orbitcpp-list

[orbitcpp-list] Two IDLN enumerations for Any, which one to use

[Gordon M. <gm...@bi...>]

I've written an extension to the pyIDL to add an IDLTypeAny object and
I've also written a test for it.  While writing the test, I discovered
that IDL.h defines two enumerations for Any's IDLN_ANY and
IDLN_TYPE_ANY.  Does anyone know the difference?  Which one should I be
using?  I'm currently using IDLN_TYPE_ANY.

I'm attaching a diff that was done in the pyIDL directory with my
changes.  These should include changes to src/pyIDL, src/test.py,
tests/any.idl, tests/any.py

Re: [orbitcpp-list] Support for any in pyIDL

[Phil D. <ph...@or...>]

Gordon Miller wrote:
> 
> Hello,
> 
> I've been a lurker here for a few weeks and have been toying with the
> Orbit-C++ code for a few versions now.  I am a very experienced C++ and
> Python programmer (8 years C++ and 5 or so for python) and have been
> doing CORBA for about 5 years now though the previous 2 have been using
> Java.  I am very interested in helping out the C++ binding effort that
> you guys have started.  My immediate goals are to work with the ORBIT
> event service, but I much prefer writing C++ so I'd like to help this
> effort out as much as possible.

Cool - we could certainly do with the help!

> I'm currently trying to compile the CosEventComm.idl that has any's as
> arguments to some of the methods.  It's choking on the any's in the
> tree_factory method of pyIdl.py  The nodetype is 29 which, of course, is
> the IDLN_TYPE_ANY.  I did a clean checkout of the source this morning
> from gnome so I'm pretty sure I have the latest source.
> 
> In the ORBit-C++ web page, Phil gives some guidelines for dealing with
> new types.  Is this something that I should go ahead and work on or
> not?
> 

Please do! I'm currently working on sequences, and Ron I think is
having problems with segfaults on solaris (did you manage to get any
further Ron? I haven't had the solaris box back to try yet), and
judging from the ORBit list has been working on that too. I don't
think you'd be stepping on anybody's toes.

The text is a bit out of date on the web page (must fix that!). Rather 
than bothering with the templates directory stuff, just hack what you
need to. The templates directory was there so that people could work
on things while the idl compiler was in a state of flux (and also
because lots of people don't know python) - both of those aren't
issues now.

I think your best bet would be to start with adding ANY support to
pyIDL. I've just written some text in HACKING files in the pyIDL/src
and pyIDL/test directories which should help you get started. I'm
afraid that means you'll need to do another cvs update.

After that, I usually create a new test in the test directory, and use
that as a basis to build the IDL compiler (I'm quite a fan of coding
through a test harness - you might have noticed ;-).


> Thanks and I'm looking forward to being able to contribute, even if
> nothing more than documentation.

I look forward your conributions!

Cheers,

Phil.

BTW, do you already have gnome cvs write access? If not, in the short
term I prefer unified diff style patches. (cvs diff -u or something
like that).

[orbitcpp-list] Support for any in pyIDL

[Gordon M. <gm...@bi...>]

Hello,

I've been a lurker here for a few weeks and have been toying with the
Orbit-C++ code for a few versions now.  I am a very experienced C++ and
Python programmer (8 years C++ and 5 or so for python) and have been
doing CORBA for about 5 years now though the previous 2 have been using
Java.  I am very interested in helping out the C++ binding effort that
you guys have started.  My immediate goals are to work with the ORBIT
event service, but I much prefer writing C++ so I'd like to help this
effort out as much as possible.

I'm currently trying to compile the CosEventComm.idl that has any's as
arguments to some of the methods.  It's choking on the any's in the
tree_factory method of pyIdl.py  The nodetype is 29 which, of course, is
the IDLN_TYPE_ANY.  I did a clean checkout of the source this morning
from gnome so I'm pretty sure I have the latest source.  

In the ORBit-C++ web page, Phil gives some guidelines for dealing with
new types.  Is this something that I should go ahead and work on or
not?  

Thanks and I'm looking forward to being able to contribute, even if
nothing more than documentation.

Gordon Miller

Re: [orbitcpp-list] CORBA and C++ exceptions

[Phil D. <ph...@li...>]

Petter Reinholdtsen wrote:
> 
> [Phil Dawes]
> > Thanks for the patch, but unfortunately it doesn't compile!
> 
> Yes, I noticed that as well when I testcompiled it.  It was a quick
> and dirty version to see how such change would be received.  The
> exception part works, but the 'operator<<' needs more work.
> 
> > Normally I'm not keen on adding extra functionality to ORBit-C++
> > over and above what is in the spec, however in Henning&Vinoski's
> > book* they state that an ostream operator for Exceptions is likely
> > to be in future revisions of the spec anyway, so I'd be happy to
> > accept a working patch for providing this.
> 
> My problem is that I do not have the spec, nor a good description on
> how CORBA should work in C++.  Do you know of such online
> documentation?
> 

You should be able to get the C++ language mapping spec on 
http://www.omg.org/library/clangindx.html

> > Some other comments:
> 
> > Make sure that the standard C++ stuff is prefixed with std:: to
> > remain ansi compliant (I don't think g++ checks for this unless you
> > give it the right cmd line args)
> 
> Sounds reasonable.  What is the cmd line args?
> 

Don't know off hand - It'll be in the gcc info files.

> > I'm don't think I'm keen on having CORBA::Exception inherit from
> > std::exception. It's not in the spec, and thus it would make
> > people's programs behave differently if they port from a compliant
> > ORB.
> 
> I do not follow you.  If the programs are programmed correctly, they
> will not be able to detect the difference.  If I'm not mistaken, the
> std::exception class was made to have a common exception class to
> inherit from.  Having such toplevel superclass makes a lot of things
> easier.

It means that people catching std::exception and handling it would also
catch CORBA::Exceptions, but this wouldn't happen with other CORBA
implementations (the exception would slip through and segfault). 

> 
> > Thanks again for making the effort to produce the patch; sorry if
> > this email sounded a bit critical - that wasn't the intention.
> 
> I enjoy getting comments on my suggested changes. :-)
> 

Cool!

Cheers,

Phil.

Re: [orbitcpp-list] CORBA and C++ exceptions

[Petter R. <pe...@hu...>]

[Phil Dawes]
> Thanks for the patch, but unfortunately it doesn't compile! 

Yes, I noticed that as well when I testcompiled it.  It was a quick
and dirty version to see how such change would be received.  The
exception part works, but the 'operator<<' needs more work.

> Normally I'm not keen on adding extra functionality to ORBit-C++
> over and above what is in the spec, however in Henning&Vinoski's
> book* they state that an ostream operator for Exceptions is likely
> to be in future revisions of the spec anyway, so I'd be happy to
> accept a working patch for providing this.

My problem is that I do not have the spec, nor a good description on
how CORBA should work in C++.  Do you know of such online
documentation?

> Some other comments:

> Make sure that the standard C++ stuff is prefixed with std:: to
> remain ansi compliant (I don't think g++ checks for this unless you
> give it the right cmd line args)

Sounds reasonable.  What is the cmd line args?

> I'm don't think I'm keen on having CORBA::Exception inherit from
> std::exception. It's not in the spec, and thus it would make
> people's programs behave differently if they port from a compliant
> ORB.

I do not follow you.  If the programs are programmed correctly, they
will not be able to detect the difference.  If I'm not mistaken, the
std::exception class was made to have a common exception class to
inherit from.  Having such toplevel superclass makes a lot of things
easier.

> Thanks again for making the effort to produce the patch; sorry if
> this email sounded a bit critical - that wasn't the intention.

I enjoy getting comments on my suggested changes. :-)

> If you come up with a good ostream operator scheme, I'd be happy to
> update the compiler so that UserExceptions use it as well.

I'll have another look when I find time.  The suggested patch gave me
debug information unavailable with your current implementation and
will probably stay in my copy for time to come. :-)
-- 
##>  Petter Reinholdtsen  <##  |  pe...@td...

Re: [orbitcpp-list] CORBA and C++ exceptions

[Phil D. <ph...@so...>]

Hi Petter,

[... patch snipped ...]

Thanks for the patch, but unfortunately it doesn't compile! 

Normally I'm not keen on adding extra functionality to ORBit-C++ over
and above what is in the spec, however in Henning&Vinoski's book* they
state that an ostream operator for Exceptions is likely to be in future
revisions of the spec anyway, so I'd be happy to accept a working patch
for providing this.

Some other comments:

Make sure that the standard C++ stuff is prefixed with std:: to remain
ansi compliant (I don't think g++ checks for this unless you give it the
right cmd line args)

I'm don't think I'm keen on having CORBA::Exception inherit from
std::exception. It's not in the spec, and thus it would make people's
programs behave differently if they port from a compliant ORB.

Following on from the above, the what() function isn't part of the CORBA
spec either, so I'd prefer if it was made private - you could then make
the operator<<() a friend.


Thanks again for making the effort to produce the patch; sorry if this
email sounded a bit critical - that wasn't the intention. If you come up
with a good ostream operator scheme, I'd be happy to update the compiler
so that UserExceptions use it as well.

Cheers,

Phil.


* 'Advanced Corba Programming with C++' Henning&Vinoski

[orbitcpp-list] CORBA and C++ exceptions

[Petter R. <pe...@hu...>]

Here is a small patch to implement the exception changes I suggested
earlier.  They are untested, but I belive this should work.

This would make it possible to print the exception type to discover
more on what went wrong.  It also makes it possible to only check for
superclass exception in the top level 'catch' statement.

I'll test it this evening, but I thought I should ask if you think
this is a good idea.

diff -ur orbitcpp-0.24.1/orb/Exception.hh orbitcpp-0.24.1-pere/orb/Exception.hh
--- orbitcpp-0.24.1/orb/Exception.hh	Thu Sep  9 03:34:16 1999
+++ orbitcpp-0.24.1-pere/orb/Exception.hh	Tue Jan 11 16:50:30 2000
@@ -37,15 +37,17 @@
 #define _ORBIT_CPP_EXCEPTION_HH
 
 #include <orb/BasicTypes.hh>
-
+#include <exception>
+#include <iostream>
 
 namespace CORBA
 {
 
-	class Exception {
+	class Exception : public exception {
 	public:
 		virtual ~Exception() {}
 		virtual void _raise() = 0;
+        virtual const char* what() const { return "CORBA::Exception"; }
 	protected:
 		Exception() {}
 	};
@@ -56,6 +58,7 @@
 	public:
 		virtual ~UserException();
 		static UserException* _narrow(Exception* e);
+        virtual const char* what() const { return "CORBA::UserException"; }
 	};
 
   
@@ -105,6 +108,8 @@
 
 		virtual const char * NP_RepositoryId() const { return ""; }
 
+        virtual const char* what() const { return "CORBA::SystemException"; }
+
 	protected:
 		ULong             pd_minor;
 		CompletionStatus  pd_status;
@@ -114,6 +119,7 @@
 class name : public SystemException {				\
 public:								\
 	name(ULong minor, CompletionStatus status) : SystemException(minor, status) {} \
+    virtual const char* what() const { return "CORBA::" #name; } \
 };  
 
 
@@ -148,6 +154,7 @@
 CPPSYSEXC (INVALID_TRANSACTION)
 CPPSYSEXC (INV_POLICY)
 
+	extern ostream& operator<<(ostream& out, CORBA::Exception e&);
 	
 };
 

diff -ur orbitcpp-0.24.1/orb/Exception.cc orbitcpp-0.24.1-pere/orb/Exception.cc
--- orbitcpp-0.24.1/orb/Exception.cc	Thu Feb 11 17:11:49 1999
+++ orbitcpp-0.24.1-pere/orb/Exception.cc	Tue Jan 11 16:52:30 2000
@@ -55,3 +55,9 @@
 
   return static_cast<SystemException*>(e);
 }
+
+ostream&
+operator<<(ostream& out, CORBA::Exception e&)
+{
+	out << e.what() << endl;
+}
-- 
##>  Petter Reinholdtsen <##    | pe...@td...
 O-  <SCRIPT Language="Javascript">window.close()</SCRIPT>
http://www.hungry.com/~pere/    | Go Mozilla, go! Go!

[orbitcpp-list] Release 0.24 is out!

[Phil D. <ph...@or...>]

Hi Folks,

I've just uploaded orbitcpp-0.24.tar.gz to sourceforge. You can get it
from the sourceforge ORBit-C++ project page - I haven't updated the
'official' orbitcpp web page yet.

http://www.sourceforge.net/project/?form_grp=646

This version fixes adds enum support, and fixes some bugs. 

Cheers,

Phil

[orbitcpp-list] Re: digging a deeper and deeper hole

[Ronald G. <rga...@ir...>]

Hey phil,

further research into the SUN segfault fiasco:

1) It has nothing to do with the GHashtable stuff for registering
StubFactories (I didn't expect it to, but I'm running out of
ideas...).

2) I compiled the integertest with Bruce Perens' Electric Fence...and
instead of finding a memory violation, the program decided to execute
without a hitch.  So apparently replacing the system malloc with
Electric Fence's malloc makes it work.  Now does this mean that there
is something wrong with the system malloc (which sounds pretty
unlikely to me), or is there some bug that is obscured by other malloc
implementations, or some altogether different problem? I'll keep
digging....

ron

[orbitcpp-list] Re: digging a deeper and deeper hole

[Ronald G. <rga...@ir...>]

hey phil,

As for the debugging, I can get examples to run fine from C with ORBit
(you may have  noticed my patches from yesterday...that was me
checking ORBit-C behavior...just a side effect of that).

I suspect that the cause is at the C++ level, not the C level, but I'm
not sure where.  If worst comes to worst, I'll probably unpack an old
version of the C++ bindings to see if I can roughly figure out where a
change may have broken something.  One point of note, the last sigbus
problem I had that was isolated to the Ultra system had to do with a
hashing thing for a glib hashtable (I remember you fixing that one for
me a while ago).  There may be a starting point...just a guess.

ron

[orbitcpp-list] Re: digging a deeper and deeper hole

[Phil D. <ph...@or...>]

Ronald Garcia wrote:
> 
> From: Ronald Garcia <rga...@pi...>
> 
> howdy all,
> 
>      did a little more delving into my bus error problems...things are
> getting just a touch out of control now.  I'm not quite sure if this
> is a compiler or an ORBit problem, but it's sure a problem...and in
> general I tend to assume it's not the compiler, but I digress...
> 
>      to review, the error happens in
>  PortableServer_POA_activate_object (poa.c:711)
> 
>      this is the line:
> 
> new_objid =  ORBit_POA_allocate_oid(obj,
>                 ORBIT_OBJECT_KEY(servant->_private)->class_info->class_name);
> 
> well, the problem seems to be the following:
> 'ORBIT_OBJECT_KEY(servant->_private)->class_info' gets set in
> POA_test_IntegerTest__init (integer-skels.c:225)
> 
>      this is the line:
> 
> ORBIT_OBJECT_KEY(((PortableServer_ServantBase *) servant)->
>   _private)->class_info = (PortableServer_ClassInfo *) & class_info;
> 
> class_info is a static object within the function.
> 
> it turns out that the value of servant->_private->class_info is
> getting changed before it is used in
> 'PortableServer_POA_activate_object'. Here's where things get scary.
> The following is a trace of where it happens:
> 
> (gdb) continue
> Continuing.
> Watchpoint 2: $2->class_info
> 
> Old value = (PortableServer_ClassInfo *) 0x217c0
> New value = (PortableServer_ClassInfo *) 0x217c1
> 0xef445b08 in _smalloc ()
> (gdb) backtrace
> #0  0xef445b08 in _smalloc ()
> #1  0xef445b38 in malloc ()
> #2  0xef4fb684 in __builtin_new (sz=16) at ./cp/new1.cc:84
> #3  0xef7757f8 in PortableServer::POA::POA (this=0x34850, o=0x38c30,
>     parent=0x0, release=true) at POA.cc:117
> #4  0xef7759b0 in PortableServer::POA::_duplicate (_obj=0x347b0) at POA.cc:152
> #5  0xef774448 in CORBA::ORB::resolve_initial_references (this=0x35b10,
> continue    str=0xef783830 "RootPOA") at ORB.cc:116
> #6  0xef775624 in PortableServer::ServantBase::_default_POA (this=0xefffef04)
>     at POA.cc:93
> #7  0x18320 in POA_test::IntegerTest::_this (this=0xefffeef8)
>     at integer-cpp-skels.cc:121
> #8  0x17668 in main (argc=1, argv=0xefffef9c) at server.cc:23
> (gdb) up
> 
> the line of consequence is in POA.cc:117, that being:
> _poaManager = new PortableServer::POAManager(pm);
> 
> at this point, i haven't the foggiest idea why '_smalloc' would modify
> one of my locations...anyone, anyone?
> 
> If I step through to PortableServer_POA_activate_object and class_info
> back to its old value, the program runs properly.
> 
> ron
> 



Hi Ron,

I didn't get very far debugging this. I did notice however that the
echo-server in the *orbit* tests directory works without sigbussing.
I've written a little orbitcpp equivalent of the echo server which works
on my linux box. Unfortunately I've had the solaris box taken away from
me now (sob) because they want to shut it down ready for the millenium.
(doh - no sense of priority etc...)

Get the tarball from

ftp://orbitcpp.sourceforge.net/pub/orbitcpp/echo.tgz

and unpack it in the ORBit-C++ tests directory. (I recommend you get a
new CVS fresh version of ORBit-C++)

then add the Makefile.ams to the configure.in so that you can cd to it
and build it.


This will probably sigbus in the same way, but I was hoping to be able
to tweak things so that it takes the same (working) approach as the
echo-server test in orbit.

\Good luck, and have a good xmas

Phil.

P.S. A brief look at the ORBit echo-server.c shows that it creates it's
own object id and uses that... Dunno if that makes a difference.

[orbitcpp-list] Re: Help

[Phil D. <ph...@or...>]

ch...@su... wrote:
> 
> It's seems that gcc have some problem,I found that the symbol __ashrdi3
> is in the library libgcc.a.But How to resolve it?
> Thank you very much
> 

Hi Chen,

Fixed it!

As you correctly observed, the symbol is in the gcc-lib (perhaps for
handling 64 bit types? i.e. CORBA::LongLong). You can link to it by
going to your ORBit/libIDL directory and linking it manually:

e.g.
ld -G -h libIDL-0.6.so.0 -o .libs/libIDL-0.6.so.0.4.4 parser.lo lexer.lo
ns.lo util.lo  -L~/lib -lglib -lc
~/lib/gcc-lib/sparc-sun-solaris2.5.1/2.95.2/libgcc.a

and then copy it into your install lib directory

cp .libs/libIDL-0.6.so.0.4.4 ~/lib


BTW, I had another link problem which was fixed by manually copying
orbit-config into the bin directory - for some reason it wasn't
installed properly. (make sure it is executable, since orbitcpp uses it
to determine the ORBit link variables)

Hope this works for you,

Phil

P.S., If you're likely to be using orbitcpp at all, I recommend you join
the new mailing list: 
http://lists.sourceforge.net/mailman/listinfo/orbitcpp-list
(This is different to the one that used to be advertised on the web
page)

P.P.S. If the test.sh script in the tests directory doesn't work, it's
because it tries to find /bin/bash. /bin/sh should work so change it to
that. - I'll update this for the next release

P.P.P.S. Now I seem to be getting a bus error running the integer test -
compiling up gdb now...!

[orbitcpp-list] Re: Help

[<ch...@su...>]

It's seems that gcc have some problem,I found that the symbol __ashrdi3
is in the library libgcc.a.But How to resolve it?
Thank you very much



On Thu, 23 Dec 1999, Phil Dawes wrote:

> 
> Chen Hao wrote:
> > 
> >     WHen I compile oribtcpp 0.22 in solaris 2.7,it's report:
> > ImportError: ld.so.1: python: fatal: relocation error:
> > file /export/home/chen/lib/libIDL-0.6.so.0: symbol __ashrdi3: referenced
> > symbol not found
> >   what's the matter?How to resolve it?
> > 
> > My platform: Solaris 2.7 ORBit 0.50 orbitcpp 0.22
> 
> 
> I've finally managed to get my hands on a solaris box to try and
> diagnose this problem. I get the same problem on an ultra1 (solaris 2.5)
> with everything built from source. Hmmmm....
> 
> Unfortunately I've only got the machine for today, so I'll see what I
> can do.
> 
> Cheers,
> 
> Phil.
> 

[orbitcpp-list] Re: Help

[Phil D. <ph...@or...>]

Chen Hao wrote:
> 
>     WHen I compile oribtcpp 0.22 in solaris 2.7,it's report:
> ImportError: ld.so.1: python: fatal: relocation error:
> file /export/home/chen/lib/libIDL-0.6.so.0: symbol __ashrdi3: referenced
> symbol not found
>   what's the matter?How to resolve it?
> 
> My platform: Solaris 2.7 ORBit 0.50 orbitcpp 0.22


I've finally managed to get my hands on a solaris box to try and
diagnose this problem. I get the same problem on an ultra1 (solaris 2.5)
with everything built from source. Hmmmm....

Unfortunately I've only got the machine for today, so I'll see what I
can do.

Cheers,

Phil.