Re: Guile in Emacs (was: integer overflow)

[Ken Raeburn <raeburn@raeburn.org>]

On Mar 8, 2010, at 13:42, Chad Brown wrote:
> Ken Raeburn has done some work on Guile in Emacs, which might be helpful.  There's a (not super-current) status page here:
> 
>  http://www.mit.edu/~raeburn/guilemacs/

Yeah, I haven't updated that in a while...

> Summary: there is something runable, but it's certainly not finished.  There are some design questions that I think it's safe to say are still in an `exploratory' phase.

Yes, though I think many of the open questions can be put off until what I might call "phase 2" ... where "phase 1" just deals with basic object representations, allocation and GC, and keeps the current single-threaded Lisp engine.  I want that to be on solid footing before pushing other stuff forward too much, if only so there's something to show off. :-)

So after "phase 1", I think it would be time to assess how well things work.  Is work in certain areas of Guile needed?  (If so, go hack on Guile a while and come back later.)  Does it do some things better than stock Emacs?  Is it time to discuss whether it would be suitable for integration into Emacs 24/25/26/whatever?  What else needs to happen first?

>  Ken has given some thought to threading (not a surprise if you know Ken), but as of the middle of last year (the date on the status update), I would characterize his progress as `thoughts and questions'.

Yeah, threads bring up lots of interesting issues, and there's enough stuff going on in this Guile project even without having to settle those issues right away.  (Even though my original impetus was wanting to do work in Emacs while Gnus was crunching away on newsgroup data in the same process!)  Other people are already working on related projects (Tom Tromey's work on the Emacs side, and Daniel Kraft and others working on a Lisp reader for Guile) where some of the issues may get hashed out.  Though, I ought to be paying more attention to them....


I haven't made a lot of direct progress on the project since then.  Some amount of my effort has gone into indirectly-helpful sub-projects, like making upstream Emacs work better without doing the unexec step, so that I don't have to make Guile and everything it might link against unexec-friendly, deal with shared libraries in unexec, make static versions of Guile and N other libraries, etc.  (Obviously we don't want Emacs to take forever to start up for end users, but if we don't get another solution for that from the Guile side, we can work on the unexec bits later, and sidestepping that problem for now lets me focus on other things.)  Another one that's appeared on the radar is digging up Dave Love's old work on making Emacs work with Boehm's GC library, which Guile uses, and Emacs-with-Guile would wind up using as a result, but I haven't even started with that one; currently I think I've just had Emacs leak memory since Guile switched to libgc.

(And then there's the new job, which is sucking up a lot of my time now.  Most of the work seems to get done in bursts every several years, when I'm between jobs; then I get a job, or there's some VCS breakage, and the work stops for a while....  I'm hoping to put more time in on it soon, especially since Andy Wingo surprised me with a proposed timeline for finishing this work in his Guile presentation at GHM '09, and I'd like to meet it, but not by going jobless again. :-)

Ken