orbit-python-list

[Orbit-python-list] segfault

[Adam O. <rh...@d2...>]

Attached is 'short' (80 line) script which reliably triggers a
segfault.  You use by running it in one terminal, then once it prints
'ready' you start a second copy.  The second copy will segfault.

I developed this using patched o-p and pygtk, but it seems to crash in
the same spot without them.  I added some try/except statements so it
should work either way with no changes.  I don't know if they have
anything to do with it or not.  I don't even remember what the patches
do ;)


-- 
Adam Olsen, aka Rhamphoryncus

Re: [Orbit-python-list] two questions

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

> I think you can, simply by having something like:
> IDL class -> base class -> your class

Not quite.  You're right about mix-ins though.  You want something like
this.

    module Example {
    	interface A {
    		void one();
    	};
    	interface B : A {
    		void two();
    	};
    };
    

    import CORBA
    import Example, Example__POA
    
    class A(Example__POA.A):
    	def one(self):
    		print "A::one"
    
    class B(Example__POA.B, A):
    	def one(self):
    		A.one(self)
    		print "B::one"
    
    	def two(self):
    		print "B::two"
    
Cheers,
Jason.
	
-- 
Academic Computing Support Specialist
Algoma University College
Sault Ste. Marie, Ontario
705-949-2301 x330                                   Personal Home Page
http://www.auc.ca                                     http://sault.org

Re: [Orbit-python-list] two questions

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

On Tue, 12 Feb 2002, [koi8-r] =E5=D7=C7=C5=CE=C9=CA =F3=C9=DA=C9=CB=CF=D7 w=
rote:

> > CORBA supports inheritance only at the interface level.  Implementors o=
f
> > a hierarchy can inherit their own implementation, of course, but CORBA
> > does not provide a means to inherit someone else's.
>
> But it would be nice to use the python class inheritance here, wouldn't i=
t?

I think you can, simply by having something like:

IDL class -> base class -> your class

You can probably use mixins too.

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

Re: [Orbit-python-list] two questions

[<eu...@en...>]

From: "Jason Tackaberry" <ta...@au...>
To: "Eugene Sizikov" <eu...@en...>
Cc: <orb...@li...>
Sent: Monday, February 11, 2002 11:16 PM
Subject: Re: [Orbit-python-list] two questions


> On Mon, 2002-02-11 at 01:40, Eugene Sizikov wrote:
> > hello all ppl!
> 
> Hi Eugene.
> 
> > i have a question: what's about interface inheritance in o-p? as i can
> > see, i need to implement methods of parent interface for all children?
> > or i'm not?
> 
> CORBA supports inheritance only at the interface level.  Implementors of
> a hierarchy can inherit their own implementation, of course, but CORBA
> does not provide a means to inherit someone else's.

But it would be nice to use the python class inheritance here, wouldn't it?

> 
> > also i don't understand how to work with CORBA exception declaration in
> > o-p.
> 
> You might want to look at the test suite under the src/ directory
> (test-suite.idl, test-server, and test-client) for an example of custom
> exceptions.  If you have any specific questions, feel free to ask here.
> 
> Jason.
> 
> -- 
> Academic Computing Support Specialist
> Algoma University College
> Sault Ste. Marie, Ontario
> 705-949-2301 x330                                   Personal Home Page
> http://www.auc.ca                                     http://sault.org

Re: [Orbit-python-list] two questions

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

On Mon, 2002-02-11 at 01:40, Eugene Sizikov wrote:
> hello all ppl!

Hi Eugene.

> i have a question: what's about interface inheritance in o-p? as i can
> see, i need to implement methods of parent interface for all children?
> or i'm not?

CORBA supports inheritance only at the interface level.  Implementors of
a hierarchy can inherit their own implementation, of course, but CORBA
does not provide a means to inherit someone else's.

> also i don't understand how to work with CORBA exception declaration in
> o-p.

You might want to look at the test suite under the src/ directory
(test-suite.idl, test-server, and test-client) for an example of custom
exceptions.  If you have any specific questions, feel free to ask here.

Jason.

-- 
Academic Computing Support Specialist
Algoma University College
Sault Ste. Marie, Ontario
705-949-2301 x330                                   Personal Home Page
http://www.auc.ca                                     http://sault.org

[Orbit-python-list] two questions

[Eugene S. <eu...@en...>]

hello all ppl!
i have a question: what's about interface inheritance in o-p? as i can
see, i need to implement methods of parent interface for all children?
or i'm not?
also i don't understand how to work with CORBA exception declaration in
o-p.

Re: [Orbit-python-list] workaround for gtk+corba

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

On Fri, 8 Feb 2002, Brian Craft wrote:

> Operating on the theory that the problem is the threading, I rebuilt pygtk w/o
> thread support (orbit-python has it disabled with a #define).

Yes, that's a known problem. Sorry to not have aided you before, but I
have been very busy this week with an article for FOSDEM and couldn't
concentrate.

If you use pygtk-0.6.9 it allows you to disable threading at runtime.

> There seems to be a significant design problem here with the python thread
> model. Perhaps python modules need to agree on a policy for storing thread
> info, so it can be shared. I don't know if it's possible for modules to
> share information.

I think it's possible, but Tack would be the person to comment on this.

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

[Orbit-python-list] workaround for gtk+corba

[Brian C. <bc...@th...>]

Operating on the theory that the problem is the threading, I rebuilt pygtk w/o
thread support (orbit-python has it disabled with a #define).

This appears to work. The glade top window came up, and it was able to process
a servant method invocation via orbit. Whoohoo.

The failure case (as I understand it) was occurring because pygtk was doing a
thread save prior to gtk_main(), and then the first corba event would attempt
to call into python w/o doing a thread restore. Then I'd get the thread error.

Enabling threading in orbit-python merely caused it to fail in the same
callback, on thread restore. I suspect this is because it's attempting to
restore from an uninitialized variable (since it's normally initialized in
orb.run(), which is never invoked).

There seems to be a significant design problem here with the python thread
model. Perhaps python modules need to agree on a policy for storing thread
info, so it can be shared. I don't know if it's possible for modules to
share information.

b.c.

[Orbit-python-list] threading, main loop

[Brian C. <bc...@th...>]

I'm starting to think the main loop problems are due to python's thread
locking.  The glib main loop stuff looks fairly straight-forward, and
everything seems to be handled correctly.

pygtk and orbit-python both make use of PyEval_SaveThread() and
PyEval_RestoreThread() when invoking callbacks. They reference different global
PyThreadState variables, and each assumes that they called PyEval_SaveThread()
prior to getting a callback.

The PyEval_SaveThread() calls are in their respective main()/run() methods.  So
when a callback occurs, one of the two libraries is going to do a restore on an
uninitialized state variable.

If gtk.mainloop() is called, this causes python to explicitly abort when a corba
event occurs, complaining about the state info. If orb.run() is called instead,
the gtk main loop is blocked for some reason I haven't figured out -- so
there's no error, but gtk also fails to run.

b.c.

Re: [Orbit-python-list] mainloop...

[Brian C. <bc...@th...>]

...hrrm. Apparently what I'm overlooking is orbit is broken:

CORBA_boolean CORBA_ORB_work_pending(CORBA_ORB orb, CORBA_Environment *ev)
{
        g_assert(!"Not yet implemented");
        return(CORBA_FALSE);
}

/* Section 4.9.2 */
void CORBA_ORB_perform_work(CORBA_ORB orb, CORBA_Environment *ev)
{
        g_assert(!"Not yet implemented");
        return;
}


bleh. Looks like that should read "Never going to be implemented", since
development seems to have shifted to ORBit2. ORBit2 appears to support these.

Dunno if anything works with ORBit2, however.

b.c.

Re: [Orbit-python-list] mainloop...

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

On Thu, 7 Feb 2002, Brian Craft wrote:

>   if orb.events_pending():
>     orb.mainiteration(0)
>     i = 0
> Is there some problem here I'm overlooking?

Yes. The ORBit-0.5.x API doesn't offer these functions.

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

[Orbit-python-list] mainloop...

[Brian C. <bc...@th...>]

I don't think this mainloop issue has to be so complicated.

Here's a bit of code that runs the pygtk main loop w/o halting the interpreter:

while 1:
  if gtk.events_pending():
    gtk.mainiteration(0)
  else:
    time.sleep(0.2)


Just implementing two equivalent calls for orbit-python would allow python,
orbit, and gtk to all coexist, something like this:

while 1:
  i = 1
  if gtk.events_pending():
    gtk.mainiteration(0)
    i = 0

  if orb.events_pending():
    orb.mainiteration(0)
    i = 0

  if i:
    time.sleep(0.1)


Is there some problem here I'm overlooking?

b.c.

Re: [Orbit-python-list] more mainloop woes

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

On Thu, 7 Feb 2002, Brian Craft wrote:

> errrrr..... Does orbit-python also hammer the python main loop? After orb.run()
> everything comes to a halt -- threads don't run, timers don't execute.

Python's global interpreter lock works that way: orb.run() is atomic, and
signals aren't handled, etc. IIRC it's been said that the GTK mainloop
uses a set of hacks to get things working, but I may be wrong. Tack is an
authority on this, and if you search the ML archives, you'll see me asking
the same questions.

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

[Orbit-python-list] more mainloop woes

[Brian C. <bc...@th...>]

errrrr..... Does orbit-python also hammer the python main loop? After orb.run()
everything comes to a halt -- threads don't run, timers don't execute.

b.c.

[Orbit-python-list] gnome, orbit & python?

[Brian C. <bc...@th...>]

Hi all -- Is it possible to use any of the python gnome bindings with
orbit-python? There seems to be an issue of integrating main loops. Poking
around the code I didn't see any methods besides run(), which doesn't
appear to allow such things. Maybe in different threads?

b.c.

[Orbit-python-list] doing a frontend/backend with o-p

[Adam O. <rh...@d2...>]

The situation:  I want a frontend that checks for user input, a
backend that checks networking, and for them to notify eachother when
they get input.

The problem:  If they both try to notify eachother at once they'll
deadlock.  It's a race condition.

The solutions:
a) I can make the frontend poll the backend for updates, instead of
the backend pushing them to the client
b) I can make them able to service requests while making requests of
their own.

b can be done either by making the orb reentrant[0], so that it
recursively handles requests when waiting for requests of it's own to
be answered, or by using threads.  If there's a problem with threads
then forking could probably be done instead.

And so my question:  what is the practical solution now, and what'll
be practical in the future?


[0] I've no idea if CORBA has a problem with this or not.

-- 
Adam Olsen, aka Rhamphoryncus

[Orbit-python-list] glib mainloop patch (for posterity)

[Adam O. <rh...@d2...>]

-- 
Adam Olsen, aka Rhamphoryncus

[Orbit-python-list] Re: ORBit-Python lacks a version string.

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

On Fri, 2002-02-01 at 15:23, Johan Dahlin wrote:
> > And CORBA._orbit_version please. :-)
> and/or CORBA._orbit_python_version

CORBA._orbit_python_version and CORBA._orbit_version would be fine.  I
think I'd really like to see an ORBit module where we can put all these
o-p specific things, like _load_idl, and _libidl_args.

Jason.

-- 
Academic Computing Support Specialist
Algoma University College
Sault Ste. Marie, Ontario
705-949-2301 x330                                   Personal Home Page
http://www.auc.ca                                     http://sault.org

[Orbit-python-list] Re: ORBit-Python lacks a version string.

[Johan D. <jd...@te...>]

fre 2002-02-01 klockan 21.14 skrev Christian Robottom Reis:
> On 1 Feb 2002, Johan Dahlin wrote:
> 
> > > It should be pretty simple to fix, no? We could have the ORBit version and
> > > the ORBit-Python version done in the same way. We'd have to do op_version
> > > perhaps there.
> > >
> > Actually, you can do this.
> >
> > orbit-python-config --version
> 
> Yes, but not from a pure Python script without os.system() or something
> like that..
> 
> > But that requires the -devel package of orbit-python to be installed.
> 
> Uhh, we do source code installs here.
> 
> > Tack, what do you think about adding a CORBA._op_version ?
> 
> And CORBA._orbit_version please. :-)
and/or CORBA._orbit_python_version

> 
> Take care,
> --
> Christian Reis, Senior Engineer, Async Open Source, Brazil.
> http://async.com.br/~kiko/ | [+55 16] 272 3330 | NMFL
> 

[Orbit-python-list] Re: ORBit-Python lacks a version string.

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

On 1 Feb 2002, Johan Dahlin wrote:

> > It should be pretty simple to fix, no? We could have the ORBit version and
> > the ORBit-Python version done in the same way. We'd have to do op_version
> > perhaps there.
> >
> Actually, you can do this.
>
> orbit-python-config --version

Yes, but not from a pure Python script without os.system() or something
like that..

> But that requires the -devel package of orbit-python to be installed.

Uhh, we do source code installs here.

> Tack, what do you think about adding a CORBA._op_version ?

And CORBA._orbit_version please. :-)

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

[Orbit-python-list] ORBit-Python lacks a version string.

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

Recently, we added an installer to our product, which checks to see
versions available of our dependencies. One real problem we ran into with
O-P was the fact that nowhere is there a version string we can check on.

It would be nice to have one. I'm adding here a user-view of how pygtk
does it:

>>> gtk.pygtk_version
(0, 6, 9)
>>> gtk.gtk_version
(1, 2, 10)

It should be pretty simple to fix, no? We could have the ORBit version and
the ORBit-Python version done in the same way. We'd have to do op_version
perhaps there.

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

Re: [Orbit-python-list] Do activate_object_with_id and -ORBIPv4Port really work?

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

On Thu, 31 Jan 2002, ml wrote:

> It seems to be either a problem with (C-)Orbit or with my
> understanding of it.  I compiled the echo-server.c from
> the orbit-0.5.13 test suite and ran it as follows:
>
> ./echo-server -ORBIPv4Port=7777 -ORBIIOPIPv4=1 -ORBIIOPUSock=0
>
> Neither is the object id "myEchoString" as it should,
> because PortableServer_POA_activate_object_with_id() has
> been called nor is the open port 7777, but 1166 or so.
> The ior-decode utility and a check using netstat -an shows
> this clearly.  IP and not UNIX sockets is used, at least.

Could you file a bug on bugzilla.gnome.org and CC: me on it please?

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

Re: [Orbit-python-list] Do activate_object_with_id and -ORBIPv4Port really work?

[<ml...@kn...>]

On Thu, Jan 31, 2002 at 06:30:15PM -0200, Christian Robottom Reis wrote:
> On Thu, 31 Jan 2002, ml wrote:
> 
> > > I hacked 0.3.1 to fix this, but it could be that the parameter is not
> > > being passed along. I'm not sure if that's your problem. What happens if
> > > you don't pass those in?
> >
> > The first two arguments do have the expected effect, the
> > third not.
> 
> It could be an orbit bug; can you try and bring it up with them?
> 
> We may not be passing in the parameter, but I find that very hard to
> believe if the others do and we don't manipulate them. Changing order does
> nothing, I assume?

It seems to be either a problem with (C-)Orbit or with my
understanding of it.  I compiled the echo-server.c from
the orbit-0.5.13 test suite and ran it as follows:

./echo-server -ORBIPv4Port=7777 -ORBIIOPIPv4=1 -ORBIIOPUSock=0

Neither is the object id "myEchoString" as it should,
because PortableServer_POA_activate_object_with_id() has
been called nor is the open port 7777, but 1166 or so.
The ior-decode utility and a check using netstat -an shows
this clearly.  IP and not UNIX sockets is used, at least.

Cheers!

Re: [Orbit-python-list] Do activate_object_with_id and -ORBIPv4Port really work?

[<ml...@kn...>]

On Thu, Jan 31, 2002 at 06:30:15PM -0200, Christian Robottom Reis wrote:
> On Thu, 31 Jan 2002, ml wrote:
> 
> > > I hacked 0.3.1 to fix this, but it could be that the parameter is not
> > > being passed along. I'm not sure if that's your problem. What happens if
> > > you don't pass those in?
> >
> > The first two arguments do have the expected effect, the
> > third not.
> 
> It could be an orbit bug; can you try and bring it up with them?
> 
> We may not be passing in the parameter, but I find that very hard to
> believe if the others do and we don't manipulate them. Changing order does
> nothing, I assume?

Right, that doesn't help either.  I hope, I will find time
to test it with (C-)Orbit(1).

Cheers.

Re: [Orbit-python-list] ORBit-python 1.99.0 released

[Johan D. <jd...@te...>]

tor 2002-01-31 klockan 21.22 skrev ml:
> Hi,
> 
> On Thu, Jan 31, 2002 at 10:57:48AM +0100, Johan Dahlin wrote:
> > I just uploaded orbit-python-1.99.0.tar.gz to ftp.gnome.org (actually
> > James Henstridge did).
> 
> Thanks for helping debugging by leaving a 1.2M core file
> under test-suite/ :-)
You're welcome :)
(doh!)

> 
> Anyway, I tried compiling, but idl.c and types.c failed
> because of a problem with 'sublabels'.  Has it to be
> CORBA_long or CORBA_any or what?  Maybe it's because I
> have still orbit2 2.3.102 and not 2.3.103?
Exactly, you'll need ORBit2 2.3.103.

> 
> Cheers!