Gambit-list Février 2007

gambit-list@iro.umontreal.ca

30 participants
37 discussions

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

04 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

Re: [gambit-list] compiler bug?
by Marc Feeley 03 Sep '07

03 Sep '07

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 25-Sep-06, at 3:48 PM, Sven.Hartrumpf(a)FernUni-Hagen.de wrote: > Hello Marc. > > I have a large program which behaves a little different > with gsc than any other Scheme I know of (bigloo, chicken, gauche): > Here is the problematic region: > > (let* ((orth (and (pair? word-info) > ;(not (eq? (caar word-info) 'words)) > (fs-value (car word-info) '(orth)))) > (orth-l (if orth (string-length orth) 0)) > (left-hyphen (and (> orth-l 2) > (char=? (string-ref orth 0) # > \-))) ; examples: \quw{Steuergesetzgebung und -verwaltung}, \quw > {auspringen und -setzen} > (right-hyphen (and (> orth-l 1) > (char=? (string-ref orth (- orth- > l 1)) #\-))) > (step (if left-hyphen > (and (not right-hyphen) > -1) > (and right-hyphen > 1)))) > > left-hyphen and right-hyphen are evaluated to #f for some binding - > this > is as expected. But step is bound to 1 which seems wrong to me. > Minimizing the problem might be hard for me, so I hope that you can > see > the problem already :-) > > Ciao > Sven Sven, you have just uncovered a nasty bug in the compiler. In beta 18 the transformation for the "and" form is too aggressive in the case where the second argument is a constant. As far as I can tell this bug was introduced just before beta 18 was released. Surprisingly in the 70Kloc in the Gambit runtime system and compiler this case does not occur. I have now fixed the bug and will release beta 19 shortly because this is a serious bug. Thanks! Marc -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (Darwin) iD8DBQFFGEqS//V9Zc2T/v4RAqTeAJ9asp7elGoK7yqa6MzmLFTRj6K8UwCfc3d4 5haROCNvlgMs1NREyZCgYIw= =bvLI -----END PGP SIGNATURE-----

2 1

Re: [gambit-list] Conflict bewteen #<<c-declare-end and syntax-case?
by Raffael Cavallaro 25 Mar '07

25 Mar '07

On Feb 7, 2007, at 8:06 PM, Marc Feeley wrote: > It's probably easy to fix for the implementors of syntax-case > (Dybvig et al), but I shudder at the thought of figuring out which > of the over 40 usages of 'quote in syntax-case.scm has to be made > conditional on the object being quoted (the quote should be dropped > for strings, numbers, booleans, and characters). Given that you can't fix syntax-case.scm, would it be possible to modify c-declare, etc. so that they take both strings and quoted strings? regards, Ralph Raffael Cavallaro, Ph.D. raffaelcavallaro(a)mac.com

2 2

MacGambit 2.2.2
by Frank Gizinski 27 Fév '07

27 Fév '07

To Whom it may interest, I downloaded MacGambit-C 3.0 a short time ago for my Mac OS. 9.1 and it works fine. I'm learning Scheme from the Dybvig book with aid from the UCB Scheme folder. I also downloaded MacGambit 2.2.2. I had version 2.2.2 running on Mac OS 9.1 before I had a hard disk failure. I tried the complied interpreter on the download but at startup I got an "illegal instruction error". so I tried compiling it myself. It turned out that it had to be updated to my later version of the CodeWarrior compiler. I tried that and then everything went wrong. As I said MG-C 3.0 works all right on my Mac OS 9.1 but as far as I know version 2.2.2 is the last that ran the drawing-demo1.scm and graphics from "Concrete Abstractions" on the classic Mac and I just wanted to play with the graphics. I hope someone has this rare old OS 9.1 version of 2.2.2 and I can download it. Yours, Frank Gizinski Racine, Wisconsin

1 0

Read macros in Scheme?
by James Cash 27 Fév '07

27 Fév '07

I've been using Gambit Scheme as my primary language for about a year now, and I'm finding it pretty much the best for what I'm doing. However, the one thing that I find lacking is read- macros: Why doesn't Scheme have an equivalent to CL's set-macro-char and the like? It seems to me that you can do lots of interesting things with them that you couldn't do otherwise. Does anyone know of a way to do something equivalent to the following CL in Gambit? I suspect that there's some way to do it using readtables...but I have no idea how.. (set-macro-character #\] (get-macro-character #\))) (set-dispatch-macro-character #\# #\[ #'(lambda (stream char1 char2) (let ((accum nil) (pair (read-delimited-list #\] stream t))) (do ((i (ceiling (car pair)) (1+ i))) ((> i (floor (cadr pair))) (list 'quote (nreverse accum))) (push i accum))))) Thanks for your time, any help is appreciated! James

1 0

FFI with (char *) buffer
by Ben Weaver 26 Fév '07

26 Fév '07

Hello Everyone, I'm creating an FFI that requires writing to and reading from a C (char *) buffer. The buffer may contain arbitrary binary data (not necessarily a character string). I wrote a few procedures (see below) to copy the data to and from a u8vector so I can operate on it using ports. I'm hoping for comments or suggestions from you all about the code. Is there a cleaner/better/faster way to do this? Ideally there would be some way to open a byte-port directly to the buffer so it wouldn't have to be copied. Is this possible? Thanks in advance, -Ben ;; Typical use of this code: (with-input-from-u8vector (c-buffer->u8vector foreign-pointer-to-pointer 0 buffer-size ) (lambda () ...)) (u8vector->c-buffer (with-output-to-u8vector '(char-encoding: ASCII) (lambda () ...)) foreign-pointer-to-buffer 0 buffer-size) ;; The code (declare (fixnum) (not safe)) (c-declare #<<eo-declare typedef const char * const_char_ptr; eo-declare ) (c-define-type const-char-buffer "const_char_ptr") (c-define-type size-type unsigned-int32) ; Using -D_FILE_OFFSET_BITS=64 makes off_t 8 bytes instead of 4 (c-define-type offset-type "off_t" "S64_TO_SCMOBJ" "SCMOBJ_TO_S64" #f) (define u8vector->c-buffer (c-lambda (scheme-object (pointer char) offset-type size-type) void #<<end-lambda off_t i; ___U8 c; for (i = 0; i < ___arg4; i++) { ___SCMOBJ_to_U8(___U8VECTORREF(___arg1, ___FIX(i)), &c, i); ___CAST(char *,___arg2)[i + ___arg3] = c; } end-lambda )) (define %c-buffer->u8vector (c-lambda (const-char-buffer scheme-object offset-type size-type) void #<<end-lambda off_t i; ___SCMOBJ c; ___U8* buff = ___CAST(___U8*, ___arg1); for (i = 0; i < ___arg4; i++) { ___U8_to_SCMOBJ(buff[i + ___arg3], &c, i); ___U8VECTORSET(___arg2, ___FIX(i), c); } end-lambda )) (define (c-buffer->u8vector buff offset size) (let ((v (make-u8vector size))) (%c-buffer->u8vector buff v offset size) v))

2 2

Calling Scheme code from different OS threads
by James Long 25 Fév '07

25 Fév '07

I need the ability to create OS threads because of the blocking nature of the c calls (mainly with c functions that do network stuff). I ended up wrapping up boost's excellent thread library in c functions (everything is compiled as c++ now because it's a c++ library, which should be fine) to maintain cross-platform-ness. The resulting interface is clean and simple and it works great. I noticed what should have been an expected result, however, and I'm interested in exactly what's going on. When I call a scheme function from my created OS thread, the process crashes if it does anything with I/O or anything more complex than an if/then statement. My example app crashed when I tried to call 'display' from the OS thread. I know that we are entering Scheme totally outside of it's threading system, which means it's probably accessing memory that it normally wouldn't be allowed to. Is it just a result of Gambit using shared memory often, so two executions of Gambit code corrupt each other? Again, I'll usually use the OS threads to only call C code so this isn't a problem, but I was just curious about the internal workings of Gambit (and possibly if it will support OS threads in the future? or is that Termite?) James

3 2

Some questions about declarations (mostly)
by Ian D. Leroux 22 Fév '07

22 Fév '07

Good evening (or whatever your local time of day happens to be), I'm looking into adopting gambit for some hobby projects of mine, and while exploring the documentation and the source code I noticed a few things which puzzled me. If these newbie questions elicit any responses deemed important enough for inclusion in the documentation, I'd be happy to write them up. 1- The documentation for the 'block' declaration states that: "the compiler assumes that global variables defined in the current file that are not mutated in the file will never be mutated". Strictly interpreted, this means that any global variable that *is* mutated in the current file does not benefit from this declaration. In particular, using lexical scoping to hide private variables (define (foo) 'forward) (define (bar) 'forward) (let ( ... foo and bar's secret helper functions and variables ...) (set! bar the-real-bar) (set! foo the-real-foo)) would stymie the optimizer. Does it really work that way, or does the declaration imply a stronger assumption, such as no mutation of any bindings outside the current file? 2- Am I correct in interpreting the (not core) declaration as: "the following code is made available to the compiler in case it helps optimization, but this file is not responsible for providing it to outside clients and so the compiler can ignore it if it chooses"? 3- Aside from mentioning a few of the associated error messages, the documentation doesn't discuss the namespace mechanism. Is it meant to be superseded by the R6RS library mechanism? If not, does it have any problems that should discourage mere mortals from using it? On a related note, does the ##foo notation mean "use the compiler's native implementation/interpretation of foo, even if it has been redefined in the current namespace"? 4- I note that the gambit source code (e.g. in _ptreeadt.scm) doesn't use define-structure when creating abstract data types, but rather hand-codes them as vectors with explicit tags. Is this for historical reasons, or are there tradeoffs involved? Are there circumstances under which define-structure should be avoided? I assume that R5RS compliance wasn't a concern in this case. Thanks for any and all insights, -- Ian D. Leroux

2 2

call/cc across threads
by Lang Martin 20 Fév '07

20 Fév '07

I have a (possibly irrational) bias against mutexes, and attempted to solve a threading problem with just message passing. The code works, but only part of the time. This code: (let ((th (thread-start! (make-thread (lambda () (let lp () (let ((p (thread-receive 0 #f))) (if p (p 40) (begin (thread-yield!) (lp)))))))))) (+ 2 (call/cc (lambda (ret) (thread-send th ret) (thread-sleep! 4))))) Occasionally fails by attempting to add 2 to #!void. Actually, it raises the error, but returns 42 anyway. Seems like I can get away with 4 or 5 evaluations before I hit the failure condition. It seems risky, but I was wondering if someone could explain why? If I increase thread-receive's timeout to 1, it succeeds consistently, but I haven't tried it with lots of threads -- I assume it's a race condition that would reappear. Where is the #!void coming from? Is the execution of the continuation interrupting the thread-sleep!, but returning the value of the sleep rather than the value passed to the continuation? I'm willing to use mutexes, but I'm curious. Incidentally, the end goal is a stack of database connections, maintained through mutation. It's intended to be thread-safe, so I was planning on closing over a designated thread to do the mutations, and having it return values to the calling functions through this mechanism. I'll use mutexes if that's the right solution. Lang

3 2

___H_calculate_2d_size redefinition
by Levi Pearson 19 Fév '07

19 Fév '07

I'm having trouble compiling a program I've written. There seems to be a redefinition of ___H_calculate_2d_size in the generated C code. Anyone have any idea why this happened and how I might fix it? Output: $ gsc vm.scm vm.c:6411: error: redefinition of '___H_calculate_2d_size' vm.c:6075: error: previous definition of '___H_calculate_2d_size' was here $ My system: Darwin ibook.lan 8.8.0 Darwin Kernel Version 8.8.0: Fri Sep 8 17:18:57 PDT 2006; root:xnu-792.12.6.obj~1/RELEASE_PPC Power Macintosh powerpc powerpc-apple-darwin8-gcc-4.0.1 (GCC) 4.0.1 (Apple Computer, Inc. build 5363) Gambit version 4.0 beta 20 --Levi

2 1

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

Gambit-list Février 2007