Re: PLEASE: debugging embedded guile code

[Bruce Korb <bkorb@veritas.com>]

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