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

Public release of Snow
by Marc Feeley 02 Mar '07

02 Mar '07

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 It is my pleasure to announce the public release of Snow, a repository of portable Scheme packages. You can read more about Snow on the Snow web site at: http://snow.iro.umontreal.ca Marc -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (Darwin) iD8DBQFF56gt//V9Zc2T/v4RAksJAKCL0lHdxrhgrm4taefhMSif3fl0KgCgs6Ml tFitKdsKEt467nH4zzRa7QA= =fWNk -----END PGP SIGNATURE-----

1 0

MacGambit 2.2.2
by Frank Gizinski 28 Fév '07

28 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 28 Fév '07

28 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 27 Fév '07

27 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 23 Fév '07

23 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 20 Fév '07

20 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

Re: [gambit-list] open-tcp-client behavior
by schemeway＠sympatico.ca 20 Fév '07

20 Fév '07

François, > I am currently working on a multi-platform project and I stumbled on > a difference in the behavior of open-tcp-client between MacOSX and > Windows (MinGW) using Gambit-C 4.0 beta20. The difference occurs > when I open a connection to an address where no server is running and > try to read from it. In MacOSX I get an exception and in Windows I > get an infinite loop. I noticed this behaviour too a few days ago (on Cygwin). If you set a timeout on the input connection, read-line returns #!eof instead of throwing an exception. That's misleading. I think the correct behaviour would be for open-tcp-client to throw an exception, not wait until read-line is called. Dominique _______________________________________________ Gambit-list mailing list Gambit-list(a)iro.umontreal.ca https://webmail.iro.umontreal.ca/mailman/listinfo/gambit-list

1 0

open-tcp-client behavior
by François Magnan 19 Fév '07

19 Fév '07

Hi, I am currently working on a multi-platform project and I stumbled on a difference in the behavior of open-tcp-client between MacOSX and Windows (MinGW) using Gambit-C 4.0 beta20. The difference occurs when I open a connection to an address where no server is running and try to read from it. In MacOSX I get an exception and in Windows I get an infinite loop. Here is a trivial test: (define (test-tcpclient) (let ((p (open-tcp-client (list server-address: "127.0.0.1" port-number: 8087 eol-encoding: 'cr-lf )))) (display "test\n\n" p) (read-line p))) On MacOSX I get: *** ERROR IN ##read-line -- Connection refused (read-char '#<input-output-port #3 (tcp-client "127.0.0.1" 8087)>) On Windows I get an infinite loop waiting for the read-line to terminate. I know I can put some timeout on the read-line but I think the MacOSX behavior is the correct one. Thank you, Francois Magnan

1 0