Gambit-list Mars 2008

gambit-list@iro.umontreal.ca

34 participants
49 discussions

Problem compiling v4.2.5 with Visual C++ 2003 std
by Louis-David Perron 25 Mar '08

25 Mar '08

I have problems compiling v4.2.5 with Visual C++ 2003 std (as stated in the title). This procedure worked perfectly with v4.0.1: - untar source tree. - copy include/config.h.in and include/gambit.h.in to ".h" and configure @.*@ strings from gambit.h. - unzip the "vstudio.zip" file in the source root folder. - open the gambc.sln file. - remove ___SINGLE_HOST from the "Release" preprocessor options (I'm just too impatient.. in fact, I think it fails due to not enough memory on my machine). - build the project with "Release" configuration If I do the same procedure with v4.2.5, the "lib", "gsi" and "gsc" projects compiles properly, but gsi and gsc fail during the link phase. I compared and I have the exact same command line for the linker in both cases. Here is my exact error message (unresolved external symbol): Édition des liens en cours... _gsi_.obj : error LNK2001: symbole externe non résolu _____20___gambcgsi Release/gsi.exe : fatal error LNK1120: 1 externes non résolus Thanks for the help! Louis-David

2 2

Looking at the continuation tree?
by Derek Peschel 24 Mar '08

24 Mar '08

Last night I found "A Better API for First-Class Continuations", which explains how a debugger can take control and give it back to the original computation. The paper also describes the tree created by a series of continuations. Is there a way to see the whole tree? I'd like to under- stand how the backtrace command creates the stack out of the tree. You need a first error or step to show a backtrace. As the transcript below shows, a second error will change the backtrace (I had hoped it would add frames to the printout). Curiously the change is only temporary -- "undoing" the second error with ,d also undoes the change. As the second test shows, tail recursion is not involved. I assume the "change" is really an effect of the ,b printing code. Thanks! -- Derek Gambit v4.2.4 > (define (a) ; a (step) in tail position doesn't cause a stop -- doubling (step) (step)) ; creates a non-tail (step) which is what the test uses > (a) *** STOPPED IN a, (console)(a)2.9 1> ,b 0 a (console)@2:9 step 1 (interaction) (console)@3:1 (a) 1> x *** ERROR IN (console)(a)5.1 -- Unbound variable: x 2> ,b 0 (interaction) (console)@5:1 x 1 (interaction) (console)@3:1 (a) 2> ,d 1> ,b 0 a (console)@2:9 step 1 (interaction) (console)@3:1 (a) 1> ,q Gambit v4.2.4 > (generate-proper-tail-calls #f) > (define (a) (step) (step)) > (a) *** STOPPED IN a, (console)(a)3.9 1> ,b 0 a (console)@3:9 step 1 (interaction) (console)@4:1 (a) 1> x *** ERROR IN (console)(a)6.1 -- Unbound variable: x 2> ,b 0 (interaction) (console)@6:1 x 1 (interaction) (console)@4:1 (a) 2> ,d 1> ,b 0 a (console)@3:9 step 1 (interaction) (console)@4:1 (a) 1> ,q

1 1

Updated Schemeray
by Bradley Lucier 22 Mar '08

22 Mar '08

I'd found Schemeray by James Long on the net earlier, and had played around with it somewhat to get it to run a bit faster. I've uploaded Schemeray-0.2b.tgz (think of "b" as the second version of 0.2, or for "Brad", however you like); here are the times on my 2.0GHz G5 with a 100MB minimum heap ("gsi -:m100000") Original: (time (load "schemeray")) 75190 ms real time 73757 ms cpu time (72821 user, 936 system) 1041 collections accounting for 33949 ms real time (33087 user, 297 system) 80379235552 bytes allocated no minor faults no major faults "/Users/lucier/Desktop/Downloads/schemeray-0.2/schemeray.o2" After playing around with inlining-limit and using flonum- and fixnum- specific operations: (time (load "schemeray.o7")) 20978 ms real time 20870 ms cpu time (20672 user, 198 system) 333 collections accounting for 4864 ms real time (4804 user, 48 system) 29847131896 bytes allocated no minor faults no major faults "/Users/lucier/Desktop/Downloads/schemeray-0.3/schemeray.o7" After changing the code to just write each pixel as it's computed, instead of saving them in a list and writing them all at the end of the computation: (time (load "schemeray")) 16775 ms real time 16514 ms cpu time (16122 user, 392 system) 284 collections accounting for 312 ms real time (306 user, 7 system) 29252226080 bytes allocated no minor faults no major faults "/Users/lucier/Desktop/Downloads/schemeray-0.3/schemeray.o12" A generational garbage collector would really have helped the second version of the code, and the third wouldn't have been necessary. I'll let James decide what he wants to do with it. Brad PS: One pixel in the image differs in one RGB component by 1; so the images are not identical, but I think that can be explained by rearrangement of some of the operations and round-off error.

2 2

Suggested change to "make update"
by Bradley Lucier 22 Mar '08

22 Mar '08

Marc: I forgot to do a "make bootstrap" before doing a "make update" so the "make" failed because gsc-comp was not found to compile _io.scm. So I just copied gsc/gsc to gsc-comp and did another "make update". But this second time, it assumed the previous "make" worked, and did an hg update before doing the next "make", and everything bombed. So I suggest that "make update" do a "make" just after the "hg pull"; then if "make update" fails, and you can fix it by hand, you can just do another "make update" to get things rolling again. Brad

1 0

[Fwd: [Fluxus] games & scheme]
by David St-Hilaire 20 Mar '08

20 Mar '08

There is not much content in the slides, but I think it is still interesting ;) David -------- Original Message -------- Subject: [Fluxus] games & scheme Date: Thu, 20 Mar 2008 12:01:07 -0000 (GMT) From: Dave Griffiths <dave(a)pawfal.org> Reply-To: dave(a)pawfal.org To: fluxus(a)pawfal.org I guess most interested people would have seen this by now, but in case: http://www.naughtydog.com/corporate/press/GDC%202008/AdventuresInDataCompil… It's not that informative as just slides, but it's about how Naughty Dog wrote their last PS3 game "Uncharted: Drake's Fortune" using scheme. cheers, dave

1 0

Re: [gambit-list] As far as the renaming scheme goes, ...
by Abdulaziz Ghuloum 19 Mar '08

19 Mar '08

On Tue, 18 Mar 2008 13:50:02 -0400, Bradley Lucier <lucier(a)math.purdue.edu> wrote: > On Mar 18, 2008, at 12:25 PM, Ken Dickey wrote: >>> Dimitris Vyzovitis wrote: >>> >> ... >> >>> One of the problems I have with these systems (including the modules >>> produced by the orignal portable syntax-case) is that they produce >>> mutable >>> bindings for module/library exported identifiers. >>> >> >> Note that R6RS library bindings are immutable. >> > > Yes, but as your next comment might imply, either the module > implementation needs to change or Gambit's compiler implementation > needs to change so that the compiler can exploit that information. True. The expander has to communicate that information to the compiler somehow. The way psyntax is structured allows for providing this information on a per compiler basis by customizing the way the output is generated. The language of the output of the expander can be customized in many ways in psyntax. 1. For some forms, there is a simple flag that allows you to select how one piece of core syntax is expanded. Take lambda and case- lambda for example. One implementation can select not to generate any case-lambdas, consequently, case-lambdas will be expanded to a lambda with a dispatch code based on the number of arguments. Another implementation can select not to generate any lambdas, and in that case, all lambdas are converted to a one-clause case-lambda forms in the output. Whether the underlying implementation supports letrec, letrec*, and so on can be customized this way. [look at psyntax.config.ss (1)] 2. References to primitive procedure can be customized so that it looks like "cons", "#%cons", "##sys#cons", or whatever the underlying implementation wants it to look. The out-of-the-box expander just outputs "cons" because it's the lowest common denominator between all the targeted R5RS implementations but it's by no means a limitation of the expander. As a matter of fact, you can get away with not generating an s-expression output at all and by generating whatever the compiler accepts as input directly from the expander by customizing how the "build-*" procedures work. [look at psyntax.builders.ss (2)] As far as the immutability of the library exports, there is a hook for how the output of the run-time components of the library should be generated (see build-library-letrec* in psyntax.builders.ss). In ikarus, I generate this library-letrec* form that looks like: (library-letrec* ([local-name exported-name expression] ...) body) A portable implementation would generate: (letrec* ([local-name expression] ...) (begin (set! exported-name local-name) ... body)) A gambit-specific generator would add the declarations that you mentioned in your message (e.g., (safe) (standard-bindings) ...) and shape the output to look in a way that the gambit compiler likes. I hope that no one hacks/forks the core of the expander (i.e., psyntax.expand.ss and psyntax.library-manager.ss) since newer versions of these come out all the time and you don't want to repatch your modified version any time a new version is released. If there is any limitation in the core of the expander (e.g., if these are things that you wish you could customize but neither psyntax.config.ss nor psyntax.builders.ss provides the hooks), then I would be happy to fix it. Aziz,,, [1] http://bazaar.launchpad.net/~aghuloum/ikarus/ikarus.dev/annotate/ aghuloum%40cs.indiana.edu-20080318044924-uvf4daqro1sj8gvx? file_id=psyntax.config.ss-20071009125425-0emiakw98pjacfzu-2 [2] http://bazaar.launchpad.net/~aghuloum/ikarus/ikarus.dev/annotate/ aghuloum%40cs.indiana.edu-20080318044924-uvf4daqro1sj8gvx? file_id=psyntax.builders.ss-20071009125425-0emiakw98pjacfzu-1

2 5

Packages on the Dumping Grounds
by Marc Feeley 19 Mar '08

19 Mar '08

Wow! In less than a day we already have 6 new interesting packages on the Dumping Grounds: - Oops: Object Oriented Programming for Scheme -- Dylan/Clos-like but different - TinyTalk: Self-like object system with selector [Smalltalk like] dispatch - MySQL FFI: FFI for mysql - Bunny Test: A simple unit testing framework - Octave: A simple plotting interface using octave and gnuplot - Jss: JavaScriptScheme: a multithreaded Scheme to JavaScript compiler I'm sure all of the Gambit mailing list members can dig up some of their code to contribute to the Dumping Grounds. If everyone contributes a package we would have a few hundred packages in no time... let's make it happen! Marc

1 0

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

19 Mar '08

3 2

macroexpand
by Alex Queiroz 19 Mar '08

19 Mar '08

Hallo, I know this sounds too newbie, but I couldn't find macro-expand(-1) in Gambit's manual. Is there an equivalent form? Cheers, -- -alex http://www.ventonegro.org/

3 2

Where are nucleic benchmark results?
by Bradley Lucier 19 Mar '08

19 Mar '08

Marc: nucleic is in bench.tgz, but I don't see any results on http://dynamo.iro.umontreal.ca/~gambit/wiki/index.php/Gambit_benchmarks and Clinger doesn't have any results on his "fake r6rs" page, either. Why not? Brad

2 1

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