orbitcpp-list

[orbitcpp-list] Re: Test on CVS gcc

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

Hi Richard,

This is very useful - thanks very much for spending time doing this.
I'll integrate your patches into the CVS tree.

It might be worth trying a memory debugger (e.g. checker, electric
fence) to find your segfault problem. I've found them to be useful in
the past in pinning the segfault on the right line of code.

BTW, do you have any objections to your name appearing in the AUTHORS
file?

Cheers,

Phil


Richard Andrews writes:
 > 
 > Here's the results so far.
 > 
 > I managed to get it to build but the test servers all crash. I'm looking into it but don't know what I'm looking for. gdb puts the segfault at a weird location, I can't see the problem yet..
 > 
 > The main problem for me with the orbitcpp code is the implicit constructor problem outlined in the test section at the bottom. I have to manually edit all skel code produced by orbitcpp and insert the appropriate constructors.
 > 
 > 
 > 
 > 
 > ----------------------------
 > 
 > 
 > 
 > Building ORBit-0.5.6-patched-for-orbitcpp
 > Using gcc-20010115 an c++-20010115 from codesourcesourcery.com built for i386
 > 
 > configured as 
 > 
 > ./configure i686-pc-linux-gnu --prefix=/usr/develop
 > 
 > --------
 > 
 > services/event/orbit-event-server.c : 
 > 
 > orbit-event-server.c:4:29: CosEventChannel.h: No such file or directory
 > 
 > 
 > Root cause: orbit-idl fails to compile CosEventChannel.idl
 > 
 > CosEventComm.idl:11: Warning: `disconnect_push_consumer' underscores within identifiers are discouraged for use with C-language IDL mappings
 > CosEventChannel.idl:12: Error: Missing comma after identifier `CosEventComm'
 > CosEventChannel.idl:12: Error: parse error, expecting `TOK_OP_SCOPE' or `TOK_IDENT'
 > 
 > ** WARNING **: CosEventChannel.idl compilation failed
 > 
 > 
 > I was forced to disable event subdirectory when building services.
 > --------
 > 
 > warning: const qualifier ignored on asm
 > 
 > This warning appears more than 200 times in both ORBit and orbitcpp builds
 > 
 > --------
 > 
 > 
 > 
 > 
 > 
 > Building ORBitcpp-0.30-pre1
 > Using 
 > gcc-20010115 an c++-20010115 from codesourcery.com built for i386
 > ORBit-0.5.6-patched-for-orbitcpp
 > 
 > ./configure i686-pc-linux-gnu --prefix=/usr/develop
 > OK
 > 
 > 
 > Throughout code std namespace is not used for classes which should only be available through namespace std.
 > 
 > To fix this problem I was forced to make the following change
 > 
 > compiler/base.hh
 > 
 > 
 > 
 > --- base.hh.orig	Wed Jan 17 11:02:22 2001
 > +++ base.hh	Wed Jan 17 11:00:22 2001
 > @@ -37,6 +37,8 @@
 >  #include <iostream>
 >  
 >  
 > +using namespace std;
 > +
 >  
 >  
 >  #define IDL_CPP_KEY_PREFIX			"_cxx_"
 > --end-patch
 > 
 > --------
 > 
 > Friend requires type key. This is a recent pedantic rule implementation. No major problem though.
 > 
 > --- language.hh.orig	Tue Nov 28 09:28:12 2000
 > +++ language.hh	Wed Jan 17 11:06:27 2001
 > @@ -155,7 +155,7 @@
 >  
 >  	void getCPPNamespaceDecl(string &ns_begin,string &ns_end,string const &prefix = "");
 >  
 > -	friend IDLElement;
 > +	friend class IDLElement;
 >  };
 > 
 > 
 > --end-patch
 >  
 > 
 > 
 > 
 > 
 > --- orbitcpp_smartptr.hh.orig	Sat Nov 25 19:30:35 2000
 > +++ orbitcpp_smartptr.hh	Wed Jan 17 11:16:02 2001
 > @@ -910,7 +910,7 @@
 >  	
 >  	template<class CharT,bool p_manager = false>
 >  	class String_var {
 > -		friend String_out<CharT>;
 > +		friend class String_out<CharT>;
 >  	protected:
 >  		CharT								
 > *m_data;
 >  		typedef StringProperties<CharT>		Properties;
 > --end-patch
 > 
 > 
 > --------
 > 
 > Running tests
 > 
 > 
 > basic:
 > 
 > Implicit constructors for templated classes in generated code aren't resolved in some instances. I'm still not sure of the exact reason for this syntax problem but I'm experiencing it with a lot of my own code as well.
 > 
 > basic-cpp-skells.cc: 196
 > 
 > 		_retval = _self->returnReverse(value,*reverse_me_too,*half_of_value);
 > 
 > For this to work it needs to be
 > 
 > 		_retval = _self->returnReverse(value,*reverse_me_too,_orbitcpp::String_out<Char>(*half_of_value) );
 > 
 > 
 > 
 > basic-cpp-skells.cc: 360
 > 
 > 		_retval = _self->getCallback(_call_me_ptr,_call_me_and_change_me_ptr,_orbitcpp::ObjectPtr_out<Test::Callback, _return_me_ptr);
 > 
 > For this to work it needs to be
 > 
 > 		_retval = _self->getCallback(_call_me_ptr,_call_me_and_change_me_ptr,_orbitcpp::ObjectPtr_out<Test::Callback, _orbitcpp::stub::Test::Callback*>(_return_me_ptr));
 > 
 > 
 > 
 > client.cc: std:: not used for cout, cerr, ifstream etc.
 > Fixed by adding
 > 
 > using namespace std;
 > 
 > 
 > client.cc
 > line 66         implicit constructor
 > line 102        implicit constructor
 > 
 > 
 > 
 > server.cc
 > 
 > namespace std problems
 > 
 > 
 > Compiled and linked OK (server and client)
 > 
 > 
 > SEGFAULT in server
 > 
 > basic-cpp-skels.cc : 277
 > POA_Test::BaseB::BaseB(){
 > 
 > called from
 > server.cc : 38
 > Head_impl()
 >     : Cbi1(1), Cbi2(2), Cbi3(3) {
 > 
 > 
 > called from 
 > server.cc : 106
 > Head_impl hi;
 > 
 > 
 > I have no idea what causes the segfault. I'll try and track it down for a bit but I'm not holding out much hope. Probably another weird libstdc++ problem (sorry no debug info for libstdc++).
 > 
 > That's as far as I've gotten
 > 
 > Hope this is useful to you
 > 
 > 
 > L8r
 > 
 > Rich
 > 
 > 
 > 
 > 

[orbitcpp-list] Re: regression tests and patches for ORBit-0.5.6

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

Hi Richard,

I've placed a pre-release of orbitcpp-0.30, and a specially patched
version of ORBit-0.5.6 in 

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

The files are:

ORBit-0.5.6-patched-for-orbitcpp.tar.gz
orbitcpp-0.30-pre1.tar.gz


Any help you can give regarding future compiler versions would be
greatly appreciated.

(N.B. the fixes and patches to ORBit will be in the next stable
release - ORBit-0.5.7 - which should be out in a week or so)

Cheers,

Phil


Richard Andrews writes:
 > 
 > I have a favour to ask regarding the next release.
 > 
 > I've had troubles with ORBitcpp configure scripts and some of the generated code when using new compilers (CVS gcc or libstdc++) which I'm forced to use to get standard compliance. 
 > 
 > Most of the problems were trivial (std:: namespace stuff in test cases) and some implicit constructors (for sequences) in the generated stubs which were ambiguous(I think this was a compiler template handling bug), but I needed to fudge some -fhonor-std stuff to make the configure test programs build.
 > 
 > If you could build and test orbitcpp with a recent CVS snapshot (like a daily codesourcery.com build) that would save me a lot of headaches. 
 > Alternatively if you could mail me a tarball (sorry no CVS because of the firewall at work) that you think is OK to test I'll try it with a recent compiler and let you know how it goes. 
 > 
 > Since the compilers are unstable I'm not 100% confident about the error messages and I get the feeling that some of the problems I was blaming ORBitcpp for may be compiler induced.
 > Still I might be able to give you a warning about possible upcoming problems with gcc3 / libstdc++v3.
 > 
 > 
 > Rich
 > 
 > --
 > Richard Andrews
 > Senior Software Developer
 > Ixla Limited
 > <ric...@ix...>
 > 
 > 
 > 
 > 

[orbitcpp-list] Test, sorry

[Olaf R. <ol...@ph...>]

Just a test

Olaf Razzoli
Senior Developer
Phoenix Tools
www.phoenixtools.com

Re: [orbitcpp-list] sorry, not implemented: initializer contains unrecognized tree code

[Jiva D. <ji...@op...>]

I should add to this this does NOT happen when I compile the
examples.  I am including the orbitcpp.hh header file specifically
because I want to build some generic orbitc++ classes which I can
derive from later to make clients and servers (ie: an application
framework if you will)  So, I am NOT including specifically generated
headers, but I need the types like CORBA::ORB_var etc.

On Tue, Jan 09, 2001 at 10:22:50AM -0700, Jiva DeVoe wrote:
> I get the following error from gcc 2.95-2 (Mandrake Linux 7.2) when
> compiling any code that includes orbitcpp.h:
> 
> /usr/local/include/orb/orbitcpp_smartptr.hh:743: sorry, not
> implemented: initializer contains unrecognized tree code
> /usr/local/include/orb/orbitcpp_smartptr.hh:777: sorry, not
> implemented: initializer contains unrecognized tree code
> /usr/local/include/orb/orbitcpp_smartptr.hh:743: sorry, not
> implemented: initializer contains unrecognized tree code
> /usr/local/include/orb/orbitcpp_smartptr.hh:777: sorry, not
> implemented: initializer contains unrecognized tree code
> 
> Am using .29 of orbitcpp.  This *may* be a bug in gcc 2.95, but I
> wanted to make sure you guys didn't already have a workaround before I
> post to the gcc list.
> 

-- 
Jiva DeVoe
VP Of Software Development
Opnix, Inc. - Simply bitchin bandwidth.
GPG Fingerprint: 0A17 DF84 516A 1DC4 B837  FE6D 3128 41CD 97CB 4AA7

[orbitcpp-list] sorry, not implemented: initializer contains unrecognized tree code

[Jiva D. <ji...@op...>]

I get the following error from gcc 2.95-2 (Mandrake Linux 7.2) when
compiling any code that includes orbitcpp.h:

/usr/local/include/orb/orbitcpp_smartptr.hh:743: sorry, not
implemented: initializer contains unrecognized tree code
/usr/local/include/orb/orbitcpp_smartptr.hh:777: sorry, not
implemented: initializer contains unrecognized tree code
/usr/local/include/orb/orbitcpp_smartptr.hh:743: sorry, not
implemented: initializer contains unrecognized tree code
/usr/local/include/orb/orbitcpp_smartptr.hh:777: sorry, not
implemented: initializer contains unrecognized tree code

Am using .29 of orbitcpp.  This *may* be a bug in gcc 2.95, but I
wanted to make sure you guys didn't already have a workaround before I
post to the gcc list.

-- 
Jiva DeVoe
VP Of Software Development
Opnix, Inc. - Simply Kid-Tested, Mother-Approved bandwidth.
GPG Fingerprint: 0A17 DF84 516A 1DC4 B837  FE6D 3128 41CD 97CB 4AA7

Re: [orbitcpp-list] Re: perform_work, pending_work, can't work when blocking

[<MHL...@t-...>]

On Don, 21 Dez 2000 09:08:59 Brian May wrote:
> [...]
> 
> 1. What is the glib even loop? Is it or isn't it supported by ORBit?

"glib event loop" refers to a set of functions defined by the library
glib which can be invoced on a datastructure called GMainLoop.
This datastructure e.g. holds timeouts or file descriptors to poll.
If you want to use the glib event loop you
- allocate the data structure
- register timeouts and file descriptors
- call g_main_run or repeatadly call g_main_iteration.
(See glib/gmain.h)

ORBit currenctly doesn't register its file descriptors for the glib event
loop but uses its own algorithms. ORBit-mt _does_ use the event loop so
it is no problem to register your own timeouts etc. which then coexist
with ORBit's file descriptors.
If you look in CVS for the ORBit2 sources you can see that once finished,
ORBit2 will most likely use the glib event loop.


_______________________________________________________________________
                            +
--Martin.                  `*'
                           /.\
                          /°.°\
                 _        /'°'\
                (_)      /'°'.°\    ,_.  ,_,
         Merry X-Mas     ~~[_]~~    (_)  |ü|

Re: [orbitcpp-list] Targetting orbitcpp at ORBit 0.5

[Sam C. <sa...@to...>]

Phil Dawes <ph...@us...> wrote:
>=20
> I was thinking that it is probably best to target orbitcpp HEAD at 0.5
> for the time being (since Elliot has 'officially' disowned ORBit CVS
> HEAD), and create a archive branch to orbitcpp for ORBit-2. Does this
> sound like a sane idea?

This sounds very sensible indeed.
--=20
Sam Couter          |   Internet Engineer   |   http://www.topic.com.au/
sa...@to...    |   tSA Consulting      |
OpenPGP key available on key servers
OpenPGP fingerprint:  A46B 9BB5 3148 7BEA 1F05  5BD5 8530 03AE DE89 C75C

[orbitcpp-list] Targetting orbitcpp at ORBit 0.5

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

Hi All,

Just a mail to prevent duplication of effort:

It seems like people are having all sorts of strife trying to work
with multiple (unsupported) versions of ORBit.  To fix this, I'm
currently porting orbitcpp to work with the 'stable' ORBit-0.5.X
releases. I've attached a patch which allows cvs orbitcpp to compile
against ORBit-0.5.6.

Note that the following things are broken in ORBit-0.5.6:

   - Array memory management (Segfaults on CORBA_free)
   - CORBA_Any (the ORBit compiler generates code for complex types
   which doesn't compile)

Everything else seems to work (according to the orbitcpp 'everything'
test harness), so this should be okay for people who don't need these
features (I've probably temporarily broken the orbitcpp any support
with this patch in any case). I'm currently working on patches to
ORBit-0.5 to fix the above problems.

I was thinking that it is probably best to target orbitcpp HEAD at 0.5
for the time being (since Elliot has 'officially' disowned ORBit CVS
HEAD), and create a archive branch to orbitcpp for ORBit-2. Does this
sound like a sane idea?

Merry Christmas all,

Cheers,

Phil

Re: [orbitcpp-list] Re: perform_work, pending_work, can't work when blocking

[Michael R. <mi...@ru...>]

----- Original Message -----
From: "Brian May" <ba...@sn...>
To: <orb...@li...>
Sent: Donnerstag, 21. Dezember 2000 09:08
Subject: Re: [orbitcpp-list] Re: perform_work, pending_work, can't work when
blocking


> >>>>> "Sam" == Sam Couter <sa...@to...> writes:
>
>     Sam> If you want a timeout event, then the best way is probably
>     Sam> for the ORB to use the glib event loop instead of calling
>     Sam> select() directly.
>
>     Sam> There have been murmurs about the next version of ORBit using
>     Sam> the glib event loop, which would make it possible to register
>     Sam> your own timeout events. I don't know if that's still part of
>     Sam> the plan. Multithreading support was also mentioned a few
>     Sam> times, but again, I don't know if that's still part of the
>     Sam> plan either. Would any ORBit developers (Elliot?) like to
>     Sam> comment?
>
> From <URL:http://icps.u-strasbg.fr/~genaud/ORBIT/x421.htm>
>
> "Unfortunately, I don't really see how to do timeouts with the normal
> CORBA event model, so I'm going to have to use the ORBit-specific hack
> of having a glib event loop which supports both CORBA events and
> timeouts. Another way, I am told, is something called an Evictor
> pattern. I should understand this soon once I get my fancy CORBA book
> in the mail.  The final way is just to leak memory like a sieve leaks
> goldfish; this is the easiest thing to do."
>
> 1. What is the glib even loop? Is it or isn't it supported by ORBit?
> 2. What is the evictor pattern?

For the evictor question have a look at
http://industry.ebi.ac.uk/~lcwang/corba-wks/evictor/sld001.htm or for a more
detailed explanation read the LifeCycle Mgmt chapter in "Advanced CORBA
Programming with C++" (Michi Henning and Steve Vinoski)

Michael

Re: [orbitcpp-list] Re: perform_work, pending_work, can't work when blocking

[Brian M. <ba...@sn...>]

>>>>> "Sam" == Sam Couter <sa...@to...> writes:

    Sam> If you want a timeout event, then the best way is probably
    Sam> for the ORB to use the glib event loop instead of calling
    Sam> select() directly.

    Sam> There have been murmurs about the next version of ORBit using
    Sam> the glib event loop, which would make it possible to register
    Sam> your own timeout events. I don't know if that's still part of
    Sam> the plan. Multithreading support was also mentioned a few
    Sam> times, but again, I don't know if that's still part of the
    Sam> plan either. Would any ORBit developers (Elliot?) like to
    Sam> comment?

From <URL:http://icps.u-strasbg.fr/~genaud/ORBIT/x421.htm>

"Unfortunately, I don't really see how to do timeouts with the normal
CORBA event model, so I'm going to have to use the ORBit-specific hack
of having a glib event loop which supports both CORBA events and
timeouts. Another way, I am told, is something called an Evictor
pattern. I should understand this soon once I get my fancy CORBA book
in the mail.  The final way is just to leak memory like a sieve leaks
goldfish; this is the easiest thing to do."

1. What is the glib even loop? Is it or isn't it supported by ORBit?
2. What is the evictor pattern?

Of course, this document seems to be really old now (looks the same
last time I looked at it, 1 year+ ago), so not sure if it still
applies.
-- 
Brian May <ba...@sn...>

[orbitcpp-list] Re: perform_work, pending_work, can't work when blocking

[Sam C. <sa...@to...>]

la...@se... <la...@se...> wrote:
>=20
> I see someone has at least thought about this by the tantilizing but
> unimplemented pending_work and perform_work methods in
> orbitcpp_orb.hh.
>=20
> Does anyone else have the need for this?  Is anyone working on it?
> I've  hacked a version that sets an alarm in src/IIOP/connection.c
> before select is called, then perform my work in the signal handler.
> This is inferior to a real implementation.  If anyone is working on a
> real implementation, please let me know so I can help and use it.  If
> no one is working on this, also let me know and perhaps I will then
> write the real implementation.

I have need for this, to implement a sort of timeout on various objects, for
protection from clients that misbehave. Luckily I don't need it right now,
but I will soon.

If all you're trying to do is avoid blocking (synchronous) operations, then
you can use DII or a multithreaded ORB for the server.

If you want a timeout event, then the best way is probably for the ORB to u=
se
the glib event loop instead of calling select() directly.

There have been murmurs about the next version of ORBit using the glib event
loop, which would make it possible to register your own timeout events. I
don't know if that's still part of the plan. Multithreading support was also
mentioned a few times, but again, I don't know if that's still part of the
plan either. Would any ORBit developers (Elliot?) like to comment?

You can find a multithreaded ORB (ORBit-mt) at:

http://goethe.ira.uka.de/~wilhelmi/corba/orbit-mt.html

I'm fairly sure that ORBit-mt uses the glib event loop, meaning you should
be able to register your own timeout events instead of using a signal
handler.
--=20
Sam Couter          |   Internet Engineer   |   http://www.topic.com.au/
sa...@to...    |   tSA Consulting      |
OpenPGP key available on key servers
OpenPGP fingerprint:  A46B 9BB5 3148 7BEA 1F05  5BD5 8530 03AE DE89 C75C

[orbitcpp-list] perform_work, pending_work, can't work when blocking

[<la...@se...>]

Perhaps I'm writing software all wrong, but I'm surprised how many
challenges I'm running into using orbit for a simple but real server.
I'm doubly surprised because I see so many postings of people working
on the software.  Perhaps the problems I'm having are really odd.

I'd like the server to do something useful in addition to handling
client requests (re-registering itself with a list of servers in a timely
manner, like every few minutes).  I can imagine many scenarios
where it is not acceptable to have orb->run() essentially lockup your
server now and forevermore!

I see someone has at least thought about this by the tantilizing but
unimplemented pending_work and perform_work methods in
orbitcpp_orb.hh.

Does anyone else have the need for this?  Is anyone working on it?
I've  hacked a version that sets an alarm in src/IIOP/connection.c
before select is called, then perform my work in the signal handler.
This is inferior to a real implementation.  If anyone is working on a
real implementation, please let me know so I can help and use it.  If
no one is working on this, also let me know and perhaps I will then
write the real implementation.

Also, in a previous email, I pointed out the problem in orbit where
a client will hang indefintely when the server crashes.  Can it be
no one else has a problem with this behavior?!  I fixed this by hacking
orbit's src/orbit-idl-compiler/backends/corbit-idl-c-stubs.c where it
generated "write" code that did not error check because the environment
variable BACKWARDS_COMPAT_0_4 was defined.

-Lance.

--
-=+=--=+=--=+=--=+=--=+=--=+=--=+=--=+=--=+=--=+=--=+=--=+=-
Lance Welsh              la...@se...
Seascape Communications  (650) 327-6890
-=+=--=+=--=+=--=+=--=+=--=+=--=+=--=+=--=+=--=+=--=+=--=+=-

Re: [orbitcpp-list] ORBit-stable-0-5 and such

[Sam C. <sa...@to...>]

John Luebs <jk...@lu...> wrote:
>=20
> Anyway, I am up to speed with the issues now. I have currently been
> using orbitcpp and the patched revision ORBit that Phil put together. I
> wonder if his changes are now in orbit-stable-0-5. If they are not then
> we must post the patches to the ORBit mailing list. A couple of the
> patches are actually bug fixes, so I am sure they would be willing to
> oblige. [ ... ]

It looks like the --backenddir patch and the orbit-idl flaws in
demarshalling of sequences patches still aren't in, but the libIDL lexer
patch is. I think it has been for a while (since 0.5.1 at least, I think).

According to the comments in the ORBit-C++ patches README, the --backenddir
patch is already in CVS. It must be in HEAD, which means it'll need to be
backported to the stable branch.

> [ ... ] My any support only uses a couple non orbit-stable-0-5 things
> and it should be very easily fixed. Hopefully we can get orbitcpp fully
> functional using this branch, and that will be the end of the headaches
> for people that have had to run 2 copies of ORBit.

That would be very sweet indeed. :)
--=20
Sam Couter          |   Internet Engineer   |   http://www.topic.com.au/
sa...@to...    |   tSA Consulting      |
OpenPGP key available on key servers
OpenPGP fingerprint:  A46B 9BB5 3148 7BEA 1F05  5BD5 8530 03AE DE89 C75C

[orbitcpp-list] ORBit-stable-0-5 and such

[John L. <jk...@lu...>]

> From: Brian May <ba...@sn...>

> those functions are activate_object_with_id, deactivate_object,
> reference_to_servant, reference_to_id, id_to_servant, destroy.
> 
> If 0.29 isn't the newest release, then obviously I am looking at web
> pages that are incorrect. In this case, where can I get the latest
> version from?
> 
> Where can I find up-to-date instructions on obtaining the CVS version?
> (ie. hostname, directory, and login details).
> 
>
> Hmmm. My current version of ORBit (0.5.5) seems OK at present.  I will
> upgrade though if I encounter problems.
> 
Yes Sam, I am on the ORBit mailing list, but I did not read it terribly
carefully. I was more interested in reading some guy's wacky idea for an
HTTP based object server, hehe.
Anyway, I am up to speed with the issues now. I have currently been
using orbitcpp and the patched revision ORBit that Phil put together. I
wonder if his changes are now in orbit-stable-0-5. If they are not then
we must post the patches to the ORBit mailing list. A couple of the
patches are actually bug fixes, so I am sure they would be willing to
oblige. My any support only uses a couple non orbit-stable-0-5 things
and it should be very easily fixed. Hopefully we can get orbitcpp fully
functional using this branch, and that will be the end of the headaches
for people that have had to run 2 copies of ORBit.

I will be back soon.

John Luebs

Re: [orbitcpp-list] Re: orbitcpp status and question

[Sam C. <sa...@to...>]

Brian May <ba...@sn...> wrote:
>=20
> No, this is the latest release, 0.29, from sourceforge. Of course, I
> heard something about 0.30, but I don't think that is released yet.

Not yet. There was some muttering about it, but the features planned for
0.30 aren't quite complete, and it looks like Phil has been too busy for the
past few weeks to do much on it. Same story goes for me.

> If 0.29 isn't the newest release, then obviously I am looking at web
> pages that are incorrect. In this case, where can I get the latest
> version from?
>=20
> Where can I find up-to-date instructions on obtaining the CVS version?
> (ie. hostname, directory, and login details).

The project is hosted on SourceForge (http://orbitcpp.sourceforge.net/).
There is a link to the CVS instructions from the main project page. For
convenience, the link is:

http://sourceforge.net/cvs/?group_id=3D646

> On the topic of the specs, I was wondering, how do I free object
> references?  I had a quick glance through the specs (probably should
> check to ensure it is up-to-date: filename 99-07-41.pdf), but couldn't
> find anything.
>=20
> Currently I have:
>=20
>   void destroy() {
>     PortableServer::ObjectId *objid =3D poa->servant_to_id(this);
>     poa->deactivate_object(*objid);
>     CORBA_free(objid);
>     delete(this);
>   }
>=20
> but not really sure if I have freed objid the correct way (isn't there
> a C++ version of CORBA_free?)

There's CORBA::free(), but I don't think that's the question you're really
trying to ask. Since ORBit-C++ is just a wrapper around ORBit, you should be
able to use CORBA_free() and CORBA::free() interchangably anyway.

For instructions on freeing the object on the server side, see:

http://lists.sourceforge.net/archives//orbitcpp-list/2000-October/000331.ht=
ml

But also see the "How to do garbage collection under CORBA" chapter in the
ORBit Beginners Documentation, especially the "Difference between the client
and the server" section, which clarifies the difference between and object
and an object reference:

http://icps.u-strasbg.fr/~genaud/ORBIT/c382.htm

This should help you work out what you're really trying to do, so that you
can then work out how to do it.

I hope what I've given you helps. :)
--=20
Sam Couter          |   Internet Engineer   |   http://www.topic.com.au/
sa...@to...    |   tSA Consulting      |
OpenPGP key available on key servers
OpenPGP fingerprint:  A46B 9BB5 3148 7BEA 1F05  5BD5 8530 03AE DE89 C75C

Re: [orbitcpp-list] Fwd: Re: branch of ORBit deprecated ?

[Sam C. <sa...@to...>]

Brian May <ba...@sn...> wrote:
>=20
> What is the status of ORBit2?

Too far away. I need a multithreaded ORB soon, and ORBit2 should solve all
my problems. For now, I have to make do with ORBit-mt. It's not an optimal
solution in terms of integrating other software, but it works.

Elliot Lee has made at least one test release of ORBit2 (around a month ago=
).
The announcement went to the ORBit mailing list, and I don't think anything
more has been announced since:

http://mail.gnome.org/archives/orbit-list/2000-November/msg00098.html

Short quote:

"It is intended to fix whatever big things are broken in ORBit stable tree,
break whatever already works, and add just a few new features."

He has also heavily emphasized the _test_ nature of the _test_ release. :)
--=20
Sam Couter          |   Internet Engineer   |   http://www.topic.com.au/
sa...@to...    |   tSA Consulting      |
OpenPGP key available on key servers
OpenPGP fingerprint:  A46B 9BB5 3148 7BEA 1F05  5BD5 8530 03AE DE89 C75C

Re: [orbitcpp-list] Fwd: Re: branch of ORBit deprecated ?

[Brian M. <ba...@sn...>]

>>>>> "Sam" == Sam Couter <sa...@to...> writes:

    Sam> Another option is to just move straight to ORBit2, but I

What is the status of ORBit2?
-- 
Brian May <ba...@sn...>

Re: [orbitcpp-list] Re: orbitcpp status and question

[Brian M. <ba...@sn...>]

>>>>> "John" == John Luebs <jk...@lu...> writes:

    John> Alot is still not completed, but most of the POA stuff
    John> is. The example you cite shows that the orbitcpp you are
    John> using is older than God, I think a lot of this stuff is in
    John> the latest release. And if it isn't then it certainly is in

No, this is the latest release, 0.29, from sourceforge. Of course, I
heard something about 0.30, but I don't think that is released yet.

Just do "grep NYI *.cc" shows a number of instances in one of the
source files:

orbitcpp_poa.cc:	error("NYI");
orbitcpp_poa.cc:	error("NYI");
orbitcpp_poa.cc:	error("NYI");
orbitcpp_poa.cc:	error("NYI");
orbitcpp_poa.cc:	error("NYI");

those functions are activate_object_with_id, deactivate_object,
reference_to_servant, reference_to_id, id_to_servant, destroy.

If 0.29 isn't the newest release, then obviously I am looking at web
pages that are incorrect. In this case, where can I get the latest
version from?

Where can I find up-to-date instructions on obtaining the CVS version?
(ie. hostname, directory, and login details).

    John> CVS. Of couse you also need to have a very late dev snapshot
    John> (or CVS) of ORBit to use bleeding edge orbitcpp. Also do not
    John> install this stuff in /usr or you will be sorry because
    John> precompiled versions of GNOME depend on release ORBit, and
    John> will die with the latest dev ORBit.

Hmmm. My current version of ORBit (0.5.5) seems OK at present.  I will
upgrade though if I encounter problems.

    John> The goal of this project is to faithfully implement the
    John> CORBA C++ mapping.  In the binding spec, deep copying is
    John> done sequences and arrays, and orbitcpp tries to follow the
    John> spec.  Now if you (or anyone) finds places where compliant
    John> code crashes due to a buggy copy (shallow where it should be
    John> deep), please contact the list.

Ok, thanks for the information. If I have any problems, I will
post them here.

On the topic of the specs, I was wondering, how do I free object
references?  I had a quick glance through the specs (probably should
check to ensure it is up-to-date: filename 99-07-41.pdf), but couldn't
find anything.

Currently I have:

  void destroy() {
    PortableServer::ObjectId *objid = poa->servant_to_id(this);
    poa->deactivate_object(*objid);
    CORBA_free(objid);
    delete(this);
  }

but not really sure if I have freed objid the correct way (isn't there
a C++ version of CORBA_free?)
-- 
Brian May <ba...@sn...>

[orbitcpp-list] Fwd: Re: branch of ORBit deprecated ?

[Sam C. <sa...@to...>]

I don't know how many of you are also on the ORBit mailing list, but here's
a message sent by one of the principal developers of ORBit.

John, any chance of you implementing your Any changes using just features in
the stable branch of ORBit, instead of HEAD? I'm sure this will make things
easier for a lot of people, and I know for a fact it'll make things easier
for me. I still haven't been able to get the HEAD version of ORBit to
compile. :(

Another option is to just move straight to ORBit2, but I don't think it's
ready just yet.
-- 
Sam Couter          |   Internet Engineer   |   http://www.topic.com.au/
sa...@to...    |   tSA Consulting      |
OpenPGP key available on key servers
OpenPGP fingerprint:  A46B 9BB5 3148 7BEA 1F05  5BD5 8530 03AE DE89 C75C

[orbitcpp-list] Re: orbitcpp status and question

[John L. <jk...@lu...>]

> Hello,
> 
> I have been interested in C++ bindings for ORBit for sometime now,
> although I don't have a lot of time to keep up-to-date :-(. I have
> three questions.
> 
I hope this won't have to do with velocity of swallows!

> 1. What is the current status of this project? After porting my program
> to use these bindings, I suddenly noticed a lot of important functions
> have error("NYI") (eg. deactivate_object). Any ideas when these
> functions will be implemented?
> 
Alot is still not completed, but most of the POA stuff is. The example
you cite shows that the orbitcpp you are using is older than God, I
think a lot of this stuff is in the latest release. And if it isn't then
it certainly is in CVS. Of couse you also need to have a very late dev
snapshot (or CVS) of ORBit to use bleeding edge orbitcpp. Also do not
install this stuff in /usr or you will be sorry because precompiled
versions of GNOME depend on release ORBit, and will die with the latest
dev ORBit.

As for the pace, things seem to have slowed down. Everyone that writes
free software enjoys it, but most of us have jobs and or other
engagements necessary for survival. I have not heard from Phil Dawes
lately, and I would assume that this is the case with him. The holiday
season has made me awfully busy myself. The IDL compiler has come along
nicely, but there are still some issues with it that I am going to take
a look at over the next week. Hopefully things will settle down for the
other developers so that orbitcpp can pick up the pace.
If after installing CVS orbitcpp and ORBit, you find any NYIs for simple
things, reports to the mailing list are appreciated.

> 2. In C, it is not always safe to copy an object (eg CORBA struct
> containing interfaces and strings) using =, as only a shallow copy is
> created, and you risk freeing nested objects multiple times. Do the
> C++ bindings overload the copy constructor to create deep copies, or
> is this something which has to be done manually by the programmer?
> 
> (this is IMHO one of the hardest aspects of CORBA programming -
> especially with C or C++ - knowing how/when to copy/free/deactivate
> objects - few examples seem to deal with these issues, but rely on
> memory being freed when the program exits).

The goal of this project is to faithfully implement the CORBA C++
mapping.
In the binding spec, deep copying is done sequences and arrays,
and orbitcpp tries to follow the spec.
Now if you (or anyone) finds places where compliant code crashes due to
a buggy copy (shallow where it should be deep), please contact the list.

> 
> 3. Also, I noticed in <URL:http://gnome.dataplus.se/gnomefaq/html/x703.html>
> 
> "...Now, that might be a shared library which got mapped into your
> address space and you are now doing straight function calls into
> it..."
> 
> this is something that really interests me. From
> <URL:http://orbitcpp.sourceforge.net/> it says that a secondary
> objective is to "Allow C and C++ objects in the same address space to
> short-circuit calls (i.e. no on-the-wire marshalling) for maximum
> speed.", which I assume is the same thing.

In someway this is already done, as ORBit itself short circuits the
calls if the server is in the same address space. orbitcpp is merely
wrapping  the stubs and skels of ORBit, and ORBit does this
optimization.

> 
> Previously,I always thought CORBA objects had to run as separate
> processes or threads. I now get the impression that this is not the
> case.  However, how do I construct an object as a shared library that
> is meant to be run from the same address space?
> --
> Brian May <ba...@sn...>

ORBit handles this sort of thing automatically. If the server is in the
same address space, when you deal with the IORs and the client resolves
the IOR, if the servant is in the same space, then the object reference
that the client gets will be "complete", and will have a pointer to the
actual entry point vectors for the servant The stubs check if the
CORBA_Object is complete and call the method directly instead of going
on the wire.  Also, as long as you have the CORBA_Object from the
servant creation, it is totally safe to pass that around in client code,
I believe that the binding allows this. 

John

> 
> --__--__--
> 
> _______________________________________________
> orbitcpp-list mailing list
> orb...@li...
> http://lists.sourceforge.net/mailman/listinfo/orbitcpp-list
> 
> End of orbitcpp-list Digest

[orbitcpp-list] orbitcpp status and question

[Brian M. <ba...@sn...>]

Hello,

I have been interested in C++ bindings for ORBit for sometime now,
although I don't have a lot of time to keep up-to-date :-(. I have
three questions.


1. What is the current status of this project? After porting my program
to use these bindings, I suddenly noticed a lot of important functions
have error("NYI") (eg. deactivate_object). Any ideas when these
functions will be implemented?


2. In C, it is not always safe to copy an object (eg CORBA struct
containing interfaces and strings) using =, as only a shallow copy is
created, and you risk freeing nested objects multiple times. Do the
C++ bindings overload the copy constructor to create deep copies, or
is this something which has to be done manually by the programmer?

(this is IMHO one of the hardest aspects of CORBA programming -
especially with C or C++ - knowing how/when to copy/free/deactivate
objects - few examples seem to deal with these issues, but rely on
memory being freed when the program exits).


3. Also, I noticed in <URL:http://gnome.dataplus.se/gnomefaq/html/x703.html>

"...Now, that might be a shared library which got mapped into your
address space and you are now doing straight function calls into
it..."

this is something that really interests me. From
<URL:http://orbitcpp.sourceforge.net/> it says that a secondary
objective is to "Allow C and C++ objects in the same address space to
short-circuit calls (i.e. no on-the-wire marshalling) for maximum
speed.", which I assume is the same thing.

Previously,I always thought CORBA objects had to run as separate
processes or threads. I now get the impression that this is not the
case.  However, how do I construct an object as a shared library that
is meant to be run from the same address space?
-- 
Brian May <ba...@sn...>

Re: [orbitcpp-list] two rookie questions: initialization, object validation

[<la...@se...>]

Phil Dawes wrote:

> > Perhaps more importanly, if the server has gone down, what
>  > is the best way for the client to avoid hanging or crashing on
>  > subsequent calls to that server?  Is there a way to validate
>  > the object such as objectPointer->isWorking() or even
>  > objectPointer->wontHang().  Perhaps I can embed and
>  > catch an alarm signal before each client call.
>  >
>
> I'm not sure about this one. If orbit is unable to connect to the
> server you get a CORBA::COMM_FAILURE system exception. However if
> ORBit has previously connected to the server then you do seem to get a
> hang. I'll do some experimenting over the weekend...

In trying to unbemuse myself how to use orbit in a fault-tolerant way on linux,
I've discovered where the client hangs when the server dies.  On any idl-defined
function call, the client permenantly hangs when calling
    'giop_recv_reply_buffer_use_2'
in the <name>-stubs.c file where it is apparently expecting to receive a reply
after having sent a write via:
    'giop_send_buffer_write'
where the write failed (but the error is not checked.

This hang can be avoided by checking 'errno' after 'giop_send_buffer_write'
then throwing an exception:

errno=0 ;       // lance
      giop_send_buffer_write(_ORBIT_send_buffer);
if (errno)      // lance
goto _ORBIT_system_exception;   // lance

which works well but needs to be part of orbit-idl's 'C'-code generation
(and has nothing to do with orbitcpp other than be used by it).

    ...  please standby while I download ORBit-0.5.5 ...

I've found the code that generates 'giop_recv_reply_buffer_use_2':

#ifdef BACKWARDS_COMPAT_0_4
  fprintf(ci->fh, "giop_send_buffer_write(_ORBIT_send_buffer);\n");
#else
  fprintf(ci->fh, "if(giop_send_buffer_write(_ORBIT_send_buffer)) goto _ORBIT_system_exception;\n");
#endif

Wow.  I love open source.  Gives me all sorts of new ways to spend
my Friday nights!  Now I change ./ORBit-0.5.5/src/orb/orbit.h.in:

/* #define BACKWARDS_COMPAT_0_4 */
/* #undef NOT_BACKWARDS_COMPAT_0_4 */
#undef BACKWARDS_COMPAT_0_4
#define NOT_BACKWARDS_COMPAT_0_4

followed by a 'make clean' and that almost works but alas that still
leaves ./ORBit-0.5.5/src/orbit-idl-compiler/backends/c/ which appears
to not be a generated file with a '#define BACKWARDS_COMPAT_0_4'.
Forcing that change, a remake and install should finally yield the desirable
results of generating a <name>-stubs.c file which checks the return
value of giop_send_buffer_write for an error and appropriately
throws an exception.  Ahh, but it doesn't - my previous orbit was
installed in '/usr' where this 'make install' went to '/usr/local'.
A quick run of './configure --prefix=/usr' and there's the fix!

Perhaps someone in the ORBit community can tell me how thin
the ground is when not defining 'BACKWARDS_COMPAT_0_4'?
Perhaps I should have simple made the modification locally to
orbit-idl-c-stubs.c rather then the sweeping undefine.

And I hope this is of use to someone else.  Thanks,  -Lance.

--
-=+=--=+=--=+=--=+=--=+=--=+=--=+=--=+=--=+=--=+=--=+=--=+=-
Lance Welsh              la...@se...
Seascape Communications  (650) 327-6890
-=+=--=+=--=+=--=+=--=+=--=+=--=+=--=+=--=+=--=+=--=+=--=+=-

Re: [orbitcpp-list] orbit requires gcc 2.95.2+?

[<la...@se...>]

Phil Dawes wrote:

> Installing libstdc++-compat-2.95.2-3.i386.rpm sorted these sort of
> problems for me.

Thanks for your thorough and thoughtful reply some time ago.
It took me awhile to exaust all the possibilities, but I can not
seem to get a compiler combo to compile orbitcpp-0.29's 'test'
programs (although the rest such as 'compiler' and ' orb'
compiler just fine).  While I wasn't able to exactly replicate
your system (I'm running SGI's  version of redhat 6.1 linux
which had the 2.91 compilers), I came up with these RPMs:

cpp-2.95.2-4tr.i586.rpm      libstdc++-2.95.2-4tr.i586.rpm
gcc-2.95.2-4tr.i586.rpm      libstdc++-compat-2.95.2-4tr.i586.rpm
gcc-c++-2.95.2-4tr.i586.rpm  libstdc++-devel-2.95.2-4tr.i586.rpm

but I get errors compiling the 'test' programs, such as in 'boolean':

/include -I/usr/include     -g -O0 -Wall -c boolean-cpp-common.cc
In file included from boolean-cpp-stubs.hh:11,
                 from boolean-cpp-common.cc:6:
boolean-cpp-common.hh:21: parse error before `<'
boolean-cpp-common.hh:22: parse error before `<'
make[1]: *** [boolean-cpp-common.o] Error 1

I'm sticking with orbitcpp-0.26 which works fine with me!

The main problem I'm having (clients hanging on a reply
from a dead server) is with orbit's generated 'C' files and
not with the generated 'C++' files.  I'm bemuzed as to how
anyone has seriously used orbit in a fault-tolerant way!

Thanks again, always, and anyways,  -Lance.

_______________________________________________

> orbitcpp-list mailing list
> orb...@li...
> http://lists.sourceforge.net/mailman/listinfo/orbitcpp-list

--
-=+=--=+=--=+=--=+=--=+=--=+=--=+=--=+=--=+=--=+=--=+=--=+=-
Lance Welsh              la...@se...
Seascape Communications  (650) 327-6890
-=+=--=+=--=+=--=+=--=+=--=+=--=+=--=+=--=+=--=+=--=+=--=+=-

[orbitcpp-list] Re: Gearing up for release 0.30

[<MHL...@t-...>]

On Don, 23 Nov 2000 21:49:01 Martin Schulze wrote:
> Hi,
> 
> Maybe you should also make orbitcpp link against the latest
> ORBit2-preview that was recently announced on the orbit-list.
> 
> It seems that there are only few changes necessary:
> [snip]


Phil, did you already fixed some problems!? I made some temporary
fixes for myself but checked out orbitcpp, so my changes should
have got lost; however it still compiles and links against ORBit2!


However, with (hacked) ORBit2 and orbitcpp up and running, there
are two problems left:

- The orbitcpp-test "string" compiles but doesn't link. There is
  a dozen unresolved externals; each of them starts with CORBA_*.
  This is strange because the linker finds the right version of
  ORBit. I even copied the library to libORBit-2.3.90.so/la and
  link with -lORBit-2.3.90 ...
  I don't know what's going wrong here.

- This code doesn't compile:

______________________________________________________________
  namespace _orbitcpp { namespace c {
        #include "corbaSigC.h"
// *** This line doesn't cause errors:
        class testtest { CORBA_sequence_CORBA_any anytesttest; };
  } }

  namespace corbaSigC {
// *** This one causes an error:
// `CORBA_sequence_CORBA_any' undeclared in namespace `_orbitcpp::c'
    class ctesttest { ::_orbitcpp::c::CORBA_sequence_CORBA_any anytesttest;
};

// *** This one works!
    class cctesttest { CORBA_sequence_CORBA_any anytesttest; };
  }
_____________________________________________________________

  The problem is, that CORBA_sequence_CORBA_any and friends are
  declared to have C-linkage (extern "C" {...}). The
  "namescpace _orbitcpp { namespace c { } }" around
  "#include "corbaSigC.h" is ignored for those symbols.
  I don't know whether there is a workaround (compliler-option).
  otherwise we have to cut the "::_orbitcpp::c::"!

Cu, Martin

Re: [orbitcpp-list] What does this error message mean?

[Sam C. <sa...@to...>]

Richard Andrews <ric...@ix...> wrote:
> If anyone actually reads this list...
>=20
> I've just managed to get ORBit-cpp 0.29 to build with ORBit-0.5.4-helix
> but when I try to use it I get the following errors from orbit-idl
>=20
> orbit-idl -lc++ test.idl
>=20
> ** WARNING **: Module load failed:
> /usr/lib/orbit-idl/liborbit-idl-c++-backend.so: undefined symbol:
> __vt_9exception

Unhelpful answer: The backend was compiled with an external symbol declared,
which doesn't exist in the orbit-idl binary program, or any of its
dynamically linked libraries. Whatever the symbol was named in the source,
the C++ compiler has mangled it into "__vt_9exception".

Getting slightly more helpful: Since the C++ compiler has mangled the
symbol name, it was either in the C++ headers, or the Helix version of the
ORBit headers is missing some extern "C" {} blocks. The second alternative
is more likely, as the problem doesn't exist with Debian (woody) ORBit or
with ORBit-mt.

Should have been more helpful but isn't: I can't reproduce the problem on my
Debian (woody) box with the Helix ORBit packages installed, so I can't work
on determining a cause and/or fixing it. Maybe after I've had some sleep I
can give it another go.
--=20
Sam Couter          |   Internet Engineer   |   http://www.topic.com.au/
sa...@to...    |   tSA Consulting      |
OpenPGP key available on key servers
OpenPGP fingerprint:  A46B 9BB5 3148 7BEA 1F05  5BD5 8530 03AE DE89 C75C