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

gtk-server
by William James 10 Avr '11

10 Avr '11

There's no Gambit example here: http://www.turtle.dds.nl/gtk-server/examples.html This seems to work: ;; NOTE: requires srfi-13 for "string-join". (define *gtk-port* (open-process "gtk-server -stdin")) (thread-sleep! 1) (define (gtk-command . items) (let ((strings (map (lambda (x) (if (string? x) x (object->string x))) items))) (display (string-join strings " ") *gtk-port*) (newline *gtk-port*) (force-output *gtk-port*) (read-line *gtk-port*))) (gtk-command "gtk_init NULL NULL") (define *win* (gtk-command "gtk_window_new 0")) (gtk-command "gtk_window_set_title" win "\"Scheme GTK-server demo via stdin\"") (gtk-command "gtk_window_set_default_size" *win* 400 200) (gtk-command "gtk_window_set_position" *win* 1) (define *tbl* (gtk-command "gtk_table_new 10 10 1")) (gtk-command "gtk_container_add" *win* *tbl*) (define *but* (gtk-command "gtk_button_new_with_label \"Click to Quit\"")) (gtk-command "gtk_table_attach_defaults" *tbl* *but* 5 9 5 9) (gtk-command "gtk_widget_show_all" win) (let loop () (let ((event (gtk-command "gtk_server_callback WAIT"))) (if (not (member event (list *win* *but*))) (loop)))) (display "gtk_server_exit" *gtk-port*) (newline *gtk-port*) (force-output *gtk-port*) (close-port *gtk-port*)

1 0

Possible bug in define-macro
by William James 10 Avr '11

10 Avr '11

Gambit v4.6.1 > (include "~/srfi-1-reference.scm") > (member 2 (iota 5) =) (2 3 4) > (define-macro (pushnew item lst . test) (let ((== (gensym))) `(let ((,== ,(if (null? test) equal? (car test)))) (if (not (member ,item ,lst ,==)) (set! ,lst (cons ,item ,lst)))))) > (define flist '(2 3 5)) > (pushnew 5 flist) *** ERROR IN (console)(a)21.1 -- Ill-formed expression > This macro works properly in Guile (and Bigloo): guile> (load "test-pushnew.scm") (2.0 8 2 3 5) where test-pushnew.scm is (define-macro (pushnew item lst . test) (let ((== (gensym))) `(let ((,== ,(if (null? test) equal? (car test)))) (if (not (member ,item ,lst ,==)) (set! ,lst (cons ,item ,lst)))))) (define flist '(2 3 5)) (pushnew 5 flist) (pushnew 8 flist) (pushnew 2.0 flist) (pushnew 3.0 flist =) (write flist) (newline)

4 5

0mq with Gambit
by Feng Hou 10 Avr '11

10 Avr '11

Hello everyone, Gambit has great concurrency support by green-thread and no-blocking I/O scheduling. However, they are only able to use one native thread on multicore hardware. I have noticed some wish list on wiki for multicore/multiprocessing concurrency support. I'm wondering whether 0MQ ( http://www.zeromq.org/) can be used as substance for Gambit to build such capabilities. My thoughts are, -- Not just a FFI binding. -- Use it as message passing broker for multicore and distributed concurrency. -- Share nothing between the GVM thread and other in-process native threads (doing long CPU bound computation or blocking I/O). -- How to integrate 0MQ inter-thread transport to gambit green-thread scheduler without blocking it? -- Would it be possible to bind 0MQ inter-thread socket to gambit mailbox? -- How to integrate 0MQ I/O event poller with gambit I/O loop? -- Would it be better to expose 0MQ IPC/TCP/PGM socket types as Gambit Port objects? I realized they were way beyond my knowledge and skill level to implement (some may not even make sense, please correct me). Nevertheless, just want to see if others have similar thoughts or needs. Cheers, Feng Hou

4 8

reading a serialized value from an offset in a file
by mikel evins 10 Avr '11

10 Avr '11

Marc, Suppose I have a file containing data serialized by calling object->u8vector and then written to a file. Suppose, further, that I happen to know that an object of interest to me starts at a specific byte offset within the file. What's the right way to read that object from the file? Of course, I could read the whole file and convert its contents to Scheme objects, continuing until I get the one I want. Suppose, though, that the file might grow very large, and I want to be able to read just a particular indicated object from a particular offset. The idea, by the way, is that I'm going to serialize values into a log-structured file and use an index to fetch them back again on-demand. If I serialize the values using object->u8vector, then it's very easy to deserialize them using u8vector->object, provided that I have the correct sequence of bytes to feed to u8vector->object. Given that my index is correct, I have the start of the bytes that make up the object I'm trying to read. Now what's the right way to know how many bytes to read into a u8vector that I can then pass to u8vector->object? It would be even cooler if there were a sort of stream version of u8vector->object, so that I could open the file, seek to the indicated offset, and then tell u8vector->object to read from the bytes starting at that offset--but I don't particularly expect to find that such a facility exists. No matter; if I know how to infer the bytecount of a valid serialized value that starts at a given offset, then I'm home free. Thanks, --me

1 0

Failed to build Gambit v4.6.0 on i586 (builds fine on x86-64)
by Paul Wolneykien 08 Avr '11

08 Avr '11

Hi! Trying to build Gambit v4.6.0 on i586 with a bootstrap compiler I've got the following error: LD_LIBRARY_PATH=../lib:../gsi:../gsc: ../gsc-comp -:d-,~~bin=../bin,~~lib=../lib,~~include=../include -f -c -check _num.scm make: *** [_num.c] Segmentation fault I try to build Gambit v4.6.0 from the git tree (http://www.iro.umontreal.ca/~gambit/repo/gambit.git) using gsc v4.5.3 that was built earlier by the same procedure explained below. The same build procedure if running on x86-64 architecture compiles Gambit fine from the same v4.6.0 sources. About the build process in more detail. First, the v4.5.3 Gambit compiler are copied from /usr/bin/gsc to gsc-comp in the directory where the 4.6.0 bootstrap version sources are deployed. Some information on it: /usr/bin/gsc --- $ ls -l /usr/bin/gsc -rwxr-xr-x 1 rooter rooter 46380 Apr 7 20:05 /usr/bin/gsc $ /usr/bin/gsc -v v4.5.3 20091102023345 i586-alt-linux-gnu "./configure --build=i586-alt-linux --host=i586-alt-linux --prefix=/usr --exec-prefix=/usr --bindir=/usr/bin --sbindir=/usr/sbin --sysconfdir=/etc --datadir=/usr/share --includedir=/usr/include --libdir=/usr/lib --libexecdir=/usr/lib --localstatedir=/var/lib --sharedstatedir=/usr/com --mandir=/usr/share/man --infodir=/usr/share/info --disable-dependency-tracking --without-included-gettext --enable-single-host --enable-shared --disable-absolute-shared-libs" $ ldd /usr/bin/gsc libgambcgsc.so => /usr/lib/libgambcgsc.so (0xb7ca9000) libgambc.so => /usr/lib/libgambc.so (0xb78eb000) libc.so.6 => /lib/libc.so.6 (0xb7787000) libutil.so.1 => /lib/libutil.so.1 (0xb7783000) libdl.so.2 => /lib/libdl.so.2 (0xb777d000) libm.so.6 => /lib/libm.so.6 (0xb7753000) /lib/ld-linux.so.2 (0xb7f4b000) --- Then, the bootstrap version sources are configured with the use of just --enable-single-host option in order to build a statically linked bootstrap compiler: ./configure --enable-single-host Then the bootstrap compilation started with make bootstrap The resulting gsc is overwritten to ./gsc-comp. Some information on it: The bootstrap built from the bootstrap tree [a56942cf9d4d4a57512edc0f1070baf7bd41cb4f] --- $ ls -l ./gsc-comp -rwxr-xr-x 1 builder builder 15383359 Apr 8 15:00 ./gsc-comp $ ./gsc-comp -v v4.5.3 20100107170955 i586-alt-linux-gnu "./configure --build=i586-alt-linux --host=i586-alt-linux --prefix=/usr --exec-prefix=/usr --bindir=/usr/bin --sbindir=/usr/sbin --sysconfdir=/etc --datadir=/usr/share --includedir=/usr/include --libdir=/usr/lib --libexecdir=/usr/lib --localstatedir=/var/lib --sharedstatedir=/usr/com --mandir=/usr/share/man --infodir=/usr/share/info --disable-dependency-tracking --without-included-gettext --enable-single-host" $ ldd ./gsc-comp libutil.so.1 => /lib/libutil.so.1 (0xb7f68000) libdl.so.2 => /lib/libdl.so.2 (0xb7f63000) libm.so.6 => /lib/libm.so.6 (0xb7f39000) libc.so.6 => /lib/libc.so.6 (0xb7dd5000) /lib/ld-linux.so.2 (0xb7f70000) --- Then the freshly built bootstrap compiler file gsc-comp is copied to the separate directory where 4.6.0 release version sources are deployed. The sources are then configured with the use of just --enable-single-host option in order to build a statically linked bootstrap compiler: ./configure --enable-single-host Then the bootstrap compilation is started with make bootstrap Note, that because the release version sources are deployed in the separate directory, there is no need to run `make bootclean`, is it? The resulting gsc is overwritten to ./gsc-comp. Some information on it: The bootstrap built from the release tree [3bdc64fb33dcdd1792d4c899c861c317aa0feabb] --- $ ls -l ./gsc-comp -rwxr-xr-x 1 builder builder 15401399 Apr 8 15:03 ./gsc-comp $ ./gsc-comp -v v4.6.0 20100610205958 i586-alt-linux-gnu "./configure --build=i586-alt-linux --host=i586-alt-linux --prefix=/usr --exec-prefix=/usr --bindir=/usr/bin --sbindir=/usr/sbin --sysconfdir=/etc --datadir=/usr/share --includedir=/usr/include --libdir=/usr/lib --libexecdir=/usr/lib --localstatedir=/var/lib --sharedstatedir=/usr/com --mandir=/usr/share/man --infodir=/usr/share/info --disable-dependency-tracking --without-included-gettext --enable-single-host" $ ldd ./gsc-comp libutil.so.1 => /lib/libutil.so.1 (0xb7f2c000) libdl.so.2 => /lib/libdl.so.2 (0xb7f27000) libm.so.6 => /lib/libm.so.6 (0xb7efd000) libc.so.6 => /lib/libc.so.6 (0xb7d99000) /lib/ld-linux.so.2 (0xb7f34000) --- Then the release version tree is cleaned using make realclean and configured again with more options specified in order to build a dynamically linked set of programs: ./configure --enable-single-host --enable-shared --disable-absolute-shared-libs Then an attempt is made to compile the final versions of the programs. On x86-64 (64-bit mode) it builds fine, but it fails to build on the same machine in an i586 environment. Note, that Gambit v4.5.3 (used as the first available compiler in this session) builds fine on the top of v4.5.2 by the same three-stage build process and all of the tests (cd tests; make check) are passed successfully. The compilation of the final 4.6.0 version fails in the lib subdirectory: Try to build a shared-lib version from the release tree [3bdc64fb33dcdd1792d4c899c861c317aa0feabb] --- ... LD_LIBRARY_PATH=../lib:../gsi:../gsc: ../gsc-comp -:d-,~~bin=../bin,~~lib=../lib,~~include=../include -f -c -check _num.scm make: *** [_num.c] Segmentation fault --- I've tried to run the same command in the debugger: Run it within gdb --- LD_LIBRARY_PATH=../lib:../gsi:../gsc: gdb --args ../gsc-comp -:d-,~~bin=../bin,~~lib=../lib,~~include=../include -f -c -check _num.scm ... Starting program: /usr/src/RPM/BUILD/gambit-4.6.0/gambit-4.6.0/gsc-comp -:d-,\~\~bin=../bin,\~\~lib=../lib,\~\~include=../include -f -c -check _num.scm Program received signal SIGSEGV, Segmentation fault. mark_array (start=<value optimized out>, n=4) at mem.c:2108 2108 head = body[-1]; I will be glad to see your comments on the build process described above and about any way I could debug or workaround that error. TIA, Paul.

1 0

Fwd: 0mq with Gambit
by Feng Hou 07 Avr '11

07 Avr '11

---------- Forwarded message ---------- From: Feng Hou <houfen(a)gmail.com> Date: Thu, Apr 7, 2011 at 7:34 PM Subject: Re: [gambit-list] 0mq with Gambit To: "Jason E. Aten" <j.e.aten(a)gmail.com> On Thu, Apr 7, 2011 at 6:39 PM, Jason E. Aten <j.e.aten(a)gmail.com> wrote: > > > On Thu, Apr 7, 2011 at 4:50 PM, Feng Hou <houfen(a)gmail.com> wrote: > >> >> >> On Wed, Apr 6, 2011 at 12:17 PM, Jason E. Aten <j.e.aten(a)gmail.com>wrote: >> >>> On Wed, Apr 6, 2011 at 8:13 AM, Marc Feeley <feeley(a)iro.umontreal.ca>wrote: >>> >>>> >>>> On 2011-04-03, at 11:04 PM, Feng Hou wrote: >>>> >>>> > Hello everyone, >>>> > >>>> > Gambit has great concurrency support by green-thread and no-blocking >>>> I/O scheduling. However, they are only able to use one native thread on >>>> multicore hardware. I have noticed some wish list on wiki for >>>> multicore/multiprocessing concurrency support. I'm wondering whether 0MQ ( >>>> http://www.zeromq.org/) can be used as substance for Gambit to build >>>> such capabilities. >>>> > >>>> > My thoughts are, >>>> > >>>> > -- Not just a FFI binding. >>>> > -- Use it as message passing broker for multicore and distributed >>>> concurrency. >>>> > -- Share nothing between the GVM thread and other in-process native >>>> threads (doing long CPU bound computation or blocking I/O). >>>> > -- How to integrate 0MQ inter-thread transport to gambit green-thread >>>> scheduler without blocking it? >>>> > -- Would it be possible to bind 0MQ inter-thread socket to gambit >>>> mailbox? >>>> > -- How to integrate 0MQ I/O event poller with gambit I/O loop? >>>> > -- Would it be better to expose 0MQ IPC/TCP/PGM socket types as Gambit >>>> Port objects? >>>> > >>>> > I realized they were way beyond my knowledge and skill level to >>>> implement (some may not even make sense, please correct me). Nevertheless, >>>> just want to see if others have similar thoughts or needs. >>>> > >>>> > Cheers, >>>> > Feng Hou >>>> >>>> I quickly read the 0MQ docs and it seems interesting. I can give >>>> pointers to whoever wants to implement them into Gambit. >>>> >>>> Marc >>> >>> >>> I'd be up for contributing on this. ZMQ and Gambit together would be >>> quite sweet on multicore and as the basis for very scalable distributed >>> systems. >>> >>> As an aside, the last missing piece would be using Google's Protocol >>> Buffers (PB) for very efficient serialization. I say this in reference to >>> the comments in the Termite paper that the new serialization in Gambit was >>> the only bottleneck that kept Termite from beating Erlang outright in all >>> categories. By the way, has the serialization situation improved? If so >>> then perhaps PB is not necessary. But PB would also give one really nice >>> inter-language interoperability, since PB bindings are available from just >>> about any language (sadly except Scheme; but perhaps the Common Lisp >>> bindings could be ported without much trouble) at this point. >>> >>> But back to ZMQ. It would seem to be more general, as Feng suggests, to >>> be able to use ZMQ from Gambit rather than just Termite. I say this because >>> if one could use ZMQ from Gambit, then there would be no need play elaborate >>> games to get mutable state, (or variables that actually vary =) ; i.e. >>> without needing to do the gen_server trick/(section 4.6 of the Termite paper >>> workaround) when you actually need mutable variables. Unfortunately, I work >>> with big enough data, that I really do need mutable variables. >>> >>> So assuming that one wants to be able to use ZMQ in Gambit (which I >>> would!), I'd be very glad to hear any advice on how to do that. >>> >>> Jason >>> >> >> I'm glad to hear so much interest and help offered. I've been playing >> around a toy binding, and reading 0mq source. I'd like to share a few more >> concrete ideas. >> >> 0mq socket is a concurrent device, rather than an I/O device. It's very >> lightweight, essentially a concurrent in-memory queue. Hundreds of thousands >> to the same tcp end-point would only consume just one tcp connection. This >> seems a perfect fit to gambit green-thread model. Pulling socket send/recv >> in noblock mode loop is equivalent to spinning on memory CAS+fance of a >> pointer (this appears to be how zmq implements it). 0mq also provides a >> timer facility, but I believe it'd block gambit thread scheduler. Instead, >> gambit thread-yield!/thread-sleep! can be used for scheduling noblock >> send/recv pulling. We can have thousands of green-threads pulling on >> thousands of 0mq sockets concurrently. This can be done fairly >> straightforward in user land. Ideally, it'd be nice to just write, >> >> (write u8vector a-zmq-port) >> >> (read u8vector a-zmq-port timeout: 10) >> >> All looping/retry/yield/sleep can happen in gambit scheduler (need >> continuation magic?). Even nicer would be able to bind sockets to thread >> mailboxes so messages are pumped into mailboxes on receiving automatically. >> So we can use Erlang/Termite style receive loop, which gambit already >> adopted for local thread message passing (Though I'm not too keen on sending >> messages to remote threads, i.e. erlang Pid model. IMO, It's too tightly >> coupled in distributed environment, where 0mq subject-oriented message >> passing is better architecturally). >> > Hi Feng, > > I'm glad to hear about your experiments and ideas. Could elaborate on the > last comment that I've quoted above, re "not too keen on sending messages to > remote threads." I think I must be misunderstanding something, because the > whole point of ZMQ is to send messages to remote threads. I'm also not > clear what you mean by the terms subject-oriented message vs. too tightly > coupled. Feel free to elaborate on these, if you can. > > Thank you. > > Best regards, > > Jason > > Hi Jason, I meant to send messages to a specific thread _identity_. A receiver thread has to expose its identity (a pid or tid) on network in order to provide a service. Sender thread has to get hold of specific receiver thread's identity to ask for a service - tightly coupled (not much different from distributed object).This is useful model within local process, where shared state allow them to find each other easily. More important, message delivery is guaranteed, and peer errors can be handled easily. However, these properties become much difficult in distributed network. An architecture works better in distributed environment would be any threads in a cluster of gambit process nodes that can offer data or service on a subject just bind himself to a well known url (e.g. tcp://weather.com/va/reston/today, or pgm://stocktick.com/apple) can be one, two, or ten threads, they can come and go anytime as long as someone else take over their duty. Any threads consume services or data just send request message to well known urls, or simply bind their mailbox to them. Yes, ultimately 0mq delivers messages to gambit thread, but it decouples sender and receiver's identity. Hope this make some sense. Cheers, - Feng

1 1

A proof of concept for (+ GTK+ gambit)
by Diogo F. S. Ramos 07 Avr '11

07 Avr '11

I would like to thank you for the help and time that you've gave to me. I really appreciate it. To show that it has not be in vain, I was able to, more or less, reproduce the GTK+ tutorial [0] using just scheme with an .o1, and from the REPL. The code for it is: ;;;;;;;; (let ((win (make-gtk-window 0)) (bt (make-gtk-button "hello, world"))) (connect win "delete-event" (lambda () (display "delete event occurred") (newline) #f)) (connect win "destroy" (lambda () (gtk-main-quit))) (connect bt "clicked" (lambda () (display "hello, world"))) (connect bt "clicked" (lambda () (gtk-main-quit))) (add win bt) (show win) (show bt) (gtk-main)) ;;;;;;;; I've not cheated too much and overall it's really instantiating objects and connecting signals (using my proxy hack). The purpose of this is not to create a whole binding, not even 1/7 of it, but just the bare minimum to have a working GUI. [0] http://developer.gnome.org/gtk-tutorial/stable/c39.html#SEC-HELLOWORLD -- Diogo F. S. Ramos

1 0

FFI and Callbacks
by Diogo F. S. Ramos 06 Avr '11

06 Avr '11

The last thread [0] got me thinking about a problem that I'm having with registering callbacks. I'm still in the quest of making a GTK+ application and I'm jumping between designs. GTK+ have the following strategy: If one wants to call a function when, say, a button is clicked, one needs to register this function, which have a specific signature, with the following function: g_signal_connect(button, "clicked", func, data); func is the callback to be called and data is a void* that will be passed to func. My problem is: how do I allow registering scheme callbacks? I don't have a clear idea on how to convert a lambda to a C function or even how to pass it. Also, when running my .o1 with the interpreter, I don't have a representation of a C function and I can't use (c-define) to make one. My present idea is the following: At the moment I instantiate a GtkButton (button) I also register a proxy "clicked" callback. This proxy procedure will read a list and execute the procedures listed there. So, when I want to register a new callback I don't actually register it at the C level, but I append it to the proxy's list so, when I click the button, the proxy is called and all the procedures listed all called. What do you think? Is there a way to do it without the proxy? [0] http://article.gmane.org/gmane.lisp.scheme.gambit/4948 -- Diogo F. S. Ramos

1 0

cmake for projects written in gambit?
by Matthew Koichi Grimes 06 Avr '11

06 Avr '11

Has anybody used CMake as a build system for their Gambit projects? I'm not talking about building Gambit itself, but rather building projects that are written in Gambit. If so, could I see your CMakeList bulid files? I would also be interested in other build systems' makefiles (make, ant, etc), if people are wiling to share, or point me to an open-source project written in Gambit that I could download. Best, -- Matt

2 4

dlopen -- is there a simpler way?
by Jason E. Aten 06 Avr '11

06 Avr '11

Dear Gambit enthusiasts, I think I figured out how to use dlopen to run functions from Gambit that live in dynamically loaded libraries (plugins); my best to date is below. But I'm not quite happy with it--because it's kind of elaborate. That is, I couldn't figure out how to avoid some of the boiler plate below. Perhaps there is a shorter way? So my question for Gambit enthusiasts is: Is there a cleaner way to do this--to run functions from plugin libraries? i.e. without having to pre-declare call_plugin_print8 and call_print8. What if you wanted to make such a call after inspecting a new library at runtime? Many thanks! Gambit rocks! Thanks again for such a great system. - Jason ;;;;;;;;;;;;;;; file: libex.cpp ;;;;;;;;;;;; ; ; a simple library of one function for ; testing/development of plugin loading ; #include <stdio.h> extern "C" int print8() { printf("\n In print8() : returning 8\n"); return 8; } ;;;;;;;;;;;;;;; file: libex.h ;;;;;;;;;;;; #ifndef LIBEX_H #define LIBEX_H int print8(); #endif ;;;;;;;;;;;;;;; file: dlopen.scm ;;;;;;;;;;;; ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; ;; dlopen.scm : plugins in Gambit ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; ; compile and link with: ; ; gsc -link dlopen.scm ; gcc -I/usr/local/Gambit-C/include -L/usr/local/Gambit-C/lib dlopen.c dlopen_.c -lgambc -lm -lutil -ldl -o dlopen (c-declare #<<c-declare-end #include <stdio.h> #include <stdlib.h> #include <dlfcn.h> #include "libex.h" /* simple wrapper to do runtime plugin function calls (call into .so library) */ int call_plugin_print8(void* handle) { char *error; int (*my_func)(); // my_func = (int (*)()) dlsym(handle,"print8"); *(void **) (&my_func) = dlsym(handle, "print8"); if ((error = dlerror()) != NULL) { fprintf(stderr, "%s\n", error); exit(EXIT_FAILURE); } return (*my_func)(); } c-declare-end ) ; from dlfcn.h ; see man dlopen ; ; void * dlopen(const char *filename, int flag); ; char * dlerror(void); ; void * dlsym(void *handle, const char *symbol); ; int dlclose(void *handle); ; ; translated into Gambit-C FFI: ; (define dlopen (c-lambda (nonnull-char-string int32) (pointer void) "dlopen")) (define dlerror (c-lambda () char-string "dlerror")) (define dlsym (c-lambda ((pointer void) nonnull-char-string) (pointer void) "dlsym")) (define dlclose (c-lambda ((pointer void)) int32 "dlclose")) ;; hmm is there a defconstant in scheme that we could use for these C header constants? ;; for now generate a function of the same name to get us the constant int value we need. (define RTLD_LAZY (c-lambda () int32 "___result = RTLD_LAZY;")) ; declare the type of the foreign function (define call_print8 (c-lambda ((pointer void)) int32 "call_plugin_print8")) (let* ((h (dlopen "/home/jaten/dj/gamb/libex.so" (RTLD_LAZY))) (res (dlsym h "print8"))) (if (null? res) (error "could not locate symbol 'print8' in the plugin library!")) (pretty-print (list "calling print8() gives: " (call_print8 h))) (pretty-print res) (pretty-print h) (pretty-print (list "The value of the constant RTLD_LAZY is: " (RTLD_LAZY)))) ;; output: ;;; $ ./dlopen ; ; In print8() : returning 8 ;8 ;#<void* #2 0x7fdd20c1868c> ;#<void* #3 0x22cd7b0> ;("The value of the constant RTLD_LAZY is: " 1) ;;;;;;;;;;;;;;; file: Makefile ;;;;;;;;;;;; all: gsc -link dlopen.scm gcc -I/usr/local/Gambit-C/include -L/usr/local/Gambit-C/lib dlopen.c dlopen_.c -lgambc -lm -lutil -ldl -o dlopen g++ -c libex.cpp -fpic -o libex.o g++ -shared libex.o -o libex.so @echo "testing ./dlopen" ./dlopen clean: rm -f dlopen dlopen_.c dlopen.c dlopen.o1 dlopen.o2 *~ *.o *.so

2 1