[pyorbit] pyIDL

[James Henstridge]

I made one change to the libIDL wrapper so that it would compile with
recent libIDL's.  There was a structure member that has been deprecated
(they renamed it to discourage people from using it.  The change may break
some of pyIDL (I could not really check this because the files were a bit
incoherent).

On Mon, 13 Sep 1999, Justin Bradford wrote:

> > Anyway, enough jabbering; I'm here to help hack code if you need it. I'd
> > be more than happy to help write the idl compiler - I've got very quick
> > at it in the last couple of months!
> 
> The current IDL compiler is limited. Michael had started on struct
> support, but the source code died in a vi crash. Core dumps from that are
> under the misc/ directory.
> 
> If you're up to writing a new compiler, then great. I had been planning to
> explore pyIDL when I got to the compiler, anyway. I see Jeff has given you
> CVS access, so feel free to make a new directory and start committing 
> code.
> 
> > Do you have any plans for a dynamic client side? Something which looks
> > up type information in the IR so that you don't have to compile IDL for
> > client side stubs would be really cool!
> 
> That's our most requested feature, so we'll get it in eventually.
> 
> I'm busy this week with school work, but this weekend I'm planning on a
> mild tree cleanup. I haven't looked at what James has committed yet for
> building, but I'm going to move it over to autoconf/automake.

I have submited the autoconf/automake macros I use in gnome-python to Tom
Tromey, so they (or a modified version of them) should apear in
automake-1.5.  If you want to use them before then, they are available
from the GNOME CVS tree in the gnome-python module.

The build changes I did commit were the minimal ones to get it to use
orbit-config and libIDL-config to get the compile/link flags.  The other
changes were a couple of NULL checks and the code to raise python
exceptions when CORBA exceptions occur.  This last change only required
changing the checkCORBA macro.

> 
> After that, I'll work on a plan for IR support and dynamic clients. Input
> is welcome.

If you are going to play around with the interface repository code,
remember that you will have to pass the --ORBIfaceRepoIOR argument to the
program.  Something like this should be sufficient for testing:

  $ orbit-ird | tail /tmp/ird.ior &
  $ python
   ...
  >>> import CORBA
  >>> ird_ior = open('/tmp/ird.ior').read()
  >>> if ird_ior[-1] == '\n': ird_ior = ird_ior[:-1]
  >>> orb = CORBA.ORB_init(['foo', '--ORBIfaceRepoIOR', ird_ior],
  ...                      'orbit-local-orb')
  >>> ir = orb.resolve_initial_references('InterfaceRepository')

Without this, any interface repository related calls could potentially
cause seg faults (because ORBit's internal pointer to the interface
repository would be NULL).

You can do a similar thing to test the sample orbit-name-server with the
--ORBNamingIOR argument.

> 
> Also, if anyone finds limitations, bugs, or incompatibilities with the OMG
> spec, send them to the list. By now, there are probably people on the list
> who know the current code better than I do.
> 
> Justin
> 
> 
> 

One other thing to look at is whether overloading CORBA.__dict__ as a
place to register object stubs is the best way of setting things up.  It
works fine at the moment, but there may be better ways to register stubs.

James.

--
Email: james at daa.com.au
WWW:   http://www.daa.com.au/~james/