orbitcpp-list

[orbitcpp-list] Time for a release?

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

Hi Andreas & all,

I've been getting a couple of emails recently from people who have
downloaded orbitcpp-0.25 and are asking what they can do to help. 

The problem is that orbitcpp-0.25 is a release using the old
architecture and python idl compiler. I think it's time to put a release
of the new archive out even though it isn't as featureful as 0.25 was. 

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.

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?

What do you think?

Phil.

<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>

[orbitcpp-list] Change in memory management...

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

... of String_mgr and variable length structs.

Consider a variable length struct with a string in it:

// IDL
struct VariableLengthStruct {
       string foo;
};

The old mechanism defined the delete operator for the variable length
struct to call CORBA_free() which would deep-free the struct (and
therefore free the string). This meant that the String_mgr couldn't
release the string in its destructor otherwise the memory would be freed
twice.

The problem is that the CORBA C++ language mapping allows variable
length structs to be created on the stack (thus no new and delete
operator involved) which causes the string memory to be leaked with the
above String_mgr implementation.

I've fixed this by making operator delete call ORBit_free() rather than
CORBA_free(), which allows me to free the struct without deep-freeing
the string. The String_mgr() class now releases its own strings and all
is right with the world (I hope).

N.B. there is still a requirement for a String_mgr class, since corba
2.3 requires that string members be initialised to "" rather than NULL
(which is what String_var must initialise them to).

Cheers,

Phil.

Re: [orbitcpp-list] Re: [orbitcpp-commits] orbitcpp philipd

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

Andreas Kloeckner wrote:
> 
> Hi Phil,
> 
> > - Added compiler helper function to detect whether type is variable length
> > (and added the function to IDLElement (I ripped these off of the
> > orbit-idl code - hope this is okay)
> 
> Uh, hope you don't mind me bickering, but I'd rather have
> "isVariableLength()" as a member func of IDLType. It's much more natural,
> you don't have to rip off dumb hacks from orbit-idl code, polymorphism
> makes your day without lengthy case statements. also mind the fact that
> not all IDLTypes are IDLElements (such as short, string).

Of course you're right. I did consider using polymorphism, but it was
like 'two minutes to rip off the (already tested) ORBit code verses 1/4
hour to write a few recursive virtual functions and test them' and I was
keen to get the struct stuff working. I'll see if I can refactor it for
the next commit.

> phil, i guess i'll be kinda busy till next thursday. don't expect too much
> work done by me till that damn calculus exam is all over...
> 

Okay - BTW Good luck,

Cheers,

Phil.

[orbitcpp-list] Re: [orbitcpp-commits] orbitcpp philipd

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

Hi Phil,

> - Added compiler helper function to detect whether type is variable length 
> (and added the function to IDLElement (I ripped these off of the
> orbit-idl code - hope this is okay)

Uh, hope you don't mind me bickering, but I'd rather have 
"isVariableLength()" as a member func of IDLType. It's much more natural,
you don't have to rip off dumb hacks from orbit-idl code, polymorphism
makes your day without lengthy case statements. also mind the fact that
not all IDLTypes are IDLElements (such as short, string).

> - Added struct declaration support for fixed and variable length structs

cool.

phil, i guess i'll be kinda busy till next thursday. don't expect too much
work done by me till that damn calculus exam is all over...

cu
andy

[orbitcpp-list] "Test everything" thingie

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

Hi Phil,

have a look at my "basic" test. It tests pretty much of everything
already.

I've been busy studying this night, just as I will be the next days.
Calculus is still some kind of dark matter to me :)

cu
andy

[orbitcpp-list] work tonight

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

Hi All,

I've got some time for hacking tonight, I'll be working on writing an
integrated test harness (rather than the 1 directory per test
arrangement on the old ORBit-C++ archive).

Andreas, are you hacking or studying? Does it affect you much if I tweak
the runtime code?

Cheers,

Phil.

Re: [orbitcpp-list] various stuff

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

Andreas Kloeckner wrote:
> 
> Hi Phil,
> 
> * I put some blurb about the compiler design into the HACKING file,
> please have a look because I am not so sure anyone will be able to see
> what i meant :((
> 

This is cool - I thought you said you didn't like writing documentation
;-)

> * Can we agree on some standard for doing the
> m_header
> << indent << "int u;" << endl
> << indent << "blah" << endl;
> things? (This is suggestive because it presents the way I propose to do
> it :)
> 

That's why I asked you for your .emacs file ;-)
I quite like your << style - lets use that.

> * Hey, you duplicated code from pass_xlate in pass_stub! All this _var
> and _out stuff is already declared there! (have a look at the
> *-common.hh file...) i believe it should o there because people may well
> want objrefs in their structs and stuff. ain't it so? :)))))

Doh! - you're right. Feel free to do the right thing :-)

> * I've got two things that I'll be hacking tonight:
> 1) make the skels work
> 2) implement all the MI stuff for the stubs that we talked about
> I don't know how far I'll get with either one, so if you want to avoid
> having to go to the pub :)) feel free to mail me, I'll be checking my
> mails about every hour.
> 

Okay, I've implemented that orbit-idl --backenddir=<our shared library
dir> flag in ORBit that I've been harping on about, and now I'm just
sticking the autoconf stuff to detect its presence and react
accordingly.

Actually, I am going to the pub in about half an hour, so I don't think
I'll be doing much more. 

Cheers,

Phil.

[orbitcpp-list] patch for overriding idl backend dir as cmd parameter

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

Hi Elliot, Dick,

Here's a patch to allow the orbit-idl backend library directory to be
overridden as a command line parameter. 

We need this for ORBit-C++ because otherwise the package cant compile
its own tests without the user first installing its C++ backend library
(which rules out 'make distcheck').

The patch is against a snapshot of the ORBit CVS archive taken today
(9th March)

Cheers

Phil.

[orbitcpp-list] various stuff

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

Hi Phil,

* I put some blurb about the compiler design into the HACKING file,
please have a look because I am not so sure anyone will be able to see
what i meant :((

* Can we agree on some standard for doing the
m_header
<< indent << "int u;" << endl
<< indent << "blah" << endl;
things? (This is suggestive because it presents the way I propose to do
it :)

* Hey, you duplicated code from pass_xlate in pass_stub! All this _var
and _out stuff is already declared there! (have a look at the
*-common.hh file...) i believe it should o there because people may well
want objrefs in their structs and stuff. ain't it so? :)))))

* I've got two things that I'll be hacking tonight:
1) make the skels work
2) implement all the MI stuff for the stubs that we talked about
I don't know how far I'll get with either one, so if you want to avoid
having to go to the pub :)) feel free to mail me, I'll be checking my
mails about every hour.

cya
andy

Re: [orbitcpp-list] Task list

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

Andreas Kloeckner wrote:
> 
> Hi folks,
>
> > 1) Get the skeletons working with the string example
> 
> i'll be looking into this right now. (we had a probability theory exam
> yesterday, and today i'm taking a break from learning) i hope i can
> commit as frequently as possible.
> 

Cool - I was going to work on this tonight, but if you've already
started I'll find something else to do (like maybe go to the pub :-)

> > 2) Port the other non-MI tests over from ORBit-C++ and make sure they
> > work:
> > boolean, consts, corba_unknown, enum, exception, integers, objref,
> > struct, typedef, sequence
> 
> boolean: should be ok
> consts: no support yet
> corba_unknown: huh? what should this do?

The server throws an exception which the idl skels don't know about.

> enum: no support yet
> exception: should be ok
> integers: should be ok
> objref: should be ok
> typedef: should be ok
> sequence: no support yet
> 

Okay, I'll start moving the 'should be ok' tests ready for when the
skels work.

> > 3) Put in support for multiple inheritance (with the inline casts and
> > downcall functions), and port the 'diamond' test.
> 
> perhaps i'll do some preliminary work on this today.
> 
> > 5) Fix orbit-idl so that it can take its shared library backends from
> > any directory. This will enable the tests to be run without installing
> > the compiler first (I really want this, because otherwise I can't use
> > 'make distcheck' to catch build/install bugs before I do a release)
> 
> uh, let's first produce something worth releasing :)
> 

:-)
Although, I think a release may be in order after we get basic stuff
going again, just to retain interest, and maybe encourage people to look
at the code.

> > Andy, do you think you could cobble together some notes on the compiler
> > structure? - just a few lines on things like IDLScope and the supporting
> > functions. It took me a good 20 minutes to figure out how to remove the
> > leading :: from fully qualified CPP names.
> 
> i'll see what i can do. though i hate documenting. phil, can you think
> of a way to make the thing more self-explanatory? (and thus lessen the
> need for docs? ;-)

It was actually pretty self explanatory as code goes. It's more general
concepts that need documentation (like 'what is IDLScope? Conceptual
examples of an IDLScope are...'). I may write a couple of notes along
these lines, but I agree that self-explanatory code is better than
docuementation.

Cheers,

Phil.

Re: [orbitcpp-list] Task list

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

Hi folks,

Phil dawes wrote:
> 
> Hi All,
> 
> Here's my take on what needs to be done:
> 
> 1) Get the skeletons working with the string example

i'll be looking into this right now. (we had a probability theory exam
yesterday, and today i'm taking a break from learning) i hope i can
commit as frequently as possible.

> 2) Port the other non-MI tests over from ORBit-C++ and make sure they
> work:
> boolean, consts, corba_unknown, enum, exception, integers, objref,
> struct, typedef, sequence

boolean: should be ok
consts: no support yet
corba_unknown: huh? what should this do?
enum: no support yet
exception: should be ok
integers: should be ok
objref: should be ok
typedef: should be ok
sequence: no support yet

> 3) Put in support for multiple inheritance (with the inline casts and
> downcall functions), and port the 'diamond' test.

perhaps i'll do some preliminary work on this today.

> 5) Fix orbit-idl so that it can take its shared library backends from
> any directory. This will enable the tests to be run without installing
> the compiler first (I really want this, because otherwise I can't use
> 'make distcheck' to catch build/install bugs before I do a release)

uh, let's first produce something worth releasing :)

> Andy, do you think you could cobble together some notes on the compiler
> structure? - just a few lines on things like IDLScope and the supporting
> functions. It took me a good 20 minutes to figure out how to remove the
> leading :: from fully qualified CPP names.

i'll see what i can do. though i hate documenting. phil, can you think
of a way to make the thing more self-explanatory? (and thus lessen the
need for docs? ;-)

> A quick tip for anybody wanting to do some compiler hacking - if you run
> ./configure --disable-static (or ./autogen.sh --disable-static) then the
> compiler builds much faster.

bye
andy

[orbitcpp-list] Task list

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

Hi All,

Here's my take on what needs to be done:

1) Get the skeletons working with the string example

2) Port the other non-MI tests over from ORBit-C++ and make sure they
work:
boolean, consts, corba_unknown, enum, exception, integers, objref,
struct, typedef, sequence

3) Put in support for multiple inheritance (with the inline casts and
downcall functions), and port the 'diamond' test.

4) Finish off the rest of the corba spec types and knock up quick tests
for them.

5) Fix orbit-idl so that it can take its shared library backends from
any directory. This will enable the tests to be run without installing
the compiler first (I really want this, because otherwise I can't use
'make distcheck' to catch build/install bugs before I do a release)

6) Put in support for DII, DSI, typecode and any (Gordon, are you still
interested in doing typecode and any?)

I think that after (1) is done, the other work should be fairly easy to
parallelize.

Andy, do you think you could cobble together some notes on the compiler
structure? - just a few lines on things like IDLScope and the supporting
functions. It took me a good 20 minutes to figure out how to remove the
leading :: from fully qualified CPP names.

A quick tip for anybody wanting to do some compiler hacking - if you run
./configure --disable-static (or ./autogen.sh --disable-static) then the
compiler builds much faster.

Cheers,

Phil.

[orbitcpp-list] Working on stubs tonight

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

Hi Folks,

I'll be working on the stubs part of the compiler this evening (from
~6pm GMT), with the aim of making the output stubs look like the
string-template test function. 
If this steps on anybody's toes (Andy?), then mail this list and we'll
sort out a better plan.

Cheers,

Phil.

Re: [orbitcpp-list] to hell with inheritance ;)

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

Phil Dawes wrote:
> 
> Andreas Kloeckner wrote:
> >
> > Example:
> >
> >     A
> >    / \
> >   B   C
> >    \ /
> >     D
> >
> > In this case, the compiler might generate something like: (A,B,C
> > straightforward, with inheritance)
> >
> > class D : B {
> >   operator C { reinterpret_cast... blah... }
> >   stub_of_C_1(blah) { reinterpret_cast<C *>(this)->stub_of_C_1(blah); }
> >   stub_of_C_2(blah) { reinterpret_cast<C *>(this)->stub_of_C_2(blah); }
> >   ...
> >   rest of D
> > };
> >
> > what do you think?
> > 
> 
> Yep, I was coming to that conclusion today on the train home from work.
> BTW, what does virtual inheritance do if you don't define any virtual
> methods?
> 

Having thought for a minute, I've realised that it must still instrument
the object instance with offset pointers to member state otherwise the
whole thing wouldn't work polymorphically. Doh!

Phil.

Re: [orbitcpp-list] to hell with inheritance ;)

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

Andreas Kloeckner wrote:
> 
> Example:
> 
>     A
>    / \
>   B   C
>    \ /
>     D
> 
> In this case, the compiler might generate something like: (A,B,C
> straightforward, with inheritance)
> 
> class D : B {
>   operator C { reinterpret_cast... blah... }
>   stub_of_C_1(blah) { reinterpret_cast<C *>(this)->stub_of_C_1(blah); }
>   stub_of_C_2(blah) { reinterpret_cast<C *>(this)->stub_of_C_2(blah); }
>   ...
>   rest of D
> };
> 
> what do you think?
> 

Yep, I was coming to that conclusion today on the train home from work.
BTW, what does virtual inheritance do if you don't define any virtual
methods?

Phil.

Re: [orbitcpp-list] to hell with inheritance ;)

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

On Sun, Mar 05, 2000 at 09:19:21PM +0000, Phil Dawes wrote:
> > something came to my mind just this moment. we cannot use inheritance on
> > the stubs, right? We may single-inherit them from CORBA::Object, but
> > that's about it. If we use virtual inheritance, the compiler will add
> > some thunking data, which will be broken (i.e. non-existent) the very
> > moment we reinterpret_cast a CORBA_Object_struct to be a stub. yet, the
> > spec demands implicit widening, so we need to add cast operators for
> > each and every base class. correct? is there any way around this?
> > 
> 
> I'm probably being thick, but I can't see why we need vtable inheritance
> for the stubs. There's no polymorphism done at the C++ level - all calls
> are just sent (statically linked) to the C stubs, which do epv
> polymorphism themselves (using Elliots shortcircuit classid mechanism).
> Or am I missing something? 
> Hmmm... Maybe I haven't thought everything through: If we do multiple
> inheritance without virtual inheritance, you get multiple copies of
> CORBA::Object. Does that matter?

Think so. Consider the usual A,B,C,D diamond of death. D's got two copies of 
CORBA::Object, assume that C's copy is placed behind B's in memory. Assume 
now you'd call one of the stubs inherited from C. C's CORBA_Object_struct
(from its copy of CORBA::Object) is out somewhere in the plains, whatever 
sits behind the "right" CORBA_Object_struct, so the call will most probably 
go segfault or something like that. Not good. Furthermore, if anyone
calls one of A's stubs, the call needs to be disambiguated. (or else people
will run into compiler errors) I'd say we should make the compiler 
intelligent enough to just stick with single inheritance, and in case of MI
generate all the stuff (cast operators, stubs that reinterpret_cast and forward
the call) to simulate the existence of MI. (so we save all the hassle in the
much more probable case of SI, whereas users of MI incur _some_ overhead.)

Example:

    A
   / \
  B   C
   \ /
    D
    
In this case, the compiler might generate something like: (A,B,C 
straightforward, with inheritance)

class D : B {
  operator C { reinterpret_cast... blah... }
  stub_of_C_1(blah) { reinterpret_cast<C *>(this)->stub_of_C_1(blah); }
  stub_of_C_2(blah) { reinterpret_cast<C *>(this)->stub_of_C_2(blah); }
  ...
  rest of D
};

what do you think?

bye
andy

[orbitcpp-list] string-template test directory

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

Hi Andrew, all,

I've split the string test into 2: string-template and string

The string-template directory will take the role which the string test
used to have - to develop and try out hand coded stubs and skeletons
which serve as a target to build the idl compiler to. 

The string test directory will be a proper test which uses the idl
compiler to build itself. The stubs and skeletons produced will
approximate the ones in the string-template test directory.

Eventually I will remove the string-template directory when the idl
compiler is mature enough.

Cheers,

Phil.

Re: [orbitcpp-list] to hell with inheritance ;)

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

Andreas Kloeckner wrote:
> 
> Hi Phil,
> 
> something came to my mind just this moment. we cannot use inheritance on
> the stubs, right? We may single-inherit them from CORBA::Object, but
> that's about it. If we use virtual inheritance, the compiler will add
> some thunking data, which will be broken (i.e. non-existent) the very
> moment we reinterpret_cast a CORBA_Object_struct to be a stub. yet, the
> spec demands implicit widening, so we need to add cast operators for
> each and every base class. correct? is there any way around this?
> 

I'm probably being thick, but I can't see why we need vtable inheritance
for the stubs. There's no polymorphism done at the C++ level - all calls
are just sent (statically linked) to the C stubs, which do epv
polymorphism themselves (using Elliots shortcircuit classid mechanism).
Or am I missing something? 
Hmmm... Maybe I haven't thought everything through: If we do multiple
inheritance without virtual inheritance, you get multiple copies of
CORBA::Object. Does that matter?

> bye,
> 
> andy
> 
> PS: If any of my recent rather technical question-answer-style posts to
> this list seemed rude or too demanding to you, I'd like to say sorry for
> this. I didn't mean to be offensive in any way, just in case you felt it
> to be like this. :)
> 

No, I didn't take them like that - Thanks for being thoughtful though
:-)

Cheers,

Phil.

[orbitcpp-list] to hell with inheritance ;)

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

Hi Phil,

something came to my mind just this moment. we cannot use inheritance on
the stubs, right? We may single-inherit them from CORBA::Object, but
that's about it. If we use virtual inheritance, the compiler will add
some thunking data, which will be broken (i.e. non-existent) the very
moment we reinterpret_cast a CORBA_Object_struct to be a stub. yet, the
spec demands implicit widening, so we need to add cast operators for
each and every base class. correct? is there any way around this?

bye,

andy

PS: If any of my recent rather technical question-answer-style posts to
this list seemed rude or too demanding to you, I'd like to say sorry for
this. I didn't mean to be offensive in any way, just in case you felt it
to be like this. :)

Re: [orbitcpp-list] coding standards for compiler/

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

Andreas Kloeckner wrote:
> 
> Hi Phil,
> 
> I've started converting the compiler to our new conventions. (at least
> the parts that can be done with sed :) However, i'd suggest we leave the
> method names in the compiler the way they are. When I first wrote it, I
> chose to use extremely descriptive (i.e. long) method names, and I do
> not regret that. 

Yep, I tend to do that alot as well - makes the code easier to follow.

> But imagine making
> 
> writeCPPStubReturnMarshalCode()
> 
> something like
> 
> write_cpp_stub_return_marshal_code()
> 
> (34 characters, as opposed to 29. this is madness.)
> 
> what do you think?
> 


I'm happy for you to leave the compiler method names in 'java' format.

Cheers,

Phil.

Re: [orbitcpp-list] extra ORB_var type

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

Andreas Kloeckner wrote:
> 
> Hi Phil,
> 
> why isn't ORB_var defined in terms of the _var template? i could not
> find any difference between the template and the ORB_var implementation.
> (in orbitcpp_orb.hh)
> 

Agreed - I think they can be merged.

Phil.

Re: [orbitcpp-list] string_alloc / exceptions?

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

Andreas Kloeckner wrote:
> 
> Hi Phil,
> 
> in CORBA::string_*() you say
> 
> // TODO: need to deal with exceptions here!
> 
> what kind of exceptions do you mean? the spec says those methods may not
> throw any, so where's the issue?
> 

You're right. I think you can safely remove those comments.

Phil.

Re: [orbitcpp-list] orbitcpp_corba.hh

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

Andreas Kloeckner wrote:
> 
> Hi Phil,
> 
> what's the exact purpose of orbitcpp_corba.hh? What is it supposed to
> contain? why is ORB_init in orbitcpp_corba.cc instead of
> orbitcpp_orb.cc? am i missing something?
> 

Hi Andy,

You're probably not missing something. The files and their names were
cobbled together early on and haven't changed much. Feel free to move
things about if you feel they'd be better placed in other files.

Cheers,

Phil.

Re: [orbitcpp-list] diff String_mgr String_var

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

Andreas Kloeckner wrote:
> 
> Hi again Phil,
> 
> the only difference between String_var and String_mgr i have been able
> to detect was that _mgr does not free anything in its destructor. in the
> comment above its declaration, you state it also initializes to an
> empty, rather than a null string, but this does not appear to be the
> case. 

Err.. Yes - you're right. I need to check the spec to see if this is
what indeed is required. 

> what exactly should be done differently? (since i'm integrating
> the _mgr with my _var templates, the only difference being made by a
> bool template parameter)
> 

string_mgr definitely needs to not free anything in the destructor
(since CORBA_free on a variable length struct or sequence also deep
frees the contents). I'm not sure if it also needs to initialise to an
empty string - it depends on whether the C marshallers can cope with
NULL strings in sequences and structs.

Cheers,

Phil.

[orbitcpp-list] coding standards for compiler/

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

Hi Phil,

I've started converting the compiler to our new conventions. (at least
the parts that can be done with sed :) However, i'd suggest we leave the
method names in the compiler the way they are. When I first wrote it, I
chose to use extremely descriptive (i.e. long) method names, and I do
not regret that. But imagine making

writeCPPStubReturnMarshalCode()

something like

write_cpp_stub_return_marshal_code()

(34 characters, as opposed to 29. this is madness.)

what do you think?

andy