On Fri, 2004-02-06 at 06:56, James Henstridge wrote: > On 06/02/04 11:33, Bob Smith wrote: > > > Hmm... This would be a lot of work to program in all this information > > > >manually. > > > >I believe the GTK# project has a program that analyzes C files and > >produces an XML description of the GObjects... If they do, maybe it > >could be modified or an XSLT document be created to convert that > >information to a form that can be automatically linked into a > >library/program. > > > > > The interface descriptions in GTK# (which are actually quite similar to > the s-expression based ones most other language bindings use) are not > quite what I was referring to, since it doesn't really tie into a type > system very well. If you look at the ORBit2 code, you get a > CORBA::TypeCode for each function argument and one for the return value. Yeah. What I was talking about is writing a tool or adapting GTK#'s, to look at the C source for GObjects and generate type code for the object in a form that can be introspected well at runtime. > > Each typecode has a kind (which is picked from a fixed size enum), such > as "int", "enum", "string", "struct", "sequence" or "interface". For > the struct type, you can get a list of the struct member names along > with TypeCodes describing the types of the members. This makes it quite > easy to write a finite amount of code that can convert pretty much any > CORBA type into a Python equivalent, for instance. Yeah. > > The other reason for not picking XML is that it isn't very shareable, so > each application that loads the interface description will have a > separate copy in memory. I was referring to XML only because I think GTK#'s tool generates it currently. Wouln't require any extra code if it was used directly. > In contrast, ORBit IInterfaces are usually > static data loaded from a shared library, so are quite shareable. > Similarly Mozilla's XPCOM type libraries are structured in such a way > that they can be mmaped read only, making it shareable between multiple > processes. Yeah. This is the idea. Have a program analize the C source for a GObject and make a type library out of it so it can be introspected at runtime and bindings automatically generated for CORBA, python, perl, whatever. > > >> * Some way to invoke a method on an instance programatically. > >> > >>The last one is probably most difficult. The two ways to solve it are > >>to generate marshalling code (similar to what we do for signals), or use > >>something like libffi to construct the function calls (probably making > >>use of the interface information to help construct the call). > >> > >> > > > >Yeah. Mono seems to be doing fairly well doing this sort of thing. Maybe > >their team can provide a good solution to the problem. > > > > > Yep. It looks like they are using libffi. If the scripting framework > ended up using libffi, I would hope that it has some layer on top that > is a bit easier to use ... At one point they were, but I don't think they are anymore. I think the JIT does the calls itself. Maybe its separable enough that it could be reused for this though. > > >Know how COM on Python works? Does it create proxy Python objects? We > >could do the same thing... > > > > > Invocations are performed using the IDispatch interface, IIRC. It can > run in two modes -- in one it generates Python source files that call > Dispatch from a COM typelib. In the other it does everything at runtime. > So GObjects would need to support something like IDispatch. That doesn't seem too difficult. If thats done, then all you would have to do to script an application is program using GObjects and register a root object with a scripting language. The scripting language can do all the rest itself. Bob > James. -- Bob Smith <bob thestuff net>
Attachment:
signature.asc
Description: This is a digitally signed message part