On Fri, Aug 26, 2022 at 9:28 AM <b...@ccrma.stanford.edu> wrote:
> *error-hook* is only called if there is no catch; it resets the s7 stack
> when it returns, so you're back at the top level. My first thought is
> that you need a catch in convert.scm where you do the s7_call. Maybe
> I have the wrong model of what's happening.
>
> The s7 stack can be viewed via (*s7* 'stack); it is independent of the
> C stack (I assume that's what you're seeing with backtrace). I don't
> think the GC is the culprit. s7_show_stack can give an abbreviated
> view of the s7 stack from C (you'll need a declaration -- it's not
> in s7.h, but it is accessible globally -- I thought of it as a
> debugging aid -- (*s7* 'stack) is sometimes very verbose).
>
Looks like the s7 stack is the issue. I got rid of the error-hook. Now my
'return' statement hangs. Here is the code, details omitted:
for each dune file (composed of "stanza" sexps):
while(true) {
s7_pointer stanza = s7_read(s7, port);
s7_show_stack(s7);
errmsg = s7_get_output_string(s7, s7_current_error_port(s7));
if ((errmsg) && (*errmsg)) {
if (strstr(errmsg,
";read-error (\"unexpected close paren:") != NULL) {
... fix problem, reading entire dune file ...
break;
}
}
if (stanza == s7_eof_object(s7)) {
break;
}
... do stuff with stanza ...
}
If the file has no errors, the stack looks like this:
stack:
let*1
let*1
eval_done
gc_protect
But when we try to s7_read a stanza with the dot syntax error, the stack is:
reading stanza
stack:
read_list
read_list
eval_done
barrier
let*1
let*1
eval_done
gc_protect
I can still fix the error by reading the file into a string, fixing it, and
then s7_read the string-port. But now my return hangs.
Is there any way to unwind the stack past "barrier"? Or is there a way to
call s7_read with a catch that will allow me to recover in situ?
Thanks,
Gregg
_______________________________________________
Cmdist mailing list
Cmdist@ccrma.stanford.edu
https://cm-mail.stanford.edu/mailman/listinfo/cmdist
