Septembre 2009 - Gambit-list - mailman.iro.umontreal.ca

Re: [gambit-list] Apple's code for Grand Central Station
by Christian Jaeger 12 Sep '09

12 Sep '09

Hello Brad I'm summarizing my understanding of "Grand Central Station" at the end of this mail [*], for the possibly benefit to others or as a base for detailed discussion or corrections if I'm missing something. To me it seems the most immediate usefulness of Apple's library for Gambit may be in the FFI, to move blocking procedure calls off the Gambit VM system thread in an efficient way (more efficient than with the pipe based approach; although I'm not sure there's another solution than a pipe for the backward communication of the results). Whether parts of the library can be useful for an SMP implementation of the VM: maybe the queue implementation? Relying on the "blocks" implementation is probably not in the interest of portability. Since I don't have OS X: has anyone gotten anything to run under Linux? Christian. [*] "Grand Central Station" seems to be, in my words: (1) a modification to the GCC (only llvm-gcc?) and clang compilers to add closure support to C/C++/ObjC, with captured bindings being read-only by default (for some reason unknown to me they call them "blocks") (2) an efficient lockless SMP safe queue implementation, used to send data to other OS threads (aka mailbox) (3) an api/spec to use the queues for sending jobs, in the form of the newly added closures (thunks); there are several queue types, some of them with guarantees to start the next job only after finishing the previous one (if I've understood correctly--I guess this will constrain concurrency, since only one job can run at the same time as the enqueuer of the job; although if the jobs themselves enqueue other jobs, maybe it can get to more than a parallelism of 2). (4) a persistent pool of threads that read jobs from those queues and run them (somehow respecting the above-mentioned user-specified serialization wishes) (5) some mechanism to increase and decrease the number of threads in the pool to a number optimal for the system. This partly depends on OS X, but at the same time adapting the pool size may simply not be necessary on operating systems with more efficient thread implementations. The whole thing seems meant to deal with short-lived jobs (I haven't seen this mentioned explicitely, but I guess you could disrupt the parallel processing if you push a couple jobs that never finish, although maybe they will increase the number of OS threads in the pool to accomodate for the never-ending threas). The idea is to avoid the overhead of creation and termination of a new OS thread for each job.

1 0

Regarding garbage collection in Windows XP
by peter lo 12 Sep '09

12 Sep '09

Dear all, I have been using Gambit to write programs for my research, but recently I encounter a problem. When I run some programs, I get this error: *** ERROR IN ##rest-param-check-heap -- Heap overflow 1> ,b 0 ##rest-param-check-heap 1 trace-back-path 2 find-seq 3 find-seq 4 find-motif-in-occ-list 5 find-motif-in-occ-list 6 find-motif-in-occ-list 7 find-motif-in-fasta-pruned 8 find-motif-in-fasta-pruned 9 find-motif-in-fasta-pruned ... 12 with-output-to-file 13 for-each 14 for-each 15 (interaction) (stdin)@69:1 (for-each (lambda (errL) ... 1> ,t I am using Gambit-C v4.4.4 on Windows XP with 1.95 GB ram. I have tried rebooting and run again, and have added a call to (##gc) for each run like this: (for errL '(0.2 0.3) (for s (append game-data-sets tompa-data-sets) (##gc) (with-output-to-file (string-append "motif_finder_res/game_tompa/" s "_g_e_" (number->string errL) "_res.txt") (f0 (find-motif-in-fasta (codify-fasta (read-fasta s) DNA-code) 5 20 (k-best-keeper 50 better-motif) errL))))) But the same problem arises, and Windows XP says virtual memory low. Is this a problem of Gambit or Windows XP? Is the garbage collector a mark and sweep one and fragmentation occurrs? Regards, Peter Yahoo!香港提供網上安全攻略，教你如何防範黑客! 請前往 http://hk.promo.yahoo.com/security/ 了解更多!

7 17

Apple's code for Grand Central Station
by Bradley Lucier 11 Sep '09

11 Sep '09

Marc: Apple has released its user-level code for Grand Central Station, its way of managing multi-core chips, under an Apache 2.0 license, which is one of the licenses under which Gambit is used. It would be interesting to see whether incorporating this as a Gambit library would quicken the resurrection of parallel Gambit. Brad http://libdispatch.macosforge.org/

1 0

[ANN] Gambit-C v4.5.2 released
by gambit＠iro.umontreal.ca 11 Sep '09

11 Sep '09

1 0

Cleaning up error checking in the bit-field code
by Bradley Lucier 10 Sep '09

10 Sep '09

Marc: Here's a small patch that reorganizes the error checking in some of the bit-field code, to remove it as much as possible from the internal ##whatever routines. I ran make check, but I have no idea whether these routines are actually checked by "make check". Oh, for a real testsuite ... Note that there's still a need for a #macro-nonnegative-exact-int? and ##fail-check-nonnegative-exact-integer. Brad

1 0

Diff to gambit.el
by Alex Queiroz 09 Sep '09

09 Sep '09

Hallo, I've added some more font locking and indentation to gambit-mode. It's not much, I am doing it an as-needed basis. If anybody else cares, I am attaching the diff. Cheers, -- -alex http://www.ventonegro.org/

1 0

Some UTF-8 support issues.
by Ramil Farkhshatov 08 Sep '09

08 Sep '09

Hello. 1. WRITE and PP procedures output unicode (UTF-8 with nonlatin characters) strings in such form: "\uXXXX\uXXXX" ; when run with t8 option "\XXX\XXX" ; when run without t8 option Also procedures returning strings output in REPL acts in same manner. Is there a way to change that behaviour? 2. Have troubles operating files with unicode names when gsi runned with t8 option. With t8 option: > (file-exists? "~/develop/каталог") #f Without t8 option: > (file-exists? "~/develop/каталог") #f OPEN-DIRECTORY cannot open directories with unicode names: > (define fd (open-directory "~/develop/каталог/")) *** ERROR IN (console)(a)20.12 -- (Argument 1) Can't convert to C char-string (open-directory "~/develop/\u043a\u0430\u0442\u0430\u043b\u043e\u0433/") Additional info: % locale LANG=ru_RU.UTF-8 LC_CTYPE="ru_RU.UTF-8" LC_NUMERIC="ru_RU.UTF-8" LC_TIME="ru_RU.UTF-8" LC_COLLATE=C LC_MONETARY="ru_RU.UTF-8" LC_MESSAGES="ru_RU.UTF-8" LC_PAPER="ru_RU.UTF-8" LC_NAME="ru_RU.UTF-8" LC_ADDRESS="ru_RU.UTF-8" LC_TELEPHONE="ru_RU.UTF-8" LC_MEASUREMENT="ru_RU.UTF-8" LC_IDENTIFICATION="ru_RU.UTF-8" LC_ALL= % echo $GAMBCOPT dar,t8E,f8,-8 -- Ramil Farkhshatov

3 3

Re: [gambit-list] Some UTF-8 support issues.
by Christian Jaeger 07 Sep '09

07 Sep '09

> I think that current locale settings (locale(7)) should be used as > default value. Software on Unix like systems, at least Linux, tends to use utf-8 for encoding of filenames nowadays, but there's no global enforcement for this. The kernel and libc treat paths just as byte strings. I guess OS X has some enforcement law to make everything use utf-8. Windows afaik stores the used encoding in the filesystem, which should make it more clear which encoding to assume (and might even do the transcoding for you, not sure). I think you can't really assume locale settings for changing this behaviour; if you do, you're fine as long as you don't change the locale for the lifetime of a particular filesystem. Since you're inevitable also going to deal with filesystems written with different encoding assumptions sometimes. Probably there's no other way to deal with it than the same way you deal with textual file ports: specify the encoding when opening the port. Meaning, give the encoding when calling |open-directory|. Maybe have another Gambit startup flag to set the default. (Gambit doesn't check the locale for file ports, why should it use the locale for directory ports?) (One could argue that if the encoding is unknown, input/output procedures should return u8vector's instead of strings, and accept u8vectors instead of strings.) Christian. (This is my first mail to a mailing list sent from Gmail, going to see whether lines are too long. If they are, what are other Gmail users doing about it?)

2 1

##subu8vector-move!
by Alex Queiroz 05 Sep '09

05 Sep '09

Hallo, I almost started coding something like ##subu8vector-move! when I found it in the source code. Is there any caveat with using it? It is not in the manual. Cheers, -- -alex http://www.ventonegro.org/

2 5

gambit + blackhole + srfi 13
by Steve Huffman 02 Sep '09

02 Sep '09

Hi All, I'm attempting to compile Black Hole on Gambit 4.5.1. I've installed BH from Git. I ran modules-compile!, and each of the standard BH modules compiled successfully, except for srfi-13, which fails because it runs out of memory. I'm running OS X with 4 gigs of ram. I notice the cc process that is spawned uses about 3.5 gigs before it dies. That seems a bit excessive, no? > (modules-compile! (modules-in-dir "~~/lib/modules/std") #t) Compiling 1 modules "/usr/local/Gambit-C/lib/modules/std/srfi/13.scm" (1/1) cc1(209) malloc: *** mmap(size=97247232) failed (error code=12) *** error: can't allocate region *** set a breakpoint in malloc_error_break to debug cc1: out of memory allocating 97245440 bytes after a total of 0 bytes Warning: Compilation failed: C compilation or link failed while compiling "/usr/local/Gambit-C/lib/modules/std/srfi/13.scm" > Thanks for any help, Steve

3 3