Re: Need internal help please (dynamic loading support)
"J. Kean Johnston" <jkj(a)sco.com> writes:
On Tue, Sep 08, 1998 at 06:03:07PM -0700, Darryl Okahata wrote:
> > Over the weekend I had what I thought was a bright idea. While Elisp is
> > ummm ... fine and dandy, I figured it would be nice if it were possible to
> > extend XEmacs using dynamically loaded objects. For those applications
> > that are very CPU intensive, it would make more sense (and make for much
> > greater speed) if they were written in C and then loaded into emacs.
>
> Ummm:
>
> 1. It's already been done (and is a part of XEmacs 21.0), but it hasn't
> been widely publicized, because of various remaining issues (which
> might cause the interface to change, etc.). See the source file
> "src/dll.c".
>
> [ Bottom line: it's not yet ready for prime time. Think of it as a
> prototype: you can play with it, but don't depend on it. ]
Ok ... I had a look at it and the stuff I did for 20.4 was much further
along, and works as well with 21 as it was with 20.4. I dont know how
close 201 is to release, but this is an area I know a great deal about
(the technology, not getting it to play nicely with XEmacs). I would like
to make this work, and believe I can with a little internals help. It
would make things go much faster if I could ask questions and get them
answered rather than wading through large doucments.
Does anyone really care about this or am I the sole torch barer? The
stuff in dll.c, while its on the right track, is missing lots of
things. I already have them so lets try and save duplication of
effort. Here's what I have got:
I'm definitely a fellow torch bearer, since I wrote all the original
stuff and the samples. Due to personal issues I've had zilch time for
serious hacking since january of this year though.
a) Functions for loading and unloading DLLs.
This is all in sysdll.[ch] right now - it should work on just about all
known unix operating systems, as well as windows.
b) Function for listing loaded DLLs and their versions
Not sure if we really need this or not, but it could be handy for
debugging stuff. Save the situation of 'I just changed that .el file, why
aren't I seeing my changes'. :)
c) A sensible and similar (to the internals) API, which is partly
documented
already.
d) Required patches for the Makefile to propperly support dynamic
loading.
That should be taken care of already as well. Just need to add some
stuff for linux and HP/UX to export symbols to the loaded modules. I
thought I had done that already, but it seems to be missing from the CVS
versions.
e) Samples that actually work. None of the stuff in modules/* will
work at
all, as dll.c is expecting to find a symbol emacs_initialize, which
doesn't exist in any of the samples.
Ooops, I must never have submitted my patches... someone changed the
dll.c and not the modules, and I'm the only one who really ever builds the
modules evidently. _MY_ local CVS tree builds just fine. :)
f) A plan (and 90% implementation) for making it easy for any user to
compile
module source and have it loaded. This involves copying the right header
files across and providing 2 shell scripts which invoke the compiler and
linker correctly.
I had planned on doing something similar to Perl's Makefile.PL stuff.
You would write a Makefile.el script describing your targets and things
like that, and:
xemacs -batch -e "(require 'makemaker)" -f make-makefile Makefile.el
g) Time and inclination to see this through quickly and correctly :-)
We don't want to be too quick about it, but this is something I
definitely want to see in 21.x (x > 0). As always, correctness counts more
than quickness. :) I'm trying to free up more time for hacking on XEmacs
and Emacs, but time will tell.
-Bill P.