orbitcpp-list

Re: [orbitcpp-list] from the "out of the loop" department

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

Ronald Garcia wrote:
> 
> hey folks,
> 
>      just a quick question, actually related to orbit-c.  Which
> version of the CORBA standard is the target currently for ORBIT-C?
> 2.2? 2.3? the eventual 3.0?  just checking which specs I should be
> following for things.
> 
> ron
> 

I don't think there's any concensus on which spec ORBit-C tracks. I'd
recommend refering to the latest one (2.3 I think).

Cheers,

Phil.

[orbitcpp-list] HACKING, NEWS, etc.

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

howdy,

     are the standard files (HACKING, etc) up to date, or have some of 
the projects therein been completed (I just like knowing the real
status of things as much as possible).  thanks.

ron

[orbitcpp-list] hmm...troubles in paradise...

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

howdy,

     I noticed that some of the _orbitcpp::c stuff has been
removed...unfortunately my build is broken now...here's what I'm
getting:

....
crap
...
...
CosNaming.cc:14: parse error before `&'
CosNaming.cc: In method `class CORBA::Object * _orbitcpp::stub::CosNaming::NamingContext::resolve(const CosNaming::Name &)':
CosNaming.cc:187: `CORBA_Object' undeclared in namespace `_orbitcpp::c'
CosNaming.cc:187: parse error before `;'
CosNaming.cc:189: `_retval' undeclared (first use this function)
CosNaming.cc:189: (Each undeclared identifier is reported only once
CosNaming.cc:189: for each function it appears in.)
CosNaming.cc:213: warning: control reaches end of non-void function `_orbitcpp::stub::CosNaming::NamingContext::resolve(const CosNaming::Name &)'
make[2]: *** [CosNaming.lo] Error 1
make[2]: Leaving directory `/afs/nd.edu/user12/rgarcia4/code/gnome/orbitcpp/services/name'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/afs/nd.edu/user12/rgarcia4/code/gnome/orbitcpp/services'
make: *** [all-recursive] Error 1


looks like some things are still being placed in _orbitcpp::c by the
compiler.  Is something amiss or not checked in yet (I should really
learn not to update all the time...)

ron

[orbitcpp-list] from the "out of the loop" department

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

hey folks,

     just a quick question, actually related to orbit-c.  Which
version of the CORBA standard is the target currently for ORBIT-C?
2.2? 2.3? the eventual 3.0?  just checking which specs I should be
following for things.

ron

[orbitcpp-list] orbit-c development tree

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

hey all,

     just so you know, i compiled orbitcpp against the current
development tree of orbit (or at least a relatively recently updated
orbit cvs tree).  i didn't check in my changes since most people are
running it against the stable orbit (i'm a masochist, i know :-) ).
anyway, here's a patch to allow orbitcpp to compile against the orbit
in cvs:

Index: orbitcpp_tools.cc
===================================================================
RCS file: /cvsroot/orbitcpp/orbitcpp/orb/orbitcpp_tools.cc,v
retrieving revision 1.4
diff -u -r1.4 orbitcpp_tools.cc
--- orbitcpp_tools.cc	2000/04/26 12:53:45	1.4
+++ orbitcpp_tools.cc	2000/05/29 23:05:55
@@ -37,7 +37,9 @@
 // tool functions -------------------------------------------------------------
 char *_orbitcpp::get_repository_id(_orbitcpp::c::CORBA_Object obj) {
 	// *** FIXME: this is a goddamn hack. it relies on orbit implementation detail
-	return obj->object_id;
+  //	return obj->object_id;
+  // RG - dev ORBit-C changed object_id to type_id
+  return obj->type_id;
 }
 
 
@@ -82,6 +84,8 @@
 #ifdef ORBIT_DEBUG
 	block->magic = 0xdeadbeef;
 #endif
-	block->free = freefunc;
+	//	block->free = freefunc;
+	//RG free changed to freekids in dev ORBit
+	block->freekids = freefunc;
 	block->func_data = reinterpret_cast<void*>(numElements);
 }

Re: [orbitcpp-list] more notes

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

>>>>> "me" == Ronald Garcia <rga...@ir...> writes:

    me> hey all,

    me>      test/basic doesn't seem to have anything in it (which
    me> brings my make process to a halt)...is this just being worked
    me> on now, or are some things not yet checked in?

    me> ron

oops, I should look more closely before I speak...actually, the
problem is a parse error I'm getting when trying to parse the idl:

> orbit-idl basic.idl
basic.idl:7: Error: Missing semicolon after constant declaration for
`number'
basic.idl:7: Error: parse error, expecting `TOK_ENUM' or `TOK_STRUCT'
or `TOK_UN
ION'

** WARNING **: basic.idl compilation failed


is something wrong with the idl, or the compiler (the idl parser, that
is)... my printout of the IDL grammar is about 12 hours away at the
moment (I'm at home for a wedding, working through a Windows telnet
session).

ron

[orbitcpp-list] more notes

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

hey all,

     test/basic doesn't seem to have anything in it (which brings my
make process to a halt)...is this just being worked on now, or are
some things not yet checked in?

ron

Re: [orbitcpp-list] orbit-idl woes

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

>>>>> "me" == Ronald Garcia <rga...@ir...> writes:

    me> hey guys, i'm not very familiar with the dynamically loadable
    me> module aspects of orbit-idl, and i'm running into some trouble
    me> running the orbit-cpp idl compiler.  heres what I'm getting:

hey again,

     turns out that on my system, libtool is using /usr/ccs/bin/ld to
do linking, (I'm running an UltraSparc with Solaris 2.6 or something
like that...), and it's finding the wrong libstdc++.  I had to relink
the backend library using c++ directly and all the same parameters
(which I presume got passed down to ld eventually), so the path
parameters would resolve correctly.  Just thought you guys might like
to know...

ron

[orbitcpp-list] orbit-idl woes

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

hey guys,

     i'm not very familiar with the dynamically loadable module
aspects of orbit-idl, and i'm running into some trouble running the
orbit-cpp idl compiler.  heres what I'm getting:

> orbit-idl -l c++ --backenddir=../../compiler/.libs CosNaming.idl

** WARNING **: Module load failed: ld.so.1: orbit-idl: fatal:
relocation error:
file ../../compiler/.libs/liborbit-idl-c++-backend.so: symbol
__pure_virtual: referenced symbol not found

** CRITICAL **: file orbit-idl-driver.c: line 50
(orbit_idl_to_backend): asserti
on `binfo && binfo->op_output' failed.

** WARNING **: CosNaming.idl compilation failed


it looks like the linker doesn't know where to find __pure_virtual, as
though it's not linked into the shared lib.  anyone run into this
before?

ron

[orbitcpp-list] Proposal to drop the _orbitcpp::c namespace

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

hey phil,
>>>>> "pd" == Phil Dawes <ph...@us...> writes:

    pd> Hi All,

    pd> I'm proposing that we move the ORBit C stuff into the root
    pd> namespace, since trying to use orbitcpp with other
    pd> applications that use ORBit and glib is fraught with
    pd> difficulties otherwise.  E.g. A couple of days ago I attempted
    pd> to wrap gnorba (the gnome/orbit event loop integration and
    pd> activation stuff), but ran into problems with header files.

    pd> Also, gtk-- and gnome-- stick their C stuff in the root
    pd> namespace.

    pd> N.B. The compiler generated C stuff should still be in a
    pd> separate namespace to prevent collisions with generated C++
    pd> code.

    pd> Andreas, Ron, What do you think?


Well, I tend to lean more towards using the namespaces, but I haven't
worked with this stuff in a bit, or run into the problems you may be
having with them.  I'll have to peek around a bit more since a lot has 
changed since I last took a good look at things...if the trend in
ORBit design makes wrapping things difficult, then we should probably
drop the namespaces.  I'll revisit this real soon.

ron

Re: [orbitcpp-list] question about ORBit-tools

[Andreas K. <ak...@ix...>]

Ronald Garcia wrote:
> 
> hey guys,
>      got a question about some code I found in orbitcpp_tools.hh.
> 
> There is some code which goes like so:
> 
> #ifdef ORBITCPP_HAVE_BAD_CAST
>         #define ORBITCPP_NARROW_OR_NULL(type,item) \
>                 type *result; \
>                 try { \
>                         result = dynamic_cast<type *>(item); \
>                 } \
>                 catch (bad_cast) {\
>                     result = NULL; \
>                 }
> #else
>         #warning ORBit-C++ will not detect narrowing errors on pseudo objects.
>         #define ORBITCPP_NARROW_OR_NULL(type,item) \
>                 type *result = static_cast<type *>(item);
> #endif
> 
> a few questions/comments:
> 
>      1)  In C++, dynamic casting to a pointer type doesn't throw
> exceptions, it just returns a 1.  bad_cast is thrown on dynamic casts
> to references...ie, I don't think that code will work.

whoops. you're right.

> 
>      2)  I looked at the code to set ORBITCPP_HAVE_BAD_CAST in
> acinclude.m4... as far as I recall, in g++, bad_cast can be found in
> <typeinfo> instead of <exception>.  I think this is the wrong place
> according to c++ standards, but if we're going to use it, we might as
> well support the most common compiler for this stuff.

if we decide to keep the code, we should probably add g++ compatibility
and fix it.

>      3)  I think that the above could be implemented as a template,
> n'est-ce pas?  That would be the c++ way

true. it's just those damn old habits, you know :))

bye
andy

Re: [orbitcpp-list] question about ORBit-tools

[Andreas K. <ak...@ix...>]

Phil Dawes wrote:
> I don't think the dynamic cast thing will work at all, since it requires
> rtti information AFAIK, and we're using reinterpret_casted C objects
> which won't have this information (since no vtable etc..). Andreas?

The only point where this _is_ indeed needed is narrowing of exceptions,
which is in turn barely needed anywhere. Additionally, as Ron correctly
stated in his original message, the code is broken. If you feel like
eliminating this, go ahead.

bye
andy

Re: [orbitcpp-list] Proposal to drop the _orbitcpp::c namespace

[Andreas K. <ak...@ix...>]

Phil Dawes wrote:
> 
> Hi All,
> 
> I'm proposing that we move the ORBit C stuff into the root namespace,
> since trying to use orbitcpp with other applications that use ORBit and
> glib is fraught with difficulties otherwise.
> E.g. A couple of days ago I attempted to wrap gnorba (the gnome/orbit
> event loop integration and activation stuff), but ran into problems with
> header files.
> 
> Also, gtk-- and gnome-- stick their C stuff in the root namespace.
> 
> N.B. The compiler generated C stuff should still be in a separate
> namespace to prevent collisions with generated C++ code.
> 
> Andreas, Ron, What do you think?

I've also already addressed the problem in my mini-FAQ in the source
tree. One solution is to include the ORBit and glib headers before any
ORBit-C++ stuff. This works reliably, but anyhow, it's a hack. I don't
object to killing the namespace.

bye
andy

[orbitcpp-list] Proposal to drop the _orbitcpp::c namespace

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

Hi All,

I'm proposing that we move the ORBit C stuff into the root namespace,
since trying to use orbitcpp with other applications that use ORBit and
glib is fraught with difficulties otherwise.
E.g. A couple of days ago I attempted to wrap gnorba (the gnome/orbit
event loop integration and activation stuff), but ran into problems with
header files.

Also, gtk-- and gnome-- stick their C stuff in the root namespace.

N.B. The compiler generated C stuff should still be in a separate
namespace to prevent collisions with generated C++ code.

Andreas, Ron, What do you think?

Cheers,

Phil.

Re: [orbitcpp-list] question about ORBit-tools

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

Ronald Garcia wrote:
> 
> hey guys,
>      got a question about some code I found in orbitcpp_tools.hh.
> 
> There is some code which goes like so:
> 
> #ifdef ORBITCPP_HAVE_BAD_CAST
>         #define ORBITCPP_NARROW_OR_NULL(type,item) \
>                 type *result; \
>                 try { \
>                         result = dynamic_cast<type *>(item); \
>                 } \
>                 catch (bad_cast) {\
>                     result = NULL; \
>                 }
> #else
>         #warning ORBit-C++ will not detect narrowing errors on pseudo objects.
>         #define ORBITCPP_NARROW_OR_NULL(type,item) \
>                 type *result = static_cast<type *>(item);
> #endif
> 
> a few questions/comments:
> 
>      1)  In C++, dynamic casting to a pointer type doesn't throw
> exceptions, it just returns a 1.  bad_cast is thrown on dynamic casts
> to references...ie, I don't think that code will work.
> 

I don't think the dynamic cast thing will work at all, since it requires
rtti information AFAIK, and we're using reinterpret_casted C objects
which won't have this information (since no vtable etc..). Andreas?

Cheers,

Phil.

[orbitcpp-list] question about ORBit-tools

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

hey guys,
     got a question about some code I found in orbitcpp_tools.hh.

There is some code which goes like so:

#ifdef ORBITCPP_HAVE_BAD_CAST
	#define ORBITCPP_NARROW_OR_NULL(type,item) \
		type *result; \
		try { \
			result = dynamic_cast<type *>(item); \
		} \
		catch (bad_cast) {\
		    result = NULL; \
		}
#else
	#warning ORBit-C++ will not detect narrowing errors on pseudo objects.
	#define ORBITCPP_NARROW_OR_NULL(type,item) \
		type *result = static_cast<type *>(item);
#endif


a few questions/comments:

     1)  In C++, dynamic casting to a pointer type doesn't throw
exceptions, it just returns a 1.  bad_cast is thrown on dynamic casts
to references...ie, I don't think that code will work.

     2)  I looked at the code to set ORBITCPP_HAVE_BAD_CAST in
acinclude.m4... as far as I recall, in g++, bad_cast can be found in
<typeinfo> instead of <exception>.  I think this is the wrong place
according to c++ standards, but if we're going to use it, we might as
well support the most common compiler for this stuff.

     3)  I think that the above could be implemented as a template,
n'est-ce pas?  That would be the c++ way

just wondering what's thought about that...

ron

Re: [orbitcpp-list] array & union

[Andreas K. <ak...@ix...>]

Phil Dawes wrote:
> 
> Hi Andreas,
> 
> Did you get anywhere with arrays or unions? I'm a bit short of stuff to
> do, and these are the biggest glaring holes in the implementation at the
> moment.

Go ahead, I won't be able to do much for at least two weeks. Things are
collapsing over my head a bit currently. No need to worry, but...

bye
andy

Re: [orbitcpp-list] howdy all...

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

Ronald Garcia wrote:
> 
> hey all,
> 
>      well, I know I've been out of the loop for a while, but the end
> of my semester is upon me...meaning that I should find myself with
> more time on my hands in the very near future.  I'll get updated on
> the CVS tree today...if anything pressing needs to be worked on, let
> me know.
> 
> 

Hi Ron, - good to see you back!

If you're short of things to do, then wrapping some of those POA methods
would be a good starter. (That's unless somebody else is secretly doing
this - shout now if you are!)

Cheers,

Phil.

[orbitcpp-list] howdy all...

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

hey all,

     well, I know I've been out of the loop for a while, but the end
of my semester is upon me...meaning that I should find myself with
more time on my hands in the very near future.  I'll get updated on
the CVS tree today...if anything pressing needs to be worked on, let
me know.

ron

[orbitcpp-list] array & union

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

Hi Andreas,

Did you get anywhere with arrays or unions? I'm a bit short of stuff to
do, and these are the biggest glaring holes in the implementation at the
moment.

Cheers,

Phil.

Re: [orbitcpp-list] my patches to ORBit

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

Andreas Kloeckner wrote:
> 
> Hi Phil & all,
> 
> all the patches have been included in current cvs except the sequence
> demarshalling one. [of course, the one that is most important] here are
> the last messages i exchanged with elliot concerning the thing.
> 

I sent a mail to the orbit-list last week explaining the patch and
asking if there were any objections to me committing it to CVS. I didn't
get any replies, so I've just committed it.

Cheers,

Phil 'about to get his butt kicked by Elliot' Dawes

Re: [orbitcpp-list] bugfix release, and ORBit-C++ examples

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

Phil Dawes wrote:
> 
> Petter Reinholdtsen wrote:
> >
> > Sounds good.  Could you make a simple object creation example, like
> > the bank/account example of other ORBs?
> >
> > When I tried using ORBit C++, I was unable to get this right.  I want
> > to have a gatekeeper object returning server objects to the clients.
> >
> > Having a working example would help a lot. :-)
> 
> Hi Petter,
> 
> I noticed that mico has the POA account example you mentioned. I'll see
> if it I can get it working with orbitcpp tomorrow.
> 

I've put the POA account example in orbitcpp-examples-0.2.tar.gz, which
you can get from the ftp site:
ftp://orbitcpp.sourceforge.net/pub/orbitcpp

Hope this helps,

Phil.

Re: [orbitcpp-list] compiling problem

[Andreas K. <ak...@ix...>]

kr...@pc... wrote:
> 
> Hi all,
> 
> I've downloaded orbitcpp-0.28.1, but I have a problem compiling it.
> After configure and make it stops here:
> 
> c++ -DHAVE_CONFIG_H -I. -I. -I. -I.. -I.. -I/usr/lib/glib/include -I/usr/include -g -O0 -Wall -c  -fPIC -DPIC orbitcpp_poa.cc -o .libs/orbitcpp_poa.lo
> In file included from ../orb/orbitcpp_object.hh:33,
>                  from ../orb/orbitcpp_orb.hh:35,
>                  from ../orb/orbitcpp_poa.hh:38,
>                  from orbitcpp_poa.cc:30:
> ../orb/orbitcpp_tools.hh:54: warning: #warning ORBit-C++ will not detect narrowing errors on pseudo objects.
> In file included from orbitcpp_poa.cc:30:
> ../orb/orbitcpp_poa.hh:49: template-id `operator new<>' for `::_orbitcpp::::_orbitcpp::SequenceTmplForFixedLengthElem<unsigned char,::_orbitcpp::c::PortableServer_sequence_octet>::operator new<>(ULong)' does not match any template declaration
> ../orb/orbitcpp_poa.hh:49: confused by earlier errors, bailing out
> make[1]: *** [orbitcpp_poa.lo] Error 1
> make[1]: Leaving directory `/home/krusina/orbitcpp-0.28.1/orb'
> make: *** [all-recursive] Error 1
> 
> Any idea what's wrong and how to fix it ?

yup, go get gcc-2.95.2 :-)

hope this helps

later
andy

[orbitcpp-list] compiling problem

[<kr...@pc...>]

Hi all,

I've downloaded orbitcpp-0.28.1, but I have a problem compiling it.
After configure and make it stops here:

c++ -DHAVE_CONFIG_H -I. -I. -I. -I.. -I.. -I/usr/lib/glib/include -I/usr/include -g -O0 -Wall -c  -fPIC -DPIC orbitcpp_poa.cc -o .libs/orbitcpp_poa.lo
In file included from ../orb/orbitcpp_object.hh:33,
                 from ../orb/orbitcpp_orb.hh:35,
                 from ../orb/orbitcpp_poa.hh:38,
                 from orbitcpp_poa.cc:30:
../orb/orbitcpp_tools.hh:54: warning: #warning ORBit-C++ will not detect narrowing errors on pseudo objects.
In file included from orbitcpp_poa.cc:30:
../orb/orbitcpp_poa.hh:49: template-id `operator new<>' for `::_orbitcpp::::_orbitcpp::SequenceTmplForFixedLengthElem<unsigned char,::_orbitcpp::c::PortableServer_sequence_octet>::operator new<>(ULong)' does not match any template declaration
../orb/orbitcpp_poa.hh:49: confused by earlier errors, bailing out
make[1]: *** [orbitcpp_poa.lo] Error 1
make[1]: Leaving directory `/home/krusina/orbitcpp-0.28.1/orb'
make: *** [all-recursive] Error 1


Any idea what's wrong and how to fix it ?

thanx,
	Pavel
-- 
   ______      ___   __
  /_____/\    /__/| /_/
 |  ___ \/ _ |  |_/  /    _
 |  ____// /)|   _  ( \ / /)
 |__|/  (_)/ |__|/\__\/(_)/

Re: [orbitcpp-list] bugfix release, and ORBit-C++ examples

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

Petter Reinholdtsen wrote:
> 
> [Phil Dawes]
> > In order to help people get started with ORBit-C++, I've written a
> > small package with a helloworld and name service example.
> 
> Sounds good.  Could you make a simple object creation example, like
> the bank/account example of other ORBs?
> 
> When I tried using ORBit C++, I was unable to get this right.  I want
> to have a gatekeeper object returning server objects to the clients.
> 
> Having a working example would help a lot. :-)

Hi Petter,

The 'everything' test (orbitcpp/test/everything) has a testFactory
interface which serves corba object references to other test servers. It
creates implementations of the other TestServers on the stack (they are
members of the TestFactory_impl class), and obtains transient object
references from them using the _this() method (which regesters the
implementation with the default poa and returns a reference). I think
this covers what you want - please reply if it doesnt.

I noticed that mico has the POA account example you mentioned. I'll see
if it I can get it working with orbitcpp tomorrow.

Cheers,

Phil