[CM] fn defined in C returns to wrong place

[Gregg Reynolds]

On Fri, Aug 26, 2022 at 9:28 AM <bil at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cm-mail.stanford.edu/pipermail/cmdist/attachments/20220826/19b66e6e/attachment-0001.html>