[Top][All Lists]

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

Re: Debugging plans

From: Thien-Thi Nguyen
Subject: Re: Debugging plans
Date: Sun, 01 Jul 2001 13:41:38 -0700

   From: Neil Jerram <address@hidden>
   Date: 01 Jul 2001 09:29:25 +0100

   - Is it really necessary to use an additional socket for debug info?
     Given that the IDE is the only sink for output from guile, why not
     just use a convention for identifying significant bits of stdout
     (as in current gdb + emacs)?

well, if you ever have to abstract further (like accross a network, or
into an eval board), sockets are a nice standard...  it all boils down
to how far ahead you want to look.  :->  for uni-host debugging, stdout
grokking is fine.

(however, note that gdb does indeed support a serial protocol, and that
emacs groks both subprocess and network stream as "subprocess object",
so this approach is actually already realized in this case; thanks for
making my point! :-)

   It's dead useful that elisp's and scheme's read can read a lot of
   each other's stuff, isn't it!

yes.  IIRC university of washington's imap implementation passed sexps
over the wire, too -- just goes to show other people have good ideas we
can snarf.

   [elisp transaction queues]

   This looks cool; I never knew that elisp/emacs had this kind of
   facility in it!

more spew on my work manglings: say you have a program that spews out
its data structures periodically (like a hardware simulation outputting
registers ;-).  w/ the above approach, i've hooked it up like so:

        program --> emacs

but a little rework like this:

        program --> displayer --> emacs

makes it possible to optimize displayer and swap in something else
besides emacs (for the WIMP folks :-).  typical optimization would be to
cache input and only pass on display events for those structures that
have changed.  displayer can also keep history (for "rewind" and other
"tape-recorder" functionality), write pretty logs, etc.  it's nice if
displayer is implemented in guile, too.  :->


reply via email to

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