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

Edge triggered I/O with libevent
by Adam Langley 05 Avr '13

05 Avr '13

Gambit uses the select call on POSIX systems to multiplex IO operations. This is fine for small numbers of file descriptors, but falls apart quickly with large numbers[1]. libevent[2] is a wrapper library around a number of modern IO multiplexing systems (epoll on Linux, kqueue on the BSDs as well as poll and select). Attached is a patch which converts Gambit to using edge triggered I/O with epoll and libevent. This also requires a patch (attached) of libevent since the standard distribution doesn't include edge triggering support and the upstream appears to be on holiday. (epoll is required because I don't have a BSD box on which to develop edge triggering support for kqueue) This patch (for Gambit) preprocesses away to nothing unless --enable-libevent is passed to the configure script. (Note that, since this patches the configure.ac script, you'll need to run autoconf to regenerate). I hope I've not broken anything, but at this stage I've only tested that the console and tcp ports work. This patch (in the future) should also allow people, who write programs which use socket calls directly, to integrate into the main event loop at some point. Testing is more than welcome and, if you find a form of IO which is broken, please email me. [1] http://monkey.org/~provos/libevent/libevent-benchmark2.jpg [2] http://monkey.org/~provos/libevent/ -- Adam Langley agl(a)imperialviolet.org http://www.imperialviolet.org (+44) (0)7906 332512 PGP: 9113 256A CC0F 71A6 4C84 5087 CDA5 52DF 2CB6 3D60

2 2

Interactive 3D graphics with Gambit-C
by Alex Sandro Queiroz e Silva 06 Jan '10

06 Jan '10

Hallo, I am thinking about doing some basic 3D graphics with Gambit-C. Although I am sure code generated by Gambit-C is fast enough[1], I am a bit worried about the garbage collector. What's the type of garbage collector used by Gambit? If it kicks in during interactive rendering, should I expect annoying pauses? [1] - http://www.ventonegro.org/2008/09/the-need-for-speed/ -alex http://www.ventonegro.org/

5 7

Serialization of structures
by François Magnan 01 Déc '09

01 Déc '09

Hi, I found a strange behavior with serialization/deserialization: (define-structure point x y color) (define p (make-point 3 5 'red)) (point? (u8vector->object (object->u8vector p))) ==> #f Here is my version info: gsi -v v4.5.3 20091112143817 i386-apple-darwin10.2.0 "./configure --no-create --no-recursion" Are structures serializable? Thank you Francois Magnan

2 1

Problem with fxbit-set?
by Alex Queiroz 27 Nov '09

27 Nov '09

Hallo, Is this the intended behaviour? > (bit-set? 3 99) #f > (fxbit-set? 3 99) *** ERROR IN (console)(a)12.1 -- (Argument 2) Out of range (fxbit-set? 3 99) 1> ,d > (##fxbit-set? 3 99) #f Cheers, -- -alex @asandroq http://www.ventonegro.org/

3 2

Web design with gambit question
by Alfonso Urroz 26 Nov '09

26 Nov '09

Marc, I know you have answered this before, but I just wanted to know, where is the web application file or files on Gambit Scheme? Thanks. Alfonso Urroz

2 1

Threading and TCP-SERVICE-REGISTER! (or, how to join on the service
by James Long 19 Nov '09

19 Nov '09

Hey guys, I've been working on some server code in Gambit. One of my projects uses TCP-SERVICE-REGISTER! to start a service. The problem with this is that when I go to run the program, Gambit doesn't wait for all threads to exit by default, so my program immediately exists. I've seen people add a (##repl-debug-main) call at the end of the script to keep the program going, but there are several IO issues with doing this. I would like to simply: * Tell Gambit to wait for all threads to exit before exiting OR * Get the thread for the tcp service and join on it OR * Write a function which joins on all threads The third option is a bit mysterious to me. I'm not sure how to get all threads safely, but here was an attempt. This is pseudo-code basically. The problem with this code is that threads may exit after I have put them into my list but before I call join on them. (define (thread-join-all!) (let* ((threads (vector->list (thread-group->thread-vector (thread-thread-group (current-thread)))))) (for-each (lambda (el) (if (not (eq? el (current-thread))) (thread-join! el))) threads))) What would be the best way to join on the threads created by TCP-SERVICE-REGISTER! ?

2 6

Re: [gambit-list] Speed improvement of lib/digest.scm
by Marc Feeley 19 Nov '09

19 Nov '09

On 19-Feb-09, at 4:49 PM, Mikael More wrote: > Cool! > > Useful! > > What is the approx speed on your machine btw? > On my 2GHz Mac Book Pro: For MD5: 0.06 seconds per MB. For SHA-1: 0.13 seconds per MB. That's still about 3 times slower than the "md5" utility on my machine, but still not too bad for bit-bashing code entirely written in Scheme. Marc

4 10

[ADMIN] - accessing list archive gives invalid certificate error
by Raffael Cavallaro 18 Nov '09

18 Nov '09

The mailing list archive: <https://mercure.iro.umontreal.ca/pipermail/gambit-list/> linked to from the main page of the wiki gives an error that the user is attempting a secure connection to a server with an invalid certificate. I receive this error in both Firefox and Sarari under Mac OS X 10.6.2. Configuration error or has someone hijacked this link... warmest regards, Ralph Raffael Cavallaro raffaelcavallaro(a)me.com

1 0

Speed of u8vector-ref
by Alex Queiroz 17 Nov '09

17 Nov '09

Hallo, According to statprof, I am spending nearly 40% of my running time in lines which call 'board-ref', which is simply defined as: (define board-ref u8vector-ref) 'u8vector-ref' seems a pretty low-level call, so I can't see how this can be improved further. It is just a macro around '##u8vector-ref'. Maybe using it directly instead of 'board-ref'? Or is this probably a memory alignment issue? Cheers, -- -alex @asandroq http://www.ventonegro.org/

2 5

Gambit-C 4.5.3 breaks blackhole import of compiled modules
by Nicola Archibald 17 Nov '09

17 Nov '09

Reported as an 'issue' on the blackhole tracker (http://github.com/pereckerdal/blackhole/issues/#issue/6) but I figured I'd copy it to the list in case anyone else was interested/being-affected, or on the offhand chance that this isn't a responsibility of blackhole to correct for a change in gambit... upgrading to 4.5.3 kills import dead in it's tracks whenever you have a module that uses the C FFI and thus requires compilation. As demonstrated below (only change is upgrade to 4.5.3 and re-build of 'build.scm'/removal of ns.dat) [nikki@vbox src]$ bsc Loaded Black Hole... Gambit v4.5.2 > (import test-c) /home/nikki/src/test-c is being compiled... > (c-print) Hello world > ===== [nikki@vbox src]$ bsc Loaded Black Hole... Gambit v4.5.3 > (import test-c) /home/nikki/src/test-c is being compiled... *** ERROR -- Operator is not a PROCEDURE (#("test-c.o1" ##2 <http://github.com/pereckerdal/blackhole/issues/#issue/2> | test-c.o1|>)) > At a guess, this is likely caused by something in the following commit : http://www.iro.umontreal.ca/~gambit/repo/.cgit.cgi/Gambit/commit/?id=5bae3c… <http://www.iro.umontreal.ca/%7Egambit/repo/.cgit.cgi/Gambit/commit/?id=5bae…>

3 3