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

build failure after latest make update
by Bradley Lucier 05 Oct '08

05 Oct '08

gcc -mcpu=7450 -I../include -I. -no-cpp-precomp -Wall -W -Wno-unused - O1 -fno-math-errno -fschedule-insns2 -fno-trapping-math -fno-strict- aliasing -fwrapv -fomit-frame-pointer -fPIC -fno-common - DHAVE_CONFIG_H -D___PRIMAL -D___LIBRARY -D___GAMBCDIR="\"/usr/local/ Gambit-C/v4.2.9\"" -D___SYS_TYPE_CPU="\"powerpc\"" - D___SYS_TYPE_VENDOR="\"apple\"" -D___SYS_TYPE_OS="\"darwin8.11.0\"" - c _kernel.c gcc: unrecognized option '-no-cpp-precomp' _kernel.c:13957:52: error: invalid digit "9" in octal constant

2 1

Re: [gambit-list] Strategies on decreasing executable size for Gambit-based software for client distribution
by Marc Feeley 04 Oct '08

04 Oct '08

Sure that could be done. But then it would change the semantics of your language, in the sense that (eval '(map sqrt '(1 4 9))) would only "work" if somewhere else in your program you use "map" and "sqrt" *and* the compiler did not inline them (which Gambit currently does). The semantics of eval would be implementation dependent. Frankly I would find it very hard to use eval reliably. Marc On 4-Oct-08, at 5:39 AM, Mikael More wrote: > Does really the ability of introspection bring with it that all code > is referenced to? Can't introspection work like that all routines > can be introspected, that are linked in in any case? > > Mikael >

2 1

Strategies on decreasing executable size for Gambit-based software for client distribution
by Mikael More 04 Oct '08

04 Oct '08

Hi! Compiling (display "Hello world\n") to an individual executable file generates a ~3MB executable. What are the strategies available to get Gambit application binary sizes down as much as possible, for applications to be distributed to client machines, with a particular designated purpose? Can parts of the Gambit core somehow be taken away, such as (eval) support, flonum support, arithmetical functions? Is there any strategy using which one can compile Scheme code to binary form, in a way that only the functions used in the code is included in the binary? I.e. smaller binary for (display "Hello world\n") than for an application that uses cos, eval, open-tcp-client. Thanks Mikael

5 6

Re: [gambit-list] Strategies on decreasing executable size for Gambit-based software for client distribution
by Marc Feeley 04 Oct '08

04 Oct '08

Eval introduces an interesting problem because it allows introspection, e.g. (define (foo x) (* x x)) ;; foo is not called directly by the program (pretty-print ((eval 'foo) 10)) ;; should print 100 So if the code can call eval, then anything accessible from the toplevel must be retained in the executable. If after tree-shaking the code contains a call to eval, then nothing can be thrown away. That's the price to pay for an introspective system. Note that many things might call eval, such as the REPL, or the exception handling system and even "read", so in practice it may be hard to remove much code. One "solution" is to add some switches to the compiler to ask it to not support the REPL, and to exit abruptly when an exception is raised. Marc On 3-Oct-08, at 5:38 PM, Mikael More wrote: > In case you would implement this, how would eval work? > > Mikael >

1 0

Mikel Evins about the Lisp-based Newton OS.
by Bradley Lucier 02 Oct '08

02 Oct '08

I saw this on Reddit programming; some interesting parts are > As a matter of fact, my favorite programming language of all time > is not Common Lisp, but the S-expression-based Dylan (later Dylan > versions don't excite me). High on the list of things I would like > to see is a new implementation of something very close to that > language, with several things designed to bring it forward to > today, notably libraries supporting POSIX, multithreaded > programming, Internet protocols and data formats, and good XML > support. DUIM would be nice, too. and > Q: [How do you compare] Dylan vs. Guile (a Scheme). > > Mikel: Things the old Dylan had that I would miss in Guile: > > * absolutely everything is an object in the sense of its object > system > * native code compiler > * iteration protocol (and the generally well-thought-out > collection classes) > * comparison protocol > * a single convenient form for binding single or multiple values > * singletons (yes, I know it's possible to implement them using > the MOP) > * functional features like curry, rcurry, compose, complement, > disjoin, and so on > * sealing > * the condition system > * the module system (I prefer it to that of Guile) > * grew fond of several Dylan conventions that differ from > Scheme (e.g. the use of "bind" in place of "let") > > On the other hand, Guile does provide some things I would misss if > I had to go back to the old Dylan, notably threads and SRFI > support. As I've said above, I'd also like to see a modern Dylan > support POSIX and XML and Internet standard protocols and data > formats. http://lispm.dyndns.org/news?ID=NEWS-2004-08-14-1

1 0

Profiler or coverage tool?
by Bradley Lucier 02 Oct '08

02 Oct '08

In January 2005, Guillaume Germaine announced his statistical profiler for Gambit, available here: http://www.iro.umontreal.ca/~germaing/statprof.html I've looked at some reports from a run with a recent gambit, and it doesn't seem to give me a reasonable results (or maybe I'm not using it right). After requesting help from Marc for a test-coverage tool, he sent me the program at the end of the file, which just dumps line locations of statements in the file to stderr, so it isn't all that helpful as is (but it shows how to hook it into the interpreter). I'm really looking for a code coverage tool; does anyone have one, or plan to write one? Brad From Marc: ;= = = = = = ======================================================================== ; File: "coverage.scm", Time-stamp: <2005-04-27 12:12:52 feeley> ; Copyright (C) 2005 by Marc Feeley, All Rights Reserved. ;= = = = = = ======================================================================== ; This is a simple test coverage system for Gambit 4.0 that uses the ; interpreter's single stepping infrastructure. The test coverage can ; only be done on interpreted code. However, the test coverage system ; (this file) can either be compiled or not, but if it is not compiled ; the program's execution will be much slower. When the test coverage ; system is compiled the program's execution is roughly 4 times slower ; than normal. When the test coverage system is interpreted the ; program's execution is roughly 20 times slower than normal. ; ; Here's a sample use: ; ; % gsi coverage.scm - ; > (coverage-on) ; > (if #f (+ 1 2 3) 4) ; (console)(a)2.5 ; (console)(a)2.18 ; 4 ; > (coverage-off) ; (console)(a)3.2 ; (console)(a)3.1 ; > (if #f (+ 1 2 3) 4) ; 4 ;= = = = = = ======================================================================== (define-macro (coverage-system-setup) (define coverage-system-code '(let () (define (step-handler leapable? $code rte execute-body . other) (hit (##code-locat $code)) (##apply execute-body (##cons $code (##cons rte other)))) (define (hit locat) (if locat (begin ; the statistics could be tallied and displayed in a ; more user-friendly way than just dumping them to stderr (##display-locat locat #t ##stderr-port) (##newline ##stderr-port)))) (let ((new-stepper (##vector (##vector step-handler step-handler step-handler step-handler step-handler step-handler step-handler) #f #f #f #f #f #f #f))) (set! ##main-stepper new-stepper)))) `(if (##interp-procedure? (lambda () 0)) ; compiled or interpreted? (begin (set! ##main-stepper (##no-stepper)) ; don't step coverage system! (##eval ',coverage-system-code)) (begin ,coverage-system-code))) (define (coverage-on) (##step-on)) (define (coverage-off) (##step-off)) (coverage-system-setup) ;= = = = = = ========================================================================

2 1

Gambit installer
by Adrien Pierard 01 Oct '08

01 Oct '08

Hi everyone. With the new version of Gambit, I decided to take some time to fix the installer and chose to install gambit in $prefix/bin/{gsi-$version,gsc-$version} $prefix/lib/gambit-c/$version $prefix/doc/gambit-c/$version $prefix/share/gambit-c/$version $prefix/info/gambit-c/$version $prefix/include/gambit-c/$version (the hardcoded "gambit-c" couls also be a variable, for those who run only one version of gambit and want to install directly into the $prefix subtree.) This should hopefully allow those who want to run several versions of gambit at once to do so (which explains the current behaviour of the installer), and also avoid clashes with names already taken by other binaires (such as ghostscript). Yet, there's two issues for which I need your advice: - Where should I put syntax-case.scm? - What happens to the shortcut "~~" in file paths? ideally, "~~" should be expanded by the binaries into the corresponding path (such as $prefix/lib/gambit-c/$version) where everything needed is found, and where I plan to put syntax-case.scm The aim of this "fix" is to make gambit fully portable and configurable on as many OSs as possible. So ? Adrian -- "I am not a Church numeral; I am a free variable!" (The Scheme Underground) For every complex problem, there is a solution that is simple, neat, and wrong.

4 13

Re: [gambit-list] Gambit installer
by Robert D. Skeels 01 Oct '08

01 Oct '08

I would like to see an option at configure stage to remove the version from the path, in order to honor the --prefix= path I set before compile. It is tiresome to edit PATH variables in .cshrc every time Gambit's version changes. Note I am requesting this as something we would explicitly pass at configure, the default would remain as is. I understand the logic and reasoning for current pathnames. However, it would be nice for those of us used to conventional bsd filesystem layouts to have Gambit install in expected directories. I'm no expert in makefiles, but it shouldn't be more than a conditional statement to include PACKAGE_SUBDIR or not, no?

3 2

A proper way to allocate memory in C extensions
by Frederick LeMaster 01 Oct '08

01 Oct '08

Is there a proper way to allocate memory for c extensions that will be compiled under both C and C++ versions of gambit? In the Xlib example this is used: (define (make-XColor-box) ((c-lambda () XColor* "___result_voidstar = ___EXT(___alloc_mem) (sizeof (XColor));"))) Should I do that for foreign objects/structs? What is the proper macro to free memory allocated this way?

1 0

New define-type wiki page
by David St-Hilaire 30 Sep '08

30 Sep '08

Hi all, I just wanted to let you know that I added a page on the wiki that is a translation of some of Marc's slides which indicate how to use the define-type special form, and most importantly lists all the options available (with some exemple code). link: http://dynamo.iro.umontreal.ca/~gambit/wiki/index.php/Define-type I think it could be usefull since I don't believe this information appears in the official doc. David

2 1