Re: Guile in Emacs (was: integer overflow)

[Ken Raeburn]

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