Gambit-list Mars 2005

gambit-list@iro.umontreal.ca

12 participants
24 discussions

Problem using 'if' in a macro to conditionaly define a let form
by Eric Merritt 29 Mar '05

29 Mar '05

Guys, I am having a bit of a problem with if in a macro and I could use some help. Say I have a macro similar to the following (define-macro (foo somestuff) `(let ((x ,sumstuff) ,(if (is-cool sumstuff) `(do-something-else-cool))) (some-more-stuff))) this will result in an ill formed let anytime 'some-stuff' isn't cool. Thats becuase the 'if' statement returns #!void in the expansion which is invalid. Cond does the same thing. Is there an alternate way to do this, am I missing something obvious? I get the feeling that I am. Thanks, Eric

1 0

srfi-13 define-macro replacements
by ben＠crickhollow.fuhok.net 27 Mar '05

27 Mar '05

Here are define-macro versions of `let-string-start+end' and `let-string-start+end2' needed by the reference implementation of srfi-13. I'm still reading over everyone else's work, so I don't know if these will be useful or not. ------------------------------------------------------------------------------- (define-macro (let-string-start+end start+end proc s-exp args-exp . body) (or (list? start+end) (error "let-string-start+end: start+end must be list")) (case (length start+end) ((2) `(receive ,start+end (string-parse-final-start+end ,proc ,s-exp ,args-exp) ,@body)) ((3) `(receive ,start+end (string-parse-start+end ,proc ,s-exp ,args-exp) ,@body)) (else (error "let-string-start+end: wrong length start+end")))) (define-macro (let-string-start+end2 start+end-pair proc str1 str2 args . body) (or (list? start+end-pair) (error "let-string-start+end: start+end-pair must be list")) (let ((rest (gensym)) (procv (gensym))) (receive (start1 end1 start2 end2) (apply values start+end-pair) `(let ((,procv ,proc)) ; Make sure PROC is only evaluated once. (let-string-start+end (,rest ,start1 ,end1) ,procv ,str1 ,args (let-string-start+end (,start2 ,end2) ,procv ,str2 ,rest ,@body)))))) ------------------------------------------------------------------------------- Regards, Ben

3 3

Whither ##unchecked-structure-ref?
by Bradley Lucier 26 Mar '05

26 Mar '05

Marc: I tried the following---the problem arises when I try to look at the macro expansion of this compiled file: [descartes:programs/SAGE14/libraries] lucier% gsc loading /usr/local/Gambit-C/gambcext.scm Gambit Version 4.0 beta 12 > (with-output-to-file "crap.scm" (lambda () (compile-file "srfis.scm" '(expansion)))) *** ERROR -- Unbound variable: ##unchecked-structure-ref 1> > (compile-file "srfis.scm") gcc: unrecognized option '-no-cpp-precomp' #t I also find: banach-26% grep -r unchecked-structure-ref * gsc/_prims.scm:("##unchecked-structure-ref" (4) #f () 0 (#f) extended) gsc/_t-c-2.scm:(targ-op "##unchecked-structure-ref" gsc/_t-c-2.scm:(targ-spec "##structure-ref" (targ-u "##unchecked-structure-ref")) lib/_io.scm: (##unchecked-structure-ref lib/_kernel.scm: (##unchecked-structure-ref type 1 ##type-type ##type-id)) lib/_kernel.scm: (##unchecked-structure-ref type 2 ##type-type ##type-name)) lib/_kernel.scm: (##unchecked-structure-ref type 3 ##type-type ##type-flags)) lib/_kernel.scm: (##unchecked-structure-ref type 4 ##type-type ##type-super)) lib/_kernel.scm: (##unchecked-structure-ref type 5 ##type-type ##type-fields)) lib/_kernel.scm: (##unchecked-structure-ref type 6 ##type-type ##type-cfields)) lib/_kernel.scm: (##unchecked-structure-ref obj i type proc) Brad

1 0

SRFI-1
by Eric Merritt 25 Mar '05

25 Mar '05

I have ported SRFI-1 to gambit and put it in its own "srfi1#" namespace. It was pretty trivial to do. I think this might be of interest to other people so I figured I would offer it the community. For those interested, I have also ported Yasos to gambit. The main thing I did was convert the hygienic macros to un-hygienic macros so that it wouldn't depend on syntax-case.scm and error line numbers would be a little more accurate. In the future I intend to extend it with method-missing and perform functionality. Neither of these are extremely well tested at this point. I am in the process of finding and porting a unit test framework but I have not finished yet. Once I do I will add unit tests for the above two to the package. It may be that someone else has already made these available for gambit, if so just ignore this and I apologize for the noise.

5 7

Does , l do anything different than , s in the debugger?
by Bradley Lucier 24 Mar '05

24 Mar '05

I think Maxin Naumov found another bug. Man, these students that take the documentation seriously ;-)! I tried a straightforward definition of (fact n) and tried to leap through the subcall (fact (- n 1)) and it didn't work; in fact, ,l seemed to do the same thing as ,s in all cases. Looks like a bug. Brad

2 1

RE: [gambit-list] Calling from C on Windows
by Dan Hristodorescu 20 Mar '05

20 Mar '05

Hi Marc, It works fine now. Thank you very much. Regards, Dan. -----Original Message----- From: Marc Feeley [mailto:feeley@IRO.UMontreal.CA] Sent: Saturday, March 19, 2005 9:05 AM To: dhristodorescu(a)borderfree.com Cc: gambit-list(a)IRO.UMontreal.CA Subject: Re: [gambit-list] Calling from C on Windows I fixed the bug. You need to change the USE_WIN32 section in ___os_device_stream_open_predefined to this: switch (___INT(index)) { case -4: open_console: { ___device_tty *d; if ((e = ___device_tty_setup_console (&d, io_mod.dgroup, direction)) != ___FIX(___NO_ERR)) return e; dev = ___CAST(___device_stream*,d); break; } default: { switch (___INT(index)) { default: case -1: h = GetStdHandle (STD_INPUT_HANDLE); break; case -2: h = GetStdHandle (STD_OUTPUT_HANDLE); break; case -3: h = GetStdHandle (STD_ERROR_HANDLE); break; } if (h == INVALID_HANDLE_VALUE) return err_code_from_GetLastError (); if (GetFileType (h) == FILE_TYPE_UNKNOWN) goto open_console; ... The bug occurs on Windows when the Gambit runtime is being run as a windowed application (no problem in console applications). In a windowed application the GetStdHandle calls (which are meant to return the standard input/output/error) return a handle whose type is not recognized by Gambit (it is not a file, a pipe, a socket, a console, or a serial port). This caused the runtime to terminate. The fix adds a check for the handle type and associates a console window to stdin/out/err if their type is unknown. So for windowed applications any "standard I/O" from Scheme will go to a freshly created console (unless stdin/out/err were redirected). Marc

1 0

Calling from C on Windows
by Dan Hristodorescu 19 Mar '05

19 Mar '05

Hello, Does anyone have any luck in calling Gambit4b12 from a C function on a non-console Windows application? I tried it with both mingw and VS6 and while it works fine in a console application it crashes when compiled for the graphical subsystem. In debugger it seems that inside the Scheme function a parameter retrieved from the stack doesn't have the proper value and I get a segfault. I think it has something to do with the stack frame alignment but I couldn't figure out how to avoid it. I would appreciate any hints on how to make it work. Thank you, Dan.

2 1

A question concerning load/include
by Bradley Lucier 17 Mar '05

17 Mar '05

I seem to have trashed about a dozen recent e-mail messages, including this one, but here's a reply: > Are these declarations documented anywhere, I can't seem to find it in > gambits distributed docs. > > > > > See also (declare (core)) and (declare (not core)). > > Use The Source, Luke. Marc, these really should be documented unless you think they're a hack and will be eliminated in the near future. In gsc/_ptree1.scm, we find: ; - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - ; ; Declarations. <stuff omitted> ; Compilation strategy declarations: ; ; (block) global vars defined are only mutated by code in the current file ; (separate) global vars defined can be mutated by other code ; ; (core) toplevel expressions and definitions must be compiled to code ; (not core) toplevel expressions and definitions belong to another module And see how it's used in the compiler. For example, there's _envadt.scm, which defines Abstract Data Types for use in _env.scm, but which are also used in other files. So in _env.scm we find _env.scm:(include "_envadt.scm") while in other files that use the accessors, setters, etc., defined in _envadt.scm we find _back.scm:(include-adt "_envadt.scm") _env.scm:(include "_envadt.scm") _front.scm:(include-adt "_envadt.scm") _gvm.scm:(include-adt "_envadt.scm") _ptree1.scm:(include-adt "_envadt.scm") _ptree2.scm:(include-adt "_envadt.scm") _source.scm:(include-adt "_envadt.scm") _t-c-1.scm:(include-adt "_envadt.scm") _t-c-2.scm:(include-adt "_envadt.scm") _t-c-3.scm:(include-adt "_envadt.scm") _utils.scm:(include-adt "_envadt.scm") while include-adt is defined by (##define-macro (include-adt filename) `(begin (##declare (not core)) (##include ,(string-append "../gsc/" filename)) (##declare (core)))) So the definitions in files included with "include-adt" can be inlined, etc., in the surrounding source files, which is important for speed, but code for these standalone accessors will be defined only in _env.scm. Brad

1 0

RE: [gambit-list] Calling from C on Windows
by Dan Hristodorescu 17 Mar '05

17 Mar '05

Thanks Marc, I figured out you are very busy and I tried to find exactly why it happens but it wasn't too obvious for me. I just thought maybe someone else more experienced than me (especially looking at assembly code) had the same problem. It's very good news it's on your list. I also have an unrelated question regarding the limitations for the C-Scheme interface in a multithreading environment. I read that there is a problem with multithreading when calling C to Scheme and back to C due to stack cleanup. I would like to know what are the safe scenarios. Would it also happen in a chain like Scheme to C and back to Scheme? I assume that calling just Scheme to C or just C from Scheme in a multithreaded environment would be ok. Is that the case? Regards, Dan. -----Original Message----- From: Marc Feeley [mailto:feeley@IRO.UMontreal.CA] Sent: Wednesday, March 16, 2005 6:58 PM To: dhristodorescu(a)borderfree.com Subject: Re: [gambit-list] Calling from C on Windows > Hello, > > > > Does anyone have any luck in calling Gambit4b12 from a C function on a > non-console Windows application? > > I tried it with both mingw and VS6 and while it works fine in a console > application it crashes when compiled for the graphical subsystem. > > In debugger it seems that inside the Scheme function a parameter retrieved > from the stack doesn't have the proper value and I get a segfault. > > I think it has something to do with the stack frame alignment but I couldn't > figure out how to avoid it. > > > > I would appreciate any hints on how to make it work. Sorry, I've been very busy lately and couldn't look into it. I'll do that first thing tomorrow morning. It appears the problem also exists with Linux. Marc

1 0

A question concerning load/include.
by Eric Merritt 16 Mar '05

16 Mar '05

Guys, I am a bit confused. I have a file with a simple macro in it ;; alias so compiler can inline for speed (define-syntax INSTANCE-DISPATCHER (syntax-rules () ((instance-dispatcher inst) (cdr inst)))) This is the only thing in the file (its been striped down). If I invoke gsi enter (load "~~/syntax-case") (load "oop.scm"), oop.scm is the name of the file, everything works great. However, if I change the file to contain (load "~~/syntax-case") ;; alias so compiler can inline for speed (define-syntax INSTANCE-DISPATCHER (syntax-rules () ((instance-dispatcher inst) (cdr inst)))) invoke gsi and then enter (load "oop.scm") I get a "Ill-formed expression" error. I don't really understand why these two methods produce very different results. Obviously, I am missing something but I have yet to find out what. Any help is appreciated. -- I'm a programmer, I don't have to spell correctly; I just have to spell consistently

4 6

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

Gambit-list Mars 2005