On Sep 1, 2008, at 16:30, Ludovic Courtès wrote:
On a tangent, is anyone still seriously considering to run Emacs
atop GUILE?
There's Ken Reaburn's attempt at http://www.mit.edu/~raeburn/guilemacs/
,
and there's also the Elisp support that's under `lang'. I don't think
the former is really maintained. The latter isn't actively maintained
either but I think it's in a pretty good shape. Neil?
Still keeping it in the back of my mind, but first my attempts to use
SVK to mirror the Emacs repository broke (naturally, after it had
looked solid enough that I had switched to it for my Emacs development
work), and now Guile uses git, which I've never picked up, and some
Emacs folks are talking about changing to yet another source control
system. (BTW, are people aware that the www.gnu.org pages for guile
list an ftp snapshot site that has in fact not been updated since last
September? For people not interested in downloading, installing, and
learning N new source control systems, daily or weekly snapshots are
handy.)
I'm thinking that if I do pick this project up again, it'll probably
be with released versions of Guile; as long as Emacs continues to use
CVS, I can easily stay current with that.
I did play with it a little bit a few months ago, and found one
annoying problem:
I'm using a Mac as my main machine these days. The Emacs unexec
mechanism interacts badly with the Mac version of malloc, so Emacs
uses its own version specially tailored to use Mac system allocation
routines in a way that works with unexec. Guile doesn't have any
hooks for doing that sort of thing. Of course you can configure with -
Dmalloc=unexec_malloc and so on, but then you're guaranteed not to be
able to build an actual guile interpreter executable without the extra
Emacs code. An alternative is to set up Emacs to not use unexec, but
that's uncommon enough a configuration that you can't always expect it
to work -- or expect anyone else to be terribly interested in why
Emacs-without-unexec (even without Guile-related hacks) behaves
strangely.
My work -- as far as it had progressed -- has nothing to do with
converting lisp to scheme or anything like that. My "phase one"
project keeps all the lisp evaluation code intact, and while both
interpreters could conceivably be used and objects from each language
might even be visible to the other, they may have totally different
types -- like lisp strings with their text properties and such could
be smobs in guile...
Ken
