Gambit-list Janvier 2006

gambit-list@iro.umontreal.ca

15 participants
32 discussions

Gambit-C 4.0 beta 17
by Marc Feeley 11 Jan '06

11 Jan '06

Beta 17 of Gambit-C 4.0 is now available in source form at this address: http://www.iro.umontreal.ca/~feeley/gambc40b17.tar.gz It includes the bug fixes discussed on this list over the past few days. Marc P.S. We're planning a major face-lift for the Gambit web site. What would you like to see on the site? If you have suggestions please let us know. Sorry if the latest releases are not on the web site... I have lost the password and it is taking longer than expected to get a new one... sigh!

4 6

--enable-single-host comments in INSTALL.txt
by Sven.Hartrumpf＠FernUni-Hagen.de 11 Jan '06

11 Jan '06

Hi all. INSTALL.txt: "--enable-single-host This option is not used by default because compilation is much longer and requires much more RAM. In fact some platforms may not have enough resources to build the system this way. With --enable-single-host the build takes roughly 500 megabytes and 20 minutes on a 1.2 GHz Athlon Linux machine with the GCC 3.1 compiler instead of 100 megabytes and 2 minutes when --enable-single-host is not used." This warning might be a little dated. On a Pentium M 1600, "make" (with gcc 3.4.4) takes less than 150MB and around 103 seconds. (Gambit Version 4.0 beta 17) And make -j 2 takes only 98 seconds. Greetings Sven

2 1

reserved identifiers
by Thomas Hafner 11 Jan '06

11 Jan '06

scheme-r5rs renders this error message when I load SLIB and enter (require 'http): *** ERROR IN "/usr/share/slib/htmlform.scm"@83.28 -- Reserved identifier can't be used as a variable: delay The referenced SLIB code looks like this: (define (html:meta-refresh delay . uri) ;;this is line 83 (if (null? uri) (sprintf #f "\\n<META HTTP-EQUIV=\"Refresh\" CONTENT=\"%d\">" delay) (sprintf #f "\\n<META HTTP-EQUIV=\"Refresh\" CONTENT=\"%d;URL=%s\">" delay (car uri)))) Should this SLIB code be portable? Is Gambit-C somehow special? Is there a list of all reserved identifiers? My system is: - Ubuntu with Linux kernel 2.6.11 amd64 - Gambit-C 4.0b16 - SLIB 3a1-4.2 Regards Thomas

1 0

We want our SMP! (with apologies to MTV)
by Bradley Lucier 10 Jan '06

10 Jan '06

Marc: My new 8-core opteron server with 16GB of ram just went online today, and I want to plaaaaaaay! When can we have a single-image, multi- processor runtime? Please, pretty-please, pretty-please, huh???? Are we there yet? Brad PS: Are we there yet?

3 8

Input buffering and other IO issues
by Christian 08 Jan '06

08 Jan '06

Hello I wanted to write a small program which reads exactly n bytes from a port (and calculates an md5 hash on them, like "head -c n | md5sum"). It turned out that even with buffering: #f, read-subu8vector reads through buffers, as strace shows (it reads in 1024 byte chunks, not in the lengths I'm giving to read-subu8vector). The reason why I want it to not read past the given number of bytes is: - I wanted to checksum a cdrom (by reading from /dev/cdrom), and reading past the length of the cdrom image is giving read errors on my OS (linux on ppc). - I might need it for reading from pipes and not block (I've not checked whether gambit would block the thread or not), or worse, read from pipes used for interprocess-locking (even if gambit doesn't block when trying too many bytes from a pipe, it will break the idea of using pipes for locking). (define-macro (qq . lis) (list 'quasiquote lis)) (define (test bytes path) (call-with-input-file (qq path: ,path ;;char-encoding: #f -> STRING or port settings expected char-encoding: ascii buffering: #f ) (lambda (port) (let ((buf (make-u8vector bytes))) (let ((res (read-subu8vector buf 0 bytes port))) res))))) > (test 20 "./cj-md5sum-cdrom.scm" ) 20 open("/home/chris/schemedevelopment/gambit/mod/./cj-md5sum-cdrom.scm", O_RDONLY|O_NONBLOCK) = 4 ioctl(4, SNDCTL_TMR_TIMEBASE or TCGETS, 0xbf911cc8) = -1 ENOTTY (Inappropriate ioctl for device) fstat64(4, {st_mode=S_IFREG|0664, st_size=2258, ...}) = 0 read(4, "; cj Sun, 08 Jan 2006 01:29:03 +"..., 1024) = 1024 close(4) = 0 write(3, "2", 1) = 1 write(3, "0", 1) = 1 write(3, "\n", 1) = 1 write(3, ">", 1) = 1 write(3, " ", 1) = 1 In this strace output a second issue can be seen as well: output to the console is done in single bytes (maybe chars). This makes output of a gambit process to emacs (when running under run-scheme) slow (much so on my laptop, where there seems to be an issue with frequent system calls between programs). Either outputting objects as a whole instead of single characters (the way unbuffered output in e.g. perl works), or buffering on line boundaries, would be an improvement. Finally, I can't understand why I'm getting this: > (test 10 "/dev/cdrom") *** ERROR IN (console)(a)7.1 -- Unknown error (call-with-input-file '(path: "/dev/cdrom" char-encoding: ascii buffering: #f) '#<procedure #3>) 1> head -c 10 /dev/cdrom works just fine, as the same system user. It might help if the error message would include the OS level message. strace output: open("/dev/cdrom", O_RDONLY|O_NONBLOCK) = 4 ioctl(4, TCGETS, 0x7ffff148) = -1 EINVAL (Invalid argument) fstat(4, {st_mode=S_IFBLK|0660, st_rdev=makedev(22, 0), ...}) = 0 close(4) = 0 Thanks Christian.

2 1

Re: [gambit-list] Interrupted in wait-for-io
by Christian 08 Jan '06

08 Jan '06

At 10:28 Uhr -0500 04.01.2006, Marc Feeley wrote: >It is possible using undocumented procedures. Here's what you want: Thank you. >I'm planning to change this so that the default user-interrupt- >handler behaves like exceptions, i.e. the default will be to >terminate the program after displaying "*** INTERRUPTED IN ...". The default for unix programs is that SIGINT makes them terminate *and deliver that fact to the parent* (through wait(2) the parent can know if the child terminated because of a signal and which one it was). If you trap SIGINT, then afaik the only way to make the parent know we are terminating because of a signal is to remove our signal handler and then killing ourselves again. This poses the question as to why a signal handler has been installed in the first place. I think that printing a message and exiting with an error code is a nonstandard and thus suboptimal solution, and that not installing signal handlers at all unless really necessary would be, in principle, a better solution. (I'm mainly coming from perl, which works that way.) I don't want to suggest to give this a high priority though and also have never really programmed on non-unix systems. >With the runtime option "-:d" the system will instead start a REPL. >With the runtime option "-:d0" the program will terminate silently. >However, when inside a REPL (such as the one normally started in >interactive mode), a SIGINT will start a nested REPL. That makes sense to me. >>(*) that leads to another question I've been wondering about: >>parameterize doesn't accept procedures which aren't parameters (it >>checks their type). This makes the above suggestion impossible to >>be implement transparently of course, since it would require >>running code other than just for setting the dynamic value (**). > >I don't understand what you mean. Here's a normal parameter p1, and a self-written parameter like function p2 which has the side effect of something like initializing signal setup if not done already: (define p1 (make-parameter #f)) (define pseudo-signal-handler-hook #f) (define p2 (let ((absent (gensym)) (value #f)) (lambda (#!optional (newvalue absent)) (if (eq? newvalue absent) value (begin (if (not pseudo-signal-handler-hook) (set! pseudo-signal-handler-hook (lambda () (display "hello world\n")))) (set! value newvalue)))))) ; > (p1) ; #f ; > (p1 "hello") ; > (p1) ; "hello" ; > (p2) ; #f ; > pseudo-signal-handler-hook ; #f ; > (p2 "world") ; > (p2) ; "world" ; > pseudo-signal-handler-hook ; #<procedure #2 pseudo-signal-handler-hook> ; > (#2) ; hello world ; > (begin (parameterize ((p1 "a")) (display (p1))(newline)) (display (p1))(newline)) ; a ; #f ; > (begin (parameterize ((p2 "a")) (display (p2))(newline)) (display (p2))(newline)) ; *** ERROR IN (console)(a)3.8 -- PARAMETER expected ; 1> The problem is that my side-effecting pseudo parameter cannot be transparently used with parameterize. It occured to me as an unnecessary drawback when I first realized that parameters were procedures but procedures can't be parameters. I did assume parameterize were implemented about like this (e.g. querying the old value, storing in lexical context, setting new value with dynamic-wind): ; (let ((#:g10 (p2))) ; (dynamic-wind ; (lambda () (p2 "a")) ; (lambda () (display (p2)) (newline)) ; (lambda () (p2 #:g10)))) (let ((#:var2 "a")) (let ((#:swap4 (lambda () (let ((#:tmp3 (p2))) (p2 #:var2) (set! #:var2 #:tmp3))))) (dynamic-wind #:swap4 (lambda () (display (p2)) (newline)) #:swap4))) ; as generated by this macro: (define-macro (my-parameterize bindings . body) (let* ((b-alist (map (lambda (l) (cons l (gensym 'var))) bindings)) (b->var (lambda (l) (cdr (assoc l b-alist)))) (b->name car) (b->init cadr) (tmp (gensym 'tmp)) (swap (gensym 'swap))) `(let ,(map (lambda (l) (list (b->var l) (b->init l))) bindings) (let ((,swap (lambda () ,@ (map (lambda (l) `(let ((,tmp (,(b->name l)))) (,(b->name l) ,(b->var l)) (set! ,(b->var l) ,tmp))) bindings)))) (dynamic-wind ,swap (lambda () ,@ body) ,swap))))) I know this implementation of parameterize has a problem though: dynamic-wind is not safe when using exceptions. Why? I find this especially strange considering that I thought with-exception-catcher was implemented using continuations. Which other reasons are there for implementing parameters differently? Performance or semantics? I guess the above implementation would be rather slow. I've taken a cursory look at the srfi-39 document and discussion archive, but most of it is over my head right now, I'll reread later. So, it seems that the "most natural way" of how parameterize would be implemented is not the best and thus I shouldn't expect to be able to put callbacks into a supposedly lowlevel dynamic bindings mechanism. >>What's the reason for this restriction? >> > >Parameters are special procedures that contain a key. This key is >used to lookup the binding of the parameter. The machinery is quite >complex (see _thread.scm). I'll reread it later. >>((**) without this, the user would have to run some >>(user-interrupt- initialize!) hook first -- at least, that might be >>better for thread safety?) Thanks, Christian.

2 4

Re: We want our SMP! (with apologies to MTV)
by Bradley Lucier 07 Jan '06

07 Jan '06

You asked: > P.S is that Opteron for real? Yes, is has 8 cores in four packages, 16GB, etc. It's a slightly slower version of this one: http://store.sun.com/CMTemplate/CEServlet? process=SunStore&cmdStartWebConfig_CP&familyCode=SFV40Z&baseSelected=3

1 0

Gambit-C 4.0 beta 16
by Marc Feeley 06 Jan '06

06 Jan '06

Beta 16 of Gambit-C 4.0 is now available in source form at this address: http://www.iro.umontreal.ca/~feeley/gambc40b16.tar.gz Most of the bugs reported since the last release have been fixed. Marc

4 8

New bignum macros in gambit.h
by Bradley Lucier 06 Jan '06

06 Jan '06

Marc: I tired of wondering whether fixing the bignum macros in gambit.h would speed up bignum calculations substantially, so I changed them, and the answer is, No, not really. I get about 2% speedup on some operations, less on others, on a 2GHz G5 running Mac OS X 10.4.3, with CC='gcc -mcpu=970 -m64' So I investigated why this was happening. It turns out that I already had changed the macros for F64VECTOR{REF,SET} to use the information that the bottom bits of a fixnum are zero, so the fft in bignum multiplication didn't benefit much from the change. (Loading and unloading 8-bit values from the bignum didn't benefit from this information about fixnums.) Gambit needs a better GVM register allocator. You know that---there is way too much screwing around moving values one and off the stack at basic block boundaries, the stack is used for local variables in a basic block, etc. You had code in the compiler to deal with at least the latter problem, perhaps you want to break it out again and look at it more closely. _num.o is a bit smaller with the new macros: [lindv2:~/programs/gambc40b16-new] lucier% ll lib/_num.o -rw-r--r-- 1 lucier lucier 589036 Jan 6 12:32 lib/_num.o [lindv2:~/programs/gambc40b16] lucier% ll lib/_num.o -rw-r--r-- 1 lucier lucier 589260 Jan 6 10:48 lib/_num.o The new macros are a *lot* cleaner, however, and the speedups are fairly consistent, so I'm including my changed gambit.h in this e- mail. I tested it with my set of bignum operations in gambit- trace2.scm, which I'm also including, together with the results. The new macros assume that ___{S,U}32 and ___{S,U}16 types exist. Perhaps you'd like to say a few words why you jump through all the hoops you do to allow Gambit to run on machines that don't have these types. (I don't know of any current machines like that.) BTW, some of the bignum a-digit macros were used in ways that I wasn't familiar with; you must have added some new macros that used the BIGA* macros in new ways. I didn't want to screw with the new use of those macros, so I renamed the old macros to ___MARCBIGA* and left them. Perhaps you'd like to look at those. Brad

1 1

Interrupted in wait-for-io
by Christian 04 Jan '06

04 Jan '06

Hello Why aren't interrupts (ctl-c in particular) running the current exception handler, but instead enter the debugger unconditionally? $ cat testinterrupt.scm (with-exception-catcher (lambda (e) (display "Catched an exception: ") (write e) (newline) (##repl)) (lambda () (read))) $ gsi > (load "testinterrupt.scm") *** INTERRUPTED IN ##wait-for-io! 1> fooo Catched an exception: #<unbound-global-exception #2> 1> foo *** ERROR IN (console)(a)3.1 -- Unbound variable: foo 2> Note that inside the debugger, my exception handler is still active, as shown after entering |fooo|. So it's not that ##wait-for-io or some other function would install another handler, but that the current-exception-handler is simply ignored. Same thing in compiled code, except that there's no handler catching exceptions when inside mine: $ gsc -warnings testinterrupt $ gcc -O3 -fomit-frame-pointer -mpreferred-stack-boundary=2 -Wdisabled-optimization testinterrupt.c testinterrupt_.c -I/usr/local/Gambit-C/include -L/usr/local/Gambit-C/lib -lgambc -lm -lutil -ldl -o testinterrupt $ ./testinterrupt *** INTERRUPTED IN ##wait-for-io! > foo Catched an exception: #<unbound-global-exception #2> > foo *** ERROR IN (console)(a)2.1 -- Unbound variable: foo $ The real problem with this is: how can I create a standalone Gambit program that exits when it gets SIGINT ? Thanks Christian.

2 3

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

Gambit-list Janvier 2006