* Source locations @ 2003-02-08 11:12 Joris van der Hoeven 2003-02-08 17:22 ` Wolfgang Jaehrling 0 siblings, 1 reply; 30+ messages in thread From: Joris van der Hoeven @ 2003-02-08 11:12 UTC (permalink / raw) Hi, In the online guile manual, I found that the instruction (read-enable 'positions) should tell guile to remember positions in the source code. How can I use this information? I would like to be able to display a filename and a line/column number when an error is encountered in an embedded guile program. 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-user mailing list Guile-user@gnu.org http://mail.gnu.org/mailman/listinfo/guile-user ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Source locations 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 0 siblings, 1 reply; 30+ messages in thread From: Wolfgang Jaehrling @ 2003-02-08 17:22 UTC (permalink / raw) Cc: guile-user On Sat, Feb 08, 2003 at 12:12:41PM +0100, Joris van der Hoeven wrote: > In the online guile manual, I found that the instruction > > (read-enable 'positions) > > should tell guile to remember positions in the source code. > > How can I use this information? I would like to be able > to display a filename and a line/column number when > an error is encountered in an embedded guile program. If you (read ...) some object `obj' from a file, you can do (source-property obj 'filename), (source-property obj 'line) and (source-property obj 'column) to get the position where this object has been read from. Hope this helps. Cheers, GNU/Wolfgang _______________________________________________ Guile-user mailing list Guile-user@gnu.org http://mail.gnu.org/mailman/listinfo/guile-user ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Source locations 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 0 siblings, 1 reply; 30+ messages in thread From: Joris van der Hoeven @ 2003-02-09 19:05 UTC (permalink / raw) Cc: Joris van der Hoeven Hi, > > In the online guile manual, I found that the instruction > > > > (read-enable 'positions) > > > > should tell guile to remember positions in the source code. > > > > How can I use this information? I would like to be able > > to display a filename and a line/column number when > > an error is encountered in an embedded guile program. > > If you (read ...) some object `obj' from a file, you can do > (source-property obj 'filename), (source-property obj 'line) and > (source-property obj 'column) to get the position where this object > has been read from. > > Hope this helps. Thanks for your answer. Unfortunately, I still do not really understand how to make use of this in order to display a filename and a line/column number when an error is encountered in an embedded guile program. First of all, I am not sure whether I may use 'load' instead of 'read'. Secondly, it seems that all this only gives me information about the object which is read, but not about object which are obtained indirectly through evaluation. For instance: [vdhoeven@zonnebloem progs]$ guile guile> (read-enable 'positions) (keywords #f positions) guile> (read-enable 'copy) (keywords #f positions copy) guile> (define f (open-input-file "keywords/split.scm")) guile> (define prg (read f)) guile> prg (define process-list (quote ())) guile> (eval prg) guile> (source-property process-list 'filename) standard input:8:1: In procedure source-property in expression (source-property process-list (quote filename)): standard input:8:1: Wrong type argument in position 1: () ABORT: (wrong-type-arg) Type "(backtrace)" to get more information. guile> (source-property prg 'filename) "keywords/split.scm" guile> Thanks for your attention, 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-user mailing list Guile-user@gnu.org http://mail.gnu.org/mailman/listinfo/guile-user ^ permalink raw reply [flat|nested] 30+ messages in thread
* PLEASE: debugging embedded guile code 2003-02-09 19:05 ` Joris van der Hoeven @ 2003-02-25 14:19 ` Joris van der Hoeven 2003-02-25 14:36 ` Dale P. Smith 2003-04-26 14:45 ` Neil Jerram 0 siblings, 2 replies; 30+ messages in thread From: Joris van der Hoeven @ 2003-02-25 14:19 UTC (permalink / raw) Cc: guile-devel 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 ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: PLEASE: debugging embedded guile code 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-04-26 14:51 ` PLEASE: debugging embedded guile code Neil Jerram 2003-04-26 14:45 ` Neil Jerram 1 sibling, 2 replies; 30+ messages in thread From: Dale P. Smith @ 2003-02-25 14:36 UTC (permalink / raw) Cc: guile-user 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 ^ permalink raw reply [flat|nested] 30+ messages in thread
* Customized error reports 2003-02-25 14:36 ` Dale P. Smith @ 2003-02-27 12:17 ` Joris van der Hoeven 2003-02-28 18:06 ` Paul Jarc 2003-04-26 14:51 ` PLEASE: debugging embedded guile code Neil Jerram 1 sibling, 1 reply; 30+ messages in thread From: Joris van der Hoeven @ 2003-02-27 12:17 UTC (permalink / raw) Hi, Is it possible to let customized error reports display the file name and line number of an object of my choice, and not the expression which raised the error. For instance, I have the following piece of code (define (menu-format-error where which) (throw 'error 'texmacs-error "Bad menu format in: %S" (list which))) On an error in a menu definition, I get the following report: menu-define.scm:58:3: In procedure throw in expression (throw (quote error) (quote texmacs-error) ...): menu-define.scm:58:3: Bad menu format in: oops What I would like to have, is the not the file and line number where the throw is done, but the file and the line number of the erroneous expression. In other words, the error report should have been something like test-menu.scm:111:5: In procedure throw in expression (oops "blahblah") test-menu.scm:111:5: Bad menu format in: oops So how can I do that? Thanks, 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-user mailing list Guile-user@gnu.org http://mail.gnu.org/mailman/listinfo/guile-user ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Customized error reports 2003-02-27 12:17 ` Customized error reports Joris van der Hoeven @ 2003-02-28 18:06 ` Paul Jarc 0 siblings, 0 replies; 30+ messages in thread From: Paul Jarc @ 2003-02-28 18:06 UTC (permalink / raw) Cc: guile-user Joris van der Hoeven <TeXmacs@math.u-psud.fr> wrote: > Is it possible to let customized error reports display > the file name and line number of an object of my choice, > and not the expression which raised the error. In a lazy-catch handler, you can use (make-stack #t your-handler) to create a stack object, and then inspect its frames to see where you think the error might be. When you find the evaluation frame in question, you can use frame-source to get the list expression, and then use source-properties to get the filename, line, and column where that list came from. See the Debugging node in the manual for more. paul _______________________________________________ Guile-user mailing list Guile-user@gnu.org http://mail.gnu.org/mailman/listinfo/guile-user ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: PLEASE: debugging embedded guile code 2003-02-25 14:36 ` Dale P. Smith 2003-02-27 12:17 ` Customized error reports Joris van der Hoeven @ 2003-04-26 14:51 ` Neil Jerram 2003-04-26 16:40 ` Bruce Korb 2003-04-28 13:52 ` Mikael Djurfeldt 1 sibling, 2 replies; 30+ messages in thread From: Neil Jerram @ 2003-04-26 14:51 UTC (permalink / raw) Cc: Joris van der Hoeven >>>>> "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 ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: PLEASE: debugging embedded guile code 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-28 13:52 ` Mikael Djurfeldt 1 sibling, 1 reply; 30+ messages in thread From: Bruce Korb @ 2003-04-26 16:40 UTC (permalink / raw) Cc: Joris van der Hoeven 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 ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: PLEASE: debugging embedded guile code 2003-04-26 16:40 ` Bruce Korb @ 2003-04-26 19:12 ` Neil Jerram 2003-04-26 20:13 ` Bruce Korb 0 siblings, 1 reply; 30+ messages in thread From: Neil Jerram @ 2003-04-26 19:12 UTC (permalink / raw) Cc: guile-devel >>>>> "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 ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: PLEASE: debugging embedded guile code 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 0 siblings, 2 replies; 30+ messages in thread From: Bruce Korb @ 2003-04-26 20:13 UTC (permalink / raw) Cc: guile-devel 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 ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: PLEASE: debugging embedded guile code 2003-04-26 20:13 ` Bruce Korb @ 2003-04-26 22:25 ` Thien-Thi Nguyen 2003-04-27 20:49 ` Neil Jerram 1 sibling, 0 replies; 30+ messages in thread From: Thien-Thi Nguyen @ 2003-04-26 22:25 UTC (permalink / raw) Cc: guile-user From: Bruce Korb <bkorb@veritas.com> Date: Sat, 26 Apr 2003 13:13:43 -0700 It's also hard to read dark blue on a black background (glug page). i confess as a w3m user (on console) i don't really test www.glug.org for color correctness / image placement / anything graphical, before deployment -- sometimes it's more fun to generate stuff than to look at what's generated, eh? :-) anyway, a simple find-grep on www.glug.org shows "bgcolor" black on a few pages, for which there is no corresponding "fgcolor" blue. however, i see there is no explicit {un}visited link color specification, clearly a bug. thanks for the tip. i've manually jammed link = "yellow" alink = "yellow" vlink = "green" in the live index.html body tag for now; still waiting for an opportunity to revive the hard drive on which rests source for that page, to do a proper regen from http://www.glug.org/index.laml (and do other maintenance). thi _______________________________________________ Guile-user mailing list Guile-user@gnu.org http://mail.gnu.org/mailman/listinfo/guile-user ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: PLEASE: debugging embedded guile code 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 1 sibling, 1 reply; 30+ messages in thread From: Neil Jerram @ 2003-04-27 20:49 UTC (permalink / raw) Cc: guile-devel >>>>> "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 ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: PLEASE: debugging embedded guile code 2003-04-27 20:49 ` Neil Jerram @ 2003-04-27 21:57 ` Bruce Korb 2003-04-28 15:54 ` Paul Jarc 2003-04-28 19:21 ` Neil Jerram 0 siblings, 2 replies; 30+ messages in thread From: Bruce Korb @ 2003-04-27 21:57 UTC (permalink / raw) Cc: guile-devel 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 ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: PLEASE: debugging embedded guile code 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 1 sibling, 1 reply; 30+ messages in thread From: Paul Jarc @ 2003-04-28 15:54 UTC (permalink / raw) Cc: Neil Jerram 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 ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: PLEASE: debugging embedded guile code 2003-04-28 15:54 ` Paul Jarc @ 2003-04-28 16:07 ` Bruce Korb 0 siblings, 0 replies; 30+ messages in thread From: Bruce Korb @ 2003-04-28 16:07 UTC (permalink / raw) Cc: guile-devel 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 ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: PLEASE: debugging embedded guile code 2003-04-27 21:57 ` Bruce Korb 2003-04-28 15:54 ` Paul Jarc @ 2003-04-28 19:21 ` Neil Jerram 2003-04-28 20:06 ` Bruce Korb 1 sibling, 1 reply; 30+ messages in thread From: Neil Jerram @ 2003-04-28 19:21 UTC (permalink / raw) Cc: guile-devel >>>>> "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 ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: PLEASE: debugging embedded guile code 2003-04-28 19:21 ` Neil Jerram @ 2003-04-28 20:06 ` Bruce Korb 2003-04-28 20:58 ` Neil Jerram 0 siblings, 1 reply; 30+ messages in thread From: Bruce Korb @ 2003-04-28 20:06 UTC (permalink / raw) Cc: guile-devel 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 ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: PLEASE: debugging embedded guile code 2003-04-28 20:06 ` Bruce Korb @ 2003-04-28 20:58 ` Neil Jerram 2003-05-16 17:19 ` Bruce Korb 0 siblings, 1 reply; 30+ messages in thread From: Neil Jerram @ 2003-04-28 20:58 UTC (permalink / raw) Cc: guile-devel >>>>> "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 ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: PLEASE: debugging embedded guile code 2003-04-28 20:58 ` Neil Jerram @ 2003-05-16 17:19 ` Bruce Korb 2003-05-16 19:23 ` Neil Jerram 0 siblings, 1 reply; 30+ messages in thread From: Bruce Korb @ 2003-05-16 17:19 UTC (permalink / raw) Cc: guile-devel 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 ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: PLEASE: debugging embedded guile code 2003-05-16 17:19 ` Bruce Korb @ 2003-05-16 19:23 ` Neil Jerram 2003-05-16 20:27 ` Bruce Korb 0 siblings, 1 reply; 30+ messages in thread From: Neil Jerram @ 2003-05-16 19:23 UTC (permalink / raw) Cc: guile-devel >>>>> "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 ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: PLEASE: debugging embedded guile code 2003-05-16 19:23 ` Neil Jerram @ 2003-05-16 20:27 ` Bruce Korb 2003-05-16 21:21 ` Rob Browning 0 siblings, 1 reply; 30+ messages in thread From: Bruce Korb @ 2003-05-16 20:27 UTC (permalink / raw) Cc: guile-devel 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 ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: PLEASE: debugging embedded guile code 2003-05-16 20:27 ` Bruce Korb @ 2003-05-16 21:21 ` Rob Browning 2003-05-16 21:56 ` Bruce Korb 0 siblings, 1 reply; 30+ messages in thread From: Rob Browning @ 2003-05-16 21:21 UTC (permalink / raw) Cc: Neil Jerram 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 ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: PLEASE: debugging embedded guile code 2003-05-16 21:21 ` Rob Browning @ 2003-05-16 21:56 ` Bruce Korb 2003-05-17 0:31 ` Bruce Korb 0 siblings, 1 reply; 30+ messages in thread From: Bruce Korb @ 2003-05-16 21:56 UTC (permalink / raw) Cc: Neil Jerram 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 ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: PLEASE: debugging embedded guile code 2003-05-16 21:56 ` Bruce Korb @ 2003-05-17 0:31 ` Bruce Korb 2003-05-17 2:33 ` Bruce Korb 0 siblings, 1 reply; 30+ messages in thread From: Bruce Korb @ 2003-05-17 0:31 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: PLEASE: debugging embedded guile code 2003-05-17 0:31 ` Bruce Korb @ 2003-05-17 2:33 ` Bruce Korb 2003-05-19 15:00 ` Paul Jarc 0 siblings, 1 reply; 30+ messages in thread From: Bruce Korb @ 2003-05-17 2:33 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: PLEASE: debugging embedded guile code 2003-05-17 2:33 ` Bruce Korb @ 2003-05-19 15:00 ` Paul Jarc 0 siblings, 0 replies; 30+ messages in thread From: Paul Jarc @ 2003-05-19 15:00 UTC (permalink / raw) Cc: guile-devel 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 ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: PLEASE: debugging embedded guile code 2003-04-26 14:51 ` PLEASE: debugging embedded guile code Neil Jerram 2003-04-26 16:40 ` Bruce Korb @ 2003-04-28 13:52 ` Mikael Djurfeldt 2003-04-28 19:26 ` Neil Jerram 1 sibling, 1 reply; 30+ messages in thread From: Mikael Djurfeldt @ 2003-04-28 13:52 UTC (permalink / raw) Cc: Joris van der Hoeven 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 ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: PLEASE: debugging embedded guile code 2003-04-28 13:52 ` Mikael Djurfeldt @ 2003-04-28 19:26 ` Neil Jerram 0 siblings, 0 replies; 30+ messages in thread From: Neil Jerram @ 2003-04-28 19:26 UTC (permalink / raw) Cc: Joris van der Hoeven >>>>> "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 ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: PLEASE: debugging embedded guile code 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:45 ` Neil Jerram 1 sibling, 0 replies; 30+ messages in thread From: Neil Jerram @ 2003-04-26 14:45 UTC (permalink / raw) Cc: guile-user >>>>> "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 ^ permalink raw reply [flat|nested] 30+ messages in thread
end of thread, other threads:[~2003-05-19 15:00 UTC | newest] Thread overview: 30+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 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 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
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).