Gambit-list Mars 2008

gambit-list@iro.umontreal.ca

34 participants
49 discussions

macro-expand
by Joel Borggrén-Franck 10 Mar '08

10 Mar '08

The manual says to use pp as a macro expander: > (define-macro (push var #!optional val) `(set! ,var (cons ,val ,var))) > (pp (lambda () (push stack 1) (push stack) (push stack 3))) (lambda () (set! stack (cons 1 stack)) (set! stack (cons #f stack)) (set! stack (cons 3 stack))) Since I got tired of the extra writing and the lambda in the output, I wrote my own macro-expand macro based on the pp example from the manual: ;; Expand one a gambit-c macro form. (define-macro (macro-expand mac) (let ((port (gensym)) (form (gensym))) `(let ((,port (open-string))) (pp (lambda () ,mac) ,port) (let ((,form (read ,port))) (caddr ,form))))) It works as I expect: > (macro-expand (macro-expand 0)) (let ((#:g2 (open-string))) (pp (lambda () 0) #:g2) (let ((#:g3 (read #:g2))) (caddr #:g3))) but it strikes me as a bit inelegant. Is there a better solution? Is there a way to read from pp without creating a port first? I played around with with-output-to-string first but that just gave me a headache. /Joel

2 6

GSoC ideas list
by Marc Feeley 10 Mar '08

10 Mar '08

Here are the GSoC ideas: http://dynamo.iro.umontreal.ca/~gambit/wiki/index.php/GSoC_ideas_list Please let me know (or edit the page as indicated) if you have suggestions. Marc

1 0

Untested patch: Debugger command to reprint error
by Derek Peschel 06 Mar '08

06 Mar '08

Since (IMO) the debugger should be able to describe everything it knows about, I wrote a new command (for version 4.2.2) to reprint the last error. Unfortunately I have no idea if I implemented it right. A patch is attached. The test case foo bar ,d ,r implies that there's only one error shared by all REPL levels (which makes the levels less useful than they might be). Typing the "foo bar" on the same line also shows how prompts and output can be mixed. The Emacs interface doesn't recognize the 1> prompt before the second error message, so it only highlights the first error even though the interpreter has forgotten the first error. Thanks for any comments. -- Derek

1 0

Termite memory leak
by Nicholas Walton 05 Mar '08

05 Mar '08

Hi, I've been tracking down what seemed to be a memory leak in a large program written using Termite. The image was growing to over 500Mb for no obvious reason and after a lot of hunting the problem seems to lie with the use of spawned processes to model mutable structures. The example code from the paper on the Termite site as below (define (make-cell content) (spawn (lambda () (let loop ((content content)) (recv ((from tag 'ref) (! from (list tag content)) (loop content)) (('set! content) (loop content))))))) (define (cell-ref cell) (!? cell 'ref)) appears at first glance to be tail recursive. However, the example below (define (cell-set! cell value) (! cell (list 'set value))) (define c (make-cell (make-vector 10000))) (define v (vector->list (make-vector 100000 -3))) (define (ctest) (map (lambda(i)(cell-set! c (make-vector 1000 -2))) v)) (ctest) will run a heap of 200Mb out of space. I assume recv is a macro which generates non-tail callable code. So after a large number of accesses o a cell memory is eaten up by the loop recursing. Is there any way around this? Or have I made a mistake esp. since named lets seem to be very common in Termite code. I would have used define-structure and worked around side effecting code except structure types appear not be equivalent between Termite instances ie defined structure A on instance X is not the same objects defined using the same structure A but created in a separate instance B. Accessing A objects created on X but passed to B result in a type exception. Nick Walton

1 0

Paper on the compiler
by Marc Feeley 04 Mar '08

04 Mar '08

I have put on the web a paper which explains how Gambit-C does speculative predefined procedure inlining. It also briefly describes the compiler's architecture. I think it will be a useful read for those interested in knowing more about the implementation of Gambit-C. The paper is available here: http://www.iro.umontreal.ca/~feeley/papers/ifl07-feeley.pdf Marc

1 0

Re: [gambit-list] Dynamic bindings?
by Marc Feeley 04 Mar '08

04 Mar '08

On 4-Mar-08, at 6:05 PM, David St-Hilaire wrote: > Ok Thx! But having x defined as a global variable, and thus being > present in the lexical scoping of f when it is defined doesn't feel > much like dynamic bindincs, doesn't it? If we do something like: > > > (define x (make-parameter #f)) > > > > (define (f) (pp (x))) > > > > (set! x 'oups) > > (parameterize ((x 10)) > > (f)) > > results in an error, but doesn't dynamic scoping would permit > something like that? A parameter object is not a variable, it is an object... You can bind it to a variable (global or not), but that's just a way to give it a "name" so that you can refer to it in the rest of your code. So when you do (define x (make-parameter #f)) all code that can see the variable x has access to the parameter object. You could use a local variable as in (let () (define x (make-parameter #f)) ...) and then only the body of the let has access to the parameter object. This is not a bug... it's a feature (because you have more control than a globally visible "dynamically scoped variable"). The "dynamic binding" aspect is obtained with the (parameterize ...) form, which is the analog of your (dynamic-let ...). This is a bit amusing because in earlier versions of Gambit, "dynamic- let" was supported with the semantics you seem to expect. Marc

1 0

Dynamic bindings?
by David St-Hilaire 04 Mar '08

04 Mar '08

Hi gambit list! Is there a way to get some dynamic scoping in gambit? I tried to use the make-parameter and parameterize forms, but I guess I didn't understood them because it didn't work out... I'd like to do something like: (define (f) (dynamic-let ((x)) x)) (let ((x 10)) (f)) --> 10 such that x gets defined dynamically? How can I use make-parameter and parameterize to do such a thing? Thank you! David

2 1

Using OpenMP as a basis for shared-memory parallel Gambit?
by Bradley Lucier 02 Mar '08

02 Mar '08

OpenMP is a programming model/API/library for shared-memory parallel computations in C, C++, and Fortran: http://www.openmp.org/drupal/ Gcc now implements OpenMP http://gcc.gnu.org/onlinedocs/libgomp/ Perhaps OpenMP can be used as a basis for shared-memory parallel Gambit. Brad

1 0

[ANN] Gambit-C v4.2.3 released
by gambit＠iro.umontreal.ca 02 Mar '08

02 Mar '08

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 Mars 2008