orbitcpp-list

[orbitcpp-list] errors when running autogen.sh

[Mark G. <mar...@ya...>]

Hello all,

I am trying to build everything from cvs, but I get
the following errors when running autogen.sh. (Note I
was able to build everything from *.tar.gz file. From
the looks of the error messages, I'm assuming I need
to specify some values, but I'm not sure what or
where.

Is there something else I need to do before I run
autogen.sh?

Any help would be greatly appreciated.
Thanks,
Mark

Error output:

I am going to run ./configure with no arguments - if
you wish 
to pass any to it, please specify them on the
./autogen.sh command line.
processing .
You should add the contents of
`/usr/share/aclocal/libtool.m4' to `aclocal.m4'.
aclocal: configure.in: 82: macro `AM_PATH_ORBIT' not
found in library
Makefile.am:5: HAVE_ORBIT_IDL_BACKENDDIR does not
appear in AM_CONDITIONAL
configure.in: 96: required file
`orb/orbitcpp_config.hh.in' not found
orb/Makefile.am:31: variable `ORBIT_LIBS' not defined
test/idl-torture/Makefile.am:21:
HAVE_ORBIT_IDL_BACKENDDIR does not appear in
AM_CONDITIONAL
test/basic/Makefile.am:4: variable `ORBIT_LIBS' not
defined
test/basic/Makefile.am:4: variable `ORBIT_LIBS' not
defined
test/basic/generated/Makefile.am:21:
HAVE_ORBIT_IDL_BACKENDDIR does not appear in
AM_CONDITIONAL
test/string/Makefile.am:6: variable `ORBIT_LIBS' not
defined
test/string/Makefile.am:6: variable `ORBIT_LIBS' not
defined
test/string/generated/Makefile.am:21:
HAVE_ORBIT_IDL_BACKENDDIR does not appear in
AM_CONDITIONAL
test/boolean/Makefile.am:6: variable `ORBIT_LIBS' not
defined
test/boolean/Makefile.am:6: variable `ORBIT_LIBS' not
defined
test/boolean/generated/Makefile.am:21:
HAVE_ORBIT_IDL_BACKENDDIR does not appear in
AM_CONDITIONAL
test/everything/Makefile.am:6: variable `ORBIT_LIBS'
not defined
test/everything/Makefile.am:6: variable `ORBIT_LIBS'
not defined
test/everything/generated/Makefile.am:21:
HAVE_ORBIT_IDL_BACKENDDIR does not appear in
AM_CONDITIONAL
test/everything-typedef/Makefile.am:6: variable
`ORBIT_LIBS' not defined
test/everything-typedef/Makefile.am:6: variable
`ORBIT_LIBS' not defined
test/everything-typedef/generated/Makefile.am:21:
HAVE_ORBIT_IDL_BACKENDDIR does not appear in
AM_CONDITIONAL
Running ./configure --enable-maintainer-mode
loading cache ./config.cache
./configure: line 552: syntax error near unexpected
token `AM_INIT_AUTOMAKE($PACKAGE,'
./configure: line 552: `AM_INIT_AUTOMAKE($PACKAGE,
$VERSION, no-define)'

Now type 'make' to compile ORBit-C++.

__________________________________________________
Do You Yahoo!?
Send online invitations with Yahoo! Invites.
http://invites.yahoo.com

[orbitcpp-list] the whoppin' funky bunch

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

Hi Phil & all,

tonight I've dumped a load of code and fixes back to cvs. (now that
finally all tests work <phew>). to enjoy the new version to the fullest
8-)))) you need to apply a patch to ORBit (about sequence handling), it
is located in the patches/ subdir of the repository. (new)

for the last three days i've been mainly busy hunting down spurious
segfaults, if you want to know more about them, look in the new
"mini-FAQ".

furthermore, i guess the code is quite ready for 0.27. [i've still got
two little improvements in mind that i want to have in that version, so
please don't release before about tomorrow afternoon] btw, in features
we're almost level with the old Python ORBit-C++, while my old o2cpp
'basic' test is also working. our current state probably isn't all too
bad B-)))))

for your schedule, i'll be hacking unions and constants tomorrow.

cya
andy

[orbitcpp-list] orbitcpp_sequence

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

Hi Phil,

we've been stepping on each other's toes reimplementing
orbitcpp_sequence.hh. sorry for any inconvenience.

cu
andy

Re: [orbitcpp-list] problem with emacs and tab formatting!

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

Andreas Kloeckner wrote:
> 
> > Andreas - what do you think? Does this sound over complicated? - Maybe
> > we should move to spaces?
> 
> Uh. Just when I started to like 'em (the tabs). On this particular
> issue, I like the
> 
> SomeDamnLongMethodName(arg1,arg2,
>         arg3,arg4,arg5,...)
> ^ one tab
> 
> style better. But heck, if you want to switch to spaces, do it. Main
> thing is the whole thing remains readable.
> 

Agreed! I think I'm going to stick to tabs for at least the next few
days while I attempt to get an emacs CC mode fix together. (just bought
the giraffe emacs extensions book). If that's too hard, then I think
I'll give up and move to spaces.

Cheers,

Phil.

Re: [orbitcpp-list] Windows + CVS

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

a9506264 wrote:
> 
> Hi there
> 
> With no telephone line at home I have to use a public Windows
> terminal (University) . Is there an easy way to get a CVS Snapshot (a CVS
> Proggy for Windows) from there, or can you send me one in a tarball/put one
> in the download section.
> 
> Thanks
> 
> eT
> 

Hi eT,

If you can install stuff on the windows box, there's always wincvs
http://www.wincvs.org
- it even tunnels through firewals (via ssl).

Failing that, cvs snapshots are a possibility - I'd have to invest some
time writing a script to create them nightly. Hmmm....

In the meantime, I think it's about time for 0.27 anyway. I've got
IDLObjects to code, and then the name service should be accessible via
ORBit-C++. Hopefully I'll upload the new release sometime tomorrow.

Cheers,

Phil.

[orbitcpp-list] shared library weirdness

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

Hi folks,

I've run into something that I just plain don't understand. I know how
to fix it, but I don't understand it. It's the following:

Every use of exceptions together with liborbitcpp.so segfaults on me, no
matter what I do. Even "int main() { throw 5; }" segfaults, instead of
aborting. I have discovered (by commenting out half of the library) that
the segfault is somehow caused by CORBA::Exception. From other
observations I know that whenever the complete vtbl for CORBA::Exception
can be known from the header file, the segfault happens. (how? why? i
just do not get the point.)

any idea, anyone? 

cya
andy

[orbitcpp-list] Windows + CVS

[a9506264 <a95...@un...>]

Hi there

With no telephone line at home I have to use a public Windows
terminal (University) . Is there an easy way to get a CVS Snapshot (a CVS
Proggy for Windows) from there, or can you send me one in a tarball/put one
in the download section.

Thanks

eT

Re: [orbitcpp-list] problem with emacs and tab formatting!

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

> Andreas - what do you think? Does this sound over complicated? - Maybe
> we should move to spaces?

Uh. Just when I started to like 'em (the tabs). On this particular
issue, I like the

SomeDamnLongMethodName(arg1,arg2,
	arg3,arg4,arg5,...)
^ one tab

style better. But heck, if you want to switch to spaces, do it. Main
thing is the whole thing remains readable. 

cya
andy

Re: [orbitcpp-list] problem with emacs and tab formatting!

[Braden N. M. <br...@en...>]

On Sun, 9 Apr 2000, Phil Dawes wrote:

> "Braden N. McDaniel" wrote:
> > 
> > On Sat, 8 Apr 2000, Phil Dawes wrote:
> > 
> > > Hi All,
> > >
> > > I've just realised a problem with tab formatting that I hadn't
> > > considered:
> > >
> > > For functions with many arguments, I tend to do:
> > >
> > >       thisIsALongMethodName(FirstArg arg1,
> > >                             SecondArg arg2,
> > >                             ThirdArg arg3)
> > >
> > > However, when you set emacs to do tab formatting, it uses tabs in the
> > > second and third arg lines, which of course gets a bit out when you
> > > change the tab stop size. Has anybody managed to get emacs to 'do the
> > > right thing'? (i.e. tab to alignment with the start of the method, and
> > > then space the rest)
> > 
> > <URL:http://www.geocrawler.com/archives/3/835/2000/3/0/3377470/>
> > 
> > Eloquently:
> > 
> > <URL:http://www.jwz.org/doc/tabs-vs-spaces.html>
> > 
> > ;-)
> > 
> 
> Hi Braden,
> 
> You're right! Sorry - I somehow didn't register the
> 
>    void Class::method(Type arg1,
>                       Type arg2)
>    {}
> 
> problem when you mentioned it (got to ammend my skim reading habits so
> that I actually take things in ;-).
> 
> I still like the ability to vary the tab width though - I've got a 19
> inch monitor at home, and a small laptop. I use 4 tabs on the former and
> 2 on the latter (hence me noticing the problem). Ideally for me, I'll
> configure emacs to tab align with the start of the method and then space
> the rest - Unless I'm missing something, this should then scale
> appropriately with tab width.
> 
> Andreas - what do you think? Does this sound over complicated? - Maybe
> we should move to spaces?
> 
> 
> Thanks for the feedback Braden - I enjoyed reading your critique,

Ah, that "critique" is *not* mine, it's Jamie Zawinsky's. I'm just
spreading the "Tabs Are Evil" gospel. :-)

-- 
Braden N. McDaniel
br...@en...
<URL:http://www.endoframe.com>

Re: [orbitcpp-list] problem with emacs and tab formatting!

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

"Braden N. McDaniel" wrote:
> 
> On Sat, 8 Apr 2000, Phil Dawes wrote:
> 
> > Hi All,
> >
> > I've just realised a problem with tab formatting that I hadn't
> > considered:
> >
> > For functions with many arguments, I tend to do:
> >
> >       thisIsALongMethodName(FirstArg arg1,
> >                             SecondArg arg2,
> >                             ThirdArg arg3)
> >
> > However, when you set emacs to do tab formatting, it uses tabs in the
> > second and third arg lines, which of course gets a bit out when you
> > change the tab stop size. Has anybody managed to get emacs to 'do the
> > right thing'? (i.e. tab to alignment with the start of the method, and
> > then space the rest)
> 
> <URL:http://www.geocrawler.com/archives/3/835/2000/3/0/3377470/>
> 
> Eloquently:
> 
> <URL:http://www.jwz.org/doc/tabs-vs-spaces.html>
> 
> ;-)
> 

Hi Braden,

You're right! Sorry - I somehow didn't register the

   void Class::method(Type arg1,
                      Type arg2)
   {}

problem when you mentioned it (got to ammend my skim reading habits so
that I actually take things in ;-).

I still like the ability to vary the tab width though - I've got a 19
inch monitor at home, and a small laptop. I use 4 tabs on the former and
2 on the latter (hence me noticing the problem). Ideally for me, I'll
configure emacs to tab align with the start of the method and then space
the rest - Unless I'm missing something, this should then scale
appropriately with tab width.

Andreas - what do you think? Does this sound over complicated? - Maybe
we should move to spaces?


Thanks for the feedback Braden - I enjoyed reading your critique,

Cheers,

Phil.

[orbitcpp-list] problem with emacs and tab formatting!

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

Hi All,

I've just realised a problem with tab formatting that I hadn't
considered:

For functions with many arguments, I tend to do:

	thisIsALongMethodName(FirstArg arg1,
	                      SecondArg arg2,
	                      ThirdArg arg3)

However, when you set emacs to do tab formatting, it uses tabs in the
second and third arg lines, which of course gets a bit out when you
change the tab stop size. Has anybody managed to get emacs to 'do the
right thing'? (i.e. tab to alignment with the start of the method, and
then space the rest)

Cheers,

Phil.

[orbitcpp-list] (no subject)

[<uj...@rz...>]

Hi Phil & folks,

I've been out to Holland for a biking trip (which was great btw), so
I had no chance to access any kind of computer (which I didn't miss for a
change :), so I've lost track a bit. Right now, I'm still at a friend's
place, I'll be back sunday, so hang on for more action...

cya
andy

Andreas Kloeckner / ak...@ix... / Was waere Mathe ohne Techno?

[orbitcpp-list] Plan for next few days

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

Hi folks,

I've got a couple of free days so I'm going to attempt to do the
following:

- Implement the typedef fix I posted earlier
- Bounded sequences
- Forward declarations
- Enums

If anybody has already started on any of these things, please post a
mail to the list.

Cheers,

Phil.

[orbitcpp-list] typedef implementation

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

Hi Andreas, all,

I think that the way the compiler handles typedefs needs
revisiting. For example, the idl:

typedef foo bah;

interface Test {
        op(in inArg);
}


writes the c++ operation stub:

void op(const foo& inArg);

and it should be: 

void op(const bah& inArg);



The hack I used for the sequence typedef was to keep a ref to the
typedef in the sequence object (wired up in the
IDLSequence::writeTypeDef() method), however this only works because
sequence is a anonymous type that must be typedefd before it can be
used.

As an alternative, I suggest renaming getCPPQualifiedIdentifier() to
getCPPQualifiedTypename() and putting it in an abstract base
class. Then appending an argument to the end of each write*() method
with a pointer to the object with the identifier to use. That way,
IDLTypedef can propogate the appropriate identifier to the 'real' IDL
types.

Suggestions? Alternatives?

Cheers,

Phil.

Re: [orbitcpp-list] Questions/FAQ

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

Mark Gunn wrote:
> 
> Hi all,
> 
> Is there a FAQ for the project? As I've stated to
> Phil, I'm interested in helping out on the project,
> but I'm a beginner when it comes to CORBA. So, if
> there isn't one, then I'd be willing to start one for
> the project and maintain it. (Seeing that I'm probably
> going to have a lot of questions initially, I guess
> it's only fair that I document them. :-)
> 

There used to be a faq in the old archive, but the maintainer went off
on a round-the-world type trip, and it's now got a bit out of date what
with the change in archives, C++ idl compiler etc...

> Let me know if you think it would be helpful or not.
> 

I think it would be very helpful. I'll see if I can dig out the old FAQ
and send it to you.

Cheers,

Phil.

Re: [orbitcpp-list] splitting ServantBase into 2 classes

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

Phil dawes wrote:
> 
> Hi Andrew,
> 
> What was the rationale for ServantMethods not inheriting from
> ServantBase?

I hadn't thought of virtual inheritance, sorry.

> 
> The problem with the above is that the _this() method needs to be on a
> ServantBase object or it can't activate itself with the default poa.

that explains why the boolean thing refused to work. I noticed this was
so, but lacked time to look into it.

> I've fixed this by making ServantMethods inherit virtually from
> ServantBase again, so that code which uses _this() works, but I don't
> know how these affects your inheritance scheme...

this is probably the RIGHT THING (tm).

> Cheers,
> 
> Phil.

[orbitcpp-list] splitting ServantBase into 2 classes

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

Hi Andrew,

What was the rationale for ServantMethods not inheriting from
ServantBase?

The problem with the above is that the _this() method needs to be on a
ServantBase object or it can't activate itself with the default poa.

I've fixed this by making ServantMethods inherit virtually from
ServantBase again, so that code which uses _this() works, but I don't
know how these affects your inheritance scheme...

Cheers,

Phil.

[orbitcpp-list] Questions/FAQ

[Mark G. <mar...@ya...>]

Hi all,

Is there a FAQ for the project? As I've stated to
Phil, I'm interested in helping out on the project,
but I'm a beginner when it comes to CORBA. So, if
there isn't one, then I'd be willing to start one for
the project and maintain it. (Seeing that I'm probably
going to have a lot of questions initially, I guess
it's only fair that I document them. :-)

Let me know if you think it would be helpful or not.

Thanks,
Mark





__________________________________________________
Do You Yahoo!?
Talk to your friends online with Yahoo! Messenger.
http://im.yahoo.com

Re: [orbitcpp-list] back with a vengeance :)

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

Andreas Kloeckner wrote:
> 
> Hi Phil & folks,
> 
> i'm back from the dead, finally... the calculus exam is over! hooray!
> two dumb weeks of studying, six hours of examination spread across two
> days, phew...
> (we'll see about the "hooray" when i get my results, but for now i'm
> just happy that i will definitely not have to do all this stuff again
> :-)
> 

I know how you feel. The time after my finals was fantastic. The best
thing is being able to watch tv without feeling guilty for not revising!

> back to some "real work" then...
> 
> * do you see any problems with having the skels use virtual inheritance?
> 

Don't think so. The skeletons can be as elaborate as we like, since
AFAIK there's no way we can make them 'binary compatible'.

> * the 0.26 release is awfully broken. i noticed that i slipped in some
> code that dumb-loops the compiler on any occurence of inheritance. we'd
> better get 0.27 out the door before anyone notices...
> 

hmmm... How about after the weekend? I should have the unbounded
sequence stuff finished by then.

> * some things concerning tonight's commit:
> 

Doh! I've got some sequence code to commit. Better get merging...

> - new: the notion of "type containers". up to now, the compiler just
> threw away any types declared inside an interface. to remedy this, i've
> introduced type container classes, which are classes that sit in the
> same namespace hierarchy as their real-life stub counterparts, but under
> "_orbitpp::type_container". the compiler translates iface-scope types
> into types inside these containers, from where they are imported into
> stubs and skels by means of inheritance. unfortunately, even though
> these container classes don't have data members, gcc makes them have
> size 1. thus, the stub binary footprint is no more the same as C
> ORBit's. yet, i hope this does not
> matter because gcc hopefully never accesses this memory.
 
Hmmm sounds dodgy ;-)
Could it be something to do with rtti?

> - for the rest of the changes, see the cvs log entry.

Got it.


Cheers,

Phil.

[orbitcpp-list] back with a vengeance :)

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

Hi Phil & folks,

i'm back from the dead, finally... the calculus exam is over! hooray!
two dumb weeks of studying, six hours of examination spread across two
days, phew...
(we'll see about the "hooray" when i get my results, but for now i'm
just happy that i will definitely not have to do all this stuff again
:-)

(actually, it's already over since last thursday, but i just needed some
time for recovery from all those parties and time to visit my parents
and time to clean the flat and time to... oh well....;)

back to some "real work" then... 

* do you see any problems with having the skels use virtual inheritance?

* the 0.26 release is awfully broken. i noticed that i slipped in some
code that dumb-loops the compiler on any occurence of inheritance. we'd
better get 0.27 out the door before anyone notices...

* some things concerning tonight's commit:

- it is not perfect. the string test works, the basic test works almost,
boolean fails to compile, i haven't yet tried "everything". i didn't
want to wait till i catch all those rather small bugs to get this commit
done because it has some effect on all of the compiler.

- new: the notion of "type containers". up to now, the compiler just
threw away any types declared inside an interface. to remedy this, i've
introduced type container classes, which are classes that sit in the
same namespace hierarchy as their real-life stub counterparts, but under
"_orbitpp::type_container". the compiler translates iface-scope types
into types inside these containers, from where they are imported into
stubs and skels by means of inheritance. unfortunately, even though
these container classes don't have data members, gcc makes them have
size 1. thus, the stub binary footprint is no more the same as C
ORBit's. yet, i hope this does not
matter because gcc hopefully never accesses this memory.

- for the rest of the changes, see the cvs log entry.

cya
andy

[orbitcpp-list] still doesn't work

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

Phil,

I sent you a message in February about problems I was having with running an
orbitcpp sample program on two separate machines.  You recommended upgrading
ORBit and orbitcpp to 0.5.1 and 0.25.1, respectively.  I did so, but the
problem persists, more or less.

I have now tried the slightly mutated helloworld sample on several more
machines, (call them A, B, C, and D) and my results are as follows:

The client always fails (exception, minor code = 5) when the server is on
machine D.

The client succeeds on all other combinations, even when machine D is the
client.

I have spent a fair amount of time trying to find out what is different about
machine D, but I have yet to find anything significant.  Is there any kind of
network configuration setting you can think of that might cause the exception
with minor code 5?  All the machines tested were running Red Hat 6.1, with the
0.5.1 and 0.25.1 versions of ORBit and orbitcpp.

It does not appear to be an identification problem, because the client machine
is always able to obtain the IOR from an LDAP server running on the orbitcpp
server machine.  The client calls _narrow() successfully, but then it throws an
exception during the invocation of the interface method.

Any suggestions?

Thanks.

--Bill Lasley

__________________________________________________
Do You Yahoo!?
Talk to your friends online with Yahoo! Messenger.
http://im.yahoo.com

[orbitcpp-list] orbitcpp-0.26 released

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

Hi all,

I've finally managed to release orbitcpp-0.26. You can get this via the
web page:
http://orbitcpp.sourceforge.net/

I've reduced the content of the web page so that it is easier to keep in
sync (at least until somebody makes it all nice and shiney :-)

Cheers,

Phil.

BTW, I'm currently working on coding IDL sequences, just in case that
conflicts with anybody.

[orbitcpp-list] Problems with the release

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

Hi Folks,

I'm having problems with the sourceforge file release process - judging
by the support manager it looks like others are too, so no release today
I'm afraid.

Cheers,

Phil.

Re: [orbitcpp-list] Time for a release?

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

Andreas Kloeckner wrote:
> 
> > This will keep interest up, give people something to build and play
> > with, and hopefully allow us to spot some build/test problems on other
> > platforms. I hope it will also encourage more developers to help out.
> 
> Release early, release often. I'm very much in favor of releasing now
> that there is something people can usefully toy around with. Yet, I
> believe we should not raise too much dust about it, such as by
> announcing it on freshmeat, since what we have is still clearly
> pre-alpha. But there's certainly nothing bad about having a small
> internal release for people who care about the project.
> 

Agreed.

> > Of course the next issue is version number: I'm not keen on 0.30 since
> > this version doesn't represent any significant increase in CORBA
> > functionality. orbitcpp-0.26?
> 
> It depends. Do you intend to do any new releases on the old python
> stuff? In this case, I'd say we should choose something really
> different, such as orbitcpp-devel-0.20, orbitcpp-hacker-0.20 or
> orbitcpp2-0.20. If not, 0.26 is not such a bad choice, since it suggests
> there wasn't much user-visible improvement, which is clearly true. On
> the other hand, the people who are obeying our project will certainly
> have noticed that 0.26 _is_ something radically different, so the clumsy
> naming won't matter to them.

Yep. I don't intend on doing any more work on the old ORBit-C++ release
(except perhaps bug fixed). 0.26 it is!

> 
> Any plan about the release date?
> 

Err.. Today if I get the chance.

Phil.

Re: [orbitcpp-list] Time for a release?

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

> This will keep interest up, give people something to build and play
> with, and hopefully allow us to spot some build/test problems on other
> platforms. I hope it will also encourage more developers to help out.

Release early, release often. I'm very much in favor of releasing now
that there is something people can usefully toy around with. Yet, I
believe we should not raise too much dust about it, such as by
announcing it on freshmeat, since what we have is still clearly
pre-alpha. But there's certainly nothing bad about having a small
internal release for people who care about the project.

> Of course the next issue is version number: I'm not keen on 0.30 since
> this version doesn't represent any significant increase in CORBA
> functionality. orbitcpp-0.26?

It depends. Do you intend to do any new releases on the old python
stuff? In this case, I'd say we should choose something really
different, such as orbitcpp-devel-0.20, orbitcpp-hacker-0.20 or
orbitcpp2-0.20. If not, 0.26 is not such a bad choice, since it suggests
there wasn't much user-visible improvement, which is clearly true. On
the other hand, the people who are obeying our project will certainly
have noticed that 0.26 _is_ something radically different, so the clumsy
naming won't matter to them.

Any plan about the release date?

> <SHOTINTHEDARK>
> The ORBit-C++ web page is in need of a bit of a facelift. Unfortunately
> time spent keeping it up to date detracts from my hacking time. If
> anybody else fancies maintaining the site, drop me an email.
> </SHOTINTHEDARK>

Though I hate html, I'll probably have time to do it by the end of next
week - if there aren't any volunteers, that is... 8-))))

cya
andy