Gambit-list Février 2009

gambit-list@iro.umontreal.ca

37 participants
66 discussions

way interpreted code is stored / unraveling trace
by lowly coder 23 Fév '09

23 Fév '09

Join me for episode 201 of "gambit detective stories", today, we're going to try to solve the case of "how the f*ck does trace insert hooks" So looking at lib/_repl.scm , we see in ##trace that we have: (##interp-procedure-entry-hook-set! proc new-hook) which looks something like: (define-prim (##interp-procedure-entry-hook-set! proc hook) (let (($code (##interp-procedure-code proc))) (macro-code-set! $code (##fixnum.- (macro-code-length $code) 2) hook))) this "2" here looks like a magic constant, let's ignore it for now; looking for macro-code-set! in lib/_eval#.scm , we see: (##define-macro (macro-code-set! c n x) `(##vector-set! ,c (##fixnum.+ ,n 5) ,x)) now, this 5 here is anothe rmagical constant -- but this looks interesting; for the interpreter, does gambit basically store the procedure in a vector ... and for inserting traces, we just _DYNAMICALLY REWRITE THE CODE_ to insert stuff before & after? If so, this is really really cool. Any insights / clarifications / tips / deatils appreciated. Thanks!

3 3

limiting trace
by lowly coder 21 Fév '09

21 Fév '09

Code: ~/code/irc$ cat trace.scm (define (foo x) x) (define (bar) (foo 0)) (define (test) (foo 1) (bar)) (trace foo) (test) ~/code/irc$ gsi trace.scm | > (foo 1) | 1 | > (foo 0) | 0 Problem: Can I control trace where I can say "trace foo, but not when it's called by bar". I.e. rather than just saying "trace this function", I would like to be able to say: (trace foo predicate) where predicate is a function that takes as input the "stack" frame, and as output creates a #t / #f, which decides whether this particular trace should be printed On a side note -- all the cool debugging functions in Gambit -- is this part of the 100K LOC scheme or 50K LOC hand written C? (hoping it's the former)

2 5

Gambit Git on Windows
by Guillaume Cartier 19 Fév '09

19 Fév '09

I just installed and built the latest Gambit from sources on Windows and when I do git status I get the following entries ._relpath bin/gambc-doc.bat bin/gambc-doc.bat.unix bin/gambc-doc.bat.windows relpath These probably need to be added to the .gitignore? Guillaume Cartier

1 0

Speed improvement of lib/digest.scm
by Marc Feeley 19 Fév '09

19 Fév '09

The file lib/digest.scm, which computes digests (CRC32, MD5, SHA-1, etc), has been optimized. The new version is on the repository. Essentially it now does all computations with fixnums (the old version did many operations on bignums and the fixnum operations were not inlined). Digest computation of a 1MB file is over 100 times faster than the previous version! Marc

1 0

user-defined ports / input-port-byte-position on u8vector ports
by Darren Baker 19 Fév '09

19 Fév '09

Hi all, I've been implementing a virtual file system in Gambit; the idea is that I can open a file for input and it could be transparently sourced from a .zip file, or the local filesystem, http connection, etc., and a suitable newly-created port would be returned that the caller can do the usual character and byte I/O with. So for example if a request resolves to a local file, then open-input-port is used, if it's a compressed file, then a different port would be used that handles the decompression. Two issues: 1) In the case of reading from a .zip, Gambit obviously doesn't have a port for this, so it seemed to me that creating a new custom port type would be ideal. Is there an official / easy way to do this? (A simplified low-level user port type would be great, in the style used by many C libraries, ie user provides read-bytes, write-bytes, seek and tell functions.) 2) For now I've implemented .zip functionality by extracting the required file to a u8vector, then creating a u8vector-input-port on that, and returning it. Good idea... except that I find out the hard way that input-port-byte-position doesn't work on u8vector ports. This seems to indicate that I can't do random access binary I/O on them using the port functions...? I realise it's not a "device port" but it seems a logical thing to want to do in general. Btw, reading the list archives from 2006 there was a discussion on the behaviour of input-port-byte-position returning the *buffered* position not the read-u8 cursor position. FWIW, my vote is for the read-u8 position, the current behaviour totally caught me out and isn't particularly usable. :) Thanks, Darren

1 0

fast binary serialization
by lowly coder 19 Fév '09

19 Fév '09

hey, I have some non-recursive scheme data structures that I want to store/load between runs; I'm currently storing them with "pp" and loading them with "(read-all (open-input-file ...))" on my particular data source, with my macbook pro, i'm getting 7MB / seconds for parsing the s-exps back in; I'm wondering if there is a generic gambit way to store/load in binary, non-human readable format for something faster (btw, i'm NOT IO bound since for timing, I do the reading multiple times, so the file is probably already in RAM / some file cache) thanks!

4 6

Fwd: loc count
by Robby Findler 17 Fév '09

17 Fév '09

On Tue, Feb 17, 2009 at 7:50 PM, Marc Feeley <feeley(a)iro.umontreal.ca> wrote: > On my MacBook Pro, after a few iterations (to get the executables into > the disk cache), I get: > > % time gsi -f -e '(exit)' < /dev/null > > real 0m0.012s > user 0m0.005s > sys 0m0.006s > > % time mzscheme -I scheme/base -e '(exit)' < /dev/null > > real 0m0.057s > user 0m0.037s > sys 0m0.014s > > So mzscheme is still a factor of 5 slower to startup and exit, and > with Gambit you get all the REPL stuff included, which is really > important if you want to be able to debug your code comfortably if > something goes wrong (I would expect this to be an important point for > most users given that this is an advantage of using Scheme... indeed > the default in mzscheme is to include the REPL support). > > Anyway my point is simply that even though the Gambit runtime may seem > big, it still is lightweight to use. Hey Marc -- those are impressive numbers indeed! I think, tho, that maybe you overstate the case a little bit. You do seem to be beating mzscheme fair and square and, if counting the number of exports is the right thing to measure, scheme/base has a similar number to what you wrote earlier (it has 1193 exports if I did the computation right -- I'm sure Matthew can correct me if I've made a mistake). But when Eli said "all the REPL stuff", I think he just meant a larger library. The basic scheme library, for example, has 2847 exports, which is (I think) what you get when you pass no commandline options to mzscheme. Anyways, just a minor quibble and kudos on the speed with which gambit starts up! Robby

1 0

Re: [gambit-list] tab completion
by Guillaume Cartier 17 Fév '09

17 Fév '09

Hi Oisín, In case you didn't know, Jedi has tab completion for all cross-referenced code. Guillaume > Hi guys, > > Is there a way to get tab completion working at the REPL (and, > ideally, while editing scheme files) in Emacs, just as it works when > you run gsi directly at the command line? I'm not a very advanced > Emacs user, so I don't know if there's some blindingly obvious > solution. Using scheme-complete.el helps a little with standard Scheme > functions in Scheme source mode, but not functions provided by Gambit > like random, u8-... etc. > > thanks, > Oisín

1 0

Re: [gambit-list] loc count
by Marc Feeley 17 Fév '09

17 Fév '09

On 17-Feb-09, at 1:47 PM, lowly coder wrote: > Not impressed at all. In fact, why is Gambit so big? Why is there > 100K LOC for the *.scm s? There doesn't seem to be many built in > libraries. All for optimizing? Don't ask why but why not! ;-) There are on the order of 200 procedures and special forms defined by R5RS. Gambit adds another 800. So there are lots of builtin features. About 50 KLOC are in the runtime system and 50 KLOC in the compiler. I've written a few small Scheme's in my career... for example picobit is really small (it can fit in less than 10K on an embedded system) and BIT is just slightly bigger but it implements almost all of R4RS. So my question to you... why are you not using BIT? That would be the best choice if you are worried about size and R4RS conformance. I suspect there are features of Gambit that you like and that make your life as a programmer simpler so you prefer using it to other Scheme systems. Perhaps one of - feature-full debugger (single-stepping, backtrace, descriptive error messages, error pinpointing, live repair, etc) - space and time efficient scalable thread system (how many languages do you know can manage millions of threads?) - full-featured I/O system integrated into the thread system - ability to mix compiled and interpreted code seamlessly and to load compiled code dynamically - ability to interface easily with C code - one of the many extensions (homogeneous vectors, networking, subprocesses, hash tables, pretty printing, readtables, serialization, etc) - complete numerical library with fast bignum operations - etc (check the README file) All of these things contribute to the "user experience" that people appreciate when using Gambit. You aren't confronted with these things when you first start using Gambit (and that's the way it should be)... you only see the simple > prompt. But these features are ready to be used when you are ready to use them. It is true that these things take code space, so that the gsi executable (essentially the Gambit runtime system) takes about 3 MB, but that compares favourably to many other language implementations (on desktops) and it takes only 15 milliseconds (real time) to start and exit, so it is lightweight enough to use for everyday scripting (on my computer that's about 3 times slower than /bin/sh, but still twice as fast as Scheme48 (which also has a 3 MB footprint) and about 30 times faster than mzscheme). So Gambit is not as "bloated" as you might think! Marc

4 4

tab completion
by Oisín Mac Fhearaí 17 Fév '09

17 Fév '09

Hi guys, Is there a way to get tab completion working at the REPL (and, ideally, while editing scheme files) in Emacs, just as it works when you run gsi directly at the command line? I'm not a very advanced Emacs user, so I don't know if there's some blindingly obvious solution. Using scheme-complete.el helps a little with standard Scheme functions in Scheme source mode, but not functions provided by Gambit like random, u8-... etc. thanks, Oisín

1 0

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 2009