[Moved to a new thread]
[Evgeny's original post is in the thread "Do we need to re-evaluate?"]
* Zajcev Evgeny <zevlg@xxxxxxxxx> writes:
> Steve Youngs <steve@xxxxxxxxxxx> writes:
>> No, this doesn't mean that FFI is out. It means that we either have
>> both (at least initially) or just FFI if it can load the XEmacs
>> DSO's.
> DSOs can be easily loaded. Main difference from FFI module is that
> DSO will not have any FFI arguments translations, because they are
> already translated by means of DEFUN. Another difference is that DSO
> will need to do job to exporting/kill its symbols, functions, etc
> to/from elisp for itself (currently `load-module' does that job). But
> it is easily achieved using _init()/_fini() functions controled by
> dlopen()/dlclose(). However i'm not awared about situation for M$,
> but who cares about M$? :)
Not me. And not anyone else involved with this project (otherwise
they're gonna be mighty disappointed).
> Also, to be fully compatible it is possible to create special
> `ffi-load-module-dso' function, which will do most of the job what
> `load-module' do.
OK, cool.
Now then...
1) Without going into technical details, describe what an FFI is.
2) Tell me what it gives me that DSO's can't (or can't be made to
do).
3) How long would it take to get these FFI thingies into shape?
(imagine you could hack non-stop uninterrupted, how long?)
4) Can it wait until the windoze code is gone?
5) Are they sexy?
--
|---<Steve Youngs>---------------<GnuPG KeyID: A94B3003>---|
| In space, |
| No one can hear you rip a stinky |
|------------------------------------<steve@xxxxxxxxxxx>---|
pgppovZyqCl76.pgp
Description: PGP signature
|