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

Eclipse-based Scheme Debugger
by William Cook 30 Sep '08

30 Sep '08

I've uploaded a first working version of my Scheme IDE based on Eclipse. Its called Schemeide http://schemeide.sourceforge.net/ Right now it mostly does auto-formatting and debugging. It works with Gambit 4.2.9 on MacOS, Win32, and Linux. It is still alpha quality, with many features still to do. But it seems to be usable, at least for easy stack inspection of problems. Function breakpoints still need to be entered manually. And the interaction between the output window and debug mode is not good. I'll be working on it since I'm using it daily in my Scheme work. If anyone wants to help, please let me know. Feedback is welcome. William Cook http://www.cs.utexas.edu/users/wcook

1 0

Bug with unsigned-long-long C type
by Arnaud Bergeron 30 Sep '08

30 Sep '08

Basically, the conversion macros for it and long-long are not defined. So you get errors like this: warning: implicit declaration of function '___BEGIN_CFUN_SCMOBJ_TO_ULONGLONG' And the code does not compile. Arnaud

1 0

[ANN] Gambit-C v4.2.9 released
by gambit＠iro.umontreal.ca 28 Sep '08

28 Sep '08

1 0

Help With Memory
by Joel J. Adamson <adamsonj＠email.unc.edu> 28 Sep '08

28 Sep '08

Dear Gambitizers, I have programmed a simulation, and the list has successfully helped me with a few prior problems. Those are taken care of, but now I have a much more basic problem: I'm using up memory, to the point where my kernel (named after a certain Finn) # uname -srmp Linux 2.6.26-custom i686 Intel(R) Core(TM)2 Quad CPU Q6700 @ 2.66GHz kills the program. Of course I had the common misconception that this would never happen in a Lisp-like language and on and on: my real concern is that there is some basic programming technique that I am missing. Basically, is something failing to get garbage-collected? I will discuss a specific problem below, but I ask the kind generosity of someone who could examine the code (or show me how to better examine it), and let me know if there are any major red-flags, or ways I could improve it. My basic goal is that since I really enjoy programming in Scheme, I'd like to avoid having to do this in FORTRAN on the big ol' supercomputer here. Yes, I am in school, but my adviser had never heard of Scheme before I mentioned it to her ;) To stop the memory allocation problem, I attempted to install an exception handler: (define (mem-handler exc) (if (or (heap-overflow-exception? exc) (stack-overflow-exception? exc)) (if (noncontinuable-exception? exc) (abort exc) exc) (with-exception-catcher error-handler (lambda () (raise exc))))) And then run the main driving routine within this like so: (with-exception-handler mem-handler (lambda () (gen-sim-data))) Here's what happens when I run it: chondestes: /home/joel/lisp/scm/agjones> nice -n +10 jonesim -:m1000000,dR- *** WARNING -- Variable "gsl-vector" used in module "genxic.o1" is undefined .9999107177669622 2000 50 16 2 1000. .5 0. 0. 0. 1e-4 1. .25 true .9999111243206196 2000 50 16 2 1000. .5 0. 0. 0. 1e-4 1. .25 false .9999110166041458 2000 50 16 2 1000. .5 0. 0. 0. 1e-4 1. .75 true .9999111775781226 2000 50 16 2 1000. .5 0. 0. 0. 1e-4 1. .75 false .9999108917731552 2000 50 16 2 1000. .5 0. 0. 0. .09 1. .25 true .9999104499002971 2000 50 16 2 1000. .5 0. 0. 0. .09 1. .25 false .9999107898981544 2000 50 16 2 1000. .5 0. 0. 0. .09 1. .75 true zsh: killed nice -n +10 jonesim -:m1000000,dR- Thanks for any help you can offer, Joel Getting the code ================ The code is available for public download from svn at http://chondestes.bio.unc.edu/svn/models/agjones A simple "make" in the top directory will yield a single executable that reads "input.txt." The critical parameter is "N," the first variable in "input.txt." I have tested this at 10, 100, and 2000, and it only finishes successfully at N=10. To run it you will need the loadable library "genxic.o1" from the package located at http://chondestes.bio.unc.edu/svn/genxic/trunk To build the library, do a "make" in the scm/ directory, then copy it to the top directory of agjones/. -- Joel J. Adamson University of North Carolina at Chapel Hill CB #3280, Coker Hall Chapel Hill, NC 27599-3280 Before you reply to this email, please read http://www.unc.edu/~adamsonj/email-howto.html

8 39

Expose C constants to Scheme
by Arnaud Bergeron 27 Sep '08

27 Sep '08

For the LLVM interface to Scheme I am working on I need to export some constants in C to Scheme. I was advised to proceed with the following construct: (define <scheme-name> ((c-lambda () int "__result = <c-name>;"))) Since it is boring to retype the same thing a lot of times I considered making a macro, but I am facing the problem that c-lambda wants a literal string as its third argument. I can make the string I need with string-append, but I have no idea how to build a literal string in a macro. Here is what I have right now: (define-macro (c-define-const name c-name) `(define ,name ((c-lambda () int (string-append "___result = " ,c-name ";"))))) If anybody has a better idea on how to do this or a way to fix my macro, I would appreciate. Arnaud

2 1

Small patch requested
by William Cook 24 Sep '08

24 Sep '08

I'm about ready to release an alpha version of my Eclipse-based Gambit IDE. TO get this working I had to make a small change to Gambit to enable another hook. If there is a better way to do this, using the existing binaries, I'd love to know it. Here's the patch to lib/_repl.scm: ============ 2145c2145 < (define-prim (##repl-within cont write-reason) --- > (define-prim (##repl-within-default cont write-reason) 2512a2513,2514 > (set! ##repl-within ##repl-within-default) > ================== I'm asking about this because I started building a version of GSI with this feature on mulitple platforms, and its proving to be a challenge. If I could get a standard build with this feature it would be great. It allows me to hook into ##repl-within any time an error or break happens So far the IDE has: *debugging - stack trace and source location - inspection of lists, tables, and *closure* - stepping (sort of) *syntax coloring *indenting and formatting *Other things like autocompletion, source outline are not done *I don't think I can do true breakpoints without more support, but I might be able to do some function-breaks. -- William Cook http://www.cs.utexas.edu/users/wcook

2 3

Re: [gambit-list] Gambit-list Digest, Vol 48, Issue 22
by Ken Dickey 24 Sep '08

24 Sep '08

On Monday 22 September 2008 18:06:25 Arthur Smyles wrote: ... > My original example > > (if (values #f #f) #t #f) > > doesn't work in scheme because values creates a special object that is > not false so to make it work properly, No. The example does not work as you expect because you are expecting a different language semantics than the Scheme standard specifies. > I have to do: > > (if (call-with-values > (lambda () (values #f #f)) > (lambda (primary . secondary) primary)) > #t > #f) > > But if I always have to do that in order to use my function, then I > might as well not use values/call-with-values and split the function into > 2. The root problems with what you suggest are [1] not all functions talk an arbitrary number of values and [2] making this change would really torque the semantics. You are asking for ((lambda (x) (* x x)) 2 3) -> 4 (if (vaues #f 2 3 4) 1 2) -> 1 The decision that the language designers made was for safety and for compiler optimization. The safety assumption is that an error message is more appropriate than ignoring "extra" values and filling in "missing" values. Perhaps it is best to think of calling a function. Do you want all functions to pay the cost of a "rest" list? I.e. you wish to require the following two functions to be equivalent? (define (double n) (* 2 n)) == (define (double n . rest) (* 2 n)) [Some languages are defined this way. I would claim that they pay a performance penalty, but that is another discussion.] > >> Unfortunately, the only way to use the current implementation of > >> 'values' properly is to de-structure it using call-with-values. In many/most common used cases a compiler can optimize this so that values are transmitted directly without the need of a procedure call or construction of a function. I.e. (call-with-values (values 2 3) cons) can be transformed to (cons 2 3) by the compiler and even constant folded to '(2 . 3) if the compiler can "prove" from context that the cons cell is never side effected and that CONS refers to the classical binding of the cons function. Whether or not this is done is a compiler optimization problem. [I have not looked, so don't know if Gambit currently performs this optimization. You should probably do so]. You are asking that this type of optimization never be done. I think it is a lot to ask. $0.02, -KenD

1 0

Re: [gambit-list] gambit + llvm
by Arnaud Bergeron 23 Sep '08

23 Sep '08

2008/9/22 David Rush <kumoyuki(a)gmail.com>: > On Mon, Sep 22, 2008 at 8:19 PM, Marc Feeley <feeley(a)iro.umontreal.ca> wrote: >> I haven't looked at LLVM since its first release, and following your >> post I took a new look > > As have I. I am glad of the reminder. > >> For fun I tried compiling Gambit with llvm-gcc on my Mac OS X machine > ... >> The good news is that this works > ... >> The bad news is that the compile time is really high (10 minutes for >> some of the larger C files like lib/_num.c and lib/_io.c) and the >> execution speed if often lower than when using the standard gcc. > > Well a custom back-end would be using Gambit's high-level > optimizations and LLVM's low-level ones. I wouldn't be at all > surprised if the use of C as an intermediate language (however > stylized) introduces inefficiencies. > >> If anyone is interested in contributing to implement an LLVM back-end >> for Gambit, please send me an email. I can guide you through the >> steps required. > > I am indirectly interested, and may become actively so depending on > what happens in the next couple of months (waiting on funding :) > Please keep the list posted if anyone steps up. Too late :) I will be doing this for the semester with somebody else as a project for our compilation course with Marc. Our original project was just to compile scheme to LLVM, but since this enquiry popped up we got a proposition to do this and we accepted. Arnaud > david rush > -- > GPG Public key at http://cyber-rush.org/drr/gpg-public-key.txt > _______________________________________________ > Gambit-list mailing list > Gambit-list(a)iro.umontreal.ca > https://webmail.iro.umontreal.ca/mailman/listinfo/gambit-list >

2 1

Symbol warning output made by (load) when making multiple (load):s in another thread than the primordial block the thread
by Mikael More 23 Sep '08

23 Sep '08

Hi! We have been having a strange annoyance - probably very simple to solve - for quite some while, and I wanted to address it here so that we and anyone running into it might get around it. What we do is to run a procedure that runs (load) multiple times in a sequence, where the (load):s are such that they output multiple warnings about unresolved symbols during the process. I'm well aware that unresolved symbols are not acceptable in final code, but, during development, there may be good reasons to prioritize other things than fixing symbol usage in code that's not used in the present moment anyhow. As you know, the general pattern for unresolved symbol warnings output by (load) is *** WARNING -- Variable "some-module-name#some-function-name" used in module "some-object-file.o1" is undefined The problem is that when we execute the procedure from another thread than the primordial, quite each of its warning output operations block (i.e. is blocked / freezes / waits), and gets output to the console first after that one makes an evaluation in the REPL. Making a thread-sleep! or evaluating zero is sufficient. After the evaluation, the procedure resumes until it outputs another line, and then another evaluation needs to be made to make it resume again, etc. How do we make (load) never block, undepending of in what thread it is executed? Example code below. Thanks Mikael - Set up test environment echo "(define (test) (unknown-symbol-a) (unknown-symbol-b) (unknown-symbol-c))" > a.scm echo "(define (test) (unknown-symbol-d) (unknown-symbol-e) (unknown-symbol-f))" > b.scm echo "(define (test) (unknown-symbol-g) (unknown-symbol-h) (unknown-symbol-i))" > c.scm gsc (compile-file "a.scm") (compile-file "b.scm") (compile-file "c.scm") ,q Expected behaviour, load:s don't block: gsc (load "a") (load "b") (load "c") ,q Output is: > (load "a") (load "b") (load "c") "/home/mikael/a" > *** WARNING -- Variable "unknown-symbol-d" used in module "b.o1" is undefined *** WARNING -- Variable "unknown-symbol-e" used in module "b.o1" is undefined *** WARNING -- Variable "unknown-symbol-f" used in module "b.o1" is undefined "/home/mikael/b.o1" > *** WARNING -- Variable "unknown-symbol-g" used in module "c.o1" is undefined *** WARNING -- Variable "unknown-symbol-h" used in module "c.o1" is undefined *** WARNING -- Variable "unknown-symbol-i" used in module "c.o1" is undefined "/home/mikael/c.o1" Unexpected behaviour, load:s block: gsc (thread-start! (make-thread (lambda () (load "a") (load "b") (load "c")))) Output is: #<thread #2> > (thread-sleep! 5) ------------- REPL is now in #<thread #2> ------------- *** WARNING -- Variable "unknown-symbol-d" used in module "b.o1" is undefined *** WARNING -- Variable "unknown-symbol-e" used in module "b.o1" is undefined *** WARNING -- Variable "unknown-symbol-f" used in module "b.o1" is undefined *** WARNING -- Variable "unknown-symbol-g" used in module "c.o1" is undefined *** WARNING -- Variable "unknown-symbol-h" used in module "c.o1" is undefined *** WARNING -- Variable "unknown-symbol-i" used in module "c.o1" is undefined ------------- REPL is now in #<thread #1 primordial> ------------- > Alternatively: #<thread #2> > 0 0 ------------- REPL is now in #<thread #2> ------------- *** WARNING -- Variable "unknown-symbol-a" used in module "a.o1" is undefined ------------- REPL is now in #<thread #1 primordial> ------------- > 0 0 ------------- REPL is now in #<thread #2> ------------- *** WARNING -- Variable "unknown-symbol-b" used in module "a.o1" is undefined ------------- REPL is now in #<thread #1 primordial> ------------- > 0 0 ------------- REPL is now in #<thread #2> ------------- *** WARNING -- Variable "unknown-symbol-c" used in module "a.o1" is undefined ------------- REPL is now in #<thread #1 primordial> ------------- > 0 0 ------------- REPL is now in #<thread #2> ------------- *** WARNING -- Variable "unknown-symbol-d" used in module "b.o1" is undefined ------------- REPL is now in #<thread #1 primordial> ------------- > 0 0 ------------- REPL is now in #<thread #2> ------------- *** WARNING -- Variable "unknown-symbol-e" used in module "b.o1" is undefined ------------- REPL is now in #<thread #1 primordial> ------------- > 0 0 ------------- REPL is now in #<thread #2> ------------- *** WARNING -- Variable "unknown-symbol-f" used in module "b.o1" is undefined ------------- REPL is now in #<thread #1 primordial> ------------- > 0 0 ------------- REPL is now in #<thread #2> ------------- *** WARNING -- Variable "unknown-symbol-g" used in module "c.o1" is undefined ------------- REPL is now in #<thread #1 primordial> ------------- > 0 0 ------------- REPL is now in #<thread #2> ------------- *** WARNING -- Variable "unknown-symbol-h" used in module "c.o1" is undefined ------------- REPL is now in #<thread #1 primordial> ------------- > 0 0 ------------- REPL is now in #<thread #2> ------------- *** WARNING -- Variable "unknown-symbol-i" used in module "c.o1" is undefined ------------- REPL is now in #<thread #1 primordial> ------------- > 0 0 > 0 0

2 1

Question/feature request regarding #!key parameters
by Per Eckerdal 23 Sep '08

23 Sep '08

Hi. I am working on a hygiene system on top of Gambit. It is a syntactic closures implementation and syntax-rules on top of that. There are definitely some quirks left to fix, but it is slowly getting mature. I have run into one problem though. The code (let ((a #t)) (let ((a #t)) a)) expands to something like (let ((h1#a #t)) (let ((h2#a #t)) h2#a)) This is working fine. (It is so because the outer a must be reachable from the inner let.) However, this approach cannot be used for #!key parameters. (define (fun #!key a) #f) cannot expand into (define (fun #!key h1#a) #f) Because it would force the user of the function to call it like (fun h1#a: name). It cannot expand into (define (fun #!key a) #f) either, because it breaks hygiene. This is what the system does right now, but it would be nice to actually make correct. It works rather well already, because #!key parameters are relatively rare, and usually have rather unique names (that is, not builtin functions and not nested with the same names). Is there any way of working around this? One way of fixing this would be to change Gambit to add support for syntax like (lambda (#!key ((outside-name . inside-name) default-value)) #f). In that case the example above would expand into (define (fun #!key ((a . h1#a) #f)) #f) which would be hygienic. It would be better with something that didn't needed a change in Gambit though. Any ideas? /Per

2 1