Re: emacs, guile, and the manual

["Jose A. Ortega Ruiz" <jao@gnu.org>]

On Wed, Jul 28 2010, Neil Jerram wrote:


[...]

> Jao said he wanted to work on some manual doc for Geiser - I wonder how
> that is going?

It's still work in progress. Most of what i have so far (a bit more than
half the tutorial) is online at <http://www.nongnu.org/geiser>.
>
>> I would be OK with excising GDS and its docs, and having the manual
>> endorse Geiser, *IF* someone (Jao?) takes a close look at GDS docs and
>> code, takes notes on what's useful, and replicates those bits of
>> functionality in Geiser.
>
> Agreed, and I imagine that's not too far in practice from what Jao was
> already planning.
>
>> In particular I would be happy if I could connect to a TCP port running
>> on an application from Emacs (not requiring stdin to be the repl). I
>> suppose that port could just be running a new REPL on a telnet, which
>> does have the advantage that you can connect to it with plain comint.

That's actually my plan. All that's needed is a Guile module that spawns
a thread serving a REPL over a socket and writing an elisp function, and
everything that works today for a locally run REPL will work for a
remote connection (modulo firewalls and such). The only reason i haven't
written that yet is that i don't need it :)

>> The debugging integration could probably wait, as debugging VM programs
>> is still in flux, I think.
>
> When debugging integration is (at some future time) included, I think
> the application<->debugger channel will need to be more complex than a
> normal REPL - for example, so that there is a way for the application to
> tell the debugger when a breakpoint has been hit (on some thread other
> than the TCP port thread).  Therefore it may not be wise to begin with a
> REPL implementation now.

So far, the Guile 2.0 debugger is based on a REPL, and Geiser copes well
with it, although we need some polish, possibly defining some Emacs
commands that send the appropriate comma-commands to Guile's REPL. If it
were up to me, i would implement breakpoints and stepping also via the
debugging REPL; but this preference is, i am sure, highly influenced by
the fact that that be very easy to support in Geiser.

> On the other hand, a REPL is fine for things like help, introspection
> and evaluation (and tracing, if asynchronous trace output doesn't get
> mixed up with other REPL output), so if it's really easy to implement a
> REPL-based channel, probably that is worth doing in the interim after
> all (until VM debugging crystallises).

Agreed. Using a debugger model a la GDS in Geiser would require
considerable tweaking of the latter's internals, given its current REPL
bias. If it finally comes out that GDS's is the right debugging story
for Guile 2.x, that'll be the time to start the effort of redesigning
Geiser.

Cheers,
jao
--
Not far from the invention of fire must rank the invention of doubt.
-Thomas Henry Huxley, biologist (1825-1895)