[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Dynamic loading progress
From: |
Eli Zaretskii |
Subject: |
Re: Dynamic loading progress |
Date: |
Sun, 15 Feb 2015 19:34:16 +0200 |
> From: "Stephen J. Turnbull" <address@hidden>
> Cc: Stefan Monnier <address@hidden>,
> address@hidden,
> address@hidden
> Date: Sun, 15 Feb 2015 18:21:54 +0900
>
> > . Some definition of Lisp_Object
> >
> > This already presents at least 2 problems. The first is 32- vs
> > 64-bit issues. We need some way of checking that a 32-bit module
> > isn't loaded by a 64-bit Emacs, and vice versa.
> >
> > The other problem is more serious: Emacs can be built with or
> > without --check-lisp-object-type, and with or without --wide-int;
> > how will the module know which implementation to use?
>
> XEmacs builds a separate compiler driver ellcc that knows how to build
> modules of the same configuration.
That won't support binary distributions of modules, would it?
> > Perhaps the solution is to make Lisp_Object an opaque data type for
> > the modules, and not use the definition we have on lisp.h.
>
> I don't know how you identify type of objects, but since you only have
> a couple of tag bits left, I have to assume you use a header word of
> some kind. In XEmacs the header word is a pointer to a table of
> functions that define the common functionality of Lisp objects used by
> the interpreter and the virtual machines. Whether a method table
> pointer or an enum, that header word is pretty much the only thing
> that's going to be common to all types. Seems to me that's pretty
> close to opaque already.
Making a Lisp_Object opaque, one way or the other, is easy. Getting
people to accept that it will be opaque is harder. I posted my
suggestion to try to convince that this is the way to go, but I'm not
holding my breath, frankly.
> > . Functions to access values of Lisp objects.
>
> Not values, attributes.
I don't think the difference matters for the purposes of this
discussion. The intent is to allow extracting a C int from Emacs
integer, a C double from a Lisp float, a C char array from a Lisp
string, a pointer to buffer text for buffers, etc.
> You don't want to just unbox the Lisp object and give modules access
> to internals. Rather, each object type should export a specific API
> in the form of accessors and mutators for its Lisp-visible
> attributes.
I don't think modules will settle for using only the Lisp attributes,
they would like access to C attributes as well.
> > The above means that most of the C source files under modules/ should
> > be thoroughly rewritten.
>
> Sounds like a good idea to me. Wouldn't hurt if you rewrote most of
> the C source under src/ that way too. ;-)
I'm not holding my breath.
- Re: Dynamic loading progress, (continued)
- Re: Dynamic loading progress, Eli Zaretskii, 2015/02/15
- Re: Dynamic loading progress, Stephen Leake, 2015/02/15
- implementing curl module with opaque emacs types, Stephen Leake, 2015/02/15
- Re: implementing curl module with opaque emacs types, Eli Zaretskii, 2015/02/15
- Re: implementing curl module with opaque emacs types, Stephen Leake, 2015/02/17
- Re: Dynamic loading progress, Eli Zaretskii, 2015/02/15
- Re: Dynamic loading progress, Stefan Monnier, 2015/02/15
- Re: Dynamic loading progress, Stephen Leake, 2015/02/16
- Re: Dynamic loading progress, Stefan Monnier, 2015/02/16
- Re: Dynamic loading progress, Stephen J. Turnbull, 2015/02/15
- Re: Dynamic loading progress,
Eli Zaretskii <=
- Re: Dynamic loading progress, Aurélien Aptel, 2015/02/11
- Re: Dynamic loading progress, Aurélien Aptel, 2015/02/11
- Re: Dynamic loading progress, Aurélien Aptel, 2015/02/11
- Re: Dynamic loading progress, Stefan Monnier, 2015/02/11
- Re: Dynamic loading progress, Aurélien Aptel, 2015/02/11
- Re: Dynamic loading progress, Stefan Monnier, 2015/02/11
- Re: Dynamic loading progress, Paul Eggert, 2015/02/11
- Re: Dynamic loading progress, Ted Zlatanov, 2015/02/10
- Re: Dynamic loading progress, Aurélien Aptel, 2015/02/11
- Re: Dynamic loading progress, Ted Zlatanov, 2015/02/11