Thanks for replying...
On Tuesday 12 October 2004 10:53 am, Nikodemus Siivola wrote:
> Why can't you load the shared object earlier? (If it's a library you
> use that does this, then it's a bug in the library, IMO.)
Sorry for not being more clear. I *do* load the shared object first,
and then load the "bindings.lisp" file. The problem is that if some
of the c++ symbols referenced in the lisp bindings file are *not* in
the shared object, then I get a simple-error that seems to be hard to
FYI, I am automatically generating the lisp bindings file via the
output of GCCXML, using XMLS and some Common Lisp.
I think I have handled the "obvious" cases of "artificial" functions
(e.g., copy constructors) defined yet not always generated by GCC, and
I prevent them from appearing in the bindings.
However, if system header files are included in any of the source
(say, <stdio.h>, <typeinfo>), they may declare system functions that
will not be in my shared library. I am not sure if it's computable to
identify them and prevent their inclusion in the auto-generated lisp
bindings. I have to think about this.
Anyway, that's why I wanted to ignore any errors like that.
> OTOH, I do have a vague plan how lazyness could be achieved there,
> but the prospect isn't really attractive.
> In short: if the foreign symbol isn't there yet turn the DEFUN
> generated by DEFINE-ALIEN-ROUTINE into something like
> (defun foo (&rest args)
> (let ((*alien-definition-or-lose* t))
> (eval <original define-alien-routine form>)
> (apply 'foo args))
> *eugh* -- I've the feeling there are going to be cases of this behaving
> badly that i can't think of right now...
OK. Thanks. I am sure I will have more stupid questions later.
> -- Nikodemus Schemer: "Buddha is small, clean, and serious."
> Lispnik: "Buddha is big, has hairy armpits, and laughs."
==== John Morrison
==== MAK Technologies Inc.
==== 10 Fawcett Street, Cambridge, MA 02138
==== vox:617-876-8085 x115