orbit-python-list

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

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

> The process keeps on running. So some handlers are actually called - just
> user-defined ones aren't. I don't know if this is because we're using
> CORBA's default handlers.

I assume this is because of the global interpreter lock.  When the
process receives a signal that was set by the signal module, it enters
the Python stub function to call the custom handler back in Python
space, but it blocks until the interpreter lock is released which won't
happen until some CORBA event occurs.

'course I could be wrong, but it makes sense. :)

> What call do I have to produce to get the interpreter to handle signal
> requests? I've managed to implement a dummy handler here that does what I
> want, but how to I let python handle the events?

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).

Jason.

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

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

On Wed, 29 Nov 2000, Jason Tackaberry wrote:

> When the ORB's run method is called, it in turn calls CORBA_ORB_run
> which starts the main loop.  So, control is not returned to the Python
> interpreter until a CORBA event happens.  This means by using the signal
> module, if the program receives a signal for which a custom handler is
> installed, the handler will not be called until some event happens (a
> client invokes a method from the server, or the ORB exits, for example).

Yes, it does seem to be the case. Interesting that if you set a handler
for a signal which CORBA (or python, I can't say) has a default handler,
it never get called, whereas if you signal a default handler it does
work. E.g, for the fragment:

orb=CORBA.ORB_init(sys.argv,CORBA.ORB_ID)
orb.run()

I get:

blackjesus:~/devel/pyorb> kill -ALRM %2
[2]    Alarm clock                   ./run

But for the fragment:

def handle_alarm():
    print "Foo!"
    exit

signal.signal(signal.SIGALRM, handle_alarm)
orb=CORBA.ORB_init(sys.argv,CORBA.ORB_ID)
orb.run()

I get nothing at all:

blackjesus:~/devel/pyorb> kill -ALRM %2
blackjesus:~/devel/pyorb> 

The process keeps on running. So some handlers are actually called - just
user-defined ones aren't. I don't know if this is because we're using
CORBA's default handlers.

> One possible fix would be to install a custom handler for all signals
> just before entering CORBA_ORB_run that somehow allows the interpreter
> to take control in order to call the handler set using the signal

What call do I have to produce to get the interpreter to handle signal
requests? I've managed to implement a dummy handler here that does what I
want, but how to I let python handle the events?

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

Re: [Orbit-python-list] RootPOA

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

On Wed, 29 Nov 2000, Jason Tackaberry wrote:

> I was reasonably sure you couldn't pass NameService to
> resolve_initial_references with ORBit, and a quick perusal of ORBit's
> source shows this to be the case.  The name service object only seems to
> be set on calling set_initial_references, which doesn't help much when
> you don't have a reference to the object to begin with.

Apparently you can set an IOR for the NameService in your orbitrc, but I
have yet to see this work. This code fragment in 0.5.3 indicates it does
something when you send NameService on to it:

 else if(!strcmp(identifier, "NameService"))
        return CORBA_Object_duplicate(orb->naming, ev);

orb->naming being set through naming_ior or naming_addr. I don't know if
this code is actually being used but it is there.

> Fetching a reference to GNOME's name service, at least, is done with
> Gnorba's gnome_name_service_get().  I don't think there is some elegant

I thought the name service IOR for gnome came through X hints.. I can't
use hints as I have a real distributed operation here. However, setting
the IOR through orbitrc or through the commandline would be an initial
solution, though I would have to fill this out manually until the time
came where I'd have persistent object being started up by orbit (if this
ever gets done :-)

I suppose nobody has effectively used orbitrc or argv parameters to poison
NameService so far, however.

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

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

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

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.

Any ideas?

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

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

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

Does anybody get anything remotely like 

>>> import CORBA
>>> import PortableServer
Traceback (innermost last):
  File "<stdin>", line 1, in ?
ImportError: /usr/local/lib/python1.5/site-packages/PortableServermodule.so: undefined
symbol: POAManager_PyObject_Type
>>> 

when using orbit-python-cvs? I'm thinking there's some version mismatch
here, but I'm still looking.

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()

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

> If you have an idea of where I can start looking I promise I'll try
> digging in myself, so let me know.

I believe I've found the source of the problem, but I'm not confident I
know how to fix it.  From the documentation for the signal module:

- Although Python signal handlers are called asynchronously as far as
  the Python user is concerned, they can only occur between the
  ``atomic'' instructions of the Python interpreter. This means that
  signals arriving during long calculations implemented purely in C
  (e.g.  regular expression matches on large bodies of text) may be
  delayed for an arbitrary amount of time.

When the ORB's run method is called, it in turn calls CORBA_ORB_run
which starts the main loop.  So, control is not returned to the Python
interpreter until a CORBA event happens.  This means by using the signal
module, if the program receives a signal for which a custom handler is
installed, the handler will not be called until some event happens (a
client invokes a method from the server, or the ORB exits, for example).

One possible fix would be to install a custom handler for all signals
just before entering CORBA_ORB_run that somehow allows the interpreter
to take control in order to call the handler set using the signal
module.  I have a hunch this may not be the best solution. :)  Surely
someone else has had to deal with this problem.  I'd love some help in
resolving this.  It's probably nothing a note to c.l.p couldn't solve,
but if anyone on this list has some insight, please speak up. :)

Jason.

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

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

> If you have an idea of where I can start looking I promise I'll try
> digging in myself, so let me know.

Not at this point.  As soon as I find something I'll let you know.

> Unrelated: would orbit-python work with orbit-mt? I'm asking because it
> seems rather simple to multithread a python app with orbit, but if orbit's
> not thread-safe all sorts of ugly things could happen, couldn't it?

I committed some changes to CVS back in August to make ORBit-Python
thread-safe by using the global interpreter lock, but I have some
reservations about the correctness of this code.  My initial thoughts
were that Python's interpreter will prevent two threads from
simultaneously calling ORBit functions, but I may want to reinvestigate
this, especially since Roland's bug report in September (see the list
archives).

I don't know much about orbit-mt, but my impressions from what I've read
on the project's webpage is that it would be workable with ORBit-Python
with some trivial changes.

Jason.

Re: [Orbit-python-list] Tentative API Documentation

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

> It's not very lovely but I did it out of necessity, and I'm submitting it
> for criticism and flames (who knows, Jason might by chance include it
> without looking :-) ).

One thing is for sure, anything is better than what's there now (which
is nothing). :)  I'll read this over for accuracy in a bit, but I think
it's a pretty safe bet that I'll include this in the distribution. :)

You might want to check out the latest CVS tree.  Quite a bit has
changed internally and things conform much more closely to the Python
mapping specification than the latest release (0.1.3).  I have a week
off this month, and I'd like to release a 0.2.0 but the CVS version
needs some cleaning and bug fixing.

Naturally help is always appreciated, especially with documentation. :)
Thanks!

Jason.

Re: [Orbit-python-list] RootPOA

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

> This is more of a Orbit question but I'll crosspost so Jason gets some
> email :-)

Aww, gee, thanks for thinking of me. :)

First, a disclaimer: I haven't looked at this code in a while and I'm
awfully rusty.  I'm especially sticking my neck out when I talk about
ORBit internals, so pay more attention to say Elliot or Owen before me.
:)

> AFAICS, Orbit-0.5.3 only implements RootPOA as a possible request to
> resolve_initial_references. Is this true? Can I not access
> the NameService object?

I was reasonably sure you couldn't pass NameService to
resolve_initial_references with ORBit, and a quick perusal of ORBit's
source shows this to be the case.  The name service object only seems to
be set on calling set_initial_references, which doesn't help much when
you don't have a reference to the object to begin with.

Fetching a reference to GNOME's name service, at least, is done with
Gnorba's gnome_name_service_get().  I don't think there is some elegant
way with strictly ORBit (please correct me if I'm wrong).  For now it's
a matter of finding the IOR from the naming service and calling
string_to_object on it.

> I've been quite confused about how exactly this would work. I understand I
> can set an IOR for the name server in orbitrc, but how far down Orbit and
> orbit-python this goes is unknown to me. Can I actually use this inside
> orbit-python today?

In theory if you import the CosNaming module (in non-cvs versions you do
this with load_idl, with the CVS version just import CosNaming and it
does everything magically) and pass the IOR to string_to_object, you
should have a NamingContext object to play with.  In practice, there
seems to be some sort of bug with ORBit-Python that I still need to
track down and this will fail.

Jason.

[Orbit-python-list] Tentative API Documentation

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

I've put together a very simple (somewhat miserable :-) document which
informally describes the orbit-python API that I've worked with so far.
It's not very lovely but I did it out of necessity, and I'm submitting it
for criticism and flames (who knows, Jason might by chance include it
without looking :-) ).

I'll be working on it locally so if anyone is cranky about it or knows a
whole lot more than what's written there..

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 Wed, 29 Nov 2000, Jason Tackaberry wrote:

> Whatever the cause of this, it's not entirely obvious to me either.  I
> have some free time tonight so I'll see if I can figure out what's going
> on. :)

If you have an idea of where I can start looking I promise I'll try
digging in myself, so let me know.

Unrelated: would orbit-python work with orbit-mt? I'm asking because it
seems rather simple to multithread a python app with orbit, but if orbit's
not thread-safe all sorts of ugly things could happen, couldn't it?

I have this event problem to look over.. still haven't got around to
finding out if a push-push server is workable.

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()

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

> orb.run(). The default effect is getting all the handlers remapped to
> somebody's default handlers.. I have yet to find out who's exactly
> (SIGALRM, for example, prints "Alarm!" and quits). I'm sure they can be
> remapped, somehow, but how?

Whatever the cause of this, it's not entirely obvious to me either.  I
have some free time tonight so I'll see if I can figure out what's going
on. :)

Jason.

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

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

I've taken a couple of shots at implementing list_initial_handlers for
orbit-python in CORBA_ORB.c but since I've failed miserably I've come here
to ask for a bit of help:

As far as I can see all I need to do is request the list and parse the
sequence back into a python object, returning it. Requesting the list
isn't a problem at all, but I'm running into trouble figuring out exactly
what to do with it: should I use demarshal_sequence on the ObjectIdList or
is this more envolved than I think? What exactly is this list - just a
CORBA sequence of ObjectIds, or something complex?

Tracking down what types go where in Orbit is rather complicated, but I'm
still digging through it. One problem I've found is that if I am
effectively to use demarshal_sequence, I'll have to put together a
TypeCode structure, and this isn't exactly trivial to me. If anyone could
lend me a hand, it would be great.

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

[Orbit-python-list] RootPOA

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

This is more of a Orbit question but I'll crosspost so Jason gets some
email :-)

AFAICS, Orbit-0.5.3 only implements RootPOA as a possible request to
resolve_initial_references. Is this true? Can I not access
the NameService object?

I've been quite confused about how exactly this would work. I understand I
can set an IOR for the name server in orbitrc, but how far down Orbit and
orbit-python this goes is unknown to me. Can I actually use this inside
orbit-python today?

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

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

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

Hey there,

I'm wondering if it's at all possible to catch signals (SIGINT would be
nice, but any signal is something already) when I've issued an
orb.run(). The default effect is getting all the handlers remapped to
somebody's default handlers.. I have yet to find out who's exactly
(SIGALRM, for example, prints "Alarm!" and quits). I'm sure they can be
remapped, somehow, but how?

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

Re: [Orbit-python-list] CosNaming marshalling problem.

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

> Well, now I'm stuck ... can you help me ? 

This does seem to be a bug.  I'll look into this tonight if I have time
-- today is my birthday. :)

Cheers,
Jason.

[Orbit-python-list] CosNaming marshalling problem.

[Marcelo CB <co...@as...>]

This code refuses to work : 

------------------------------------------------
#!/usr/bin/env python
import sys, CORBA

    CORBA.load_idl("CosNaming.idl")
    orb = CORBA.ORB_init(sys.argv, CORBA.ORB_ID)

    ior = open("name-server.ior").readline()
    CosNaming = orb.string_to_object(ior)
--------------------------------------------------------

Resulting in :

--------------------------------------------------------
Message: CORBA exception raised: IDL:CORBA/MARSHAL:1.0
Traceback (innermost last):
  File "./ns.py", line 8, in ?
    CosNaming = orb.string_to_object(ior)
CORBA.SystemException: IDL:CORBA/MARSHAL:1.0: IDL:CORBA/MARSHAL:1.0
--------------------------------------------------------

CosNaming.idl came from ORBit 0.53.

orbit-name-server is running and an ior-decode in name-server.ior shows me
it is what I think it is.

I can browse the name-server with ORBit's name-client.

I tried orbit-python 0.1.3 and latest CVS checkout, but got the same
results.

I already have a lot of other stuff running ok with orbit-python.

Well, now I'm stuck ... can you help me ? 

thanks,

marcelo.

--
Marcelo Corbani de Barros                   co...@as...
Async Open Source Development - Brasil
www.async.com.br

Re: [Orbit-python-list] hi

[Khaled D. <kh...@w-...>]

On Sat, 11 Nov 2000, Jason Tackaberry wrote:

> According to the mapping specification, Nil objects are represented by
> None.  I don't think ORBit-Python handles this properly, now that you
> mention it.  And so it is on the todo list of things to check.

Ok good to know.

> If the object is a CORBA.Object it means that the interface definition
> for the object represented in the IOR was not found.  It looks like you
> are importing the idl before doing anything, so this could very well be
> a bug.  Try printing the __repo_id attribute of that object and see what
> you get.  If it's correct, then the problem would seem to be the dynamic
> IDL loading.  Can you send me the IOR and IDL files you're working with?

printing __repo_id gives a sound answer -> IDL:Time:1.0
which got me to the conclusion that it was my fault all along, 
since I had inserted a module around the interface that was first
defined and compiled with mico, doh!

Time is an interface and I had a module around it, ofcourse it could
not find it.

Anyway I got some interesting information out from this :)

> Also, give the CVS version a try, as this may inadvertently have been
> fixed.  (There's been quite a bit of internal changes since the last
> release.)  You'll have to patch automake as documented in the
> python-am-changes directory.

Just took it down, Ill have a go at it.

/Khaled Daham, w.arts
Mail:    kh...@w-...
Cell:    +46-70-6785492, +966-54491462
FreeBSD: The Power to Serve! http://www.FreeBSD.org/

Re: [Orbit-python-list] hi

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

> First I would like to point out that it seems like it is dead quiet on
> this list ( im not subscribed ) atleast if you like at the archive.

Yup, life here has been fairly quiet.  I really wanted to make another
release early September, but my RL job has been occupying quite a bit of
my time and I need to do a few hours more hacking before it is ready.

> the output looks like this.
> <CORBA.Object object at 80ff980> 
> 
> Could one take that it is a nil reference with orbit-python ( Id like a
>  is_nil implemented ) or should it be None ? 

According to the mapping specification, Nil objects are represented by
None.  I don't think ORBit-Python handles this properly, now that you
mention it.  And so it is on the todo list of things to check.

> So ofcourse the client i wrote with orbit-python does not
> work, the c++ client works, but anyway I would like to know what
> makes 't' to be a CORBA.Object.

If the object is a CORBA.Object it means that the interface definition
for the object represented in the IOR was not found.  It looks like you
are importing the idl before doing anything, so this could very well be
a bug.  Try printing the __repo_id attribute of that object and see what
you get.  If it's correct, then the problem would seem to be the dynamic
IDL loading.  Can you send me the IOR and IDL files you're working with?

Also, give the CVS version a try, as this may inadvertently have been
fixed.  (There's been quite a bit of internal changes since the last
release.)  You'll have to patch automake as documented in the
python-am-changes directory.

Cheers,
Jason.

[Orbit-python-list] hi

[Khaled D. <kh...@w-...>]

First I would like to point out that it seems like it is dead quiet on
this list ( im not subscribed ) atleast if you like at the archive.

Anyway on to a problem Ive encountered.
I have a simple server implemented using c++/mico,
then using python and orbit-python I did this.

CORBA.load_idl("time.idl")
orb = CORBA.ORB_init((), CORBA.ORB_ID)
ior = open("/tmp/time.ior").readline()[:-1]
t = orb.string_to_object(ior)

the output looks like this.

<CORBA.Object object at 80ff980> 

Could one take that it is a nil reference with orbit-python ( Id like a
 is_nil implemented ) or should it be None ? 

When using your Bank example I get a nicer output
<Bank.Account object at 80f1a80>

So ofcourse the client i wrote with orbit-python does not
work, the c++ client works, but anyway I would like to know what
makes 't' to be a CORBA.Object.

If more info is needed just let me know.

/Khaled Daham, w.arts
Mail:    kh...@w-...
Cell:    +46-70-6785492, +966-54491462
FreeBSD: The Power to Serve! http://www.FreeBSD.org/

Re: [Orbit-python-list] Exceptions

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

> I apologize.  I cut and paste from two different attempts.  

Thought so.  But I still need to see the .idl file.  And a code snippet
that I can try myself and reproduce the error would help greatly as
well.

Re: [Orbit-python-list] Exceptions

[James T. <ja...@ko...>]

I apologize.  I cut and paste from two different attempts.  

The section

    try:
      self.database = self.factory.newDatabase( self.databaseName );
    except UnknownDatabase,ex:
      print "Failed to connect to database. Exiting."
      print ex.detail
      sys.exit(0)



should read

    try:
      self.database = self.factory.newDatabase( self.databaseName );
    except GEDI.UnknownDatabase,ex:
      print "Failed to connect to database. Exiting."
      print ex.detail
      sys.exit(0)


When _this_ code runs I get

  File "./DSgedi.py", line 38, in connect
    except GEDI.UnknownDatabase,ex:
NameError: GEDI

Sorry for the mix up,
James

Re: [Orbit-python-list] Exceptions

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

> This same code runs fine when not inside a class.  Any idea what am I
> missing?

The code and the error message don't seem to jive.  If you could paste
complete examples (even functional snippets), including the python code
and idl code of what breaks, then we'll have a better shot at finding
the answer.  In other words, your problem isn't obvious to me from what
you pasted.  The exception that was pasted doesn't make any sense to me
given the above code, so something's missing.  Need more info. :)

Cheers,
Jason.

[Orbit-python-list] Exceptions

[James T. <ja...@ko...>]

Hello,

I'm new to ORBit and orbit-python and having a bit of trouble. I've taken
a piece of python test code that contained no classes and attempted to
make it into a class.

Here's a snip of the code

import sys
try:
  import CORBA
except ImportError,ex:
  print "Failed to load CORBA module."
  print "Please see http://projects.sault.org/orbit-python/ for the
required python CORBA bindings"
  sys.exit(0);
        

class DSdataLink:
  def __init__(self, name, table):
    self.databaseName = name
    self.tableName    = table
    
  def connect(self):
    # find the object server base object
    CORBA.load_idl( "../../objectserver/idl/gedi.idl" )
    orb = CORBA.ORB_init( () , CORBA.ORB_ID )
    ior = open("/tmp/databasefactory.ior").readline()
    self.factory = orb.string_to_object(ior)

    try:
      self.database = self.factory.newDatabase( self.databaseName );
    except UnknownDatabase,ex:
      print "Failed to connect to database. Exiting."
      print ex.detail
      sys.exit(0)

    self.database.connect()


A bunch snipped.  

Now when this code runs I get


  File "./DSgedi.py", line 38, in connect
    except GEDI.UnknownDatabase,ex:
NameError: GEDI


This same code runs fine when not inside a class.  Any idea what am I
missing?

Thanks,
James

Re: [Orbit-python-list] Porting to Python 2.0b1

[Roland M. <ma...@ec...>]

Roland Mas (2000-09-07 19:11:54 +0200) :

> Jason Tackaberry (2000-09-07 12:47:36 -0400) :

[Roland Mas:]

> > >    * renamed init_exceptions() to ORBit_Python_init_exceptions() to avoid
> > >      namespace conflict with a similarly named function appearing in
> > >      Python 2.0.  Works fine with 2.0b1.
> > 
> > That's fine; we might as well rename all the other init_ functions to
> > use this convention as well.
> 
>   Okay, I'll do that part.  Well, my Emacs will, at any rate :-)

  Done, tested, went into CVS.

Roland.
-- 
Roland Mas

Mou ichido !  Hayaku !  Ookii koede !
  -- Atsuko Sasaki