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

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

[Martin Kuehl]

[-- Attachment #1: Type: text/plain, Size: 1647 bytes --]

Hello all,

I stumbled upon the Guile Project's "Project Ideas"[1] page while
looking for inspiration for this year's issue of Google's "Summer of
Code", and I think guile would make an interesting project to hack on.

I saw the "Does Guile still need to be listed on help-wanted?"
thread[2] though, so I wonder whether any one of you is interested in
mentoring an SoC student?

Also, the ideas page looks quite out of date (it mentions R5RS
compliance and GMP, e.g.) and most CVS modules[3] don't include a `TODO'
file, so what's the status of the items on that page, and which might
be completed in a period of ~3 months?
I'm "mainly" interested in the "Value history", "C parser" and "Henry
Spencer's regexp matcher" items and garbage collection (I also read
the "Guile + Boehm GC" thread[4], so I'll assume this is an open
issue).

I was also thinking about SLIME[5] support, probably by porting
slime48[6], and maybe even evaluationg what's been done for Pika
Scheme[7] -- and ripping out the good bits... Feedback anyone?

This concludes my inquiry, thank you four your attention, and please
excuse all those footnotes ;-)

 Martin


Footnotes:
[1]  http://www.gnu.org/software/guile/ideas.html
[2]  http://lists.gnu.org/archive/html/guile-devel/2006-03/msg00001.html
[3]  read: all but -oops, -tk, qscheme and workbook ;-)
[4]  http://lists.gnu.org/archive/html/guile-devel/2006-03/msg00047.html
[5]  http://common-lisp.net/project/slime/
[6]  http://mumble.net/~campbell/scheme/slime48/
[7]  http://savannah.nongnu.org/projects/pika

--
"We are stuck with technology when what we really want
 is just stuff that works."
  -- Douglas Adams

[-- Attachment #2: Type: text/plain, Size: 143 bytes --]

_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel

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

[Andy Wingo]

Hi Martin,

On Mon, 2006-04-24 at 23:17 +0200, Martin Kuehl wrote:
> I stumbled upon the Guile Project's "Project Ideas"[1] page while
> looking for inspiration for this year's issue of Google's "Summer of
> Code", and I think guile would make an interesting project to hack on.

Neat! Guile is quite a useful scheme implementation.

I don't know that I would be qualified to mentor, but I can comment on
the potential of some of the ideas. The ideas page is indeed *really*
out of date.

> I'm "mainly" interested in the "Value history", "C parser" and "Henry
> Spencer's regexp matcher" items and garbage collection (I also read
> the "Guile + Boehm GC" thread[4], so I'll assume this is an open
> issue).
> 
> I was also thinking about SLIME[5] support, probably by porting
> slime48[6], and maybe even evaluationg what's been done for Pika
> Scheme[7] -- and ripping out the good bits... Feedback anyone?

Value history has existed ((ice-9 history), a 100-line hack) at least
since I started using guile in 2003. I can't bear to go through that
list right now, there are too many old things... someone (ahem) should
find the time to take out the lawn-mower.

Guile+boehm gc would indeed be very interesting. You should probably
talk to han-wen at some point, who afaiu did most of the gc hacking for
1.7/1.8.

Slime support would be verrry interesting (I wrote about it once [0]),
and probably should be done using ports from scheme48. It shouldn't be
too terribly hard, either. Neil Jerram has done a lot of guile<->emacs
work, perhaps he has some thoughts on the subject.

The other perennial topic with guile is compilation -- many important
operations are fundamentally limited by interpreter speed (large GOOPS
libraries, for example) -- compilation is the only reasonable way to
improve this IMO. There have been a few ideas, including a port of
hobbit to guile from a while ago, but a comprehensive solution should
take macros and modules into account. There is was a thread on
guile-devel in 2004 [1] that's still relevant about the topic; also the
"You want it when?" paper by Flatt.

To finish my rambling on compilation: to be something that would be
likely to be used in the future, it should take modules and macros into
account. There have been quite a few halfway attempts. It would probably
be acceptable to ignore r5rs macros, as being very complicated, and in
the hopes that something like srfi-72 replaces them. As for libraries,
guile will probably (I think) adopt r6rs libraries as its native module
format, whenever it is that it gets standardized (srfi-83). It might be
easier to base such a system on a minimal implementation of srfi-83.

So, for summer-of-code it would be very educational for a more advanced
student to have a stab at the compilation problem. You can go very far,
and learn a lot of interesting things. That's the most exciting one
imo :)

[0] http://wingolog.org/archives/2006/01/02/slime
[1]
http://news.gmane.org/find-root.php?group=gmane.lisp.guile.devel&article=1787

Happy hacking,
-- 
Andy Wingo
http://wingolog.org/



_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel

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

[Neil Jerram]

Andy Wingo <wingo@pobox.com> writes:

> Hi Martin,
>
> On Mon, 2006-04-24 at 23:17 +0200, Martin Kuehl wrote:
>> 
>> I was also thinking about SLIME[5] support, probably by porting
>> slime48[6], and maybe even evaluationg what's been done for Pika
>> Scheme[7] -- and ripping out the good bits... Feedback anyone?

> Slime support would be verrry interesting (I wrote about it once [0]),
> and probably should be done using ports from scheme48. It shouldn't be
> too terribly hard, either. Neil Jerram has done a lot of guile<->emacs
> work, perhaps he has some thoughts on the subject.

Yes; I think my guile-debugging package (available from gna.org)
pretty much covers this area, and if there are missing features it
would probably make sense to fill them in in guile-debugging, rather
than port SLIME as a whole.  I'd be very happy to help someone work in
this area.

(FWIW, I was unaware of SLIME until I came across Andy's blog entry
recently, but was then surprised by how similar SLIME's architecture
and approach are to guile-debugging's.  It's also worth noting that
guile-debugging builds on the nice low-level debugging features in the
Guile evaluator code, which I presume are a bit different from
corresponding features in other Schemes.)

Regards,
    Neil



_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel

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

[Ludovic Courtès]

Hi,

On Mon, Apr 24, 2006 at 11:17:17PM +0200, Martin Kuehl wrote:
> (I also read
> the "Guile + Boehm GC" thread[4], so I'll assume this is an open
> issue).

Just to let you know: I've been working on this over the past weeks
and I'm getting to something nice.  Hopefully, I'll post a status
summary next week or so to this list.

BTW, I think you forgot to mention Guile-VM which I started to revive
some time ago but haven't been able to work on lately.  So that might
count as a nice SOC project as well (you can search the archives for
details and code pointers).

Thanks,
Ludovic.



_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel

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

[Martin Kuehl]

[-- Attachment #1: Type: text/plain, Size: 1167 bytes --]

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?]

Guile-VM also sounds neat, but I was neither able to compile the code
from CVS head nor to fetch the revival code from Ludovics arch repo,
which makes it even harder to devise a plan of action.  Judging from
the mail thread about its revival, completing the translation from
Scheme to Ghil and/or from Glil to assembly might be good candidates. 
Another might be comparison with "similar" VMs and ILs (the thread
mentions STklos; s48s "PreScheme" also comes to mind).

So... I'm willing to help -- is this roughly the right track?

Cheers,
 Martin

[-- Attachment #2: Type: text/plain, Size: 143 bytes --]

_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel

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

[Ludovic Courtès]

Hi,

"Martin Kuehl" <martin.kuehl@gmail.com> writes:

> Guile-VM also sounds neat, but I was neither able to compile the code
> from CVS head nor to fetch the revival code from Ludovics arch repo,
> which makes it even harder to devise a plan of action.  Judging from
> the mail thread about its revival, completing the translation from
> Scheme to Ghil and/or from Glil to assembly might be good
> candidates. Another might be comparison with "similar" VMs and ILs
> (the thread
> mentions STklos; s48s "PreScheme" also comes to mind).

To fetch it:

  $ tla register-archive \
    http://www.laas.fr/~lcourtes/software/arch-2004/
  $ tla get lcourtes@laas.fr--2004-libre/guile-vm--revival--0.6 guile-vm

To summarize: the main issue left (and probably the main reason why
Keisuke Nishida never "finished" it) is the integration of first-class
macros.  Preserving the current semantics may be feasible but requires
some thought.  There are a couple of papers available from
library.readscheme.org on the compilation of first-class macros.

Apart from macros, compilation from Scheme to GHIL, GLIL and then
bytecode basically works.  Bytecode interpretation (the VM) is also
roughly functional.

Thanks,
Ludovic.


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel

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

[Martin Kuehl]

On 5/2/06, Ludovic Courtès <ludovic.courtes@laas.fr> wrote:
> To fetch it:
>
>   $ tla register-archive \
>     http://www.laas.fr/~lcourtes/software/arch-2004/
>   $ tla get lcourtes@laas.fr--2004-libre/guile-vm--revival--0.6 guile-vm
>
> To summarize: the main issue left (and probably the main reason why
> Keisuke Nishida never "finished" it) is the integration of first-class
> macros.  Preserving the current semantics may be feasible but requires
> some thought.  There are a couple of papers available from
> library.readscheme.org on the compilation of first-class macros.
>
> Apart from macros, compilation from Scheme to GHIL, GLIL and then
> bytecode basically works.  Bytecode interpretation (the VM) is also
> roughly functional.

Damn, macros again :-)
I'll definitely take a look at the revival, but I really doubt I'm the
one to take on first-class macros just yet.  I seem to have a hard
time reasoning about them instead of CL macros (or maybe I just
confuse them too much with Haskell-style pattern matching, i'm not
sure), and that's something I'd want to change before dealing with
their compilation.

Thanks again for the pointers,
 Martin


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel

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

[Clinton Ebadi]

[-- Attachment #1.1: Type: text/plain, Size: 1476 bytes --]

On Sat, 2006-05-06 at 00:02 +0200, Martin Kuehl wrote:
> Damn, macros again :-)
> I'll definitely take a look at the revival, but I really doubt I'm the
> one to take on first-class macros just yet.  I seem to have a hard
> time reasoning about them instead of CL macros (or maybe I just
> confuse them too much with Haskell-style pattern matching, i'm not
> sure), and that's something I'd want to change before dealing with
> their compilation.

Guile's built in macros are unhygenic, and work in the same way that
Common Lisp macros do.

A few weeks ago I spent a few hours in the eval code, and it looks like
the big thing that still needs doing is making memoization and macro
expansion eager (macroexpand + memoize an entire expression before
beggining to evaluate any part of it instead of waiting until the
evaluator evals the statement itself like it does now).

Once that is done then the first part of the eval should be split into a
compiler, and the second half into the actual eval step. Then it would
be relatively trivial to drop a new compiler/executor into Guile (if I
understood the code correctly). All the new backend would need to do is
understand the primitive operations that the macroexpander/memoizer
produces.

-- 
http://unknownlamer.org
AIM:unknownlamer IRC:unknown_lamer@fnode#tpu Jabber:clinton@hcoop.net
I use Free Software because I value freedom over features.
443E 4F1A E213 7C54 A306  E328 7601 A1F0 F403 574B

[-- Attachment #1.2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

[-- Attachment #2: Type: text/plain, Size: 143 bytes --]

_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel

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

[Neil Jerram]

"Martin Kuehl" <martin.kuehl@gmail.com> 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.

You mentioned the bugs on gna.org, 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.

Please also feel free to suggest more of your own ideas too, of
course.

Regards,
        Neil



_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel

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

[Martin Kuehl]

On 5/4/06, Neil Jerram <neil@ossau.uklinux.net> wrote:
> "Martin Kuehl" <martin.kuehl@gmail.com> 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 gna.org, 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.

Cheers,
 Martin

[1]  http://www.cs.mu.oz.au/~bjpop/buddha/


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel

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

[Neil Jerram]

"Martin Kuehl" <martin.kuehl@gmail.com> writes:

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

Yes, those would both be nice features too.

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

No; the scenario here is when displaying an error stack or stopped at
a breakpoint, so Emacs is displaying the stack in one window and the
source for the selected stack frame in the other window.  In this
state, if you hover the mouse over a variable (or in fact any
identifier) in the highlighted source code, GDS will send a request to
the Guile process to get the value of that variable, and then display
the value in a help-echo (aka tooltip).

Currently the tooltip display routine calls accept-process-output
synchronously until the value comes back from the Guile process, so
GDS will be deadlocked if something goes wrong and prevents the value
from coming back.  Therefore the idea of this task is to impose a
timeout on this.

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

I just took a quick look at [1] (just the "What is buddha?") and I'm
afraid I can't immediately see the connections.  Can you explain a bit
further what you have in mind?

Regards,
        Neil



_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel

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

[Martin Kuehl]

[-- Attachment #1: Type: text/plain, Size: 1353 bytes --]

Hello,

[Sorry if this arrives twice, gmail somehow base64-encoded the last version.]

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?]

Guile-VM also sounds neat, but I was neither able to compile the code
from CVS head nor to fetch the revival code from Ludovics arch repo,
which makes it even harder to devise a plan of action.  Judging from
the mail thread about its revival, completing the translation from
Scheme to Ghil and/or from Glil to assembly might be good candidates.
Another might be comparison with "similar" VMs and ILs (the thread
mentions STklos; s48s "PreScheme" also comes to mind).
[Except PreScheme isn't an IL; it's compiled to C but AFAIK not from
Scheme.  Might still be worth a look.]

So... I'm willing to help -- is this roughly the right track?

Cheers,
 Martin

[-- Attachment #2: Type: text/plain, Size: 143 bytes --]

_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel