* PLEASE: debugging embedded guile code [not found] <Pine.GSO.3.96.1030209200016.26546A-100000@anh> @ 2003-02-25 14:19 ` Joris van der Hoeven 2003-02-25 14:36 ` Dale P. Smith 2003-04-26 14:45 ` PLEASE: debugging embedded guile code Neil Jerram 0 siblings, 2 replies; 33+ 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] 33+ 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:51 ` Neil Jerram 2003-04-26 14:45 ` PLEASE: debugging embedded guile code Neil Jerram 1 sibling, 1 reply; 33+ 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] 33+ messages in thread
* Re: PLEASE: debugging embedded guile code 2003-02-25 14:36 ` Dale P. Smith @ 2003-04-26 14:51 ` Neil Jerram 2003-04-26 16:40 ` Bruce Korb 2003-04-28 13:52 ` Mikael Djurfeldt 0 siblings, 2 replies; 33+ 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] 33+ messages in thread
* Re: PLEASE: debugging embedded guile code 2003-04-26 14:51 ` 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; 33+ 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] 33+ 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; 33+ 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] 33+ 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-27 20:49 ` Neil Jerram 0 siblings, 1 reply; 33+ 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] 33+ messages in thread
* Re: PLEASE: debugging embedded guile code 2003-04-26 20:13 ` Bruce Korb @ 2003-04-27 20:49 ` Neil Jerram 2003-04-27 21:57 ` Bruce Korb 0 siblings, 1 reply; 33+ 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] 33+ 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; 33+ 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] 33+ 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; 33+ 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] 33+ 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; 33+ 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] 33+ 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; 33+ 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] 33+ 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; 33+ 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] 33+ 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; 33+ 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] 33+ 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; 33+ 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] 33+ 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; 33+ 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] 33+ 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; 33+ 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] 33+ 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; 33+ 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] 33+ 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; 33+ 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] 33+ 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; 33+ 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] 33+ 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; 33+ 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] 33+ 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; 33+ 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] 33+ messages in thread
* Re: PLEASE: debugging embedded guile code 2003-04-26 14:51 ` 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; 33+ 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] 33+ messages in thread
* Re: PLEASE: debugging embedded guile code 2003-04-28 13:52 ` Mikael Djurfeldt @ 2003-04-28 19:26 ` Neil Jerram 2003-04-30 0:13 ` SRFI 34 Neil Jerram 0 siblings, 1 reply; 33+ 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] 33+ messages in thread
* SRFI 34 2003-04-28 19:26 ` Neil Jerram @ 2003-04-30 0:13 ` Neil Jerram 2003-05-17 0:45 ` Marius Vollmer 0 siblings, 1 reply; 33+ messages in thread From: Neil Jerram @ 2003-04-30 0:13 UTC (permalink / raw) Cc: guile-devel >>>>> "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 ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: SRFI 34 2003-04-30 0:13 ` SRFI 34 Neil Jerram @ 2003-05-17 0:45 ` Marius Vollmer 2003-05-17 9:39 ` Neil Jerram 0 siblings, 1 reply; 33+ messages in thread From: Marius Vollmer @ 2003-05-17 0:45 UTC (permalink / raw) Cc: djurfeldt 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 ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: SRFI 34 2003-05-17 0:45 ` Marius Vollmer @ 2003-05-17 9:39 ` Neil Jerram 2003-05-17 20:36 ` Marius Vollmer 0 siblings, 1 reply; 33+ messages in thread From: Neil Jerram @ 2003-05-17 9:39 UTC (permalink / raw) Cc: djurfeldt >>>>> "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 ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: SRFI 34 2003-05-17 9:39 ` Neil Jerram @ 2003-05-17 20:36 ` Marius Vollmer 2004-03-07 18:34 ` Neil Jerram 0 siblings, 1 reply; 33+ messages in thread From: Marius Vollmer @ 2003-05-17 20:36 UTC (permalink / raw) Cc: djurfeldt 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 ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: SRFI 34 2003-05-17 20:36 ` Marius Vollmer @ 2004-03-07 18:34 ` Neil Jerram 0 siblings, 0 replies; 33+ messages in thread From: Neil Jerram @ 2004-03-07 18:34 UTC (permalink / raw) Cc: djurfeldt, guile-devel 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 ^ permalink raw reply [flat|nested] 33+ 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; 33+ 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] 33+ messages in thread
[parent not found: <Pine.GSO.4.33.0304261706460.1619-100000@sunanh>]
* Re: PLEASE: debugging embedded guile code [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 0 siblings, 1 reply; 33+ messages in thread From: Neil Jerram @ 2003-04-26 15:34 UTC (permalink / raw) Cc: Guile Development >>>>> "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 ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: PLEASE: debugging embedded guile code 2003-04-26 15:34 ` Neil Jerram @ 2003-04-26 15:40 ` Joris van der Hoeven 2003-04-26 19:30 ` Neil Jerram 0 siblings, 1 reply; 33+ messages in thread From: Joris van der Hoeven @ 2003-04-26 15:40 UTC (permalink / raw) Cc: Guile Development 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 ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: PLEASE: debugging embedded guile code 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 0 siblings, 1 reply; 33+ messages in thread From: Neil Jerram @ 2003-04-26 19:30 UTC (permalink / raw) Cc: Guile Development >>>>> "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 ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: PLEASE: debugging embedded guile code 2003-04-26 19:30 ` Neil Jerram @ 2003-04-27 8:40 ` Joris van der Hoeven 0 siblings, 0 replies; 33+ messages in thread From: Joris van der Hoeven @ 2003-04-27 8:40 UTC (permalink / raw) Cc: Guile Development > >>>>> "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 ^ permalink raw reply [flat|nested] 33+ messages in thread
end of thread, other threads:[~2004-03-07 18:34 UTC | newest] Thread overview: 33+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- [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 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
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).