orbitcpp-list

Re: [orbitcpp-list] Re: Where's the Any support

[ERDI G. <ca...@ca...>]

On Sun, 12 Nov 2000, John Luebs wrote:

> Hmm. The official orbitcpp project is located at
> http://sourceforge.net/projects/orbitcpp. If you go to the CVS
> repository link (towards the bottom) it has instructions on getting the
> sources from CVS, I just looked at the Browse CVS Repository link and
> the changes are in there.

Now it is, thanks. But it wasn't in the afternoon.

-- 
   .--= ULLA! =----------------------------.  finger ca...@ca...
   \      http://cactus.rulez.org           \   for PGP public key
    `----------= ca...@ca... =--'
Sajnálom, de nem tudok segíteni. Engem csak a szépségem miatt vettek fel.

[orbitcpp-list] Re: Where's the Any support

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

Hmm. The official orbitcpp project is located at
http://sourceforge.net/projects/orbitcpp. If you go to the CVS
repository link (towards the bottom) it has instructions on getting the
sources from CVS, I just looked at the Browse CVS Repository link and
the changes are in there.
Everything just about works except: Functions that take or return
TypeCode_ptr, and Any_var, which will be in shortly. Finally due to an
oversight on my part, an Any in an exception causes the server to crash.
That problem will be fixed shortly. I have loosely tested Any's with
strings and objects and struct, and almost everything "seems" to work.
Please post any (no pun intended) problems you find on the list.

Thank you,
John Luebs

[orbitcpp-list] Where's the Any support?

[ERDI G. <ca...@ca...>]

Hi,

I've read about the Any stuff checked in, but can't find it in CVS HEAD.
Is ORBit/C++ branched? Is it moved from SourceForge? Where should I be
looking?

Thanks,
	Cactus

-- 
   .--= ULLA! =----------------------------.  finger ca...@ca...
   \      http://cactus.rulez.org           \   for PGP public key
    `----------= ca...@ca... =--'
'Two beer or not two beer?'-Shakesbeer

[orbitcpp-list] A bit of a problem

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

I have been working quite a bit with sequences and Anys.. Everything in
the current CVS works, except for proper sequence packing/unpacking.
However, when testing exceptions with sequences, I came across a bitch
of a problem. The problem is that every sequence needs "spec code" that
is triggered by a Typedef that issues a job that is run when outside of
an interface (class). This is basically fine but what about this:
interface Test {
	typedef sequence<long> LongSeq;
	exception Fail { LongSeq theProblem; };
};
Well the spec is written after the class Test, but there is an
instantiation in the exception, before the spec code. Only one spec is
needed for each unique C++ type of template (ie two typedef
sequence<long>s produce one spec). To this end there is a list that is
put in the compiler state that keeps track of seqs and arrays. when the
spec job is about to be queued, it is checked. Since we can't predict
when this situation is going to occur, it seems like the only thing is
to build the unique sequence list during the gather pass and then the
first thing during the translate pass is to output those sequence specs.
Of course there is put the specs in another file solution, but I think
that is too unwieldy.
Your thoughts?

John Luebs

[orbitcpp-list] compiler fixes and Any support

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

I checked in Any support in both the ORB and compiler. I also fixed a
couple nasty bugs in arrays, and sequences. Although most people might
write:
typedef sequence< string > mySeq;
struct Test {
	mySeq test_seq;
};
You can write:
struct Test {
	sequence< string > test_seq;
};
This is not a typedef, but since this causes an UnboundedSequenceTmpl
instance we still need to write the operator new and allocbuf. I
consider the operator new and allocbuf to be "Typespec implementation".
Implementation that has to be present whenever the typespec exists for
any reason, that is whenever getCPPMemberDeclarator is called for
putting the typespec in the generated code. Well getCPPMemberDeclarator
is used in structs, exceptions, and typedefs, and unions for members
that may possibly need "implementation" to complement the simple
declarator. So I added a function writeTypeImplCode to IDLType that
takes care of this "implementation." This functions is simply called in
the doTypedef, doException, and doStruct. I eschewed Unions because I
knew Phil was working on that and I just thought I won't touch it for
now.

Also what about
struct Test {
	long LongArr[5];
};
Well this just requires that the identifier be output correctly (it
wasn't before), with dims attached, but no typedef things like smart
pointers and Any functions have to be written. This problem is fixed.
Also arrays in exceptions are supported.
I think that about covers it. If there are any problems (it all compiles
fine for me, I hope your mileage does not vary) please drop me an email
and I will work on them immediately!

John Luebs

Re: [orbitcpp-list] Compiler Any support and sequence bug

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

Hi Sam, John,

Looks like we're going to have to do a merge-fest fairly soon. I've
almost finished union support (which was a bugger btw) and hope to do
a cvs commit tonight with this stuff. There are quite a few changes to
the compiler so I'd like to commit this before merging commences.

Then we have 2 options:

1) I merge the typecode/any patches manually and commit to cvs
2) We do the cvs 'thing' and each commit our stuff, merging as we go.

As a future plan, it makes sense to commit early and often - as long
as the thing compiles I'm not that fussed. (I'm guilty of not
committing early - mainly because I've had the archive to myself for
the last 3 months or so :-(

Cheers,

Phil


Sam Couter writes:
 > Phil Dawes <ph...@us...> wrote:
 > > 
 > > Sam - have you had a chance to look at this? Is there any crossover
 > > with what you've done?
 > 
 > More than that - All I can add to this is a C++ wrapper of the ORBit
 > TypeCode to create a C++ TypeCode implementation. John's implementation of
 > Any is way beyond what I've got done so far.
 > 
 > I'm attaching my TypeCode implementation as a patch to orbitcpp_orb.{cc,hh}
 > and two new files: orbitcpp_typecode.{cc,hh}.
 > John, you might like to use this C++ wrapper implementation of TypeCode in
 > your Any implementation. I don't know if it's necessary or even useful.
 > 
 > The compiler still won't generate the appropriate C++ TypeCode constants
 > for each generated type though.
 > -- 
 > Sam Couter          |   Internet Engineer   |   http://www.topic.com.au/
 > sa...@to...    |   tSA Consulting      |
 > PGP key available on key servers
 > PGP key fingerprint:  A46B 9BB5 3148 7BEA 1F05  5BD5 8530 03AE DE89 C75C

Re: [orbitcpp-list] Compiler Any support and sequence bug

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

Phil Dawes <ph...@us...> wrote:
> 
> Sam - have you had a chance to look at this? Is there any crossover
> with what you've done?

More than that - All I can add to this is a C++ wrapper of the ORBit
TypeCode to create a C++ TypeCode implementation. John's implementation of
Any is way beyond what I've got done so far.

I'm attaching my TypeCode implementation as a patch to orbitcpp_orb.{cc,hh}
and two new files: orbitcpp_typecode.{cc,hh}.
John, you might like to use this C++ wrapper implementation of TypeCode in
your Any implementation. I don't know if it's necessary or even useful.

The compiler still won't generate the appropriate C++ TypeCode constants
for each generated type though.
-- 
Sam Couter          |   Internet Engineer   |   http://www.topic.com.au/
sa...@to...    |   tSA Consulting      |
PGP key available on key servers
PGP key fingerprint:  A46B 9BB5 3148 7BEA 1F05  5BD5 8530 03AE DE89 C75C

[orbitcpp-list] Any and other compiler enhancements

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

I am awfully sorry about the last one, Balsa screwed up the attachments!
Here they are.

John Luebs

[orbitcpp-list] Any and other Compiler enhancements

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

Attached is output of diff to the orb, orbitcpp_any.hh orbitcpp_any.cc, and
diffs on the compiler. The compiler should eek out marshalling for Any with
the correct argument passing rules. I have done some minimal testing and it
seems to work well. I also have a good start on the generation of any
inserter and extractor functions. I have tried my best to follow the basic
patterns of the compiler framework. So your comments on the compiler patch
file itself are appreciated.

in CORBA::Any works except for things with TypeCode_ptr (they are basically
implemented, just
commented out so the code will compile).

One issue in the compiler  patch:
The IDL compiler needs to keep track of Array and Sequence (and soon Fixed)
type definitions to make sure that multiple specs aren't being written for
what is effectively the same type. I started a solution to this (making a
IDLSequenceList in types.hh that is basically implemented as a set, so it
should be very fast). The list is kept in IDLCompilerState. The same exact
thing has to be done for array. In addition I am fixing array to defer its
spec generation (just like sequence), at this time because without it, the
code generated for array typedef nested more than module scope is broken.

John Luebs
/* -*- Mode: C++; tab-width: 4; indent-tabs-mode: t; c-basic-offset: 4 -*-
*/

/*
 *  ORBit-C++: C++ bindings for ORBit.
 *
 *  Copyright (C) 2000 John K. Luebs
 *
 *  This library is free software; you can redistribute it and/or
 *  modify it under the terms of the GNU Library General Public
 *  License as published by the Free Software Foundation; either
 *  version 2 of the License, or (at your option) any later version.
 *
 *  This library is distributed in the hope that it will be useful,
 *  but WITHOUT ANY WARRANTY; without even the implied warranty of
 *  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
 *  Library General Public License for more details.
 *
 *  You should have received a copy of the GNU Library General Public
 *  License along with this library; if not, write to the Free
 *  Software Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
 *
 *  Author: John K. Luebs <jk...@ma...>
 *
 *  Description: CORBA Any implementation
 */
#include <cwchar>
#include <orb/orbit.h>
#include "orbitcpp_any.hh"

/*void CORBA::Any::copy(TypeCode_ptr tc, void* value, Boolean release)
{
	m_target._type = 
		ORBit_TypeCode_dup(reinterpret_cast<CORBA_TypeCode>(tc));
	if( release )
		m_target._value = ORBit_copy_value(value, _type);
	else
		m_target._value = value;
	m_target._release = release;
}
*/

void CORBA::Any::insert_simple(CORBA_TypeCode tc, void* value, Boolean
v_copy)
{
	g_assert( tc->parent.refs == ORBIT_REFCNT_STATIC );
	void *new_val;
	if(v_copy)
		new_val = ORBit_copy_value(value, tc);
	else
		new_val = value;
	if( m_target._release )
		CORBA_free( m_target._value );
	m_target._value = new_val;
	m_target._release = CORBA_TRUE;
	if( m_target._type != tc )
	{
		ORBit_RootObject_release(m_target._type);
		m_target._type = tc;
	}
}	

void CORBA::Any::operator<<=(from_string in)
{
	if( in.bound && (strlen(in.val) > in.bound) )
		return;
	ORBit_RootObject_release(m_target._type);
	CORBA_TypeCode new_tc = _orbitcpp::TypeCode_allocate();
	new_tc->kind = CORBA_tk_string;
	new_tc->length = in.bound;
	m_target._type = new_tc;
	if( m_target._release )
		ORBit_free( m_target._value );

	if( in.nocopy ) {
		m_target._value = ORBit_alloc_tcval(m_target._type, 1);
		*(CORBA_char**)m_target._value = in.val;
	}
	else
		m_target._value = ORBit_copy_value(&in.val,
m_target._type);
	m_target._release = CORBA_TRUE;
}

void CORBA::Any::operator<<=(from_wstring in)
{
	if( in.bound && (wcslen((wchar_t*)in.val) > in.bound) )
		return;
	ORBit_RootObject_release(m_target._type);
	CORBA_TypeCode new_tc = _orbitcpp::TypeCode_allocate();
	new_tc->kind = CORBA_tk_wstring;
	new_tc->length = in.bound;
	m_target._type = new_tc;
	if( m_target._release )
		ORBit_free( m_target._value );
	
	if( in.nocopy ) {
		m_target._value = ORBit_alloc_tcval(m_target._type, 1);
		*(CORBA_char**)m_target._value = (CORBA_char*)in.val;
	}
	else
		m_target._value = ORBit_copy_value(&in.val,
m_target._type);
	m_target._release = CORBA_TRUE;
}

CORBA::Boolean
CORBA::Any::operator>>=(to_string out) const
{
	CORBA_TypeCode tmp = _orbitcpp::TypeCode_allocate();
	tmp->kind = CORBA_tk_string;
	tmp->length = out.bound;
	Boolean ret = extract(tmp, const_cast<char*&>(out.val));
	ORBit_RootObject_release(tmp);
	return ret;
}

CORBA::Boolean
CORBA::Any::operator>>=(to_wstring out) const
{
	CORBA_TypeCode tmp = _orbitcpp::TypeCode_allocate();
	tmp->kind = CORBA_tk_wstring;
	tmp->length = out.bound;
	Boolean ret = extract(tmp, const_cast<WChar*&>(out.val));
	ORBit_RootObject_release(tmp);
	return ret;
}

Re: [orbitcpp-list] Compiler Any support and sequence bug

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

Phil Dawes <ph...@us...> wrote:
>=20
> Sam - have you had a chance to look at this? Is there any crossover
> with what you've done?

I haven't had a chance to look yet. I'll check it out today, with any luck.
--=20
Sam Couter          |   Internet Engineer   |   http://www.topic.com.au/
sa...@to...    |   tSA Consulting      |
PGP key available on key servers
PGP key fingerprint:  A46B 9BB5 3148 7BEA 1F05  5BD5 8530 03AE DE89 C75C

Re: [orbitcpp-list] Compiler Any support and sequence bug

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

Hi John,

Many thanks for submitting this; I'm afraid I won't be able to look at
it until tomorrow evening (spare time is a bit scarce at present :-(

Sam - have you had a chance to look at this? Is there any crossover
with what you've done?

Thanks again John,

Phil

John Luebs writes:
 > I managed to get the IDL compiler to eek out code for Any. Marshalling and
 > Demarshalling work
 > and I spent some to get operator functions made for user defined types. The
 > compiler patch can be
 > found at ftp://www.luebsphoto.com/pub/
 > There is also the beginnings of the CORBA::Any I mentioned earlier.
 > In hammering out the Any insertion extraction operator generation, I found
 > a bit a bug. The sequence
 > creation in the compiler uses that IDLWriteSeqSpec job. Well consider:
 > typedef sequence<long, 5> test_seq;
 > typedef sequence<long, 5> test_seq2;
 > The IDLWriteSeqSpec job should only run once, yet right now it runs for
 > both writeTypedefs for the
 > sequences. There are two possible solutions, the pretty/fast one, and the
 > kludgy one. The code
 > generated by IDLWriteSeqSpec job can be guarded by #ifndef, #define, #endif
 > so even though
 > the code appears more than once, there are no compilation problems. The
 > "better" solution is to
 >  have a map of CPPTypeNames of the sequences and the map is checked before
 > the a sequence
 > Write spec job is submitted.
 > I made a few changes to make this effect and ended up with
 > ftp://www.luebsphoto.com/pub/compiler2.idl.
 > 
 > John Luebs
 > 
 > _______________________________________________
 > orbitcpp-list mailing list
 > orb...@li...
 > http://lists.sourceforge.net/mailman/listinfo/orbitcpp-list
 > 

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

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

la...@se... writes:
 > Thanks for the quick reply!
 > 
 > Phil Dawes wrote:
 > 
 > > Hi lance,
 > >
 > > There really isn't much point regressing to orbitcpp-0.24 - there's
 > > not a huge amount of functionality in that release and it's not
 > > supported.
 > 
 > Good news - I've got 0.27 built and examples running (tho having
 > some troubles running them accross two machines at the moment,
 > even with care to copy the server's ior file).
 > 

You have to enable TCP/IIOP support explicitly - the gnome folks
disabled this in ORBit by default because it might be a 'security
hole'. I think you need to pass -ORBIIOPIPv4=1 or something. It's in
the orbit faq:
http://orbit-resource.sourceforge.net/faq.html

 > > I'm confused as to why you're locked into stock compilers - I've
 > > upgraded many a rh6 system to gcc 2.95.2 (well 4 anyway :-).
 > >
 > > These are the rpms I've got:
 > >
 > > gcc-2.95.2-3.i386.rpm
 > > gcc-c++-2.95.2-3.i386.rpm
 > > cpp-2.95.2-3.i386.rpm
 > > libstdc++-2.95.2-3.i386.rpm
 > > libstdc++-compat-2.95.2-3.i386.rpm
 > > libstdc++-devel-2.95.2-3.i386.rpm
 > 
 > Hmmm, perhaps I shall try it again.  The initial problem I had
 > was misinfo - I thought 2.95.2 was not object/link compatible
 > (perhaps that's 2.96) as I'll need to link with others and their
 > objects from 2.91.  

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

Hope this helps,

Phil

[orbitcpp-list] Compiler Any support and sequence bug

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

I managed to get the IDL compiler to eek out code for Any. Marshalling and
Demarshalling work
and I spent some to get operator functions made for user defined types. The
compiler patch can be
found at ftp://www.luebsphoto.com/pub/
There is also the beginnings of the CORBA::Any I mentioned earlier.
In hammering out the Any insertion extraction operator generation, I found
a bit a bug. The sequence
creation in the compiler uses that IDLWriteSeqSpec job. Well consider:
typedef sequence<long, 5> test_seq;
typedef sequence<long, 5> test_seq2;
The IDLWriteSeqSpec job should only run once, yet right now it runs for
both writeTypedefs for the
sequences. There are two possible solutions, the pretty/fast one, and the
kludgy one. The code
generated by IDLWriteSeqSpec job can be guarded by #ifndef, #define, #endif
so even though
the code appears more than once, there are no compilation problems. The
"better" solution is to
 have a map of CPPTypeNames of the sequences and the map is checked before
the a sequence
Write spec job is submitted.
I made a few changes to make this effect and ended up with
ftp://www.luebsphoto.com/pub/compiler2.idl.

John Luebs

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

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

Thanks for the quick reply!

Phil Dawes wrote:

> Hi lance,
>
> There really isn't much point regressing to orbitcpp-0.24 - there's
> not a huge amount of functionality in that release and it's not
> supported.

Good news - I've got 0.27 built and examples running (tho having
some troubles running them accross two machines at the moment,
even with care to copy the server's ior file).

> I'm confused as to why you're locked into stock compilers - I've
> upgraded many a rh6 system to gcc 2.95.2 (well 4 anyway :-).
>
> These are the rpms I've got:
>
> gcc-2.95.2-3.i386.rpm
> gcc-c++-2.95.2-3.i386.rpm
> cpp-2.95.2-3.i386.rpm
> libstdc++-2.95.2-3.i386.rpm
> libstdc++-compat-2.95.2-3.i386.rpm
> libstdc++-devel-2.95.2-3.i386.rpm

Hmmm, perhaps I shall try it again.  The initial problem I had
was misinfo - I thought 2.95.2 was not object/link compatible
(perhaps that's 2.96) as I'll need to link with others and their
objects from 2.91.  Secondly, when I installed a similar set to
the above, the linker gave me unersolved symbols from libX11.so
(something like getpum@@(GLIBC2_2) and setshm@@(GLIBC2_2))
and I freaked-out (I'm using an SGI PC).  I don't think there's any
new libX11 in the rpms above, so unless you steer me otherwise,
I will see how far I get with 0.27.

> Sorry that this is such a crap reply, but I really don't think it's
> worth your while attempting to compile that old release.

I greatly appreciate your reply.  It's quite late here and I'm on the
end of a 20 hour binge.  I will look forward to rereading your reply
in the morning and may even have the energy to retry new compilers.

Thanks,   -Lance.

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

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

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

Hi lance,

There really isn't much point regressing to orbitcpp-0.24 - there's
not a huge amount of functionality in that release and it's not
supported.

I'm confused as to why you're locked into stock compilers - I've
upgraded many a rh6 system to gcc 2.95.2 (well 4 anyway :-).

These are the rpms I've got:

gcc-2.95.2-3.i386.rpm
gcc-c++-2.95.2-3.i386.rpm
cpp-2.95.2-3.i386.rpm
libstdc++-2.95.2-3.i386.rpm
libstdc++-compat-2.95.2-3.i386.rpm
libstdc++-devel-2.95.2-3.i386.rpm

Sorry that this is such a crap reply, but I really don't think it's
worth your while attempting to compile that old release.

Cheers,

Phil


la...@se... writes:
 > I'm locked into stock compilers on my Redhat 6.x system (gcc 2.91)
 > but would really love to use orbitcpp.  I've tried regressing to orbitcpp
 > v0.24 which seems to be the last before the 2.95.2 compiler requirement,
 > but that requires some python development environment.
 > 
 > Any creative ideas on how to get a recent verion of  orbitcpp working
 > on a stock Redhat 6.x system with 2.91 compilers?  I don't need any
 > advance functinoality, and only the client is locked into 2.91.
 > 
 > Can someone provide direction on installing the required python files
 > (or tell me that this distant release is not worth installing)?
 > 
 > If neither, perhaps reply with some pointers to other simple examples
 > of using corba.  Thx, -Lance.
 > 

[orbitcpp-list] orbit requires gcc 2.95.2+?

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

I'm locked into stock compilers on my Redhat 6.x system (gcc 2.91)
but would really love to use orbitcpp.  I've tried regressing to orbitcpp
v0.24 which seems to be the last before the 2.95.2 compiler requirement,
but that requires some python development environment.

Any creative ideas on how to get a recent verion of  orbitcpp working
on a stock Redhat 6.x system with 2.91 compilers?  I don't need any
advance functinoality, and only the client is locked into 2.91.

Can someone provide direction on installing the required python files
(or tell me that this distant release is not worth installing)?

If neither, perhaps reply with some pointers to other simple examples
of using corba.  Thx, -Lance.

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

Re: [orbitcpp-list] Any implementation

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

John Luebs <jk...@lu...> wrote:
> [ ... ] I just subscribed to ORBit mailing list and see
> that Mr. Couter
> is already working on CORBA::Any. I did a good bit of work on both the IDL
> compiler side
> and the class implementation, [ ... ]

I haven't touched the IDL compiler yet, nor do I really know how to tackle
it. I haven't even looked at it yet, as I figured I'd get the CORBA::Any
class implemented and tested first. Phil has indicated to me that he or
Andreas would be the most appropriate people to modify the IDL compiler
itself.

If you send whatever work you've done to me or the list (especially work on
the IDL compiler), then I can see where my work stands in comparison to
yours. Then I can try to merge it all together, or I can just step aside so
you can complete it.
--=20
Sam Couter          |   Internet Engineer   |   http://www.topic.com.au/
sa...@to...    |   tSA Consulting      |
PGP key available on key servers
PGP key fingerprint:  A46B 9BB5 3148 7BEA 1F05  5BD5 8530 03AE DE89 C75C

[orbitcpp-list] Any implementation

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

Hello, my name is John Luebs.
I have been lurking around for a while. I would like to make some
contributions to this
project. I thought I might implement CORBA::Any and submit that during the
middle of next
week as a starting point. I just subscribed to ORBit mailing list and see
that Mr. Couter
is already working on CORBA::Any. I did a good bit of work on both the IDL
compiler side
and the class implementation, which I do not regret in the least because I
feel much more
comfortable with both the ORBit and orbitcpp codebase. I would like to make
some valuable
contributions to the project and was wondering what seems to be of a high
priority right
now. To be honest I haven't looked at the POA implementation carefully in
comparison to the
standard, so I am not sure what position it is in. Also it seems unions and
arrays are not
completed, is someone actively working on them? Eventually I would like to
work on DII, DSI
and IR but I wanted to see if there were other higher priority things I
could help out with.

Thank you,
John Luebs 

[orbitcpp-list] Re: CORBA_long_double type

[Elliot L. <so...@re...>]

On Fri, 3 Nov 2000, Sam Couter wrote:

> I tried changing the typedef for CORBA_long_double to "long double" (I would
> have used glib's gldouble if it had been defined) and rebuilding ORBit, but
> now if I try to send CORBA_long_double arguments I get garbage.

> Can anyone help me make CORBA_long_double a distinct type from CORBA_double?

The problem is that 'long double' is totally undefined. On my Alpha box,
it is the same size as a 'double'. On my x86 box, it is 12 bytes compared
to 8 for a double. The CORBA spec seems to want it to be 16 bytes long.

I am not sure if the ORBit IDL compiler even handles 'long double'
properly... I would recommend avoiding it altogether if possible - it
seems it is too much of a problem to actually implement...

-- Elliot
[ "In a democracy, the government is the people," Milo explained. "We're people,
aren't we? So we might just as well keep the money and eliminate the middleman." ]
							- Catch-22

Re: [orbitcpp-list] Orbit Name Service

[Phil D. <pd...@be...>]

Hi Esther,

I think the problem is most likely with ORBit 0.5.4. Could you try
it with the unofficial ORBit cvs snapshot mentioned on the
orbitcpp-0.29 release notes?

Here's a direct link to the notes:

http://sourceforge.net/project/shownotes.php?release_id=13737

Hope this helps,

Phil

Esther writes:
 > Hello:
 > 
 > We are trying to execute an example of Orbit c++ using the naming
 > service in a computer with the next distribution:
 >     - Linux Mandrake 7.1
 >     - glib 1.2.8
 >     - ORBit 0.5.4
 >     - orbitcpp 0.29
 > 
 > The compilation is OK, but when we run the server it get some errors
 > like this:
 > 
 >     GLib-CRITICAL **: file gutils.c: line 249 (g_basename): assertion
 > `file_name != NULL' failed.
 >     CORBA::SystemException: ID (null), minor code = 0x5, completed = NO
 > 
 > Could you send us the server implementation in order to know if we have
 > a mistake in the source code or it is  an orbit problem?
 > 
 >     Our e-mail is:
 >                                  ech...@la...
 >                                  mca...@in...
 > 
 > Thank you very much.
 > 
 > _______________________________________________
 > orbitcpp-list mailing list
 > orb...@li...
 > http://lists.sourceforge.net/mailman/listinfo/orbitcpp-list
 > 
-------------------------------------------
Phil Dawes - Senior Consultant
BEA Professional Services
Tel: +44 7780 693052 (Mobile)

[orbitcpp-list] Orbit Name Service

[Esther <ech...@la...>]

Hello:

We are trying to execute an example of Orbit c++ using the naming
service in a computer with the next distribution:
    - Linux Mandrake 7.1
    - glib 1.2.8
    - ORBit 0.5.4
    - orbitcpp 0.29

The compilation is OK, but when we run the server it get some errors
like this:

    GLib-CRITICAL **: file gutils.c: line 249 (g_basename): assertion
`file_name != NULL' failed.
    CORBA::SystemException: ID (null), minor code = 0x5, completed = NO

Could you send us the server implementation in order to know if we have
a mistake in the source code or it is  an orbit problem?

    Our e-mail is:
                                 ech...@la...
                                 mca...@in...

Thank you very much.

[orbitcpp-list] CORBA_long_double type

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

G'day all.

I'm working on implementing Any in ORBit-C++, but have a problem.

The C++ mapping spec says that the CORBA::LongDouble type must be distinct
from other types for the purposes of overloading functions.
CORBA::LongDouble is typedef'd to ORBit's CORBA_long_double type, which is
in turn typedef'd to glib's gdouble type. CORBA::Double is likewise
typedef'd to ORBit's CORBA_double type, which is also typed to glib's
gdouble type. So the compiler can't tell them apart, and thinks the Any
insertion operator for CORBA::LongDouble is a redeclaration of the insertion
operator for CORBA::Double.

That's no good.

I tried changing the typedef for CORBA_long_double to "long double" (I would
have used glib's gldouble if it had been defined) and rebuilding ORBit, but
now if I try to send CORBA_long_double arguments I get garbage. I can't see
anywhere that has a size hard-coded. Yes, I rebuilt the IDL compiler as
well, and regenerated the stubs and skeletons with that.

Can anyone help me make CORBA_long_double a distinct type from CORBA_double?
Or more importantly, make CORBA::LongDouble distinct from CORBA::Double?
I don't really want to write a CORBA::LongDouble class and implement all the
standard arithmetic operators. :(
--=20
Sam Couter          |   Internet Engineer   |   http://www.topic.com.au/
sa...@to...    |   tSA Consulting      |
PGP key available on key servers
PGP key fingerprint:  A46B 9BB5 3148 7BEA 1F05  5BD5 8530 03AE DE89 C75C

Re: [orbitcpp-list] Problems with CosNaming ORBit

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

Hi Bruce,

Bruce Ide writes:
 > 
 > Does the ORBit in CVS play nice with gnome? Juggling ORBs gives me a
 > headache, and I'd like to have just one running on my system.

I'm afraid it doesn't, since AFAIK lots of the gnome stuff is
statically linked with stubs that don't play nice with cvs ORBit.

I do the following:

1) Install CVS ORBit in a different directory 
(./autogen.sh --prefix=/some/dir)

2) Start gnome

3) Once gnome is started (and all the stuff is running nicely), 
export LD_LIBRARY_PATH=/some/dir/lib:$LD_LIBRARY_PATH
export PATH=/some/dir/bin:$PATH

4) hack. (support for unions currently)


Hopefully the ORBit in CVS (or ORBit2) will become the gnome
ORBit soon - then all will be right with the world again. 

(either that, or we'll patch stable ORBit to support the features we
need to run orbitcpp without breaking gnome apps).

Cheers,

Phil

Re: [orbitcpp-list] Problems with CosNaming ORBit

[Bruce I. <bru...@ec...>]

>>>>> "Phil" == Phil Dawes <ph...@us...> writes:

    Phil> I strongly recommend that you upgrade to orbitcpp-0.29, and
    Phil> install the specially packaged version of ORBit cvs for that
    Phil> (details in the release notes for orbitcpp-0.29).

Does the ORBit in CVS play nice with gnome? Juggling ORBs gives me a
headache, and I'd like to have just one running on my system.

-- 
Bruce Ide                                            bru...@ec...
http://www.paratheoanametamystikhood.net

Re: [orbitcpp-list] Re: TypeCode for ORBit-C++

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

Sam Couter writes:
 > 
 > Heh. Check out page 56 of "The Common Object Request Broker: Architecture
 > and Specifications" for an example of C++ code where the return types from
 > create_recursive_tc() and create_value_tc() seem to be a TypeCode_var.
 > 

If the example is something like:

       // C++ 
       CORBA::TypeCode_var new_tc = orb->create_struct_tc(
                     "IDL:MyStruct:1.0",
                     "MyStruct",
                     mems
       );

Then the return type *is* CORBA::TypeCode_ptr, it's just that the
client is using an _var type to wrap it so that they don't have to
call CORBA::release() on the reference after use.

 > I'll modify the prototypes to match what you've suggested, for two reasons:
 > 1) It will match the C++ mapping correctly.
 > 2) I can't get it to work using TypeCode_var return types anyway. :)

Probably because the reference is being prematurely released by a
temporary _var. (Any C++ lawyers care to confirm or deny?)

Cheers,

Phil