Gambit-list Octobre 2008

gambit-list@iro.umontreal.ca

30 participants
36 discussions

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

22 Oct '08

4 3

Scheme workshop survey
by Marc Feeley 17 Oct '08

17 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 10 Oct '08

10 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 09 Oct '08

09 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 08 Oct '08

08 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 05 Oct '08

05 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

build failure after latest make update
by Bradley Lucier 05 Oct '08

05 Oct '08

gcc -mcpu=7450 -I../include -I. -no-cpp-precomp -Wall -W -Wno-unused - O1 -fno-math-errno -fschedule-insns2 -fno-trapping-math -fno-strict- aliasing -fwrapv -fomit-frame-pointer -fPIC -fno-common - DHAVE_CONFIG_H -D___PRIMAL -D___LIBRARY -D___GAMBCDIR="\"/usr/local/ Gambit-C/v4.2.9\"" -D___SYS_TYPE_CPU="\"powerpc\"" - D___SYS_TYPE_VENDOR="\"apple\"" -D___SYS_TYPE_OS="\"darwin8.11.0\"" - c _kernel.c gcc: unrecognized option '-no-cpp-precomp' _kernel.c:13957:52: error: invalid digit "9" in octal constant

2 1

Re: [gambit-list] Strategies on decreasing executable size for Gambit-based software for client distribution
by Marc Feeley 04 Oct '08

04 Oct '08

Sure that could be done. But then it would change the semantics of your language, in the sense that (eval '(map sqrt '(1 4 9))) would only "work" if somewhere else in your program you use "map" and "sqrt" *and* the compiler did not inline them (which Gambit currently does). The semantics of eval would be implementation dependent. Frankly I would find it very hard to use eval reliably. Marc On 4-Oct-08, at 5:39 AM, Mikael More wrote: > Does really the ability of introspection bring with it that all code > is referenced to? Can't introspection work like that all routines > can be introspected, that are linked in in any case? > > Mikael >

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