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

Git procedures for Gambit
by Marc Feeley 23 Oct '08

23 Oct '08

The new procedures for using git with Gambit are available here: http://dynamo.iro.umontreal.ca/~gambit/wiki/index.php/Contributing_Patches_… Marc

1 0

gti'ing 4.3
by Ken Dickey 23 Oct '08

23 Oct '08

v4.3.0 builds fine, but... gambit>> make update fatal: Not a git repository make: *** [fetch] Error 128 gambit>> git --version git version 1.5.4.3 gambit>> git init Initialized empty Git repository in .git/ gambit>> make update fatal: 'origin': unable to chdir or not a git archive fatal: The remote end hung up unexpectedly make: *** [fetch] Error 128 ?!? Cheers, -KenD

3 2

[ANN] Gambit-C v4.3.0 released
by gambit＠iro.umontreal.ca 23 Oct '08

23 Oct '08

4 3

Scheme workshop survey
by Marc Feeley 18 Oct '08

18 Oct '08

The Scheme workshop has been held every year since 2000 (http://www.schemeworkshop.org/ ). It is one of the main venues where the Scheme community can come together to discuss the Scheme programming language. Traditionally the workshop is co-located with the ICFP conference (the only exception is in 2003 when it was held in Boston). The Scheme workshop steering committee (http://www.schemeworkshop.org/sc.html ) which oversees the organization of the workshop is searching for ways to increase the level of participation from the Scheme community. For this reason we are conducting a survey to determine at what location and time the next workshop should be held. One important issue is whether we should continue co-location with the ICFP conference. Please take a few minutes of your time to complete the online survey at the following URL (before the deadline of midnight friday October 31): http://dynamo.iro.umontreal.ca/sw/survey Your feedback is very much appreciated! Marc Feeley for the Scheme workshop steering committee P.S. My apologies if you get this message multiple times.

1 0

Mercurial -> git
by Marc Feeley 16 Oct '08

16 Oct '08

I'm planning to move the source-code repository from Mercurial to git in the next few days. This change is prompted by slugish performance of Mercurial on some operations I use frequently, such as "hg diff", on the current repository. If you plan on developing with Gambit, in particular you want "make update" to recompile your Gambit using the most up-to-date patches, then please get ready for the switch by making sure git is installed on your development workstation. Git is available here: http://git.or.cz/ . There are binaries for many OSes including Mac OS X and Windows. It turns out the "hg" and "git" commands have almost the same syntax, so it should be a fairly easy transition for most Mercurial users. Moreover, up to now Gambit has been released in source form in a single compressed tarball, e.g. gambc-v4_2_9.tgz, which is bloated due to the inclusion of all the revision-control history. In the next release Gambit will be released in 2 tarballs: gambc-v4_2_10.tgz and gambc-v4_2_10-devel.tgz . The "devel" variant which contains the revision-control history should be used by developers. The non-devel variant is about half the size (7 MB instead of 14 MB). Marc

9 16

[PATCH] Fix .gambc_history permissions
by Christian Jaeger 15 Oct '08

15 Oct '08

Create the repl history file with private permissions (as most tools are doing). Tested on Linux, I don't know whether this works on non-POSIXy systems.

2 2

Git repository
by Marc Feeley 11 Oct '08

11 Oct '08

I decided to use "cgit" as a web interface to the git repository. Another option would have been "viewgit" and "gitweb" but I could not get either to work. Also cgit is pretty fast. Here is a mockup you can try. Let me know what you think. Marc Gambit Scheme system repository: http://www.iro.umontreal.ca/~gambit/repo/.cgit.cgi/Gambit Changelog: http://www.iro.umontreal.ca/~gambit/repo/.cgit.cgi/Gambit/log

2 1

Cygwin (WAS RE: Mercurial -> git)
by Nathan Thern 10 Oct '08

10 Oct '08

On Thu, Oct 9, 2008 at 1:20 PM, David Rush <kumoyuki(a)gmail.com> wrote: > ... And please don't say "cygwin" - > it's just *too* painful. I gotta disagree with you there. As a small cog in a mind-numbingly large machine, I don't have a choice about using windows. Cygwin is what makes using windows bearable for me. It has its warts, but it is amazingly successful in its goal of providing a *nix/POSIX API. I certainly wouldn't call it "painful". BTW, I have an unofficial gambit package for cygwin. Point cygwin's setup.exe to http://www.liquid.spod.org/~nthern/cygwin/ I don't have to patch the source, but in order to get shared libraries to work right I hijack gcc with a libtool wrapper script. Gambit compiles OTOB on cygwin, but you get static libs only. regards, Nate T

2 1

On FFI argument and buffer memory handling
by Mikael More 09 Oct '08

09 Oct '08

Hi! I suppose these questions better be directed to Marc: a) On many occassions, FFI:s need to pass external libraries structures. These are variables passed by value (ints, floats, bools), and variables passed as pointers, that is, strings and structures. Two questions: First off, I presume that UTF-8-string argument values passed to a c-lambda are by default allocated until function return. How can one make so that such an argument value continues to exist after the C function returns (i.e. increase reference count)? At the time one wants to discard the string, how is that done (i.e. decrease reference count)? Second, on many occasions, one needs malloc/free functionality in FFI code. Do you recommend one to use some Gambit-internal function to get the functional equivalent, or to go with a malloc such as tcmalloc? b) Do c-lambda invocation require a trampoline, so that there's a trampoline cost involved in each Scheme-to-C call? (Each taking ~0.5*10^-8 seconds, afaik) c) Is there one particular practice you recommend for FFI functions to return multiple return values, in a performant way? Can you give a code example that returns bool, unsigned 32- and 64-bit integer, char* containing UTF-8 string, and byte buffer returned as u8vector? Thanks Mikael

1 0

Multi-process
by Guillaume Cartier 06 Oct '08

06 Oct '08

I was having a discusion with someone about Gambit and he asked me the following question : > One issue...from the Gambit threading documentation. > > "Gambit supports the execution of multiple Scheme threads. These > threads are managed entirely by Gambit's runtime and are not related > to the host operating system's threads. Gambit's runtime does not > currently take advantage of multiprocessors (i.e. at most one thread > is running)." > > I really do need multiprocessor support as computer graphics gets a > pretty linear speedup on multiple CPUs. Do know if Gambit can, like > Lispworks, at least have calls into foreign functions running on > multiple CPUs? > Does Gambit support that model like Lispworks?

2 1