From: Bruce Korb <bkorb@veritas.com>
Cc: Joris van der Hoeven <TeXmacs@math.u-psud.fr>
Subject: Re: PLEASE: debugging embedded guile code
Date: Sat, 26 Apr 2003 09:40:49 -0700 [thread overview]
Message-ID: <3EAAB691.6AD935B5@veritas.com> (raw)
In-Reply-To: m3znmd8g72.fsf@laruns.ossau.uklinux.net
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
next prev parent reply other threads:[~2003-04-26 16:40 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <Pine.GSO.3.96.1030209200016.26546A-100000@anh>
2003-02-25 14:19 ` PLEASE: debugging embedded guile code Joris van der Hoeven
2003-02-25 14:36 ` Dale P. Smith
2003-04-26 14:51 ` Neil Jerram
2003-04-26 16:40 ` Bruce Korb [this message]
2003-04-26 19:12 ` Neil Jerram
2003-04-26 20:13 ` Bruce Korb
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
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-30 0:13 ` SRFI 34 Neil Jerram
2003-05-17 0:45 ` Marius Vollmer
2003-05-17 9:39 ` Neil Jerram
2003-05-17 20:36 ` Marius Vollmer
2004-03-07 18:34 ` Neil Jerram
2003-04-26 14:45 ` PLEASE: debugging embedded guile code Neil Jerram
[not found] <Pine.GSO.4.33.0304261706460.1619-100000@sunanh>
2003-04-26 15:34 ` Neil Jerram
2003-04-26 15:40 ` Joris van der Hoeven
2003-04-26 19:30 ` Neil Jerram
2003-04-27 8:40 ` Joris van der Hoeven
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=3EAAB691.6AD935B5@veritas.com \
--to=bkorb@veritas.com \
--cc=TeXmacs@math.u-psud.fr \
/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).