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

working with ___arg* variables in c interface
by James Long 15 Oct '07

15 Oct '07

In a c-lambda, what are the types of the argument variables ___arg1, ___arg2, and so on? It seems like they are statically resolved to the types I passed in to the c-lambda, and everything happens that I expect to happen: (define %%addOne (c-lambda (int) int "___result=___arg1+1;")) (display (%%addOne 10)) This correctly prints out 11, and other various operations on pointers seemed to work too. For example, if 'ctx' is a structure with a 'id' field, and 'ctxp' is defined as (pointer ctx), the following function works fine: (define %%useCtx (c-lambda (ctxp) int "___result=(*___arg1).id;")) Basically, my question is when do I need to use ___CAST on the argument variables? Is it something I should be doing most of the time for safety, to suppress warnings or for some other reason? Or is it something done in a special case I haven't encountered yet? I've seen it done in other gambit FFI's and I'm wondering if the other was just paranoid or something (and if I should be).

3 2

Wiki vandalism
by Marc Feeley 14 Oct '07

14 Oct '07

The Gambit wiki has regularly been the target of some random vandalism. Yesterday we hit a new high with over a dozen vandalized pages. I don't know what to think. Is someone getting any enjoyment out of this? Is it the result of some robot? In any case I can't continue wasting time repairing the vandalism. Anyone have a suggestion on how to deal with this? Marc

7 9

Build of latest gambit-c --prefix problem?
by Eric Jonas 14 Oct '07

14 Oct '07

I'm not sure if I'm doing something wrong, but when I build gambit-c with the --prefix option (like, say, --prefix=$HOME/scheme) it dumps all of the resulting binaries and libs in $HOME/scheme/v4.0.1/bin, $HOME/scheme/v4.0.1/share, etc. Is there any way to get the gambit build system to place these directories (the bin and share) directly in the directory specified by --prefix? ...Eric

2 1

Re: [gambit-list] Wiki vandalism
by Harold Ancell 13 Oct '07

13 Oct '07

(Pardon if you see this twice, it may have been dropped on the floor, and the message you'be already seen depends on this one.) At 09:40 AM 10/13/2007, Raffael Cavallaro wrote: >On Oct 13, 2007, at 10:28 AM, Marc Feeley wrote: > >> Anyone have a > suggestion on how to deal with this? > >Require a login, confirmed by email, to edit content? That will hinder people who want to help, especially since MediaWiki isn't so good about maintaining sessions or remembering users. If you're willing to wait up to a day, I check the site every morning and will revert vandalism (don't have authority to delete pages, though), and would be happy to fight this clown for a week or so to see if he gives up. It looks like the same person from a PRC address started the vandalism on the Gambit Wiki on the same day as he hit the Scheme Punks (ERR5RS among other things) Wiki, same style and about the same number of edits. Scheme Punks then got spammed (new pages) by perhaps the same person (Chinese language, I think (not Japanese or Korean)) and the administrator instituted a system where new pages can only be created by logged in and pre-authorized users (this works for the ERR5RS effort, might not be so good for Gambit). And it's still suffering from the random psuedo-word insertion vandalism as of today (plus I just noticed some link spam). And, yeah, some people just revel in vandalism. Very recent statistics seem to show that the psychic payoff for participating in the Wikipedia community hit a tipping point in February, and I think at least a third of that is vandals masquerading as Wiki- lawyer "deletionists" who just enjoy destroying other people's work. Wikipedia is also constantly vandalized in this general sort of insertion way, but what has prompted someone to attack seriously obscure Scheme sites is open to question. Given how automated attacks were half a decade ago, I'd guess just random port-80 "do I see a MediaWiki?" scanning---no "FORTRAN RULZ!" graffiti ^_^. Which implies this may be a robot rather than someone we can deter with reverts.... - Harold

1 0

recommended source for SRFI-1
by Eric Jonas 10 Oct '07

10 Oct '07

Hello! I'm a relatively new user of gambit-c, and I was curious what people use as their canonical source for SFRIs, like SRFI-1? The gambit website says that a package system will be coming soon, but in the mean time it would be great to be able to fold :) Thanks, ...Eric

2 1

Termite and aglets
by Nicholas Walton 08 Oct '07

08 Oct '07

Hi, Can anyone point me to info on any comparison between the models use by Termite (or Termite like tools) and Java aglets or other such Java technology. Nick Walton

1 0

gsc crashing when using Snow + syntax-case + define-record*
by James Long 05 Oct '07

05 Oct '07

I'm posting this to Gambit and not the Snow list because this is Gambit specific (or at least specific to the portable implementation of syntax-case that Gambit uses). I believe there is a bug which causes gsc to crash when compiling a snow package in Gambit's syntax-case environment (gsc -e '(load "~~/syntax-case")', or in Snow terms, using gambit-sc as the snow host). Any package that uses define-record* crashes. It looks like Snow implements its own form of define-record, and it must be somehow conflicting in the syntax-case environment. If I have a simple snow package like so: (package* sc/v1.0.0 (provide: (define-record* vec3d x y z))) (display "Nothing here") This code runs fine interpreted (using `snow -- sc.scm`) as well as compiling fine under Gambit without syntax-case, however when trying to compile the module with a snow host of "gambit-sc" (which is just gambit with syntax-case loaded in), I get an ugly crash: /usr/share/snow/current/bin/snow: line 185: 25809 Bus error "${PROGRAM_gambit_comp}" -prelude '(begin (include "'${SNOW_MACROS}'") (include*-cd "'${snow_file}'"))' -e '(load "~~/syntax-case")' "${snow_file}" If I change snow to include syntax-case.scm and not load it, I get this error: *** ERROR IN #<procedure #2> -- Wrong number of arguments passed to procedure (sc#eval '(begin (define (_snow:macro-expand expr) expr) (cond-expand ((or guile kawa) #f) (else '(begin)))) '#(env #(top-ribcage *top* #t) ((top) #(top-ribcage *top* #t)))) I also added -:dr- so I'd have a repl when this happened, and here's the procedure attached to the current frame: #<procedure #2> = (lambda (%%%%lst512) (datum->syntax-object %%%%k310 (apply (lambda %%%%exprs613 (if (pair? %%%%exprs613) (sc#eval (if (null? (cdr %%%%exprs613)) (car %%%%exprs613) (cons 'begin %%%%exprs613)) (sc#interaction-environment)) #f)) %%%%lst512))) I'm somewhat new to syntax-case so I have no idea what's going on. Apologies for probably not debugging this very well, I'm just dumping everything I can find about it. I am using Snow 1.1.1 and Gambit 4.0.1. -- James Long Coptix, Inc. longster(a)gmail.com

1 0

process-status, close-port, and zombie processes
by Lang Martin 04 Oct '07

04 Oct '07

I've been building a system that runs (without a tty, if that makes a difference) in the background on a Linux system, and which, in turn runs a series of processes. It's in a fairly normal shell script pipeline and exists for the purpose of multi-threading this one step of the pipeline. All seems to be well running interactively. However, when the process runs as a gsi-script, it blocks inside ##thread-sleep! in ##process- status. The final result is the script running at 100% of the CPU (polling the port, seemingly) with a dangling child process, which has already exitted (exat?) and is now a zombie. It seems as though once this happens, each remaining open-process port will block until the full timeout of process-status is reached. the most relevant functions are here: (define (throw-shell-error port timeout) (or (zero? (process-status port timeout 100)) (error "fg command failed")) (close-port port)) (define (bg cmd . arguments) (open-process (list path: cmd arguments: arguments))) (define (fg cmd . arguments) (let ((proc (open-process (list path: cmd arguments: arguments)))) (throw-shell-error proc *join-timeout*))) I am running these commands purely for side-effects, and not reading from or writing to their ports. The problem appears to have something to do with load -- I can run a large number of low impact commands, and a much smaller number of "convert" (from the ImageMagick tools) commands before the zombie processes begin to block my execution. So, as I'm investigating: am I using these commands in the fashion intended by the author? I believe that they are correct in the sense of indicating the programs I mean to run, but am I misusing the port metaphor in some fashion? Any help would be appreciated. For a bit I had each process represented by a gambit thread, but I'm currently just mapping over collections of ports. Gambit v4.0.0, Linux 2.6.17.3 running under gsi-script, same behavior with and without -:d. I haven't used other options to gsi-script.

2 2

Wish list
by Marc Feeley 03 Oct '07

03 Oct '07

I've created a wish list on the Gambit wiki (http:// www.iro.umontreal.ca/~gambit/wiki/index.php/Wish_list) Don't hold back! Marc

1 0

How to use the mercurial version of gambit?
by Sven.Hartrumpf＠FernUni-Hagen.de 02 Oct '07

02 Oct '07

Hi all. I have tried a mercurial checkout following this page: http://www.iro.umontreal.ca/~gambit/wiki/index.php/Contributing_Patches_to_… Unfortunately, I only know cvs, svn, darcs, but not mercurial, so excuse my dumb question. Everthing (starting with the 4.0.1 tar ball ... ; cd gambit; ./configure; make bootstrap) worked till this step: > hg pull abort: index 00changelog.i invalid format 2! gambit [ERROR: 255] > Ciao Sven

2 1