Gambit-list Février 2012

gambit-list@iro.umontreal.ca

22 participants
26 discussions

Setting up scheme environment causes SDL to hang
by Patrick Li 16 Fév '12

16 Fév '12

Hi, I am trying to get Gambit playing well with SDL, and am running into some strange problems when trying to set up the scheme environment. This is the main() function that starts up a SDL window: int main(int argc, char *argv[]) { /* //SETUP */ ___setup_params_struct setup_params; ___setup_params_reset (&setup_params); setup_params.version = ___VERSION; setup_params.linker = SCHEME_LIBRARY_LINKER; ___setup (&setup_params); x = 0; run_stuff(); //Starts a simple SDL animation /* //CLEANUP */ ___cleanup (); } Currently everything is still in C, so there are *no* calls to any scheme functions yet. I found that the animation runs for about 3 seconds before the whole program hangs. If I comment out __setup(&setup_params), then the program executes normally. Are there some subtleties when setting up the Gambit environment that I have to watch out for? Is Gambit spawning another thread and causing some deadlock problems? I am fairly certain that SDL is single-threaded, and the whole animation runs in an infinite loop. I would appreciate any insight people would have on this. Thanks a lot. -Patrick On Wed, Feb 15, 2012 at 1:11 PM, Marc Feeley <feeley(a)iro.umontreal.ca>wrote: > > On 2012-02-15, at 1:36 PM, Patrick Li wrote: > > > Hello everyone, > > > > I am just getting started using gsc to compile files, and I'm wondering > how to go about debugging some error messages I'm seeing. > > > > This is what I am doing: > > > > == inside misha-sdl.scm == > > (println "hello world") > > > > == inside terminal == > > gsc -link misha-sdl > > gcc misha-sdl.c misha-sdl_.c -I/Library/Gambit-C/v4.6.2/include > -L/Library/Gambit-C/v4.6.2/lib -lgambc > > > > == error message == > > ld: warning: ignoring file /Library/Gambit-C/v4.6.2/lib/libgambc.a, file > was built for archive which is not the architecture being linked (x86_64) > > Undefined symbols for architecture x86_64: > > "____gstate", referenced from: > > ____H__20_misha_2d_sdl in cci2oaPA.o > > "____G_println", referenced from: > > ____H__20_misha_2d_sdl in cci2oaPA.o > > "_____20___gambc", referenced from: > > ____linker_tbl in ccR9LONi.o > > "____main_char", referenced from: > > _main in ccR9LONi.o > > > > The notice about skipping libgambc.a is especially worrying. > > > > However, using the command: > > gsc -o hello -exe misha-sdl.scm > > works perfectly. Is there any way to query to see what flags gsc is > passing to gcc? > > > > You can use the -verbose option to gsc : > > gsc -verbose -o hello -exe misha-sdl.scm > > Marc > >

2 2

gambit 4.6.4 taking long time to compile blackhole
by Álvaro Castro-Castilla 15 Fév '12

15 Fév '12

Hi, I'm trying gambit 4.6.4 under Ubuntu 32bits, 64 bits and Gentoo 64 bits. It compiles fine in these systems. However: - Ubuntu 32 bits: fails to compile blackhole, with an out of memory error - Ubuntu 64 bits: compiles, but on a 16gb ram machine. - Gentoo 64 bits: uses all 4gb of ram and takes forever using swap. I didn't finish compiling, because taking that long makes it impossible to develop Blackhole. I've read in the git commits that now the default flag is -O2, could this be the reason? Best regards Álvaro

4 10

Re: [gambit-list] [ANN] Gambit-C v4.6.4 released
by Marc Feeley 15 Fév '12

15 Fév '12

On 2012-02-15, at 7:38 PM, Quan Ta wrote: > On MacOS Lion, using gcc-4.7, "make check" failed with the following: > > > make check > ... > --- > > (file-type ".") => unknown > > (file-type "error.scm") => unknown > > ;;; No such file or directory: (file-type "newdir2") > > ;;; No such file or directory: (file-type "newdir2/bbb") > 1211,1212c1211,1212 > < (file-size "error.scm") => 65891 > < (file-size "newdir2/bbb") => 65891 > --- > > (file-size "error.scm") => 0 > > ;;; No such file or directory: (file-size "newdir2/bbb") > 1214,1220c1214,1220 > < ;;; #<os-exception #10>: (delete-directory "newdir2") > < (delete-file "newdir2/aaa") => #!void > < (delete-file "newdir2/bbb") => #!void > < ;;; No such file or directory: (delete-file "newdir2/ccc") > < (delete-directory "newdir2") => #!void > < (open-process '(path: "sort" arguments: ("input") eol-encoding: cr-lf)) => #<input-output-port #11 (process "sort" "input")> > < (read-all-open-process) => (brown dog fox jumps lazy over quick the the) > --- > > ;;; #<os-exception #19>: (delete-directory "newdir2") > > ;;; #<os-exception #20>: (delete-file "newdir2/aaa") > > ;;; #<os-exception #21>: (delete-file "newdir2/bbb") > > ;;; #<os-exception #22>: (delete-file "newdir2/ccc") > > ;;; #<os-exception #23>: (delete-directory "newdir2") > > ;;; #<os-exception #24>: (open-process '(path: "sort" arguments: ("input") eol-encoding: cr-lf)) > > ;;; CALL EXPRESSION (open-process '(path: "sort" arguments: ("input") eol-encoding: cr-lf)) IS WRONG: (read-all-open-process) > make[1]: *** [test2] Error 1 > make[1]: Leaving directory `/private/tmp/gambc-v4_6_4-devel/tests' > make: *** [check] Error 2 > > > > > Here is my configure command: > > ./configure CC=/opt/local/gcc-4.7/bin/gcc --prefix=/opt/gambc --enable-single-host --enable-gcc-opts \ > --enable-multiple-versions --enable-ansi-c > > > Does anyone encounter the same error? I get the same error when configuring the system with: ./configure --enable-ansi-c This is normal, because --enable-ansi-c means that Gambit's sources will only include the ANSI-C headers and libraries (stdio, stdlib, etc). This is particularly useful when compiling Gambit for an embedded system which has few available libraries (perhaps not even an operating system). Because of this some of the Gambit features will not work because the ANSI-C libraries are insufficient to implement them. For example the "file-type" library procedure which is normally implemented with the C function "stat" (which is part of POSIX but not included in the ANSI-C libraries). So, with --enable-ansi-c you only get a minimal Gambit system. It is still powerful enough to recompile the whole Gambit Scheme sources (at least it was the last time I tried). The solution, on Mac OS X, is to not use the --enable-ansi-c option when configuring! Marc

1 0

Re: [gambit-list] gambit 4.6.4 taking long time to compile blackhole
by Alex Queiroz 15 Fév '12

15 Fév '12

Hallo, On Wed, Feb 15, 2012 at 10:49 PM, Mikael <mikael.rcv(a)gmail.com> wrote: > (you may reply with the ml on cc) > > Hi Alex, great! In the bugzilla post, Andrey didn't clarify approx what > /change in/ memory use could be expected after their update. In case you > don't think this was apparent as well, you could always ask him to clarify > this there :) Brgds, Mikael > Before the fix, compiling _t-c-2.c would take 75GB of memory and cause thrashing; after, gcc peaks at 4GB but mostly stay at 2GB. Still not easy on machines with average amounts of RAM, but much better. Cheers, -- -alex http://www.artisancoder.com/

1 0

Debugging errors using gsc and gcc
by Patrick Li 15 Fév '12

15 Fév '12

Hello everyone, I am just getting started using gsc to compile files, and I'm wondering how to go about debugging some error messages I'm seeing. This is what I am doing: == inside misha-sdl.scm == (println "hello world") == inside terminal == gsc -link misha-sdl gcc misha-sdl.c misha-sdl_.c -I/Library/Gambit-C/v4.6.2/include -L/Library/Gambit-C/v4.6.2/lib -lgambc == error message == ld: warning: ignoring file /Library/Gambit-C/v4.6.2/lib/libgambc.a, file was built for archive which is not the architecture being linked (x86_64) Undefined symbols for architecture x86_64: "____gstate", referenced from: ____H__20_misha_2d_sdl in cci2oaPA.o "____G_println", referenced from: ____H__20_misha_2d_sdl in cci2oaPA.o "_____20___gambc", referenced from: ____linker_tbl in ccR9LONi.o "____main_char", referenced from: _main in ccR9LONi.o The notice about skipping libgambc.a is especially worrying. However, using the command: gsc -o hello -exe misha-sdl.scm works perfectly. Is there any way to query to see what flags gsc is passing to gcc? Thanks very much -Patrick

2 1

R7RS public comment period
by Marc Feeley 14 Fév '12

14 Fév '12

This message is being posted to various lists to inform members of the Scheme community on the development of R7RS. I am pleased to announce that the sixth draft version of R7RS ("small" language) has been completed by working group 1 and is now available at the following URL: http://trac.sacrideo.us/wg/raw-attachment/wiki/WikiStart/r7rs-draft-6.pdf A copy will also be posted on schemers.org . Other documents produced by working group 1, including previous drafts and progress reports are available at the following URL: http://www.scheme-reports.org/2012/working-group-1.html The editors of working groups 1 and 2, in consultation with the Scheme language steering committee, have provided a mechanism for comment and discussion. For details, including instructions on how to submit a formal comment, please see this document: http://www.scheme-reports.org/2012/process1.html The comment period is now open and will continue until June 30, 2012. The steering committee thanks the editors for their intensive work on the draft R7RS, and looks forward to the public comment period on this sixth draft. Enjoy! For the Scheme language Steering Committee, -- Marc Feeley

1 0

New make update problems
by Bradley Lucier 14 Fév '12

14 Fév '12

[Bradley-Luciers-MacBook-Pro:~/programs/gambc-v4_6_4-devel] lucier% make update From http://www.iro.umontreal.ca/~gambit/repo/gambit 8ccd2bd..fd08700 master -> origin/master Updating 15c7390..fd08700 error: Your local changes to the following files would be overwritten by merge: makefile.in prebuilt/remote-connect Please, commit your changes or stash them before you can merge. Aborting M makefile.in M prebuilt/remote-connect Already on 'master' Your branch is behind 'origin/master' by 2 commits, and can be fast-forwarded. make Marc, it's like we're looking over your shoulder downloading your private Gambit repository, hoping it will work. This is not a good feeling. Brad

2 2

Re: [gambit-list] [Gambit-iphone] Remote REPL in iOS app
by Marc Feeley 13 Fév '12

13 Fév '12

What you describe is a common problem when adding a REPL to a program in order to monitor it and debug it. You want the REPL to interact with the user independently from what the main program is doing. In other words, conceptually you want 2 threads: one running the main program, and one running the REPL. To avoid synchronization problems and allow calls between C and Scheme using Gambit's C-interface, these conceptual threads should not be OS threads. It is best to use a cooperative thread model, where only one of these two conceptual threads is active at any given point, and control is passed explicitly between the "main thread" and the "REPL thread". I'll get to how this can be implemented in a moment. Note that when a C to Scheme call returns (to C), or when Scheme code calls a C function, the state of the Scheme world is suspended (in other words all of the Scheme threads are blocked). It is only when C makes a call to a Scheme function, or when a Scheme to C call returns, that the Scheme thread scheduler gets a chance to multiplex the execution of the threads (the multiplexing is done at regular intervals using a "heartbeat" timer interrupt, but only when control is in the Scheme code). Starting a Scheme thread for the REPL is pointless if control (mostly) remains in the C world because it doesn't guarantee that the REPL thread actually runs. Given that there are multiple Scheme threads alive in the Scheme world, you might wonder what happens when a C to Scheme function call is performed... in which Scheme thread is the Scheme function executed? It is simply the same Scheme thread that was executing when control returned to C from Scheme. In your case, you probably need 2 Scheme threads. One is responsible for executing the REPL (call it thread R), and one is responsible for executing the Scheme functions that are called from C (call it thread S). To implement this, the idea is to have the C code make calls to a Scheme "heartbeat" function in thread S on a regular basis. This is usually done in the application's main event loop. The heartbeat function then calls (##thread-heartbeat!) to allow the Scheme thread scheduler to run thread R (and possibly other Scheme threads that might have been created). After the Scheme scheduler has given a fraction of a second for each Scheme thread to advance their computation, the Scheme thread S will be resumed, and at the end of the heartbeat function control returns back to C. At the next C to Scheme call of the heartbeat function, the Scheme thread scheduler will give another fraction of a second of execution time to each Scheme thread, etc. Please check the Gambit REPL example, in particular file intf.scm, which contains an improved heartbeat function which passes back to C the time that should elapse before the heartbeat function is called again (this period of time depends on information that the scheduler has on what the Scheme threads are doing, such as sleeping with a timeout, doing I/O, computing, etc). This reduces the power consumption. Marc On 2012-02-10, at 3:11 PM, François Magnan wrote: > Hi, > > I am currently building an iOS app with Gambit and I (of course) need a REPL-server in it so I can develop interactively instead of recompiling the app every time I make a change. > I saw the REPL-server that Marc developed in the iOS example folder of Gambit distribution so I tried to integrate it in my app. I was able to make it work but I have some problems. > > When I first tried it I tried to run the repl server in a separate gambit thread. I therefore defined the following: > > (c-define (init-repl-server) () void "initREPLServer" "" > ; Start a REPL server > (thread-start! > (make-thread > (lambda () > (display "\n\nStarting REPL server on port 7000\n") > (repl-server-start "toto"))))) > > > In the objective-c method (BOOL)application:(UIApplication *)application didFinishLaunchingWithOptions:(NSDictionary *)launchOptions > I called the gambit setup and then the initREPLServer(); function. > > This didn't work: when the C function returned the Gambit thread died (this is my interpretation) and I could not connect to the server. > > I therefore tried put an infinite-loop at the end of the (init-repl-server) function. It worked but the app would not finish the startup process since "application didFinishLaunchingWithOptions" > call never returns YES as expected. > > I then tried to run the scheme program in a separate thread (in that thread the call to (init-repl-server) in C would not have to return and would keep running). > [NSThread detachNewThreadSelector:@selector(initReplServer) toTarget:self withObject:nil]; > I could then connect to the repl server but all assignments in objects are ignored by the interface loop since they are done in a separate thread. I then had the idea to use objective-c blocks (kind of closures in the objective-c world). > > [[NSOperationQueue mainQueue] addOperationWithBlock:^{ object.slot=value; }]; > > This worked.... All the updates were now done in the GUI while working in the remote REPL. One day I tried to instantiate a UIWebView and the app crashed. UIWebView only works in the "main" thread. > > I don't like the idea to have the REPL-server and Scheme program in a separate thread. So I tried to put just the REPL-server in a separate thread and run my actual scheme program in the main thread. > In this setup I could connect to the remote REPL but all the variables in the Scheme world are not pointing to the right memory location so everything is scrambled. > > Is there a way out of this...? Can my program run in the main thread while still having a working remote REPL to debug it? > > > Thank you, > Francois Magnan > > _______________________________________________ > Gambit-iphone mailing list > Gambit-iphone(a)iro.umontreal.ca > https://webmail.iro.umontreal.ca/mailman/listinfo/gambit-iphone

2 1

slime (swank) and gambit
by Attila Lendvai 13 Fév '12

13 Fév '12

dear list, i'm a new hacker on board. i'm planning to use gambit on an embedded device. i have many years of CL experience, but i'm open for anything good. i have quite some background with slime and been using it and hacking on it for long years, so i'd like to use it with gambit. i've seen this mail, but noone answered: https://mercure.iro.umontreal.ca/pipermail/gambit-list/2011-August/005262.h… what is the status of swank-gambit? who is the current maintainer? where is its official repo? i've found two, but neither seems anything like 'official', but rather a random repo on github. https://github.com/jlongster/swank-gambit https://github.com/shortsightedsid/swank-gambit i'm planning to invest time into making it more useful, but i don't want to waste efforts on something that has already been done, just hidden from my google skills. any answers/hints are greatly appreciated, -- attila Notice the erosion of your (digital) freedom, and do something about it! PGP: 2FA1 A9DC 9C1E BA25 A59C 963F 5D5F 45C7 DFCD 0A39 OTR XMPP: 8647EEAC EA30FEEF E1B55146 573E52EE 21B1FF06

5 14

is this a bug in ffi?
by Álvaro Castro-Castilla 06 Fév '12

06 Fév '12

Hi! I open a new thread, because this is a deeper issue than the C++ enums conversion problem. When I declare this: (define CAIRO_FORMAT_RGB24 ((c-lambda () cairo-format-t "___result = CAIRO_FORMAT_RGB24;"))) or: (define CAIRO_FORMAT_RGB24 (c-lambda () cairo-format-t "___result = CAIRO_FORMAT_RGB24;")) and then call (CAIRO_FORMAT_RGB24) my program segfaults. It seems that just executing that c-lambda, returning an enum, fails. The enum is defined as: (c-define-type cairo-format-t "cairo_format_t") I don't understand why this segfaults: 1) I'm declaring the type 2) I'm returning the proper type. What's the problem? Best regards, Álvaro

5 15

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

Gambit-list Février 2012