orbitcpp-list

Re: [orbitcpp-list] idl compiler pass classes

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

On Mon, Feb 28, 2000 at 01:48:24PM +0000, Phil dawes wrote:
> Hi Andreas,
> 
> Could we rename the files/classes from pass<N> (e.g. pass0, pass1 etc..)
> to skelpass stubpass or something like that?  - Just so that the code is
> more self-describing.

yup, go ahead, commit before 20:00 CET.. that's when I have time this evening.

cu
andy

[orbitcpp-list] idl compiler pass classes

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

Hi Andreas,

Could we rename the files/classes from pass<N> (e.g. pass0, pass1 etc..)
to skelpass stubpass or something like that?  - Just so that the code is
more self-describing.

Cheers,

Phil.

Re: [orbitcpp-list] idl compiler has arrived

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

Hi Andreas,

Andreas Kloeckner wrote:
> 
> Hi phil, hi list,
> 
>   the compiler's in sourceforge cvs. for me, it does compile, it does
> install, but it does not do anything even remotely sensible ;)

Everything compiles for me too (hurrah!). Ron - can you compile and run
the code on solaris - If there's a segfault problem I want to catch it
now.

> Some other things you should know about:
> 
> * configure.in now has special handling (should i say "kludge") for
> --enable-debug. I do not believe this is very well written, but heck, it
> prevents me from growing a dwarf's beard while compiling everything with
> "-O2" on.
> 

Okay. Actually I'd prefer that the default is to leave the debug code
in, and have an '--enable-optimized' or something for cast-iron
releases. That way we're more likely to be able to get people using
development releases to send us stack traces.

> * i put the two tests i had created so far in the tests directory. (they
> are basic/ and idl-torture/, where "basic" is just plain understatement
> for the kind of test. it features basic types, strings, typedefs,
> scoping, diamond of death inheritance, object reference passing back and
> forth, well, all this really _basic_ stuff B-> ... first job should be
> to get this baby working again, i guess.)
> 

Sounds good. BTW, the 'check' target is meant to run the tests rather
than build them - I couldn't get this to build so I've removed
idl-torture and basic from the test Makefile.am so that the global check
target runs. 
I'd like to aim to keep the 'make' and 'make check' global targets
always working, and we'll just add tests to them when they're finished
and working.

> * phil, i know you hate my indentation style, so if you want to do
> something about it (or got a tool to do so), now is the time. 

It's not just your code - I've been lazy and used about 3 or so
indentation styles during the course of developing ORBit-C++ so the code
isn't at all consistent.
I think we should choose one of the standard indentation styles and go
with it. I'll send a post later addressing this once I've found what I
did with that C++ indentation tool.

> (while
> you're at it, you may also make a mess of my nice-and-plain (tm) source
> file headers to keep things uniform) (if you tell me what to do, i will
> help out) (call this stage "one" (tm))

I use the 'stick a gnu license (gpl/lgpl) in every file' because that's
the way it has worked on other projects I've hacked with. This does mean
that anybody wishing to pinch code from the file immediately knows the
implications.

As regards copyrights, we've sort of used the informal 'the person who
creates the source file has the copyright, and anybody ammending the
file can add their name to the authors list in the file header' rule as
we've been developing (although I don't think anybody decided this). I'd
like to keep that if there isn't a good reason to change it.

> * and for the final and most important question: what is to be done
> next, after stage "one" (tm) is complete? ya, get the thing to work,
> right. i almost forgot. :) but in what order? and _who_ does _what_? i'm
> currently preparing for a math exam, so there's not too much time, i'll
> see what i can do. (say, an hour or so each day) first thing i would
> look into is doing some cleanup on the idl compiler, to remove the
> clearly o2cpp-specific parts (and perhaps code new ones for your
> runtime). yet, this requires completion of stage "one" (tm) :)
> 
> tell me about your plans. i wanna get goin'!
> 

Erm, good question!

I think:

1) Get the 'string test' stubs and skeletons in a shape that we're happy
with - that way we have an example of stubs and skeletons which allows
gives us something to shoot at.
Actually they are probably almost there now - I'd appreciate it if you
could have a look and check that there aren't some obscene optimisations
I'm missing or something that would make things much simpler. 

2) Aim the compiler at that.

3) Keep adding features...

As for who does what:
It'd probably be simpler if we split the compiler work into 'you do the
stubs, I'll do the skeletons' or something like that. 

Phil.

[orbitcpp-list] idl compiler has arrived

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

Hi phil, hi list,

  the compiler's in sourceforge cvs. for me, it does compile, it does
install, but it does not do anything even remotely sensible ;) 

Some other things you should know about:

* configure.in now has special handling (should i say "kludge") for
--enable-debug. I do not believe this is very well written, but heck, it
prevents me from growing a dwarf's beard while compiling everything with
"-O2" on.

* i put the two tests i had created so far in the tests directory. (they
are basic/ and idl-torture/, where "basic" is just plain understatement
for the kind of test. it features basic types, strings, typedefs,
scoping, diamond of death inheritance, object reference passing back and
forth, well, all this really _basic_ stuff B-> ... first job should be
to get this baby working again, i guess.)

* phil, i know you hate my indentation style, so if you want to do
something about it (or got a tool to do so), now is the time. (while
you're at it, you may also make a mess of my nice-and-plain (tm) source
file headers to keep things uniform) (if you tell me what to do, i will
help out) (call this stage "one" (tm)) 

* and for the final and most important question: what is to be done
next, after stage "one" (tm) is complete? ya, get the thing to work,
right. i almost forgot. :) but in what order? and _who_ does _what_? i'm
currently preparing for a math exam, so there's not too much time, i'll
see what i can do. (say, an hour or so each day) first thing i would
look into is doing some cleanup on the idl compiler, to remove the
clearly o2cpp-specific parts (and perhaps code new ones for your
runtime). yet, this requires completion of stage "one" (tm) :) 

tell me about your plans. i wanna get goin'!

cu
andy

PS:
phil> (I copied a load of naming conventions from Andreas' o2cpp ;-)

I just _love_ naming conventions ;)

[orbitcpp-list] orbitcpp-commits list working

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

Hi again,

The orbitcpp commits list now propogates commit messages from the new
sourceforge orbitcpp archive.
If anybody is interested in subscribing (probably only me, Ron and
Andrew), goto:
http://lists.sourceforge.net/mailman/listinfo/orbitcpp-commits

Cheers,

Phil.

Re: [orbitcpp-list] New ORBit-C++ CVS archive

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

Phil Dawes wrote:
> 
> Okay folks,
> 
> The new ORBit-C++ archive is available from sourceforge cvs. This is
> basically a copy of the new prototype with some code made neater (I
> copied a load of naming conventions from Andreas' o2cpp ;-)
> Anonymous cvs instructions can be found on:
> http://sourceforge.net/cvs/?group_id=646
> 
> Cheers,
> 
> Phil.
> 

One thing I didn't mention is that the new cvs modulename is orbitcpp
rather than ORBit-C++ (which was the modulename in the gnome cvs
archive).

Cheers,

Phil.

[orbitcpp-list] New ORBit-C++ CVS archive

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

Okay folks,

The new ORBit-C++ archive is available from sourceforge cvs. This is
basically a copy of the new prototype with some code made neater (I
copied a load of naming conventions from Andreas' o2cpp ;-)
Anonymous cvs instructions can be found on:
http://sourceforge.net/cvs/?group_id=646

Cheers,

Phil.

Re: [orbitcpp-list] Update on the new cvs repository and orbitcpp code

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

Hi Phil,


Phil dawes wrote:
> I've mostly prepared the code that I want to import into the new
> orbitcpp sourceforge CVS repository; I'm now just waiting on one of the
> sourceforge staff to upload a couple of scripts to the CVSROOT to enable
> the cvs-commits mailing list to work appropriately.

why not start working right away without the commits-list? I've got some
spare time right now as two of my exams (the CS ones) are done and two
more (the math ones) await being taken in later march.

> I haven't got a fantastic amount of time on my hands at the moment
> because of work pressures, so I'm going to upload some code which will
> need a bit of massaging to pull it in the right direction. I'm hoping
> that Andreas will be interested in helping out with this (in addition to
> the usual crowd) so that we can start the ball rolling.

I've got my massage sticks ready B-)

> Then I'd like Andreas to upload the latest version of his c++ idl
> compiler, and we'll then butcher it a bit so that it produces stubs and
> skeletons that work with the massaged orb runtime.

I'll get going as soon as the CVS tree accepts commits by me ("inducer"
at sourceforge). Or do you want to start off without CVS, with me just
uploading a .tar.gz to my website?

> Does that sound like a good plan?

Yep. Let's get going then...

> 
> Cheers,
> 
> Phil.

Shalom,
Andreas

Re: [orbitcpp-list] running orbitcpp client and server programs from separate machines

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

Bill Lasley wrote:
> 
> Phil,
> 
> I downloaded, built, and installed ORBit 0.5.1, and then I went to your site
> and downloaded orbitcpp-0.25.1.  I ran ./configure, but the make reported
> errors trying to build the test programs.  I removed the test directory from
> the list of targets and was then able to complete the make and make install,
> but when I try to run make on my app, I get the following error:
> 
> orbit-idl2cpp ../admanager.idl
> Traceback (innermost last):
>   File "/usr/local/bin/orbit-idl2cpp", line 11, in ?
>     from orbit_idl2cpp.commonfile import CommonGenerator
> ImportError: cannot import name CommonGenerator
> make[2]: *** [admanager.hh] Error 1
> 
> If it makes any difference, I am running RedHat 6.1, which came with gcc
> version egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)
> 
> So here are my questions:
> 
> - Does the idl2cpp error above look familiar?  Is there an easy fix?  Sorry
> to bug you with this, but I really don't know anything about python.
> 

I think it's a missing PYTHONPATH error - have you read README.PYTHON?

> - Is there a devel version of orbitcpp 0.25.1 that I also need, or does your
> tar file have everything required for development?
> 

The tar file should contain everything. BTW, If you haven't already, I
recommend you uninstall the redhat orbitcpp rpm before attempting to
build/install ORBit-C++.

Hope this helps,

Phil.

Re: [orbitcpp-list] running orbitcpp client and server programs from separate machines

[Bill L. <the...@ya...>]

Phil,

I downloaded, built, and installed ORBit 0.5.1, and then I went to your site
and downloaded orbitcpp-0.25.1.  I ran ./configure, but the make reported
errors trying to build the test programs.  I removed the test directory from
the list of targets and was then able to complete the make and make install,
but when I try to run make on my app, I get the following error:

orbit-idl2cpp ../admanager.idl
Traceback (innermost last):
  File "/usr/local/bin/orbit-idl2cpp", line 11, in ?
    from orbit_idl2cpp.commonfile import CommonGenerator
ImportError: cannot import name CommonGenerator
make[2]: *** [admanager.hh] Error 1

If it makes any difference, I am running RedHat 6.1, which came with gcc
version egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)

So here are my questions:

- Does the idl2cpp error above look familiar?  Is there an easy fix?  Sorry
to bug you with this, but I really don't know anything about python.

- Is there a devel version of orbitcpp 0.25.1 that I also need, or does your
tar file have everything required for development?


Thanks.

-Bill Lasley



--- Phil Dawes <ph...@or...> wrote:
> Bill Lasley writes:
>  > Hi,
>  > 
>  > I installed ORBit-0.5.0-1, ORBit-devel-0.5.0-1,  orbitcpp-0.22-1, and
>  > orbitcpp-0.22-1 on three machines, all running RedHat 6.1.  As far as
> I
>  > can tell, all three machines have similar network configurations.
>  > 
>  > I built and ran the simple helloworld sample on various combinations
> of
>  > these machines (call them A, B, and C).
>  > 
>  > I perverted the sample slightly so that the programs could read and
>  > write IOR strings from an LDAP server on A.
>  > 
>  > Running server on A and client on A works.
>  > Running server on B and client on B works.
>  > Running server on C and client on C works.
>  > 
>  > Running server on A and client on B works.
>  > Running server on B and client on A works.
>  > 
>  > Running server on A and client on C causes the client to crash and
> dump
>  > core.
>  > Running server on C and client on A causes the client to crash and
> dump
>  > core.
>  > 
>  > I added code to trap exceptions in the client program, and it appears
> to
>  > be a system exception, minor code of 5, thrown when the client
> program
>  > calls the _narrow() function.
>  > 
>  > I can't figure out why the sample works for A and B but not for A and
>  > C.  I thought maybe C might have too low a limit on open file
>  > descriptors, but that was not the case (1024 for all machines).
>  > 
>  > Is there a particular setting that causes client crashes (untrapped
>  > exception, minor code 5) when the orbitcpp helloworld samples are run
> on
>  > two separate machines?
>  > 
>  > The ORBit source code looks like a steep learning curve, so I thought
>  > I would ask around before I go any further into the source, in case
>  > there is something very simple wrong here.   I am not very
> knowledgeable
>  > about CORBA in general, which is why I used the ldap server instead
> of
>  > the orbit name server.
>  > 
>  > If anybody has any suggestions, I am (like Ross Perot) all ears.
>  > 
> 
> Hi Bill,
> 
> There was a dodgy memory bug in that version, and it didn't get fixed
> (because I couldn't repeat it ;-) until version 0.25.1.
> I suggest you get ORBit-0.5.1 and orbitcpp-0.25.1 (from
> ftp://orbitcpp.sourceforge.net/pub/orbitcpp)
> 
> Hope this helps,
> 
> Phil.
> 
> _______________________________________________
> orbitcpp-list mailing list
> orb...@li...
> http://lists.sourceforge.net/mailman/listinfo/orbitcpp-list
> 
__________________________________________________
Do You Yahoo!?
Talk to your friends online with Yahoo! Messenger.
http://im.yahoo.com

Re: [orbitcpp-list] running orbitcpp client and server programs from separate machines

[Bill L. <the...@ya...>]

Phil,

Thanks for your response.  

I am not sure that we are both talking about the same
problem, though, because the crash I referred to in my
previous message is completely reproducible--it
happens every time I try to run the sample on machines
A and C or B and C.  However, I will try the later
versions and let you know if that fixes the problem.

-Bill Lasley

--- Phil Dawes <ph...@or...>
wrote:
> Bill Lasley writes:
>  > Hi,
>  > 
>  > I installed ORBit-0.5.0-1, ORBit-devel-0.5.0-1, 
> orbitcpp-0.22-1, and
>  > orbitcpp-0.22-1 on three machines, all running
> RedHat 6.1.  As far as
> I
>  > can tell, all three machines have similar network
> configurations.
>  > 
>  > I built and ran the simple helloworld sample on
> various combinations
> of
>  > these machines (call them A, B, and C).
>  > 
>  > I perverted the sample slightly so that the
> programs could read and
>  > write IOR strings from an LDAP server on A.
>  > 
>  > Running server on A and client on A works.
>  > Running server on B and client on B works.
>  > Running server on C and client on C works.
>  > 
>  > Running server on A and client on B works.
>  > Running server on B and client on A works.
>  > 
>  > Running server on A and client on C causes the
> client to crash and
> dump
>  > core.
>  > Running server on C and client on A causes the
> client to crash and
> dump
>  > core.
>  > 
>  > I added code to trap exceptions in the client
> program, and it appears
> to
>  > be a system exception, minor code of 5, thrown
> when the client
> program
>  > calls the _narrow() function.
>  > 
>  > I can't figure out why the sample works for A and
> B but not for A and
>  > C.  I thought maybe C might have too low a limit
> on open file
>  > descriptors, but that was not the case (1024 for
> all machines).
>  > 
>  > Is there a particular setting that causes client
> crashes (untrapped
>  > exception, minor code 5) when the orbitcpp
> helloworld samples are run
> on
>  > two separate machines?
>  > 
>  > The ORBit source code looks like a steep learning
> curve, so I thought
>  > I would ask around before I go any further into
> the source, in case
>  > there is something very simple wrong here.   I am
> not very
> knowledgeable
>  > about CORBA in general, which is why I used the
> ldap server instead
> of
>  > the orbit name server.
>  > 
>  > If anybody has any suggestions, I am (like Ross
> Perot) all ears.
>  > 
> 
> Hi Bill,
> 
> There was a dodgy memory bug in that version, and it
> didn't get fixed
> (because I couldn't repeat it ;-) until version
> 0.25.1.
> I suggest you get ORBit-0.5.1 and orbitcpp-0.25.1
> (from
> ftp://orbitcpp.sourceforge.net/pub/orbitcpp)
> 
> Hope this helps,
> 
> Phil.
> 
> _______________________________________________
> orbitcpp-list mailing list
> orb...@li...
>
http://lists.sourceforge.net/mailman/listinfo/orbitcpp-list
> 
__________________________________________________
Do You Yahoo!?
Talk to your friends online with Yahoo! Messenger.
http://im.yahoo.com

[orbitcpp-list] Update on the new cvs repository and orbitcpp code

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

Hi folks,

Just to keep people in the loop:

I've mostly prepared the code that I want to import into the new
orbitcpp sourceforge CVS repository; I'm now just waiting on one of the
sourceforge staff to upload a couple of scripts to the CVSROOT to enable
the cvs-commits mailing list to work appropriately.
You can get to the commits mailing list through:
http://sourceforge.net/mail/?group_id=646
At the moment it forwards commits to the gnome ORBit-C++ cvs repository.

I haven't got a fantastic amount of time on my hands at the moment
because of work pressures, so I'm going to upload some code which will
need a bit of massaging to pull it in the right direction. I'm hoping
that Andreas will be interested in helping out with this (in addition to
the usual crowd) so that we can start the ball rolling.

Then I'd like Andreas to upload the latest version of his c++ idl
compiler, and we'll then butcher it a bit so that it produces stubs and
skeletons that work with the massaged orb runtime.

Does that sound like a good plan?

Cheers,

Phil.

Re: [orbitcpp-list] running orbitcpp client and server programs from separate machines

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

Bill Lasley writes:
 > Hi,
 > 
 > I installed ORBit-0.5.0-1, ORBit-devel-0.5.0-1,  orbitcpp-0.22-1, and
 > orbitcpp-0.22-1 on three machines, all running RedHat 6.1.  As far as
I
 > can tell, all three machines have similar network configurations.
 > 
 > I built and ran the simple helloworld sample on various combinations
of
 > these machines (call them A, B, and C).
 > 
 > I perverted the sample slightly so that the programs could read and
 > write IOR strings from an LDAP server on A.
 > 
 > Running server on A and client on A works.
 > Running server on B and client on B works.
 > Running server on C and client on C works.
 > 
 > Running server on A and client on B works.
 > Running server on B and client on A works.
 > 
 > Running server on A and client on C causes the client to crash and
dump
 > core.
 > Running server on C and client on A causes the client to crash and
dump
 > core.
 > 
 > I added code to trap exceptions in the client program, and it appears
to
 > be a system exception, minor code of 5, thrown when the client
program
 > calls the _narrow() function.
 > 
 > I can't figure out why the sample works for A and B but not for A and
 > C.  I thought maybe C might have too low a limit on open file
 > descriptors, but that was not the case (1024 for all machines).
 > 
 > Is there a particular setting that causes client crashes (untrapped
 > exception, minor code 5) when the orbitcpp helloworld samples are run
on
 > two separate machines?
 > 
 > The ORBit source code looks like a steep learning curve, so I thought
 > I would ask around before I go any further into the source, in case
 > there is something very simple wrong here.   I am not very
knowledgeable
 > about CORBA in general, which is why I used the ldap server instead
of
 > the orbit name server.
 > 
 > If anybody has any suggestions, I am (like Ross Perot) all ears.
 > 

Hi Bill,

There was a dodgy memory bug in that version, and it didn't get fixed
(because I couldn't repeat it ;-) until version 0.25.1.
I suggest you get ORBit-0.5.1 and orbitcpp-0.25.1 (from
ftp://orbitcpp.sourceforge.net/pub/orbitcpp)

Hope this helps,

Phil.

[orbitcpp-list] running orbitcpp client and server programs from separate machines

[Bill L. <bl...@mi...>]

Hi,

I installed ORBit-0.5.0-1, ORBit-devel-0.5.0-1,  orbitcpp-0.22-1, and
orbitcpp-0.22-1 on three machines, all running RedHat 6.1.  As far as I
can tell, all three machines have similar network configurations.

I built and ran the simple helloworld sample on various combinations of
these machines (call them A, B, and C).

I perverted the sample slightly so that the programs could read and
write IOR strings from an LDAP server on A.

Running server on A and client on A works.
Running server on B and client on B works.
Running server on C and client on C works.

Running server on A and client on B works.
Running server on B and client on A works.

Running server on A and client on C causes the client to crash and dump
core.
Running server on C and client on A causes the client to crash and dump
core.

I added code to trap exceptions in the client program, and it appears to
be a system exception, minor code of 5, thrown when the client program
calls the _narrow() function.

I can't figure out why the sample works for A and B but not for A and
C.  I thought maybe C might have too low a limit on open file
descriptors, but that was not the case (1024 for all machines).

Is there a particular setting that causes client crashes (untrapped
exception, minor code 5) when the orbitcpp helloworld samples are run on
two separate machines?

The ORBit source code looks like a steep learning curve, so I thought
I would ask around before I go any further into the source, in case
there is something very simple wrong here.   I am not very knowledgeable
about CORBA in general, which is why I used the ldap server instead of
the orbit name server.

If anybody has any suggestions, I am (like Ross Perot) all ears.

Thanks.

--Bill Lasley

Re: [orbitcpp-list] Errors trying to make orbitcpp-0.25.1

[Darwin Z. <dz...@mi...>]

Either it's newbie'ism or I'm just stupid, but with the gcc 2.95.2 that I built
from source I get this error when trying to do the make on orbitcpp:

make[4]: Entering directory
`/home/dzins1/src/orbitcpp-0.25.1/test/string/generated'
c++ -DHAVE_CONFIG_H -I. -I. -I../../.. -I../../..  -I/usr/lib/glib/include -I
-I/usr/lib/glib/include -I/usr/include     -g -O0  -c stringtest-cpp-stubs.cc
stringtest-cpp-stubs.cc: In method `char * test::StringTester_stub::op(const char
*, char *&, CORBA::String_out)':
stringtest-cpp-stubs.cc:75: passing `const char *' as argument 2 of
`ORBIT_C::test_StringTester_op(ORBIT_C::CORBA_Object_struct *, CORBA_char *,
CORBA_char **, CORBA_char **, ORBIT_C::CORBA_Environment *)' discards qualifiers
make[4]: *** [stringtest-cpp-stubs.o] Error 1
make[4]: Leaving directory
`/home/dzins1/src/orbitcpp-0.25.1/test/string/generated'
make[3]: *** [all-recursive] Error 1
make[3]: Leaving directory `/home/dzins1/src/orbitcpp-0.25.1/test/string'
make[2]: *** [all-recursive] Error 1
make[2]: Leaving directory `/home/dzins1/src/orbitcpp-0.25.1/test'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/home/dzins1/src/orbitcpp-0.25.1'
make: *** [all-recursive-am] Error 2

When I try to use gcc from the rpms from redhat when I run the configure script I
get the following error:

checking for c++... c++
checking whether the C++ compiler (c++  ) works... no
configure: error: installation or configuration problem: C++ compiler cannot
create executables.

Thanks again for any help.  The packages I had before were egcs packages (came
with RedHat 6.1).  I downloaded the ones you pointed to in /pub/rawhide, but they
were gcc packages, I don't know if that makes a difference.  I did install
binutils gcc gcc-c++ cpp using rpm -Uvh.

I'm really interested in your project.

Darwin

Phil Dawes wrote:

> Darwin Zins wrote:
> >
> > Thanks, you know I even saw that in the archives, but it didn't dawn on me...
> >
> > Are there an options when configuring gcc that you suggest I should enable?
> >
> > Thanks,
> >
> > Darwin
> >
>
> Not that I know of - a stock gcc 2.95.2 build should do the trick.
> <lamer>
> I run linux so I just got my copy of gcc-2.95.2 as a redhat package from
> ftp.redhat.com/pub/rawhide
> </lamer>
>
> Cheers,
>
> Phil.
>
> _______________________________________________
> orbitcpp-list mailing list
> orb...@li...
> http://lists.sourceforge.net/mailman/listinfo/orbitcpp-list

Re: [orbitcpp-list] Errors trying to make orbitcpp-0.25.1

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

Darwin Zins wrote:
> 
> Thanks, you know I even saw that in the archives, but it didn't dawn on me...
> 
> Are there an options when configuring gcc that you suggest I should enable?
> 
> Thanks,
> 
> Darwin
> 

Not that I know of - a stock gcc 2.95.2 build should do the trick. 
<lamer>
I run linux so I just got my copy of gcc-2.95.2 as a redhat package from
ftp.redhat.com/pub/rawhide
</lamer>

Cheers,

Phil.

Re: [orbitcpp-list] Errors trying to make orbitcpp-0.25.1

[Darwin Z. <dz...@mi...>]

Thanks, you know I even saw that in the archives, but it didn't dawn on me...

Are there an options when configuring gcc that you suggest I should enable?

Thanks,

Darwin

Phil Dawes wrote:

> Darwin Zins wrote:
> >
> > This is what I get:
> >
> > make[4]: Entering directory
> > `/home/dzins1/src/orbitcpp-0.25.1/test/sequence/generated'
> > c++ -DHAVE_CONFIG_H -I. -I. -I../../.. -I../../..
> > -I/usr/lib/glib/include -I -I/usr/lib/glib/include -I/usr/include     -g
> > -O0  -c sequence-cpp-stubs.cc
> > In file included from sequence-cpp-stubs.cc:2:
> > sequence.hh:35: template-id `operator new<>' for
> >
>
> The problem is that you need a newer versin of gcc - gcc version 2.95.2
> doesn't have this problem.
>
> Hope this helps,
>
> Phil.
>
> _______________________________________________
> orbitcpp-list mailing list
> orb...@li...
> http://lists.sourceforge.net/mailman/listinfo/orbitcpp-list

[orbitcpp-list] orbitcpp proof of concept

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

>>>>> "pd" == Phil Dawes <ph...@or...> writes:

    pd> Hi Andreas, Ron and everybody, I've finally uploaded a copy of
    pd> my little proof-of-concept prototype for the new ultra-thin
    pd> orbitcpp architecture onto the ftp site.
    pd> ftp://orbitcpp.sourceforge.net/pub/orbitcpp/ This basically
    pd> uses the binary compatibility between C and C++ objrefs to
    pd> eliminate the need for stateful wrapper instances for things
    pd> like orb and poa. Instead, the C++ object has the same binary
    pd> footprint as the C one, and so the two are interchangable
    pd> using reinterpret_casts. If you have a look at the actual
    pd> method implementations in Object.cc, ORB.cc etc.. you'll see
    pd> how this works.

    pd> I adapted the string example to demonstrate how the stubs
    pd> would look under the new regieme.

cool beans,

I've been really swamped lately so I have been pretty much useless,
but I'll take a look-see as soon as I get a chance.

ron

[orbitcpp-list] orbitcpp proof of concept

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

Hi Andreas, Ron and everybody,

I've finally uploaded a copy of my little proof-of-concept prototype for
the new ultra-thin orbitcpp architecture onto the ftp site.
ftp://orbitcpp.sourceforge.net/pub/orbitcpp/
This basically uses the binary compatibility between C and C++ objrefs
to eliminate the need for stateful wrapper instances for things like orb
and poa. Instead, the C++ object has the same binary footprint as the C
one, and so the two are interchangable using reinterpret_casts. If you
have a look at the actual method implementations in Object.cc, ORB.cc
etc.. you'll see how this works.

I adapted the string example to demonstrate how the stubs would look
under the new regieme.

BTW, To implement the prototype I just ripped off the old ORBit-C++
runtime code - it's still in need of a rewrite to clean things up. 

Cheers,

Phil

P.S. I'll try and have a good look at the idl compiler code in o2cpp
tomorrow night with a view to setting up a new source repository.

Re: [orbitcpp-list] Errors trying to make orbitcpp-0.25.1

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

Darwin Zins wrote:
> 
> This is what I get:
> 
> make[4]: Entering directory
> `/home/dzins1/src/orbitcpp-0.25.1/test/sequence/generated'
> c++ -DHAVE_CONFIG_H -I. -I. -I../../.. -I../../..
> -I/usr/lib/glib/include -I -I/usr/lib/glib/include -I/usr/include     -g
> -O0  -c sequence-cpp-stubs.cc
> In file included from sequence-cpp-stubs.cc:2:
> sequence.hh:35: template-id `operator new<>' for
> 

The problem is that you need a newer versin of gcc - gcc version 2.95.2
doesn't have this problem.

Hope this helps,

Phil.

Re: [orbitcpp-list] Errors trying to make orbitcpp-0.25.1

[Darwin Z. <dz...@mi...>]

This is what I get:

make[4]: Entering directory
`/home/dzins1/src/orbitcpp-0.25.1/test/sequence/generated'
c++ -DHAVE_CONFIG_H -I. -I. -I../../.. -I../../..
-I/usr/lib/glib/include -I -I/usr/lib/glib/include -I/usr/include     -g
-O0  -c sequence-cpp-stubs.cc
In file included from sequence-cpp-stubs.cc:2:
sequence.hh:35: template-id `operator new<>' for
`::ORBIT_CPP::::ORBIT_CPP::SequenceTmpl<::CORBA::String_mgr,::ORBIT_C::CORBA_sequence_CORBA_string,::test::CORBA_sequence_CORBA_string_cppseqstruct>::operator
new<>(size_t)' does not match any template declaration
sequence.hh:35: confused by earlier errors, bailing out
make[4]: *** [sequence-cpp-stubs.o] Error 1
make[4]: Leaving directory
`/home/dzins1/src/orbitcpp-0.25.1/test/sequence/generated'
make[3]: *** [all-recursive] Error 1
make[3]: Leaving directory
`/home/dzins1/src/orbitcpp-0.25.1/test/sequence'
make[2]: *** [all-recursive] Error 1
make[2]: Leaving directory `/home/dzins1/src/orbitcpp-0.25.1/test'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/home/dzins1/src/orbitcpp-0.25.1'
make: *** [all-recursive-am] Error 2

Thanks again for any help.

Darwin

Ronald Garcia wrote:

> Hey darwin,
> >>>>> "dz" == Darwin Zins <dz...@mi...> writes:
>
>     dz> Hi,
>
>     dz> I downloaded orbitcpp-0.25.1.tar.gz, untarred it, typed
>     dz> ./configure in the orbitcpp-0.25.1 directory and then typed
>     dz> make.  make comes up with an error in
>     dz> test/sequence/generated/sequence.hh on line 31.
>
>     dz> Am I doing something wrong?
>
> what is the error exactly? could you post it to the list?
>
> ron
>
> _______________________________________________
> orbitcpp-list mailing list
> orb...@li...
> http://lists.sourceforge.net/mailman/listinfo/orbitcpp-list

[orbitcpp-list] Errors trying to make orbitcpp-0.25.1

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

Hey darwin,
>>>>> "dz" == Darwin Zins <dz...@mi...> writes:

    dz> Hi,

    dz> I downloaded orbitcpp-0.25.1.tar.gz, untarred it, typed
    dz> ./configure in the orbitcpp-0.25.1 directory and then typed
    dz> make.  make comes up with an error in
    dz> test/sequence/generated/sequence.hh on line 31.

    dz> Am I doing something wrong?

what is the error exactly? could you post it to the list?

ron

[orbitcpp-list] Errors trying to make orbitcpp-0.25.1

[Darwin Z. <dz...@mi...>]

Hi,

I downloaded orbitcpp-0.25.1.tar.gz, untarred it, typed ./configure in
the orbitcpp-0.25.1 directory and then typed make.  make comes up with
an error in test/sequence/generated/sequence.hh on line 31.

Am I doing something wrong?

Thanks for any help,

Darwin

[orbitcpp-list] OOps - forgot the url for the ftp site

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

ftp://orbitcpp.sourceforge.net/pub/orbitcpp/orbitcpp-0.25.1.tar.gz  

Cheers,

Phil.

Re: [orbitcpp-list] everyone still alive?

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

Andreas Kloeckner wrote:
> 
> Hi,
> 
>   what has happened? Is everyone still alive? The last thing I've been
> hearing was something about sourceforge cvs and a new source tree. what
> is everyone doing currently? phil?
> 
> cu
> andreas
> 

Hi Andreas,
Sorry about the delay - I've been in London all week with work and cut
off from the internet (well, at least from my linux box). I've taken
tomorrow (monday) off work so hopefully I'll have time to set things up
then.
I pretty much had the prototype string test example of the new orb
architecture working before I left, so I'll finish that off and post it
to the ftp site asap.

BTW, there's a new intermediate release of ORBit-C++ on the ftp site -
this fixes a memory bug, and may (you never know) sort out Ron's solaris
problem.

Cheers,

Phil.