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

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

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

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