PLEASE: debugging embedded guile code

PLEASE: debugging embedded guile code

[Joris van der Hoeven]

Hi,

I am sorry to bother you again with the same question
as a few weeks ago, but I think that it is a crucial point
if you want Guile to be used as an extension language.

When I run Guile interactively, and my code contains an error,
then I get a nice error message with the location (file name,
line number, column) of the error. I would like to have
something similar for errors which occur in embedded Guile code.

So: what should I do in order to enable debugging support
for embedded Guile code? How can I retrieve the location of
a possible error when calling guile code from the main program?

Now these questions certainly do have an answer, because it is
possible to debug interactive programs. However, I have been
unable to retrieve this information from the sources after
one day of study :^((( Maybe someone can tell me at least
who wrote the interactive Guile shell?

Best wishes, Joris


-----------------------------------------------------------
Joris van der Hoeven <vdhoeven@texmacs.org>
http://www.texmacs.org: GNU TeXmacs scientific text editor
http://www.math.u-psud.fr/~vdhoeven: personal homepage
-----------------------------------------------------------



_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel

Re: PLEASE: debugging embedded guile code

[Dale P. Smith]

On Tue, 25 Feb 2003 15:19:54 +0100 (MET)
Joris van der Hoeven <TeXmacs@math.u-psud.fr> wrote:

> 
> Hi,
> 
> I am sorry to bother you again with the same question
> as a few weeks ago, but I think that it is a crucial point
> if you want Guile to be used as an extension language.
> 
> When I run Guile interactively, and my code contains an error,
> then I get a nice error message with the location (file name,
> line number, column) of the error. I would like to have
> something similar for errors which occur in embedded Guile code.
> 
> So: what should I do in order to enable debugging support
> for embedded Guile code? How can I retrieve the location of
> a possible error when calling guile code from the main program?
> 
> Now these questions certainly do have an answer, because it is
> possible to debug interactive programs. However, I have been
> unable to retrieve this information from the sources after
> one day of study :^((( Maybe someone can tell me at least
> who wrote the interactive Guile shell?

The answer is lazy-catch.

Normally, you would handle exceptions with catch, but by the time catch
gets the exception, all the context of the error is lost.  So you need
to catch the error with lazy-catch instead, which still has the error
context.  Lazy-catch is not allowed to return, you must re-throw or
abort, so you must also catch the throw from lazy-catch.

Here is how I did it in mod-guile:


SCM
mg_lazy_handler(void *data, SCM tag, SCM throw_args)
{
  SCM eport = scm_current_error_port();

  /* header only tag.  Just return */
  if (SCM_EQ_P(header_only_key, tag))
    scm_ithrow(tag, throw_args, 1);
   
  /* Error report */
  scm_putc('[', eport);
  scm_puts(ap_get_time(), eport);
  scm_puts("] mod_guile:", eport);
  if (!SCM_DEVAL_P)
    scm_puts(" (enable debugging evaluator for backtrace output)", eport);
  scm_putc('\n', eport);

  scm_handle_by_message_noexit(data, tag, throw_args);
  scm_force_output(eport);
  scm_ithrow(tag, throw_args, 1);
  return SCM_UNSPECIFIED; /* never returns */
}

SCM
mg_empty_handler(void *data, SCM tag, SCM args)
{
  /* header only tag.  Just return */
  if (SCM_EQ_P(header_only_key, tag))
      return SCM_UNSPECIFIED;

  /* This (non SCM_UNSPECIFIED) return causes the handler to return an
     error back to apache */
  return SCM_BOOL_F;
}


static SCM
mg_lazy_eval_file(char *file)
{
  return scm_internal_lazy_catch(SCM_BOOL_T,
				 (scm_t_catch_body) scm_c_primitive_load, file,
				 (scm_t_catch_handler) mg_lazy_handler, file);
}

static SCM
mg_eval_file(char *file)
{
  return scm_internal_catch(SCM_BOOL_T,
			    (scm_t_catch_body) mg_lazy_eval_file, file,
			    (scm_t_catch_handler) mg_empty_handler, file);
}



-- 
Dale P. Smith
Senior Systems Consultant,      | Treasurer,
Altus Technologies Corporation  | Cleveland Linux Users Group
dsmith@altustech.com            | http://cleveland.lug.net
440-746-9000 x239               |


_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user

Re: PLEASE: debugging embedded guile code

[Neil Jerram]

>>>>> "Dale" == Dale P Smith <dsmith@altustech.com> writes:

    Dale> On Tue, 25 Feb 2003 15:19:54 +0100 (MET)
    Dale> Joris van der Hoeven <TeXmacs@math.u-psud.fr> wrote:

    >> So: what should I do in order to enable debugging support
    >> for embedded Guile code? How can I retrieve the location of
    >> a possible error when calling guile code from the main program?

    Dale> The answer is lazy-catch. [...]

    Dale> Here is how I did it in mod-guile:

    Dale> SCM
    Dale> mg_lazy_handler(void *data, SCM tag, SCM throw_args)
    Dale> {
    Dale>   SCM eport = scm_current_error_port(); [...]

I'm curious about this because the question of error handling keeps
popping up and I'm wondering whether our current solution is good
enough.  (With a strong suspicion that it isn't.)

One thing I'm not sure I understand is why you want (or perhaps need)
to do this lazy-catch in C rather than in Scheme, since it would be
much easier in Scheme.  Can you explain?

Thanks,
        Neil



_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user

Re: PLEASE: debugging embedded guile code

[Bruce Korb]

Neil Jerram wrote:
>     >> So: what should I do in order to enable debugging support
>     >> for embedded Guile code? How can I retrieve the location of
>     >> a possible error when calling guile code from the main program?

>     Dale> Here is how I did it in mod-guile:
> 
>     Dale> SCM
>     Dale> mg_lazy_handler(void *data, SCM tag, SCM throw_args)
>     Dale> {
>     Dale>   SCM eport = scm_current_error_port(); [...]
> 
> I'm curious about this because the question of error handling keeps
> popping up and I'm wondering whether our current solution is good
> enough.  (With a strong suspicion that it isn't.)
> 
> One thing I'm not sure I understand is why you want (or perhaps need)
> to do this lazy-catch in C rather than in Scheme, since it would be
> much easier in Scheme.  Can you explain?

The need is to be able to point our clients to problems in the
Scheme code.  We (or, at least, I) know where in our client's
input we are when we hand a string off to Guile for evaluation.
I'd like to be able to tell Guile what the current file name
and line number so that when it emits an error message, Guile
can refer to our client's source file.  As it is, I have to
set an atexit routine.  All it is able to tell is that Guile
called exit(3C) and it must now emit a generic "this is where
we were when Guile called exit" message:

    switch (procState) {
    case PROC_STATE_EMITTING:
    case PROC_STATE_INCLUDING:
        /*
         *  A library (viz., Guile) procedure has called exit(3C).
         *  The AutoGen abort paths all set procState to PROC_STATE_ABORTING.
         */
        if (*pzOopsPrefix != NUL) {
            /*
             *  Emit the CGI page header for an error message.
             */
            fputs( pzOopsPrefix, stderr );
            pzOopsPrefix = "";
        }

        fprintf( stderr, zErr, pCurTemplate->pzFileName, pCurMacro->lineNo );

Of course, I have to do a bunch of magic anyway because if there
is an error exit, I may or may not have to emit a CGI-style preamble:

> static const char zOops[] =
> "Content-type: text/plain\n\n"
> "AutoGen form processing error:\n";

but it would still be nice to have the above file/line woven into
the native Guile message as it is for the interactive guile program.


_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user

Re: PLEASE: debugging embedded guile code

[Neil Jerram]

>>>>> "Bruce" == Bruce Korb <bkorb@veritas.com> writes:

    >> One thing I'm not sure I understand is why you want (or perhaps need)
    >> to do this lazy-catch in C rather than in Scheme, since it would be
    >> much easier in Scheme.  Can you explain?

    Bruce> The need is to be able to point our clients to problems in the
    Bruce> Scheme code.  We (or, at least, I) know where in our client's
    Bruce> input we are when we hand a string off to Guile for evaluation.
    Bruce> I'd like to be able to tell Guile what the current file name
    Bruce> and line number so that when it emits an error message, Guile
    Bruce> can refer to our client's source file.  As it is, I have to
    Bruce> set an atexit routine.  All it is able to tell is that Guile
    Bruce> called exit(3C) and it must now emit a generic "this is where
    Bruce> we were when Guile called exit" message:

Now you've really lost me, I'm afraid.  Why don't you use a catch,
either in Scheme or in C, to catch the error?

        Neil



_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user

Re: PLEASE: debugging embedded guile code

[Bruce Korb]

Neil Jerram wrote:

> Now you've really lost me, I'm afraid.  Why don't you use a catch,
> either in Scheme or in C, to catch the error?

Yes, I can catch it.  Now what do I print out?  I know the file
and line where the scheme text started, but I don't know what
Guile's objections are and I don't know how far into the text
the problem text was.  If it is in the docs, then I didn't find
it when I read it a few years ago.  :-)  It's also hard to read
dark blue on a black background (glug page).  So I generally get
by by reading source code and I don't do it unless I really have
to.  I don't "really have to" because I can "catch" the exit call.


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel

Re: PLEASE: debugging embedded guile code

[Neil Jerram]

>>>>> "Bruce" == Bruce Korb <bkorb@veritas.com> writes:

    Bruce> Neil Jerram wrote:
    >> Now you've really lost me, I'm afraid.  Why don't you use a catch,
    >> either in Scheme or in C, to catch the error?

    Bruce> Yes, I can catch it.  Now what do I print out?  I know the
    Bruce> file and line where the scheme text started, but I don't
    Bruce> know what Guile's objections are and I don't know how far
    Bruce> into the text the problem text was.

OK.  (I don't see what this has to do with atexit, but never mind
that.)  The current situation is that:

- Guile's objection is encoded:

  - primarily in the throw key (a symbol) that is the first arg passed
    to the catch handler, e.g. 'misc-error

  - secondarily in the remaining throw args, in a way which is
    key-dependent and very poorly documented

- the location where the problem arose is not supplied by default, but
  can be found out by capturing the current stack - (make-stack #t) -
  in a lazy-catch handler.

My impression from various emails is that there may be issues with
this model, so my purpose here is to explore whether there are issues
and, if so, to address them.

So, given this description, can you be more precise about which (if
any) parts of it are causing you trouble?

Thanks,
        Neil



_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel

Re: PLEASE: debugging embedded guile code

[Bruce Korb]

Neil Jerram wrote:

> So, given this description, can you be more precise about which (if
> any) parts of it are causing you trouble?

I guess I'm really lazy.  I'm interested in playing with my project
and I'm completely _un_interested in figuring out the inner workings
of Guile error handling.  But I have a problem.  Sometimes my clients
provide my project with a scheme script that is many lines long.
I merrily hand the whole string off to gh_eval_str() to deal with.
Somewhere in that string, Guile becomes confused and says, "this is
confusing" and calls exit(3C).  My client emails me and says, "Your
program said it was confused but won't tell me where or why."  Well,
I do print out where the Scheme script starts, but not where in the
script the confusion was.  It's adequate for me because I generally
keep my Scheme scripts to under a half dozen lines.  It's a problem.

So, what I would really like:

Explicit, unambiguous directions on exactly how to get the Guile library
to print out the same error messages it does when running as part
of the "guile" independent program.  That message has sufficient
contextual information to help the user debug the problem.  e.g.:

> guile> (define foo bar)
> standard input:1:1: In expression (define foo bar):
> standard input:1:1: Unbound variable: bar
> ABORT: (unbound-variable)

as opposed to:

> $ autogen --no-def -Txx.tpl --base=x
> ERROR: Unbound variable: bar
> AutoGen ABENDED in template xx.tpl line 2

the library message here consists of ``ERROR: Unbound variable: bar''
and leaves out ``In expression (define foo bar):'' and also the line
and column numbers.  (This is a trivial case and obviously easy to
diagnose.)

Example solutions:

*  gh_eval_file_line_str( pz_text, state->file_name, state->line_no )

*  a detailed example of gh_eval_str_with_catch that shows how to print the
   broken expression and how to describe where in the input string that
   expression was encountered.  Perhaps this can be accomplished by
   adding a file name and incrementing the line number passed along in
   the error description list, then forwarding to the normal handler?

Frankly, I'd prefer the first, but I'd need to understand the latter
anyway just to be compatible with Guile libraries without this new gh_*
function.  :-)  Heck, with a proper implementation of gh_eval_file_line_str
I could just tack it into my program and configure it if not present.  :)


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel

Re: PLEASE: debugging embedded guile code

[Paul Jarc]

Bruce Korb <bkorb@veritas.com> wrote:
> Explicit, unambiguous directions on exactly how to get the Guile library
> to print out the same error messages it does when running as part
> of the "guile" independent program.

You'll need this:     (read-enable 'positions)
And maybe this:       (debug-enable 'show-file-name)
Then you can do this: (source-property obj 'line)
(You can also use 'column and 'filename.)


paul


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel

Re: PLEASE: debugging embedded guile code

[Bruce Korb]

prj@po.cwru.edu wrote:
> 
> Bruce Korb <bkorb@veritas.com> wrote:
> > Explicit, unambiguous directions on exactly how to get the Guile library
> > to print out the same error messages it does when running as part
> > of the "guile" independent program.
> 
> You'll need this:     (read-enable 'positions)
> And maybe this:       (debug-enable 'show-file-name)
> Then you can do this: (source-property obj 'line)
> (You can also use 'column and 'filename.)

That's helpful.  'course the file name is known by my code and not Guile.
And it will vary from one gh_eval_str call to another.
And the line number must be incremented by the line number I have.
Do I invoke these at the start of my run?  What does the catch
code look like?  Or, should I still be relying on the native
catch/fail-exit code?  If that, then I have to correct its impression
about the file and line numbers.

Thank you! - Bruce


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel

Re: PLEASE: debugging embedded guile code

[Neil Jerram]

>>>>> "Bruce" == Bruce Korb <bkorb@veritas.com> writes:

    Bruce> I guess I'm really lazy.  I'm interested in playing with my project
    Bruce> and I'm completely _un_interested in figuring out the inner workings
    Bruce> of Guile error handling.  But I have a problem.  Sometimes my clients
    Bruce> provide my project with a scheme script that is many lines long.
    Bruce> I merrily hand the whole string off to gh_eval_str() to deal with.
    Bruce> Somewhere in that string, Guile becomes confused and says, "this is
    Bruce> confusing" and calls exit(3C).  My client emails me and says, "Your
    Bruce> program said it was confused but won't tell me where or why."  Well,
    Bruce> I do print out where the Scheme script starts, but not where in the
    Bruce> script the confusion was.  It's adequate for me because I generally
    Bruce> keep my Scheme scripts to under a half dozen lines.  It's a problem.

    Bruce> So, what I would really like:

    Bruce> Explicit, unambiguous directions on exactly how to get the Guile library
    Bruce> to print out the same error messages it does when running as part
    Bruce> of the "guile" independent program.  [...]

OK, I understand.  There are three parts to the answer that I think
you need.

1. You want an evaluator with a catch handler,
   e.g. gh_eval_str_with_catch, instead of plain gh_eval_str, which
   just exits.

2. The handler needs to call display-error, which is the function that
   displays all the useful information.

3. In order for display-error to show maximum useful information, the
   port that the source code came from must have a name.
   Unfortunately the current default is that string ports are unnamed.

If I were you, I'd do as much of this as possible in Scheme, e.g.:

(use-modules (ice-9 stack-catch))

(define (eval-client-input str)
  (stack-catch #t
    (lambda ()
      (call-with-input-string str
        (lambda (p)
          (set-port-filename! p "<string port>")
          (list (primitive-eval (read p))))))
    (lambda (key . args)
      ;; [1]
      (apply display-error (fluid-ref the-last-stack)
                           (current-error-port)
                           args)
      (set! stack-saved? #f)
      #f)))

Basic testing...

guile> (eval-client-input "(define foo bar)")
<string port>:1:1: In expression (define foo bar):
<string port>:1:1: Unbound variable: bar
#f
guile> (eval-client-input "(let ((x 1)) (* x x unknown))")
<string port>:1:14: While evaluating arguments to * in expression (* x x ...):
<string port>:1:14: Unbound variable: unknown
#f
guile> (eval-client-input "\
... (for-each (lambda (x)
...             (display (* x x))
...             (newline))
...           number-list)
... ")
<string port>:1:1: While evaluating arguments to for-each in expression (for-each
(lambda # # ...) number-list):
<string port>:1:1: Unbound variable: number-list
#f
guile> (eval-client-input "\
... (for-each (lambda (x)
...             (display (* x x))
...             (newline))
...           (cdr number-list))
... ")
<string port>:4:11: While evaluating arguments to cdr in expression (cdr number-list):
<string port>:4:11: Unbound variable: number-list
#f

You can call `eval-client-input' from C using scm_c_lookup and
scm_call_1.

Note - the code above assumes that `args' has the right structure (see
doc for display-error), which is true for all the exceptions generated
by Guile itself.  If you want to handle exceptions generated by your
own or your client's code, you need to add code at [1] to identify
non-core exceptions and turn their throw args into suitable parameters
for display-error.

Does this help?

        Neil



_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel

Re: PLEASE: debugging embedded guile code

[Bruce Korb]

Neil Jerram wrote:
> 
> Does this help?

Yes.  A lot.  I think I know why I didn't think of it before, though.  :-)

> OK, I understand.  There are three parts to the answer that I think
> you need.
> 
> 1. You want an evaluator with a catch handler,
>    e.g. gh_eval_str_with_catch, instead of plain gh_eval_str, which
>    just exits.

I knew that, but didn't have a good idea about how to make it work.

> 2. The handler needs to call display-error, which is the function that
>    displays all the useful information.

OK.

> 3. In order for display-error to show maximum useful information, the
>    port that the source code came from must have a name.
>    Unfortunately the current default is that string ports are unnamed.
> 
> If I were you, I'd do as much of this as possible in Scheme, e.g.:
> 
> (use-modules (ice-9 stack-catch))
> 
> (define (eval-client-input str)
>   (stack-catch #t
>     (lambda ()
>       (call-with-input-string str
>         (lambda (p)
>           (set-port-filename! p "<string port>")
>           (list (primitive-eval (read p))))))
>     (lambda (key . args)
>       ;; [1]
>       (apply display-error (fluid-ref the-last-stack)
>                            (current-error-port)
>                            args)
>       (set! stack-saved? #f)
>       #f)))

except instead of "<string port>" I'd supply the name of the
file I was reading to get the Scheme code.  Right near [1]
I would want to add the starting line number to the evaluator's
notion of what the current line number is.  If I'm on line 100
of my clients input text, it would be nice for the display-error
code to display a line number 99 higher than otherwise.  I'd
do this by using some of my own functions:

> (define (eval-client-input str)
>   (stack-catch #t
>     (lambda ()
>       (call-with-input-string str
>         (lambda (p)
>           (set-port-filename! p (tpl-file))
>           (SET-PORT-FILELINE! p (string->number (tpl-file-line "%2$d")))
>           (list (primitive-eval (read p))))))
>     (lambda (key . args)
>       ;; [1]
>       (apply display-error (fluid-ref the-last-stack)
>                            (current-error-port)
>                            args)
>       (set! stack-saved? #f)
>       #f)))

> Basic testing...  [[elided]]

> You can call `eval-client-input' from C using scm_c_lookup and
> scm_call_1.
> 
> Note - the code above assumes that `args' has the right structure (see
> doc for display-error), which is true for all the exceptions generated
> by Guile itself.  If you want to handle exceptions generated by your
> own or your client's code, you need to add code at [1] to identify
> non-core exceptions and turn their throw args into suitable parameters
> for display-error.

I think I'd want to test for a client error list massaging procedure
and invoke that if present.  The only places I throw errors, I call
scm_wrong_type_arg directly.  I would guess it would have args set up okay. :)


_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user

Re: PLEASE: debugging embedded guile code

[Neil Jerram]

>>>>> "Bruce" == Bruce Korb <bkorb@veritas.com> writes:

    Bruce> Neil Jerram wrote:
    >> 
    >> Does this help?

    Bruce> Yes.  A lot.  I think I know why I didn't think of it
    Bruce> before, though.  :-)

:-)

    Bruce> except instead of "<string port>" I'd supply the name of the
    Bruce> file I was reading to get the Scheme code.

Good idea.  You might check out `emacs-load' in (ice-9 emacs) which
uses the same trick to set port name and position for code sent to it
from Emacs.

    Bruce> Right near [1] I would want to add the starting line number
    Bruce> to the evaluator's notion of what the current line number
    Bruce> is.  If I'm on line 100 of my clients input text, it would
    Bruce> be nice for the display-error code to display a line number
    Bruce> 99 higher than otherwise.  I'd do this by using some of my
    Bruce> own functions:

    >> (define (eval-client-input str)
    >>   (stack-catch #t
    >>     (lambda ()
    >>       (call-with-input-string str
    >>         (lambda (p)
    >>           (set-port-filename! p (tpl-file))
    >>           (SET-PORT-FILELINE! p (string->number (tpl-file-line "%2$d")))
    >>           (list (primitive-eval (read p))))))
    >>     (lambda (key . args)
    >>       ;; [1]
    >>       (apply display-error (fluid-ref the-last-stack)
    >>                            (current-error-port)
    >>                            args)
    >>       (set! stack-saved? #f)
    >>       #f)))

Exactly (except that set-port-fileline! is actually set-port-line!).

    >> Note - the code above assumes that `args' has the right
    >> structure (see doc for display-error), which is true for all
    >> the exceptions generated by Guile itself.  If you want to
    >> handle exceptions generated by your own or your client's code,
    >> you need to add code at [1] to identify non-core exceptions and
    >> turn their throw args into suitable parameters for
    >> display-error.

    Bruce> I think I'd want to test for a client error list massaging
    Bruce> procedure and invoke that if present.

Yes, I've been thinking about a mechanism for this, probably
GOOPS-based.  My thinking now (much advanced by this thread) is that
there are 3 points of weakness in the error handling system:

1. No documentation :-)

2. No mechanism for relating the throw or error args at the point
   where an exception is raised to how they should be interpreted or
   displayed by the catch handler.

3. The fragile interdependencies of stack-catch,
   lazy-handler-dispatch, the-last-stack and stack-saved?

We can live with 3 for a while longer, but I think it won't be too
hard to specify a nice mechanism for 2; so I'd like to do that and
then document the whole thing.

    Bruce> The only places I throw errors, I call scm_wrong_type_arg
    Bruce> directly.  I would guess it would have args set up okay. :)

Yes, I believe so.  Anything that goes through scm_error will be OK.

        Neil



_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user

Re: PLEASE: debugging embedded guile code

[Bruce Korb]

Neil Jerram wrote:

Hi Neil,

Back to this again:

>     >> (define client-input "")
>     >> (define (eval-client-input str)
>     >>   (stack-catch #t
>     >>     (lambda ()
>     >>       (call-with-input-string str
>     >>         (lambda (p)
>     >>           (set-port-filename! p (tpl-file))
>     >>           (set-port-line! p (string->number (tpl-file-line "%2$d")))
>     >>           (list (primitive-eval (read p))))))
>     >>     (lambda (key . args)
>     >>       ;; [1]
>     >>       (apply display-error (fluid-ref the-last-stack)
>     >>                            (current-error-port)
>     >>                            args)
>     >>       (set! stack-saved? #f)
>     >>       #f)))

> 1. No documentation :-)

Based on your example, I would need to emit this to libguile:

  (eval-client-input "...whatever...")

The problem is that the ``...whatever...'' is likely to often include
double quotes, backslashes and all kinds of interesting stuff.
I don't particularly want to go over the string and reformat it
so that the reader can reconstruct what I already have in hand.
What I want to do is along these lines:

>   {
>     SCM str = gh_str02scm( "...whatever..." );
>     scm_set_x( client_input_scm, str );
>     gh_eval_str( "(eval-client-input client-input)" );
>   }

of course, there _is_ no scm_set_x procedure and scm_m_set_x is indecipherable:

> /* Will go into the RnRS module when Guile is factorized.
> SCM_SYNTAX (s_set_x, "set!", scm_makmmacro, scm_m_set_x); */
> static const char s_set_x[] = "set!";
> SCM_GLOBAL_SYMBOL (scm_sym_set_x, s_set_x);
> 
> SCM
> scm_m_set_x (SCM xorig, SCM env SCM_UNUSED)
> {
>   SCM x = SCM_CDR (xorig);
>   SCM_ASSYNT (scm_ilength (x) == 2, scm_s_expression, s_set_x);
>   SCM_ASSYNT (SCM_SYMBOLP (SCM_CAR (x)), scm_s_variable, s_set_x);
>   return scm_cons (SCM_IM_SET_X, x);
> }

and it would be nice to figure out how to convert the string, "client-input"
into an SCM that is client-input.  :)


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel

Re: PLEASE: debugging embedded guile code

[Neil Jerram]

>>>>> "Bruce" == Bruce Korb <bkorb@veritas.com> writes:

    Bruce> Based on your example, I would need to emit this to libguile:

    Bruce>   (eval-client-input "...whatever...")

    Bruce> The problem is that the ``...whatever...'' is likely to
    Bruce> often include double quotes, backslashes and all kinds of
    Bruce> interesting stuff.  I don't particularly want to go over
    Bruce> the string and reformat it so that the reader can
    Bruce> reconstruct what I already have in hand.

You don't have to.  You can do something like this:

   SCM str = gh_str02scm( "...whatever..." );
   SCM proc = scm_c_lookup( "eval-client-input" );
   scm_call_1(proc, str);

Does this make sense?

        Neil



_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel

Re: PLEASE: debugging embedded guile code

[Bruce Korb]

Neil Jerram wrote:
> 
> >>>>> "Bruce" == Bruce Korb <bkorb@veritas.com> writes:
> 
>     Bruce> Based on your example, I would need to emit this to libguile:
> 
>     Bruce>   (eval-client-input "...whatever...")
> 
>     Bruce> The problem is that the ``...whatever...'' is likely to
>     Bruce> often include double quotes, backslashes and all kinds of
>     Bruce> interesting stuff.  I don't particularly want to go over
>     Bruce> the string and reformat it so that the reader can
>     Bruce> reconstruct what I already have in hand.
> 
> You don't have to.  You can do something like this:
> 
>    SCM str = gh_str02scm( "...whatever..." );
>    SCM proc = scm_c_lookup( "eval-client-input" );
>    scm_call_1(proc, str);
> 
> Does this make sense?

Except for this:

ERROR: In procedure apply:
ERROR: Wrong type argument in position 1: #<variable 40288450 binding: #<procedure eval-client-input (str)>>
ABEND-ing in LOAD_TPL state
Last Guile command:
= = = = =
(setenv "SHELL" "/bin/sh")
= = = = =

Here's da code:

First, this is evaluated:

(define (eval-client-input str)
  (stack-catch #t
    (lambda ()
      (call-with-input-string str
        (lambda (p)
          (set-port-filename! p (tpl-file))
          (set-port-line! p (string->number (tpl-file-line "%2$d")))
          (list (primitive-eval (read p))))))
    (lambda (key . args)
      (apply display-error (fluid-ref the-last-stack)
                           (current-error-port)
                           args)
      (set! stack-saved? #f)
      #f
) ) )

The ``tpl-file'' and ``tpl-file-line'' thingeys are my own pre-registered
callback functions for getting file name and line number.

Then this function is invoked with "pzStr" pointing to the Guile command
noted above:

> static inline SCM ag_eval( tCC* pzStr )
> {
>     static SCM proc = SCM_UNDEFINED;
>     SCM str = gh_str02scm( pzStr );
>     pzLastScheme = pzStr;
> 
>     if (proc == SCM_UNDEFINED)
>         proc = scm_permanent_object( scm_c_lookup( "eval-client-input" ));
>     str = scm_call_1(proc, str);
>     pzLastScheme = NULL;
>     return str;
> }

My "atexit()" proc notices that pzLastScheme is not NULL.
If I replace all that code with just, ``return gh_eval_str( pzStr )''
it all works.  So, it's not quite equivalent yet, but it seems close.


_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user

Re: PLEASE: debugging embedded guile code

[Rob Browning]

Bruce Korb <bkorb@veritas.com> writes:

>> Does this make sense?
>
> Except for this:
> ERROR: In procedure apply:
> ERROR: Wrong type argument in position 1: #<variable 40288450 binding: #<procedure eval-client-input (str)>>

I think perhaps this:

>>    SCM str = gh_str02scm( "...whatever..." );
>>    SCM proc = scm_c_lookup( "eval-client-input" );
>>    scm_call_1(proc, str);

Should be

  SCM str = gh_str02scm( "...whatever..." );
  SCM proc_var = scm_c_lookup( "eval-client-input" );
  scm_call_1(SCM_VARIABLE_REF(proc), str);

I believe scm_c_lookup returns variables rather than values.

-- 
Rob Browning
rlb @defaultvalue.org and @debian.org; previously @cs.utexas.edu
GPG starting 2002-11-03 = 14DD 432F AE39 534D B592  F9A0 25C8 D377 8C7E 73A4


_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user

Re: PLEASE: debugging embedded guile code

[Bruce Korb]

Rob Browning wrote:

> I think perhaps this:
> 
> >>    SCM str = gh_str02scm( "...whatever..." );
> >>    SCM proc = scm_c_lookup( "eval-client-input" );
> >>    scm_call_1(proc, str);
> 
> Should be
> 
>   SCM str = gh_str02scm( "...whatever..." );
>   SCM proc_var = scm_c_lookup( "eval-client-input" );
>   scm_call_1(SCM_VARIABLE_REF(proc), str);
> 
> I believe scm_c_lookup returns variables rather than values.

Better!  But:

../agen5/autogen -L ../autoopts -Taginfo -bcolumns -DLEVEL=section \
        ../columns/opts.def
ERROR: Unbound variable: stack-catch
ABEND-ing in LOAD_TPL state
Failing Guile command:  = = = = =
(setenv "SHELL" "/bin/sh")
* * * * * * * * * * * * * * * * *

What is the "stack-catch" thing?
Should it be pre-defined by Guile?  Is it obsolete?
Thanks!! - Bruce

P.S.  Here's the definition for eval-client-input
that was suggested to me:

(define (eval-client-input str)
  (stack-catch #t
    (lambda ()
      (call-with-input-string str
        (lambda (p)
          (set-port-filename! p (tpl-file))
          (set-port-line! p (string->number (tpl-file-line "%2$d")))
          (list (primitive-eval (read p))))))
    (lambda (key . args)
      (apply display-error
         (fluid-ref the-last-stack)
         (current-error-port)
         args)
      (set! stack-saved? #f)
      #f
) ) )


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel

Re: PLEASE: debugging embedded guile code

[Bruce Korb]

OK.  Some real progress.  (Remember this all works when I evaluate
the Guile commands using gh_eval_str):

../agen5/autogen -L ../autoopts -Taginfo -bcolumns -DLEVEL=section \
        ../columns/opts.def
ERROR: Unbound variable: optname-to
Error in template ../autoopts/aginfo.tpl, line 154
        DEFINITIONS ERROR in ../autoopts/aginfo.tpl line 154 for columns.texi:
        exiting
Failing Guile command:  = = = = =
(set! opt-name (string-tr! (get "name") optname-from optname-to))
    (string-append down-prog-name " " opt-name)
* * * * * * * * * * * * * * * * *

The issue here is that gh_eval_str processes the *entire* string and
returns the result of the last expression.  This "eval-client-input"
function does not behave in the same way:

> (define (eval-client-input str)
>   (stack-catch #t
>     (lambda ()
>       (call-with-input-string str
>         (lambda (p)
>           (set-port-filename! p (tpl-file))
>           (set-port-line! p (string->number (tpl-file-line "%2$d")))
>           (list (primitive-eval (read p))))))
>     (lambda (key . args)
>       (apply display-error
>          (fluid-ref the-last-stack)
>          (current-error-port)
>          args)
>       (set! stack-saved? #f)
>       #f
> ) ) )

Before this failing command, the following was eval-ed at once:

> (define optname-from "A-Z_^")
> (define optname-to   "a-z--")

so "optname-from" is found, but "optname-to" is not.  How do I make
that ``(list (primitive-eval (read p)))'' thing into a loop that
yields the last value?

ALSO: notice that the Guile error message is not including the file
and line numbers.  Someone suggested:

> (read-enable 'positions)
> (debug-enable 'show-file-name)

but I get errors when I do that.

BY THE WAY:  when I finally have this working, I'll write it up
so nobody has to go through all this pain again.  It's pretty awful. :(


_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user

Re: PLEASE: debugging embedded guile code

[Bruce Korb]

Bruce Korb wrote:

> The issue here is that gh_eval_str processes the *entire* string and
> returns the result of the last expression.  This "eval-client-input"
> function does not behave in the same way:

> ... How do I make
> that ``(list (primitive-eval (read p)))'' thing into a loop that
> yields the last value?

Answer:  (begin ... )
EXCEPT:  the problem now is that instead of getting the final result,
         the returned SCM is an SCM *PAIR*, not the value I need.

That was because the result of the primitive-eval should not
be listified:
>          (list (primitive-eval (read p))) ) ) )

OK.  Here's what I have now:

> (use-modules (ice-9 stack-catch))
> (use-modules (ice-9 debug))
> 
> (read-enable 'positions)
> 
> (define (eval-client-input str)
>   (stack-catch #t
> 
>     (lambda ()
>       (call-with-input-string
>         (string-append "(begin " str ")")   ;;;  <<--== ICK!!
>         (lambda (p)
>           (set-port-filename! p (tpl-file))
>           (set-port-line! p (string->number (tpl-file-line "%2$d")))
>           (primitive-eval (read p)) ) ) )
> 
>     (lambda (key . args)
>       (apply display-error
>          (fluid-ref the-last-stack)
>          (current-error-port)
>          args)
>       (set! stack-saved? #f)
>       (error "exiting") )
> ) )

It's really close, but for two problems:

1.  "primitive-eval" doesn't seem to like comments:

> ERROR: In procedure list:
> ERROR: end of file in ./auto_gen.tpl
> Error in template ./auto_gen.tpl, line 675
>         DEFINITIONS ERROR in ./auto_gen.tpl line 675 for autogen.texi:
>         exiting
> Failing Guile command:  = = = = =
> 
> (shell "[ -f autogen.texi.ori ] && rm -f autogen.texi.ori
>        rm -rf ${tempdir}")
> (set-writable #t)
> 
> ;; Local Variables:
> ;; indent-tabs-mode: nil
> ;; mode: texinfo
> ;; End:
> 
> =================================

2. if you notice, the lines beginning with "ERROR:" still don't
   have the line number, but I see the file name there!!
   (Please note:  by this point, I've run through many templates.
   Likely this is the only one with scheme comments at the end.)

3. It seems (current-error-port) is set to something that got
   squirreled away when gh_enter got called.  I've scoured the
   manual now.  How do I simply set error port to the current stderr?


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel

Re: PLEASE: debugging embedded guile code

[Paul Jarc]

Bruce Korb <bkorb@veritas.com> wrote:
> How do I simply set error port to the current stderr?

Maybe something like this:
(set-current-error-port! (car (fdes->ports 2)))
But fdes->ports can return an empty list if there are no such ports.


paul


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel

Re: PLEASE: debugging embedded guile code

[Mikael Djurfeldt]

Neil Jerram <neil@ossau.uklinux.net> writes:

>     Dale> The answer is lazy-catch. [...]

In fact, it's better to use

  scm_internal_stack_catch

in which case some of the complexity disappears.

> I'm curious about this because the question of error handling keeps
> popping up and I'm wondering whether our current solution is good
> enough.  (With a strong suspicion that it isn't.)

One obvious reason is that there is no documentation.  We should
really have a simple example of how to enable debugging from C and how
to use scm_internal_stack_catch to print out all error information.

Regarding looking for new/better solutions: It's probably good to
follow closely what happens with regard to error handling in the SRFI
process.  Relevant SRFIs are, at least, 34, 18 (exception handlers,
`raise' in thread context), 23, 35, 36.

Mikael


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel

Re: PLEASE: debugging embedded guile code

[Neil Jerram]

>>>>> "Mikael" == Mikael Djurfeldt <djurfeldt@nada.kth.se> writes:

    Mikael> Neil Jerram <neil@ossau.uklinux.net> writes:
    Dale> The answer is lazy-catch. [...]

    Mikael> In fact, it's better to use

    Mikael>   scm_internal_stack_catch

    Mikael> in which case some of the complexity disappears.

True; I've used stack-catch in my latest suggestion.

    >> I'm curious about this because the question of error handling keeps
    >> popping up and I'm wondering whether our current solution is good
    >> enough.  (With a strong suspicion that it isn't.)

    Mikael> One obvious reason is that there is no documentation.  We
    Mikael> should really have a simple example of how to enable
    Mikael> debugging from C and how to use scm_internal_stack_catch
    Mikael> to print out all error information.

I agree w.r.t. documentation but am not convinced about C.  I'm
beginning to think that Guile should actively encourage people to do
as much as possible in Scheme, and I see no reasons (yet) why this
kind of error handling has to be done in C.

    Mikael> Regarding looking for new/better solutions: It's probably
    Mikael> good to follow closely what happens with regard to error
    Mikael> handling in the SRFI process.  Relevant SRFIs are, at
    Mikael> least, 34, 18 (exception handlers, `raise' in thread
    Mikael> context), 23, 35, 36.

Thanks - I'll take a look.

        Neil



_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel

SRFI 34

[Neil Jerram]

>>>>> "Neil" == Neil Jerram <neil@ossau.uklinux.net> writes:

>>>>> "Mikael" == Mikael Djurfeldt <djurfeldt@nada.kth.se> writes:

    Mikael> Regarding looking for new/better solutions: It's probably
    Mikael> good to follow closely what happens with regard to error
    Mikael> handling in the SRFI process.  Relevant SRFIs are, at
    Mikael> least, 34, 18 (exception handlers, `raise' in thread
    Mikael> context), 23, 35, 36.

    Neil> Thanks - I'll take a look.

As part of "looking", I've written and committed a first
implementation of SRFI 34.  I probably shouldn't have, because it
probably needs more thought before anyone starts relying on particular
behaviour ... but anyway.

Comments most welcome.

        Neil



_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel

Re: SRFI 34

[Marius Vollmer]

Neil Jerram <neil@ossau.uklinux.net> writes:

> As part of "looking", I've written and committed a first
> implementation of SRFI 34.

Nice!  I think I like SRFI 34.  Just the essential bits...

Anyway, I sense trouble with our lazy-catch:

    guile> (define f (make-fluid))
    guile> (lazy-catch #t (lambda ()
                            (with-fluids ((f 12))
                              (throw 'x)))
                          (lambda (x)
                            (pk 'handler (fluid-ref f))))

    ;;; (handler #f)

Shouldn't this print '(handler 12)' since the handler is supposed to
be running in the dynamic context of the throw?

-- 
GPG: D5D4E405 - 2F9B BCCC 8527 692A 04E3  331E FAF8 226A D5D4 E405


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel

Re: SRFI 34

[Neil Jerram]

>>>>> "Marius" == Marius Vollmer <mvo@zagadka.de> writes:

    Marius> Neil Jerram <neil@ossau.uklinux.net> writes:
    >> As part of "looking", I've written and committed a first
    >> implementation of SRFI 34.

    Marius> Nice!  I think I like SRFI 34.  Just the essential bits...

    Marius> Anyway, I sense trouble with our lazy-catch:

    guile> (define f (make-fluid))
    guile> (lazy-catch #t (lambda ()
    Marius>                             (with-fluids ((f 12))
    Marius>                               (throw 'x)))
    Marius>                           (lambda (x)
    Marius>                             (pk 'handler (fluid-ref f))))

    Marius>     ;;; (handler #f)

    Marius> Shouldn't this print '(handler 12)' since the handler is
    Marius> supposed to be running in the dynamic context of the
    Marius> throw?

Our lazy-catch implementation specifically unwinds dynamic context so
that we see (handler #f) here rather than (handler 12).  Effectively
the only thing that lazy-catch doesn't unwind is the stack.  I've
described this current behaviour in some detail in the manual.

Unwinding the fluid context is contrary to my intuition, though, and
it appears to yours also.

So perhaps we should consider changing it.  Right now, fluids, dynamic
winds and catches are all on the same wind list, which means we have
to unwind the list to get the right catch context for the lazy-catch
handler's throw.  One option then would be to have separate wind lists
for separate kinds of dynamic context, and only unwind the list with
the catches in it.  But I wonder if there are strong theoretical
reasons why having separate wind lists would be a bad thing?

        Neil



_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel

Re: SRFI 34

[Marius Vollmer]

Neil Jerram <neil@ossau.uklinux.net> writes:

> Our lazy-catch implementation specifically unwinds dynamic context so
> that we see (handler #f) here rather than (handler 12).  Effectively
> the only thing that lazy-catch doesn't unwind is the stack. 

Ahh, I see.  The lazy-catch was introduced so that one can get at the
call stack via 'make-stack', right?  If so and it is consistent with
the docs then we should leave it the way it is.  Maybe the docs need
some carification.

> Unwinding the fluid context is contrary to my intuition, though, and
> it appears to yours also.

Yes, but I don't think we should change such a fundamental thing about
lazy-catch just so.  We can introduce a new function, however.
Probably we should just move SRFI-34 into the core and rewrite 'error'
to use it.

But given the semantics of lazy-catch, I think your implementation of
SRFI-34 is wrong.  I does _not_ run the handler in the dynamic context
of the call to 'raise' since lazy-catch winds back to the dynamic
context of 'with-exception-handler'.

Can we use the sample implementation, and just change it to use a
fluid for the list of exception handlers.  Also, maybe we can replace
some call/cc with 'catch', but that would just be for performance.

> One option then would be to have separate wind lists
> for separate kinds of dynamic context, and only unwind the list with
> the catches in it.  But I wonder if there are strong theoretical
> reasons why having separate wind lists would be a bad thing?

That would be quite unclean, I think.  If we want to change lazy-catch
to not unwind the dynamic context (which I think we should not), then
we only need to modify scm_ithrow a bit to not call scm_dowinds for a
lazy catch and to not reset the dynwinds list.  It would just look
into the dynwind list for the matching catch, and if it is a lazy
catch, we just call the handler and do not change anything about the
dynwind list.

-- 
GPG: D5D4E405 - 2F9B BCCC 8527 692A 04E3  331E FAF8 226A D5D4 E405


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel

Re: SRFI 34

[Neil Jerram]

This is a thread from May 2003 that I never resolved.  I've revisited
it now because of Andreas Rottman's work on SRFI 35 (conditions),
which makes me think that it would be worthwhile finishing this whole
area off.

Marius Vollmer <mvo@zagadka.de> writes:

> Neil Jerram <neil@ossau.uklinux.net> writes:
> 
> > Our lazy-catch implementation specifically unwinds dynamic context so
> > that we see (handler #f) here rather than (handler 12).  Effectively
> > the only thing that lazy-catch doesn't unwind is the stack. 
> 
> Ahh, I see.  The lazy-catch was introduced so that one can get at the
> call stack via 'make-stack', right?

Yes.

> If so and it is consistent with the docs then we should leave it the
> way it is.  Maybe the docs need some carification.

I believe the docs are already correct on this point.  Try `i
lazy-catch' in the manual.

> > Unwinding the fluid context is contrary to my intuition, though, and
> > it appears to yours also.
> 
> Yes, but I don't think we should change such a fundamental thing about
> lazy-catch just so.

OK.

> We can introduce a new function, however.  Probably we should just
> move SRFI-34 into the core and rewrite 'error' to use it.

OK, but we need to be careful to preserve the behavior of existing
code that uses `catch' to catch errors.  Did you have a specific
scheme in mind here?  Here's what I think might work:

- `error' and libguile errors are rewritten to use `raise' and an
  appropriate SRFI-35 condition object.

- The default SRFI-34 exception handler maps the condition object back
  to a key + arg list, and calls `throw' with that key and args.

> But given the semantics of lazy-catch, I think your implementation of
> SRFI-34 is wrong.  I does _not_ run the handler in the dynamic context
> of the call to 'raise' since lazy-catch winds back to the dynamic
> context of 'with-exception-handler'.

Agreed.  (I glossed over this before, because (i) SRFI-34 doesn't
provide any examples that test the difference, and (ii) my
implementation was only a quick first attempt.)

> Can we use the sample implementation, and just change it to use a
> fluid for the list of exception handlers.  Also, maybe we can replace
> some call/cc with 'catch', but that would just be for performance.

OK, but for this I have 2 technical queries.

1. To minimize changes between the official SRFI 34 code and Guile's
   version, it would be nice to introduce
   call-with-escape-continuation (implemented using throw and catch)
   and just replace the call-with-current-continuation's in the SRFI
   34 code by call-with-escape-continuation.  Is the following a good
   definition of call-with-escape-continuation?

(define (call-with-escape-continuation proc)
  (let ((tag (make-symbol "call-with-escape-continuation")))
    (catch tag
	   (lambda ()
	     (proc (lambda (return-value)
		     (throw tag return-value))))
	   (lambda (key return-value)
	     return-value))))

2. Are the define-syntax forms in SRFI-34 OK as they are, or should
   they be translated (for Guile) to macro definitions?

Thanks,
        Neil


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel

Re: PLEASE: debugging embedded guile code

[Neil Jerram]

>>>>> "Joris" == Joris van der Hoeven <TeXmacs@math.u-psud.fr> writes:

    Joris> When I run Guile interactively, and my code contains an
    Joris> error, then I get a nice error message with the location
    Joris> (file name, line number, column) of the error. I would like
    Joris> to have something similar for errors which occur in
    Joris> embedded Guile code.

Where would you like this information to appear?  Do you mean that you
want to retrieve the information programmatically, or that you'd like
it to pop up in some kind of UI?

Regards,
        Neil



_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user

Re: PLEASE: debugging embedded guile code

[Neil Jerram]

>>>>> "Joris" == Joris van der Hoeven <TeXmacs@math.u-psud.fr> writes:

    >> I'm curious about this because the question of error handling keeps
    >> popping up and I'm wondering whether our current solution is good
    >> enough.  (With a strong suspicion that it isn't.)
    >> 
    >> One thing I'm not sure I understand is why you want (or perhaps need)
    >> to do this lazy-catch in C rather than in Scheme, since it would be
    >> much easier in Scheme.  Can you explain?

    Joris> I now have something more or less satisfactory for myself.

Using lazy-catch?

    Joris> One of the most important shortcomings of the current
    Joris> situation is probably poor documentation. In particular, I
    Joris> think that the manual should contain an example how to deal
    Joris> with detailed error handling.

I agree, but I also think that the lazy-catch mechanism is more tricky
than it needs to be, especially in C.  So I'd like to get the
mechanism right first and then document it.

    Joris> I also think that there you might add some scheme routines
    Joris> to construct comprehensive error messages from error
    Joris> objects.  This would allow me to print these messages in a
    Joris> popup window or include them in a status buffer. I
    Joris> currently print everything to standard output or error...

I think I understand, but can you give an example?

        Neil



_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel

Re: PLEASE: debugging embedded guile code

[Joris van der Hoeven]

On 26 Apr 2003, Neil Jerram wrote:
> >>>>> "Joris" == Joris van der Hoeven <TeXmacs@math.u-psud.fr> writes:
>
>     >> I'm curious about this because the question of error handling keeps
>     >> popping up and I'm wondering whether our current solution is good
>     >> enough.  (With a strong suspicion that it isn't.)
>     >>
>     >> One thing I'm not sure I understand is why you want (or perhaps need)
>     >> to do this lazy-catch in C rather than in Scheme, since it would be
>     >> much easier in Scheme.  Can you explain?
>
>     Joris> I now have something more or less satisfactory for myself.
>
> Using lazy-catch?

Yes.

>     Joris> One of the most important shortcomings of the current
>     Joris> situation is probably poor documentation. In particular, I
>     Joris> think that the manual should contain an example how to deal
>     Joris> with detailed error handling.
>
> I agree, but I also think that the lazy-catch mechanism is more tricky
> than it needs to be, especially in C.  So I'd like to get the
> mechanism right first and then document it.

We now started to use lazy-catch more and more, but we might
still change that. Can you tell us what you have in mind?

>     Joris> I also think that there you might add some scheme routines
>     Joris> to construct comprehensive error messages from error
>     Joris> objects.  This would allow me to print these messages in a
>     Joris> popup window or include them in a status buffer. I
>     Joris> currently print everything to standard output or error...
>
> I think I understand, but can you give an example?

You might for instance provide routines

	(error->message error-obj)
	(error->backtrace error-obj)
	(error->source error-obj)
	(error->file-name error-obj)
	(error->line-number error-obj)
	etc.



_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel

Re: PLEASE: debugging embedded guile code

[Neil Jerram]

>>>>> "Joris" == Joris van der Hoeven <TeXmacs@math.u-psud.fr> writes:

    Joris> On 26 Apr 2003, Neil Jerram wrote:
    >> 
    >> I agree, but I also think that the lazy-catch mechanism is more tricky
    >> than it needs to be, especially in C.  So I'd like to get the
    >> mechanism right first and then document it.

    Joris> We now started to use lazy-catch more and more, but we might
    Joris> still change that. Can you tell us what you have in mind?

Don't panic; I have nothing in mind yet.  Judging from the apparent
difficulty that people have with this area on the mailing list, I
thought this was an issue that we should think about.  If it really
isn't an issue, no problem (except that we should improve the docs).

lazy-catch in Scheme is straightforward, but my intuition is that
doing a lazy-catch in C is harder work than should be needed to obtain
error information.  My problem is that I don't understand why you'd
ever do it in C instead of Scheme, yet there have been several posts
describing how to do exactly that.  Hence my question about why one
needs to do this in C (which I don't think anyone has answered yet).

    Joris> I also think that there you might add some scheme routines
    Joris> to construct comprehensive error messages from error
    Joris> objects.  This would allow me to print these messages in a
    Joris> popup window or include them in a status buffer. I
    Joris> currently print everything to standard output or error...
    >> 
    >> I think I understand, but can you give an example?

    Joris> You might for instance provide routines

    Joris> 	(error->message error-obj)
    Joris> 	(error->backtrace error-obj)
    Joris> 	(error->source error-obj)
    Joris> 	(error->file-name error-obj)
    Joris> 	(error->line-number error-obj)
    Joris> 	etc.

Right.  With the current organization of things, the location of an
error is described by a stack obejct, so I think all of these but the
first would be stack->X rather than error->X, but I see what you mean.

These raise another C vs. Scheme question, though.  These routines are
trivial to implement in Scheme, but wouldn't then be readily available
on the C level.  Does that matter? and if so, why?

Regards,
        Neil



_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel

Re: PLEASE: debugging embedded guile code

[Joris van der Hoeven]

> >>>>> "Joris" == Joris van der Hoeven <TeXmacs@math.u-psud.fr> writes:
>     Joris> On 26 Apr 2003, Neil Jerram wrote:
>     >> I agree, but I also think that the lazy-catch mechanism is more tricky
>     >> than it needs to be, especially in C.  So I'd like to get the
>     >> mechanism right first and then document it.
>
>     Joris> We now started to use lazy-catch more and more, but we might
>     Joris> still change that. Can you tell us what you have in mind?
>
> Don't panic; I have nothing in mind yet.  Judging from the apparent
> difficulty that people have with this area on the mailing list, I
> thought this was an issue that we should think about.  If it really
> isn't an issue, no problem (except that we should improve the docs).
>
> lazy-catch in Scheme is straightforward, but my intuition is that
> doing a lazy-catch in C is harder work than should be needed to obtain
> error information.  My problem is that I don't understand why you'd
> ever do it in C instead of Scheme, yet there have been several posts
> describing how to do exactly that.  Hence my question about why one
> needs to do this in C (which I don't think anyone has answered yet).

I personally do not really need to make the distinction between
Scheme-level and C-level (C++-level for me) anymore, because I added
a C++ class 'object' which allows me to directly manipulate scheme
objects at C++-level. In particular, if you implement the routines
error->... below at Scheme-level, then we may take advantage of
them at C++-level too.

>     Joris> I also think that there you might add some scheme routines
>     Joris> to construct comprehensive error messages from error
>     Joris> objects.  This would allow me to print these messages in a
>     Joris> popup window or include them in a status buffer. I
>     Joris> currently print everything to standard output or error...
>     >>
>     >> I think I understand, but can you give an example?
>
>     Joris> You might for instance provide routines
>
>     Joris> 	(error->message error-obj)
>     Joris> 	(error->backtrace error-obj)
>     Joris> 	(error->source error-obj)
>     Joris> 	(error->file-name error-obj)
>     Joris> 	(error->line-number error-obj)
>     Joris> 	etc.
>
> Right.  With the current organization of things, the location of an
> error is described by a stack obejct, so I think all of these but the
> first would be stack->X rather than error->X, but I see what you mean.
>
> These raise another C vs. Scheme question, though.  These routines are
> trivial to implement in Scheme, but wouldn't then be readily available
> on the C level.  Does that matter? and if so, why?



_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel