From: Neil Jerram <neil@ossau.uklinux.net>
To: ludo@gnu.org (Ludovic Courtès)
Cc: guile-devel@gnu.org
Subject: Re: Hook for script debugging
Date: Sun, 27 Sep 2009 17:41:42 +0100 [thread overview]
Message-ID: <87vdj48hmh.fsf@ossau.uklinux.net> (raw)
In-Reply-To: <87hbuppg9d.fsf@gnu.org> ("Ludovic Courtès"'s message of "Sat, 26 Sep 2009 23:06:54 +0200")
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
next prev parent reply other threads:[~2009-09-27 16:41 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
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 [this message]
2009-10-02 8:35 ` Ludovic Courtès
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/guile/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87vdj48hmh.fsf@ossau.uklinux.net \
--to=neil@ossau.uklinux.net \
--cc=guile-devel@gnu.org \
--cc=ludo@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).