emacs, guile, and the manual

emacs, guile, and the manual

[Andy Wingo]

Hey folks,

Happy birthday Jao, and happy summering Neil, hope things are going
well. I have a bug for you two :)

I have been poking the manual in the section "Using Guile Interactvely",
in scheme-using.texi. I almost have the description of the REPL and the
debugger updated to reflect the current state of things, at which point
I will breathe a sigh of relief and promptly forget about things -- that
is, if we can decide on what to do about "Using Guile in Emacs".

That section has some excellent documentation for GDS. However, I don't
think GDS works with Guile 2.0, but Geiser does. What should we do to
fix the emacs and guile situation?

My perspective, for what it's worth, is that I am a bit irritated that
Jao chose not to start from GDS, but on the other hand I do understand
the tradeoffs.  Throwing away well-documented, well-written code
does pain me, but we do have to move on somehow...

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.

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.

The debugging integration could probably wait, as debugging VM programs
is still in flux, I think.

What do you all think?

Andy
-- 
http://wingolog.org/

Re: emacs, guile, and the manual

[Neil Jerram]

Andy Wingo <wingo@pobox.com> writes:

> Hey folks,
>
> Happy birthday Jao, and happy summering Neil, hope things are going
> well. I have a bug for you two :)

Hi Andy,

> I have been poking the manual in the section "Using Guile Interactvely",
> in scheme-using.texi. I almost have the description of the REPL and the
> debugger updated to reflect the current state of things, at which point
> I will breathe a sigh of relief and promptly forget about things -- that
> is, if we can decide on what to do about "Using Guile in Emacs".
>
> That section has some excellent documentation for GDS. However, I don't
> think GDS works with Guile 2.0, but Geiser does. What should we do to
> fix the emacs and guile situation?

In general, if any doc is now wrong (in 2.0), surely it must be
removed.  If part of your concern here is about offending me - please
don't worry about that, I won't be offended!

Right now GDS doesn't work, so I think we have to discount it.  If it
was ever resurrected, the doc (to the extent still appropriate) could of
course be resurrected too, from Git.

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

> 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.
>
> 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.

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).

Regards,
      Neil

Re: emacs, guile, and the manual

[Jose A. Ortega Ruiz]

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)

Re: emacs, guile, and the manual

[Andy Wingo]

Hi Neil,

On Wed 28 Jul 2010 19:22, Neil Jerram <neil@ossau.uklinux.net> writes:

> Right now GDS doesn't work, so I think we have to discount it.  If it
> was ever resurrected, the doc (to the extent still appropriate) could of
> course be resurrected too, from Git.

OK.

As far as the debugger goes, I will use the docs that are there as a
guide to the features that I still need to implement (breakpoints and
stepping).

> 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).

Hmmm. Good point. Threads are complicated.

Thanks for your thoughts,

Andy
-- 
http://wingolog.org/