orbitcpp-list

[orbitcpp-list] everyone still alive?

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

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

[orbitcpp-list] sourceforge accounts

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

Hi all,

I recommend that anybody wanting to do free software development
(including for ORBit-C++) gets an account on sourceforge ASAP. 

The sooner you join, the more likely you are to get your preferred login
name :-)

Cheers,

Phil.

Re: [orbitcpp-list] announcing o2cpp

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

Andreas Kloeckner wrote:
> 
> Hi Phil,
> 
> > I'm currently doing a prototype (proof-of-concept) with the current
> > ORBit-C++ runtime and the string test. I wanted prove that it would work
> > before committing anything to CVS.
> >
> > Would it be okay from your standpoint to add your compiler to the
> > ORBit-C++ source tree and then refactor the runtime from that?
> 
> Certainly. Yet, some feeling tells me that it would probably be better
> to leave the "official" ORBit-C++ cvs alone for people to use until the
> new thing is up and running. why not use your sourceforge cvs for
> building the new "call-me-experimental" source tree until then?
> 

Sounds like a good idea. I'm tempted to call the cvs tree 'orbitcpp'
rather than ORBit-C++. I think standardisation on an internal name
without capital letters or punctuation marks is a 'good thing' (tm).

> >
> > BTW, Do you have gnome cvs access?
> 
> nope.
> 

Do you have a sourceforge account? (http://www.sourceforge.net)

(N.B. you need secure shell (SSH) installed to get a the sourceforge cvs
tree)

Cheers,

Phil.

Re: [orbitcpp-list] Comments about o2cpp

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

Andreas Kloeckner wrote:
> 
> Phil dawes wrote:
> > > Hi Phil,
> 
> > ... marshalling techniques...
> 
> Got your point. Cool. For some reason, I was stuck with thinking that
> stubs needed some virtual methods, thus must be created by their genuine
> constructor, thus requiring stub factory hashing...

Yep. Of course the lack of virtual functions means you can't do straight
C++ to C++ short circuiting (since the client is statically bound to the
marshalling stubs). However the C ORBit runtime has the ability to
shortcircuit at the level below if both client and server are in the
same address space, so the call never gets marshalled to an actual giop
stream.

If the speed hit of marshalling exceptions and that extra layer of
indirection becomes a problem (I seriously doubt it, but maybe...) then
we could add a vtable interface (common client/server abstract base
class) on top at a later date. 


> > Good. Can you recommend a good C++ indent program? (I've seen a couple
> > on freshmeat so I might investigate...)
> 
> nope. i'll also see what i can find.
> 
> > > As you may have noticed, the compiler also does some indentation of its
> > > output, and of course the output is indented my way. we might have to
> > > look into that, or remove indentation entirely.
> >
> > With the python compiler I didn't bother with indenting, and assumed
> > that I could probably just pass the file through indent or something
> > after compilation.
> 
> it all depends on whether we can find some good indentation tool. if so,
> indentation by the compiler is just useless code clutter, if not,
> well...
> 

I'm tempted to leave indentation out. I never had problems with
orbit-idl2cpp because I just got emacs to indent the stubs if I wanted
to look at what was going on.

All this talk of indentation has got me interested in the possibility of
writing a CVS extension to do indentation for the user 'on the fly'
(during checkouts, updates, diffs etc..)... hmmmm... Certainly would
solve a few problems in the free software world.

Phil.

Re: [orbitcpp-list] Comments about o2cpp

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

Phil dawes wrote:
> > Hi Phil,

> ... marshalling techniques...

Got your point. Cool. For some reason, I was stuck with thinking that
stubs needed some virtual methods, thus must be created by their genuine
constructor, thus requiring stub factory hashing...

> Good. Can you recommend a good C++ indent program? (I've seen a couple
> on freshmeat so I might investigate...)

nope. i'll also see what i can find.

> > As you may have noticed, the compiler also does some indentation of its
> > output, and of course the output is indented my way. we might have to
> > look into that, or remove indentation entirely.
> 
> With the python compiler I didn't bother with indenting, and assumed
> that I could probably just pass the file through indent or something
> after compilation.

it all depends on whether we can find some good indentation tool. if so,
indentation by the compiler is just useless code clutter, if not,
well...

> 
> Cheers,
> 
> Phil.

cu
andreas

Re: [orbitcpp-list] announcing o2cpp

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

Hi Phil,

> I'm currently doing a prototype (proof-of-concept) with the current
> ORBit-C++ runtime and the string test. I wanted prove that it would work
> before committing anything to CVS.
> 
> Would it be okay from your standpoint to add your compiler to the
> ORBit-C++ source tree and then refactor the runtime from that?

Certainly. Yet, some feeling tells me that it would probably be better
to leave the "official" ORBit-C++ cvs alone for people to use until the
new thing is up and running. why not use your sourceforge cvs for
building the new "call-me-experimental" source tree until then?

> 
> BTW, Do you have gnome cvs access?

nope.

> Cheers,
> 
> Phil 'hoping his employer doesn't read orbitcpp-list' Dawes

;->

cu
andreas

Re: [orbitcpp-list] announcing o2cpp

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

Andreas Kloeckner wrote:
> 
[...]
> > > * Choice of language
> >
> > Fair enough (BTW, it's only the compiler that's written in python - all
> > of the runtime is and will be in C++). What didn't you like about
> > python?
> 
> True, it is only the compiler. But all this
> get-python-install-automake-stuff-get-everything-to-work-retry-several-times
> can really suck, and I believe it can scare people off, even coders.

True - from an installation point of view, the python build stuff is a
bit of a pain if you don't know python. (The next official version of
automake (1.5) will have python support, but that's beside the point)

> People that are looking for a c++ binding do know c++, but they might
> not know python. If they wanted to help properly, they'd have to know
> both.

Again true. I've been convinced that ideally from a community
perspective the compiler should be in C++; it's just that I didn't
really want to write it in C++ myself (too much like hard work!) - I
wasn't sure about the compiler design, and it's much easier for me to
refactor python code than C++ code (no declaration redundancy ;-). 

> (You want to know what i disliked about python? oh, plenty. not that i
> had actually tried, but there were several things that pissed me off
> enormously. first, python is not as declarative, as, say, c++. this
> makes code generally a bit harder to read. also, python does not try to
> separate declaration and implementation. 

But typically, due to python's terseness, your python class (inc
implementation) takes up less space than the header file in C++ anyway.
I'd speculate that I could grok a number of python classes in a single
file quicker than the same code spread over a number of C++ class files.
(don't even get me started on Java and its one-file-per-public-class
approach - eugh!)

> second, qualifying everything
> with "self." does not contribute to either code legibility or coding
> speed. Of course, the need for extra qualification is a direct
> consequence of having no declarations. 

Yep - you're not the first to dislike the self thing. As you say, the
self qualification is essential because you must differentiate between
object instance scope and method scope, and you don't have declarations
to do that.
On the other hand, if you're just talking about coding speed,
declarations do add redundancy. It's a static vs. dynamic typing thing -
static declarations are more work but safer. Decide what is important
and pick the right tool for the job. 

> third, i did at first not like
> the idea of a language being picky about whitespace. (I have changed my
> opinion a little on this one) ... <insert more senseless criticism
> here>... )
> 

Fair enough. I've never found it a problem personally.

> > What's your plan? Do you want to join forces / merge code?
> 
> Yup. :) My proposal would be to base the "new thing" (tm) upon your new
> runtime code (see other mail) along with an adapted version of my idl
> compiler. Which sucks because it is loads of work to do. Not that I'd
> mind, but currently I'm facing one and a half month featuring five
> exams, in two weeks' distance each. I guess I won't be able to do much
> of the like until March 24, when the exams will finally be over. After
> that date, however, I've got six weeks of free time (being a student is
> not so bad after all :).

Yep, I remember that... (sigh)
I wouldn't swap student life for working life though - all that time
sitting around in bars feeling guilty because I should be working ;-)

> We might start real soon by putting everything into one cvs tree,
> however.
> 

I'm currently doing a prototype (proof-of-concept) with the current
ORBit-C++ runtime and the string test. I wanted prove that it would work
before committing anything to CVS. 

Would it be okay from your standpoint to add your compiler to the
ORBit-C++ source tree and then refactor the runtime from that?

BTW, Do you have gnome cvs access?

> >
> > (BTW, I've put my thoughts and comments about the o2cpp implementation
> > in another mail)
> 
> (your fault. you'll have to read two replies ;)
> 

On the contrary - the more time I spend writing emails, the less I spend
doing 
'real-work' (tm)

Cheers,

Phil 'hoping his employer doesn't read orbitcpp-list' Dawes

Re: [orbitcpp-list] Comments about o2cpp

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

Andreas Kloeckner wrote:
> 
> Hi Phil,
> 
> Phil dawes wrote:
> >
> > Hi Andreas,
> >
> > I've got a couple of comments about o2cpp:
> >
> > 1) Licensing issues: Is your runtime LGPL? I could only find the GPL
> > license in your tarball.
> 
> Whoops. I intended it to be all-LGPL. I just looked into it, and at the
> top of the copying file it said
> snip ---------------------------------------------------------------
>                   GNU LIBRARY GENERAL PUBLIC LICENSE
>                        Version 2, June 1991
> 
>  Copyright (C) 1991 Free Software Foundation, Inc.
>                     675 Mass Ave, Cambridge, MA 02139, USA
>  Everyone is permitted to copy and distribute verbatim copies
>  of this license document, but changing it is not allowed.
> 
> [This is the first released version of the library GPL.  It is
>  numbered 2 because it goes with version 2 of the ordinary GPL.]
> snip ---------------------------------------------------------------
> 

Doh! You're right - I don't know how I missed that!

> > 2) A little bug report: GCC 2.95.2 won't compile the basic example
> > because the ORBit C skels declare an 'in' string as const char*, where
> > as o2cpp's stubs declare it without the const. The compiler barfs on the
> > epv function pointers.
> 
> fixed.
> 

Cool. This is an annoying 'feature' of the current ORBit tree which
means you can't have code which works with both the stable ORBit and the
cvs ORBit.

> >
> > 3) There's a lot of code in the runtime. I haven't had a lot of time to
> > look at it in detail, but it looks like a lot of the ORBit-C stuff is
> > duplicated in the orb layer (interface hash lookups, poa implementation,
> > reference counting, etc..).
> > I've already made this mistake in ORBit-C++, and am now in the middle of
> > rewriting the runtime code to take advantage of the built-in binary
> > compatibility between the C and C++ language mappings.
> >
> > If you give the C and C++ types the same binary footprint, then you can
> > convert between them with a reinterpret cast. No need for hash lookups
> > to identify the stub factory, and no need to deal with C++ object
> > lifecycles in the stubs/skeletons and for a new ref counting
> > implementation. The code size is much smaller and the marshalling code
> > is almost non-existant (the only thing that requires stub code at all is
> > marshalling exceptions from the environment structures).
> 
> Wow. After reading this, I ran (I did not walk) to my nearest mapping
> specs. It really seems possible for object references, structs and all
> the primitve stuff.
> 
> I am not quite sure whether it will work for sequences (yet, seems so),
> and I do not really get how you can get around stub factory hashing.
> Could you give me some clues?
> 

orbitcpp-0.25 (from the web page) already uses this feature for
marshalling sequences. You simply have the ORBit C sequence struct as
the only data member of the C++ wrapper  so that both the C and C++
version has the same memory footprint (and no virtual functions -i.e. no
vtable). Then write an operator-new() and operator-delete() to use the
appropriate ORBit C alloc and free functions. 

N.B. you also need a special string class (called String_mgr in
ORBit-C++) for string data members that does deep copies of const char*
strings (because the spec requires it). Since this class has a char* as
the only data member, it is also binary compatible with the C
CORBA_char* string mapping and so works in string sequences. The
String_mgr has an empty operator-delete() because calling CORBA_free()
on the underlying sequence buffer (again via operator-delete) will
implicitly free the strings; if you don't do this, the C++ runtime will
attempt to free them.

You can get round the stub factory hashing by using the same technique
for object stubs. Marshaling an out or return value object ref from C to
C++ means just reinterpret_cast'ing it to the C++ type. (method calls
will work because the compiler will 'do the right thing' because of the
type that it thinks it is).
Narrowing may be a bit more tricky, but it looks as if ORBit already has
an implemented CORBA_Object_is_a() function so that me be all that's
needed.



> > Do you have emacs or indent settings for your C++ indentation style -
> > maybe we could automate the translation between your style and one of
> > the 'standards' (I don't care which one) before it goes into CVS?
> 
> I do have emacs settings for it, but they suck. Indentation is not a
> matter of life or death to me. I like my style of indentation, but I
> have no problem using any other one, if that gives us loads of coders
> <g>
> 

Good. Can you recommend a good C++ indent program? (I've seen a couple
on freshmeat so I might investigate...)

> As you may have noticed, the compiler also does some indentation of its
> output, and of course the output is indented my way. we might have to
> look into that, or remove indentation entirely.

With the python compiler I didn't bother with indenting, and assumed
that I could probably just pass the file through indent or something
after compilation.

Cheers,

Phil.

Re: [orbitcpp-list] Comments about o2cpp

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

Hi Phil,

Phil dawes wrote:
> 
> Hi Andreas,
> 
> I've got a couple of comments about o2cpp:
> 
> 1) Licensing issues: Is your runtime LGPL? I could only find the GPL
> license in your tarball.

Whoops. I intended it to be all-LGPL. I just looked into it, and at the
top of the copying file it said
snip ---------------------------------------------------------------
                  GNU LIBRARY GENERAL PUBLIC LICENSE
                       Version 2, June 1991

 Copyright (C) 1991 Free Software Foundation, Inc.
                    675 Mass Ave, Cambridge, MA 02139, USA
 Everyone is permitted to copy and distribute verbatim copies
 of this license document, but changing it is not allowed.

[This is the first released version of the library GPL.  It is
 numbered 2 because it goes with version 2 of the ordinary GPL.]
snip ---------------------------------------------------------------

> 2) A little bug report: GCC 2.95.2 won't compile the basic example
> because the ORBit C skels declare an 'in' string as const char*, where
> as o2cpp's stubs declare it without the const. The compiler barfs on the
> epv function pointers.

fixed.

> 
> 3) There's a lot of code in the runtime. I haven't had a lot of time to
> look at it in detail, but it looks like a lot of the ORBit-C stuff is
> duplicated in the orb layer (interface hash lookups, poa implementation,
> reference counting, etc..).
> I've already made this mistake in ORBit-C++, and am now in the middle of
> rewriting the runtime code to take advantage of the built-in binary
> compatibility between the C and C++ language mappings.
> 
> If you give the C and C++ types the same binary footprint, then you can
> convert between them with a reinterpret cast. No need for hash lookups
> to identify the stub factory, and no need to deal with C++ object
> lifecycles in the stubs/skeletons and for a new ref counting
> implementation. The code size is much smaller and the marshalling code
> is almost non-existant (the only thing that requires stub code at all is
> marshalling exceptions from the environment structures).

Wow. After reading this, I ran (I did not walk) to my nearest mapping
specs. It really seems possible for object references, structs and all
the primitve stuff.

I am not quite sure whether it will work for sequences (yet, seems so),
and I do not really get how you can get around stub factory hashing.
Could you give me some clues?

To be honest, my runtime code was largely influenced by yours in some
parts, and most of the things you mention stem from that source (though
at times i called things differently to make it less obvious :)

> 4) Your indentation style is a little bizarre. If we do merge code I'd
> be a little concerned that it would be off-putting to other developers
> (just as my use of python was to you). Have you tried K&R, stroustrop or
> any of the other styles?
> Do you have emacs or indent settings for your C++ indentation style -
> maybe we could automate the translation between your style and one of
> the 'standards' (I don't care which one) before it goes into CVS?

I do have emacs settings for it, but they suck. Indentation is not a
matter of life or death to me. I like my style of indentation, but I
have no problem using any other one, if that gives us loads of coders
<g>

(erm, that is, given you do the conversion :) 

As you may have noticed, the compiler also does some indentation of its
output, and of course the output is indented my way. we might have to
look into that, or remove indentation entirely.

> 
> Cheers,
> 
> Phil.
> 

cu
andreas

Re: [orbitcpp-list] announcing o2cpp

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

Hi Phil,

Phil dawes wrote:
> 
> Cool - was I really that rude?

Guess so :) Nah, you did not quite hurt my feelings, but neither did I
feel you'd appreciate anything like a c++ port of the compiler at the
time.

> > * Choice of language
> 
> Fair enough (BTW, it's only the compiler that's written in python - all
> of the runtime is and will be in C++). What didn't you like about
> python?

True, it is only the compiler. But all this
get-python-install-automake-stuff-get-everything-to-work-retry-several-times
can really suck, and I believe it can scare people off, even coders.
People that are looking for a c++ binding do know c++, but they might
not know python. If they wanted to help properly, they'd have to know
both. 

(You want to know what i disliked about python? oh, plenty. not that i
had actually tried, but there were several things that pissed me off
enormously. first, python is not as declarative, as, say, c++. this
makes code generally a bit harder to read. also, python does not try to
separate declaration and implementation. second, qualifying everything
with "self." does not contribute to either code legibility or coding
speed. Of course, the need for extra qualification is a direct
consequence of having no declarations. third, i did at first not like
the idea of a language being picky about whitespace. (I have changed my
opinion a little on this one) ... <insert more senseless criticism
here>... )

> What's your plan? Do you want to join forces / merge code?

Yup. :) My proposal would be to base the "new thing" (tm) upon your new
runtime code (see other mail) along with an adapted version of my idl
compiler. Which sucks because it is loads of work to do. Not that I'd
mind, but currently I'm facing one and a half month featuring five
exams, in two weeks' distance each. I guess I won't be able to do much
of the like until March 24, when the exams will finally be over. After
that date, however, I've got six weeks of free time (being a student is
not so bad after all :).

We might start real soon by putting everything into one cvs tree,
however.

> 
> Cheers,
> 
> Phil.
> 
> (BTW, I've put my thoughts and comments about the o2cpp implementation
> in another mail)

(your fault. you'll have to read two replies ;)

cu
andreas

Re: [orbitcpp-list] announcing o2cpp

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

Hello Andreas,

    >> I'd like to announce to you the initial release of "o2cpp",
    >> version 0.10. o2cpp is (to become) a c++ mapping for
    >> orbit. Accidentally, you're trying to achieve the very same
    >> thing. Some of you may remember me asking last summer whether
    >> you'd need people to do a c++ port, well, the answer was
    >> "no,thanks", so i started over from scratch, which taught me a
    >> lot about corba, took about two weeks to write 99% of the code,
    >> then uni started again, i got busy with other things, and so it
    >> took another six months to let things culminate in this
    >> release.

I haven't yet had a chance to take a look at your binding code, but I
read Phil's first-look at it.  I'd be very interested in us working
together to develop a good C++ binding for ORBit.  I've been out of
the loop for a while, having run into a memory bug on Solaris that I
cannot for the life of me solve.  

As Phil said before, the code is currently being written such that it
will work, not really beauty....being picky about aesthetics >grin<,
I definitely have plans to clean up the code (or at least the dirt I
contributed).  At the same time, there exist some issues in the
ORBit-C implementation that I've been trying to fix for the sake of
the C++ wrapper.

Thanks for the comments.  I think we should work together and
cross-pollinate ideas.  I'll be taking a look at your implementation
in the near future (once I get some monkeys off my back here).

ron

Re: [orbitcpp-list] announcing o2cpp

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

Andreas Kloeckner wrote:
> 
> Hi,
> 
> I'd like to announce to you the initial release of "o2cpp", version
> 0.10. o2cpp is (to become) a c++ mapping for orbit. Accidentally, you're
> trying to achieve the very same thing. Some of you may remember me
> asking last summer whether you'd need people to do a c++ port, well, the
> answer was "no,thanks", so i started over from scratch, which taught me
> a lot about corba, took about two weeks to write 99% of the code, then
> uni started again, i got busy with other things, and so it took another
> six months to let things culminate in this release.
> 

Cool - was I really that rude?

> "Now why does this guy redo all the stuff we did?"
> --------------------------------------------------
> 
> * Choice of language
> 
> I believe Python is not quite the optimal choice of a language for a c++
> mapping, yet, one can debate that. my implementation is 100% pure c++.
> 

Fair enough (BTW, it's only the compiler that's written in python - all
of the runtime is and will be in C++). What didn't you like about
python?

> * IDL compiler design
> 
> At that time, you were using the visitor pattern as the main build
> scheme for your compiler. I don't know whether this is still true, but
> when I looked at it from a distance, it did not please me much out of
> one reason: Its use of inheritance and polymorphism in this setting is
> restricted. Thus, along with a new language, I am proposing to you a new
> compiler design: With my implementation, I have a class for every kind
> of IDL element, which in turn knows how to spit out its code if
> appropriate (e.g., cIDLType has a pure virtual method
> "writeCPPStubMarshalCode", which does so for any type given) Thus, any
> given type can be handled by the same code, and (e.g.) typedefs are
> straightforward and easy. Uh, this description isn't too good, but I'm
> sure you'll instantaneously get the point when looking at the code.
> 

I like the idea of having a single class for each IDL type - this may
well be a better design than my idl compiler. (Adding a new type still
requires changes to a number of files in my compiler)


> * Implementation integrity and robustness
> 
> Six months ago, some parts of the code seemed just not the way I'd liked
> them to be, mainly the "runtime" parts, i.e. ORB and POA stuff, as well
> as much of the generated code in the skeletons. Obviously, you will have
> made a bit of progress, so this may not be a point any more.
> 

To be honest, the runtime orb code is a bit 'fit-for-purpose'. When we
(Ronald and I) wrote it we were really looking to get something working
rather than making it a beautiful as possible, so a re-write is
definitely in order.

> "Why should the ORBit-C++ project care?"
> ----------------------------------------
> 
> Counting that two teams trying to do the same thing in basically the
> same manner do not cooperate makes both teams achieve less than they
> could.

Agreed.

> I have taken things so far as to not just be standing there, saying:
> "But wait, I want all this in C++!". I thought my request would be a bit
> more convincing if there was a base to start porting upon, so I decided
> to lay that base, and here it is.
> 
> After all, this project was always intended to augment, not to void your
> efforts.
> 

Cool! I have no qualms about an idl compiler rewrite in C++, and it's
certainly true that the runtime code *needs* rewriting.

What's your plan? Do you want to join forces / merge code? 

Cheers,

Phil.

(BTW, I've put my thoughts and comments about the o2cpp implementation
in another mail)

[orbitcpp-list] Comments about o2cpp

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

Hi Andreas,

I've got a couple of comments about o2cpp:

1) Licensing issues: Is your runtime LGPL? I could only find the GPL
license in your tarball.

2) A little bug report: GCC 2.95.2 won't compile the basic example
because the ORBit C skels declare an 'in' string as const char*, where
as o2cpp's stubs declare it without the const. The compiler barfs on the
epv function pointers.

3) There's a lot of code in the runtime. I haven't had a lot of time to
look at it in detail, but it looks like a lot of the ORBit-C stuff is
duplicated in the orb layer (interface hash lookups, poa implementation,
reference counting, etc..).
I've already made this mistake in ORBit-C++, and am now in the middle of
rewriting the runtime code to take advantage of the built-in binary
compatibility between the C and C++ language mappings. 

If you give the C and C++ types the same binary footprint, then you can
convert between them with a reinterpret cast. No need for hash lookups
to identify the stub factory, and no need to deal with C++ object
lifecycles in the stubs/skeletons and for a new ref counting
implementation. The code size is much smaller and the marshalling code
is almost non-existant (the only thing that requires stub code at all is
marshalling exceptions from the environment structures).

4) Your indentation style is a little bizarre. If we do merge code I'd
be a little concerned that it would be off-putting to other developers
(just as my use of python was to you). Have you tried K&R, stroustrop or
any of the other styles?
Do you have emacs or indent settings for your C++ indentation style -
maybe we could automate the translation between your style and one of
the 'standards' (I don't care which one) before it goes into CVS?

Cheers,

Phil.

[orbitcpp-list] announcing o2cpp

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

Hi,

I'd like to announce to you the initial release of "o2cpp", version
0.10. o2cpp is (to become) a c++ mapping for orbit. Accidentally, you're
trying to achieve the very same thing. Some of you may remember me
asking last summer whether you'd need people to do a c++ port, well, the
answer was "no,thanks", so i started over from scratch, which taught me
a lot about corba, took about two weeks to write 99% of the code, then
uni started again, i got busy with other things, and so it took another
six months to let things culminate in this release.

"Now why does this guy redo all the stuff we did?"
--------------------------------------------------

* Choice of language

I believe Python is not quite the optimal choice of a language for a c++
mapping, yet, one can debate that. my implementation is 100% pure c++.

* IDL compiler design

At that time, you were using the visitor pattern as the main build
scheme for your compiler. I don't know whether this is still true, but
when I looked at it from a distance, it did not please me much out of
one reason: Its use of inheritance and polymorphism in this setting is
restricted. Thus, along with a new language, I am proposing to you a new
compiler design: With my implementation, I have a class for every kind
of IDL element, which in turn knows how to spit out its code if
appropriate (e.g., cIDLType has a pure virtual method
"writeCPPStubMarshalCode", which does so for any type given) Thus, any
given type can be handled by the same code, and (e.g.) typedefs are
straightforward and easy. Uh, this description isn't too good, but I'm
sure you'll instantaneously get the point when looking at the code. 

* Implementation integrity and robustness

Six months ago, some parts of the code seemed just not the way I'd liked
them to be, mainly the "runtime" parts, i.e. ORB and POA stuff, as well
as much of the generated code in the skeletons. Obviously, you will have
made a bit of progress, so this may not be a point any more. 

"Why should the ORBit-C++ project care?"
----------------------------------------

Counting that two teams trying to do the same thing in basically the
same manner do not cooperate makes both teams achieve less than they
could.
I have taken things so far as to not just be standing there, saying:
"But wait, I want all this in C++!". I thought my request would be a bit
more convincing if there was a base to start porting upon, so I decided
to lay that base, and here it is.

After all, this project was always intended to augment, not to void your
efforts. 

"And how far have you come?"
----------------------------

Hope you don't mind if I paste this part from the README...

8<-----------------------------------
What o2cpp already has:

* a consistent compiler framework worked out as a backend to orbit-idl
* a c++ representation of the idl tree with some name lookup bells and
  whistles
* a consistent polymorphic type framework that should make adding new
types 
  a breeze: just add the appropriate translation code to pass1.cc (if it
is 
  a user-defined type), derive your new type from 
  cIDLType/cIDLUserDefType/CIDLUserDefScopeType (types.hh,
  types.cc) and add it to the type parser in types.cc. That should do
the 
  trick.
  (For your reference: It took me hardly an hour to hack in the 
  string type after all. All I had to change was types.cc!
  Structs shouldn't be hard either - the exception code already leads
the way)
* quite a bit of runtime code:
  - basic type definitions
  - sequence types
  - smart pointer types
  - full exception support
  - _var and _out templates
  - ORB (partly)
  - stub generation
  - POA (mostly)
* correct type mapping of
  - basic types
  - typedefs
  - interfaces
  - operations
  - object reference types
  - exceptions
  - strings
* rather complete headers / declarations of all the pseudo objects
* stub generation and registration, including exception support and 
  parameter/return (de)marshalling, based on the above type framework
* skeleton generation, including exception support
* source-code pretty-printing
* support of non-static-initialization environments (such as dlopen'd
libraries
  on some platforms)

What o2cpp is still missing:

* constants (easy)
* types
  - enum, fixed
  - sequence (templates already done)
  - struct,union,array
* attributes
* Policies
* TypeCodes (header already there)
* DII
* DSI
* CORBAservices headers (easy: put in IDL, have it compiled by Makefile)
8<-----------------------------------

The source has an introductory README, is well structured (at least I
think so!), nicely indented and commented in places. If you ask me to, I
can give you a head start on what is where.

"I want to try it."
-------------------

Fine! Thanks for giving it a try. Look for it at

http://www.stud.uni-karlsruhe.de/~uj6g/o2cpp

One thing I should mention: You should either be in possession of a
_current_ cvs orbit (that is, after January 21), or apply the patch to
be found on the homepage.

Well, thanks for reading all this. If you feel like it, flame me! 

cu
andreas

[orbitcpp-list] orbitcpp-0.25.tar.gz released

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

Hi Folks,

I've just made a new release tarball. You need gcc 2.95.2 to compile
this one on linux - I don't know about other compilers. Check out the
webpage for details: http://orbitcpp.sourceforge.net/
It adds sequence support and fixes a couple of bugs.

Targets for the next release:

- Enough stuff working to use the CosNaming service
- A revamp of the orb and objref code to make things smaller and faster
- Fix that problem with solaris that Ron found.
- Probably include some of Gordons typedef support if it's ready

Cheers,

Phil.

[orbitcpp-list] sequence support in CVS

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

Hi folks,

Good news:
I've just committed variable length sequence support to CVS. 

Bad news:
You need gcc-2.95.2 to compile it (or at least it's a requirement on my
redhat box)

The problem is that the sequence implementation requires a specialised
implementation of 'operator new' for the sequence template class. This
doesn't seem to work with older gcc and egcs versions. 

For those with redhat linux wanting to make the upgrade, I grabbed the
following rpms from the rawhide section on my local ftp.redhat.com
mirror:
gcc, gcc-c++, cpp, binutils, libstdc++ and libstdc++-devel. I also
installed libstdc++-compat (or something) so that existing c++ stuff
linked to old libraries still worked.

Cheers,

Phil.

BTW, Thanks to those who've submitted bugs - I'll fix them before doing
the next release. (I don't know who you are because the bug submit form
doesn't seem to have a field to identify you - I've just mailed the
sourceforge admin people about it)

Re: [orbitcpp-list] Typecode implementation

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

Gordon Miller wrote:
> 
> Since I've started down the Any path, I'll go ahead and look at
> implementing typecode.  I'm very familiar with what a typecode is and
> does, but I'm going to have to look at the Typecode support in orbit to
> see how they do things and then how to implement it.  I'll probably work
> on the pyIDL stuff first just to get things to compile and then work on
> the C++ classes that wrap the orbit functions.  I'll get working on that
> tonight or tomorrow morning.  pyIDL will probably be done within a
> couple days (Thursday ideally) and then I'll move to the C++ classes.
> As you stated Phil, the Any implementation will rely on Typecode.
> 

Hi Gordon,

Here's some info and tips for wrapping the ORBit C stuff in C++:

CORBA_free
----------
ORBit has it's own memory management scheme which allows all CORBA types
to be deep free'd using CORBA_free() (which is a requirement of the
CORBA C mapping spec - a bit of a crap one IMHO). It does this by
imbedding a structure in memory directly behind the type when it is
created, which contains information about the type and a function
pointer to a destructor. When you call CORBA_free it swizzles the
pointer to get the structure.

Wrapping C types in C++
-----------------------
If at all possible, strive to make the C++ type binary compatible with
the eqivalent C type. Ideally, this means that the type can be new'd in
C++, and then CORBA_free()'d in C. This makes the marshalling trivial
and fast (a simple reinterpret_cast does the trick!). I've achieved this
in all the complex CORBA types I attempted except objref using the
following technique:

1) Define the C++ class with one data member - the C type. Base all the
functions around this.
2) Don't implement any virtual functions, otherwise the C++ compiler
will create a vtable, and all bets are off. (This is the reason for not
being able to do it for objref, which requires inheritance)
3) Write an operator new and delete to use the equivilent ORBit C
function for creation and CORBA_free for deletion (and doing the
appropriate reinterpret casting).

I think think this is alright with regards to portibility, since a
compliant c++ compiler must lay out C++ structs to be binary compatible
with C ones. At the moment I'm assuming that cpp classes have the same
binary layout as cpp structs, however I'm not sure whether this is
actually in the language spec anywhere.

Hope this helps with your typedef porting efforts,

Phil.

[orbitcpp-list] Typecode implementation

[Gordon M. <gm...@bi...>]

Since I've started down the Any path, I'll go ahead and look at
implementing typecode.  I'm very familiar with what a typecode is and
does, but I'm going to have to look at the Typecode support in orbit to
see how they do things and then how to implement it.  I'll probably work
on the pyIDL stuff first just to get things to compile and then work on
the C++ classes that wrap the orbit functions.  I'll get working on that
tonight or tomorrow morning.  pyIDL will probably be done within a
couple days (Thursday ideally) and then I'll move to the C++ classes. 
As you stated Phil, the Any implementation will rely on Typecode.

[orbitcpp-list] Re: any patch

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

Gordon Miller wrote:
> 
> 
> Phil,
> 
> Attached is the patch that I created according to your instructions.  It
> seems awfully large to be a completely clean build so there might be
> some executable code trapped in there.  If there is, I apologize.  I
> will attempt to do a cleaner job in the future.  I have to admit a
> little bit of ignorance in the ways of patch.
> 

The patch worked a treat - I've committed your code to CVS.
Could I ask you to do a fresh checkout from cvs and work from that? I
noticed that there was some old code in pyIDL (accept() methods that
were used in the old days when I used the visitor pattern for the idl
compiler rather than the template-method pattern). I've no idea how they
could have got there unless there's some dodgy CVS versioning going on
somewhere, and a fresh checkout should fix that.

I noticed that you cleaned up the pyIDL code a bit to fit on 80 char
width screen; Thanks for that - I get a bit carried away with long lines
sometimes. 

BTW, There were some build files in the patch, however this will be
pretty unavoidable until I fix the 'make maintainer-clean' target so
that it works and clears out all the build files properly. It's
currently getting mixed up and attempting to build the cpp files in the
test directory using the idl compiler that has already been 'cleaned'
and so doesn't work. Once that's fixed, you'll be able to do a 'make
maintainer-clean' before doing your diff and all will be well.

> I have tested this by running it against the CosEventComm.idl and it
> appears to generate the correct idl.  I also have an any.py test that
> works against the any.idl that is also in the tests directory.

Yep. I added the any.idl file to the EXTRA_DIST target in the tests
Makefile.am. This makes sure that the idl file is included in the
distribution when I do a 'make dist' to generate it.


> I've also discovered that in order for us to really treat Anys, I'm
> going to have to create an Any object.  My plan is to just go ahead and
> wrap the existing Any stuff that is in ORBit (as it appears this is the
> general plan).  I have actually implemented Any objects in the past, so
> I'm pretty confident in my abilities for this.  Do you have a link to
> the CORBA C++ language mapping specification so that I don't miss
> anything?

You should be able to get the C++ language mapping spec on 
http://www.omg.org/library/clangindx.html

N.B. Unfortunately ORBit-C++ doesn't support typecode yet either - if my
understanding is correct, we'll need that before a full implementation
of any is possible.

cheers,

Phil.

Re: [orbitcpp-list] Support for any in pyIDL

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

Ronald Garcia wrote:
> 
> >>>>> "pd" == Phil Dawes <ph...@or...> writes:
> 
>     pd> Please do! I'm currently working on sequences, and Ron I think
>     pd> is having problems with segfaults on solaris (did you manage
>     pd> to get any further Ron? I haven't had the solaris box back to
>     pd> try yet), and judging from the ORBit list has been working on
>     pd> that too. I don't think you'd be stepping on anybody's toes.
> 
> Hey there.  I'm finally back in front of my solaris box (hacking from
> a windows 98 telnet session is truly unfun).  

Have you tried putty.exe? I find this to be a good (and free) windows
telnet for hacking with (even does the syntax colour stuff with
xemacs!).

> Haven't found the source
> of the problem yet, but I'll be working on that again now.
> 

Cool!

> Good to see some more help joining in!
> 

Isn't it!

Cheers,

Phil.

Re: [orbitcpp-list] Support for any in pyIDL

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

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


    pd> Please do! I'm currently working on sequences, and Ron I think
    pd> is having problems with segfaults on solaris (did you manage
    pd> to get any further Ron? I haven't had the solaris box back to
    pd> try yet), and judging from the ORBit list has been working on
    pd> that too. I don't think you'd be stepping on anybody's toes.

Hey there.  I'm finally back in front of my solaris box (hacking from
a windows 98 telnet session is truly unfun).  Haven't found the source 
of the problem yet, but I'll be working on that again now.

Good to see some more help joining in!

ron

[orbitcpp-list] cvs commits mailing list

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

There's an orbitcpp cvs commits list for people interested in getting
notification of commits to CVS. The formatting of the email is a bit
lame at the moment but should get better once I get round to creating a
new script for the gnome cvs server.

To subscribe, go to:
http://lists.sourceforge.net/mailman/listinfo/orbitcpp-commits

Cheers,

Phil

[orbitcpp-list] Bug Tracking software

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

ORBit-C++ has a bug tracking system - you can get to it from the
orbitcpp sourceforge project page:
http://sourceforge.net/project/?group_id=646

I'll stick a link on the web page soon.

Cheers,

Phil.

Re: [orbitcpp-list] Two IDLN enumerations for Any, which one to use

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

Gordon Miller wrote:
> 
> I've written an extension to the pyIDL to add an IDLTypeAny object and
> I've also written a test for it.  While writing the test, I discovered
> that IDL.h defines two enumerations for Any's IDLN_ANY and
> IDLN_TYPE_ANY.  Does anyone know the difference?  Which one should I be
> using?  I'm currently using IDLN_TYPE_ANY.
> 

I believe the IDLN_ANY type is for representing actual ANY values, like
are used in const declarations: e.g. 

const Any foo =  <VALUE OF ANY>;

 (or at least that's how it works with IDLN_INTEGER verses
IDLN_TYPE_INTEGER). IDLN_TYPE_ANY is (as you correctly assumed) for
representing the type, as used in operation signatures etc.. 

> I'm attaching a diff that was done in the pyIDL directory with my
> changes.  These should include changes to src/pyIDL, src/test.py,
> tests/any.idl, tests/any.py

Thanks, I'll mail back once I've looked at it.

Cheers,

Phil.

[orbitcpp-list] Re: Userdefines types in struct parameters fails

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

Petter Reinholdtsen wrote:
> 
> The following IDL file gives illegal C++ code in testsim-cpp-skels.cc.
> If I replace 'meter x,y' with 'float x,y', it compiles.
> 
>   module testsim
>   {
>     typedef float meter;
>     struct PositionType{
>       meter x;
>       meter y;
>     };
>     interface robot {
>       long VWGetPosition(in short handle, out PositionType pos);
>     };
>   };
> 

Many thanks for this. I'll see if I can fix it tonight.

> BTW: You should add a reference to the mailinglist in the README, if
> this is where you want people to send bug reports.  I'm currently
> sitting offline, and have no way to find the email address of the
> list. :-(

It's okay - I've CC'd this reply to the orbitcpp list. Actually, there's
a bug tracking page on the web (as part of the rather fantastic services
that sourceforge provides). I'll dig up the URL to it and post it to the
list.

Cheers,

Phil.