Décembre 2013 - Gambit-list - mailman.iro.umontreal.ca

Re: [gambit-list] Proposed patch
by Bradley Lucier 16 Déc '13

16 Déc '13

This got bounced the first time. On 12/15/2013 12:47 PM, Bradley Lucier wrote: > > On 12/15/2013 11:56 AM, Marc Feeley wrote: >> Your patch is now applied and on the repo. I have also added >> inlining of ##flsquare. > > Thanks. (It took me a few minutes to understand that I needed to > "make bootstrap" after the changes.) > > The compiler should probably expand > > (square x) > > as > > (cond ((##fixnum? x) > (cond ((##eq? x 0) 0) > ((##fixnum.*? x x) > => values) > (else > (##square x))) > ((##flonum? x) > (##flsquare x)) > (else > (##square x)) > > and similarly for flsquare. And similarly for conjugate. > > Brad

2 1

User-visible features in parallel code?
by Bradley Lucier 16 Déc '13

16 Déc '13

Marc: Are there any user-visible features we could try in the new infrastructure for parallel code? Brad

1 0

Getting Gambit to work under OS X Mavericks
by Tomas Möre 14 Déc '13

14 Déc '13

To those unfortunate souls who updated to OS X 10.9 The standard compiler that comes with with xcode 5 is clang and it will give you a ton of troubles. To fix this (the easiest way) install gnu gcc from Macports. That has received an update for 10.9. http://www.macports.org/install.php Be cautious I have heard that Homebrew and Macports does not work very well together. Then type the following into the terminal: sudo port install gcc48 (or the gcc version number you prefer) It will probably give you a few errors. Simply do a port install on all the dependancies. In the end it will give you a "gcc-mp-[version]" binary in /usr/bin simply rename / remove the existing gcc and rename the Macports variant to gcc. (The gcc provided by xcode is just a link to clang anyhow). Hope it helps! Tomas

2 1

Lack of Libraries/ FFI / Tutorials
by Tomas Möre 11 Déc '13

11 Déc '13

Hello everybody! I would like to start out by saying a thank you to Marc for making Gambit. It is an awesome piece of software! Keep up the good work! But I would like to point on the lack of standard libraries for things such OpenGL, cocoa / the windows equivalent etc. (there are a few in the dumping grounds but they are incredibly outdated) Starting up using gambit has required a great deal of self guided exploring and trickery. And I can not see any reason why it should not exist any kind of simple examples for beginners to look at. I do know that there are one to be found on the site however I find it a bit too "technical" for some people. To the question! I had a little idea to ask you guys if any one you are interested in making a little development project to update the basic libraries needed. Maybe some of you already have such things and I encourage you to upload them to the dumping grounds! Sharing is caring! :) I will start working on doing these things myself but I must admin I neither have enough time and experience to do a good job all by myself. If you have an interest send me a mail! Best regards, Tomas Möre

4 5

Gambit installer on OS X
by Marc Feeley 10 Déc '13

10 Déc '13

I recall hearing that some OS X users are having problems with the installer for the prebuilt Gambit. Unfortunately I can't reproduce the problem on my computer, so I can't debug this. I would like OS X users to try the most recent installer (http://www.iro.umontreal.ca/~gambit/download/gambit/v4.7/prebuilt/gambc-v4_…) and if the install fails, send me the detailed error log (which you can save to disk by selecting the "Installer Log" item in the "Window" menu). Marc

4 7

Re: [gambit-list] Gambit-list Digest, Vol 111, Issue 9
by Răzvan Rotaru 10 Déc '13

10 Déc '13

Hi, Congratulations, and a big thank you. This is great news. I remember looking over scheme implementations some time ago, and not being sure whether gambit is actually still alive or not (besides bugfixing). Whether there's a community around it. Whether somebody is till actively working on it and/or supporting it. In the mean time I have learned the answer, and I've also found out that things are moving towards multi-core and multi-platform (speak: javascript). This is great. If I am allowed, I would like to criticize the lack of a "community adopted" module system, which I think can have a big (positive) influence on the community. My oppinion is that newcomers want to get started quickly. And they have stuff to do. They want to tackle the big questions later, and get stuff done now. Rick Hickey did put it very nicely: default matters. I can't but agree. If Black Hole is good enough, I can't but suggest to give it a "pseudo standard" status and include it in the distribution (or recommend it as a standard module system). And make sure it's handling libraries at least at convenient as maven (i.e. auto download and dependency resolution). It is incredibly important to have an easy quickstart, and have libraries at your fingertips, and get stuff quickly done. This is actually the secret recipe of Java (even if they discovered it in the second decade, and the core technology still sucks big time, even now). As much as I hate to wake a sleeping dragon, I must say that gambit has to make more bold moves and decisions and focus on gathering a community around it, if it intends to be practical. Thanks, and don't kill the critique. Razvan I'm not sure if and how I can help. If there are ideas out there, I'm open to suggestions. On 9 December 2013 19:00, <gambit-list-request(a)iro.umontreal.ca> wrote: > > ---------- Forwarded message ---------- > From: Marc Feeley <feeley(a)iro.umontreal.ca> > To: Bradley Lucier <lucier(a)math.purdue.edu> > Cc: Logiciel Gambit <gambit(a)iro.umontreal.ca>, > gambit-list(a)iro.umontreal.ca > Date: Mon, 9 Dec 2013 09:10:55 -0500 > Subject: Re: [gambit-list] [ANN] Gambit-C v4.7.1 released > > On Dec 8, 2013, at 2:44 PM, Bradley Lucier <lucier(a)math.purdue.edu> wrote: > > > So, Marc, spill the beans! There are thousands and thousands of lines > of new code in this release; what's new? What can we play with here? > > This release represents the latest month of work where the runtime system > has been refactored to support multiple VMs and multiple threaded VMs (with > OS threads). Data structures had to be modified to clarify what is shared > between VMs, and what is specific to each "processor" in each VM instance. > An abstraction layer was added to interface to the operating system's > thread system. The linker was also changed to allow a VM to only > initialize the modules it requires. Not much of this work translates to > user visible features at this point, but it does put in place a new > organization of the runtime system that is necessary for a parallel Gambit. > Given that the Gambit compiler's code generation changed (to support the > new linker), it was necessary to do a "release", otherwise it would not be > possible to build Gambit from the sources on the repo. I'm also interested > in having feedback from people building this new release of Gambit. Please > report any problems building Gambit on your computer. > > One feature that is user visible, and possibly interesting for developers > of large applications, is the ability to link modules into an executable, > but not "load" these modules when the program is started. This can make > the startup of the application faster and use less memory. This is > achieved with the -nopreload linker option, the special form > (##require-module <name>) and the procedure (##load-required-module > '<name>), where <name> is a symbol naming a module. > > The form (##require-module <name>) can be placed anywhere a definition is > allowed. For example it could be at the file's top-level, inside of a > function definition, or the head of a let body. This form adds the call > (##load-required-module '<name>) at the *top* of the file. The procedure > ##load-required-module causes a linked module to be loaded if it has not > previously been loaded. By default the linker loads all the linked modules > when the program is started (what I call "preloading" of a module). The > linker now has the option -nopreload that can be placed anywhere on the > command line to prevent the preloading of the following modules. Here's an > example: > > % cat a.scm > (pp 'hello-from-a.scm) > > (define (double x) (* 2 x)) > % cat b.scm > (pp 'hello-from-b.scm) > > (define (fun x) > (##require-module a) > (pp (double x))) > % cat c.scm > (pp 'hello-from-c.scm) > > (thread-sleep! 2) > > (##load-required-module 'b) > > (fun 100) > % gsc -exe a.scm b.scm c.scm > % ./c > hello-from-a.scm > hello-from-b.scm > hello-from-c.scm > <2 second pause> > 200 > > Note that the invocation of gsc without the -nopreload option gives the > same behavior as previous versions of Gambit: all modules are preloaded in > a left to right order. > > Here's what happens when the preloading is disabled: > > % gsc -exe -nopreload a.scm b.scm c.scm > % ./c > hello-from-c.scm > <2 second pause> > hello-from-a.scm > hello-from-b.scm > 200 > > Here the program only loads module c (the "main" program is always the > last module). It is module c that explicitly requests the loading of > module b by calling (##load-required-module 'b). However, since module b > has a dependency on module a (in function fun), module b will require the > loading of module a before its body is executed. So module a's body is > executed before module b's body. > > These features form the basis for constructing a module system. > > Marc >

5 4

Continuations bug in v4.6.2?
by Patrick Li 09 Déc '13

09 Déc '13

Hello! I've been writing some tricky code involving continuations, and ran into the following surprising behavior from Gambit v.4.6.2 running on OSX. I have two versions of "make-jp", that I believe should be equivalent. Version 1: (define (make-jp block) (let [(return-point '())] (call/cc (lambda (ret) (define (jp x) (call/cc (lambda (ret) (let [(r return-point)] (set! return-point ret) (r x))))) (set! return-point ret) (let [(result (block jp))] (return-point result)))))) Version 2: (define (make-jp block) (let [(return-point '())] (call/cc (lambda (ret) (define (jp x) (call/cc (lambda (ret) (let [(r return-point)] (set! return-point ret) (r x))))) (set! return-point ret) (return-point (block jp)))))) The only difference is the final line: Version 1: (let [(result (block jp))] (return-point result)) Version 2: (return-point (block jp)) However, I get different behavior when I test with the following code: Testing Code: (let* [(j '())] (make-jp (lambda (y) (set! j y) (y 0) 10)) (println "GOT: " (j "X"))) Version 1 prints: GOT: 10 Version 2 prints: GOT: X Out of the two behaviours, I expect the answer given by Version 1. Can anyone verify whether this is a bug, and whether the latest version also shows this behavior? This fell out of a piece of code I'm using to simulate coroutines for an interpreter that I am programming. Here I've tried to isolate the problem down to as few lines as possible. Once I get my environment fixed, I will try it on the latest version of Gambit as well and see if the problem is still there. -Patrick

2 4

Need new flonum functions---are they available on all systems of interest?
by Bradley Lucier 09 Déc '13

09 Déc '13

Marc: I have the following definitions in a file I'm using when updating Gambit's trigonometric (and adding hyperbolic) functions: ;;; #include <math.h> is in gambit.h (define ##scalbn (c-lambda (double int) double "scalbn")) (define ##ilogb (c-lambda (double) int "ilogb")) (define ##flsinh (c-lambda (double) double "sinh")) (define ##flcosh (c-lambda (double) double "cosh")) (define ##fltanh (c-lambda (double) double "tanh")) (define ##flasinh (c-lambda (double) double "asinh")) (define ##flacosh (c-lambda (double) double "acosh")) (define ##flatanh (c-lambda (double) double "atanh")) (define ##fllog1p (c-lambda (double) double "log1p")) (define ##flexpm1 (c-lambda (double) double "expm1")) It would be really helpful for me if these could be added to gambit.h, the compiler, and _num.scm; then I could just propose patches to _num.scm for my changes, which will come in stages. Also, it would be good to know whether these are available on all systems that Gambit runs on. Brad

2 3

gambit in debian
by Jackson Doak 09 Déc '13

09 Déc '13

hello. I'm trying to update the version of gambit in debian, could someone help me? What's the difference between the normal tarball and the devel one? (as shown at http://www.iro.umontreal.ca/~gambit/download/gambit/v4.7/source/ ) Also, would you mind telling me if the patches at http://sources.debian.net/src/gambc/4.2.8-1.1/debian/patches are now fixed in the tarball? Finally, how much has the build process changed since 4.2? debian currently has to compile part of gambit-c, then use that part to compile the rest.

1 0

90 min s2c & linking separately compiled object files
by Michal Maruska 09 Déc '13

09 Déc '13

Hello, I'm curious about how the ... function calls translated to jumps ... explained in the 90min document/video is implemented for scheme libraries compiled separately, and thus the possible jumps are between different (Elf) object files. I.e. at the C level, how is TCO (constant space for special recursion..) achieved for 2 scheme functions which were compiled into 2 separate object files? Thanks

2 2