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

Efficient Compilation of Tail Calls and Continuations to JavaScript
by Marc Feeley 18 Sep '13

18 Sep '13

Eric Thivierge is in Copenhagen today, at the Scheme Workshop, presenting our latest paper: "Efficient Compilation of Tail Calls and Continuations to JavaScript" You can get the paper on the Scheme Worshop web page: http://users-cs.au.dk/danvy/sfp12/programme-sfp12.html It describes the implementation of tail calls and continuations in Gambit-JS and evaluates its performance. Even if you are not specifically interested in the JavaScript back-end the paper may be interesting to read as it provides a brief explanation of the Gambit Virtual Machine (GVM) and compiler front-end, and a complete example of compilation from Scheme, to GVM, to JavaScript. The performance evaluation (see attached tables) shows that the approach used by Gambit-JS is consistently faster than Scheme2JS and Spock. Marc Execution times using V8 (Chrome 21.0.1180.89): Gambit-JS Scheme2JS Spock fib35 .80 1.54 1.9x 2.40 3.0x nqueens12 .72 .76 1.1x 2.33 3.3x oddeven .83 1.92 2.3x 5.62 6.8x ctak .18 17.64 95.9x .59 3.2x contfib30 1.17 106.01 90.9x 3.38 2.9x btsearch2000 1.35 25.40 18.8x 7.93 5.9x threads10 1.34 24.68 18.5x 4.40 3.3x Execution times using JagerMonkey (Firefox 15.0.1): Gambit-JS Scheme2JS Spock fib35 1.07 7.66 7.2x 20.73 19.4x nqueens12 1.49 2.62 1.8x 12.97 8.7x oddeven 1.09 1.93 1.8x 33.91 31.1x ctak 1.25 30.38 24.3x 1.86 1.5x contfib30 5.88 156.79 26.7x 10.61 1.8x btsearch2000 11.19 27.16 2.4x 16.54 1.5x threads10 6.97 34.36 4.9x 22.11 3.2x Execution times using Nitro (Safari 6.0): Gambit-JS Scheme2JS Spock fib35 1.32 6.53 4.9x 84.69 64.2x nqueens12 1.31 1.89 1.4x 45.15 34.4x oddeven 2.52 1.55 .6x 143.97 57.1x ctak .30 52.88 177.4x 4.18 14.0x contfib30 1.60 2311.69 1443.0x 25.98 16.2x btsearch2000 3.46 102.98 29.7x 92.02 26.6x threads10 3.03 74.21 24.5x 74.88 24.7x

4 10

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

Macros, separate files, and all that
by Bradley Lucier 01 Fév '13

01 Fév '13

Marc: Assume that there's a file called "streams.scm" that has Phil Bewig's streams code in it, and that there's a file called "sieve.scm" that uses the definitions in streams.scm Now, when I do [Media-Mac-mini-3:~/Downloads] lucier% gsi -:s Gambit v4.6.6 > (load "streams.scm") "/Users/lucier/Downloads/streams.scm" > (load "sieve.scm") "/Users/lucier/Downloads/sieve.scm" > (stream->list 10 primes) (2 3 5 7 11 13 17 19 23 29) everything works fine. But if I compile the streams code and do [Media-Mac-mini-3:~/Downloads] lucier% gsi -:s Gambit v4.6.6 > (load "streams") "/Users/lucier/Downloads/streams.o3" > (load "sieve.scm") *** ERROR IN #<procedure #2>, "sieve.scm"@5.6 -- Unbound variable: define-stream then, as you can see, a macro from streams.o3 is not available for use in expanding sieve.scm. So, I guess I don't understand the "persistence" or whatever you would call it of R5RS macros, and how that interacts with Gambit's compilation model. Can you help? Brad

3 6

How do I create a pipeline of processes, as in shell?
by Jussi Piitulainen 29 Jan '13

29 Jan '13

In shell it is easy to run a program, and it is easy to chain programs into a pipeline where each process writes to the following process. In Gambit-C it appears to be easy to run a program and write to the process and read from the process. I failed to find a way to specify that the output of one process should be connected to the input of another. I have found open-process, process-status. I have found some discussions about running single processes. How does one implement the following lines in Gambit-C? $ sort infile | uniq -c | sort -nr $ sort < infile | uniq -c | sort -nr > outfile Is this non-trivial? I'm looking for something like the following, so that those processes would wait for their input and proceed when it becomes available. (let ((p (pipe '(path: "sort" arguments: ("infile")) '(path: "uniq" arguments: ("-c")) '(path: "sort" arguments: ("-nr"))))) (let* ((r1 (read-line p)) ...) ...)) (parameterize ((current-input-port (open-input-file "infile")) (current-output-port (open-output-file "outfile"))) (process-status (pipe "sort" '(path: "uniq" arguments: ("-c")) ...))) I'm _not_ looking for (string-append ...).

3 6

A rudimentary pipeline implementation with bridging threads
by Jussi Piitulainen 28 Jan '13

28 Jan '13

Assuming my previous question came through, I asked about implementing pipelines of processes in Gambit-C. The problem was that I could not seem to make the output of one process to connect to the input of the next on their own. I'm now experimenting with Gambit-C threads to bridge those gaps. Here is a rudimentary implementation of what I want. The comments indicate things that I think I know I still need to do. I haven't used threads much before, and never in Scheme. The original question stands: am I overlooking some obvious way to do such pipelines that Gambit-C already has? Because this is the easy 80% of the work and another 80% sheer tedium probably remains :) (define (echo from to) ;should use a buffer (do ((line (read-line from) (read-line from))) ((eof-object? line)) (display line to) (newline to))) (define (piece from to) (lambda () (echo from to) ;should allocate a private buffer for echo (close-output-port to) ;stopped using it as output port (process-status from))) ;wait for it - maybe time it out? (define (end from) ;not closing current output port (lambda () (echo from (current-output-port)) (process-status from))) ;actually, the end should be controlled by the called altogether! or ;is it now? ;caller needs to close the first pipe segment as output port, and do I ;need to force some output or close input ports? and errors should be ;handled, including diagnostic output from the processes and failed ;status of any, and not leave processes around on any sort of error if ;possible. oh and do all those threads terminate nicely and always? (define (pipe first . rest) (let ((first (open-process first))) (do ((last first (car rest)) (rest (map open-process rest) (cdr rest))) ((null? rest) (thread-start! (make-thread (end last))) ;;^altogether mistaken - leave it to the caller (values first last)) (thread-start! (make-thread (piece last (car rest))))))) (define (test) ;has hardwired end to echo the output in current output (call-with-values ;^fix it so the called handles reading and waiting (lambda () (pipe "date" '(path: "tr" arguments: ("0-9" "D")))) (lambda (first last) (close-output-port first))))

2 3

Request: examples of cool uses of macros
by Jason Felice 28 Jan '13

28 Jan '13

Hi! Does anyone have any examples of macros which drastically improve readability or simplicity of code? Maybe neat hacks? Not *deep* hacks that take a long time to understand, but things which can be used to illustrate why macros are powerful and awesome. Background: I'm giving a talk tomorrow on Scheme to prisoners in a job training program. The purpose is to expand their brains by exposing them to concepts they haven't seen before (they don't have Internet access). The talk is about Scheme and "Code is Data". I've laid the foundation, but am getting to the point where I want to have some flashy and interesting uses of macros. Any help would be appreciated. Thanks, -Jason

5 4

Re: [gambit-list] BH
by Mikael More 26 Jan '13

26 Jan '13

Hi Alvaro, (Two Q:s for you at the bottom.) 2013/1/25 Álvaro Castro-Castilla <alvaro.castro.castilla(a)gmail.com> > Hi! > > I write about the 2 latest emails here: > > * Separate module-systems compilation: > That's it. I think that is the best solution. I already did a proof of > concept in the past for scheme spheres and it works well: some modules > are expanded with one expander and some with other. The result is > taken by Gambit seamlessly. > In my experience, people don't mix define-macros and syntax-rules. For > those cases where you *NEED* define-macros (like processing names of > identifiers) a second pass could be offered, but is another story. > One simple expander per module is a modular and simple solution I'm > totally in for. > Yeah. By this do you mean that you think the idea I proposed in the email ~17hrs ago is a good direction for the development? > * Lightweight-portable implementation of BH: > You can see some of the techniques I talk about here: > https://www.youtube.com/watch?v=Q7c0rU9Lv28 > > The point is that if you have an implementation that is lightweight > and pluggable enough, you can use it for remote REPLs of any kind > (mobile debugging, web servers, hot code swapping in webservers -which > can be done with termite-), like the example of the video. > > Why I so much like Alexpander is because it does exactly that: it is > less than 1KLOC and works with any scheme system. The only issue with > being portable is that you don't have that nice error reporting, > apparently (and that you don't use the non-portable facilities that > could make it faster and more compact). But BH doesn't need to be > portable across scheme implementations so this is our chance to make a > BH with these features. > > This is why I insist so much on the separation of concerns and the > lightest possible BH. > I've been thinking about possible ways of making BH just a text > processor (like Alexpander currently is), and I believe is possible. > The only issue is that probably you need to output more than one file. > Simply knowing which symbols to prepend with which namespace prefix, > you already have a simple module system that can have the same > encapsulation properties than BH, if you mix that with macro expansion > then you have all you need. > > The only thing I'm trying to figure out is how to make this #namespace > be prepended to macros names, as they need to be part of the module > system as well, but that could be handled by the macro expander (which > goes hand in hand with this module system). > > Really, what I have now working at Scheme Spheres and works pretty > well (waaaaay faster macro expansion than BH) gives me this: > - full expansion of syntax-rules in a first pass > - expansion of define-macro's in a second pass > - module system in the Gambit style > - fully embeddable in any system that I want to not just eval scheme > code, but process its macros > > What does it need to achieve all we need from Blackhole and be > superior due to the portability and embeddability? > - module system that incorporates the macros > - better error reporting for macros > > In summary, a solution like I'm proposing would have the following > features: > > - embedabbility: could be embedded in a web browser (with a javascript > backend), in a web server for hot code swapping and testing, live > coding (see http://toplap.org/ for some examples of this world, and > let me tell you that one of the most interesting apps for live coding > is currently running on Racket), remote debugging and coding of > Android devices. And many others options that this would open the > doors to. > - composability: a separation of concerns would make it easy for > people to make small apps that glue together a workflow, very much in > the Unix style. Also, this would be more welcoming for people to > contribute to new "utilities". For instance, we now should worry just > about the essential utilities (macros, modules and maybe packages), > but all the niceties that we find in other ecosystems can be built on > top of these 3 (and I'm talking about gem/sids, bundler/sbundle, > testing, literate programming, automatization). And these utilities > could be used by people who don't want to use BH at all! > - control: simplicity and respecting the "Gambit ways" (like just > producing a Scheme output and delegate to Gambit), will allow for > *full* control of how you want your code to live. > I mean, with BH we > lost control of things like dynamically loading object files by need, > What was this about, can you describe the use case and problem? > or just compiling everything in one C file for MAX performance > (avoiding trampolines). > I believe BH has a feature for this, it's something like that it can take all the modules at least in the same dir and make only one module file out of them. Well, that is my proposal, and I believe it is actually much simpler > than original Blackhole and would solve more problems. > Yes, it looks like it will be something like this. Best regards, > > Álvaro > So basically the Scheme environment-specific code (like production of ##namespace codes, inserting code into the Scheme environment, doing compile-file) should be split apart from as much of the module system 'core' as possible. Maybe, I'll start drafting some kind of API for all this stuff soon. * Would be happy if you could give spontaneous feedback on the API draft I sent you yesterday, for interface between package management/module loader and module system. I'm not clear on what kind of requirements that a live coding environment or alike could have. Really, this BH now will be made primarily for Gambit, and support for generation toward other systems will be a bit like a bonus. I believe something like a-set-of-modules => a Scheme code image suitable for feeding Scheme2JS with, is completely realistic. * Alvaro: When do you believe your document on use and advanced use of syntax-rules will be ready? I'm a but curious on how line number info should be managed through this expansion process. I know Gambit has an internal format for it already, hopefully we can just hook onto that. All the macro expanders will need to traverse the input Scheme structure atop a DSL that deals with this format. Really, if the DSL:s involved are just well documented, and all the involved modules can be loaded as ordinary BH modules for anyone who wants to use them, then I believe we've got a high degree of plugability and reusability and dynamicity in all kinds of directions already there. So, BH was monolithic in these respects, perhaps it could have been designed like this but it was not. Hopefully by just doing this we get all those godo qualities. Brgds, Mikael

1 0

Demo code for mobile apps in Gambit Scheme?
by Andrew Pennebaker 25 Jan '13

25 Jan '13

I see that Gambit apps can be written for iOS. What about Android and Windows RT? Any demo code we can use as a reference? -- Cheers, Andrew Pennebaker www.yellosoft.us

3 3

Black Hole and C source
by Jason Felice 23 Jan '13

23 Jan '13

Is there a way to get the generated C (or assembly) from bh? I can't find one. Thanks! -Jason

4 10

Several questions about gambit
by Chris Müller 23 Jan '13

23 Jan '13

Hey :) I've currently started to learn/use scheme for some experiments in machine learning and chose gambit for its close relation to c. I would like to share my first impression and misunderstandings with you and have some questions which maybe also help other newcomers. 1) I managed to compile my scheme library into a dynamic loadable unit that i use in some scripts for the gsi interpreter. Does anyone know how i can specify some kind of loadpath (e.g. via ENV, commandline flag) for the interpreter where (load "...") searches scheme modules? (Or any other common alternatives) Currently i'm always using relative paths through (string-append (path-directory (this-source-file)) "/" "module") based on the file location itself. 2) I've struggled in the beginning very much with the usage of gsc and gsi. My first step is often calling the --help flag of the command itself. Unfortanetely, i haven't found any useful option like "gsc --help" or "gsi --help" that provides a short summary about its common command flags. The man page and the -:h flag provides some information about runtime configuration. But it seems a little incomplete. (Especially for compiling scheme files to .o1). It would be a great help to extend this summary with the mentioned options from the documentation in "/usr/share/gambc" or "info gambit-c". (If i missed something interesting, just let me know) 3) For my own purpose i'm currently implementing a trivial testing library similar to rspec and would like to share this. The wiki mentioned two package systems (Black Hole and Snow). I like to ask if there exists some preferences using a specific system and which one do you suggest (or is there even one of them deprecated?) 4) Do you know a good scheme alternative for the printf command in c? I've currently only used (print ..) and (display ..) which worked, but i would also prefer some formated outputs for the future :) 5) I have currently no clue about gambit overall capabilities. But i guess it already belongs to the most matured scheme implementation due to its older age. I'm especially interested in its foreign interface to C and it would be interesting to know if its possible to bind bigger libraries like Glib/GTK/Cairo flawlessly. (Or does there exists some known limitations that could lead to obvious problems). Hope you nevermind this trivial questions that helps me a little in gambits scheme landscape. Chris

4 7