orbit-python-list

Re: [Orbit-python-list] (in Object obj) marshalling error

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

> >    if (glue || !strcmp(tc->repo_id, ""))
> 
> What exactly are repo_id and repo_object? Can't seem to follow this bit of
> the code.

repo_id is the repository id of the interface (or struct, or union, or
enum, etc.) of the type.  For example, IDL:Module/Interface:1.0.

The snippet of code above checks to see if we know about the interface
described by the repo_id (it looks it up in the hash table), or if the
repo_id is an empty string, which means that the type is an generic
object reference.  I'm really not sure why ORBit uses an empty repo id
and not IDL:CORBA/Object.

Jason.

Re: [Orbit-python-list] (in Object obj) marshalling error

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

On Tue, 23 Jan 2001, Jason Tackaberry wrote:

>    if (glue || !strcmp(tc->repo_id, ""))

Fix worked - at least the object reference gets passed on. I recompiled
without ORBIT_PYTHON_NOT_THREADED and of course, when I called a method
that was part of an object I was passing as a parameter, I got the dreaded

Fatal Python error: PyThreadState_Get: no current thread

error. Recompiling with -DORBIT_PYTHON_NOT_THREADED worked fine. Thanks.


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

Re: [Orbit-python-list] (in Object obj) marshalling error

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

On Tue, 23 Jan 2001, Jason Tackaberry wrote:

>    if (glue || !strcmp(tc->repo_id, ""))

What exactly are repo_id and repo_object? Can't seem to follow this bit of
the code.

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

Re: [Orbit-python-list] Distutils for orbit-python?

[Jade M. <ja...@gn...>]

On Wed, Jan 24, 2001 at 03:33:09PM -0500, Jason Tackaberry wrote:
> > Have you guys considered using Distutils instead of autotools for
> > building orbit-python?  Auto[conf|make] is the more traditional way,
> > but distutils seems to be the more "pythonic" way of doing things
> 
> I wouldn't be opposed to it, as long as it was as portable as the
> autoconf way.  Does this pretty much only work with Python 2.0, though?

This works with 1.5.2 (I don't have anything but that installed, so it should work on 2.0) you have to install the distutils module for 1.5.2 but thats no biggie.

> I'll give your script a whirl on Solaris and Linux, and see how it
> works.

OK thanks.  I've tested it on a couple of Debian (sid) machines and all was well.  It is much much easier than having to patch automake and do strange things to it :)

-- 

Jade Meskill <ja...@gn...>
GNU Enterprise
http://www.gnue.org

Re: [Orbit-python-list] Distutils for orbit-python?

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

> Have you guys considered using Distutils instead of autotools for
> building orbit-python?  Auto[conf|make] is the more traditional way,
> but distutils seems to be the more "pythonic" way of doing things

I wouldn't be opposed to it, as long as it was as portable as the
autoconf way.  Does this pretty much only work with Python 2.0, though?

I'll give your script a whirl on Solaris and Linux, and see how it
works.

Jason.

Re: [Orbit-python-list] the never ending segfault.. (possible fix)

[Andrew M. <am...@es...>]

From: Jason Tackaberry <ta...@li...>

ta...@li... doesn't work for me - I get a ''User unknown" reply.


> Can you show me how to reproduce the segfault?

Not easily, but if the boss gives me a few moments, I'll try to get a small
program that shows the problem.

Unfortunately, the server that it's a problem with is somewhat complex to
install (several dependancies, including some data that needs to be stored
in a MySQL database) - I'll need to try and get a dummy server that gives
the same problem soon, though. That should be lots of fun, as I'm still not
certain what's actually causing the problem.

Re: [Orbit-python-list] the never ending segfault.. (possible fix)

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

> For the time being, we'll use the version with that test commented
> out, but I'm hoping someone who knows more about orbit-python can
> verify this.

Can you show me how to reproduce the segfault?

Thanks,
Jason.

Re: [Orbit-python-list] (in Object obj) marshalling error

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

> You're right. My example was stupid. The problem I have is that ATM you
> can't even pass a Corba Object as a parameter -- you get the exact same
> error. As a simple example:

Right.  It's a bug. :)   I've little free time until tomorrow night, so
I may not commit a fix until then.

But give this a try: in marshal.c, line 473 (or there abouts, I'm a
little out of sync), change:

   if (glue)

to

   if (glue || !strcmp(tc->repo_id, ""))

Like I said, this is so trivial it can't possibly work, right? :)  Let
me know.

Cheers,
Jason.

Re: [Orbit-python-list] (in Object obj) marshalling error

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

On Tue, 23 Jan 2001, Jason Tackaberry wrote:

> > [...]
> > class Foo:
> >    pass
> > a=Foo()
> > nc.bind(a)
> > TypeError: Failed to marshal: Object Reference ()
> 
> Like I said earlier, ORBit-Python doesn't handle generic object
> references.  However, even if it did, this wouldn't work because Foo
> doesn't inherit a POA class.

You're right. My example was stupid. The problem I have is that ATM you
can't even pass a Corba Object as a parameter -- you get the exact same
error. As a simple example:

module Bar {
	interface Foo {
		void bind (in Object a);
	};
};

and the following servant:

#!/usr/bin/env python
import CORBA
import Bar,Bar__POA

class Foo(Bar__POA.Foo):
	def bind(self,i):
		print i

o=CORBA.ORB_init([],CORBA.ORB_ID)
p=o.resolve_initial_references("RootPOA")
f=Foo()
f._this()
ref = p.servant_to_reference(f)
print o.object_to_string(ref)
p._get_the_POAManager().activate()
o.run()

produce the same TypeError: Failed to marshal: Object Reference ()

when a client like this tries to call bind:

#!/usr/bin/env python
import sys,CORBA, Bar, Bar__POA

o=CORBA.ORB_init([],CORBA.ORB_ID)
f=o.string_to_object(sys.argv[1])

f.bind(f)

Okay, so I used f as a parameter to itself: it should work, no? And f _is_
a reference to a Corba object.

> I'm not entirely sure what happened here, but my guess is 'a' wasn't a
> valid IOR (such as, for example, if it has trailing newlines and you're
> not using the latest CVS version).

Actually, it was a valid IOR and ior-decode indicated it as such. I'm
using CVS orbit-python (and I check to see if it's been updated daily too
*grin*) But I can't seem to reproduct this right now.

> Well again, ORBit-Python won't handle the objref properly, but in this
> case you're not passing it a CORBA object.  It sounds to me like you're
> mixing up the Any type with the Object type. 

No, just trying (brokenly) to illustrate that I get the same error message
whether it's a Corba Object or a plain Python object. My example

class Foo:
	pass

should really have been

class Foo(Bar__POA.Foo)
	pass

but it still doesn't work, regardless :-)

> It's just missing a FIXME :)
> So, here the segfault happens inside object_to_string, not bind().

Ok, this is reasonable, I was just wondering. :-)

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

[Orbit-python-list] the never ending segfault.. (possible fix)

[Andrew M. <am...@es...>]

in src/demarshall.c the test for if( RECV_BUFFER_LENGTH(buf) < n ) appears to 
be incorrect: the RECV_BUFFER_LENGTH macro was returning a value of '3' which 
is less than 4 - however, commenting out this test allowed the client to work 
fine (or at least the error I was seeing has gone away.)

in src/client.c (line 178) the variable 'o' is set to NULL, after the 
apparantly incorrect test (above). This causes the actual segfault, seemingly 
because somewhere between the two, an error check is done, but not handled. 
(I'm not sure exactly where the error should be handled - but skipping the test 
caused another error, reporting a NULL return without an error.)

For the time being, we'll use the version with that test commented out, but I'm 
hoping someone who knows more about orbit-python can verify this.

Re: [Orbit-python-list] (in Object obj) marshalling error

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

> So I'm passing as a parameter a Python Object which I've just instantiated
> from a class that inherits from a __POA class, so it _is_ a Corba Object.

As Roland pointed out, Foo is a Python object, not derived from the
__POA class.  ORBit-Python has no idea what to do with that object, even
if it weren't broken. ;)

Basically ORBit-Python doesn't seem to handle generic object references
very well (at all) right now.  I made a change to my local copy that
_seems_ to correct the problem, but the change was so trivial that it
can't possibly be right, so I'll want to test it a little further before
I commit it.

> According to the CORBA Python Mappings,
> 
>  	If an operation expects parameters of the IDL Object type, any
> 	Python object representing an object reference might be passed as
> 	a value.

I think you might have misunderstood what this says, or maybe it's a
little ambiguous.  A Python object representing an object reference
looks like:

   class Foo(CosNaming__POA.NamingContext):
      pass
   a = Foo()
   a._this() # implicit activation
   ref = poa.servant_to_reference(a) 
   # ref is a python object that represents the object reference
   print ref

Yields:

   <CosNaming.NamingContext object at 80e2518>

I don't think the mapping specification says that in your example
bind(1) should work.  1 is not a CORBA object.  I think, though, it
might be a nice feature if ORBit-Python coerced servants into object
references in this situation.

> A different message, for the same reason? What I mean is that _any_ object
> that I pass - be it local, Corba, or simple number/string objects get me

No, a different message for a different reason.  I'll go through your
examples from your original email and explain what happened:

> 1) Calling bind with a simple object reference:

> [...]
> class Foo:
>    pass
> a=Foo()
> nc.bind(a)
> TypeError: Failed to marshal: Object Reference ()

Like I said earlier, ORBit-Python doesn't handle generic object
references.  However, even if it did, this wouldn't work because Foo
doesn't inherit a POA class.

> 2) Didn't work? Ok, let's try a stringified IOR:
> nc.bind(orb.object_to_string(a))
> CORBA.SystemException: IDL:CORBA/MARSHAL:1.0: IDL:CORBA/MARSHAL:1.0

I'm not entirely sure what happened here, but my guess is 'a' wasn't a
valid IOR (such as, for example, if it has trailing newlines and you're
not using the latest CVS version).

This exception was probably raised from object_to_string, not within
the bind stub.

> 3) Let's do something dumb now:
> nc.bind(1)
> TypeError: Failed to marshal: Object Reference ()

Well again, ORBit-Python won't handle the objref properly, but in this
case you're not passing it a CORBA object.  It sounds to me like you're
mixing up the Any type with the Object type. 

> 4) And what about
> nc.bind(orb.object_to_string(1))
> Segmentation fault

Okay, well this is a bug in ORBit-Python, to be sure.  ORBit-Python's
object_to_string doesn't do any sanity checking.  ORBit-Python happily
passes this over to ORBit, which in turn happily tries to dereference
this value (thinking it is a CORBA_Object) and kaboom.

This is documented actually in the source code, in CORBA_ORB.c:

   if (PyArg_ParseTuple(args, "O", &obj)) {
      // validate obj == CORBA_PyObject
      s = CORBA_ORB_object_to_string(self->obj, obj->obj, &self->ev);
 [ ... ]

It's just missing a FIXME :)

So, here the segfault happens inside object_to_string, not bind().

Anyway thanks for identifying this bug.  I'll hopefully commit some sort
of fix by the end of the day. :)

Jason.

Re: [Orbit-python-list] (in Object obj) marshalling error

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

On 23 Jan 2001, Roland Mas wrote:

> > TypeError: Failed to marshal: Object Reference ()
> > 
> > even though a _is_ an object reference.
> 
>   Hm.  Is is a Python object reference, I'm not sure it's a CORBA
> object reference.

According to the CORBA Python Mappings,

 	If an operation expects parameters of the IDL Object type, any
	Python object representing an object reference might be passed as
	a value.

So I'm passing as a parameter a Python Object which I've just instantiated
from a class that inherits from a __POA class, so it _is_ a Corba Object.

> > Hmm. I wonder why I get a different message?
> 
>   For the same reason.  a is not of a type known by ORBit.

A different message, for the same reason? What I mean is that _any_ object
that I pass - be it local, Corba, or simple number/string objects get me
the same error. However, passing an IOR string gets me a different
one? Sounds strange, but I haven't looked at the source yet.

> You should add an interface like:
> 
> interface Foo {
>   attribute string bar ;
> } ;

Oh, I do have an interface for my Corba Object which I'm passing as a
parameter. The purpose of this exercise is binding an object - a factory
in this case - to the namingservice. The bind() call takes an Object as a
parameter, so I instantiate a factory and pass it on. However, the
marshalling breaks, and it breaks with any object I push through as well.

> > The practical effect of this is that it's impossible to use
> > orbit-python with the Orbit nameserver as of now.
> 
>   I'm not so sure.  It's not like I have done it, but I would be more
> convinced if you could retry with CORBA objects.

They were Corba Objects. I was incomplete in my explanation, and I'm
sorry, but the objects I was passing initially are Corba Objects with
interfaces defined in the IDL. And they get ht the exact same error as
plain Python objects, so it's strange.

Thanks a lot for the reply.

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

Re: [Orbit-python-list] (in Object obj) marshalling error

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

Christian Robottom Reis (2001-01-22 22:24:31 -0200) :

> Using orbit-python (no idea if we're getting a Orbit error, however) and a
> simple 
> 
> interface NamingObject {
>         void bind(in Object obj);
> };
> 
> interface, I have the following issues:
> 
> 1) Calling bind with a simple object reference:
> 
> [...]
> class Foo:
> 	pass
> a=Foo()
> nc.bind(a)
> 
> TypeError: Failed to marshal: Object Reference ()
> 
> even though a _is_ an object reference.

  Hm.  Is is a Python object reference, I'm not sure it's a CORBA
object reference.

> 2) Didn't work? Ok, let's try a stringified IOR:
> 
> nc.bind(orb.object_to_string(a))
> 
> CORBA.SystemException: IDL:CORBA/MARSHAL:1.0: IDL:CORBA/MARSHAL:1.0
> 
> Hmm. I wonder why I get a different message?

  For the same reason.  a is not of a type known by ORBit.

> 3) Let's do something dumb now:
> 
> nc.bind(1)
> 
> TypeError: Failed to marshal: Object Reference ()

  Same again.

  You can only marshal objects that are defined in a CORBA interface.

You should add an interface like:

interface Foo {
  attribute string bar ;
} ;

  Then you need to make your Python Foo class a subclass of
Your_module__POA.Foo: 

class Foo (Your_module__POA.Foo):
  def __init__ (self):
    self.bar = "Initial string"

  Only then will ORBit-Python know how to marshal your Foo objects.

> 4) And what about
> 
> nc.bind(orb.object_to_string(1))
> 
> Segmentation fault
> 
> Hmm, boom. Orbit-python or plain Orbit?

  That's a tricky question, and a nasty bug anyway.  I'll try to have
a look sometime.

> The practical effect of this is that it's impossible to use
> orbit-python with the Orbit nameserver as of now.

  I'm not so sure.  It's not like I have done it, but I would be more
convinced if you could retry with CORBA objects.

> We simply can't bind the servers to names because bind() takes an
> object parameter.

  Yep.  A CORBA object, not a Python object.

Roland.
-- 
Roland Mas

Et c'est tellement plus mignon de se faire traiter de con en chanson...
  -- in En chantant (Michel Sardou)

[Orbit-python-list] (in Object obj) marshalling error

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

Using orbit-python (no idea if we're getting a Orbit error, however) and a
simple 

interface NamingObject {
        void bind(in Object obj);
};

interface, I have the following issues:

1) Calling bind with a simple object reference:

[...]
class Foo:
	pass
a=Foo()
nc.bind(a)

TypeError: Failed to marshal: Object Reference ()

even though a _is_ an object reference.

2) Didn't work? Ok, let's try a stringified IOR:

nc.bind(orb.object_to_string(a))

CORBA.SystemException: IDL:CORBA/MARSHAL:1.0: IDL:CORBA/MARSHAL:1.0

Hmm. I wonder why I get a different message?

3) Let's do something dumb now:

nc.bind(1)

TypeError: Failed to marshal: Object Reference ()

Ok, same error as my first non-ior attempt. Passing any other object gets
me the same error (strings, etc).

4) And what about

nc.bind(orb.object_to_string(1))

Segmentation fault

Hmm, boom. Orbit-python or plain Orbit?

The practical effect of this is that it's impossible to use orbit-python
with the Orbit nameserver as of now. We simply can't bind the servers to
names because bind() takes an object parameter. I've cut out the offending
code and will start looking for the issue; in the meantime, if Jason has
any ideas.. :-)

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

Re: [Orbit-python-list] Undefined Symbol POAManager_PyObject_Type

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

On Wed, 17 Jan 2001, Jade Meskill wrote:

> > > Hrm... I must've missed that posting. :( I will take another look
> > > and see if I can recommend a patch to debian also.  Do you know if
> > > this has been fixed in later versions of Python (1.6 or 2.0)?

Ok, lucky I caught this this week :-)

The issue is that Python should _not_ use RTLD_GLOBAL, since it does (if I
may) namespace-pollution (ok, ok). Fix is

a) Patch Python (oh, yes, lovely). It's easy and it's stupid and it's what
I did. If you need to release stuff then I would definitely cry about
it. Stuff will work on RH, of course.

b) Fix orbit-python. Perhaps this sound harsh, but it's true: orbit-python
needs to get some work done if it's to be used in a large
application. I've been stumped on many little issues over it and I've
considered learning Python modules and Orbit just to get it working. I
just haven't got the time lately, it seems, and neither has Jason,
unfortunately.

I'm still considering it because of (check next post: bug)

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

Re: [Orbit-python-list] Undefined Symbol POAManager_PyObject_Type

[<jp...@ar...>]

On Wed, 17 Jan 2001, Jade Meskill wrote:
> Ah OK.  What the message suggests was what I was going to suggest next,
> basically you have to make a library that shares the common bits between
> CORBAmodule and PortableServermodule and link them to that
> library.  This would be the most correct approach anyways IMHO, as it
> doesn't rely on patching python at all.

If I may chime in here, you may want to look at how pygtk does this 
-- see gtkmodule.[ch] in pygtk.  Basically, one module needs to setup an
structure of function pointers to the C functions that are to be made
available to other modules.  A pointer to this structure is then wrapped
in a PyCObject and made available as an attribute of the module or as the
return value of a Python callable C function.

The problem with creating a shared library and having both modules link
against it is that the shared library must then be in LD_LIBRARY_PATH or
one of the system shared lib directories, which complicates installation /
uninstallation.

John

------------------------------------------------------------------------
Archaeopteryx Software, Inc.                        Wing IDE for Python 
www.archaeopteryx.com                               Take Flight!

Re: [Orbit-python-list] Undefined Symbol POAManager_PyObject_Type

[Jade M. <ja...@gn...>]

On Wed, Jan 17, 2001 at 06:34:36PM +0100, Roland Mas wrote:
> Jade Meskill (2001-01-17 10:16:45 -0700) :
> 
> > On Tue, Jan 16, 2001 at 11:45:48PM -0500, Jason Tackaberry wrote:
> [...]
> > > Christian Reis (on Dec 4) reported the problem was due to Python not
> > > passing RTLD_GLOBAL to dlopen().  RedHat packages a patched version, and
> > > since I used that, I never noticed the problem.  He included a patch as
> > > well, if you want to check the archives.
> > 
> > Hrm... I must've missed that posting. :( I will take another look
> > and see if I can recommend a patch to debian also.  Do you know if
> > this has been fixed in later versions of Python (1.6 or 2.0)?
> 
>   There has been a message in the debian-python explaining that this
> RTLD_GLOBAL "bug" was in fact not one.  See it in the archive at
> <URL:http://lists.debian.org/debian-python-0101/msg00058.html>
> 

Ah OK.  What the message suggests was what I was going to suggest next, basically you have to make a library that shares the common bits between CORBAmodule and PortableServermodule and link them to that library.  This would be the most correct approach anyways IMHO, as it doesn't rely on patching python at all.

-- 

Jade Meskill <ja...@gn...>
GNU Enterprise
http://www.gnue.org

Re: [Orbit-python-list] Undefined Symbol POAManager_PyObject_Type

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

Jade Meskill (2001-01-17 10:16:45 -0700) :

> On Tue, Jan 16, 2001 at 11:45:48PM -0500, Jason Tackaberry wrote:
[...]
> > Christian Reis (on Dec 4) reported the problem was due to Python not
> > passing RTLD_GLOBAL to dlopen().  RedHat packages a patched version, and
> > since I used that, I never noticed the problem.  He included a patch as
> > well, if you want to check the archives.
> 
> Hrm... I must've missed that posting. :( I will take another look
> and see if I can recommend a patch to debian also.  Do you know if
> this has been fixed in later versions of Python (1.6 or 2.0)?

  There has been a message in the debian-python explaining that this
RTLD_GLOBAL "bug" was in fact not one.  See it in the archive at
<URL:http://lists.debian.org/debian-python-0101/msg00058.html>

Roland.
-- 
Roland Mas

Food, shelter, source code.
  -- Cyclic Software

Re: [Orbit-python-list] Undefined Symbol POAManager_PyObject_Type

[Jade M. <ja...@gn...>]

On Tue, Jan 16, 2001 at 11:45:48PM -0500, Jason Tackaberry wrote:
> > Hello all,
> 
> Hi Jade,
> 
> > I am trying to use the latest CVS version of Orbit-Python, but am
> > having problems importing PortableServer.  on import PortableServer I
> > get undefined symbol: POAManager_PyObject_Type.  I read the mail
> > archives, but couldn't find a real solution to the problem, I have
> 
> Christian Reis (on Dec 4) reported the problem was due to Python not
> passing RTLD_GLOBAL to dlopen().  RedHat packages a patched version, and
> since I used that, I never noticed the problem.  He included a patch as
> well, if you want to check the archives.

Hrm... I must've missed that posting. :(  I will take another look and see if I can recommend a patch to debian also.  Do you know if this has been fixed in later versions of Python (1.6 or 2.0)?  
> 
> I consider this to be a bug in ORBit-Python, obviously.  One shouldn't
> have to patch Python to make it work.  I don't expect the problem will
> be excessively hard to avoid, but, sadly, I haven't had any time to hack
> on the project lately.  (I wanted to work on it during the Christmas
> break but I was having problems with my teeth and dentists are awfully
> hard to come by around that time. :))
> 
> Fixing up ORBit-Python and preparing it for a 0.2.0 release is slowly
> edging up in priority on my personal TODO list.  There's no point in my
> giving an ETA because I'm pathetic at managing my own time, but
> naturally I am accepting patches if you'd care to have your own hand at
> it. :)

Well, I am very interested in the project as we are currently using it in the project I am working on (GNU Enterprise (http://gnue.org or http://www.gnu.org/projects/gnue)), we need it to bridge our python based UI to our CORBA based object server, and I am also using it at my Real Job(tm), so I will be getting a lot of use out of it.  My C skillz are a little rusty (been using too much python lately :) but I will start to hack around and see what I can figure out.  I have had some other strange problems also, but I will send that in a separate thread.

-- 

Jade Meskill <ja...@gn...>
GNU Enterprise
http://www.gnue.org

Re: [Orbit-python-list] Undefined Symbol POAManager_PyObject_Type

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

> Hello all,

Hi Jade,

> I am trying to use the latest CVS version of Orbit-Python, but am
> having problems importing PortableServer.  on import PortableServer I
> get undefined symbol: POAManager_PyObject_Type.  I read the mail
> archives, but couldn't find a real solution to the problem, I have

Christian Reis (on Dec 4) reported the problem was due to Python not
passing RTLD_GLOBAL to dlopen().  RedHat packages a patched version, and
since I used that, I never noticed the problem.  He included a patch as
well, if you want to check the archives.

I consider this to be a bug in ORBit-Python, obviously.  One shouldn't
have to patch Python to make it work.  I don't expect the problem will
be excessively hard to avoid, but, sadly, I haven't had any time to hack
on the project lately.  (I wanted to work on it during the Christmas
break but I was having problems with my teeth and dentists are awfully
hard to come by around that time. :))

Fixing up ORBit-Python and preparing it for a 0.2.0 release is slowly
edging up in priority on my personal TODO list.  There's no point in my
giving an ETA because I'm pathetic at managing my own time, but
naturally I am accepting patches if you'd care to have your own hand at
it. :)

Cheers,
Jason.

[Orbit-python-list] Distutils for orbit-python?

[Jade M. <ja...@gn...>]

Have you guys considered using Distutils instead of autotools for building =
orbit-python?  Auto[conf|make] is the more traditional way, but distutils s=
eems to be the more "pythonic" way of doing things these days (now that it =
is functional that is :)  It may make it much easier to port orbit-python t=
o different platforms in the future, not to mention it eliminates the need =
for patching automake.  Anyways, I have hacked together a rough setup.py sc=
ript that successfully builds orbit-python for me (although I still have th=
e undefined symbol problems mentioned in my previous mail).  Please let me =
know if this is something orbit-python would like to use.  Thanks!

--=20

Jade Meskill <ja...@gn...>
GNU Enterprise
http://www.gnue.org

[Orbit-python-list] Undefined Symbol POAManager_PyObject_Type

[Jade M. <ja...@gn...>]

Hello all,

I am trying to use the latest CVS version of Orbit-Python, but am having problems importing PortableServer.  on import PortableServer I get undefined symbol: POAManager_PyObject_Type.  I read the mail archives, but couldn't find a real solution to the problem, I have made sure that there are no older versions of Orbit-Python anywhere on my system.  I am using Debian GNU/Linux on an i686, python 1.5.2.  Any suggestions?

-- 

Jade Meskill <ja...@gn...>
GNU Enterprise
http://www.gnue.org

[Orbit-python-list] orbit-python breaks shelve

[Rob R. <rr...@do...>]

I have the latest orbit-python from CVS installed and have found that
the shelve module is apparently broken. It appears to be due to the
__import__() function being overridden. To duplicate, just import CORBA
before calling shelve.open(). Does anyone have a fix or work-around for
this?

--
Rob Riggs
Unix System Administrator
DoubleClick/DARTmail - Broomfield, CO

Re: [Orbit-python-list] Re: [Python-Help] importdl.c and RTLD_GLOBAL for dlopen (fwd)

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

> I've exchanged a couple of emails with Martin here who points out my patch
> solution isn't ideal (though it Works For Me (TM)):

I'll fix ORBit-Python to work with the stock Python.  One more thing on
the todo list for my week off.

Or, that might happen next week.  I'm getting my wisdom teeth removed on
Monday (ouch!), so I'll be taking a few sick days.  I might have the
opportunity to hack a bit on ORBit-Python then.

Jason.

[Orbit-python-list] Re: [Python-Help] importdl.c and RTLD_GLOBAL for dlopen (fwd)

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

I've exchanged a couple of emails with Martin here who points out my patch
solution isn't ideal (though it Works For Me (TM)):

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

---------- Forwarded message ----------
Date: Tue, 5 Dec 2000 12:18:24 +0100 (MET)
From: Martin von Loewis <lo...@in...>
Reply-To: he...@py...
To: ki...@as...
Cc: pyt...@py...
Subject: Re: [Python-Help] importdl.c and RTLD_GLOBAL for dlopen

> a) Why was the change reverted? 

It had been causing problems if two extension modules would define the
same symbol with a different meaning. In a specific case, an Oracle
module used a symbol named "initsocket". Unfortunately, the dynamic
linker would resolve that as the symbol from the socket module, so the
application crashed.

If different extension modules can't exchange symbols, you don't get
this problem.

> Is the policy for 2.0 the same?

Yes, it is.

> Redhat supplies a patched version by default that includes
> RTLD_GLOBAL.

They should not do this. Do you know who at Redhat is responsible for
packaging Python?

> b) Is there a suggested workaround for this issue? 

Yes. The suggested work-around is to create a table of function
pointers and put that in a PyCObject. Export that object under a
well-known name in one module, and import it in the other. See
cStringIO.c or ucnhash for examples where this is used in Python, see
NumPy for a larger example that manages many functions that way.

Hope this helps,
Martin