Evaluation

Hi,

I have here this piece of code, and it seems that it doesn't evaluate 
the if correctly. Is it a bug, or is it something I overlooked? :)

Thanks,
Jan

(define (parent family)
		(car family))

(define (subfam family)
		(cdr family))

(define (add e p) (if p (cons e p)))

(define (path name family)
		(cond ((eq? name (parent family)) (list (parent family)))
			  (else (add (parent family) (path-in name (subfam family))))))

(define (path-in name families)
		(cond ((null? families) #f)
			  (else (or (path name (car families))
						(path-in name (cdr families))))))

Release of scsh 0.6.0

The following message is a courtesy copy of an article
that has been posted to
comp.lang.scheme.scsh,comp.compilers,comp.lang.lisp,comp.unix.admin,comp.unix.programmer
as well.

Olin, Brian, Mike and I are very pleased to announce the release of
version 0.6.0 of scsh, the Scheme Shell.

scsh 0.6.0 is a major new release.  Among the new features, scsh
0.6.0 supports lightweight multithreading which makes scsh an
excellent platform for writing network daemons and other concurrent
programs.

Note that scsh has a new home in the world-wide web:

http://www.scsh.net/

scsh's ftp download location has also changed; it is now at:

ftp://ftp.scsh.net/pub/scsh/

We also intend to release a new version of the Scheme Underground
Network Package with support for scsh 0.6.0 very soon.

We have appended the RELEASE file from the distribution for your
convenience.

Cordially,
Brian, Martin, Mike, and the illustrious Dr. S.,
your humble scsh maintainers

Gtk into Scheme48?

Has anybody perchance taken the guile-gtk bindings and made them work
for Scheme48?
Thanks.
--

-- 
Greg      gregs <at> ai.mit.edu (617)253-5807
Sullivan  http://www.ai.mit.edu/~gregs/

Re: Gtk into Scheme48?

>>>>> "Greg" == Gregory T Sullivan <gregs <at> ai.mit.edu> writes:

Greg> Has anybody perchance taken the guile-gtk bindings and made them work
Greg> for Scheme48?
Greg> Thanks.

No, but we have Xlib and are slowly working our way up the toolkit
hierarchy.  Since Gtk is not based on Xt, it probably will go some
other way, though.

--

-- 
Cheers =8-} Mike
Friede, Völkerverständigung und überhaupt blabla

Re: Gtk into Scheme48?

On Sun, 20 Jan 2002, Michael Sperber [Mr.  Preprocessor] wrote:

> >>>>> "Greg" == Gregory T Sullivan <gregs <at> ai.mit.edu> writes:
> 
> Greg> Has anybody perchance taken the guile-gtk bindings and made them work
> Greg> for Scheme48?
> Greg> Thanks.
> 
> No, but we have Xlib and are slowly working our way up the toolkit
> hierarchy.  Since Gtk is not based on Xt, it probably will go some
> other way, though.
> 

Is the X binding available somewhere? Will it be integrated into the main
tree?

Gtk is in the process of becoming gtk2 and probably sufficently far in it
that it might be a better idea to concentrate on teh new version...

> -- 
> Cheers =8-} Mike
> Friede, Völkerverständigung und überhaupt blabla
> 

	Sander

+++ Out of cheese error +++

Re: Gtk into Scheme48?

>>>>> "sander" == sander  <sander <at> haldjas.folklore.ee> writes:

sander> On Sun, 20 Jan 2002, Michael Sperber [Mr.  Preprocessor] wrote:

>> >>>>> "Greg" == Gregory T Sullivan <gregs <at> ai.mit.edu> writes:
>> 
Greg> Has anybody perchance taken the guile-gtk bindings and made them work
Greg> for Scheme48?
Greg> Thanks.
>> 
>> No, but we have Xlib and are slowly working our way up the toolkit
>> hierarchy.  Since Gtk is not based on Xt, it probably will go some
>> other way, though.
>> 

sander> Is the X binding available somewhere? Will it be integrated into the main
sander> tree?

There is no offical release yet but you can obtain it by checking out
the module "scx" from scsh's CVS repository. See

https://sourceforge.net/cvs/?group_id=10493

for more information about how to access to repository. scx should run
out of the box with scsh 0.6.0. For Scheme 48 some adjustments are
necessary that were not yet made.

sander> Gtk is in the process of becoming gtk2 and probably sufficently far in it
sander> that it might be a better idea to concentrate on teh new version...

External calls from callbacks and GC roots

The VM procedure S48-SET-GC-ROOTS-BASE! makes the implicit assumption

(= *external-root-stack* *external-root-stack-base*)

because that's the situation restored by S48-RELEASE-GC-ROOTS-BASE!

This assumption is not true, however, when you have an external call
from a callback.  The C code at the beginning of the calling sequence
might have protected some GC roots, thus creating a difference between
*EXTERNAL-ROOT-STACK* and *EXTERNAL-ROOT-STACK-BASE*.  The later
external call doesn't then restore *EXTERNAL-ROOT-STACK* upon
returning, which is erroneous.

I'm checking the following patch into scsh which, besides remembering
*EXTERNAL-ROOT-STACK-BASE*, also remembers *EXTERNAL-ROOT-STACK*.  It
seems to fix the problem.

Index: c/external.c
===================================================================
RCS file: /cvsroot/scsh/scsh-0.6/c/external.c,v
retrieving revision 1.12
diff -u -r1.12 external.c
--- c/external.c	2002/01/11 10:13:58	1.12
+++ c/external.c	2002/01/27 20:16:19
 <at>  <at>  -127,6 +127,8  <at>  <at> 
 s48_external_call(s48_value sch_proc, s48_value proc_name,
 		  long nargs, char *char_argv)

Re: External calls from callbacks and GC roots

   Delivery-date: Sun, 27 Jan 2002 15:25:11 -0500
   From: sperber <at> informatik.uni-tuebingen.de (Michael Sperber [Mr.  Preprocessor])
   Date: Sun, 27 Jan 2002 21:18:28 +0100

   The VM procedure S48-SET-GC-ROOTS-BASE! makes the implicit assumption

   (= *external-root-stack* *external-root-stack-base*)

   because that's the situation restored by S48-RELEASE-GC-ROOTS-BASE!

   This assumption is not true, however, when you have an external call
   from a callback.  The C code at the beginning of the calling sequence
   might have protected some GC roots, thus creating a difference between
   *EXTERNAL-ROOT-STACK* and *EXTERNAL-ROOT-STACK-BASE*.  The later
   external call doesn't then restore *EXTERNAL-ROOT-STACK* upon
   returning, which is erroneous.

Oops.  This must have been a bear to track down.

   I'm checking the following patch into scsh which, besides remembering
   *EXTERNAL-ROOT-STACK-BASE*, also remembers *EXTERNAL-ROOT-STACK*.  It
   seems to fix the problem.

I think that a simpler fix would be to change S48-RELEASE-GC-ROOTS-BASE!
to the following:

  (define (s48-release-gc-roots-base! old-base)
    (let ((current-base *external-root-stack-base*))
      (set! *external-root-stack-base* old-base)
      (if (address= *external-root-stack* current-base)