[EMAIL PROTECTED] writes:
> I agree in principle, but in practice thw swig stub generator is
> much more advanced/powerful/flexible than most corba stub generators
> (which have to be written in the corba IDL, with manually-created
> glue code.) I am also concerned that perl-corba interfaces are
> immature, and guile-corba interfaces possibly non-existant. And as
> some mentioned, even C-corba interface
Yep. At least orbit, which seems to be the most promising orb these
days (given my admittedly limited knowledge), only supports C.
(Actually, my impression is that if ILU had cleared up it's license
sooner[1], GNOME would be using that instead of direct CORBA. ILU
has perl/python/guile/tcl/whatever bindings, and looks to be quite a
bit more sophisticated than SWIG.)
[1] apparently, they're going to make it free, but haven't gotten the
bureaucratic stuff finished yet. At least that's what I heard
last time they discussed it with Debian.
Actually, I'm making progress with SWIG, but without some
non-documented stuff, there are limitations to what even swig can
handle. The problem is that unless I'm going to use statics or
globals (which I'd prefer not to, but which aren't a serious problem
until/unless we want to be thread safe) I can't get swig to easily
handle output args like "double *"'s
Basically what you really want is for something like this:
char *foo(TransientString s, OutputDouble d);
(Where TransientString is really a char* and OutputDouble is really a
double*. The type names just let SWIG know what the expected
behavior is. The type names won't show up in the C prototypes.)
to get translated into a guile function that behaves like this:
(foo "some input string) => (returned-char-ptr output-double)
i.e. you need to return a list containing the return value and any
output args.
This, as I said, is going to either require some ugly wrapper function
statics or globals, or a modification to (or use of an undocumented
feature in) swig to support returning lists when needed. I've asked
on the swig list to see which.
Note that we could make some of this a lot easier if we were just
willing to place some more script friendly restrictions on our C API,
but I think I'd just rather solve the problem correctly. Then
everyone benefits.
--
Rob Browning <[EMAIL PROTECTED]> PGP=E80E0D04F521A094 532B97F5D64E3930
----- %< -------------------------------------------- >% ------
The GnuCash / X-Accountant Mailing List
To unsubscribe, send mail to [EMAIL PROTECTED] and
put "unsubscribe gnucash-devel [EMAIL PROTECTED]" in the body
