orbitcpp-list

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

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

[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. :-)
-- 
##>  Petter Reinholdtsen  <##  |  pe...@td...

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

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

Hi all,

In order to help people get started with ORBit-C++, I've written a small
package with a helloworld and name service example.

I've also released orbitcpp-0.28.1 which fixes a bug in the .m4
configure macro. 

You can get the new release from the website:
http://orbitcpp.sourceforge.net/

and the orbitcpp-examples package from the ftp site:
ftp://orbitcpp.sourceforge.net/pub/orbitcpp/

Cheers,

Phil.

[orbitcpp-list] my patches to ORBit

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

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.

------------------------------------------------------------------------
from elliot:
------------------------------------------------------------------------

On Thu, 13 Apr 2000, Andreas Kloeckner wrote:

> Elliot Lee wrote:
> > 
> > On Thu, 13 Apr 2000, Andreas Kloeckner wrote:
> > 
> > > ORBit doesn't set the _maximum member of a sequence struct when
> > > demarshalling. The following patch against ORBit 0.5.1 fixes this.
> > 
> > _maximum is useless, realistically, unless demarshalling, 
> 
> but it's specified and we need it for orbit-c++.

I'm curious why :)

> > and your patch
> > doesn't set it correctly (because length can be smaller than maximum).
> 
> look closer. maximum = length only for unbounded sequences.

Hmm sorry.

-- Elliot
"Moron of the week" for four years running
------------------------------------------------------------------------
my reply: [sent apr 14]
------------------------------------------------------------------------

Elliot Lee wrote:
> > > _maximum is useless, realistically, unless demarshalling,
> >
> > but it's specified and we need it for orbit-c++.
> 
> I'm curious why :)

when implementing operator= for sequences, we use _maximum for
determining the size of the buffer to allocate. (_maximum needs to be
identical after assignment) now orbit gives us a zero _maximum,
resulting in no allocation, resulting in a CORBA::NO_MEMORY exception on
our side.

we could have a hacky workaround like max=length on our side, but this
is crap.

> > > and your patch
> > > doesn't set it correctly (because length can be smaller than maximum).
> >
> > look closer. maximum = length only for unbounded sequences.
> 
> Hmm sorry.

would you apply the patch? please? :)

cya
andy
------------------------------------------------------------------------

he has not answered or committed so far, so i've come to believe he is
nowhere near appreciating this patch. what can we do?

later
andy

Re: [orbitcpp-list] orbitcpp-0.28 released!

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

Claire Beckett wrote:
> [...]

^^^^^^^^^^^^^^
Doh! I forgot to change my mail reader to point to my email account
information rather than my girlfriend's before sending that mail.

Cheers,

Phil.

[orbitcpp-list] orbitcpp-0.28 released!

[Claire B. <ph...@us...>]

Hi folks,

ORBit-C++ version 0.28 is out, which adds C++ support for the ORBit name
service in addition to the latest fixes and improvements.

As usual, the web page is at:
http://orbitcpp.sourceforge.net/

BTW, don't forget to read the release notes before downloading.

Also, I'd appreciate it if people with specialist kit (i.e. not
intel-linux-g++) give this one a go, since it does some funky stuff with
operator new[], and I want to confirm its portability as far as
possible. A simple 'make check' after building will confirm that
everything is working appropriately.

Cheers,

Phil.

[orbitcpp-list] ORBit patches

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

Hi Andy,

Have all of the ORBit patches been applied to ORBit CVS? I'd like the
next version of ORBit to work with ORBit-C++ so that when we release
RPMs we don't have to also release 'special' ORBit RPMS.

Cheers,

Phil.

Re: [orbitcpp-list] POA functions

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

Hi Eric,

the POA is still an ad-hoc implementation, not much functionality except
what is needed for testing. if you've got some spare time, this would
certainly be a rewarding field of activity... :]

cya
andy


Eric Ross wrote:
> 
> Hi..
> 
> I'm looking for C++ equivalents (in C) to PortableServer_POA_create_POA
> and PortableServer_POA_find_POA. Are they implemented ? or someone is
> working on this ?
> 
> --
> Speak friend and enter
> 
> _______________________________________________
> orbitcpp-list mailing list
> orb...@li...
> http://lists.sourceforge.net/mailman/listinfo/orbitcpp-list

Re: [orbitcpp-list] POA functions

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

Eric Ross wrote:
> 
> Hi..
> 
> I'm looking for C++ equivalents (in C) to PortableServer_POA_create_POA
> and PortableServer_POA_find_POA. Are they implemented ? or someone is
> working on this ?
> 
> --
> Speak friend and enter
> 

Hi Eric,

I'm afraid not, however I'd imagine that implementing them is a fairly
trivial wrapping exercise given that they are already implemented in
ORBit C. There are already POA and POAManager classes, so adding this
functionality should be just a case of adding the methods to these
classes.

If you fancy the task, please bear in mind that in ORBit-C++ the C++
objects are binary compatible with their C counterparts - that is that
they only have one member: the C type. This allows reinterpret casting
between C and C++ types to marshal values back and forth to the ORBit C
core. Adding more members to a class breaks this binary compatibility.

If you fancy the task, please indicate this to the mailing list!

Many thanks for the interest,

Phil.

[orbitcpp-list] POA functions

[Eric R. <er...@ch...>]

Hi..

I'm looking for C++ equivalents (in C) to PortableServer_POA_create_POA
and PortableServer_POA_find_POA. Are they implemented ? or someone is
working on this ?

--
Speak friend and enter

Re: [orbitcpp-list] ORBit-cpp on win32

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

Andreas Kloeckner wrote:
> 
> Jose Felix Hernandez wrote:
> >
> >     Hello,
> >
> >     Could i use orbit-cpp on win32 ???
> >
> >     Thank you in advance.
> >
> >     Best regards.
> >
> 
> Hi Jose,
> 
> noone has tried this yet, but I don't know of any system-immanent
> bug/feature that should hinder this. If you have some time and
> frustration tolerance, go ahead. If you run into problems, always feel
> free to mail the list.
> 
> btw: try 0.27, not the cvs version. 0.27 is currently much more stable.
> 
> cya
> andy
> 

I'd try using cygwin (http://www.sourceware.cygnus.com/cygwin) to
compile it. I've successfully got glib and ORBit compiled on cygwin
before with minor hassles, and as Andreas said, I don't think ORBit-C++
should cause problems.

Cheers,

Phil.

Re: [orbitcpp-list] ORBit-cpp on win32

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

Jose Felix Hernandez wrote:
> 
>     Hello,
> 
>     Could i use orbit-cpp on win32 ???
> 
>     Thank you in advance.
> 
>     Best regards.
> 

Hi Jose,

noone has tried this yet, but I don't know of any system-immanent
bug/feature that should hinder this. If you have some time and
frustration tolerance, go ahead. If you run into problems, always feel
free to mail the list.

btw: try 0.27, not the cvs version. 0.27 is currently much more stable.

cya
andy

[orbitcpp-list] ORBit-cpp on win32

[Jose F. H. <gc...@fa...>]

    Hello,

    Could i use orbit-cpp on win32 ???

    Thank you in advance.

    Best regards.

--
Jose F. Hernandez Barrio
Universidad Politécnica de Madrid
c/ Ronda de Valencia, 3
28012 Madrid - Spain
Tel: +34 91 336 68 86

Re: [orbitcpp-list] Support for naming service!

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

On Tue, Apr 18, 2000 at 04:20:50PM +0000, Phil Dawes wrote:
> Hi Folks,
> 
> I've checked in some support for the CosNaming service, and a little
> manual test which seems to confirm that everything works as expected.

This is great news to hear.

> The library is called liborbitcppCosNaming, and I've named the header
> 'CosNaming.hh' (I used sed in the makefile to concatenate the common.hh
> and stubs.hh into one file), but I'm starting to wonder whether it
> should be called 'CosNaming-cpp.hh'. What do you think?

The compiler already generates CosNaming-cpp.hh to include common, stubs 
and skels headers. You might as well use this one. Of course, noone needs
the skels for the naming service, so we might implement the --nostubs,
--noskels --nocommon options now and use them for this.

cya
andy

Re: [orbitcpp-list] ORBITCPP_DECLARE_SIMPLE_SEQUENCE

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

On Tue, Apr 18, 2000 at 05:53:49PM +0000, Phil Dawes wrote:
> Hi Andreas,
> 
> I noticed that you wrote the ORBITCPP_DECLARE_SIMPLE_SEQUENCE macro, but 
> that it's not used by code written out by the compiler. Any reason?

Yes. The macro was just a dumb simple hack to allow easy declaration of 
PortableServer::ObjectId and similar "simple" sequence inside the orb/ code.

cya
andy

[orbitcpp-list] A 'new' problem ;-)

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

Hi Andreas, All,

I've been trying to use operator new() to allocate the space for
sequence types, however it seems to do a little more than I thought.

if you do blah[3]

it calls blah::operator new[](3*sizeof(blah) + <space for mem block>)

and then swizzles the pointer to hide the memory block - rather like
the memory alloc functions in ORBit. I've noticed that is only does
this if the type has a destructor, or nested destructors.

I've managed to get this working with the ORBit memory allocation
stuff on my linux box, but I used knowledge of what was in the C++
operator new[] memory block to do it, so I doubt it's portable, or 64
bit clean :-(

So now I'm looking for a portable way to allocate the memory (using
ORBit alloc functions) and invoke the constructors of the elements.

Idea1:
Allocate a seperate array with new[] and then allocate an ORBit block
of memory and copy the elements across
  + portable
  + simple
  - expensive, especially for big or nested structs.

Idea2:
Write some idl compiler logic to write out code which manually
allocates empty strings and objrefs after the block of memory has been
allocated.
  + portable
  - could be complex, especially for nested structures

Idea3: 
Determine the size of the operator new[] control block and write the
operation new[] as follows:

        pointer = sequence_alloc_function(num elements);
        return pointer - control block size

The C++ runtime will then 'hide' the control block by incrementing the
returned pointer, and invoke the relevant constructors.
Once the mem block is returned, deduct the size of the ORBit block to
get the 'real' first byte of allocated memory, then fill in an ORBit
block in the same way that the C sequence alloc function does.

  ~ dubiously portable (it looks portable to me, but who knows?
  + fairly simple
  + efficient
(n.b. the above pseudocode assumes that the ORBit block is bigger
than the operator new[] control block)

I'm going to implement idea3 for the time being. Please, does somebody
have a better idea?

Cheers,

Phil.

P.S. I've attached some code which deduces the size of the operator new
control block - it's 4 on my intel linux box for classes with a
destructor.

Re: [orbitcpp-list] Strings and sequences

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

Andreas Kloeckner wrote:
> 
> On Tue, Apr 18, 2000 at 05:34:47PM +0000, Phil Dawes wrote:
> > CORBA 2.3 requires that strings in structs and sequences be
> > initialised to "". This is solved for structs by using the String_mgr
> > class, whose constructor allocates an empty string.  However,
> > sequences present problems for the current implementation because we
> > use the ORBit C alloc functions for allocating sequences, and there is
> > no such 'empty string' requirement in the latest C spec.
> 
> I do not yet have the 2.3 spec. Arrays have no such requirement, right?
> Whereas every other aggregate (e.g., union, exception) falls under the
> struct'n'sequence rule?

I'm afraid arrays do have that requirement in 2.3:

Page 46 of the cpp mapping:
"If the array element is a string, wide-string or an object reference,
then the mapping uses the same type as for structure members. That is,
the default constructor for string elements and wide string elemnts
initializes them to the empty string"



> In that case, arrays is the special case and I think we'd like to name the
> new _mgr types you mention below like _mgr and _arraymgr.
> 
> > Candidate solution:
> >
> > We redefine operator new[] each time we create a sequence, which
> > invokes the underlying C allocation function. We then use the operator
> > new[] in allocbuf() instead of calling the C allocation function
> > direct. This should insure that the String_mgr constructor gets called
> > appropriately.
> 
> why not use the c allocation func in _allocbuf and do a placement new
> afterwards?

What's a placement new?
If you mean iterate over the sequence newing each element, then this
wont work because the seqence is an array of values (i.e. String_mgrs)
not pointers.

> 
> > Note that this approach must be used with any variable length type
> > containing a string. e.g.:
> 
> I can already see a needsConstructorInAggregates() method materialize
> in front of my eyes :[
> 

I'm using isVariableLength() to deduce this, since both sequences and
strings must initialise their members.

I've written an implementation which uses operator new[], by extending
the sequence template class hierarchy so that a new Elem type is defined
in the variable length sequence template on instansiation. This elem
type has its own operator new[] defined.

I've now got problems with operator new[], which I'll explain in the
next email.

Cheers,

Phil.

Re: [orbitcpp-list] Strings and sequences

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

On Tue, Apr 18, 2000 at 05:34:47PM +0000, Phil Dawes wrote:
> CORBA 2.3 requires that strings in structs and sequences be
> initialised to "". This is solved for structs by using the String_mgr
> class, whose constructor allocates an empty string.  However,
> sequences present problems for the current implementation because we
> use the ORBit C alloc functions for allocating sequences, and there is
> no such 'empty string' requirement in the latest C spec.

I do not yet have the 2.3 spec. Arrays have no such requirement, right?
Whereas every other aggregate (e.g., union, exception) falls under the 
struct'n'sequence rule?

In that case, arrays is the special case and I think we'd like to name the
new _mgr types you mention below like _mgr and _arraymgr.

> Candidate solution:
> 
> We redefine operator new[] each time we create a sequence, which
> invokes the underlying C allocation function. We then use the operator
> new[] in allocbuf() instead of calling the C allocation function
> direct. This should insure that the String_mgr constructor gets called
> appropriately.

why not use the c allocation func in _allocbuf and do a placement new 
afterwards?

> Note that this approach must be used with any variable length type
> containing a string. e.g.:

I can already see a needsConstructorInAggregates() method materialize
in front of my eyes :[

> Any comments, suggestions? Andreas - you're doing arrays; can you
> forsee any problems with this approach?

On first sight, no. But wait till I sleep over it :)

cya
andy

[orbitcpp-list] ORBITCPP_DECLARE_SIMPLE_SEQUENCE

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

Hi Andreas,

I noticed that you wrote the ORBITCPP_DECLARE_SIMPLE_SEQUENCE macro, but 
that it's not used by code written out by the compiler. Any reason?

Cheers,

Phil.

[orbitcpp-list] Strings and sequences

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

Hi All,

Once again, strings are causing headaches:

CORBA 2.3 requires that strings in structs and sequences be
initialised to "". This is solved for structs by using the String_mgr
class, whose constructor allocates an empty string.  However,
sequences present problems for the current implementation because we
use the ORBit C alloc functions for allocating sequences, and there is
no such 'empty string' requirement in the latest C spec.


Candidate solution:

We redefine operator new[] each time we create a sequence, which
invokes the underlying C allocation function. We then use the operator
new[] in allocbuf() instead of calling the C allocation function
direct. This should insure that the String_mgr constructor gets called
appropriately.

There is still a problem with this, since sequences and arrays have
seperate C allocation functions for variable length types, and you can
only define one operator new[] for each type in C++. I suggest we
remedy this by creating a version of String mgr for arrays and
sequence types - e.g.

struct orbitcpp_SequenceString_mgr : public String_mgr {
  static void *operator new[](size_t size);
};

struct orbitcpp_ArrayString_mgr : public String_mgr {
  static void *operator new[](size_t size);
};

Which allows us to create two operator new[]s.

Note that this approach must be used with any variable length type
containing a string. e.g.:


-------------- idl ----------------

struct foo {
  string str;
};

typedef sequence<foo> fooseq;

-------------- c++ ----------------

struct foo {
  String_mgr str;
};

struct orbitcpp_SequenceFoo : public foo {
  static void *operator new[](size_t size);
}

typedef _orbitcpp::SequenceTmpl<
orbitcpp_SequenceFoo,_orbitcpp::c::CORBA_sequence_foo> fooseq;

-----------------------------------

Any comments, suggestions? Andreas - you're doing arrays; can you
forsee any problems with this approach?

Cheers,

Phil.

[orbitcpp-list] Support for naming service!

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

Hi Folks,

I've checked in some support for the CosNaming service, and a little
manual test which seems to confirm that everything works as expected.

The library is called liborbitcppCosNaming, and I've named the header
'CosNaming.hh' (I used sed in the makefile to concatenate the common.hh
and stubs.hh into one file), but I'm starting to wonder whether it
should be called 'CosNaming-cpp.hh'. What do you think?

Cheers,

Phil.

Re: [orbitcpp-list] Updated Orbit-C++ FAQ

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

> 
> > 2.2. What software do I need to compile it?
> >
> > You will need the following software installed to
> > compile the source:
> >
> >         egcs [?]
> >         automake [?]
> >         autoconf [?]
> >         ORBit [?]
> >         glib [?]
> >         [any others?]
> 
> egcs-1.1 used to work for me until start of the month, I believe it
> still should be ok. gcc-2.95.2 is known to work.
> 

I think (as in an earlier post) that there is a problem with templates
and specialising operator new with egcs 1.1. I recommend anybody wanting
to build orbitcpp upgrades to gcc-2.95.2.

Cheers,

Phil.

Re: [orbitcpp-list] Compile Error

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

Mark Gunn wrote:
> 
> All,
> 
> I downloaded the new Orbitcpp release, but I am unable
> to compile it. I suspect that I didn't install the
> patched Orbit correctly. Do I need to uninstall/remove
> the previous version of Orbit? If so, how do I go
> about doing this?
> 
> I'm assuming that Orbitcpp looks uses certain files
> from Orbit. How do I ensure that it is looking in the
> right place?
> 
> The error I get is:
> 
> In file included from orbitcpp_poa.cc:30:
> ../orb/orbitcpp_poa.hh:49: template-id `operator
> new<>' for
> `::_orbitcpp::::_orbitcpp::SequenceTmpl<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: *** [orbitcpp_poa.lo] Error 1
> 
> Thanks,
> Mark
> 

Aha! - this looks like the 'operator new doesn't work with templates
with gcc version < 2.95.2' compiler bug. I'm afraid the fix is to
upgrade to gcc version 2.95.2. I upgraded mine using the rpms from the
rawhide section of the redhat ftp site.

Hope this helps,

Phil.

Re: [orbitcpp-list] switch to spaces

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

Andreas Kloeckner wrote:
> 
> Hi Phil, pholks :),
> 
> i've just made up my mind. tabs indeed are evil. let's do the switch to
> spaces asap [if you all agree]. when i've committed my array stuff, i'll
> be out of the tree for a little while [two weeks or so] for hacking a
> game with some pals. that would be a good time to do the conversion.
> what do you think?
> 
> cya
> andy
> 

Okay - looks like I'm out-voted! Spaces it is.
I'll use astyle or emacs on the archive sometime soon, with 1tab = 4
spaces.

BTW, what's the game?

Cheers,

Phil

Re: [orbitcpp-list] Updated Orbit-C++ FAQ

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

Hi Mark,

I'll fill in on what I can answer.

cya, and thx for the great work
andy


Mark Gunn wrote:
> 
> All,
> 
> Here is the updated FAQ. There are still unanswered
> questions left. So, if you've got any input, send it
> on and I'll be sure to incorporate it.
> 
> Note, I've marked my own comments and questions within
> brackets.
> 
> Thanks,
> Mark
> 


> 2.2. What software do I need to compile it?
> 
> You will need the following software installed to
> compile the source:
> 
>         egcs [?]
>         automake [?]
>         autoconf [?]
>         ORBit [?]
>         glib [?]
>         [any others?]

egcs-1.1 used to work for me until start of the month, I believe it
still should be ok. gcc-2.95.2 is known to work.

automake [i use 1.4]
autoconf [i use 2.13]
##new## libtool [i use 1.3.4, 1.3b is also okay]
ORBit [0.5.1 with our patches, see patches/README]
glib [1.2.3 is ok for me]

> 
> The version numbers listed are the minimum known to
> work. Make sure you have the development portions of
> ORBit and glib as well, otherwise you will be missing
> some of the required header files.
> 
> 2.3. How do I compile it?
> 
> First, you need to generate all the make files. In the
> top directory, run the "autogen.sh" script. Second,
> still in the top directory, run the command "make".
> This is also described in the INSTALL file.
> 
> [What is the difference between running the configure
> command and executing the autogen.sh script file?
> Also, I've noticed that the *.tar.gz file does not
> usually contain an autogen.sh script file.

autogen.sh generates 

aclocal.m4 <-- autoconf repository [/usr/share/aclocal] and acinclude.m4
[using aclocal]
configure <-- configure.in [using autoconf]
orb/orbitcpp_config.hh <-- configure.in [using autoheader]
Makefile.in <-- Makefile.am[using automake]

and finally runs ./configure $*.

> 
> 2.4. It's compiled, now what?
> 
> You need to install it. To do this, in the top
> directory run the command "make install". [Correct me
> if I'm wrong, but you need root priveledges to
> install.] 

that depends on where you install to. you need write privileges in 
{orbit_prefix}/lib/orbit-idl/.

for most installations, especially for ones from RPMs, this means you
need root privs to do "make install".

> This will allow you to use the orbit-idl
> command to generate the C and C++ bindings on IDL
> files.
> 
> 2.6 What is the name of the Orbit-C++ idl compiler?
> 
> It is orbit-idl.

[with the "-l c++" option]

> 
> 2.7 Is this the same as the Orbit idl compiler?
> 
> Yes. However, the Orbit-C++ idl compiler acts as a
> backend compiler to the Orbit idl compiler.
> 
> 3. Using
> 
> 3.1. How do I compile my IDL file?
> 
> Once you have compiled and installed the code, issue
> the following
> commands:
> 
>         orbit-idl -l c test.idl
>         orbit-idl -l c++ test.idl
> 
> This will generate the c++ code, which will wrap the
> generated c code.
> 
> 3.2. Why won't my IDL file compile?
> 
> Work on the idl-compiler is still in progress. [I'm
> not sure what is and isn't done; so, I removed what
> was here. Perhaps we could be vague here and reference
> the hacking file for features not implemented here. Or
> suggest they query the list. Suggestions?]

anything you list here will almost certainly go out of date fast. be
unspecific, the compiler usually reports some "not yet implemented"
message for things it doesn't know how to handle, in contrast to the old
python compiler that used to dump a stack trace and exit.

> 3.3. Why do the .cc files have "-cpp-" in the name?
> 
> ORBit-C++ generated files must be compiled with ORBit
> generated files. The "-cpp-" is added to prevent the
> object files from clashing. For instance:
> 
>         foo-stubs.c  -> foo-stubs.o
>         foo-stubs.cc -> foo-stubs.o
> 
> This is rectified by:
> 
>         foo-stubs.c      -> foo-stubs.o
>         foo-cpp-stubs.cc -> foo-cpp-stubs.o
> 
> 4. Development
> 
> 4.1. How can I help?
> 
> First, subscribe to the mailing list and read up on
> what work is currently being done. Secondly, check out
> the code and see if you can compile it. If this works,
> try some of the test cases. Whatever happens, let the
> mailing list know how you got on.
> 
> If you want to contribute code, look at the HACKING
> file to see what needs doing. Also, check with the
> mailing list as well. Writing test cases would also be
> useful. Of course, there is always more need for
> documentation.
> 
> 4.5. How do I submit code?
> 
> If you have write access to the SOURCEFORGE CVS

* how to get a sf login
* they can e-mail phil about write access to the tree
* "it's good habits to announce to the list before committing."

> archive, then just use the following command:
> 
>         $ cvs commit
> 
> If you have not got write access, then the best thing
> to do is create a unified diff patch against the CVS
> archive. You can do this with the following command:
> 
>         $ cvs -z3 diff -RNu ORBit-C++ > patchfile
> 
> This will pick up all of the changes you have made,
> including files that have been created or deleted. It
> is helpful if you put the date in the patch file name,
> something like "orbitcpp-19990814.patch" is good. Mail
> the patch file to the list and one of the core
> developers will apply it to the CVS archive. If you
> find yourself submitting a lot of patches,
> then it is time to get a write access account for the
> SOURCEFORGE CVS archive. Mail the list for details,
> although you will probably be spotted by one of the
> core developers first if it comes to this.
> 
> [There's a lot of good information information in
> HACKING file. Should we merge some of that information
> into here? Or keep it separate and just reference it
> from here?]

reference it. though the info is unlikely to change, it might, and we'd
have to change to documents. bah.

> 
> 5. Testing
> 
> 5.1 How do I test it?
> 
> Each directory under the test directory contains code
> for a simple test case. The README file explains what
> functionality is being tested and what to do.
> Generally, all you need to do is run make in the
> directory. If it builds, try the following commands:
> 
>         ./server > iorfile &
>         ./client `cat iorfile`

no more. 

./server &
./client

should be enough. "make check" will also do the trick. for the
"idl-torture" test, there's two ways:

* the ./run script in test/idl-torture
* libtool gdb orbit-idl in conjunction with test/idl-torture/.gdbinit

> 
> The output should give some indication of success or
> otherwise.
> 
> 6. Related Information
> 
> The CORBA 2.2 specification is available at:
> 
>         http://www.omg.org/corba/corbaiiop.html
> 
> [I'm not sure if this url is still valid. I tried
> checking it, but I couldn't get to the OMG site. So,
> I'll check it later.]
> 
> It is provided in PostScript and PDF formats, but
> there is no  (official) online version.
> 
> The ORBit homepage is at:
> 
>         http://www.labs.redhat.com/orbit/
> 
> __________________________________________________
> Do You Yahoo!?
> Send online invitations with Yahoo! Invites.
> http://invites.yahoo.com
> 
>   ------------------------------------------------------------------------
>                        Name: Orbit-C++_FAQ
>    Orbit-C++_FAQ       Type: application/x-unknown
>                    Encoding: base64
>                 Description: Orbit-C++_FAQ

Re: [orbitcpp-list] Compile Error

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

Hi Mark,

what version of gcc do you run? i have gcc-2.95.2 and all is well for
me. all versions of gcc before egcs-1.1[.1?] are known to break.

cya
andy

Mark Gunn wrote:
> 
> All,
> 
> I downloaded the new Orbitcpp release, but I am unable
> to compile it. I suspect that I didn't install the
> patched Orbit correctly. Do I need to uninstall/remove
> the previous version of Orbit? If so, how do I go
> about doing this?
> 
> I'm assuming that Orbitcpp looks uses certain files
> from Orbit. How do I ensure that it is looking in the
> right place?
> 
> The error I get is:
> 
> In file included from orbitcpp_poa.cc:30:
> ../orb/orbitcpp_poa.hh:49: template-id `operator
> new<>' for
> `::_orbitcpp::::_orbitcpp::SequenceTmpl<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: *** [orbitcpp_poa.lo] Error 1
> 
> Thanks,
> Mark
> 
> __________________________________________________
> Do You Yahoo!?
> Send online invitations with Yahoo! Invites.
> http://invites.yahoo.com
> 
> _______________________________________________
> orbitcpp-list mailing list
> orb...@li...
> http://lists.sourceforge.net/mailman/listinfo/orbitcpp-list