[Top][All Lists]

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

Re: Status of the "Project Ideas" page / Summer of Code

From: Martin Kuehl
Subject: Re: Status of the "Project Ideas" page / Summer of Code
Date: Sat, 6 May 2006 00:02:23 +0200

On 5/4/06, Neil Jerram <address@hidden> wrote:
"Martin Kuehl" <address@hidden> writes:

> Hello,
> thanks for the helpful pointers; guile-debugging, guile-vm and the
> compilation discussion all look quite interesting.  The hobbit topic
> feels a little scary though, and I'm not sure I want to try that
> before I've got a little more experience under my belt.
> I was able to take guile-debugging for a spin, it's great, and I agree
> that it makes more sense to complete it than to port swank (the lisp
> server side of slime).  I'm not sure where one would start though --
> the open bugs' summaries are maybe less descriptive than they might be
> ;)
> [Hm.  Does it complete names of modules found on guile's load-path?]

No, it doesn't; that would be a nice feature.  And perhaps
complemented by a super-convenient way to extend the load path of the
guile process.

And if it works smoothly, a module browser could be implemented on top of it.
And the way to extend the load-path could be generalized to
inspect/adapt guile's runtime options.

You mentioned the bugs on, but did you try looking at the
tasks as well?  I think the tasks would be much more suitable for a
SoC project, if any of them interest you.  If you would like me to add
to any of the task descriptions, to explain more what I have in mind,
please let me know.

With "timeout for help-echo evaluations", do you mean that the window
popping up when I, say, `gds-eval-defun' a defun?

The ones that immediately spark my interest are the repl buffer,
module browser and continuation bookmarking.  Of these, I think I'd
find the module browser the most useful, but that's because 1) I don't
think a repl buffer is needed when your "other" buffers are
interactive enough (think lisp-interaction-mode for scheme buffers
with gds underneath) and 2) I have absolutely no idea how a usable
interface for debugging with continuation bookmarks might feel like. I doubt a simple "step forward/backward" ui would capture their style
very well, and I also doubt that the ui for Emacs's own named
bookmarks would suit any kind of debugging session.
This task does sound really fancy though :-)

I'm just now remembering buddha[1], a "declarative debugger" for
Haskell.  An oracle-style interface like that might suit cont.bkm.,
and the capability to substitute expressions on the fly would be a
great improvement.

So... I'd like to take a shot at one of these two, the module browser
or continuation bookmarking.  The former is probably the more
immediate and visible one and has a more definite goal (except for any
other ideas about related conveniences it might lead to), while the
latter feels more flexible and exploratory.

You already noted you'd be happy to help, I take it that you'd be
willing to take the "Mentor" hat then?

Thank you so much for your feedback.



reply via email to

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