8:28 p.m.
Olivier Galibert <galibert(a)pobox.com> writes:
On Fri, Jan 15, 1999 at 01:10:33AM -0800, Marat Boshernitsan wrote:
> I need even more extensibility than XEmacs lisp gives me,
> and modules do just that.
Nice. Now my question is, is being able to add C functions callable from
lisp enough for you, or do you need to "plug" into the C code itself one
way or another?
I'm not 100% sure I understand what you mean by 'plug' into the C code
itself, but here's a stab at a response anyway. :) I assume you mean being
able to call core XEmacs primitives that are already in C?
I'm not sure you can really make a distinction between the two here. When
I did the first very rough cut of the module support, the first module I
wrote was a base64 decoder, which had to deal with all the cruft with MULE,
buffers, GCPRO, throwing errors, etc, etc.
Any non-trivial module would have to do this.
-Bill P.
9:26 p.m.
New subject: Beware of modules.
On Fri, Jan 15, 1999 at 03:28:07PM -0500, William M. Perry wrote:
Olivier Galibert <galibert(a)pobox.com> writes:
> Nice. Now my question is, is being able to add C functions callable from
> lisp enough for you, or do you need to "plug" into the C code itself one
> way or another?
I'm not 100% sure I understand what you mean by 'plug' into the C code
itself, but here's a stab at a response anyway. :) I assume you mean being
able to call core XEmacs primitives that are already in C?
I'm not sure you can really make a distinction between the two here. When
I did the first very rough cut of the module support, the first module I
wrote was a base64 decoder, which had to deal with all the cruft with MULE,
buffers, GCPRO, throwing errors, etc, etc.
Any non-trivial module would have to do this.
And the new stuff is no different. When you use ellcc, you get all of the
XEmacs internal header files so you have access to everything exactly as
the source was configured (including config.h) and the XEmacs executable
itsel fhas all of its symbols exported, so that modules can call any
non-static function and reference (and even modify if it has to) any
non-static variable. Modules are useless without this.
So I guess the answer to OG's question is a resounding "YES", we will
"plug into C code".
--
J. Kean Johnston | "If equal affection cannot be,
Engineer, SPG | let the more loving one be me" - W.H. Auden
Santa Cruz, CA +----------------------------------------------------------
Tel: 831-427-7569 Fax: 831-429-1887 E-mail: jkj(a)sco.com
9:37 p.m.
New subject: Beware of modules.
On Fri, Jan 15, 1999 at 01:26:18PM -0800, J. Kean Johnston wrote:
So I guess the answer to OG's question is a resounding
"YES", we will
"plug into C code".
Which means that we're going to have compatibility problems each time
we change something in the internal C interfaces. This is already a
terrible pain for the lisp code, and you want to extend that to the C
code?
Do you realize that if external third party C modules become the rule,
we can't change anything to the Mule implementation or the lisp
system? That we couldn't have ported to win32? That the "gung ho"
changes would have been impossible to make?
OG.
1:46 a.m.
New subject: Beware of modules.
On Fri, Jan 15, 1999 at 10:37:28PM +0100, Olivier Galibert wrote:
On Fri, Jan 15, 1999 at 01:26:18PM -0800, J. Kean Johnston wrote:
> So I guess the answer to OG's question is a resounding "YES", we will
> "plug into C code".
Which means that we're going to have compatibility problems each time
we change something in the internal C interfaces. This is already a
terrible pain for the lisp code, and you want to extend that to the C
code?
Do you realize that if external third party C modules become the rule,
we can't change anything to the Mule implementation or the lisp
system? That we couldn't have ported to win32? That the "gung ho"
changes would have been impossible to make?
Not so. If we change things
fundamentally in XEmacs, we simply bump the
version number in the module code, and it will refuse to load modules
that were compiled before that version. I explained this all in a previous
message, but thats how we cope with THAT. Its not a show-stopper. If you
try to load an old module you will get a message telling you you can't.
Look at line 350 of emodules.c.
--
J. Kean Johnston | "If equal affection cannot be,
Engineer, SPG | let the more loving one be me" - W.H. Auden
Santa Cruz, CA +----------------------------------------------------------
Tel: 831-427-7569 Fax: 831-429-1887 E-mail: jkj(a)sco.com
10:05 a.m.
New subject: Beware of modules.
>>>> "J" == J Kean Johnston <jkj(a)sco.com>
writes:
J> Not so. If we change things fundamentally in XEmacs, we simply bump the
Changing things fundamentally might mean simply using a different
configure switch, such as --use-minimal-tagbits. Modules should
refuse to load if they are incompatible on the lisp object
representation level.
J> version number in the module code, and it will refuse to load modules
J> that were compiled before that version. I explained this all in a previous
J> message, but thats how we cope with THAT. Its not a show-stopper. If you
J> try to load an old module you will get a message telling you you can't.
J> Look at line 350 of emodules.c.
9255
days inactive
9257
days old
4 comments
4 participants
participants (4)
-
Kean Johnston -
Martin Buchholz -
Olivier Galibert -
William M. Perry