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

embedding CUDA-C (for nVIDIA GPU usage) in Gambit?
by Jason E. Aten 14 Fév '11

14 Fév '11

Hi Gambit enthusiasts, I'm curious if anyone has played with generating CUDA kernels or CUDA from Gambit scheme code. I've learned some Lisp and some Scheme, but I'm still unclear how the "C embedding" in Gambit works. For example, if one needs to call nVidia's nvcc compiler to handle their dialect of C (CUDA-C == C with GPU extensions) instead of gcc (for example), will the Gambit compiler pass through the embedded C-with-extensions to the C compiler of choice? For that matter, the Thrust libraries bring an STL-like interface to creating and using CUDA kernels; is it possible to embed C++ code with templates directly into Gambit Scheme code? Happy to clarify if need be. Any advice or ideas (or experience) would be helpful. Thank you. Best regards, Jason -- Jason E. Aten, Ph.D.

3 7

Guidelines to implement a backend?
by Oleg Parashchenko 11 Fév '11

11 Fév '11

Hello, I've experimented with Scheme-to-PHP compilation using GVM (milestone announce below). Now I'd like to implement a complete backend. I need guildelines how to do it. Among questions: * Which primitives should be implemented? * How to generate the complete set of r5rs functions from the primitives? * How to integrate the backend to Gambit? Is it possible to select a backend from command line? * What is the recommended way to distribute a backend? Thanks! Now the announce: Gambit Scheme PHP backend, milestone 1: proof of concept http://github.com/olpa/schemevm/tree/milestone1 http://github.com/downloads/olpa/schemevm/gambit-php-20110208-milestone1.ta… The goal of this release is to mark the milestone 1. I wanted to understand the GVM and to check if compilation to PHP is possible. This is done. While the current gambit-php version is very limited (only a few primitives are partially implemented), it covers all the important functionality: * boot up: "Hello, World" example * recursion: factorial, fibonacci, ackermann * closures: function which return function which return function etc * continuations: basic return example, yin-yang puzzle Scheme code and generated PHP code: http://github.com/olpa/schemevm/tree/milestone1/step-by-step-examples The second use of this milestone release is a demostration how to start a backend. The package contains the minimal amount of code to compile the examples. Therefore, the code is much easier to understand then the code of a complete working backend. I coded straightforward. If I saw a way to solve a problem, I used this way without trying alternatives. In the development process "make it work, make it work correctly, make it work fast", I'm on the step zero "experiment if it would work". One of the consequences is that performance is poor. For example, Ackermann function A(3,9) is 100 times slowed as by gsi-script and 30 times slower as native PHP implementation. The output from yin-yang puzzle is 30 times slower as by gsi-script and 10 times slower as by Guile. However, I'm optimistic and think there is a lot of possibilties for optimization. The code is developed for PHP 4.4.8 and tested under PHP 3.0. -- Oleg Parashchenko olpa@ http://uucode.com/ http://uucode.com/blog/ XML, TeX, Python, Mac, Chess

4 5

getting up and running with swank-gambit
by Matthew Koichi Grimes 08 Fév '11

08 Fév '11

I tried downloading what seemed to be the latest version of swank-gambit at: https://github.com/shortsightedsid/swank-gambit Being a total lisp, scheme, and SLIME newbie, I'm having trouble getting off the ground with this. The swank-gambit README file reads: "Run swank-gambit.scm from the command line, and then type `M-x slime-connect ENT ENT ENT` to get a SLIME prompt." I tried running "gsi swank-gambit.scm" from a shell, but it just hangs, with no visible output. I suspect I'm grossly misunderstanding the instructions. Any help would be much appreciated. -- Matt

2 2

compile-file-to-c doesn't return on armv5tel
by Paul Wolneykien 08 Fév '11

08 Fév '11

Hi, I've encountered the following problem translating a Scheme file to C on an ARM platform: $ uname -msor Linux 2.6.35-sheeva-alt4 armv5tel GNU/Linux $ gsc -:daq- Gambit v4.5.3 > (compile-file-to-c "signal") ... ... The "compile-file-to-c" procedure never returns and CPU average load is 85% for the first minutes, then it increases up to 99%. The same module compiles fine on x86 taking a few number of seconds. The versions of the gsc and environmental programs on the x86 machine and on the ARM machine are the same (gambit v. 4.5.3). It is probably because of an error in the gsc ARM build, but I'm not sure. Is there any information on building Gambit on ARM platform? Thanks in advance, Paul.

2 1

How to implement call/cc in a GVM interpreter?
by Oleg Parashchenko 07 Fév '11

07 Fév '11

Hello, are there any documentation how to implement call/cc call on top of GVM? So far, looking at the use of the register 0 and jumps at the end of basic blocks, I optimistic concluded that GVM code is in the continuation-passing style. (Is it true?) Therefore, I tried a call/cc definition from "The 90 minute Scheme to C compiler": (define call/cc (lambda (k f) (f k (lambda (dummy-k result) (k result))))) A pseudocode for a GVM interpreter looks like: #<primitive ##call-with-current-continuation>: pc = reg1 reg1 = new continuation(reg0) goto pc A jump to the continuation is: pc = continuation.get_label() goto pc It nearly worked, but I don't know what to do with the stack. Consider an example: (define (f return) (return 2) 3) (display (f (lambda (x) x)))(newline) ; displays 3 (display (call-with-current-continuation f))(newline) ; displays 2 Here is the GVM code for the #<procedure ~#f>: #1 0 entry-point 1 () -1 = +0 -2 = +1 +1 = '2 +0 = #3 -3 = . -4 = . jump* 4 #2 A new stack frame is allocated. #2 4 jump 4 -2 1 Exit from ~#f due to the jump to the continuation. But: the stack frame still exists, it is not revoked. Therefore in jump 4 '#<primitive ##call-with-current-continuation> 1 #6 4 return-point +0 = #7 jump 4 '#<primitive display> 1 #7 4 return-point +0 = -1 jump* 4 #8 the register 0 is restored using the wrong frame. How to restore the stack correctly when jumping to a continuation? -- Oleg Parashchenko olpa@ http://uucode.com/ http://uucode.com/blog/ XML, TeX, Python, Mac, Chess

2 3

Reference implementation of SRFI-1 List Library
by Lewis 03 Fév '11

03 Fév '11

Greetings all, I downloaded and compiled the reference SRFI-1 implementation, http://srfi.schemers.org/srfi-1/srfi-1-reference.scm. I load the compiled version into gambit (after loading syntax case), but everytime it starts up I recieve these errors: lewis@1710:~$ gsc *** WARNING -- Variable ":optional" used in module "1-list-library.o1" is undefined *** WARNING -- Variable "let-optionals" used in module "1-list-library.o1" is undefined *** WARNING -- Variable "start" used in module "1-list-library.o1" is undefined. The only reference in the SRFI itself I can find is this ;;; The code has only these non-R4RS dependencies: ;;; A few calls to an ERROR procedure; ;;; Uses of the R5RS multiple-value procedure VALUES and the m-v binding ;;; RECEIVE macro (which isn't R5RS, but is a trivial macro). ;;; Many calls to a parameter-checking procedure check-arg: ;;; (define (check-arg pred val caller) ;;; (let lp ((val val)) ;;; (if (pred val) val (lp (error "Bad argument" val pred caller))))) ;;; A few uses of the LET-OPTIONAL and :OPTIONAL macros for parsing ;;; optional arguments. Does anyone know how I can get these macros in gambit? (all the list procedures i want appear to work, but the error messages are annoying.) Thanks, Lewis

5 8

bug 106
by REPLeffect 02 Fév '11

02 Fév '11

Bug 106 is marked as fixed in bugziilla, but I still get the same error when compiling against Gambit 4.6.0. Also, adding the macros to the gambit.h file by hand fixes the problem: http://www.iro.umontreal.ca/~gambit/bugzilla/show_bug.cgi?id=106 Also, it looks to me like the latest gambit.h.in in the git repository doesn't have the macros defined either. repleffect

1 2

Does anyone have a working Swank server for Gambit?
by Matt Lamari 02 Fév '11

02 Fév '11

I've downloaded https://github.com/jlongster/swank-gambit but it doesn't seem to work. I'm trying it on a mac swank:connection-info seems to have a problem, it's: :modules swank-modules instead of :modules ,swank-modules But after that, it crashes trying to load requirements from call to swank-require Swank-require seems to truncate the start of the filename. When I make it stop truncating, it looks for files such as "quote.scm" - and I don't know how to find those. If I disable the loading of the requirements, the connection just cuts out. I acknowledge I may be doing something wrong - I'd like a known working copy or setup to use as a baseline. Thanks, Matt

1 0

Take 2 : __cleanup() problem (OS X 10.6.6 / Gambit-C 4.6.0)
by David Dreisigmeyer 21 Jan '11

21 Jan '11

I tried using the shared library created from the modified test8 example, except I only called the functions from a C routine. That is, I didn't use Cython/Python. It looks like I'm getting the same problem here as when I tried using the shared library in Python: $ ./gambit_tester setup done Gambit-C : (+ 1 2) 3 Gambit-C result : 3 There should also be a "cleanup done" printed out after the call to ___cleanup (), but it doesn't seem to finish that routine. The code is attached. Do: $ make tester $ ./gambit_tester Thanks again. -Dave ****************************************** Here's the code written out also: ---------------------------------------------------------------------- Use server.scm and server.h from gambit/tests ---------------------------------------------------------------------- /* File: "client.c", Time-stamp: <2007-09-12 00:07:21 feeley> */ #include <stdio.h> #include <stdlib.h> #define ___VERSION 406000 #include "gambit.h" #include "server.h" #define SCHEME_LIBRARY_LINKER ____20_server__ ___BEGIN_C_LINKAGE extern ___mod_or_lnk SCHEME_LIBRARY_LINKER (___global_state_struct*); ___END_C_LINKAGE void gambit_setup( void ) { ___setup_params_struct setup_params; ___setup_params_reset (&setup_params); setup_params.version = ___VERSION; setup_params.linker = SCHEME_LIBRARY_LINKER; ___setup (&setup_params); } char * gambit_eval( char *in_str ) { char *temp; temp = eval_string (in_str); if (temp != 0){ printf ("%s\n", temp); } else { printf ("Error: temp == 0\n"); } ___release_string (temp); fflush ( stdout ); return temp; } void gambit_cleanup ( void ) { fflush (stdout); ___cleanup (); } ---------------------------------------------------------------------- /* gambit_tester.c */ #include "client.h" int main() { char *temp; gambit_setup(); printf("setup done\n"); printf ("Gambit-C : (+ 1 2)\n"); temp = gambit_eval("(+ 1 2)"); printf("Gambit-C result : %s\n", temp); ___release_string (temp); fflush(stdout); gambit_cleanup(); printf("cleanup done\n"); fflush(stdout); return 0; } ---------------------------------------------------------------------- C_COMPILER = /usr/bin/gcc-4.2 GAMBIT_GSC = gsc GAMBIT_INC_DIR = /usr/local/Gambit-C/include/ INC_DIR = . GAMBIT_LIB_DIR = /usr/local/Gambit-C/lib/ PYTHON = python PYTHON_INC = /opt/local/Library/Frameworks/Python.framework/Versions/2.7/include/python2.7 PYTHON_LIB1 = /opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib PYTHON_LIB2 = /opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/config all: extension standalone gsc tester gsc: $(GAMBIT_GSC) -link server.scm $(C_COMPILER) -I$(GAMBIT_INC_DIR) -I$(INC_DIR) -Wno-unused -O1 -fno-math-errno -fschedule-insns2 -fno-trapping-math -fno-strict-aliasing -fwrapv -fomit-frame-pointer -fPIC -fno-common -mieee-fp -c -o client.o client.c $(C_COMPILER) -I$(GAMBIT_INC_DIR) -I$(INC_DIR) -Wno-unused -O1 -fno-math-errno -fschedule-insns2 -fno-trapping-math -fno-strict-aliasing -fwrapv -fomit-frame-pointer -fPIC -fno-common -mieee-fp -c -o server.o server.c -D___LIBRARY $(C_COMPILER) -I$(GAMBIT_INC_DIR) -I$(INC_DIR) -Wno-unused -O1 -fno-math-errno -fschedule-insns2 -fno-trapping-math -fno-strict-aliasing -fwrapv -fomit-frame-pointer -fPIC -fno-common -mieee-fp -c -o server_.o server_.c -D___LIBRARY $(C_COMPILER) -shared -I$(GAMBIT_INC_DIR) -I$(INC_DIR) -L$(GAMBIT_LIB_DIR) -lgambc -Wno-unused -O1 -fno-math-errno -fschedule-insns2 -fno-trapping-math -fno-strict-aliasing -fwrapv -fomit-frame-pointer -fno-common -mieee-fp -o libclient.so client.o server.o server_.o tester: gsc $(C_COMPILER) gambit_tester.c -L. -lclient -I/usr/local/Gambit-C/include/ -o gambit_tester extension: gsc # ======= Cython extension: $(PYTHON) server_setup.py build_ext --inplace standalone: gsc # ======= Cython standalone: $(PYTHON) /opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/Cython-0.14-py2.7-macosx-10.6-x86_64.egg/cython.py --embed server_setup.pyx $(C_COMPILER) -c server_setup.c -I$(PYTHON_INC) -I$(GAMBIT_INC_DIR) -I$(INC_DIR) $(C_COMPILER) -o server_setup server_setup.o client.o server.o server_.o -L$(GAMBIT_LIB_DIR) -lgambc -L$(PYTHON_LIB1) -L$(PYTHON_LIB2) -lpython2.7 -ldl -framework CoreFoundation clean: rm -rf gambit.so libclient.so *.o server.c server_.c server_setup.c server_setup.o server_setup build/ gambit_tester ----------------------------------------------------------------------

3 12

Re: [gambit-list] Xlib
by David Bridgham 17 Jan '11

17 Jan '11

Good idea. Turns out that there are already printf's in there, I just need to define debug_free. And doing that . . . it's XFree_Screen(). [ . . . ] release_rc_XColor(0xfd7900) release_rc_XGCValues(0xfd8950) release_rc_XColor(0xfd7640) release_rc_XGCValues(0xfd7790) release_rc_XColor(0xfd53f0) release_rc_XGCValues(0xfd5850) XFree_Screen(0xfc8900) *** glibc detected *** ../../gsi/gsi: munmap_chunk(): invalid pointer: 0x0000000000fc8900 *** ======= Backtrace: ========= /lib/libc.so.6(+0x71ad6)[0x2b7e851c1ad6] /usr/lib/libX11.so.6(XFree+0x9)[0x2b7e85b60ec9] /home/dab/src/gambc-v4_6_0/examples/Xlib-simple/Xlib.o1(XFree_Screen+0x2f)[0x2b7e854d0d4b] ../../gsi/gsi(___release_foreign+0x4d)[0x4c6832] ../../gsi/gsi(___garbage_collect+0x9b0)[0x4c42f9] ../../gsi/gsi[0x4deedd] ../../gsi/gsi(___call+0x104)[0x4c10f3] ../../gsi/gsi(___setup+0xf47)[0x4c20bb] ../../gsi/gsi(___main+0x9c5)[0x4d6eba] ../../gsi/gsi(___main_char+0x66)[0x4cb32d] ../../gsi/gsi(main+0x15)[0x4bf8b5] /lib/libc.so.6(__libc_start_main+0xfd)[0x2b7e8516ec4d] ../../gsi/gsi[0x4bd369] ======= Memory map: ======== [ . . .] To verify, commenting out the XFree(p) call in XFree_Screen 'fixes' the problem too. However, while trying this from a different machine this morning I came across a rather strange effect. If I'm running it to a remote X display, it doesn't crash. Only crashes if the bounce program is running on the same machine as my display. -Dave On 01/14/2011 05:03 AM, Mikael wrote: > For the list: Can you maybe add a printf("ENTERED release function XYZ > for obj %l!\n",[the pointer of the object to be released]); at the > beginning and printf("DONE w release function XYZ!\n"); after release > was made, to those release functions, that could help us find exactly > what didn't work. > > Kind regards

2 5