Re: guile and emacs: unexec

[Ken Raeburn]

On Jun 20, 2009, at 05:33, Andy Wingo wrote:
> > It's also kind of appealing to have something at intermediate stages
> > that I might be able to show off, and say "hey, this works well  
> > enough
> > that you can try it out; want to help me on the next steps?"  (And
> > since I'm getting into all this now, I *would* like some help.  I was
> > just intending to fix a few more problems before making the plea. :-)
>
> I'm happy to help in making Guile a better implementation of Elisp  
> than
> the one Emacs has.

It's great to hear that.

> Daniel's work looks promising in this regard -- his idea was to make
> function values and symbol values resolve the same Guile symbol in
> different modules. The bindings would be Guile's fluids. Compilation
> would take care of the translation. Hopefully by the time you're  
> ready,
> we'll be ready with that too.

At some point soon, I am going to have to go look much more closely at  
this...  I hope I can steer my project in a direction where I can take  
advantage of some of this sooner rather than later.

> > I actually had it pretty far along once or twice before (I seem to  
> > keep
> > reviving this every few years, and spend a lot of time updating  to
> > newer code bases), but I think I've managed to push it a bit  further
> > than I had it earlier.  With just me working on it, depending  on the
> > demands of my job, there tend to be large periods when no  progress  
> > gets
> > made, and it doesn't keep up with the upstream sources;  the  
> > prospect of
> > having to do a bunch of catch-up work just makes it  that much less
> > appealing to get back into it.  It's been moving  forward in spurts  
> > for
> > over a decade now, very slowly. :-(
>
> You know though, this whole free software thing is actually OK in this
> respect. There are some technologies that just don't change very
> quickly. Keisuke had a VM working in 2001, but only now in the  
> middle of
> 2009 have we merged it into Guile. We'll make it :)

True.  It's just a bit discouraging to have such a big project in the  
works, but making relatively little progress; I want it to get  
*done*! :-)  Especially since, as some folks on the Emacs side remain  
unconvinced, it won't be until it's nearly at the "done" stage that  
I'll find out whether it's just been a huge waste of time.

> Ah, I was referring to programming languages ;) Human language is
> another kettle of fish. Doesn't emacs support a superset of unicode?

Oh, I misunderstood.  That's more interesting to me at the moment,  
especially if it means that as a by-product it'd someday be possible  
to write code for guile-emacs in perl or python too...

> Yes we want to make that work *correctly*, exactly as Emacs does. I
> think we can do it. I bet frames and buffers should also have modules,
> modules that use the global function or variable modules, as
> appropriate -- would provide for quite fast lookup and switching.

I'll be delighted if the performance is comparable to or better than  
Emacs has now, given that the Lisp system is targeted for Emacs  
specifically, without needing to worry about thread support or any of  
that stuff.  When I get to the higher-level stuff, modules are another  
thing I'll need to learn more about. :-)

> > [...use of git...]
> > Yep, but I need to get proficient with it first, and haven't put in  
> > the
> > time yet; until then I'm using subversion in a rather clumsy  fashion
> > (often just checkpointing untested merges, and my Emacs  sources have
> > the CVS admin files checked in so I can update easily).   If it's
> > something other people want to actually work on, on the other   
> > hand, we
> > could set up something via sourceforge or savannah or  whatever.  But
> > only if there's actually going to be additional help  coming....
>
> I would suggest setting up a Git repository on savannah, branching  
> from
> the Emacs git mirror. Then I would suggest distilling your patches  
> into
> correct, standalone patches, and committing those one-by-one. This  
> will
> help Emacs developers in addition to Guile developers.

Heh... um, well, it's not that clean or even "correct", right now.   
The hacks I've had to use relating to the "all-bits-zero is a valid  
lisp object" assumption are scattered through a lot of the code, and I  
keep finding myself adding more at random times as I chase down  
crashes or other odd behavior.  I've got ideas on how to fix it more  
properly, but at least temporarily it will involve additional  
divergence from the upstream Emacs sources (like, probably adding  
static initialization to all the static-storage lisp object  
variables).  Hmm... come to think of it, that's probably the worst  
piece by far, so maybe *that* should be my next sub-project, rather  
than changing object type reps.  But upstream Emacs looks like it's  
going to be frozen for new features and major changes for some time to  
come, so this would make merges annoying for quite a while, unless I  
can convince people that it wouldn't actually destabilize anything.   
Hmm...

And, as I say, I've got to learn the ins and outs of git better first,  
though, before I can set up this repository.

> It would probably
> be fine to use guile-devel as your mailing list for now -- if it ever
> becomes a problem (unlikely, as we all want Guile in Emacs :) we can
> split out another ML.

I actually got a mailing list or two created years ago, back when  
Cygnus existed and had its sourceware site, now at sourceware.org I  
think, called guile-emacs or some such; it's been pretty dead for the  
last few years.  I could make new lists at savannah, but really, with  
the level of traffic involved, guile-devel would probably work fine too.

Ken