orbit-python-list

[Orbit-python-list] Re: Implementing list_initial_handlers for orbit-python

[Christian R. R. <ki...@as...>]

On Mon, 4 Dec 2000, Harald Boehme wrote:

> Christian Robottom Reis wrote:
> > 
> What do you talking about ?
> list_initial_handlers is located where abd for what use ?

It's supposed to list the initial handlers available when initializing a
POA, apparently :-) Apart from the default " RootPOA" we can pick
"NameService" and a few other ("InterfaceRepository" IIRC..). AFAICR ORBit
does imnplement this to an extent, so I'd like to provide a binding for
orbit-python. 

Take care,
--
/\/\ Christian Reis, Senior Engineer, Async Open Source, Brazil
~\/~ http://async.com.br/~kiko/ | [+55 16] 274 4311

Re: [Orbit-python-list] Catching SIGINT inside orb.run()

[Christian R. R. <ki...@as...>]

On Mon, 4 Dec 2000, Christian Robottom Reis wrote:

> I'm wondering if we can use PyOS_getsig() and call the signal manually.
> I'm checking.

PyOS_getsig is Python 2.0 only, so I'm still wondering. I'm checking out
how pygtk does it, but my guess is it doesn't :-)

Take care,
--
/\/\ Christian Reis, Senior Engineer, Async Open Source, Brazil
~\/~ http://async.com.br/~kiko/ | [+55 16] 274 4311

Re: [Orbit-python-list] Catching SIGINT inside orb.run()

[Christian R. R. <ki...@as...>]

On Thu, 30 Nov 2000, Jason Tackaberry wrote:

> I don't _think_ so.  From what I can see in signalmodule.c, when you set
> a custom handler using signal.signal(), it stores the Python function in
> an array (line 256 of signalmodule.c, v1.5.2) after calling signal(2)
> and setting the signal handler to the stub function signal_handler
> (lines 249 and 245).

It does, but AFAICS Handlers is opaque (declared as static) and can't be
accessed by external modules. So we're hitched because we can't set
tripped.

I'm wondering if we can use PyOS_getsig() and call the signal manually.
I'm checking.

> So when you call signal(2) yourself, you're just skipping the signal
> module's stub function (signal_handler) in place of your own, both of
> which will call PyErr_CheckSignals (line 142).  PyErr_CheckSignals loops
> through that array (lines 628-644) and calls the Python functions that
> were set using signal.signal().

Yeah, and poisoning the array seems to be the only thing I would need to
do, if everything wasn't declared static :-)

Still trying.

Take care,
--
/\/\ Christian Reis, Senior Engineer, Async Open Source, Brazil
~\/~ http://async.com.br/~kiko/ | [+55 16] 274 4311

[Orbit-python-list] Re: php module for CORBA

[Jason T. <ta...@li...>]

Hi Jason,

> CORBAmodule.c: In function `CORBA_Object_to_PyObject':
> CORBAmodule.c:44: structure has no member named `object_id'
> CORBAmodule.c:52: structure has no member named `object_id'
> 
> This is after making sure the ORBit snapshot mentioned below is the ONLY
> version of ORBit on the box.  PHP4 w/ Satellite has compiled
> fine.  Thoughts and/or suggestions?

What version of ORBit is this?  ORBit-Python uses the object_id field
from CORBA_Object_struct (in the 0.5.X series, anyway) to get the repo
id.  Does anyone know of a more proper way to fetch the repo id from a
CORBA object?

Jason.

[Orbit-python-list] Python and dlopen for Orbit-Python CVS Was Re: [Orbit-python-list] Problems with orbit-python-cvs

[Christian R. R. <ki...@as...>]

On Mon, 4 Dec 2000, Christian Robottom Reis wrote:

> On Sat, 2 Dec 2000, Christian Robottom Reis wrote:
> 
> > > I too am pretty stumped.  Have you tried this on another system?  Is it
> > > only a problem on one machine?

Okay, tracked down the problem and would like to discuss a fix. It seems
Python-1.5.2 doesn't do a dlopen() with RTLD_GLOBAL, but RedHat issues a
patched version which I assume you're using (or some patched version) to
importdl.c.

This is a problem for anybody using a source-compiled python, and it would
be nice to a) provide the patch with orbit-python or b) workaround this
some way. Solution a) is okay in the short run as long as we document it
somewhere ;-)

I've attached the patch and have no further problem here; let me know what
you think we could do in the long run and I might try doing it.

Take care,
--
/\/\ Christian Reis, Senior Engineer, Async Open Source, Brazil
~\/~ http://async.com.br/~kiko/ | [+55 16] 274 4311

Re: [Orbit-python-list] Problems with orbit-python-cvs

[Christian R. R. <ki...@as...>]

On Sat, 2 Dec 2000, Christian Robottom Reis wrote:

> On Fri, 1 Dec 2000, Jason Tackaberry wrote:
> 
> > I too am pretty stumped.  Have you tried this on another system?  Is it
> > only a problem on one machine?
> 
> I'm compiling on others. I wonder if python lets me debug modules
> further. I'm writing to python-help as well.

Jason, I'm starting to think it could be linker options generated by
autoconf; what are your libtool and gcc lines for compiling the objects
and linking the .so?

Take care,
--
/\/\ Christian Reis, Senior Engineer, Async Open Source, Brazil
~\/~ http://async.com.br/~kiko/ | [+55 16] 274 4311

[Orbit-python-list] Re: orbit-python NameService resolution (was something else)

[Jason T. <ta...@li...>]

> This works NOW, I mean, it already works! Don't ask :-) Orbit alrady
> handled it, and all we needed was the whitespace fix you

Oh yes, that actually makes perfect sense now that I look at the code.
:)  (Like I said earlier, it's not fresh in my mind these days.)

> submitted. (Interesting thing was the IORs had _no_ whitespace, and I
> checked for it specifically.. was it something you did internally or just
> black magic?)

It's something I did internally:

   p = s + strlen(s) - 1;
   while (isspace(*p)) 
      *p-- = 0;

If it was failing before and it works now, and you think the IOR had no
trailing whitespace, have a closer look. :)  I was stumped on that same
thing too because I was using vi to look at the IOR, and it looked like
there was nothing at the end of the line.  Of course, od(1) is what you
need to use, and I'll bet you the last byte of the IOR has a \n.

If not, send me the IOR in question, because I'll definitely want to
figure out what's going on. :)

> Really, all you need to do is specify the IOR through orbitrc, and you'll
> get back a refernce when you resolve "NameService". You have to load_idl
> /usr/.../share/idl/name_service.idl to get the class and structure

Are you using the CVS version?  I wouldn't suggest writting any
significant amount of code with the 0.1.x series since 0.2.0 will not be
source compatable.  With the code in CVS, all you need to do is import
CosNaming after you make sure your IDLPATH has an entry for the
directory in which the name service IDL is located.  (If no IDLPATH is
specified it defaults to the cwd.)  It's really pretty magical, and
probably recommended given that load_idl is an ORBit-Python specific
extension and not part of the mapping specification.

> One that that _doesn't_ work is specifing the IOR through the commandline,
> which would be excellent. Have you ever tried specifying commandline args
> through orbit-python? I'll test this further today.

I haven't, no, but the code is in place to pass command line args over
to ORBit, so it should work.  It isn't thoroughly tested mind you, so
there could be a bug.  Let me know about that and I'll fix it this
weekend if there's a problem.

Jason.

Re: [Orbit-python-list] Problems with orbit-python-cvs

[Christian R. R. <ki...@as...>]

On Fri, 1 Dec 2000, Jason Tackaberry wrote:

> > so this really beats me. Could this be a Python or compiler
> > problem? Perhaps something automake isn't doing..? Jeez.
> 
> I too am pretty stumped.  Have you tried this on another system?  Is it
> only a problem on one machine?

I'm compiling on others. I wonder if python lets me debug modules
further. I'm writing to python-help as well.

Take care,
--
/\/\ Christian Reis, Senior Engineer, Async Open Source, Brazil
~\/~ http://async.com.br/~kiko/ | [+55 16] 274 4311

[Orbit-python-list] orbit-python NameService resolution (was something else)

[Christian R. R. <ki...@as...>]

On Fri, 1 Dec 2000, Jason Tackaberry wrote:

> > You can actually do a
> > namepoa=orb.resolve_initial_references("NameService")
> 
> Did you hack this into ORBit-Python yet?  If so, please submit a patch.
> :)  If not, I'll do it this weekend since it should be a pretty simple
> addition.

This works NOW, I mean, it already works! Don't ask :-) Orbit alrady
handled it, and all we needed was the whitespace fix you
submitted. (Interesting thing was the IORs had _no_ whitespace, and I
checked for it specifically.. was it something you did internally or just
black magic?)

Really, all you need to do is specify the IOR through orbitrc, and you'll
get back a refernce when you resolve "NameService". You have to load_idl
/usr/.../share/idl/name_service.idl to get the class and structure
definitions. I can explain more verbosely; perhaps I'll include it in the
doc file, which I'm reworking now that I know a bit more.

One that that _doesn't_ work is specifing the IOR through the commandline,
which would be excellent. Have you ever tried specifying commandline args
through orbit-python? I'll test this further today.

Take care,
--
/\/\ Christian Reis, Senior Engineer, Async Open Source, Brazil
~\/~ http://async.com.br/~kiko/ | [+55 16] 274 4311

Re: [Orbit-python-list] random.org Random.ior and orbit-python

[Jason T. <ta...@li...>]

> Jason, apparently the nameserver works fine! This is great news!

Great! :)

> You can actually do a
> namepoa=orb.resolve_initial_references("NameService")

Did you hack this into ORBit-Python yet?  If so, please submit a patch.
:)  If not, I'll do it this weekend since it should be a pretty simple
addition.

Cheers,
Jason.

Re: [Orbit-python-list] random.org Random.ior and orbit-python

[Christian R. R. <ki...@as...>]

On Fri, 1 Dec 2000, Jason Tackaberry wrote:

> > > This is probably related to the same problem with the name service IOR.
> > > I think it's an ORBit-Python bug.  I'll investigate it today.
> > 
> > Did you get any further with this?
> 
> Yes sorry, I thought you would have noticed my brief exchange with
> Elliot.  The fix for this has been committed to CVS.

Jason, apparently the nameserver works fine! This is great news!

You can actually do a

namepoa=orb.resolve_initial_references("NameService")

if you specify ORBNamingIOR=IOR:... in your orbitrc! I'm listing out the
GIOP messages as I type here :-) 

Thanks!

Take care,
--
/\/\ Christian Reis, Senior Engineer, Async Open Source, Brazil
~\/~ http://async.com.br/~kiko/ | [+55 16] 274 4311

Re: [Orbit-python-list] Problems with orbit-python-cvs

[Jason T. <ta...@li...>]

> so this really beats me. Could this be a Python or compiler
> problem? Perhaps something automake isn't doing..? Jeez.

I too am pretty stumped.  Have you tried this on another system?  Is it
only a problem on one machine?

Jason.

Re: [Orbit-python-list] Catching SIGINT inside orb.run()

[Christian R. R. <ki...@as...>]

On Thu, 30 Nov 2000, Jason Tackaberry wrote:

> So basically your stub function will have to reimplement what
> signalmodule's signal_handler does, the most important of which (from
> what I can tell) is lines 140 and 141.

Almost fixed.. still looking into a minor issue but it sorta works. I'll
submit as soon!

Take care,
--
/\/\ Christian Reis, Senior Engineer, Async Open Source, Brazil
~\/~ http://async.com.br/~kiko/ | [+55 16] 274 4311

Re: [Orbit-python-list] Problems with orbit-python-cvs

[Christian R. R. <ki...@as...>]

On Thu, 30 Nov 2000, Jason Tackaberry wrote:

> > Are you sure you're working on a clean checkout? Is there a way I can
> > diagnose this in another fashion?
> 
> I just tried it now with a clean cvs checkout and it works properly.  So
> I'm a bit bewildered by your problem.  What's the output from:
> 
>    nm CORBAmodule.so | grep POAManager_PyObject_Type

Still haven't got this to work. I'm importing CORBAmodule.so and nm does
show I've got the symbol defined:

00011d80 D POA_PyObject_Type

so this really beats me. Could this be a Python or compiler
problem? Perhaps something automake isn't doing..? Jeez.

Take care,
--
/\/\ Christian Reis, Senior Engineer, Async Open Source, Brazil
~\/~ http://async.com.br/~kiko/ | [+55 16] 274 4311

Re: [Orbit-python-list] Re: random.org Random.ior and orbit-python

[Jason T. <ta...@li...>]

> Maybe the 'ior' that you are passing has trailing newlines or something -
> the string_to_object routine in ORBit releases doesn't strip off
> whitespace...

Yep, that's exactly the problem, and I was just committing the fix to
cvs as you replied. :)

Thanks,
Jason.

Re: [Orbit-python-list] Catching SIGINT inside orb.run()

[Jason T. <ta...@li...>]

> a) I override signal A using signal.signal()
> b) orb.run() gets called
> c) Just before actually doing the run() I set a new handler for A that
> would check PyErr_CheckSignals()
> 
> I just lost the original handler, no?

I don't _think_ so.  From what I can see in signalmodule.c, when you set
a custom handler using signal.signal(), it stores the Python function in
an array (line 256 of signalmodule.c, v1.5.2) after calling signal(2)
and setting the signal handler to the stub function signal_handler
(lines 249 and 245).

So when you call signal(2) yourself, you're just skipping the signal
module's stub function (signal_handler) in place of your own, both of
which will call PyErr_CheckSignals (line 142).  PyErr_CheckSignals loops
through that array (lines 628-644) and calls the Python functions that
were set using signal.signal().

So basically your stub function will have to reimplement what
signalmodule's signal_handler does, the most important of which (from
what I can tell) is lines 140 and 141.

Jason.

[Orbit-python-list] Re: random.org Random.ior and orbit-python

[Elliot L. <so...@re...>]

On Thu, 30 Nov 2000, Christian Robottom Reis wrote:

>
> Does anyone have an idea why we get a
>
> Message: CORBA exception raised: IDL:CORBA/MARSHAL:1.0
> Traceback (innermost last):
>   File "./random", line 14, in ?
>     o = myorb.string_to_object(ior)
> CORBA.SystemException: IDL:CORBA/MARSHAL:1.0: IDL:CORBA/MARSHAL:1.0
>
> when trying to string_to_object random.org's IOR:
>
> IOR:000000000000000f49444c3a52616e646f6d3a312e3000000000000100000000000000500001000000000016706c616e7874792e6473672e63732e7463642e69650006220000002c3a5c706c616e7874792e6473672e63732e7463642e69653a52616e646f6d3a303a3a49523a52616e646f6d00
>
> The c client that random.org provides works perfectly, so I wouldn't think
> it's an Orbit issue, but it appears Orbit _is_ raising an exception, so
> I'm left wondering.

Maybe the 'ior' that you are passing has trailing newlines or something -
the string_to_object routine in ORBit releases doesn't strip off
whitespace...

-- Elliot
"The Pythagorean Theorem employed 24 words, the Lord's Prayer has 66 words,
Archimedes Principle has 67 words, the 10 Commandments have 179 words, the
Gettysburg Address had 286 words, the Declaration of Independence, 1,300 words and
finally the European Commission's regulation on the sale of cabbage: 26,911 words."

Re: [Orbit-python-list] Catching SIGINT inside orb.run()

[Christian R. R. <ki...@as...>]

On Thu, 30 Nov 2000, Jason Tackaberry wrote:

> It looks like the approach would be to release the interpreter lock and
> call PyErr_CheckSignals(), and then reestablish the lock.  (Look at
> operation_skel() in server.c on how to restore/save the lock).

Okay, this has been done, easily. However, now that I think of it, it
might not be a solution at all:

a) I override signal A using signal.signal()
b) orb.run() gets called
c) Just before actually doing the run() I set a new handler for A that
would check PyErr_CheckSignals()

I just lost the original handler, no?

So what I have to do is either set a default handler for all signals that
in turns calls a specific handler for each signal (which I doubt exists in
Unix), or save all handlers that came in in a structure and call them
accordingly depending on what signal I actually got.

Am I lost?

Take care,
--
/\/\ Christian Reis, Senior Engineer, Async Open Source, Brazil
~\/~ http://async.com.br/~kiko/ | [+55 16] 274 4311

Re: [Orbit-python-list] Problems with orbit-python-cvs

[Jason T. <ta...@li...>]

> This is python-1.5.2 here.. I'm actually somewhat familiar with object
> files, but I have no idea how Python allows access to other module's
> structures, so it could be something wierd here..

Do you have access to another machine you could try this on?

Jason.

Re: [Orbit-python-list] Problems with orbit-python-cvs

[Christian R. R. <ki...@as...>]

On Thu, 30 Nov 2000, Jason Tackaberry wrote:

> > Are you sure you're working on a clean checkout? Is there a way I can
> > diagnose this in another fashion?
> 
> I just tried it now with a clean cvs checkout and it works properly.  So
> I'm a bit bewildered by your problem.  What's the output from:
> 
>    nm CORBAmodule.so | grep POAManager_PyObject_Type

It's here :-)

00011d60 D POAManager_PyObject_Type

as is

00011e00 D POA_PyObject_Type

So while the symbol is being defined in CORBAmodule, it's not being seen
by python when it goes on to import PortableManager.

This is python-1.5.2 here.. I'm actually somewhat familiar with object
files, but I have no idea how Python allows access to other module's
structures, so it could be something wierd here..

Take care,
--
/\/\ Christian Reis, Senior Engineer, Async Open Source, Brazil
~\/~ http://async.com.br/~kiko/ | [+55 16] 274 4311

Re: [Orbit-python-list] Problems with orbit-python-cvs

[Jason T. <ta...@li...>]

> Are you sure you're working on a clean checkout? Is there a way I can
> diagnose this in another fashion?

I just tried it now with a clean cvs checkout and it works properly.  So
I'm a bit bewildered by your problem.  What's the output from:

   nm CORBAmodule.so | grep POAManager_PyObject_Type

Jason.

Re: [Orbit-python-list] Problems with orbit-python-cvs

[Christian R. R. <ki...@as...>]

On Thu, 30 Nov 2000, Jason Tackaberry wrote:

> POAManager_PyObject_Type lives in CORBAmodule, so you need to import
> that before you import PortableServer.

Even after erasing every trace of CORBAmodule.so from my whole box, and
compiling orbit-python, and running python inside src/ I get

blackjesus:~/devel/pyorb/orbit-python/src> python
Python 1.5.2 (#7, Nov 28 2000, 20:41:52)  [GCC egcs-2.91.66 19990314/Linux
(egcs- on linux2
Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam
>>> import CORBA
>>> import PortableServer  
Traceback (innermost last):
  File "<stdin>", line 1, in ?
ImportError: ./PortableServermodule.so: undefined
symbol: POAManager_PyObject_Type
>>> 

Are you sure you're working on a clean checkout? Is there a way I can
diagnose this in another fashion?

Take care,
--
/\/\ Christian Reis, Senior Engineer, Async Open Source, Brazil
~\/~ http://async.com.br/~kiko/ | [+55 16] 274 4311

Re: [Orbit-python-list] Problems with orbit-python-cvs

[Jason T. <ta...@li...>]

> suggests I do need these structures live for this to happen. Unless, of
> course, when I do an import CORBA they are created automatically; still,
> where can the error come from?

POAManager_PyObject_Type lives in CORBAmodule, so you need to import
that before you import PortableServer.

So:

[tack@anywhere src]$ python
>>> import CORBA
>>> import PortableServer

Works, but:

[tack@anywhere src]$ python
>>> import PortableServer
Traceback (innermost last):
  File "<stdin>", line 1, in ?
ImportError: ./PortableServermodule.so: undefined symbol: POAManager_PyObject_Type

Jason.

Re: [Orbit-python-list] Problems with orbit-python-cvs

[Christian R. R. <ki...@as...>]

On Thu, 30 Nov 2000, Jason Tackaberry wrote:

> > Does anybody get anything remotely like 
> [...]
> > PortableServermodule.so: undefined symbol: POAManager_PyObject_Type
> 
> Nope. Make sure you're not accidentally importing old modules.  Does the
> cvs version compile okay for you?

Yes, after doing the automake changes you suggest and running autogen.sh I
get a perfect build. However, the fragment in PortableServermodule.c

    POAManager_PyObject_Type.ob_type = &PyType_Type;
    POA_PyObject_Type.ob_type = &PyType_Type;

suggests I do need these structures live for this to happen. Unless, of
course, when I do an import CORBA they are created automatically; still,
where can the error come from?

Take care,
--
/\/\ Christian Reis, Senior Engineer, Async Open Source, Brazil
~\/~ http://async.com.br/~kiko/ | [+55 16] 274 4311

Re: [Orbit-python-list] Problems with orbit-python-cvs

[Jason T. <ta...@li...>]

> Does anybody get anything remotely like 
[...]
> PortableServermodule.so: undefined symbol: POAManager_PyObject_Type

Nope. Make sure you're not accidentally importing old modules.  Does the
cvs version compile okay for you?

Jason.