* Hook for script debugging
@ 2009-09-26 14:51 Neil Jerram
2009-09-26 21:06 ` Ludovic Courtès
0 siblings, 1 reply; 4+ messages in thread
From: Neil Jerram @ 2009-09-26 14:51 UTC (permalink / raw)
To: Guile Development
I'd like Guile to support something like the patch below - i.e. some way
of being able to execute arbitrary code before a Guile script starts
running, so as to be able to set up breakpoints (or whatever other
mechanisms are available) to trace or debug the script execution. (And
without having to edit the script.)
Some possible questions... Is GUILE_BOOT_FORM a good name? Is it too
general? Should we instead support a variable GUILE_PRE_SCRIPT_REPL,
which causes us to run a normal REPL before loading the script? Or
perhaps a more limited or debugging-focussed REPL?
I think the generality of GUILE_BOOT_FORM is useful. If the only option
is starting a REPL, that makes automated operation less convenient.
Also, imagine a build in which there might be several Guile script
invocations, and you only want to debug one of them. Then the boot form
could include a check of the script name - (car (command-line)) - and
only start a REPL (or set a breakpoint, or whatever) for that one.
Thoughts?
Regards,
Neil
diff --git a/module/ice-9/boot-9.scm b/module/ice-9/boot-9.scm
index a1537d1..86ab725 100644
--- a/module/ice-9/boot-9.scm
+++ b/module/ice-9/boot-9.scm
@@ -3514,4 +3514,9 @@ module '(ice-9 q) '(make-q q-length))}."
(define-module (guile-user)
#:autoload (system base compile) (compile))
+(let ((boot-form (getenv "GUILE_BOOT_FORM")))
+ (if (and (string? boot-form)
+ (not (zero? (string-length boot-form))))
+ (primitive-eval (with-input-from-string boot-form read))))
+
;;; boot-9.scm ends here
^ permalink raw reply related [flat|nested] 4+ messages in thread
* Re: Hook for script debugging
2009-09-26 14:51 Hook for script debugging Neil Jerram
@ 2009-09-26 21:06 ` Ludovic Courtès
2009-09-27 16:41 ` Neil Jerram
0 siblings, 1 reply; 4+ messages in thread
From: Ludovic Courtès @ 2009-09-26 21:06 UTC (permalink / raw)
To: guile-devel
Hi Neil,
Do you think a special mechanism is needed at all? Isn’t it as easy to
edit the script to be debugged than to remember the right environment
variable name, the right incantation, etc.?
(In my case I know I would most likely end up editing the script rather
than going some other way, unless that other way is significantly more
convenient.)
Thanks,
Ludo’.
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Hook for script debugging
2009-09-26 21:06 ` Ludovic Courtès
@ 2009-09-27 16:41 ` Neil Jerram
2009-10-02 8:35 ` Ludovic Courtès
0 siblings, 1 reply; 4+ messages in thread
From: Neil Jerram @ 2009-09-27 16:41 UTC (permalink / raw)
To: Ludovic Courtès; +Cc: guile-devel
ludo@gnu.org (Ludovic Courtès) writes:
> Hi Neil,
>
> Do you think a special mechanism is needed at all? Isn’t it as easy to
> edit the script to be debugged than to remember the right environment
> variable name, the right incantation, etc.?
I think it's inelegant to have to edit a script in order to debug it.
If there is some generally useful system for debugging/introspection of
a running Guile program - such as GDS, as I hope it will eventually
become - it seems more efficient to be able to have a global switch for
invoking that system - e.g. adding GUILE_BOOT_FORM to the environment -
than to have to temporarily add the same invocation code to each program
that you want to examine (and then remove it again when no longer
needed).
Also I think there can be situations where it's inconvenient or
impossible to edit the code, and I'd like to support those too. For
example a non-root user wanting to debug an installed program. It might
be possible for that user to copy parts of the installed tree, and set
various paths to pick up the writable copies instead of the read-only
installed code. But that seems difficult. And, the more one has to
modify or copy parts of any existing program, the less sure one can be
that it will still run the same as it does normally.
On the technical front - in case it makes a difference to your view on
this - I've discovered that it doesn't work to do this by adding code to
the end of boot-9.scm, because (command-line) hasn't been set up at that
point. If we provide this feature, it will need to be in C code in
scm_compile_shell_switches instead.
> (In my case I know I would most likely end up editing the script rather
> than going some other way, unless that other way is significantly more
> convenient.)
Well I would hope to make this new way convenient... But whatever
happens, the script editing approach will be possible too, of course.
Regards,
Neil
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Hook for script debugging
2009-09-27 16:41 ` Neil Jerram
@ 2009-10-02 8:35 ` Ludovic Courtès
0 siblings, 0 replies; 4+ messages in thread
From: Ludovic Courtès @ 2009-10-02 8:35 UTC (permalink / raw)
To: guile-devel
Hello,
Neil Jerram <neil@ossau.uklinux.net> writes:
> I think it's inelegant to have to edit a script in order to debug it.
> If there is some generally useful system for debugging/introspection of
> a running Guile program - such as GDS, as I hope it will eventually
> become - it seems more efficient to be able to have a global switch for
> invoking that system - e.g. adding GUILE_BOOT_FORM to the environment -
> than to have to temporarily add the same invocation code to each program
> that you want to examine (and then remove it again when no longer
> needed).
Right, that’s a more compelling argument to me. That is, if such a
mechanism can help provide a standard way to debug a program via GDS,
then I’m all for it.
Thanks,
Ludo’.
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2009-10-02 8:35 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2009-09-26 14:51 Hook for script debugging Neil Jerram
2009-09-26 21:06 ` Ludovic Courtès
2009-09-27 16:41 ` Neil Jerram
2009-10-02 8:35 ` Ludovic Courtès
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).