orbit-python-list

[Orbit-python-list] Latest CVS updates

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

Roland and I have been busy today tracking down a bug with demarshalling
sequences.  (Actually even figuring out the bug was in the demarshalling
code was a chore.)  It turns out that the bug was in some code I took
from ORBit's perl bindings.  We think the problem is fixed, and life is
once again good.

Here's the ChangeLog excerpt:

2001-01-28  Jason Tackaberry <ta...@li...>

   * marshal.c: be able to marshal generic object references
   * demarshal.c: calculate the bytes left in the receive buffer properly
     (we think) and handle the incomplete message case when this value
     goes negative.  Sequences should now demarshal properly.  Since
     this code was taken from CORBA::ORBit, it also suffered from this
     bug.  Roland submitted a patch for this project.
   * test-server: we don't need to import whrandom anymore.
   * PortableServermodule.c: removed references to POAManager_PyObject
     and POA_PyObject from the PortableServer module.  This should take
     care of the undefined symbol problem with RTLD_GLOBAL vs. RTLD_LAZY.
     Right now this is just an empty module.  I'm going to have to rethink
     the interaction between the PortableServer and CORBA modules, and
     how PortableServer.POA and POAManager types fit in.
   * eliminated compiler warnings, including those horribly annoying
     "pasting would not give a valid pre-processing token" warnings with
     gcc 2.96
   * Made a d_warning macro that works the same way has d_message.  Used
     G_STMT_START and G_STMT_END so that these macros can have
     conditionals and still work.

2001-01-28  Roland Mas  <ma...@ec...>

   * Added test_list to test suite, as a test-case for the sequence
     demarshalling bug.


I'd like to work towards a 0.2.0 sometime soon.  'course, I've been
saying that for months now. :)  I'll probably turn my attention to the
threading issues.  After looking at Jade's distutils submission, I think
we might include it, since it supports some handy features.  I'm not
sure if I want to ditch gnu auto* yet, though.  I'm open to discussion.

Anyway, please report any bugs that you run into with the CVS version.
Working code to reproduce the bug is also invaluable.  I'd love to see a
stable 0.2.0 release in Feburary. :)

Jason.

Re: [Orbit-python-list] Latest CVS updates

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

Jason Tackaberry (2001-01-28 00:00:52 -0500) :

>    * Made a d_warning macro that works the same way has d_message.  Used
>      G_STMT_START and G_STMT_END so that these macros can have
>      conditionals and still work.

[...]

> Anyway, please report any bugs that you run into with the CVS
> version.

gcc -DPACKAGE=\"orbit-python\" -DVERSION=\"0.1.3\"  -I. -I.  -I/usr/include/python1.5 -I/usr/include/python1.5 -fPIC -g -O2 -I/usr/lib/glib/include -I/usr/include    -g -O2 -c idl.c
gcc: Internal compiler error: program cpp0 got fatal signal 11

  I was told that was a problem with my processor, so I aired it a
bit, and dusted it too.  Same problem.  Also happens with my laptop,
with different versions of gcc (2.95.3, 2.91, 2.7.2), and on a Red Hat
system, and basically I think the d_* macros have something to do with
it.  If I find that reverting to g_* macros fixes the problem, I'll
come back to you with a patch and an evil grin :-)

Roland.
-- 
Roland Mas

Sauvez un arbre, tuez un castor.

Re: [Orbit-python-list] Latest CVS updates

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

> gcc: Internal compiler error: program cpp0 got fatal signal 11
[...]
> it.  If I find that reverting to g_* macros fixes the problem, I'll
> come back to you with a patch and an evil grin :-)

Oh, this just figures.  Well I'll guess I'll try it out on my RH 6.1
box.  It works fine with RH7 (gcc 2.96).

Jason.

Re: [Orbit-python-list] Latest CVS updates

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

> system, and basically I think the d_* macros have something to do with
> it.  If I find that reverting to g_* macros fixes the problem, I'll
> come back to you with a patch and an evil grin :-)

The problem _is_ with the d_* macros, and my attempt to make gcc 2.96
stop barking about the "pasting would not give a valid pre-processing
token" crap.

Basically, when you do something like:

   #define d_message(f, a...) g_message(f, ##a)

gcc 2.96 complains, and instead wants to see this:

   #define d_message(f, a...) g_message(f, #a)

Sadly, this is what is segfaulting non 2.96 versions.  Anyway, I
reverted the macros to use the former syntax which won't cause other
versions of gcc to segfault, but it does bring back those damned
annoying warnings.  I'd love to avoid #ifdef'ing my way around this so
if anyone has any ideas, let me know. :)  

Jason.