Not gone yet but very soon...
On 23 Oct 2000, Lars Gullik Bj�nnes wrote:
> Allan Rae <[EMAIL PROTECTED]> writes:
>
> | On 22 Oct 2000, Lars Gullik Bj�nnes wrote:
> |
> | > "Asger K. Alstrup Nielsen" <[EMAIL PROTECTED]> writes:
> | >
> | > Do you know if anyone has mentioned xtl on the boost list? Perhaps
> | > that should be done?
> | >
> | > Of course to include the xtl in boost the lisence has to change.
> |
> | Asger sent an email to the XTL list advocating XTL's submission to Boost.
> | It was the first email on the list for about 2 months or more. And I
> | still haven't seen a reply.
>
> Ok, same time he pushed (slighly) for sigc in boost?
yes.
>
> | requirements of XTL (rtti is still necessary though I think). The CUJ
> | article has what could be described as an "XTL for C++ to C++" in that the
> | data isn't actually externalised but wrapped up with type info and stored
> | in a fancy variant_t class -- basically a glorified void*.
>
> I haven t been able to get hold of CUJ for october...
The copy I saw was at the Uni library. So I'll probably get one at a
newsagents in about a month or two (currently newsagents have July!!!!).
I'll try to get hold of it again and have full read...
> | XTL could be the backbone for providing CORBA access to our internals (the
> | data exchange being handled by XTL). Any half decent scripting language
> | should also have XDR or GIOP libraries written for it (like Perl and
> | Python do)
>
> For python we should rather look at the py_cpp code in boost.
maybe.
> | so XTL can provide the scripting languages with access to
> | internal data in a format that looks native to them -- avoiding all that
> | silly custom string handling.
>
> You seem to forget that we want access to internal/user visible data
> structures to be handled through lyxfunc. (and passing structs to
> lyxfunc (in whatever form) is not nice).
XTL via lyxfunc works (or worked) very nicely. Then the external scripts
can call lyxfunc with data directly.
Allan. (ARRae)
