[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: guile and emacs: unexec
From: |
Ken Raeburn |
Subject: |
Re: guile and emacs: unexec |
Date: |
Sat, 20 Jun 2009 19:58:04 -0400 |
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