Gambit-list Février 2005

gambit-list@iro.umontreal.ca

12 participants
22 discussions

Re: file-seek in Gambit.
by Marc Feeley 18 Sep '05

18 Sep '05

> I can't seem to find a way to seek in and get the position in files > using Gambit (4beta11). Wouldn't this be a handy feature? Yes, I have been planing this for a while and have just completed the implementation and documentation. Here it is: @deffn procedure input-port-byte-position @var{port} @r{[}@var{position} @r{[}@var{whence}@r{]}@r{]} @deffnx procedure output-port-byte-position @var{port} @r{[}@var{position} @r{[}@var{whence}@r{]}@r{]} When called with a single argument these procedures return the byte position where the next I/O operation would take place in the file attached to the given @var{port} (relative to the beginning of the file). When called with two or three arguments, the byte position for subsequent I/O operations on the given @var{port} is changed to @var{position}, which must be an exact integer. When @var{whence} is omitted or is 0, the @var{position} is relative to the beginning of the file. When @var{whence} is 1, the @var{position} is relative to the current byte position of the file. When @var{whence} is 2, the @var{position} is relative to the end of the file. The return value is the new byte position. On most operating systems the byte position for reading and writing of a given bidirectional port are the same. When @code{input-port-byte-position} is called to change the byte position of an input-port, all input buffers will be flushed so that the next byte read will be the one at the given position. When @code{output-port-byte-position} is called to change the byte position of an output-port, there is an implicit call to @code{force-output} before the position is changed. For example: @smallexample > @b{(define p @r{@i{; p is an input-output-port}} (open-file '(path: "test" char-encoding: latin1 create: maybe)))} > @b{(list (input-port-byte-position p) (output-port-byte-position p))} (0 0) > @b{(display "abcdefghij\n" p)} > @b{(list (input-port-byte-position p) (output-port-byte-position p))} (0 0) > @b{(force-output p)} > @b{(list (input-port-byte-position p) (output-port-byte-position p))} (11 11) > @b{(input-port-byte-position p 2)} 2 > @b{(list (input-port-byte-position p) (output-port-byte-position p))} (2 2) > @b{(peek-char p)} #\c > @b{(list (input-port-byte-position p) (output-port-byte-position p))} (11 11) > @b{(output-port-byte-position p -7 2)} 4 > @b{(list (input-port-byte-position p) (output-port-byte-position p))} (4 4) > @b{(write-char #\! p)} > @b{(list (input-port-byte-position p) (output-port-byte-position p))} (4 4) > @b{(force-output p)} > @b{(list (input-port-byte-position p) (output-port-byte-position p))} (5 5) > @b{(input-port-byte-position p 1)} 1 > @b{(read p)} bcd!fghij @end smallexample @end deffn > Also, while I'm making suggestions: Have you thought about > implementing a simple package system, for example something like > Chicken Scheme's eggs[3]? No. I'm not saying this wouldn't be useful, just that I haven't perceived a need for it yet. There's really nothing to change in Gambit itself to implement a package system like the one Chicken uses because Gambit's installation directory (/usr/local/Gambit-C) can be used for this. The subdirectory /usr/local/Gambit-C/package would store the installed packages, and the programs would use these packages like this: (include "~~/package/Xlib.scm") (include "~~/package/arrays.scm") ... or (load "~~/package/foo") The system extension file (~~/gambcext) could also be modified for the packages that need to permanently extend Gambit (this file is loaded whenever the interpreter is started). The most tedious in all of this is to implement the package management tool that installs the packages, compiles them if needed, checks for the latest version, checks package dependencies, etc. If you want to contribute such a tool please be my guest. What I can do is help you out in the design and host the packages that people contribute on Gambit's web site. Of course some of this work may have to be duplicated when the R6RS module system comes out... Marc

2 2

running remote jobs with `time'
by Bill Richter 21 Mai '05

21 Mai '05

I haven't been able to run niced background jobs, and I think I finally know why, because `time' wants to print to the console which no longer exists. But I'm not quite there yet: The Gambit manual says `time' uses the interaction channel: - special form: time EXPR The `time' special form evaluates EXPR and returns the result. As a side effect it displays a message on the interaction channel which indicates how long the evaluation took (in real time and cpu time), how much time was spent in the garbage collector, how much memory was allocated during the evaluation and how many minor and major page faults occured (0 is reported if not running under UNIX). Now the node "Runtime options" says I can change the interaction channel: Both `gsi' and `gsc' as well as executable programs compiled and linked using `gsc' take a `-:' option which supplies parameters to the runtime system. `-' The REPL interaction channel will be standard input and standard output. I have a 1-line file "6.scm" (time (pretty-print 6)) So to me, the manual says that % gsi -:- 6.scm > six-out should print the time info as well as the output 6 to the file "six-out". But it doesn't: (banach)PolyTree> gsi -:- 6.scm > six (time (pretty-print 6)) 0 ms real time 0 ms cpu time (0 user, 0 system) no collections 104 bytes allocated no minor faults 5 major faults (banach)PolyTree> more six-out 6 Now it doesn't make much difference where the time info goes, unless I'm running a job overnight, nice-ed in the bg. These nice-ed bg jobs of mine hang, run for days, and I think because they want to print to the console, which no longer exists. So people must know how to solve this problem. Help!

4 6

statprof -- a statistical profiler for Gambit-C 4.0
by Guillaume Germain 27 Avr '05

27 Avr '05

With some help from Marc Feeley I have implemented a simple statistical profiler for Gambit. It is available at the following address: http://www.iro.umontreal.ca/~germaing/statprof.html Here's an output example: http://www.iro.umontreal.ca/~germaing/ring.scm.html It's not perfect and was put together somewhat quickly, but I think it can be useful. Guillaume

3 3

RE: [gambit-list] Linking to C++ problems
by Dan Hristodorescu 23 Fév '05

23 Fév '05

Hi Marc, I've done more investigation in the DLL problem and I've tried a lot of things, different compilation switches but I cannot make it work. I would really appreciate any suggestion you might have. It goes like this: Using the g++ (mingw) compiler I compiled both the program and Gambit runtime. If I replace the Scheme call with the equivalent C implementation (without going through the Gambit runtime) in all scenarios (console or graphical interface) works fine when loading the DLL. If I call a Scheme method in a small console program it works fine. I assume that happens because the DLL is loaded at a lower memory address and the pointers in the scheme method are valid. If however I use a graphical interface test program, the DLL gets loaded at a higher memory location and I get "Segmentation fault" inside the scheme code. It seems that some pointers inside Gambit runtime are invalid but I don't know why this happens. This is the error: Program received signal SIGSEGV, Segmentation fault. 0x6abc123a in pluginEntry () from c:\compile\fox-1.4.2\tests\test.dll (gdb) bt #0 0x6abc123a in pluginEntry () from c:\compile\fox-1.4.2\tests\test.dll #1 0x6abc11b5 in entryPoint@4 () from c:\compile\fox-1.4.2\tests\test.dll #2 0x004013fc in main () And this is the code I use: extern void pluginEntry(EXNOTE*); #define ___VERSION 40062 #include "gambit.h" #define SCHEME_LIBRARY_LINKER ____20_testscm__ ___BEGIN_C_LINKAGE extern ___mod_or_lnk SCHEME_LIBRARY_LINKER (___global_state_struct*); ___END_C_LINKAGE CALLBACK void entryPoint(EXNOTE* note1) { ___setup_params_struct setup_params; ___setup_params_reset (&setup_params); setup_params.version = ___VERSION; setup_params.linker = SCHEME_LIBRARY_LINKER; ___setup (&setup_params); pluginEntry(note1); ___cleanup (); } (c-define-type EXNOTE* (pointer "EXNOTE")) (c-define (pluginEntry x) (EXNOTE*) void "pluginEntry" "" (write x)) Thank you, Dan. -----Original Message----- From: Marc Feeley [mailto:feeley@IRO.UMontreal.CA] Sent: Monday, February 21, 2005 5:55 PM To: dhristodorescu(a)borderfree.com Cc: gambit-list(a)IRO.UMontreal.CA Subject: Re: [gambit-list] Linking to C++ problems > Sorry to replay to my own message but I figure out what was the = > problem. > It was just the mangling of DLL exported symbols (I was referring a = > wrong > name); it works fine now. Great. > The only relevant part of the message that remains is the one about the > extern "C" generation. I don't understand your point here. You should either compile the whole Gambit runtime system and your program with a C compiler, or with a C++ compiler, and then the names will be mangled appropriately. Are you mixing C and C++ code? (this is a bad idea in general because of the way exceptions are handled....) Marc

1 0

access to SQLite w/o c-define
by Thomas Hafner 23 Fév '05

23 Fév '05

Hello, Sqlite-G v0.2[1] shall help using SQLite when programming in Gambit-C. I followed the recommendation of Marc Feeley to use the sqlite_compile, sqlite_step, and sqlite_finalize API rather than the C callback function API (see the thread with Subject ``SQLite 2.4.7''[2]). I had to switch from SQLite 2.4.7 to SQLite 2.8.15 to do so. I'm aware that the Scheme interface provided by sqlite-g.scm is very close to the C interface rather than being a high level interface for best use in Scheme. Such an interface could be still added on top of the existing one, maybe by abstracting from the example given by file sqlite-g-example. Comments are welcome! [1] <http://hafner.sdf-eu.org/pool/sqlite-g0.2.shar.txt> [2] Message-Id: <E1CrJzS-00012j-00(a)schnucke.hafner.nl.eu.org> Regards Thomas Hafner

1 0

read-substring unbound?
by linsmi＠coretech.co.nz 22 Fév '05

22 Fév '05

Hello all, I'm just getting into the Gambit environment - looks very nice. My first wee project for myself is to implement Chris Double's continuation based web server. The ability to serialize continuations makes Gambit an attractive platform. My question is regarding the read-substring procedure. The documentation lists this procedure, but at the Gambit REPL it is unbound: > read #<procedure #2 read> > read-subu8vector #<procedure #3 read-subu8vector> > read-substring *** ERROR IN (console)(a)4.1 -- Unbound variable: read-substring 1> Are the docs ahead of the implementation? Thanks Lindsay

2 1

macro-expansion bug (?)
by dev null 22 Fév '05

22 Fév '05

Hi, The following works in chicken and bigloo, but fails on gambit 4.0b12: --------------------------------------------------------------------------------------- (define-macro (build-funcs) (define any '(list? number? string?)) (define funcnames `((is-string string?) (is-number number?) (is-list list?) (is-any ,any))) (define (build desc) (let ((name (car desc)) (tests (if (list? (cadr desc)) (cadr desc) (cdr desc)))) `(define ,name (lambda (o) (or ,@(map (lambda (x) (list x 'o)) tests)))))) `(begin ,@(map build funcnames))) (pp (lambda () (build-funcs) #t)) (build-funcs) (is-any "dd") --------------------------------------------------------------------------------------- It seems that the reference to the `any' variable is unbound inside `funcnames'. If you move the definition of `any' outside of the body of `build-funcs', everything works fine. Not sure if this is a bug, or a misunderstanding on my part. Best Regards, Ben

2 2

RE: [gambit-list] Linking to C++ problems
by Dan Hristodorescu 22 Fév '05

22 Fév '05

Hi Marc, The problem I had in my test program was because I was compiling the DLL with -D___DYNAMIC. Without this flag the test program was fine. The real program I use still crashes and I have to figure out why. It works fine without the actual call to the scheme method; Gambit initialization doesn't cause any problems. I assume it's about some linking settings but I have to investigate more. I see your point about using the C++ compiler. I was using Gambit compiled by the default configure script which probably uses the C compiler and that's why I was mixing C with C++. Thanks for clearing that out for me. I'll recompile the runtime and try again. Thanks, Dan. -----Original Message----- From: Marc Feeley [mailto:feeley@IRO.UMontreal.CA] Sent: Monday, February 21, 2005 5:55 PM To: dhristodorescu(a)borderfree.com Cc: gambit-list(a)IRO.UMontreal.CA Subject: Re: [gambit-list] Linking to C++ problems > Sorry to replay to my own message but I figure out what was the = > problem. > It was just the mangling of DLL exported symbols (I was referring a = > wrong > name); it works fine now. Great. > The only relevant part of the message that remains is the one about the > extern "C" generation. I don't understand your point here. You should either compile the whole Gambit runtime system and your program with a C compiler, or with a C++ compiler, and then the names will be mangled appropriately. Are you mixing C and C++ code? (this is a bad idea in general because of the way exceptions are handled....) Marc

1 0

RE: [gambit-list] Linking to C++ problems
by Dan Hristodorescu 21 Fév '05

21 Fév '05

Sorry to replay to my own message but I figure out what was the problem. It was just the mangling of DLL exported symbols (I was referring a wrong name); it works fine now. The only relevant part of the message that remains is the one about the extern "C" generation. Thanks, Dan. -----Original Message----- From: Dan Hristodorescu [mailto:dhristodorescu@borderfree.com] Sent: Monday, February 21, 2005 11:31 AM To: gambit-list(a)IRO.UMontreal.CA Subject: [gambit-list] Linking to C++ problems Hello, I am using Gambit4b12 to write a plugin for a C++ program. I've done some tests and had some success although right now I'm having some problems when using it in a DLL. First I would like to suggest a small improvement for the C code generation. Maybe I'm missing a switch to pass to gsc but every time I generate the C code I have to add extern "C" {} wrapper around each file after I move all the #include outside that block. I also noticed that gambit.c doesn't have a extern "C" wrapper and I had to add it. I think it would be simple to automatically add: #ifdef __cplusplus extern "C" {} #endif wrapper when generating the code. I don't know how easy would be to extract the includes in c-declare outside that wrapper but it would be nice to avoid manually editing the file. The problem I'm having right now is that the code which runs fine in a single standalone program crashes when is called in a loaded DLL. I think it must be something in the way the initialization has to be done but the documentation is not too clear. If someone would be able to give me a hint I would appreciate it. I am using mingw on Windows and I get this error: Program received signal SIGSEGV, Segmentation fault. 0x1012a67f in ___CHARSTRING_to_UCS2STRING () from c:\Gambitc_project\finalePlugin\testing\test.dll (gdb) bt #0 0x1012a67f in ___CHARSTRING_to_UCS2STRING () from c:\Gambitc_project\finalePlugin\testing\test.dll #1 0x00000000 in ?? () from #2 0x0022fe68 in ?? () #3 0x101248b1 in ___alloc_mem () from c:\Gambitc_project\finalePlugin\testing\test.dll Previous frame inner to this frame (corrupt stack?) The code is bellow. Thank you, Dan Hristodorescu. - Main program: #include <windows.h> #include <stdio.h> #include "note.h" typedef void (*EntryPointfuncPtr)(EXNOTE*); EntryPointfuncPtr callEntryPoint; HINSTANCE library; int main(int argc,char **argv) { library = LoadLibrary("test.dll"); // Check to see if the library was loaded successfully if (library == 0) { printf("Couldn't load the DLL"); exit(1); } EXNOTE* note1 = new EXNOTE(); note1->tcd=1; note1->alteration=1; note1->noteID=1; note1->flag=1; printf("Address=0x%X\n", note1); callEntryPoint = (EntryPointfuncPtr)GetProcAddress(library,"_Z10entryPointP6EXNOTE"); (*callEntryPoint)(note1); printf("Note->tcd= %d\n", note1->tcd); printf("Note->alteration= %d\n", note1->alteration); printf("Note->noteID= %d\n", note1->noteID); printf("Note->flag= %d\n", note1->flag); delete note1; } DLL code: #include <windows.h> #include <stdio.h> #include "note.h" extern "C" void pluginEntry(EXNOTE*); #define ___VERSION 40062 #include "gambit.h" #define SCHEME_LIBRARY_LINKER ____20_testscm__ ___BEGIN_C_LINKAGE extern ___mod_or_lnk SCHEME_LIBRARY_LINKER (___global_state_struct*); ___END_C_LINKAGE CALLBACK void entryPoint(EXNOTE* note1) { ___setup_params_struct setup_params; ___setup_params_reset (&setup_params); setup_params.version = ___VERSION; setup_params.linker = SCHEME_LIBRARY_LINKER; ___setup (&setup_params); pluginEntry(note1); ___cleanup (); } note.h file: #ifndef _NOTE_H_ #define _NOTE_H_ typedef short twobyte; typedef unsigned long ufourbyte; typedef ufourbyte FLAG_32; class EXNOTE { public: twobyte tcd; twobyte alteration; twobyte noteID; FLAG_32 flag; EXNOTE() : tcd(0), alteration(0), noteID(0), flag(0) {} ~EXNOTE() {} }; #endif Scheme code: (c-declare " #include \"note.h\" ") (c-define-type twobyte short) (c-define-type ufourbyte unsigned-long) (c-define-type FLAG_32 ufourbyte) ;; ;;;; EXNOTE ;;; (c-define-type EXNOTE* (pointer "EXNOTE")) (define EXNOTE-tcd (c-lambda (EXNOTE*) twobyte "___result = ___arg1->tcd;")) (define EXNOTE-tcd-set! (c-lambda (EXNOTE* twobyte) void "___arg1->tcd = ___arg2;")) (define transpose-note (lambda (note step) (EXNOTE-tcd-set! note (+ (EXNOTE-tcd note) step)))) (c-define (pluginEntry x) (EXNOTE*) void "pluginEntry" "extern" (write x) (newline) (transpose-note x 3))

2 1

Linking to C++ problems
by Dan Hristodorescu 21 Fév '05

21 Fév '05

Hello, I am using Gambit4b12 to write a plugin for a C++ program. I've done some tests and had some success although right now I'm having some problems when using it in a DLL. First I would like to suggest a small improvement for the C code generation. Maybe I'm missing a switch to pass to gsc but every time I generate the C code I have to add extern "C" {} wrapper around each file after I move all the #include outside that block. I also noticed that gambit.c doesn't have a extern "C" wrapper and I had to add it. I think it would be simple to automatically add: #ifdef __cplusplus extern "C" {} #endif wrapper when generating the code. I don't know how easy would be to extract the includes in c-declare outside that wrapper but it would be nice to avoid manually editing the file. The problem I'm having right now is that the code which runs fine in a single standalone program crashes when is called in a loaded DLL. I think it must be something in the way the initialization has to be done but the documentation is not too clear. If someone would be able to give me a hint I would appreciate it. I am using mingw on Windows and I get this error: Program received signal SIGSEGV, Segmentation fault. 0x1012a67f in ___CHARSTRING_to_UCS2STRING () from c:\Gambitc_project\finalePlugin\testing\test.dll (gdb) bt #0 0x1012a67f in ___CHARSTRING_to_UCS2STRING () from c:\Gambitc_project\finalePlugin\testing\test.dll #1 0x00000000 in ?? () from #2 0x0022fe68 in ?? () #3 0x101248b1 in ___alloc_mem () from c:\Gambitc_project\finalePlugin\testing\test.dll Previous frame inner to this frame (corrupt stack?) The code is bellow. Thank you, Dan Hristodorescu. - Main program: #include <windows.h> #include <stdio.h> #include "note.h" typedef void (*EntryPointfuncPtr)(EXNOTE*); EntryPointfuncPtr callEntryPoint; HINSTANCE library; int main(int argc,char **argv) { library = LoadLibrary("test.dll"); // Check to see if the library was loaded successfully if (library == 0) { printf("Couldn't load the DLL"); exit(1); } EXNOTE* note1 = new EXNOTE(); note1->tcd=1; note1->alteration=1; note1->noteID=1; note1->flag=1; printf("Address=0x%X\n", note1); callEntryPoint = (EntryPointfuncPtr)GetProcAddress(library,"_Z10entryPointP6EXNOTE"); (*callEntryPoint)(note1); printf("Note->tcd= %d\n", note1->tcd); printf("Note->alteration= %d\n", note1->alteration); printf("Note->noteID= %d\n", note1->noteID); printf("Note->flag= %d\n", note1->flag); delete note1; } DLL code: #include <windows.h> #include <stdio.h> #include "note.h" extern "C" void pluginEntry(EXNOTE*); #define ___VERSION 40062 #include "gambit.h" #define SCHEME_LIBRARY_LINKER ____20_testscm__ ___BEGIN_C_LINKAGE extern ___mod_or_lnk SCHEME_LIBRARY_LINKER (___global_state_struct*); ___END_C_LINKAGE CALLBACK void entryPoint(EXNOTE* note1) { ___setup_params_struct setup_params; ___setup_params_reset (&setup_params); setup_params.version = ___VERSION; setup_params.linker = SCHEME_LIBRARY_LINKER; ___setup (&setup_params); pluginEntry(note1); ___cleanup (); } note.h file: #ifndef _NOTE_H_ #define _NOTE_H_ typedef short twobyte; typedef unsigned long ufourbyte; typedef ufourbyte FLAG_32; class EXNOTE { public: twobyte tcd; twobyte alteration; twobyte noteID; FLAG_32 flag; EXNOTE() : tcd(0), alteration(0), noteID(0), flag(0) {} ~EXNOTE() {} }; #endif Scheme code: (c-declare " #include \"note.h\" ") (c-define-type twobyte short) (c-define-type ufourbyte unsigned-long) (c-define-type FLAG_32 ufourbyte) ;; ;;;; EXNOTE ;;; (c-define-type EXNOTE* (pointer "EXNOTE")) (define EXNOTE-tcd (c-lambda (EXNOTE*) twobyte "___result = ___arg1->tcd;")) (define EXNOTE-tcd-set! (c-lambda (EXNOTE* twobyte) void "___arg1->tcd = ___arg2;")) (define transpose-note (lambda (note step) (EXNOTE-tcd-set! note (+ (EXNOTE-tcd note) step)))) (c-define (pluginEntry x) (EXNOTE*) void "pluginEntry" "extern" (write x) (newline) (transpose-note x 3))

1 0

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 2005