10:20 a.m.
Jerry James <james(a)xemacs.org> writes:
(2) Performance, performance, performance. Did I mention
performance?
My ViaVoice module is already too slow. Forcing it to go through
Elisp every time, even when the Elisp is just going to call back
into C, isn't going to speed it up any.
My initial thought on this one was to use a language-level
solution. Have the module writer identify functions to be called
and variables to be accessed in some idiomatic way, and then have
ellcc do something to compile down to C function calls and C
variable accesses whenever possible, using the Lisp interface
otherwise. **Note that this means that the binary version of a
module will be specific to the version of XEmacs corresponding to
the ellcc that produced it.** I proposed something along those
lines awhile back, only I got too ambitious and proposed a similar
approach for the XEmacs core as well. Martin (rightly!) shot me
down. :-)
I still agree with Martin and I think we should not put too
much effort to imporove perfermance. This does not prevent
you from working on those code but IMHO defining API and
writing documentation is much more important for majority of
users.
My plan is to approach the tasks in this order:
1. Spec out the "obvious" API described above, and announce it as module
API version 0.1, so that potential module writers can get started.
I'm concentrating on this part so I'll send my proposal
about how we will define API to this list.
2. Change event hooking and unhooking so that it will be accessible
to
module writers. (In fact, *un*hooking isn't even possible right now,
so that will be a bonus.) Document this in API version 0.2.
3. Build a tool which will assemble a list of C functions and variables
that are visible from Lisp and record their [Lisp name -> C name]
mappings in a place accessible to ellcc.
4. Come up with an idiom for identifying Lisp accesses in a module, and
make ellcc compare with the list built by 3 in order to optimize
access in the current module. Also, give ellcc a switch to turn this
optimization off, in order to generate XEmacs version independent
modules. Document this in API version 0.3.
Several. Identify Lisp functions and variables which will always and
forever be implemented in C. Either:
(a) let module writers have direct access to those; or
(b) make ellcc always compile them to direct C accesses, even when
the optimization switch is off.
Identify them in the official API and release version 1.0.
Many. Get to work on figuring out how to write an Elisp -> module
converter, followed by optimizing intermodule function/variable
accesses.
This is a pretty interesting project. However, I doubt how
much that buys us with performance. It's too hard for
simply try and see the results. Again, I wouldn't do that
myself, but if you really want to do it, just go ahead.
Bigloo project might be interesting to you. It compiles
Scheme to executable code or Java byte code.
http://kaolin.unice.fr/~serrano/bigloo/bigloo.html
> BTW, I have written a module for using Subversion[1] from Emacs
> Lisp. I've been too busy to propose it to be included in
> XEmacs, though.
>
> [1] http://subversion.tigris.org/
> The Ruby binding which I also wrote is in Subversion repository.
Cool! Is your module publically available anywhere?
It's at
http://www.sodan.org/~penny/XEmacs/xemacs-svn-0.0.2.tar.gz
but it doesn't compile with the latest Subversion due to the
interface change of Subversion. I'll release a new version
in a few days but my development environment is not quite
ready. I've been setting up my new laptop lately.
In other module news, let me tell you about some ViaVoice
developments.
After writing the C code, I couldn't seem to find time to finish the
module off properly by writing all the Elisp to use it. So when the
graduate level Software Engineering class here asked for projects, I
offered that one up. Some students in that class did a really nice job
of developing it further. It still isn't what I would consider done,
but it is a lot further along. After I do a little cleanup on it, I'll
release it.
Very cool.
"Stephen J. Turnbull" <stephen(a)xemacs.org> writes:
>>>>> "Jerry" == Jerry James
<james(a)xemacs.org> writes:
Jerry> The obvious API would completely isolate the XEmacs
Jerry> internals from the modules,
Then why not write the whole thing in Lisp in the first place? (Yes,
you mentioned real-time apps, already.) This is pretty much a non-
starter AFAICS. I wouldn't even bother to write it up, if I were you.
My primary motivation to write module is to provide glue
code between libraries written in C and Emacs Lisp. To make
glue code as XEmacs version independent as possible, we need
standard API and it must be free from internal details.
As an added note, I'm thinking about adding configure option
to compile database.c, postgres.c, ldap.c, mule-wnnfns.c and
mule-canna.c as external module. With this change, Debian
doesn't maintain two binaries for mule, with and without wnn
and canna. Also it partially solves conflicting library
problem. For example, right now you cannot use ldap and db3
support at the same time because openldap pulls in db2.
Andrew Begel <abegel(a)eecs.berkeley.edu> writes:
Sure, it would have been nice, back when Emacs/XEmacs was young and
small to have thought about externally written plug-ins, but I suspect
that any good solution might require a fair bit of rearchitecting, and
at low levels too.
I think it's worth the effort because XEmacs will be in more
good shape. I'm ready to spend some time on it.
The current solution is that you need to know how to find the
functions
you're looking for inside XEmacs, and release your module to be tied to
a specific XEmacs major/minor release. I know that my module needed to
be modified between 21.1 and 21.4 because of some API changes, and that
was fine; I updated it and my module's source code now works with both
versions.
Sure, it's a pain in the butt to always have to check my module's
compatiblity with each new release of XEmacs, but that's the price to
pay for an active ongoing project (in my case, a research project at a
university).
It's not too hard for you and me to follow the API change in
XEmacs core but I don't expect Sunday hacker would be
willing to do the same. It's true that current situation is
not too bad but I don't expect external module will be
promoted to supported feature unless we have good API.
BTW, you can't force modules to be completely in Lisp when
attaching
legacy code written in another language (C, C++) to XEmacs. XEmacs
ability to call into C is good enough. It's not a bad thing to write
plug-ins in C or C++ -- just a different source language. If you want to
write a foreign function interface to ELisp, that wouldn't be a bad
idea; it'd be hard, but not a horrible idea. Perhaps the SWIG project
team could be persuaded to implement it...
Fully agreed. I looked at SWIG code a few weeks ago. It's
not easy to write new language module but it's not too hard
either. I estimate it to be one programmer week job. Any
volunteers to write it? You need to familiar with both SWIG
and XEmacs internals. Also, it requires minimal amount of
C++ knowledge. I'll eventually do it myself if no one else
does but it'd be nice if any lurker steps up and implement
it.
--
Yoshiki Hayashi