guile-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Hook for script debugging


From: Neil Jerram
Subject: Re: Hook for script debugging
Date: Sun, 27 Sep 2009 17:41:42 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux)

address@hidden (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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]