Re: Python mico

[Philip Dawes <philipd parallax co uk>]

Aadi wrote:
> 
> Thanks Phil,  I did get the message from the component list?  Guess it's
> not the most active list on GNOME. Shame, too, cuz it's probably the most
> important.
> 
> Anyway, as far as Python and FNORB are concerned, I'm working my way
> through all that, albeit a bit slowly due to work.  My long term goal was
> to see if I could get FNORB to use MICO as an Interface Repository as
> opposed to OmniBroker like it is now.
> 

Yeah, I tried that a while back, but ran into problems. (I think they
were due to an unstable IR at the time). Anyway, if you persue this
you'll need to get the mico IR to support an option to print out its IOR
to STDOUT just like the OmniBroker one does. (should be a simple cout <<
object_to_string(IR); )

In case you've not looked at the code, fnidl basically forks 2
processes, one which runs the omnibroker IR and pipes the IOR to the
other, which runs the omniorb idl compiler to feed the interfaces into
it. The rest of the code uses the IR to generate the python
proxy/skeletons.

> I was curious to see if anybody was working along similar lines or if
> there was a different tack that they were approaching with.  Another way I
> thought was possible was to make a IDL compiler directly for MICO, given
> the draft proposal at http://www.python.org.  But I couldn't find
> information on whether this was possible or not.  Any pointers would be
> appreciated.
> 

I intend to do that this weekend - I've had a look at the code and it
looks very clean and easy (as far as idl compilers go). I intend to copy
and butcher the class which generates idl, to generate the python stub
code. Initially I'll distribute this as a seperate compiler, but
eventually I intend to submit this as a patch to the mico idl compiler
(i.e. give it the argument --generate-python) which I hope will be
folded into the main mico release.


> As I see it, it's necessary to get some of the language support in there
> as quickly as possible.  Some of the languages would have to be Python,
> Scheme, C++, and C.
> 

We *still* need somebody to write the scheme bindings. Any takers? 

As far as I know, Elliot is looking into doing C bindings to omniorb
(since this is much faster than mico and the two interoperate well), and
Owen Taylor is playing with perl bindings for mico.


> It's a shame that we couldn't go with ILU because a lot of the language
> support was in there already.  It was just a matter of writing the
> interfaces for GTK+, GDK, imLib, etc. Oh well... guess it's more fun this
> way.

That would have been easier (sigh...). Mind you, at least we're now
following corba standards - that means we can easily move to other orbs
when they become more mature.

Cheers,

Phil.

-- 
_______________________________________________________________________
 Phil Dawes                               |   My opinions are my own
 WWW:    err.. temporarily non-existant   |   and nothing to do with
 Email:  philipd@parallax.co.uk           |      my employer.