despair, debugging, and the repl

despair, debugging, and the repl

[Andy Wingo]

Greets,

I have on my list of things to do for 2.0 a line that says "REPL docs",
by which I take it to mean that I should be updating the docs in the
manual for the command-line user experience.

I think I've tried to tackle this a couple of times before, and I am
remembering why I stopped:

  * There is a fair amount of old code here (scm-style-repl)

  * There is new code that does the same thing (the (system repl repl)
    module)

  * The old repl code is crufty but surely we have to support some of
    its interfaces (?)

  * Neil's debugger code doesn't work any more but is prettier than
    mine, and did stepping which mine doesn't yet

  * Neil's debugger (and Guile pre-1.9, generally) worked on the
    expression level rather than the function call level, so it could
    give the user nicer information in many cases.

The cumulative effect of all this stilled me back to inaction in the
past, but we should fix this now, I think.

So, to that end, then, here's a preliminary plan of action:

  * Deprecate all of the old repl code, keeping compatibility shims for
    the useful interfaces perhaps, but trying to move the REPL
    implementation entirely out to modules.

  * Remove all of the old debugger code. This pains me somewhat, but we
    have to move forward here.

  * Deprecate the-last-stack fluid -- besides being hard to reason
    about, it doesn't even work all that well.

  * Document the new REPL.

I hope to finish this work within a week or so. Comments welcome!

Andy
-- 
http://wingolog.org/

Re: despair, debugging, and the repl

[Thien-Thi Nguyen]

() Andy Wingo <wingo@pobox.com>
() Thu, 10 Jun 2010 12:03:22 +0200

   So, to that end, then, here's a preliminary plan of action:

     * Deprecate all of the old repl code, keeping compatibility shims for
       the useful interfaces perhaps, but trying to move the REPL
       implementation entirely out to modules.

     * Remove all of the old debugger code. This pains me somewhat, but we
       have to move forward here.

     * Deprecate the-last-stack fluid -- besides being hard to reason
       about, it doesn't even work all that well.

     * Document the new REPL.

If the plan is to modularize, is it possible to keep the old one around
(in a module)?  Surely, not trashing Neil's work entirely is better?

thi

Re: despair, debugging, and the repl

[Andy Wingo]

On Thu 10 Jun 2010 14:45, Thien-Thi Nguyen <ttn@gnuvola.org> writes:

> () Andy Wingo <wingo@pobox.com>
> () Thu, 10 Jun 2010 12:03:22 +0200
>
>    So, to that end, then, here's a preliminary plan of action:
>
>      * Deprecate all of the old repl code, keeping compatibility shims for
>        the useful interfaces perhaps, but trying to move the REPL
>        implementation entirely out to modules.
>
>      * Remove all of the old debugger code. This pains me somewhat, but we
>        have to move forward here.
>
>      * Deprecate the-last-stack fluid -- besides being hard to reason
>        about, it doesn't even work all that well.
>
>      * Document the new REPL.
>
> If the plan is to modularize, is it possible to keep the old one around
> (in a module)?

The old repl, yes. I was wondering how to deprecate it in boot-9 but I
think I have figured out a way.

>  Surely, not trashing Neil's work entirely is better?

Trashing is a loaded word :) It is always available in its original form
in git. But it hasn't worked, is the problem -- it relies on hooks from
ceval and deval that just aren't there any more. The part that coincides
with the new implementation is equivalent in functionality, though
Neil's code is nicer, I admit.

Guile needs to promote one main repl implementation, and one main
debugger. There is room for others, but if they are to remain in Guile
itself, they need to be maintained.

Andy
-- 
http://wingolog.org/

Re: despair, debugging, and the repl

[Thien-Thi Nguyen]

() Andy Wingo <wingo@pobox.com>
() Thu, 10 Jun 2010 16:36:57 +0200

   The old repl, yes. I was wondering how to deprecate it in
   boot-9 but I think I have figured out a way.

Cool.

   >  Surely, not trashing Neil's work entirely is better?

   Trashing is a loaded word :) It is always available in its
   original form in git. But it hasn't worked, is the problem --
   it relies on hooks from ceval and deval that just aren't there
   any more. The part that coincides with the new implementation
   is equivalent in functionality, though Neil's code is nicer, I
   admit.

This suggests to me that the best course is to re-examine both
implementations in terms of high and low layers, substituting the
untenable low bits in Neil's code with the new low bits you wrote,
and keeping the high bits of Neil's code.

   Guile needs to promote one main repl implementation, and one
   main debugger. There is room for others, but if they are to
   remain in Guile itself, they need to be maintained.

Agreed.  I think ultimately whoever does the work (sounds like
it's all you, in this case) decides, so i'll just briefly voice my
support for good documentation of the low bits, perhaps written
before doing anything else, so that if the above old-high/new-low
suggestion is not followed now, perhaps someone can follow it
later.  (Everything is in Git, anyway, as you said.)

thi

Re: despair, debugging, and the repl

[Neil Jerram]

Andy Wingo <wingo@pobox.com> writes:

> So, to that end, then, here's a preliminary plan of action:
>
>   * Deprecate all of the old repl code, keeping compatibility shims for
>     the useful interfaces perhaps, but trying to move the REPL
>     implementation entirely out to modules.
>
>   * Remove all of the old debugger code. This pains me somewhat, but we
>     have to move forward here.
>
>   * Deprecate the-last-stack fluid -- besides being hard to reason
>     about, it doesn't even work all that well.
>
>   * Document the new REPL.
>
> I hope to finish this work within a week or so. Comments welcome!

FWIW, this makes sense to me.

Re: despair, debugging, and the repl

[Ludovic Courtès]

Hello!

Andy Wingo <wingo@pobox.com> writes:

>   * Neil's debugger code doesn't work any more but is prettier than
>     mine, and did stepping which mine doesn't yet
>
>   * Neil's debugger (and Guile pre-1.9, generally) worked on the
>     expression level rather than the function call level, so it could
>     give the user nicer information in many cases.

Yep.

> So, to that end, then, here's a preliminary plan of action:
>
>   * Deprecate all of the old repl code, keeping compatibility shims for
>     the useful interfaces perhaps, but trying to move the REPL
>     implementation entirely out to modules.
>
>   * Remove all of the old debugger code. This pains me somewhat, but we
>     have to move forward here.
>
>   * Deprecate the-last-stack fluid -- besides being hard to reason
>     about, it doesn't even work all that well.
>
>   * Document the new REPL.

Fine with me (but maybe you’ve already finished it in the meantime).

What about single-stepping and expression-level debugging?

Thanks,
Ludo’.

Re: despair, debugging, and the repl

[Andy Wingo]

On Mon 14 Jun 2010 18:29, ludo@gnu.org (Ludovic Courtès) writes:

>> So, to that end, then, here's a preliminary plan of action:
>>
>>   * Deprecate all of the old repl code, keeping compatibility shims for
>>     the useful interfaces perhaps, but trying to move the REPL
>>     implementation entirely out to modules.
>>
>>   * Remove all of the old debugger code. This pains me somewhat, but we
>>     have to move forward here.
>>
>>   * Deprecate the-last-stack fluid -- besides being hard to reason
>>     about, it doesn't even work all that well.
>>
>>   * Document the new REPL.
>
> Fine with me (but maybe you’ve already finished it in the meantime).

No, there are still some repl bits of boot-9 that need limning. I
skipped over some parts when revising boot-9 recently, and hope to come
back to them soonish.

> What about single-stepping

Should be possible, given source line info and the next-instruction
hook.

> and expression-level debugging?

Trickier, we'll need expression-level debug info in the procedure. And
which expressions, the expanded ones or the ones from the original
source? I think I'd need to spend some times with other schemes to
figure this out.

Breakpoints would be good too.

Andy
-- 
http://wingolog.org/