From chris.actondev at gmail.com  Sun Dec  5 09:52:23 2021
From: chris.actondev at gmail.com (Christos Vagias)
Date: Sun, 5 Dec 2021 18:52:23 +0100
Subject: [CM] Probably a bug with call/cc
Message-ID: <CAG02pQiA5vD42bb7NnvKZ06B5Om3vOzd63=snf11L=D=70esGg@mail.gmail.com>

Hi Bil,

I'm working with some http libs & wanted to try call/cc to make some
macro to help with the callback chains, but stumbled upon a possible
bug.

I'm attaching a demo that shows the problem:
- if (main) is called from the loaded file, the call/cc chain doesn't work
- if (main) isn't called at the s7_load_file time, but later from the
repl, it works!

Thanks,
Christos
-------------- next part --------------
A non-text attachment was scrubbed...
Name: bug-cc.zip
Type: application/zip
Size: 1622 bytes
Desc: not available
URL: <https://cm-mail.stanford.edu/pipermail/cmdist/attachments/20211205/3c600eef/attachment.zip>

From bil at ccrma.Stanford.EDU  Sun Dec  5 13:37:51 2021
From: bil at ccrma.Stanford.EDU (bil at ccrma.Stanford.EDU)
Date: Sun, 05 Dec 2021 13:37:51 -0800
Subject: [CM] Probably a bug with call/cc
In-Reply-To: <CAG02pQiA5vD42bb7NnvKZ06B5Om3vOzd63=snf11L=D=70esGg@mail.gmail.com>
References: <CAG02pQiA5vD42bb7NnvKZ06B5Om3vOzd63=snf11L=D=70esGg@mail.gmail.com>
Message-ID: <5160005ba4b7cfb49af1917bb0ef0bc3@ccrma.stanford.edu>

I think this is more a matter of where the repl
loop happens.  If (main) is not commented out,
the next thing is the repl loop waiting for input;
if you type Ctrl-D, you get the rest of the
continuation stuff:

;; (main) commented out:
/home/bil/test/callcc/ asdf
hi from c

> (main)
()
> foo is response1
foo is response1 bar is response2
done!
^C

;; (main) in main.scm:
/home/bil/test/callcc/ asdf
hi from c

> foo is response1
< Ctrl-D typed here>
foo is response1 bar is response2
done!
<exits>



From chris.actondev at gmail.com  Sun Dec  5 14:08:45 2021
From: chris.actondev at gmail.com (Christos Vagias)
Date: Sun, 5 Dec 2021 23:08:45 +0100
Subject: [CM] Probably a bug with call/cc
In-Reply-To: <5160005ba4b7cfb49af1917bb0ef0bc3@ccrma.stanford.edu>
References: <CAG02pQiA5vD42bb7NnvKZ06B5Om3vOzd63=snf11L=D=70esGg@mail.gmail.com>
	<5160005ba4b7cfb49af1917bb0ef0bc3@ccrma.stanford.edu>
Message-ID: <CAG02pQgAm-qmK-H7zHDY-MCaERZr4-53MaZV83ugTUXRRf0vWQ@mail.gmail.com>

Oh, I hadn't noticed that behavior. Seems that s7_free triggers something.
But then, why is repl just.. broken, if having the (main) not commented out?

Anyway, I've come up with a better example. It seems s7_eval_c_string
behaves differently than both s7_load &  s7_load_c_string.
See the attached cpp file


On Sun, 5 Dec 2021 at 22:37, <bil at ccrma.stanford.edu> wrote:
>
> I think this is more a matter of where the repl
> loop happens.  If (main) is not commented out,
> the next thing is the repl loop waiting for input;
> if you type Ctrl-D, you get the rest of the
> continuation stuff:
>
> ;; (main) commented out:
> /home/bil/test/callcc/ asdf
> hi from c
>
> > (main)
> ()
> > foo is response1
> foo is response1 bar is response2
> done!
> ^C
>
> ;; (main) in main.scm:
> /home/bil/test/callcc/ asdf
> hi from c
>
> > foo is response1
> < Ctrl-D typed here>
> foo is response1 bar is response2
> done!
> <exits>
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: main.cpp
Type: text/x-c++src
Size: 3134 bytes
Desc: not available
URL: <https://cm-mail.stanford.edu/pipermail/cmdist/attachments/20211205/522f5501/attachment.bin>

From wdouglass at carnegierobotics.com  Wed Dec  8 11:41:18 2021
From: wdouglass at carnegierobotics.com (Woody Douglass)
Date: Wed, 8 Dec 2021 19:41:18 +0000
Subject: [CM] Possible bug in `member`
Message-ID: <e7d6dce58f2789a0fced6c4ae6d0cf0c2b0d0a2c.camel@carnegierobotics.com>

Hello,

I believe i may have found a bug
consider the following code, which searches a list of names by
substring:
```
(let* ((records (list
		 (inlet :person "oscar meyer")
		 (inlet :person "howard johnson")
		 (inlet :person "betty crocker")))
       (match-record (lambda (name record)
		       (format (current-error-port) "COMPARE '~A' '~A'~%" name (record 'person))
		       (let ((vname (record 'person)))
			 (equal? name (substring vname 0 (min (length name) (length vname)))))))
       (find-record (lambda (name)
		      (format (current-error-port) "FINDING ~A~%" name)
		      (let* ((found (member name records match-record)))
			(if found
			    (car found)
			    #f)))))
  (format #t "~A~%" (find-record "betty")))
```

I expect that code to print one line for each comparison, and the `a`
argument to `match-record` to be "betty". instead, as of git revision
b8d66a23084183b97139e49d1867638cd39a2808 this excerpt prints
```
FINDING betty
COMPARE 'betty' 'oscar meyer'
COMPARE 'oscar meyer' 'howard johnson'
COMPARE 'howard johnson' 'betty crocker'
#f
```

The compares are being rotated in a way that, to me, looks like a
stacking bug. my s7 instance in this case is compiled with
```
gcc -g3 -Wall   -c -o s7.o s7.c
gcc -o repl repl.o s7.o -lm -I. -ldl -Wl,-export-dynamic 
```

Is this a bug in s7? do i completely misunderstand how `member` works?

Thanks for any advice,
Woody Douglass



From bil at ccrma.Stanford.EDU  Wed Dec  8 12:49:23 2021
From: bil at ccrma.Stanford.EDU (bil at ccrma.Stanford.EDU)
Date: Wed, 08 Dec 2021 12:49:23 -0800
Subject: [CM] Possible bug in `member`
In-Reply-To: <e7d6dce58f2789a0fced6c4ae6d0cf0c2b0d0a2c.camel@carnegierobotics.com>
References: <e7d6dce58f2789a0fced6c4ae6d0cf0c2b0d0a2c.camel@carnegierobotics.com>
Message-ID: <50b3a3ee6b028c4a038a2c35e2772e4a@ccrma.stanford.edu>

Thanks for the bug report!  This is an inadvertent
shared list -- an over-eager optimizer basically.
I'll have to trace it back to where the optimizer
made its mistake, but in the meantime, change
line 38562 (or thereabouts) in g_member from

y = list_1(sc, args);

to:

y = list_1(sc, copy_proper_list(sc, args));



From chris.actondev at gmail.com  Mon Dec 20 05:45:11 2021
From: chris.actondev at gmail.com (Christos Vagias)
Date: Mon, 20 Dec 2021 15:45:11 +0200
Subject: [CM] Possible bug with c-object & openlet
Message-ID: <CAG02pQjkxyXhPBm9vqLxb_TObmJMR-zwFu8k_BxQjLVkakJ+DQ@mail.gmail.com>

Hi Bil,

I think I found a bug:
When creating an object with

  s7_pointer obj = s7_make_c_object(sc, type_foo, new Foo{});
  s7_pointer methods = s7_eval_c_string(
      sc, "(inlet :write foo-write))");
  // Without gc_protect the c_object loses its methods after gc
  if(arg_gc_protect == 1) s7_gc_protect(sc, methods);
  s7_c_object_set_let(sc, obj, methods);
  return s7_openlet(sc, obj);

(as the comment says) without gc_protect of the c_object let/methods, the
c_object loses its methods after gc.
I'd assume that since we "set_let" to a value that still is "alive", it's
"let/methods objects" would also not be garbage collected (at least I
assume that the let is getting gc'ed).

I'm attaching a demo program
- ./main 0 # no gc_protect, errors
- ./main 1 # gc_protect, no errors
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cm-mail.stanford.edu/pipermail/cmdist/attachments/20211220/9a59238f/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: bug-cc.zip
Type: application/zip
Size: 1622 bytes
Desc: not available
URL: <https://cm-mail.stanford.edu/pipermail/cmdist/attachments/20211220/9a59238f/attachment.zip>

From chris.actondev at gmail.com  Mon Dec 20 06:24:10 2021
From: chris.actondev at gmail.com (Christos Vagias)
Date: Mon, 20 Dec 2021 16:24:10 +0200
Subject: [CM] Possible bug with c-object & openlet
In-Reply-To: <CAG02pQjkxyXhPBm9vqLxb_TObmJMR-zwFu8k_BxQjLVkakJ+DQ@mail.gmail.com>
References: <CAG02pQjkxyXhPBm9vqLxb_TObmJMR-zwFu8k_BxQjLVkakJ+DQ@mail.gmail.com>
Message-ID: <CAG02pQhpUwUFJ-DGp+znDeCjRq8hyTEWb4Uz1urgD_1OTDNRUg@mail.gmail.com>

Oops, had attached the wrong file, apologies!


On Mon, 20 Dec 2021 at 15:45, Christos Vagias <chris.actondev at gmail.com>
wrote:

> Hi Bil,
>
> I think I found a bug:
> When creating an object with
>
>   s7_pointer obj = s7_make_c_object(sc, type_foo, new Foo{});
>   s7_pointer methods = s7_eval_c_string(
>       sc, "(inlet :write foo-write))");
>   // Without gc_protect the c_object loses its methods after gc
>   if(arg_gc_protect == 1) s7_gc_protect(sc, methods);
>   s7_c_object_set_let(sc, obj, methods);
>   return s7_openlet(sc, obj);
>
> (as the comment says) without gc_protect of the c_object let/methods, the
> c_object loses its methods after gc.
> I'd assume that since we "set_let" to a value that still is "alive", it's
> "let/methods objects" would also not be garbage collected (at least I
> assume that the let is getting gc'ed).
>
> I'm attaching a demo program
> - ./main 0 # no gc_protect, errors
> - ./main 1 # gc_protect, no errors
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cm-mail.stanford.edu/pipermail/cmdist/attachments/20211220/645d26d1/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: bug-c-object-openlet.zip
Type: application/zip
Size: 1706 bytes
Desc: not available
URL: <https://cm-mail.stanford.edu/pipermail/cmdist/attachments/20211220/645d26d1/attachment.zip>

From bil at ccrma.Stanford.EDU  Mon Dec 20 07:11:55 2021
From: bil at ccrma.Stanford.EDU (bil at ccrma.Stanford.EDU)
Date: Mon, 20 Dec 2021 07:11:55 -0800
Subject: [CM] Possible bug with c-object & openlet
In-Reply-To: <CAG02pQhpUwUFJ-DGp+znDeCjRq8hyTEWb4Uz1urgD_1OTDNRUg@mail.gmail.com>
References: <CAG02pQjkxyXhPBm9vqLxb_TObmJMR-zwFu8k_BxQjLVkakJ+DQ@mail.gmail.com>
	<CAG02pQhpUwUFJ-DGp+znDeCjRq8hyTEWb4Uz1urgD_1OTDNRUg@mail.gmail.com>
Message-ID: <790a9065a0c9a871a8052fcce25c9ea9@ccrma.stanford.edu>

You need to gc protect the methods -- c_object_set_let
does not do that.  This is partly for speed and to save
space in the gc-protected-objects list, and also because
you might create the let holding the methods, then
any amount of time might go by before you make an
object, so the let has to be gc-protected anyway.
g_block_methods in s7test.scm is an example where
each block can be considered an instance of the
g_block class, and the let is protected once.



From chris.actondev at gmail.com  Mon Dec 20 10:00:19 2021
From: chris.actondev at gmail.com (Christos Vagias)
Date: Mon, 20 Dec 2021 20:00:19 +0200
Subject: [CM] Possible bug with c-object & openlet
In-Reply-To: <790a9065a0c9a871a8052fcce25c9ea9@ccrma.stanford.edu>
References: <CAG02pQjkxyXhPBm9vqLxb_TObmJMR-zwFu8k_BxQjLVkakJ+DQ@mail.gmail.com>
	<CAG02pQhpUwUFJ-DGp+znDeCjRq8hyTEWb4Uz1urgD_1OTDNRUg@mail.gmail.com>
	<790a9065a0c9a871a8052fcce25c9ea9@ccrma.stanford.edu>
Message-ID: <CAG02pQjQoCzeSiN0K+qRG3SuiyAd6vDBi34ZQTahbBCZ+gtmMg@mail.gmail.com>

Thanks for the tip Bil!
Good to know also about the reasoning behind this behaviour.

By paying a (belated) visit to the documentation I also saw the "Don't
forget to GC-protect the let!"...
It just seemed obvious to me that it would be protected. But either
manually protecting it, or storing it somewhere -causing it to be
protected- makes much sense.

Thanks again, and happy holidays!


On Mon, 20 Dec 2021 at 17:11, <bil at ccrma.stanford.edu> wrote:
>
> You need to gc protect the methods -- c_object_set_let
> does not do that.  This is partly for speed and to save
> space in the gc-protected-objects list, and also because
> you might create the let holding the methods, then
> any amount of time might go by before you make an
> object, so the let has to be gc-protected anyway.
> g_block_methods in s7test.scm is an example where
> each block can be considered an instance of the
> g_block class, and the let is protected once.
>


From john at jcoppens.com  Mon Dec 20 10:31:01 2021
From: john at jcoppens.com (John Coppens)
Date: Mon, 20 Dec 2021 15:31:01 -0300
Subject: [CM] Installation problem version 22 (21.9?)
Message-ID: <20211220153101.b8ada822b97082d56048ad20@jcoppens.com>

Hello all,

I'm trying to get snd version 22 (21.9?) running on a Slackware64-current system.

As far as I can see, 

./configure \
  --prefix=/usr \
  --libdir=/usr/lib${LIBDIRSUFFIX} \
  --sysconfdir=/etc \
  --localstatedir=/var \
  --mandir=/usr/man \
  --docdir=/usr/doc/$PRGNAM-$VERSION \
  --disable-static \
  --with-gui \
  --with-pulseaudio \
  --with-s7 \
  --build=$ARCH-slackware-linux

Make runs quietly...

Running snd in the source directory starts the non-gui version.

Running snd outside gives this:

$ snd
writing libc_s7.c
libc_s7.c:35:10: fatal error: s7.h: No such file or directory
   35 | #include "s7.h"
      |          ^~~~~~
compilation terminated.
gcc: error: libc_s7.o: No such file or directory
loading libc_s7.so
<1> 

So, it seems libc_s7.so doesn't get installed. It _does_ exist in
the source directory though. The message 'writing libc_s7.c' confuses
me a little. Why does this happen on snd startup?

After installing both libc_s7.so and s7.h by hand, I get a running snd,
but still no GUI.

Does this have anything to do with it? (from config.log):
	GX_FILES='NO_GUI_O_FILES'
	GX_HEADERS='NO_GUI_HEADERS'

or
	#define USE_NO_GUI 1

Help! I'm lost...

John


From bil at ccrma.Stanford.EDU  Mon Dec 20 11:01:05 2021
From: bil at ccrma.Stanford.EDU (bil at ccrma.Stanford.EDU)
Date: Mon, 20 Dec 2021 11:01:05 -0800
Subject: [CM] =?utf-8?q?Installation_problem_version_22_=2821=2E9=3F=29?=
In-Reply-To: <20211220153101.b8ada822b97082d56048ad20@jcoppens.com>
References: <20211220153101.b8ada822b97082d56048ad20@jcoppens.com>
Message-ID: <bca849f7877b3f3bb538247a793fdf74@ccrma.stanford.edu>

The no-gui Snd tries to load repl.scm for its repl
unless you pass -noinit (with -noinit you'll get
the world's more annoying repl).  To load repl.scm
you need to be in a directory with s7.h and maybe
some other such files -- I forget what's needed.

To get a GUI, you need Motif.  Snd used to work with
Gtk, but Gtk was constantly changing in major ways
that required full rewrites of the Snd code, and
after at least 3 of those, I removed all the Gtk
support.  I should have stayed with Gtk2.
Motif is still available in Fedora and Debian,
but I haven't looked at slackware in a very long time.



From bil at ccrma.Stanford.EDU  Mon Dec 20 11:09:37 2021
From: bil at ccrma.Stanford.EDU (bil at ccrma.Stanford.EDU)
Date: Mon, 20 Dec 2021 11:09:37 -0800
Subject: [CM] =?utf-8?q?Installation_problem_version_22_=2821=2E9=3F=29?=
In-Reply-To: <20211220153101.b8ada822b97082d56048ad20@jcoppens.com>
References: <20211220153101.b8ada822b97082d56048ad20@jcoppens.com>
Message-ID: <ec70b7e7a30dcaa88ed1ae4a000576ab@ccrma.stanford.edu>

Another possibility is notcurses (which is also
changing rapidly, but the changes don't impact Snd
or s7 as much).  For that you need the notcurses-core
library (the full notcurses library requires more
than a GByte of ancillary libraries, overkill for
a simple repl).  Use the configuration switch
--with-notcurses for it.



From tito.01beta at gmail.com  Mon Dec 20 23:58:00 2021
From: tito.01beta at gmail.com (Tito Latini)
Date: Tue, 21 Dec 2021 08:58:00 +0100
Subject: [CM] Installation problem version 22 (21.9?)
In-Reply-To: <bca849f7877b3f3bb538247a793fdf74@ccrma.stanford.edu>
References: <20211220153101.b8ada822b97082d56048ad20@jcoppens.com>
	<bca849f7877b3f3bb538247a793fdf74@ccrma.stanford.edu>
Message-ID: <20211221075759.GA7236@vis.roboris>

> Motif is still available in Fedora and Debian,
> but I haven't looked at slackware in a very long time.

My distro is slackware 14.2 but motif is also present on
slackware64-current.

--with-gui doesn't work:

./configure --with-gui
[...]
graphics toolkit.......: None

but --with-motif is ok:

./configure --with-motif
[...]
graphics toolkit.......: Motif


From bil at ccrma.Stanford.EDU  Tue Dec 21 06:09:11 2021
From: bil at ccrma.Stanford.EDU (bil at ccrma.Stanford.EDU)
Date: Tue, 21 Dec 2021 06:09:11 -0800
Subject: [CM] =?utf-8?q?Installation_problem_version_22_=2821=2E9=3F=29?=
In-Reply-To: <20211221075759.GA7236@vis.roboris>
References: <20211220153101.b8ada822b97082d56048ad20@jcoppens.com>
	<bca849f7877b3f3bb538247a793fdf74@ccrma.stanford.edu>
	<20211221075759.GA7236@vis.roboris>
Message-ID: <cc46c8ccb65d2485005b95141ba50ae9@ccrma.stanford.edu>

Thanks for the info.  I'll change --with-gui to be
the same as --with-motif.  Motif doesn't have
pkg-config support, so it's hard to tell whether
Motif is available in advance.  But --with-gui is
going to be confusing in either case.  (I was
looking for a Gtk replacement for awhile, then
other things intervened).




From wdouglass at carnegierobotics.com  Wed Dec 22 13:07:22 2021
From: wdouglass at carnegierobotics.com (Woody Douglass)
Date: Wed, 22 Dec 2021 21:07:22 +0000
Subject: [CM] Reducing S7 'real' precision
Message-ID: <512cbbced3dc5c61cdef91023a4521f409bec6a5.camel@carnegierobotics.com>

Bill et all --

I've been using S7 for doing CV and graphics work; this work often
involves giant lookup tables (5 terms per pixel, 9600x4800 resolution,
each table ends up being ~1.8 Gigabytes)
I can cut that in half by using floats instead of doubles (Precision
isn't a really important factor here)

these lookup tables are currently implemented as s7 float-vectors

I'm finding myself tempted to patch s7.h with this:
typedef float s7_double;

but it *feels* like i'm going to get myself into trouble. Has anyone
tried reducing s7's floating-point precision, or am i falling into a
dangerous rabbit-hole here? should i just reimplement my tables as C-
objects and move on?

Any advice would be greatly appreciated!

Thanks,
Woody Douglass



From bil at ccrma.Stanford.EDU  Wed Dec 22 13:24:40 2021
From: bil at ccrma.Stanford.EDU (bil at ccrma.Stanford.EDU)
Date: Wed, 22 Dec 2021 13:24:40 -0800
Subject: [CM] Reducing S7 'real' precision
In-Reply-To: <512cbbced3dc5c61cdef91023a4521f409bec6a5.camel@carnegierobotics.com>
References: <512cbbced3dc5c61cdef91023a4521f409bec6a5.camel@carnegierobotics.com>
Message-ID: <b4cade0862734b54126b569caa2914c2@ccrma.stanford.edu>

It might work -- I just tried it and got the sorts of
errors from s7test.scm that you'd expect, but nothing
horrifying.  I haven't changed those typedefs in a
very long time -- I think s7_int has to be 64 bits.



From elronnd at elronnd.net  Wed Dec 22 16:24:35 2021
From: elronnd at elronnd.net (Elijah Stone)
Date: Wed, 22 Dec 2021 16:24:35 -0800 (PST)
Subject: [CM] Reducing S7 'real' precision
In-Reply-To: <512cbbced3dc5c61cdef91023a4521f409bec6a5.camel@carnegierobotics.com>
References: <512cbbced3dc5c61cdef91023a4521f409bec6a5.camel@carnegierobotics.com>
Message-ID: <6ab8de5f-229f-bd75-a8d-b1744941734@elronnd.net>

I was doing some stuff with opengl and so made the same modification to 
avoid conversions at edges.  I did not notice any odd behaviour.  (But, I 
did not ultimately end up doing much with that project; so there may be 
edge cases.)

Assuming that s7 works on 32-bit systems, it must already handle the case 
where an s7_double is not the same size as a pointer.  So I would be 
surprised if there were serious issues.

  -E

On Wed, 22 Dec 2021, Woody Douglass wrote:

> Bill et all --
>
> I've been using S7 for doing CV and graphics work; this work often
> involves giant lookup tables (5 terms per pixel, 9600x4800 resolution,
> each table ends up being ~1.8 Gigabytes)
> I can cut that in half by using floats instead of doubles (Precision
> isn't a really important factor here)
>
> these lookup tables are currently implemented as s7 float-vectors
>
> I'm finding myself tempted to patch s7.h with this:
> typedef float s7_double;
>
> but it *feels* like i'm going to get myself into trouble. Has anyone
> tried reducing s7's floating-point precision, or am i falling into a
> dangerous rabbit-hole here? should i just reimplement my tables as C-
> objects and move on?
>
> Any advice would be greatly appreciated!
>
> Thanks,
> Woody Douglass
>
> _______________________________________________
> Cmdist mailing list
> Cmdist at ccrma.stanford.edu
> https://cm-mail.stanford.edu/mailman/listinfo/cmdist
>


From chris.actondev at gmail.com  Thu Dec 30 12:41:51 2021
From: chris.actondev at gmail.com (Christos Vagias)
Date: Thu, 30 Dec 2021 21:41:51 +0100
Subject: [CM] Bug regarding hooks
Message-ID: <CAG02pQjpZgHLEdFXW3Ufs=vBoUbxa2CXUKbQ1G_gZ2DuZQAnTA@mail.gmail.com>

Hi Bil,

I'm attaching a demo program demonstrating the bug. It involves hooks,
setters, call-with-input-file, call-with-output-string. Not sure which
is the culprit.

- g++ ./main.cpp s7.o -ldl -I.
- ./a.out

As main.scm is, s7_load_file result is the output of the setter
triggered by (set! (state 'file) "foo.txt") instead of 'ok (at the end
of the file)

Thanks,
Christos Vagias
-------------- next part --------------
A non-text attachment was scrubbed...
Name: bug-hooks.zip
Type: application/zip
Size: 1142 bytes
Desc: not available
URL: <https://cm-mail.stanford.edu/pipermail/cmdist/attachments/20211230/e3fa0229/attachment.zip>

From bil at ccrma.Stanford.EDU  Thu Dec 30 16:11:01 2021
From: bil at ccrma.Stanford.EDU (bil at ccrma.Stanford.EDU)
Date: Thu, 30 Dec 2021 16:11:01 -0800
Subject: [CM] Bug regarding hooks
In-Reply-To: <CAG02pQjpZgHLEdFXW3Ufs=vBoUbxa2CXUKbQ1G_gZ2DuZQAnTA@mail.gmail.com>
References: <CAG02pQjpZgHLEdFXW3Ufs=vBoUbxa2CXUKbQ1G_gZ2DuZQAnTA@mail.gmail.com>
Message-ID: <bddce5b25a1e0b7f4eb0c8fc137ad3aa@ccrma.stanford.edu>

Thanks for the very clear bug report!  I don't
immediately see what's causing it -- will poke
at it tomorrow.



From bil at ccrma.Stanford.EDU  Fri Dec 31 12:21:58 2021
From: bil at ccrma.Stanford.EDU (bil at ccrma.Stanford.EDU)
Date: Fri, 31 Dec 2021 12:21:58 -0800
Subject: [CM] Bug regarding hooks
In-Reply-To: <CAG02pQjpZgHLEdFXW3Ufs=vBoUbxa2CXUKbQ1G_gZ2DuZQAnTA@mail.gmail.com>
References: <CAG02pQjpZgHLEdFXW3Ufs=vBoUbxa2CXUKbQ1G_gZ2DuZQAnTA@mail.gmail.com>
Message-ID: <d5885cf13d2de18834d53ff6fe668b74@ccrma.stanford.edu>

Here's a change that might be interesting.  Change call_setter (ca line 
46598) to:

static s7_pointer call_setter(s7_scheme *sc, s7_pointer slot, s7_pointer 
new_value)
{
   s7_pointer func = slot_setter(slot);
   if (!is_any_procedure(func))
     return(new_value);

   if (is_c_function(func))
     return(call_c_function_setter(sc, func, slot_symbol(slot), 
new_value));

   sc->args = (has_let_arg(func)) ?
                list_3(sc, slot_symbol(slot), new_value, sc->curlet) :
	       list_2(sc, slot_symbol(slot), new_value);
   return(s7_call(sc, func, sc->args));
}

I think the problem is that the error (in the setter function) longjmps
which (in the old call_setter) exited the recursive eval call, but
did not fixup the eval_done on the scheme stack.  A simple example:

(define (fc in)
   (catch 'wrong-type-arg
     (lambda ()
       (+ in 2))
     (lambda (type info)
       type)))

(define state
   (let ()
     (define file #f)
     (define contents #f)
     (set! (setter 'file)
	  (lambda (s v)
	    (set! contents (fc #\1))
	    v))
     (curlet)))

(set! (state 'file) 321)

(format *stderr* "done: ~S ~S~%" (state 'file) (state 'contents))