typelib + idl generation revisited.

I've been investigating what it would take to have TAO support in typegen. The
main reason, why TAO is not supported, is because the IDL is generated like
this:


module orogen { 
      module Corba { / * define all structs, using "sequence<Foo> foo;" syntax 
*/ }; 

  module std { module Corba { /*define all sequence typedefs */ 
             typedef sequence<Foo> _vector__Foo_;
 };
};


Since the sequence typedefs are all generated at the end, the structs can not
use the "_vector__Foo_" typedefs and the sequence types used in the structs
are undefined by the CORBA standard, so TAO and Omniorb don't agree.

That's why Sylvain hardcoded Omniorb in the typegen tool. If we don't change
typelib right now, we'll also have to hardcode TAO in the typegen tool, for
the same reasons.

So I thought, let's look for the clean solution, being a nice pair of struct +
sequence typedef and then re-using the typedef'ed type in the next struct,
if necessary:


module orogen { 

 module Corba { / * define one struct */ }; 

   module std { module Corba { /*define a sequence of struct above */ 
                typedef sequence<Foo> _vector__Foo_;
 };

    module Corba { / * define another structs, using "_vector_Foo_" syntax */ 
}; 

  module std { module Corba { /*define a sequence of struct above */ 
                typedef sequence<Bar> _vector__Bar_;
 };
 /* etc.... */
};


This needs a change in typelib/lang/corba/export.cc . After some digging, it
appears that typelib *intentionally* generates all structs first (for any
language, not only IDL) and then all typedefs, because (I quote) "Some
exporters need to limit how many times a namespace appears. So, the main
algorithm (here) is meant to limit switching between namespaces."

I don't know which languages that don't handle open namespaces, but it seems
that I can't change it at all, because it's a global setting.

The only way I could see a solution is by generating the typedefs de-facto
after each struct, even if the main typelib loop doesn't dictate it yet and
then assume that for each sequence<struct>, the typedef is available

OR

do the hardcoding of TAO in typegen's corba.rb marshaller, generate both TAO
and Omniorb and use #ifdefs in the generated code to decide at compile time.

From where I was standing, the first option was the easiest (it's modifying C++
code instead of Ruby code :-) , and only a few lines of code needed to be
changed in both typelib and orogen. The generated code then works for both TAO
and omniorb, but broader testing/review might be needed in case I missed
something.

Sylvain, would you accept this solution ?

Peter

AttachmentSize
typelib-generatet-typedefs.patch1.05 KB
orogen-use-typedef-names.patch1.23 KB

typelib + idl generation revisited.

For your information, I've updated the IDL modifications and modified
oroGen to use the "right" typedefs.

Now, I'm waiting for the oroGen-in-toolchain-2.1 situation to push them
to their respective master.
--

Sylvain Joyeux
Space& Security Robotics

!!! Achtung, neue Telefonnummer!!!

Standort Bremen:
DFKI GmbH
Robotics Innovation Center
Robert-Hooke-Straße 5
28359 Bremen, Germany

Phone: +49 (0)421 178-454136
Fax: +49 (0)421 218-454150
E-Mail: robotik [..] ...

Weitere Informationen: http://www.dfki.de/robotik
-----------------------------------------------------------------------
Deutsches Forschungszentrum fuer Kuenstliche Intelligenz GmbH
Firmensitz: Trippstadter Straße 122, D-67663 Kaiserslautern
Geschaeftsfuehrung: Prof. Dr. Dr. h.c. mult. Wolfgang Wahlster
(Vorsitzender) Dr. Walter Olthoff
Vorsitzender des Aufsichtsrats: Prof. Dr. h.c. Hans A. Aukes
Amtsgericht Kaiserslautern, HRB 2313
Sitz der Gesellschaft: Kaiserslautern (HRB 2313)
USt-Id.Nr.: DE 148646973
Steuernummer: 19/673/0060/3
-----------------------------------------------------------------------

typelib + idl generation revisited.

On 10/22/2010 11:03 PM, Peter Soetens wrote:
> I've been investigating what it would take to have TAO support in typegen. The
> main reason, why TAO is not supported, is because the IDL is generated like
> this:
>
> &#10;&gt; module orogen {&#10;&gt;      module Corba { / * define all structs, using &quot;sequence&lt;Foo&gt;  foo;&quot; syntax&#10;&gt; */ };&#10;&gt;&#10;&gt;      module std { module Corba { /*define all sequence typedefs */&#10;&gt;          typedef sequence&lt;Foo&gt;  _vector__Foo_;&#10;&gt;    };&#10;&gt; };&#10;&gt;
>
> Since the sequence typedefs are all generated at the end, the structs can not
> use the "_vector__Foo_" typedefs and the sequence types used in the structs
> are undefined by the CORBA standard, so TAO and Omniorb don't agree.
To summarize: the generated C++ class for a plain sequence<T> is
non-specified, so if we want to know the type of a field (for instance)
of type sequence<T>, we have to generate a typedef and use it. Right ?

> This needs a change in typelib/lang/corba/export.cc . After some digging, it
> appears that typelib *intentionally* generates all structs first (for any
> language, not only IDL) and then all typedefs, because (I quote) "Some
> exporters need to limit how many times a namespace appears. So, the main
> algorithm (here) is meant to limit switching between namespaces."
>
> I don't know which languages that don't handle open namespaces, but it seems
> that I can't change it at all, because it's a global setting.
It is not "what languages". These changes stem from the omniidl compiler
that does not "like" them. I.e., it will sometime generate
non-compilable code in some cases -- to the OmniORB developers defense,
I did not report that bug ...

> The only way I could see a solution is by generating the typedefs de-facto
> after each struct, even if the main typelib loop doesn't dictate it yet and
> then assume that for each sequence<struct>, the typedef is available
The general fix idea right, the implementation is wrong. You should have
generated the necessary typedefs for each container (Container const&
visitor method). For instance, you can have sequences of other things
than structs (enums, basic types, ...). Moreover, you might generate the
same typedef twice (does IDL like that ?).

i.e. don't commit those patches. To your defense, the IDL export
implementation is a mess. I've cleaned it up and implemented the fix you
propose. I'll create a merge request with those patches (but later in
the day, I have to go first to a meeting). I've just recompiled all our
orogen modules and it worked, so I think it is quite OK right now.

Once I've pushed this patch, you will have to fix orogen C++/CORBA
generated code.

typelib + idl generation revisited.

On 10/25/2010 09:58 AM, Sylvain Joyeux wrote:
> Once I've pushed this patch, you will have to fix orogen C++/CORBA
> generated code.

The two IDL fixes are the two top commits of refs/merge-requests/5. I am
sorry, it also contains the misc bugfixes I have in the pipe.

http://gitorious.org/orocos-toolchain/typelib/merge_requests/5

typelib + idl generation revisited.

On Mon, Oct 25, 2010 at 3:24 PM, Sylvain Joyeux <sylvain [dot] joyeux [..] ...> wrote:
>  On 10/25/2010 09:58 AM, Sylvain Joyeux wrote:
>>
>> Once I've pushed this patch, you will have to fix orogen C++/CORBA
>> generated code.
>
> The two IDL fixes are the two top commits of refs/merge-requests/5. I am
> sorry, it also contains the misc bugfixes I have in the pipe.
>
>   http://gitorious.org/orocos-toolchain/typelib/merge_requests/5

Thanks.

I didn't test this with namespaces and imports (ie depending on other
typekits living in other namespaces).

I'm also out of office this week, so I'll be slow to respond to any
email/problem.

Peter

>
> --
> Sylvain Joyeux
> Space&  Security Robotics
>
> Standort Bremen:
> DFKI GmbH
> Robotics Innovation Center
> Robert-Hooke-Straße 5
> 28359 Bremen, Germany
>
> Phone: +49 (0)421 218-64136
> Fax:   +49 (0)421 218-64150
> E-Mail: robotik [..] ...
>
> Weitere Informationen: http://www.dfki.de/robotik
> -----------------------------------------------------------------------
> Deutsches Forschungszentrum fuer Kuenstliche Intelligenz GmbH
> Firmensitz: Trippstadter Straße 122, D-67663 Kaiserslautern
> Geschaeftsfuehrung: Prof. Dr. Dr. h.c. mult. Wolfgang Wahlster
> (Vorsitzender) Dr. Walter Olthoff
> Vorsitzender des Aufsichtsrats: Prof. Dr. h.c. Hans A. Aukes
> Amtsgericht Kaiserslautern, HRB 2313
> Sitz der Gesellschaft: Kaiserslautern (HRB 2313)
> USt-Id.Nr.:    DE 148646973
> Steuernummer:  19/673/0060/3
> -----------------------------------------------------------------------
>
>
--
Orocos-Dev mailing list
Orocos-Dev [..] ...
http://lists.mech.kuleuven.be/mailman/listinfo/orocos-dev

typelib + idl generation revisited.

I've been investigating what it would take to have TAO support in typegen. The
main reason, why TAO is not supported, is because the IDL is generated like
this:

&#10;module orogen { &#10;      module Corba { / * define all structs, using &quot;sequence&lt;Foo&gt; foo;&quot; syntax &#10;*/ }; &#10;&#10;  module std { module Corba { /*define all sequence typedefs */ &#10;             typedef sequence&lt;Foo&gt; _vector__Foo_;&#10; };&#10;};&#10;

Since the sequence typedefs are all generated at the end, the structs can not
use the "_vector__Foo_" typedefs and the sequence types used in the structs
are undefined by the CORBA standard, so TAO and Omniorb don't agree.

That's why Sylvain hardcoded Omniorb in the typegen tool. If we don't change
typelib right now, we'll also have to hardcode TAO in the typegen tool, for
the same reasons.

So I thought, let's look for the clean solution, being a nice pair of struct +
sequence typedef and then re-using the typedef'ed type in the next struct,
if necessary:

&#10;module orogen { &#10;&#10; module Corba { / * define one struct */ }; &#10;&#10;   module std { module Corba { /*define a sequence of struct above */ &#10;                typedef sequence&lt;Foo&gt; _vector__Foo_;&#10; };&#10;&#10;    module Corba { / * define another structs, using &quot;_vector_Foo_&quot; syntax */ &#10;}; &#10;&#10;  module std { module Corba { /*define a sequence of struct above */ &#10;                typedef sequence&lt;Bar&gt; _vector__Bar_;&#10; };&#10; /* etc.... */&#10;};&#10;

This needs a change in typelib/lang/corba/export.cc . After some digging, it
appears that typelib *intentionally* generates all structs first (for any
language, not only IDL) and then all typedefs, because (I quote) "Some
exporters need to limit how many times a namespace appears. So, the main
algorithm (here) is meant to limit switching between namespaces."

I don't know which languages that don't handle open namespaces, but it seems
that I can't change it at all, because it's a global setting.

The only way I could see a solution is by generating the typedefs de-facto
after each struct, even if the main typelib loop doesn't dictate it yet and
then assume that for each sequence<struct>, the typedef is available

OR

do the hardcoding of TAO in typegen's corba.rb marshaller, generate both TAO
and Omniorb and use #ifdefs in the generated code to decide at compile time.

From where I was standing, the first option was the easiest (it's modifying C++
code instead of Ruby code :-) , and only a few lines of code needed to be
changed in both typelib and orogen. The generated code then works for both TAO
and omniorb, but broader testing/review might be needed in case I missed
something.

Sylvain, would you accept this solution ?

Peter

typelib + idl generation revisited.

I've been investigating what it would take to have TAO support in typegen. The
main reason, why TAO is not supported, is because the IDL is generated like
this:

&#10;module orogen { &#10;      module Corba { / * define all structs, using &quot;sequence&lt;Foo&gt; foo;&quot; syntax &#10;*/ }; &#10;&#10;  module std { module Corba { /*define all sequence typedefs */ &#10;             typedef sequence&lt;Foo&gt; _vector__Foo_;&#10; };&#10;};&#10;

Since the sequence typedefs are all generated at the end, the structs can not
use the "_vector__Foo_" typedefs and the sequence types used in the structs
are undefined by the CORBA standard, so TAO and Omniorb don't agree.

That's why Sylvain hardcoded Omniorb in the typegen tool. If we don't change
typelib right now, we'll also have to hardcode TAO in the typegen tool, for
the same reasons.

So I thought, let's look for the clean solution, being a nice pair of struct +
sequence typedef and then re-using the typedef'ed type in the next struct,
if necessary:

&#10;module orogen { &#10;&#10; module Corba { / * define one struct */ }; &#10;&#10;   module std { module Corba { /*define a sequence of struct above */ &#10;                typedef sequence&lt;Foo&gt; _vector__Foo_;&#10; };&#10;&#10;    module Corba { / * define another structs, using &quot;_vector_Foo_&quot; syntax */ &#10;}; &#10;&#10;  module std { module Corba { /*define a sequence of struct above */ &#10;                typedef sequence&lt;Bar&gt; _vector__Bar_;&#10; };&#10; /* etc.... */&#10;};&#10;

This needs a change in typelib/lang/corba/export.cc . After some digging, it
appears that typelib *intentionally* generates all structs first (for any
language, not only IDL) and then all typedefs, because (I quote) "Some
exporters need to limit how many times a namespace appears. So, the main
algorithm (here) is meant to limit switching between namespaces."

I don't know which languages that don't handle open namespaces, but it seems
that I can't change it at all, because it's a global setting.

The only way I could see a solution is by generating the typedefs de-facto
after each struct, even if the main typelib loop doesn't dictate it yet and
then assume that for each sequence<struct>, the typedef is available

OR

do the hardcoding of TAO in typegen's corba.rb marshaller, generate both TAO
and Omniorb and use #ifdefs in the generated code to decide at compile time.

From where I was standing, the first option was the easiest (it's modifying C++
code instead of Ruby code :-) , and only a few lines of code needed to be
changed in both typelib and orogen. The generated code then works for both TAO
and omniorb, but broader testing/review might be needed in case I missed
something.

Sylvain, would you accept this solution ?

Peter

typelib + idl generation revisited.

I've been investigating what it would take to have TAO support in typegen. The
main reason, why TAO is not supported, is because the IDL is generated like
this:

&#10;module orogen { &#10;      module Corba { / * define all structs, using &quot;sequence&lt;Foo&gt; foo;&quot; syntax &#10;*/ }; &#10;&#10;  module std { module Corba { /*define all sequence typedefs */ &#10;             typedef sequence&lt;Foo&gt; _vector__Foo_;&#10; };&#10;};&#10;

Since the sequence typedefs are all generated at the end, the structs can not
use the "_vector__Foo_" typedefs and the sequence types used in the structs
are undefined by the CORBA standard, so TAO and Omniorb don't agree.

That's why Sylvain hardcoded Omniorb in the typegen tool. If we don't change
typelib right now, we'll also have to hardcode TAO in the typegen tool, for
the same reasons.

So I thought, let's look for the clean solution, being a nice pair of struct +
sequence typedef and then re-using the typedef'ed type in the next struct,
if necessary:

&#10;module orogen { &#10;&#10; module Corba { / * define one struct */ }; &#10;&#10;   module std { module Corba { /*define a sequence of struct above */ &#10;                typedef sequence&lt;Foo&gt; _vector__Foo_;&#10; };&#10;&#10;    module Corba { / * define another structs, using &quot;_vector_Foo_&quot; syntax */ &#10;}; &#10;&#10;  module std { module Corba { /*define a sequence of struct above */ &#10;                typedef sequence&lt;Bar&gt; _vector__Bar_;&#10; };&#10; /* etc.... */&#10;};&#10;

This needs a change in typelib/lang/corba/export.cc . After some digging, it
appears that typelib *intentionally* generates all structs first (for any
language, not only IDL) and then all typedefs, because (I quote) "Some
exporters need to limit how many times a namespace appears. So, the main
algorithm (here) is meant to limit switching between namespaces."

I don't know which languages that don't handle open namespaces, but it seems
that I can't change it at all, because it's a global setting.

The only way I could see a solution is by generating the typedefs de-facto
after each struct, even if the main typelib loop doesn't dictate it yet and
then assume that for each sequence<struct>, the typedef is available

OR

do the hardcoding of TAO in typegen's corba.rb marshaller, generate both TAO
and Omniorb and use #ifdefs in the generated code to decide at compile time.

From where I was standing, the first option was the easiest (it's modifying C++
code instead of Ruby code :-) , and only a few lines of code needed to be
changed in both typelib and orogen. The generated code then works for both TAO
and omniorb, but broader testing/review might be needed in case I missed
something.

Sylvain, would you accept this solution ?

Peter

typelib + idl generation revisited.

I've been investigating what it would take to have TAO support in typegen. The
main reason, why TAO is not supported, is because the IDL is generated like
this:

&#10;module orogen { &#10;      module Corba { / * define all structs, using &quot;sequence&lt;Foo&gt; foo;&quot; syntax &#10;*/ }; &#10;&#10;  module std { module Corba { /*define all sequence typedefs */ &#10;             typedef sequence&lt;Foo&gt; _vector__Foo_;&#10; };&#10;};&#10;

Since the sequence typedefs are all generated at the end, the structs can not
use the "_vector__Foo_" typedefs and the sequence types used in the structs
are undefined by the CORBA standard, so TAO and Omniorb don't agree.

That's why Sylvain hardcoded Omniorb in the typegen tool. If we don't change
typelib right now, we'll also have to hardcode TAO in the typegen tool, for
the same reasons.

So I thought, let's look for the clean solution, being a nice pair of struct +
sequence typedef and then re-using the typedef'ed type in the next struct,
if necessary:

&#10;module orogen { &#10;&#10; module Corba { / * define one struct */ }; &#10;&#10;   module std { module Corba { /*define a sequence of struct above */ &#10;                typedef sequence&lt;Foo&gt; _vector__Foo_;&#10; };&#10;&#10;    module Corba { / * define another structs, using &quot;_vector_Foo_&quot; syntax */ &#10;}; &#10;&#10;  module std { module Corba { /*define a sequence of struct above */ &#10;                typedef sequence&lt;Bar&gt; _vector__Bar_;&#10; };&#10; /* etc.... */&#10;};&#10;

This needs a change in typelib/lang/corba/export.cc . After some digging, it
appears that typelib *intentionally* generates all structs first (for any
language, not only IDL) and then all typedefs, because (I quote) "Some
exporters need to limit how many times a namespace appears. So, the main
algorithm (here) is meant to limit switching between namespaces."

I don't know which languages that don't handle open namespaces, but it seems
that I can't change it at all, because it's a global setting.

The only way I could see a solution is by generating the typedefs de-facto
after each struct, even if the main typelib loop doesn't dictate it yet and
then assume that for each sequence<struct>, the typedef is available

OR

do the hardcoding of TAO in typegen's corba.rb marshaller, generate both TAO
and Omniorb and use #ifdefs in the generated code to decide at compile time.

From where I was standing, the first option was the easiest (it's modifying C++
code instead of Ruby code :-) , and only a few lines of code needed to be
changed in both typelib and orogen. The generated code then works for both TAO
and omniorb, but broader testing/review might be needed in case I missed
something.

Sylvain, would you accept this solution ?

Peter

typelib + idl generation revisited.

I've been investigating what it would take to have TAO support in typegen. The
main reason, why TAO is not supported, is because the IDL is generated like
this:

&#10;module orogen { &#10;      module Corba { / * define all structs, using &quot;sequence&lt;Foo&gt; foo;&quot; syntax &#10;*/ }; &#10;&#10;  module std { module Corba { /*define all sequence typedefs */ &#10;             typedef sequence&lt;Foo&gt; _vector__Foo_;&#10; };&#10;};&#10;

Since the sequence typedefs are all generated at the end, the structs can not
use the "_vector__Foo_" typedefs and the sequence types used in the structs
are undefined by the CORBA standard, so TAO and Omniorb don't agree.

That's why Sylvain hardcoded Omniorb in the typegen tool. If we don't change
typelib right now, we'll also have to hardcode TAO in the typegen tool, for
the same reasons.

So I thought, let's look for the clean solution, being a nice pair of struct +
sequence typedef and then re-using the typedef'ed type in the next struct,
if necessary:

&#10;module orogen { &#10;&#10; module Corba { / * define one struct */ }; &#10;&#10;   module std { module Corba { /*define a sequence of struct above */ &#10;                typedef sequence&lt;Foo&gt; _vector__Foo_;&#10; };&#10;&#10;    module Corba { / * define another structs, using &quot;_vector_Foo_&quot; syntax */ &#10;}; &#10;&#10;  module std { module Corba { /*define a sequence of struct above */ &#10;                typedef sequence&lt;Bar&gt; _vector__Bar_;&#10; };&#10; /* etc.... */&#10;};&#10;

This needs a change in typelib/lang/corba/export.cc . After some digging, it
appears that typelib *intentionally* generates all structs first (for any
language, not only IDL) and then all typedefs, because (I quote) "Some
exporters need to limit how many times a namespace appears. So, the main
algorithm (here) is meant to limit switching between namespaces."

I don't know which languages that don't handle open namespaces, but it seems
that I can't change it at all, because it's a global setting.

The only way I could see a solution is by generating the typedefs de-facto
after each struct, even if the main typelib loop doesn't dictate it yet and
then assume that for each sequence<struct>, the typedef is available

OR

do the hardcoding of TAO in typegen's corba.rb marshaller, generate both TAO
and Omniorb and use #ifdefs in the generated code to decide at compile time.

From where I was standing, the first option was the easiest (it's modifying C++
code instead of Ruby code :-) , and only a few lines of code needed to be
changed in both typelib and orogen. The generated code then works for both TAO
and omniorb, but broader testing/review might be needed in case I missed
something.

Sylvain, would you accept this solution ?

Peter

typelib + idl generation revisited.

I've been investigating what it would take to have TAO support in typegen. The
main reason, why TAO is not supported, is because the IDL is generated like
this:

&#10;module orogen { &#10;      module Corba { / * define all structs, using &quot;sequence&lt;Foo&gt; foo;&quot; syntax &#10;*/ }; &#10;&#10;  module std { module Corba { /*define all sequence typedefs */ &#10;             typedef sequence&lt;Foo&gt; _vector__Foo_;&#10; };&#10;};&#10;

Since the sequence typedefs are all generated at the end, the structs can not
use the "_vector__Foo_" typedefs and the sequence types used in the structs
are undefined by the CORBA standard, so TAO and Omniorb don't agree.

That's why Sylvain hardcoded Omniorb in the typegen tool. If we don't change
typelib right now, we'll also have to hardcode TAO in the typegen tool, for
the same reasons.

So I thought, let's look for the clean solution, being a nice pair of struct +
sequence typedef and then re-using the typedef'ed type in the next struct,
if necessary:

&#10;module orogen { &#10;&#10; module Corba { / * define one struct */ }; &#10;&#10;   module std { module Corba { /*define a sequence of struct above */ &#10;                typedef sequence&lt;Foo&gt; _vector__Foo_;&#10; };&#10;&#10;    module Corba { / * define another structs, using &quot;_vector_Foo_&quot; syntax */ &#10;}; &#10;&#10;  module std { module Corba { /*define a sequence of struct above */ &#10;                typedef sequence&lt;Bar&gt; _vector__Bar_;&#10; };&#10; /* etc.... */&#10;};&#10;

This needs a change in typelib/lang/corba/export.cc . After some digging, it
appears that typelib *intentionally* generates all structs first (for any
language, not only IDL) and then all typedefs, because (I quote) "Some
exporters need to limit how many times a namespace appears. So, the main
algorithm (here) is meant to limit switching between namespaces."

I don't know which languages that don't handle open namespaces, but it seems
that I can't change it at all, because it's a global setting.

The only way I could see a solution is by generating the typedefs de-facto
after each struct, even if the main typelib loop doesn't dictate it yet and
then assume that for each sequence<struct>, the typedef is available

OR

do the hardcoding of TAO in typegen's corba.rb marshaller, generate both TAO
and Omniorb and use #ifdefs in the generated code to decide at compile time.

From where I was standing, the first option was the easiest (it's modifying C++
code instead of Ruby code :-) , and only a few lines of code needed to be
changed in both typelib and orogen. The generated code then works for both TAO
and omniorb, but broader testing/review might be needed in case I missed
something.

Sylvain, would you accept this solution ?

Peter

typelib + idl generation revisited.

I've been investigating what it would take to have TAO support in typegen. The
main reason, why TAO is not supported, is because the IDL is generated like
this:

&#10;module orogen { &#10;      module Corba { / * define all structs, using &quot;sequence&lt;Foo&gt; foo;&quot; syntax &#10;*/ }; &#10;&#10;  module std { module Corba { /*define all sequence typedefs */ &#10;             typedef sequence&lt;Foo&gt; _vector__Foo_;&#10; };&#10;};&#10;

Since the sequence typedefs are all generated at the end, the structs can not
use the "_vector__Foo_" typedefs and the sequence types used in the structs
are undefined by the CORBA standard, so TAO and Omniorb don't agree.

That's why Sylvain hardcoded Omniorb in the typegen tool. If we don't change
typelib right now, we'll also have to hardcode TAO in the typegen tool, for
the same reasons.

So I thought, let's look for the clean solution, being a nice pair of struct +
sequence typedef and then re-using the typedef'ed type in the next struct,
if necessary:

&#10;module orogen { &#10;&#10; module Corba { / * define one struct */ }; &#10;&#10;   module std { module Corba { /*define a sequence of struct above */ &#10;                typedef sequence&lt;Foo&gt; _vector__Foo_;&#10; };&#10;&#10;    module Corba { / * define another structs, using &quot;_vector_Foo_&quot; syntax */ &#10;}; &#10;&#10;  module std { module Corba { /*define a sequence of struct above */ &#10;                typedef sequence&lt;Bar&gt; _vector__Bar_;&#10; };&#10; /* etc.... */&#10;};&#10;

This needs a change in typelib/lang/corba/export.cc . After some digging, it
appears that typelib *intentionally* generates all structs first (for any
language, not only IDL) and then all typedefs, because (I quote) "Some
exporters need to limit how many times a namespace appears. So, the main
algorithm (here) is meant to limit switching between namespaces."

I don't know which languages that don't handle open namespaces, but it seems
that I can't change it at all, because it's a global setting.

The only way I could see a solution is by generating the typedefs de-facto
after each struct, even if the main typelib loop doesn't dictate it yet and
then assume that for each sequence<struct>, the typedef is available

OR

do the hardcoding of TAO in typegen's corba.rb marshaller, generate both TAO
and Omniorb and use #ifdefs in the generated code to decide at compile time.

From where I was standing, the first option was the easiest (it's modifying C++
code instead of Ruby code :-) , and only a few lines of code needed to be
changed in both typelib and orogen. The generated code then works for both TAO
and omniorb, but broader testing/review might be needed in case I missed
something.

Sylvain, would you accept this solution ?

Peter

typelib + idl generation revisited.

I've been investigating what it would take to have TAO support in typegen. The
main reason, why TAO is not supported, is because the IDL is generated like
this:

&#10;module orogen { &#10;      module Corba { / * define all structs, using &quot;sequence&lt;Foo&gt; foo;&quot; syntax &#10;*/ }; &#10;&#10;  module std { module Corba { /*define all sequence typedefs */ &#10;             typedef sequence&lt;Foo&gt; _vector__Foo_;&#10; };&#10;};&#10;

Since the sequence typedefs are all generated at the end, the structs can not
use the "_vector__Foo_" typedefs and the sequence types used in the structs
are undefined by the CORBA standard, so TAO and Omniorb don't agree.

That's why Sylvain hardcoded Omniorb in the typegen tool. If we don't change
typelib right now, we'll also have to hardcode TAO in the typegen tool, for
the same reasons.

So I thought, let's look for the clean solution, being a nice pair of struct +
sequence typedef and then re-using the typedef'ed type in the next struct,
if necessary:

&#10;module orogen { &#10;&#10; module Corba { / * define one struct */ }; &#10;&#10;   module std { module Corba { /*define a sequence of struct above */ &#10;                typedef sequence&lt;Foo&gt; _vector__Foo_;&#10; };&#10;&#10;    module Corba { / * define another structs, using &quot;_vector_Foo_&quot; syntax */ &#10;}; &#10;&#10;  module std { module Corba { /*define a sequence of struct above */ &#10;                typedef sequence&lt;Bar&gt; _vector__Bar_;&#10; };&#10; /* etc.... */&#10;};&#10;

This needs a change in typelib/lang/corba/export.cc . After some digging, it
appears that typelib *intentionally* generates all structs first (for any
language, not only IDL) and then all typedefs, because (I quote) "Some
exporters need to limit how many times a namespace appears. So, the main
algorithm (here) is meant to limit switching between namespaces."

I don't know which languages that don't handle open namespaces, but it seems
that I can't change it at all, because it's a global setting.

The only way I could see a solution is by generating the typedefs de-facto
after each struct, even if the main typelib loop doesn't dictate it yet and
then assume that for each sequence<struct>, the typedef is available

OR

do the hardcoding of TAO in typegen's corba.rb marshaller, generate both TAO
and Omniorb and use #ifdefs in the generated code to decide at compile time.

From where I was standing, the first option was the easiest (it's modifying C++
code instead of Ruby code :-) , and only a few lines of code needed to be
changed in both typelib and orogen. The generated code then works for both TAO
and omniorb, but broader testing/review might be needed in case I missed
something.

Sylvain, would you accept this solution ?

Peter

typelib + idl generation revisited.

I've been investigating what it would take to have TAO support in typegen. The
main reason, why TAO is not supported, is because the IDL is generated like
this:

&#10;module orogen { &#10;      module Corba { / * define all structs, using &quot;sequence&lt;Foo&gt; foo;&quot; syntax &#10;*/ }; &#10;&#10;  module std { module Corba { /*define all sequence typedefs */ &#10;             typedef sequence&lt;Foo&gt; _vector__Foo_;&#10; };&#10;};&#10;

Since the sequence typedefs are all generated at the end, the structs can not
use the "_vector__Foo_" typedefs and the sequence types used in the structs
are undefined by the CORBA standard, so TAO and Omniorb don't agree.

That's why Sylvain hardcoded Omniorb in the typegen tool. If we don't change
typelib right now, we'll also have to hardcode TAO in the typegen tool, for
the same reasons.

So I thought, let's look for the clean solution, being a nice pair of struct +
sequence typedef and then re-using the typedef'ed type in the next struct,
if necessary:

&#10;module orogen { &#10;&#10; module Corba { / * define one struct */ }; &#10;&#10;   module std { module Corba { /*define a sequence of struct above */ &#10;                typedef sequence&lt;Foo&gt; _vector__Foo_;&#10; };&#10;&#10;    module Corba { / * define another structs, using &quot;_vector_Foo_&quot; syntax */ &#10;}; &#10;&#10;  module std { module Corba { /*define a sequence of struct above */ &#10;                typedef sequence&lt;Bar&gt; _vector__Bar_;&#10; };&#10; /* etc.... */&#10;};&#10;

This needs a change in typelib/lang/corba/export.cc . After some digging, it
appears that typelib *intentionally* generates all structs first (for any
language, not only IDL) and then all typedefs, because (I quote) "Some
exporters need to limit how many times a namespace appears. So, the main
algorithm (here) is meant to limit switching between namespaces."

I don't know which languages that don't handle open namespaces, but it seems
that I can't change it at all, because it's a global setting.

The only way I could see a solution is by generating the typedefs de-facto
after each struct, even if the main typelib loop doesn't dictate it yet and
then assume that for each sequence<struct>, the typedef is available

OR

do the hardcoding of TAO in typegen's corba.rb marshaller, generate both TAO
and Omniorb and use #ifdefs in the generated code to decide at compile time.

From where I was standing, the first option was the easiest (it's modifying C++
code instead of Ruby code :-) , and only a few lines of code needed to be
changed in both typelib and orogen. The generated code then works for both TAO
and omniorb, but broader testing/review might be needed in case I missed
something.

Sylvain, would you accept this solution ?

Peter