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

[ANN] Gambit-C v4.5.0 released
by gambit＠iro.umontreal.ca 06 Aoû '09

06 Aoû '09

1 0

OBJ model loader for Gambit, serialization/deserialization examples
by James Long 04 Aoû '09

04 Aoû '09

Hey guys, If anyone here is doing 3d stuff with Gambit, you might find my OBJ model loader useful. It'll load vertices, normals, and indices for models from the Wavefront .OBJ format. I'll implement UV coordinates soon. I wrote a blog post about using it and posted the code (it's also in the gambit iphone github project and I'll be improving it there): http://jlongster.com/blog/2009/08/3/iphone-physics-and-models/ I also studied Gambit's serialization mechanisms using object->u8vector for compressing models and speeding up loading times. It turned out great! You can find examples in my post. Hope someone finds it useful. Thanks - James

3 3

Re: [gambit-list] scheme on llvm
by Harold Ancell 01 Aoû '09

01 Aoû '09

At 02:19 AM 7/31/2009, lowly coder wrote: >I've been on gambit for 6+ months now; and the more I dig into the >internal *.scm's, the more I'm impressed -- anyone interested in >forming a group to port this to LLVM as an exercise to better >understand gambit internals? Something like meeting on irc 15 minutes >every week or so to discuss would be really nice. I'm very interested, but I just got tasked with creating a web site of some sophistication and it looks like I'll be drawn to the Clojure side of the Force, which at minimum will be educational (e.g. it's by default functional). But who knows.... Back then I got a snapshot of the initial cut by Arnaud Bergeron and Mathieu Larose from the former for placement in the Dumping Grounds, but didn't get a release from the latter for putting it there; I didn't try very hard at all and didn't follow up. Mathieu, say the word and I'll put that snapshot up. >On Thu, Jul 30, 2009 at 9:50 PM, Bradley Lucier<lucier(a)math.purdue.edu> wrote: >> >> On Jul 31, 2009, at 12:39 AM, Nguyen Thai Ngoc Duy wrote: >> >>> It's six months since this post. Any progress on the llvm backend? >> >> The last time I compiled the Gambit-generated C code with LLVM (which >> wasn't so long ago) gsi failed at startup. (I know this isn't what >> you're referring to, but I presume the LLVM compiler may have the >> same difficulties compiling the LLVM intermediate representation.) Hmmmm; I assume you used the gcc front end instead of Clang? - Harold

2 4

scheme on llvm
by lowly coder 31 Jul '09

31 Jul '09

this is kinda off topic, -- but people here seem really smart, so I'll risk the occasional flames for good criticism + insight i think the llvm/jvm projects are really cool, since so much work is put into jitting; and for one reason or another, I like llvm more than jvm i'm curious about the possiblity of a high performance scheme (and perhaps gambit in particular) running on llvm; where the 'initial implementation' may not be all that fast ... but letting llvm jit it away how does this sound? feasible for a scheme (but not gambit)? down the pipes planned for gambit? or totally stupid/crazy? the 'main' advantage of this approach is that I _assume_ that the llvm guys are pretty good at hacking up interpreters / jit's ... so why not benefit from their constant progress :-D

5 7

Re: [gambit-list] error running with emacs in windows xp
by Oisín 30 Jul '09

30 Jul '09

This is a somewhat old thread, but I'm getting this same behaviour on my Windows Vista box at work with Gambit 4.4.3 and 4.4.4 (it's never happened on my OS X machine) - ^D starts a spammy infinite loop: ;;;; Gambit v4.4.4 > (go-into-a-weird-infinite-loop-because-this-symbol-is-unbound) *** ERROR IN (stdin)(a)1.2 -- Unbound variable: go-into-a-weird-infinite-loop-because-this-symbol-is-unbound 1> *** ERROR IN (stdin)(a)1.2 -- The pipe has been ended. (peek-char '#<input-port #2 (stdin)>) 1> *** ERROR IN (stdin)(a)1.2 -- The pipe has been ended. (peek-char '#<input-port #2 (stdin)>) 1> *** ERROR IN (stdin)(a)1.2 -- The pipe has been ended. (peek-char '#<input-port #2 (stdin)>) ;;;; It spams the console in Emacs until I send a kill signal. As before, debugger commands like ,t and ,d work fine though. Do I have Emacs configured wrong (after all, I can be pretty dumb), or is this a regression? Oisín

1 0

namespace woes
by lowly coder 28 Jul '09

28 Jul '09

~$ cat test.scm (define bleh 10) (##namespace ("foo#")) (##include "~~lib/gambit#.scm") (define + 20) (define blah 20) (define bleh 20) (##namespace ("")) (pp `(+ ,+)) (pp `(bleh ,bleh)) (pp `(blah ,blah)) ; what's going on? ~$ gsi test.scm (+ 20) (bleh 10) *** ERROR IN "test.scm"@13.13 -- Unbound variable: blah what happened? how did I just rebind + ? I thought it would only affect foo#+ furthermore, it also seems to have effect on varaibles like "angle" Thanks!

2 1

blackhole fixes
by moochee＠gmx.net 26 Jul '09

26 Jul '09

Hello dear all, while trying to port Alex Shinn's fmt to blackhole (not finished yet) i faced some difficulties resulting in the attached patch. I am neither familiar with black hole nor with the subleties of gambit. I hope this is the right place for discussion. The Black-Hole page seems to be unreachable for several days now. let-optionals: the hunk addressing optionals changes ,,body ...'' in (let-optionals* arglst ((var default) ...) body ...) to be wrapped into a let-form instead of a begin-form. This is what fmt seems to expect as the body starts with define-expressions leading to a complaint of gambit about misplaced expressions. Of course i could modify the fmt code to solve the problem at hand. But as the code seems to be working on other schemes it might be what other schemers expect. At least i don't see any drawbacks from doing so. As the begin-expresion will be wrapped into an outer let-expression anyway this modification should be completely transparent besides the gain expressive freedom. srfi/13 string-index: The result of an argument sanity check was passed along instead of the checked argument itself. srfi/13 char-cased char-titlecase: These are quick hacks. I didn't find them defined anywhere. Not sure whether this actually led to an error or not. srfi/14 char-set?: Black hole seems not to deal correctly with define-record-type. Instead of fixing the cause, i decided to provide this quick hack for the apparent problem of not exporting ,,char-set?''. Bye Tara

1 0

Register now! for the Scheme Workshop
by John Clements 25 Jul '09

25 Jul '09

2009 Workshop on Scheme and Functional Programming Coordinated with the Symposium in Honor of Mitchell Wand August 22, 2009 Boston, Massachusetts, USA http://www.schemeworkshop.org/2009 CALL FOR PARTICIPATION To the delight of all and sundry, the 2009 Scheme and Functional Programming Workshop will be held on August 22nd at Northeastern University, and it is a signal honor for me to be able to invite YOU to the WORLD'S FOREMOST WORKSHOP on the marvelous Scheme language, and to present a program PACKED with contributions from familiar faces and new ones, certain to amaze, delight, and edify. Lend us your ears, and we will widen the space between them. - John Clements IMPORTANT DATES August 11, 2009 - Registration deadline August 22, 2009 - Workshop on Scheme and Functional Programming August 23-24, 2009 - Symposium in Honor of Mitchell Wand: http://www.ccs.neu.edu/events/wand-symposium VENUE Northeastern University Boston Massachusetts Building and Room TBA ACCOMMODATION A limited block of hotel rooms has been reserved for participants of the Scheme Workshop and/or the Mitchell Wand Symposium at hotels in Cambridge and Boston. See the workshop web site for more information, and please note that some of these special rates expire soon (one as early as July 27th). REGISTRATION The registration fee will be $40 to help cover the operating costs and lunch accommodations. Please register by *August 11, 2009* so that we will have an accurate head count. To register, please send an email to aoeuswreg(a)brinckerhoff.org with your name and any dietary restrictions for lunch. PROGRAM COMMITTEE * John Clements (Cal Poly State University (organizer & chair)) * Dominique Boucher (Nu Echo) * Abdulaziz Ghuloum (Indiana University) * David Herman (Northeastern University) * Shriram Krishnamurthi (Brown University) * Matthew Might (University of Utah) * David Van Horn (Northeastern University) PRELIMINARY PROGRAM Invited Talk on the Bootstrap Program Emmanuel Schanzer Invited Talk on Future Directions for the Scheme Language The Newly Elected Scheme Language Steering Committee The Scribble Reader: An Alternative to S-expressions for Textual Content Eli Barzilay World With Web: A compiler from world applications to JavaScript Remzi Emre Başar, Caner Derici, Çağdaş Şenol Scalable Garbage Collection with Guaranteed MMU William D Clinger, Felix S. Klock II Distributed Software Transactional Memory Anthony Cowley Sequence Traces for Object-Oriented Executions Carl Eastlund, Matthias Felleisen Keyword and Optional Arguments in PLT Scheme Matthew Flatt, Eli Barzilay Fixing Letrec (reloaded) Abdulaziz Ghuloum, R. Kent Dybvig Descot: Distributed Code Repository Framework Aaron W. Hsu A pattern-matcher for miniKanren -or- How to get into trouble with CPS macros Andrew W. Keep, Michael D. Adams, Lindsey Kuper, William E. Byrd, Daniel P. Friedman Randomized Testing in PLT Redex Casey Klein, Robert Bruce Findler Screen-Replay: A Session Recording and Analysis Tool for DrScheme Mehmet Fatih Köksal, Remzi Emre Başar, Suzan Üsküdarlı Interprocedural Dependence Analysis of Higher-Order Programs via Stack Reachability Matthew Might, Tarun Prabhu Get stuffed: Tightly packed abstract protocols in Scheme John Moore Higher-Order Aspects in Order Eric Tanter Peter J Landin (1930-2009) Olivier Danvy

1 0

explicit pp
by Stéphane Le Cornec 25 Jul '09

25 Jul '09

Is there a way to explicitly pretty-print? Something like: > (display '(a XXX b c)) (a b c) > i.e. XXX outputs as some (newline) + spaces.

2 6

remote debugger improvement
by James Long 24 Jul '09

24 Jul '09

Hey Marc (and other relevant readers), I found a bug with the remote debugger. At the end of a session with a client (the running program), when the client exits and disconnects from the remote debugger, the server halts with a "deadlock detection." This seems to always happen with any program, so I wonder if others are experiencing this. I think I figured out what's going on, and I'm offering a fix. If anyone has any opinions, let me know. The relevant changes affect how the server reads incoming connections. Before, it would create a server using OPEN-TCP-SERVER, wait for an initial connection, and establish the connection and then use THREAD-JOIN! from the primordial thread (thread A) to the writer thread (thread B) to wait for everything to finish. It seems like the design was to only have the server handle one client and then quit. The problem with this is that thread B wasn't terminated properly, and it sits there waiting for messages using THREAD-RECEIVE, while thread A is waiting for it to finish. Essentially, when the network connections quit and those threads die, you are left with thread A and B in a deadlocked situation. (That probably only makes sense to those who have studied Marc's remote debugger, which might only be Marc.) There are 2 solutions: 1. On the server, kill the writer thread at the appropriate time. This is probably when it receives the message that the reader thread has died, meaning that the client connection was lost. The server would simply exit. 2. Change the server so that it loops and continually accepts new client connections. It would only exit with a ^C. I think #2 is better server design. It seems like it should stay open, continually accepting new connections. This makes it very usable as simply a background process. Here are my changes to implement #2. You simple need to replace RDI-OPEN-SERVER with this one: (define (rdi-open-server rdi) (let ((listen-port (open-tcp-server (list port-number: (rdi-port-num rdi) reuse-address: #t)))) (let loop () (let ((connection (read listen-port))) (let ((request (read connection))) (if (not (equal? request rdi-version1)) (error "unexpected debuggee version") (begin (write rdi-version2 connection) (force-output connection) (let ((reader-thread (rdi-create-reader-thread rdi connection))) (rdi-connection-set! rdi connection) (thread-start! reader-thread) (loop))))))))) Now, the main thread doesn't to use THREAD-JOIN!, but it simply loops forever. So, the call (rdi-force-connection rdi) in debugger.scm never returns, but starts the loop. I've attached my current version of the remote debugger. It also features a different server interface; you pass in the host/port when running (gsi -:dar,h10000 debugger.scm 20000). - James

1 0