* libguile/unidata_to_charset.pl (designated): renamed from full
* libguile/srfi-14.c (scm_char_set_designated): new char-set
* libguile/srfi-14.i.c (cs_designated): renamed from cs_full
Since combining characters, such as accents, modify the appearance of the
previous letter, it looks awkward in its character literal form (#\name)
since it modified the backslash. This instead prints the combining
character on a small circle.
* libguile/chars.h (SCM_CODEPOINT_DOTTED_CIRCLE): new #define
* libguile/print.c (iprint1): print combining characters on dotted circles
* libguile/read.c (scm_read_character): parse the combination of combining
characters and dotted circles
* libguile/srfi-14.c (scm_i_ucs_range_to_char_set): new function that
contains the functionality of ucs_range_to_char_set, fixes
off-by-one, and doesn't store surroges
(scm_ucs_range_to_char_set, scm_ucs_range_to_char_set_x): call
scm_i_ucs_range_to_char_set
(scm_i_charset_set_range): new helper function
char-set-xor! was not modifying its input parameter. It isn't
technically required to do so by the spec, but, the other similar
functions do it.
* libguile/srfi-14.c (scm_char_set_xor_x): modify the input parameter
* module/language/tree-il/compile-glil.scm (flatten): Fix compilation of
loops within loops in non-tail positions. Will add a test case soon,
but one way to reproduce it was with the following function:
(define (test)
(let lp ()
(pk 'zero)
(let ((fk (lambda ()
(let ((fk2 (lambda () (pk 'two))))
(let ((fk3 (lambda () (if #t (pk 'three) (fk2)))))
(if #t
(fk3)
(fk2)))))))
(pk 'one)
(fk))
(lp)))
One would expect to see a sequence of "zero one three", but in fact zero
only showed once.
This should fix simplex as well.
* test-suite/tests/encoding-iso88591.test: tests for writing and display
of characters
* test-suite/tests/encoding-iso88597.test: tests for writing and display
of characters
* test-suite/tests/encoding-utf8.test: tests for writing and display
of characters
String ports, being 8-bit, store strings using the character encoding
of the port. This fixes a bug where the default character encoding, and
not the port's encoding, was being used to convert the string port data
back to a string.
* libguile/strports.c: extra comments
(scm_strport_to_string): use port's encoding when converting port data
to a string
* libguile/strings.c (scm_i_from_stringn): renamed from scm_from_stringn
and made internal. All callers changed.
(scm_from_stringn): renamed to scm_i_from_stringn.
* libguile/strings.h: declaration for scm_i_from_stringn
* libguile/srfi-14.c (charsets_complement): use surrogate #defines instead
of hardcoded numbers
* libguile/srfi-14.i.c (cs_full_ranges): remove surrogates from full
charset
* libguile/unidata_to_charset.pl (full): test for surrogates
* libguile/gc_os_dep.c (GC_linux_stack_base) [LINUX_STACKBOTTOM]: cast
input of ctype functions to int
* libguile/inet_aton.c (inet_aton): cast input of ctype functions to int
* libguile/read.c (scm_scan_for_encoding): cast input of isalnum to int
* libguile/win32-socket.c (scm_i_socket_uncomment): cast input of isspace
to int
* libguile/load.c (scm_primitive_load_path): If the compiled path was
out of date, but the fallback path was current, we correctly detected
that case, but loaded the wrong file. So here fix the typo.
* test-suite/lib.scm (with-locale, with-locale*): new test functions
* test-suite/tests/encoding-escapes: don't fail if en_US.utf8 doesn't exist
* test-suite/tests/encoding-iso88591.test: set and restore locale, if
possible
* test-suite/tests/encoding-iso88597.test: set and restore locale, if
possible
* test-suite/tests/encoding-utf8.test: set and restore locale, if possible
* test-suite/tests/srfi-14.test: don't need to setlocale to Latin-1 to
test Latin-1 since string conversion is handled at read/compile time.
Set and restore locale, if possible.
This script was used to generate srfi-14.i.c from the UnicodeData.txt
file supplied by ftp://www.unicode.org/Public/UNIDATA/
* libguile/unidata_to_charset.pl
* emacs/gds-scheme.el (gds-start-utility-guile): Use buffer-local
variable gds-client instead of client, as client is actually unbound
when the process-filter lambda runs. (i.e. This isn't Scheme code!)
* emacs/gds-scheme.el (gds-start-utility-guile): Make the extraction
of client number more robust; in particular when the client emits
comments (about auto compilation) before the number.
i.e. put the extensions where they need to be, and delete
ice-9-debugger-extensions.scm.
* doc/ref/api-debug.texi (Single Stepping through a Procedure's Code):
Change mentions of (ice-9 debugging ice-9-debugger-extensions)
module to whatever is appropriate now (or just remove them).
* module/Makefile.am (NOCOMP_SOURCES): Remove
ice-9-debugger-extensions.scm.
* module/ice-9/debugger.scm (debug-trap): Move here from
ice-9-debugger-extensions.scm.
* module/ice-9/debugger/command-loop.scm ("continue", "finish",
"step", "next"): Move here from ice-9-debugger-extensions.scm.
* module/ice-9/debugger/commands.scm (assert-continuable, continue,
finish, step, next): Move here from ice-9-debugger-extensions.scm.
* module/ice-9/debugging/breakpoints.scm: Don't use
ice-9-debugger-extensions module.
* module/ice-9/debugging/ice-9-debugger-extensions.scm: Removed.
* module/ice-9/debugging/trace.scm, module/ice-9/debugging/traps.scm:
Remove more old version code.
* module/ice-9/debugging/traps.scm (guile-trap-features): Hardcoded as
'(tweaking).
* module/ice-9/debugging/ice-9-debugger-extensions.scm: Remove all
code checking for version < 1.7, and move code for versions >= 1.7
up to top level. Comment out dummy mutex definitions for now, as
I'm not sure how to rewrite them correctly for psyntax.
On Aug 5, 2009, at 10:06, Ken Raeburn wrote:
> (1) In scm_pthread_mutex_lock, we leave and re-enter guile mode so
> that we don't block the thread while in guile mode. But we could
> use pthread_mutex_trylock first, and avoid the costs scm_leave_guile
> seems to incur on the Mac. If we can't acquire the lock, it should
> return immediately, and then we can do the expensive, blocking
> version. A quick, hack version of this changed my run time for
> A(3,8) from 17.5s to 14.5s, saving about 17%; sigaltstack and
> sigprocmask are still in the picture, because they're called from
> scm_catch_with_pre_unwind_handler. I'll work up a nicer patch
> later.
Ah, we already had scm_i_pthread_mutex_trylock lying around; that made
things easy.
A second timing test with A(3,9) and this version of the patch (based
on 1.9.1) shows the same improvement.
* libguile/threads.c (scm_pthread_mutex_lock): Try the mutex before
leaving and reentering guile mode.
From Ken Raeburn:
The Mac build off of "master" fails for me currently in srfi-13.c,
with the comparison-always-false warning Greg discussed. I hacked
around that, but then guile-readline doesn't build:
Making all in guile-readline
../libguile/guile-snarf -o readline.x ../../guile-readline/readline.c
-
DHAVE_CONFIG_H -I. -I.. -I../../guile-readline/.. -I../../guile-
readline/lib -I./lib -g -O2
In file included from ../../guile-readline/readline.c:29:
../../guile-readline/../libguile.h:25:17: error: gmp.h: No such file
or directory
In file included from ../../guile-readline/../libguile.h:95,
from ../../guile-readline/readline.c:29:
../../guile-readline/../libguile/strings.h:26:21: error: uniconv.h: No
such file or directory
Neither the path specified for libgmp nor the path specified for
libunistring at configure time is included here.
I don't think any of this is Mac-specific; I'm surprised that it works
on GNU/Linux systems. Perhaps I'm building it in ways that are
unusual for the other developers (build dir != src dir, libgmp and
guile-1.8 installed in the same place, libgmp and libunistring
installed in different nonstandard directories)?
If I use CPPFLAGS=... and LDFLAGS=... instead of --with-libfoo-prefix
configure options to specify paths to find libgmp and libunistring,
the tests still pick old, installed Guile headers (which this time
I've poisoned to highlight the problem) from those locations instead
of the in-tree versions:
Making all in test-suite
Making all in standalone
../../libguile/guile-snarf -o test-asmobs-lib.x ../../../test-suite/
standalone/test-asmobs-lib.c -DHAVE_CONFIG_H
-I. -I../../../test-suite/ standalone -I../.. -I/opt/local/include
-I/Users/raeburn/dev/guile/ libunistring-0.9.1/I/include -g -O2
-I../../.. -I../../../lib -I../../ lib -I../..
In file included from /opt/local/include/libguile.h:30,
from ../../../test-suite/standalone/test-asmobs-
lib.c:23:
/opt/local/include/libguile/__scm.h:3:2: error: #error Poison!
I might be building Guile as part of a larger package
(*cough*Emacs*cough*) that wants to include stuff from the same system
directories (e.g., for MacPorts, pkgsrc, whatever) where an old
version of Guile is installed, and thus Guile gets passed CPPFLAGS/
LDFLAGS settings that add that old version to the search paths. So I
think the CPPFLAGS/LDFLAGS version needs to be made to work, as well
as the --with-libfoo-prefix version.
With the attached patch, I can get guile to build with CPPFLAGS= and
LDFLAGS= ... someone more familiar than I am with automake will have
to fix the guile-readline stuff.
* meta/Makefile.am (bin_SCRIPTS): Re-add guile-tools here (removed in
54b38caf19). Otherwise guile-tools
doesn't get installed. I think that 1.9.2 had this bug.
