orbit-python-list

[Orbit-python-list] Exiting Corba Server app

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

Hi, sorry for the crosspost but perhaps someone on the main list knows
something I don't.

I now wonder what's the proper way to shut down a corba application
server? I'm using orbit-python, and I've noticed the following problem:

I can't kill my server gracefully. I can't shut down my database
connections, and I can't flush my files. Why?

a) I can exit using Ctrl-\ or Ctrl-Z + kill %. This works, but since I
can't catch signals inside my corba app, it isn't a graceful exit and
everything is left pending. I understand daemons are supposed to be killed
with signals, but orbit-python won't let me do it unless I hack the source
code unconventionally.

b) I could exit by receiving a corba request. However, orbit won't shut
down when processing a client request (or it does, but breaks the
marshalling). Ok, so I can close files and connections and just break, but
it's a bit ugly, no?

c) I guess I could receive a request and set an alarm.. but wait, I can't
handle signals. Jeez.

Any help?

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

[Orbit-python-list] Re: Changes in marshalling code between 0.5.3 and 0.5.6?

[Owen T. <ot...@re...>]

Roland Mas <ma...@ec...> writes:

> Roland Mas (2001-01-26 23:02:51 +0100) :
>=20
> >   As a developer for ORBit-Python, a Python binding for ORBit, I'm
> > encountering a problem.  You could even call that a bug, but I'm not
> > casting the blame to anyone (yet >:-] ).
>=20
>   Well, after a bit of hacking, it appears that given a
> GIOPRecvBuffer=A0*buf, the attribute
> GIOP_MESSAGE_BUFFER(buf)->message_header.message_size is too small by
> twelve bytes.  "Coincidentally", twelve is sizeof(GIOPMessageHeader)
> too.
>=20
>   So, we patched ORBit-Python to add this sizeof() to the message_size
> when checking for availability of bytes in the buffer, but it still
> feels uncomfortable.  So I'd like a confirmation that what we did was
> The Right Thing, and not a dirty hack to fix a broken behaviour in
> ORBit.  Should this be a broken behaviour, please keep me informed
> when it is fixed, so that we can clean the hack.

Well, to shed a little more light on the issue, the root cause
of the problem was Elliot's change of Nov 9:

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
revision 1.117.4.3
date: 2000/11/09 20:14:05;  author: sopwith;  state: Exp;  lines: +10 -11

src/IIOP/giop-msg-buffer.c: Avoid a memory corruption problem on the Alpha =
by doing
some magic voodoo that makes the symptoms go away. No clue what the actual =
cause is.

diff -u -r1.117.4.2 -r1.117.4.4
--- giop-msg-buffer.c   2000/10/27 19:40:52     1.117.4.2
+++ giop-msg-buffer.c   2000/11/15 02:10:36     1.117.4.4
@@ -56,6 +56,8 @@
   GIOP_octet flags;
 } PACKED;
=20
+#include <stdlib.h>
+
 /* functions */
 static gint giop_recv_decode_message(GIOPRecvBuffer *buf);
 static gboolean num_on_list(GIOP_unsigned_long num,
@@ -754,13 +756,11 @@
   if (buffer =3D=3D NULL)
     return;
=20
-  if(buffer->message_body) {
-    buffer->message_body =3D ((guchar *)buffer->message_body)
-      - sizeof(GIOPMessageHeader);
-=20=20=20=20
-    g_free(buffer->message_body);
-    buffer->message_body =3D NULL;
-  }
+  if(buffer->message_body)
+    {
+      g_free(buffer->message_body);
+      buffer->message_body =3D NULL;
+    }
=20
   if(GIOP_MESSAGE_BUFFER(buffer)->connection->incoming_msg =3D=3D buffer)
     GIOP_MESSAGE_BUFFER(buffer)->connection->incoming_msg =3D NULL;
@@ -888,11 +888,10 @@
          goto errout;
        }
=20
-       retval->message_body =3D g_malloc(message_size+sizeof(GIOPMessageHe=
ader));
+       retval->message_body =3D g_malloc(message_size+sizeof(GIOPMessageHe=
ader)+4);
        /* XXX1 This is a lame hack to work with the fact that
           alignment is relative to the MessageHeader, not the RequestHeade=
r */
-       retval->message_body =3D ((guchar *)retval->message_body) + sizeof(=
GIOPMessageHeader);
-       retval->cur =3D retval->message_body;
+       retval->cur =3D retval->message_body + 12;
        retval->state =3D GIOP_MSG_READING_BODY;
        retval->left_to_read =3D message_size;
        break;
@@ -1131,7 +1130,7 @@
 if(!( (( ((guchar*)GIOP_RECV_BUFFER(buf)->cur) \
                        + (requested_increment) ) \
                       <=3D ( ((guchar *)GIOP_RECV_BUFFER(buf)->message_bod=
y) \
-                          + GIOP_MESSAGE_BUFFER(buf)->message_header.messa=
ge_size)) \
+                          + GIOP_MESSAGE_BUFFER(buf)->message_header.messa=
ge_size) + 12) \
                      && ( ( ((guchar*)GIOP_RECV_BUFFER(buf)->cur) \
                            + (requested_increment) ) \
                          >=3D ((guchar*)GIOP_RECV_BUFFER(buf)->cur) ))) go=
to out
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

This is indeed magic voodoo, and I don't think changing the interpretation
of retval->message_body was necessary -- the reason why I don't think
it is necessary, is that the only places that used it were the
places that broke: orbit-perl, orbit-python, and ORBit. Yes, ORBit is
currently broken. (See code below)

The two possibilities of things that might have actually been fixed here
were:

1) Allocating message_body bigger (though that could only have covered
   up bugs elsewhere.)

2) Not counting on sizeof(GIOPMessageHeader) =3D=3D 12. Though if that were=
n't
   the case, the breakage would not be subtle.

Though perhaps changing message_body back is worse than the just leaving it
as it is now.

=3D=3D=3D=3D=3D=3D=3D
void ORBit_decode_CORBA_TypeCode(CORBA_TypeCode* t, GIOPRecvBuffer* buf)
{
        CDR_Codec codec_d;
        CDR_Codec* codec =3D &codec_d;
        TCDecodeContext ctx;
        GSList* l;

        CDR_codec_init_static(codec);
        codec->buffer=3Dbuf->cur;
        codec->release_buffer=3DCORBA_FALSE;
        codec->readonly=3DCORBA_TRUE;
        codec->buf_len =3D                /* hope this is correct */
          ((guchar *)buf->message_body) +
          GIOP_MESSAGE_BUFFER(buf)->message_header.message_size
          - ((guchar *)buf->cur);
=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20
        codec->data_endian=3DGIOP_MESSAGE_BUFFER(buf)->message_header.flags=
 & 1;

        ctx.current_idx=3D0;
        ctx.prior_tcs=3DNULL;
        tc_dec(t, codec, &ctx);
        for(l=3Dctx.prior_tcs;l;l=3Dl->next)
                g_free(l->data);
        g_slist_free(ctx.prior_tcs);
        buf->cur =3D ((guchar *)buf->cur) + codec->rptr;
}
=3D=3D=3D=3D=3D=3D

That hope is now pretty forlorn.

Regards,
                                        Owen

Re: [Orbit-python-list] [patch] make autogen.sh (automake really) work on Debian

[Sune K. <su...@in...>]

[ Jason Tackaberry ]
> > So, I set out to fix the problem, which resulted in the following patch.
> 
> I think the patch is good, but I'd like it if you could modify it so
> that if their automake is not patched, it asks them if they want to
> patch it, instead of automatically doing it for them. Mention that
> the configure script already exists and they don't really need to use
> autogen.sh if they don't want to patch automake.

It now suggests that they use the included configure script, unless they
really need to regenerate configure and the Makefile.in's.  It's just a
simple "Press CTRL-C to cancel, enter to really do it"-style warning.

Also, about checking that it can actually patch automake, since what it
actually does is to create a patched copy (in ./automake+python), and
use the included macro-files, there's not much need to check it can do
so.  I know it's not the optimal solution, but I like it a lot better
than having to run autogen.sh as root, or some equivalent solution.

Oh, and it also fixes a buglet in autogen.sh, where the second time
you ran autogen.sh, on a system w/o Python support in the global
automake, it would forget to include the local macro-files.

> Otherwise it looks good, and I'll merge it in.

Nice.

-- 
Sune Kirkeby                    | Please forgive me if, in the heat of battle,
http://mel.interspace.dk/~sune/ | I sometimes forget which side I'm on.

Re: [Orbit-python-list] orbit-python and __setattr__ overloading

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

> I couldn't update, but checkout worked properly. Got the patch, will try
> it out.

How bizarre.  Well if it checked out okay, you won't need to apply the
patch (since I was able to commit it fine).

Jason.

Re: [Orbit-python-list] orbit-python and __setattr__ overloading

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

I couldn't update, but checkout worked properly. Got the patch, will try
it out.

On Tue, 30 Jan 2001, Jason Tackaberry wrote:

> > was to overload the _set_'s and _get_'s instead of __setattr__ so I don't
> > have to check if the attributes being changed are critical to the
> > persistency or not. I just override the correct arguments.
> 
> That said, __setattr__ and __getattr__ *should* be handled properly
> anyway, so I've committed an update for this.
> 
> Unfortunately, SourceForge's anoncvs server is being weird right now (is
> it broken for anyone else too?), so I've attached the patch to this
> email (patches server.c).
> 
> Jason.
> 

Marcelo Corbani de Barros                   co...@as...
Async Open Source Development - Brasil

Re: [Orbit-python-list] orbit-python and __setattr__ overloading

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

> was to overload the _set_'s and _get_'s instead of __setattr__ so I don't
> have to check if the attributes being changed are critical to the
> persistency or not. I just override the correct arguments.

That said, __setattr__ and __getattr__ *should* be handled properly
anyway, so I've committed an update for this.

Unfortunately, SourceForge's anoncvs server is being weird right now (is
it broken for anyone else too?), so I've attached the patch to this
email (patches server.c).

Jason.

Re: [Orbit-python-list] orbit-python and __setattr__ overloading

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

Hi Jason,

You're right, after Roland's post I realized that the right thing to do
was to overload the _set_'s and _get_'s instead of __setattr__ so I don't
have to check if the attributes being changed are critical to the
persistency or not. I just override the correct arguments.

thanks.

On Tue, 30 Jan 2001, Jason Tackaberry wrote:

> > Hi,
> 
> Hi Marcelo,
> 
> > is it possible that orbit-python would set the attribites through
> > __setattr__ the way I though so  could overload it ?
> 
> Keep in mind that ORBit-Python's transparent handling of attributes is
> not really part of the mapping spec, and there are some good reasons to
> avoid using them (such as explicitness).  I personally like the idea of
> transparency, though.
> 
> At the moment, ORBit-Python won't call the servant's __setattr__ and
> __getattr__ functions on invocation of one of the attribute accessor
> functions.  It obviously should.  I expect that's an easy thing to fix,
> so I'll do that right now.  (Stay tuned.)
> 
> As an alternative, you could override the accessor function, which is
> what you're supposed to do anyway (if you want to be compliant with the
> mapping spec).  So for example:
> 
> interface Foo {
>    attribute string mystr;
> };
> 
> Then in the implementation:
> 
> class Foo_Impl(Global__POA.Foo):
>    def _set_mystr(self, val):
>       print "Setting mystr attribute"
>       self.mystr = val
> 
>    def _get_mystr(self):
>       print "Getting mystr attribute"
>       return self.mystr
> 
> Anyway, I'll commit a fix for ORBit-Python to call __setattr__ and
> __getattr__ for the servant in the absence of an implemented accessor
> function.
> 
> Cheers,
> Jason.
> 
> _______________________________________________
> Orbit-python-list mailing list
> Orb...@li...
> http://lists.sourceforge.net/lists/listinfo/orbit-python-list
> 

Marcelo Corbani de Barros                   co...@as...
Async Open Source Development - Brasil

Re: [Orbit-python-list] orbit-python and __setattr__ overloading

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

thanks, it just worked as expected!

_set_<attribname>



On 30 Jan 2001, Roland Mas wrote:

> Marcelo CB (2001-01-30 16:43:29 -0200) :
>=20
> > I was wondering if this is an expected behaviour, mostly because I
> > would like to overload __setattr__ to know when an attribute was
> > changed. I need this to control the persistency state of the class.
>=20
>   I think I coded that sometime last summer.  You just have to use the
> correct method names, namely _get_<attributename> and
> _set_<attributename>.
>=20
> Roland.
> --=20
> Roland Mas
>=20
> C r  ' s  d   a  u    e   e    ll r   a  u i r . =20
>   -- Signatures =E0 collectionner, s=E9rie n=B01, partie 1/3.
>=20
> _______________________________________________
> Orbit-python-list mailing list
> Orb...@li...
> http://lists.sourceforge.net/lists/listinfo/orbit-python-list
>=20

Marcelo Corbani de Barros                   co...@as...
Async Open Source Development - Brasil

Re: [Orbit-python-list] orbit-python and __setattr__ overloading

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

> Hi,

Hi Marcelo,

> is it possible that orbit-python would set the attribites through
> __setattr__ the way I though so  could overload it ?

Keep in mind that ORBit-Python's transparent handling of attributes is
not really part of the mapping spec, and there are some good reasons to
avoid using them (such as explicitness).  I personally like the idea of
transparency, though.

At the moment, ORBit-Python won't call the servant's __setattr__ and
__getattr__ functions on invocation of one of the attribute accessor
functions.  It obviously should.  I expect that's an easy thing to fix,
so I'll do that right now.  (Stay tuned.)

As an alternative, you could override the accessor function, which is
what you're supposed to do anyway (if you want to be compliant with the
mapping spec).  So for example:

interface Foo {
   attribute string mystr;
};

Then in the implementation:

class Foo_Impl(Global__POA.Foo):
   def _set_mystr(self, val):
      print "Setting mystr attribute"
      self.mystr = val

   def _get_mystr(self):
      print "Getting mystr attribute"
      return self.mystr

Anyway, I'll commit a fix for ORBit-Python to call __setattr__ and
__getattr__ for the servant in the absence of an implemented accessor
function.

Cheers,
Jason.

Re: [Orbit-python-list] orbit-python and __setattr__ overloading

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

Marcelo CB (2001-01-30 16:43:29 -0200) :

> I was wondering if this is an expected behaviour, mostly because I
> would like to overload __setattr__ to know when an attribute was
> changed. I need this to control the persistency state of the class.

  I think I coded that sometime last summer.  You just have to use the
correct method names, namely _get_<attributename> and
_set_<attributename>.

Roland.
-- 
Roland Mas

C r  ' s  d   a  u    e   e    ll r   a  u i r .  
  -- Signatures à collectionner, série n°1, partie 1/3.

[Orbit-python-list] orbit-python and __setattr__ overloading

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

Hi,

I noticed that when overloading __setattr__ for ORBit classes, I wont get
the attributes handled by orbit-python, what means it handles the class
__dict__ directly at server side, right ? 

I was wondering if this is an expected behaviour, mostly because I would
like to overload __setattr__ to know when an attribute was changed. I need
this to control the persistency state of the class.

one workaround I can think of ( and I am actually using it ) is to
implement myself methods to set each attribute (setAttrib1, setAttrib2, or
set_attrib1, set__attrib2), and then take whatever action I would
like before setting the attribute.

I could also use a 'set' method, so I would do set('attrib','value'), but
none of this would be as elegant as overloading __setattr__ and catching
attribute changes transparently.

Am I crazy, or blind, not to see a better option ?

is it possible that orbit-python would set the attribites through
__setattr__ the way I though so  could overload it ?

sorry for the long msg, and thanks.


-------------------------------------------------------------------
Marcelo Corbani de Barros                   co...@as...
Async Open Source Development - Brasil

Re: [Orbit-python-list] [patch] make autogen.sh (automake really) work on Debian

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

> I think the patch is good, but I'd like it if you could modify it so
> that if their automake is not patched, it asks them if they want to

Additionally, it ought to check that you have sufficient privileges to
do this, and fail gracefully otherwise.

Jason.

Re: [Orbit-python-list] [patch] make autogen.sh (automake really) work on Debian

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

> This was due to (1) the lack of configure and friends in the CVS tree
> (they seem to have appeared in the meanwhile, yay!), and (2) autogen.sh

Yeah, Roland suggested we include that stuff for people who don't want
to patch automake.

> So, I set out to fix the problem, which resulted in the following patch.

I think the patch is good, but I'd like it if you could modify it so
that if their automake is not patched, it asks them if they want to
patch it, instead of automatically doing it for them.  Mention that the
configure script already exists and they don't really need to use
autogen.sh if they don't want to patch automake.

Otherwise it looks good, and I'll merge it in.

Cheers,
Jason.

[Orbit-python-list] [patch] make autogen.sh (automake really) work on Debian

[Sune K. <su...@in...>]

Hi all,

A few days ago I co'ed the CVS-tree, and to my dismay discovered that it
was quite uncompilable on my Debian box (a somewhat outdated unstable is
installed here).

This was due to (1) the lack of configure and friends in the CVS tree
(they seem to have appeared in the meanwhile, yay!), and (2) autogen.sh
being borken with the Debian automake (version 1.4, unpatched I think).
So, I set out to fix the problem, which resulted in the following patch.

The patch makes orbit-python compilable on my Debian box, by looking
inside automake to see if it contains the string "handle_python", and
if not create a patched automake in the build directory (and instructing
aclocal to look in the python-am-changes directory).

This might not be the finest of solutions, but for me it sure beats
not being able to compile other than by hand :-).

Regards,

P.S.  I copied the patch in below my signature, verbatim, it's something
like 60 lines long, so I though that would be best.  Please say if you
prefer it otherwise, even for small patches such as this.

P.P.S.  I changed the automake download-URL, since ftp.gnu.org is it's
home AFAIK, and there was only a 1.2d (or 1.3d, can't remember) at the
old URL.

-- 
Sune Kirkeby                    | Please forgive me if, in the heat of battle,
http://mel.interspace.dk/~sune/ | I sometimes forget which side I'm on.


--- Makefile.am.orig	Mon Jan 29 20:37:51 2001
+++ Makefile.am	Mon Jan 29 20:43:47 2001
@@ -1 +1,2 @@
-SUBDIRS=src
\ No newline at end of file
+SUBDIRS=src
+DISTCLEANFILES=automake+python
--- autogen.sh.orig	Sat Jan 27 18:10:47 2001
+++ autogen.sh	Mon Jan 29 20:42:22 2001
@@ -22,11 +22,38 @@
 (automake --version) < /dev/null > /dev/null 2>&1 || {
 	echo
 	echo "You must have automake installed to compile orbit-python."
-	echo "Get ftp://ftp.cygnus.com/pub/home/tromey/automake-1.2d.tar.gz"
-	echo "(or a newer version if it is available)"
+	echo "Get ftp://ftp.gnu.org/gnu/automake/automake-1.4.tar.gz"
 	DIE=1
 }
 
+# This is a very ugly hack, it might even be better to distribute our
+# own automake, but. . .  nah.  -sune
+if [ -f automake+python ] ; then
+    AUTOMAKE="./automake+python"
+else
+    AUTOMAKE=`which automake`
+fi
+if ! grep -q handle_python $AUTOMAKE ; then
+        echo "Creating patched copy of automake with Python-support."
+        cp $AUTOMAKE automake+python || exit 1
+        AUTOMAKE="./automake+python"
+
+        if $AUTOMAKE --version | grep -q 1.3 ; then
+                PATCH=python-am-changes/automake-1.3.diff
+        elif $AUTOMAKE --version | grep -q 1.4 ; then
+                PATCH=python-am-changes/automake-1.4.diff
+        else
+                echo "Warning: This automake is not version 1.3 or 1.4,"
+                echo "I'll try patching it anyway.  Wish me luck."
+                PATCH=python-am-changes/automake-1.4.diff
+        fi
+
+        if ! patch $AUTOMAKE < $PATCH ; then
+                echo "Error: It failed, bailing out."
+                DIE=1
+        fi
+fi
+
 if test "$DIE" -eq 1; then
 	exit 1
 fi
@@ -41,8 +68,8 @@
   echo processing $i
   (cd $i; \
     libtoolize --copy --force; \
-    aclocal $ACLOCAL_FLAGS; autoheader; \
-    automake --add-missing; \
+    aclocal -I python-am-changes $ACLOCAL_FLAGS; autoheader; \
+    $AUTOMAKE --add-missing; \
     autoheader; \
     autoconf)
 done

[Orbit-python-list] Re: Distutils submission

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

On Sun, Jan 28, 2001 at 05:40:21PM -0500, Jason Tackaberry wrote:
> Hi Jade.  I noticed that with your setup.py, passing bdist_rpm fails,
> presumably because it isn't copying the header files necessary to build
> ORBit-Python.  Any ideas how to fix that?

Yes, like I said the first script I submitted was just a quick hack (I wanted to see if you were interested first :)  I have fixed that problem, plus made a few minor changes to the setup.py file.   You will need two additional files to make RPMs build properly and they are attached here along with my changes to setup.py.  Please let me know if you have any more problems as I will be glad to fix them.

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

[Orbit-python-list] Distutils submission

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

Hi Jade.  I noticed that with your setup.py, passing bdist_rpm fails,
presumably because it isn't copying the header files necessary to build
ORBit-Python.  Any ideas how to fix that?

Cheers,
Jason.

[Orbit-python-list] Re: Changes in marshalling code between 0.5.3 and 0.5.6?

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

>   Well, after a bit of hacking, it appears that given a
> GIOPRecvBuffer *buf, the attribute
> GIOP_MESSAGE_BUFFER(buf)->message_header.message_size is too small by
> twelve bytes.  "Coincidentally", twelve is sizeof(GIOPMessageHeader)
> too.

that sounds likely to me, from what I could see..   anyway, the latest code in
CVS fixes a bug in the (de)marshalling code, so it would be a good idea to grab
that, and see if it works for you, as well.  It has solved the segfault problem
I was having, anyway.

[Orbit-python-list] Re: Changes in marshalling code between 0.5.3 and 0.5.6?

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

Roland Mas (2001-01-26 23:02:51 +0100) :

>   As a developer for ORBit-Python, a Python binding for ORBit, I'm
> encountering a problem.  You could even call that a bug, but I'm not
> casting the blame to anyone (yet >:-] ).

  Well, after a bit of hacking, it appears that given a
GIOPRecvBuffer *buf, the attribute
GIOP_MESSAGE_BUFFER(buf)->message_header.message_size is too small by
twelve bytes.  "Coincidentally", twelve is sizeof(GIOPMessageHeader)
too.

  So, we patched ORBit-Python to add this sizeof() to the message_size
when checking for availability of bytes in the buffer, but it still
feels uncomfortable.  So I'd like a confirmation that what we did was
The Right Thing, and not a dirty hack to fix a broken behaviour in
ORBit.  Should this be a broken behaviour, please keep me informed
when it is fixed, so that we can clean the hack.

  Have a nice day,
Roland.
-- 
Roland Mas

Depuis 1977.

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.

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

[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] the never ending segfault.. (possible fix)

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

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

The latest commits ought to take care of this.  Beat on it and let me know
if it's all good.

Thanks,
Jason.

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

[Orbit-python-list] Changes in marshalling code between 0.5.3 and 0.5.6?

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

  Hello people,

[Cc: to the ORBit-Python developers list]

  As a developer for ORBit-Python, a Python binding for ORBit, I'm
encountering a problem.  You could even call that a bug, but I'm not
casting the blame to anyone (yet >:-] ).

  Basically, I get warnings like
** WARNING **: incomplete message received
in my client, which results in a segmentation fault in the client.
The server seems to run OK (no segfault).

  But, where this becomes interesting is that this behaviour appears
with ORBit 0.5.6, I seem to remember it also did with 0.5.5, and it
does not happen with 0.5.3 (I kept that one because I knew it worked).
Compile and run with 0.5.3 OK, compile and run with 0.5.6 -> segfault.
The same ORBit-Python source, the same test case.

  The test-case is the following:

typedef sequence<long> seq ;
interface Instance {
[...]
  seq gimme_list ();
};

  The test server picks a random number n, say n=4, and returns the
sequence (0, 1, 2, 3).  When n=0 (empty list), the call returns OK,
result is an empty list as expected.  When n=1 (list with only one
element, the long 0), the call returns OK, the result is the list
containing one element, that is 0, as expected.  When n>1, shit
happens with 0.5.6, not with 0.5.3.

  Let's change seq to be a sequence<short>.  The limit is now 3: n<=3
OK, n>3 NOK.  long long?  n=0 OK, n>0 NOK.  float?  n<=1 OK, n>1 NOK.
For strings, the problem seems a bit different, and the limit depends
on the length of the strings that the server returns.

  So, I'd be interested in knowing what changes were made in the
marshalling code.  What I'd love most of all would be someone standing
up and saying "Yea, I plead guilty, silly bug, here's the two-line
patch to ORBit", but I won't hold my breath for it.  The size
limitation induces me into thinking that there's some buffer size
problem somewhere...  I will once again review the marshalling code in
ORBit-Python, but I'd be inclined to think it is correct (after all,
it works with an older ORBit, doesn't it?).

  Thanks for your attention,

Roland.
-- 
Roland Mas

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

[Orbit-python-list] ORBit Object repository ID

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

On Fri, 26 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.
> 
> 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.

Eliott, anyone..? cares to comment as to why we're using "" for repository
id for CORBA/Object types? Or is something getting lost along the way?

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