From: Neil Jerram <neil@ossau.uklinux.net>
Cc: guile-devel@gnu.org
Subject: Re: PLEASE: debugging embedded guile code
Date: 28 Apr 2003 20:21:47 +0100 [thread overview]
Message-ID: <m3ptn6ctro.fsf@laruns.ossau.uklinux.net> (raw)
In-Reply-To: <3EAC5266.23DEEB7F@veritas.com>
>>>>> "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
next prev parent reply other threads:[~2003-04-28 19:21 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-02-08 11:12 Source locations Joris van der Hoeven
2003-02-08 17:22 ` Wolfgang Jaehrling
2003-02-09 19:05 ` Joris van der Hoeven
2003-02-25 14:19 ` PLEASE: debugging embedded guile code Joris van der Hoeven
2003-02-25 14:36 ` Dale P. Smith
2003-02-27 12:17 ` Customized error reports Joris van der Hoeven
2003-02-28 18:06 ` Paul Jarc
2003-04-26 14:51 ` PLEASE: debugging embedded guile code Neil Jerram
2003-04-26 16:40 ` Bruce Korb
2003-04-26 19:12 ` Neil Jerram
2003-04-26 20:13 ` Bruce Korb
2003-04-26 22:25 ` Thien-Thi Nguyen
2003-04-27 20:49 ` Neil Jerram
2003-04-27 21:57 ` Bruce Korb
2003-04-28 15:54 ` Paul Jarc
2003-04-28 16:07 ` Bruce Korb
2003-04-28 19:21 ` Neil Jerram [this message]
2003-04-28 20:06 ` Bruce Korb
2003-04-28 20:58 ` Neil Jerram
2003-05-16 17:19 ` Bruce Korb
2003-05-16 19:23 ` Neil Jerram
2003-05-16 20:27 ` Bruce Korb
2003-05-16 21:21 ` Rob Browning
2003-05-16 21:56 ` Bruce Korb
2003-05-17 0:31 ` Bruce Korb
2003-05-17 2:33 ` Bruce Korb
2003-05-19 15:00 ` Paul Jarc
2003-04-28 13:52 ` Mikael Djurfeldt
2003-04-28 19:26 ` Neil Jerram
2003-04-26 14:45 ` Neil Jerram
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/guile/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=m3ptn6ctro.fsf@laruns.ossau.uklinux.net \
--to=neil@ossau.uklinux.net \
--cc=guile-devel@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).