11:29 p.m.
Hello all.
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.
A faster HTML parser would be a good example. So I styarted hacking about
in the source and I now have rudimentary support for this. I have added
the commands for loading in .sos and I am doing almost everything right.
However, there are some problems.
I would like to enlist the help of an XEmacs internals guru to get me over
these hurdles, if you think this would be a worthwhile exercise. I already
have things set up such that compiling modules is trivial (and will work
the same way on all platforms that support dlopen()). Here is what I dont
know how to do, or do properly:
a) Getting DOC strings for variables defined correctly. When the .so is loaded
in, a special function is called which does the moral equivalent of
DEFSUBR() or DEFVAR_LISP() et al. I can see the variables defined but
I dont know how to go about making the doc string visible.
b) When i DEFSUBR() a function that was declared in the .so, and try to execute
it, I get a SIGSEGV in Fcommanp when it calls SUBRP(fun).
There is deep dark stuff I dont understand too well and would like to. Such
as:
1) What is staticpro?
2) When do I need to GCPRO and when not? Whats the difference between
GCPRO and NGCPRO?
3) Since this is all dynamic, after Emacs has dumped, how do I avoid
purespace? Do I need to? Can I use xmalloc() for internal data?
4) If there is an existing Lisp or even intern function, can I replace its
definition with a new one? How? Same thing for variables.
Any help at all would be GREATLY appreciated. If it would help to talk
by phone rather than email, let me know and I can either call or give you
a 1-800 number for you to call me at. If you can help out, I would appreciate
it if you could respond privately, as I dont read the whole list very often.
I will summarise my findings.
Thanks in advance,
--
J. Kean Johnston | "Truth and beauty, beauty and truth. This is all we know,
Engineer, SPG | and all we need ever know." -- John Keats, Endymion
Santa Cruz, CA +----------------------------------------------------------
Tel: 408-427-7569 Fax: 408-429-1887 E-mail: jkj(a)sco.com
2:03 a.m.
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. ]
2. For XEmacs internals, see the XEmacs Internals Manual, which is
distributed with XEmacs.
--
Darryl Okahata
darrylo(a)sr.hp.com
DISCLAIMER: this message is the author's personal opinion and does not
constitute the support, opinion, or policy of Hewlett-Packard, or of the
little green men that have been following him all day.
7:11 a.m.
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:
a) Functions for loading and unloading DLLs.
b) Function for listing loaded DLLs and their versions
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.
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.
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.
g) Time and inclination to see this through quickly and correctly :-)
--
J. Kean Johnston | "Truth and beauty, beauty and truth. This is all we know,
Engineer, SPG | and all we need ever know." -- John Keats, Endymion
Santa Cruz, CA +----------------------------------------------------------
Tel: 408-427-7569 Fax: 408-429-1887 E-mail: jkj(a)sco.com
10:20 a.m.
This file contains a RealAudio attachment.
RealPlayer v4.0 or later is required.
A version of this message in GSM WAV format is located at
http://www.666.com/audio/mail/19980909-2-gsm-8k.wav
J. Kean Johnston wrote:
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:
a) Functions for loading and unloading DLLs.
b) Function for listing loaded DLLs and their versions
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.
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.
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.
g) Time and inclination to see this through quickly and correctly :-)
--
J. Kean Johnston | "Truth and beauty, beauty and truth. This is all we know,
Engineer, SPG | and all we need ever know." -- John Keats, Endymion
Santa Cruz, CA +----------------------------------------------------------
Tel: 408-427-7569 Fax: 408-429-1887 E-mail: jkj(a)sco.com
--
Ben Wing
- If this message is long and typed, someone else typed it for me
- If it has a .rm (RealAudio) attachment, see
http://www.real.com/products/player/downloadrealplayer.html?wp=dl0498
- If this doesn't work and there's a GSM WAV attachment, see
http://xanim.va.pubnix.com/home.html
9572
days inactive
9573
days old
3 comments
3 participants
participants (3)
-
Ben Wing -
Darryl Okahata -
Kean Johnston