I'm testing typegen with the TaskBrowser, but I'm stuck because of the given
type names. These have the form /Namespace/Type or /Type. The '/' character is
not a valid part of an identifier. Also /std/vector<Bar> would be problematic
due to the <...> in the name.
Is there a way we can resolve this ? Are these names used by the ruby/typelib
tooling ?
The easiest way would be another option to typegen imho, but it could also be
an opportunity to improve the scripting a bit in order to understand scopes,
such that something that doesn't clash in C++ won't clash in typekit space
either.
Peter
typegen: /type names
On Saturday 28 August 2010 23:33:57 Peter Soetens wrote:
> I'm testing typegen with the TaskBrowser, but I'm stuck because of the
> given type names. These have the form /Namespace/Type or /Type. The '/'
> character is not a valid part of an identifier. Also /std/vector<Bar>
> would be problematic due to the <...> in the name.
>
> Is there a way we can resolve this ? Are these names used by the
> ruby/typelib tooling ?
>
> The easiest way would be another option to typegen imho, but it could also
> be an opportunity to improve the scripting a bit in order to understand
> scopes, such that something that doesn't clash in C++ won't clash in
> typekit space either.
I have updated the RTT scripting such that a typename may also have these
characters: /<>
It seems to work... but maybe dropping the leading '/' from typenames might be
a bit easier on the eyes ?
Peter
typegen: /type names
On 08/29/2010 01:31 AM, Peter Soetens wrote:
> On Saturday 28 August 2010 23:33:57 Peter Soetens wrote:
>> I'm testing typegen with the TaskBrowser, but I'm stuck because of the
>> given type names. These have the form /Namespace/Type or /Type. The '/'
>> character is not a valid part of an identifier. Also /std/vector<Bar>
>> would be problematic due to the<...> in the name.
>>
>> Is there a way we can resolve this ? Are these names used by the
>> ruby/typelib tooling ?
>>
>> The easiest way would be another option to typegen imho, but it could also
>> be an opportunity to improve the scripting a bit in order to understand
>> scopes, such that something that doesn't clash in C++ won't clash in
>> typekit space either.
>
> I have updated the RTT scripting such that a typename may also have these
> characters: /<>
>
> It seems to work... but maybe dropping the leading '/' from typenames might be
> a bit easier on the eyes ?
Typenames in typelib should stay the same so that they are totally
unambiguous. So it is not an option to remove the leading / from the
type names. Removing it could be done at display time, though.
typegen: /type names
On Monday 30 August 2010 07:27:41 Sylvain Joyeux wrote:
> On 08/29/2010 01:31 AM, Peter Soetens wrote:
> > On Saturday 28 August 2010 23:33:57 Peter Soetens wrote:
> >> I'm testing typegen with the TaskBrowser, but I'm stuck because of the
> >> given type names. These have the form /Namespace/Type or /Type. The
> >> '/' character is not a valid part of an identifier. Also
> >> /std/vector<Bar> would be problematic due to the<...> in the name.
> >>
> >> Is there a way we can resolve this ? Are these names used by the
> >> ruby/typelib tooling ?
> >>
> >> The easiest way would be another option to typegen imho, but it could
> >> also be an opportunity to improve the scripting a bit in order to
> >> understand scopes, such that something that doesn't clash in C++ won't
> >> clash in typekit space either.
> >
> > I have updated the RTT scripting such that a typename may also have these
> > characters: /<>
> >
> > It seems to work... but maybe dropping the leading '/' from typenames
> > might be a bit easier on the eyes ?
>
> Typenames in typelib should stay the same so that they are totally
> unambiguous. So it is not an option to remove the leading / from the
> type names. Removing it could be done at display time, though.
But can't it be removed from the type name in the RTT::TypeInfo registration ?
C++ typename: std::vector<double>
typelib typename: /std/vector<double>
Orocos type: std/vector<double>
foo type: std.vector<double>
What does it mean to have a typename that does not start with a '/' ? How is
the typename represented in ruby ?
Peter
typegen: /type names
On Monday 30 August 2010 14:03:39 Peter Soetens wrote:
> On Monday 30 August 2010 07:27:41 Sylvain Joyeux wrote:
> > On 08/29/2010 01:31 AM, Peter Soetens wrote:
> > > On Saturday 28 August 2010 23:33:57 Peter Soetens wrote:
> > >> I'm testing typegen with the TaskBrowser, but I'm stuck because of the
> > >> given type names. These have the form /Namespace/Type or /Type. The
> > >> '/' character is not a valid part of an identifier. Also
> > >> /std/vector<Bar> would be problematic due to the<...> in the name.
> > >>
> > >> Is there a way we can resolve this ? Are these names used by the
> > >> ruby/typelib tooling ?
> > >>
> > >> The easiest way would be another option to typegen imho, but it could
> > >> also be an opportunity to improve the scripting a bit in order to
> > >> understand scopes, such that something that doesn't clash in C++ won't
> > >> clash in typekit space either.
> > >
> > > I have updated the RTT scripting such that a typename may also have
> > > these characters: /<>
> > >
> > > It seems to work... but maybe dropping the leading '/' from typenames
> > > might be a bit easier on the eyes ?
> >
> > Typenames in typelib should stay the same so that they are totally
> > unambiguous. So it is not an option to remove the leading / from the
> > type names. Removing it could be done at display time, though.
>
> But can't it be removed from the type name in the RTT::TypeInfo
> registration ?
>
> C++ typename: std::vector<double>
> typelib typename: /std/vector<double>
> Orocos type: std/vector<double>
> foo type: std.vector<double>
>
> What does it mean to have a typename that does not start with a '/' ? How
> is the typename represented in ruby ?
On second thought, I'd prefer the Orocos type to be std.vector<double>, since
dots are generally used to scope in the rtt scripting language.
Peter
typegen: /type names
On 08/30/2010 02:09 PM, Peter Soetens wrote:
> On Monday 30 August 2010 14:03:39 Peter Soetens wrote:
>> On Monday 30 August 2010 07:27:41 Sylvain Joyeux wrote:
>>> On 08/29/2010 01:31 AM, Peter Soetens wrote:
>>>> On Saturday 28 August 2010 23:33:57 Peter Soetens wrote:
>>>>> I'm testing typegen with the TaskBrowser, but I'm stuck because of the
>>>>> given type names. These have the form /Namespace/Type or /Type. The
>>>>> '/' character is not a valid part of an identifier. Also
>>>>> /std/vector<Bar> would be problematic due to the<...> in the name.
>>>>>
>>>>> Is there a way we can resolve this ? Are these names used by the
>>>>> ruby/typelib tooling ?
>>>>>
>>>>> The easiest way would be another option to typegen imho, but it could
>>>>> also be an opportunity to improve the scripting a bit in order to
>>>>> understand scopes, such that something that doesn't clash in C++ won't
>>>>> clash in typekit space either.
>>>>
>>>> I have updated the RTT scripting such that a typename may also have
>>>> these characters: /<>
>>>>
>>>> It seems to work... but maybe dropping the leading '/' from typenames
>>>> might be a bit easier on the eyes ?
>>>
>>> Typenames in typelib should stay the same so that they are totally
>>> unambiguous. So it is not an option to remove the leading / from the
>>> type names. Removing it could be done at display time, though.
>>
>> But can't it be removed from the type name in the RTT::TypeInfo
>> registration ?
>>
>> C++ typename: std::vector<double>
>> typelib typename: /std/vector<double>
>> Orocos type: std/vector<double>
>> foo type: std.vector<double>
>>
>> What does it mean to have a typename that does not start with a '/' ? How
>> is the typename represented in ruby ?
>
> On second thought, I'd prefer the Orocos type to be std.vector<double>, since
> dots are generally used to scope in the rtt scripting language.
This is breaks the 1:1 mapping between Orocos type names and Typelib
registries, which is a really bad idea.
I would suggest that the scripting parser do the work. If everybody that
wants to use typelib to manipulate orocos-provided values has to do the
convertion, this is going to be really painful.
typegen: /type names
On Thu, May 26, 2011 at 2:34 PM, <ruben [dot] smits [..] ...> wrote:
>
>> On 08/30/2010 02:09 PM, Peter Soetens wrote:
>> > On Monday 30 August 2010 14:03:39 Peter Soetens wrote:
>> >> On Monday 30 August 2010 07:27:41 Sylvain Joyeux wrote:
>> >>> On 08/29/2010 01:31 AM, Peter Soetens wrote:
>> >>>> On Saturday 28 August 2010 23:33:57 Peter Soetens wrote:
>> >>>>> I'm testing typegen with the TaskBrowser, but I'm stuck because of
>> >>>>> the given type names. These have the form /Namespace/Type or /Type.
>> >>>>> The '/' character is not a valid part of an identifier. Also
>> >>>>> /std/vector<Bar> would be problematic due to the<...> in the
>> >>>>> name.
>> >>>>>
>> >>>>> Is there a way we can resolve this ? Are these names used by the
>> >>>>> ruby/typelib tooling ?
>> >>>>>
>> >>>>> The easiest way would be another option to typegen imho, but it could
>> >>>>> also be an opportunity to improve the scripting a bit in order to
>> >>>>> understand scopes, such that something that doesn't clash in C++
>> >>>>> won't clash in typekit space either.
>> >>>>
>> >>>> I have updated the RTT scripting such that a typename may also have
>> >>>> these characters: /<>
>> >>>>
>> >>>> It seems to work... but maybe dropping the leading '/' from typenames
>> >>>> might be a bit easier on the eyes ?
>> >>>
>> >>> Typenames in typelib should stay the same so that they are totally
>> >>> unambiguous. So it is not an option to remove the leading / from the
>> >>> type names. Removing it could be done at display time, though.
>> >>
>> >> But can't it be removed from the type name in the RTT::TypeInfo
>> >> registration ?
>> >>
>> >> C++ typename: std::vector<double>
>> >> typelib typename: /std/vector<double>
>> >> Orocos type: std/vector<double>
>> >> foo type: std.vector<double>
>> >>
>> >> What does it mean to have a typename that does not start with a '/' ?
>> >> How is the typename represented in ruby ?
>>
>> Not related to ruby but to typelib. Typelib uses '/' as a scoping
>> mechanism and differs between absolute typenames and relative typenames
>> (since you can 'open' namespaces the same way than in C++)
>
> I don't understand yet why the typename in the RTT needs to be the same as the
> typename in typelib, while the typename in ruby does not need to be the same.
> Does it mean your other tools use the typelib name directly, ie, users at dfki
> write /std/vector<double> at places ?
>
>>
>> > On second thought, I'd prefer the Orocos type to be std.vector<double>,
>> > since dots are generally used to scope in the rtt scripting language.
>>
>> Yes, and typelib generally used '/' to scope the types. This is a
>>
>> That would be ambiguous with the dot of the method calls, no ?
>
> No. It's similar to what other languages have, scoping in a package (ie
> namespace) with dots and scoping in an object with dots. The parser can
> distinguish this.
>
> I'll try to work around the current constraint that you impose, But I'd still
> like to know why/when the typelib internal name is exposed. It's new syntax,
> it may lead to confusion. when both forms are available.
>
> Peter
>
>
> Me and Markus just discovered that it is ambiguous. The types provided by the kdl_typekit all live in the KDL namespace. This results in the types being available as KDL.Vector etc.
>
> Now Markus added some operations in a "KDL" service as a subservice of the global service:
>
> gs->provides("KDL")->addOperation(...)
>
> This results in the inability to construct any of the KDL types in the taskbrowser (and probably also in the scripting;
>
> To sum up, without the extra service I was able to do:
>
> var KDL.Vector v = KDL.Vector(1,2,3)
> = [ 1 ,2 ,3 ]
>
> including the KDL service I now get
>
> var KDL.Vector v = KDL.Vector(1,2,3)
> No method "Vector" registered for the object or task "Deployer".
>
>
> I don't know whether it is a regression, but probably no-one ever ran into this before.
This was never tested. It's the ExpressionParser which is confused.
For example, it also can't handle KDL.SubTypes.Foo for example (two
dots).
It's certainly fixable... I'll see when it is...
Peter
--
Orocos-Dev mailing list
Orocos-Dev [..] ...
http://lists.mech.kuleuven.be/mailman/listinfo/orocos-dev
typegen: /type names
On Thursday 26 May 2011 16:31:09 Peter Soetens wrote:
> On Thu, May 26, 2011 at 2:34 PM, <ruben [dot] smits [..] ...> wrote:
> >
> >> On 08/30/2010 02:09 PM, Peter Soetens wrote:
> >> > On Monday 30 August 2010 14:03:39 Peter Soetens wrote:
> >> >> On Monday 30 August 2010 07:27:41 Sylvain Joyeux wrote:
> >> >>> On 08/29/2010 01:31 AM, Peter Soetens wrote:
> >> >>>> On Saturday 28 August 2010 23:33:57 Peter Soetens wrote:
> >> >>>>> I'm testing typegen with the TaskBrowser, but I'm stuck because of
> >> >>>>> the given type names. These have the form /Namespace/Type or
> >> >>>>> /Type. The '/' character is not a valid part of an identifier.
> >> >>>>> Also /std/vector<Bar> would be problematic due to the<...> in
> >> >>>>> the name.
> >> >>>>>
> >> >>>>> Is there a way we can resolve this ? Are these names used by the
> >> >>>>> ruby/typelib tooling ?
> >> >>>>>
> >> >>>>> The easiest way would be another option to typegen imho, but it
> >> >>>>> could also be an opportunity to improve the scripting a bit in
> >> >>>>> order to understand scopes, such that something that doesn't
> >> >>>>> clash in C++ won't clash in typekit space either.
> >> >>>>
> >> >>>> I have updated the RTT scripting such that a typename may also have
> >> >>>> these characters: /<>
> >> >>>>
> >> >>>> It seems to work... but maybe dropping the leading '/' from
> >> >>>> typenames might be a bit easier on the eyes ?
> >> >>>
> >> >>> Typenames in typelib should stay the same so that they are totally
> >> >>> unambiguous. So it is not an option to remove the leading / from the
> >> >>> type names. Removing it could be done at display time, though.
> >> >>
> >> >> But can't it be removed from the type name in the RTT::TypeInfo
> >> >> registration ?
> >> >>
> >> >> C++ typename: std::vector<double>
> >> >> typelib typename: /std/vector<double>
> >> >> Orocos type: std/vector<double>
> >> >> foo type: std.vector<double>
> >> >>
> >> >> What does it mean to have a typename that does not start with a '/' ?
> >> >> How is the typename represented in ruby ?
> >>
> >> Not related to ruby but to typelib. Typelib uses '/' as a scoping
> >> mechanism and differs between absolute typenames and relative typenames
> >> (since you can 'open' namespaces the same way than in C++)
> >
> > I don't understand yet why the typename in the RTT needs to be the same
> > as the typename in typelib, while the typename in ruby does not need to
> > be the same. Does it mean your other tools use the typelib name
> > directly, ie, users at dfki write /std/vector<double> at places ?
> >
> >> > On second thought, I'd prefer the Orocos type to be
> >> > std.vector<double>, since dots are generally used to scope in the rtt
> >> > scripting language.
> >>
> >> Yes, and typelib generally used '/' to scope the types. This is a
> >>
> >> That would be ambiguous with the dot of the method calls, no ?
> >
> > No. It's similar to what other languages have, scoping in a package (ie
> > namespace) with dots and scoping in an object with dots. The parser can
> > distinguish this.
> >
> > I'll try to work around the current constraint that you impose, But I'd
> > still like to know why/when the typelib internal name is exposed. It's
> > new syntax, it may lead to confusion. when both forms are available.
> >
> > Peter
> >
> >
> > Me and Markus just discovered that it is ambiguous. The types provided by
> > the kdl_typekit all live in the KDL namespace. This results in the types
> > being available as KDL.Vector etc.
> >
> > Now Markus added some operations in a "KDL" service as a subservice of
> > the global service:
> >
> > gs->provides("KDL")->addOperation(...)
> >
> > This results in the inability to construct any of the KDL types in the
> > taskbrowser (and probably also in the scripting;
> >
> > To sum up, without the extra service I was able to do:
> >
> > var KDL.Vector v = KDL.Vector(1,2,3)
> > = [ 1 ,2 ,3 ]
> >
> > including the KDL service I now get
> >
> > var KDL.Vector v = KDL.Vector(1,2,3)
> > No method "Vector" registered for the object or task "Deployer".
> >
> >
> > I don't know whether it is a regression, but probably no-one ever ran
> > into this before.
>
> This was never tested. It's the ExpressionParser which is confused.
> For example, it also can't handle KDL.SubTypes.Foo for example (two
> dots).
>
> It's certainly fixable... I'll see when it is...
In 2.4.0. It needs more testing, since I only ran the unit tests and the fix
didn't break anything... yours to find out if it fixed anything :-)
Peter
typegen: /type names
On 08/30/2010 02:09 PM, Peter Soetens wrote:
> On Monday 30 August 2010 14:03:39 Peter Soetens wrote:
>> On Monday 30 August 2010 07:27:41 Sylvain Joyeux wrote:
>>> On 08/29/2010 01:31 AM, Peter Soetens wrote:
>>>> On Saturday 28 August 2010 23:33:57 Peter Soetens wrote:
>>>>> I'm testing typegen with the TaskBrowser, but I'm stuck because of the
>>>>> given type names. These have the form /Namespace/Type or /Type. The
>>>>> '/' character is not a valid part of an identifier. Also
>>>>> /std/vector<Bar> would be problematic due to the<...> in the name.
>>>>>
>>>>> Is there a way we can resolve this ? Are these names used by the
>>>>> ruby/typelib tooling ?
>>>>>
>>>>> The easiest way would be another option to typegen imho, but it could
>>>>> also be an opportunity to improve the scripting a bit in order to
>>>>> understand scopes, such that something that doesn't clash in C++ won't
>>>>> clash in typekit space either.
>>>>
>>>> I have updated the RTT scripting such that a typename may also have
>>>> these characters: /<>
>>>>
>>>> It seems to work... but maybe dropping the leading '/' from typenames
>>>> might be a bit easier on the eyes ?
>>>
>>> Typenames in typelib should stay the same so that they are totally
>>> unambiguous. So it is not an option to remove the leading / from the
>>> type names. Removing it could be done at display time, though.
>>
>> But can't it be removed from the type name in the RTT::TypeInfo
>> registration ?
>>
>> C++ typename: std::vector<double>
>> typelib typename: /std/vector<double>
>> Orocos type: std/vector<double>
>> foo type: std.vector<double>
>>
>> What does it mean to have a typename that does not start with a '/' ? How
>> is the typename represented in ruby ?
Not related to ruby but to typelib. Typelib uses '/' as a scoping
mechanism and differs between absolute typenames and relative typenames
(since you can 'open' namespaces the same way than in C++)
> On second thought, I'd prefer the Orocos type to be std.vector<double>, since
> dots are generally used to scope in the rtt scripting language.
Yes, and typelib generally used '/' to scope the types. This is a
That would be ambiguous with the dot of the method calls, no ?
typegen: /type names
On Tuesday 31 August 2010 02:20:54 Sylvain Joyeux wrote:
> On 08/30/2010 02:09 PM, Peter Soetens wrote:
> > On Monday 30 August 2010 14:03:39 Peter Soetens wrote:
> >> On Monday 30 August 2010 07:27:41 Sylvain Joyeux wrote:
> >>> On 08/29/2010 01:31 AM, Peter Soetens wrote:
> >>>> On Saturday 28 August 2010 23:33:57 Peter Soetens wrote:
> >>>>> I'm testing typegen with the TaskBrowser, but I'm stuck because of
> >>>>> the given type names. These have the form /Namespace/Type or /Type.
> >>>>> The '/' character is not a valid part of an identifier. Also
> >>>>> /std/vector<Bar> would be problematic due to the<...> in the
> >>>>> name.
> >>>>>
> >>>>> Is there a way we can resolve this ? Are these names used by the
> >>>>> ruby/typelib tooling ?
> >>>>>
> >>>>> The easiest way would be another option to typegen imho, but it could
> >>>>> also be an opportunity to improve the scripting a bit in order to
> >>>>> understand scopes, such that something that doesn't clash in C++
> >>>>> won't clash in typekit space either.
> >>>>
> >>>> I have updated the RTT scripting such that a typename may also have
> >>>> these characters: /<>
> >>>>
> >>>> It seems to work... but maybe dropping the leading '/' from typenames
> >>>> might be a bit easier on the eyes ?
> >>>
> >>> Typenames in typelib should stay the same so that they are totally
> >>> unambiguous. So it is not an option to remove the leading / from the
> >>> type names. Removing it could be done at display time, though.
> >>
> >> But can't it be removed from the type name in the RTT::TypeInfo
> >> registration ?
> >>
> >> C++ typename: std::vector<double>
> >> typelib typename: /std/vector<double>
> >> Orocos type: std/vector<double>
> >> foo type: std.vector<double>
> >>
> >> What does it mean to have a typename that does not start with a '/' ?
> >> How is the typename represented in ruby ?
>
> Not related to ruby but to typelib. Typelib uses '/' as a scoping
> mechanism and differs between absolute typenames and relative typenames
> (since you can 'open' namespaces the same way than in C++)
I don't understand yet why the typename in the RTT needs to be the same as the
typename in typelib, while the typename in ruby does not need to be the same.
Does it mean your other tools use the typelib name directly, ie, users at dfki
write /std/vector<double> at places ?
>
> > On second thought, I'd prefer the Orocos type to be std.vector<double>,
> > since dots are generally used to scope in the rtt scripting language.
>
> Yes, and typelib generally used '/' to scope the types. This is a
>
> That would be ambiguous with the dot of the method calls, no ?
No. It's similar to what other languages have, scoping in a package (ie
namespace) with dots and scoping in an object with dots. The parser can
distinguish this.
I'll try to work around the current constraint that you impose, But I'd still
like to know why/when the typelib internal name is exposed. It's new syntax,
it may lead to confusion. when both forms are available.
Peter
Re: typegen: /type names
I don't understand yet why the typename in the RTT needs to be the same as the typename in typelib, while the typename in ruby does not need to be the same. Does it mean your other tools use the typelib name directly, ie, users at dfki write /std/vector<double> at places ?
> > > On second thought, I'd prefer the Orocos type to be std.vector<double>, > > since dots are generally used to scope in the rtt scripting language. > > Yes, and typelib generally used '/' to scope the types. This is a > > That would be ambiguous with the dot of the method calls, no ?
No. It's similar to what other languages have, scoping in a package (ie namespace) with dots and scoping in an object with dots. The parser can distinguish this.
I'll try to work around the current constraint that you impose, But I'd still like to know why/when the typelib internal name is exposed. It's new syntax, it may lead to confusion. when both forms are available.
Peter
Me and Markus just discovered that it is ambiguous. The types provided by the kdl_typekit all live in the KDL namespace. This results in the types being available as KDL.Vector etc.
Now Markus added some operations in a "KDL" service as a subservice of the global service:
gs->provides("KDL")->addOperation(...)
This results in the inability to construct any of the KDL types in the taskbrowser (and probably also in the scripting;
To sum up, without the extra service I was able to do:
var KDL.Vector v = KDL.Vector(1,2,3) = [ 1 ,2 ,3 ]
including the KDL service I now get
var KDL.Vector v = KDL.Vector(1,2,3) No method "Vector" registered for the object or task "Deployer".
I don't know whether it is a regression, but probably no-one ever ran into this before.
-- Ruben
typegen: /type names
On 05/26/2011 02:34 PM, ruben [dot] smits [..] ... wrote:
>
>> On 08/30/2010 02:09 PM, Peter Soetens wrote:
>>> On Monday 30 August 2010 14:03:39 Peter Soetens wrote:
>>>> On Monday 30 August 2010 07:27:41 Sylvain Joyeux wrote:
>>>>> On 08/29/2010 01:31 AM, Peter Soetens wrote:
>>>>>> On Saturday 28 August 2010 23:33:57 Peter Soetens wrote:
>>>>>>> I'm testing typegen with the TaskBrowser, but I'm stuck because of
>>>>>>> the given type names. These have the form /Namespace/Type or /Type.
>>>>>>> The '/' character is not a valid part of an identifier. Also
>>>>>>> /std/vector<Bar> would be problematic due to the<...> in the
>>>>>>> name.
>>>>>>>
>>>>>>> Is there a way we can resolve this ? Are these names used by the
>>>>>>> ruby/typelib tooling ?
>>>>>>>
>>>>>>> The easiest way would be another option to typegen imho, but it could
>>>>>>> also be an opportunity to improve the scripting a bit in order to
>>>>>>> understand scopes, such that something that doesn't clash in C++
>>>>>>> won't clash in typekit space either.
>>>>>> I have updated the RTT scripting such that a typename may also have
>>>>>> these characters: /<>
>>>>>>
>>>>>> It seems to work... but maybe dropping the leading '/' from typenames
>>>>>> might be a bit easier on the eyes ?
>>>>> Typenames in typelib should stay the same so that they are totally
>>>>> unambiguous. So it is not an option to remove the leading / from the
>>>>> type names. Removing it could be done at display time, though.
>>>> But can't it be removed from the type name in the RTT::TypeInfo
>>>> registration ?
>>>>
>>>> C++ typename: std::vector<double>
>>>> typelib typename: /std/vector<double>
>>>> Orocos type: std/vector<double>
>>>> foo type: std.vector<double>
>>>>
>>>> What does it mean to have a typename that does not start with a '/' ?
>>>> How is the typename represented in ruby ?
>> Not related to ruby but to typelib. Typelib uses '/' as a scoping
>> mechanism and differs between absolute typenames and relative typenames
>> (since you can 'open' namespaces the same way than in C++)
> I don't understand yet why the typename in the RTT needs to be the same as the
> typename in typelib, while the typename in ruby does not need to be the same.
> Does it mean your other tools use the typelib name directly, ie, users at dfki
> write /std/vector<double> at places ?
It means that the tooling internals currently assumes that typename in
typelib registry == TypeInfo::getName(). In Ruby, I translate the type
names into Ruby-like naming scheme, in C++ into C++ syntax and so on.
The bottom line is: you need to have an internal type name which has to
be "something" and then gets translated to whatever target language is
manipulating the type in the end. You will always have to translate, as
different languages have different requirements for types.
And yes, sometimes, people do
registry.get("/base/Vector3d")
This became rarer these days as one can do
Types::Base::Vector3d
But for cases where you want to translate a type that evolved (i.e. have
different repositories that contain different versions of the same type)
it does help.
typegen: /type names
On 08/31/2010 10:11 AM, Peter Soetens wrote:
> On Tuesday 31 August 2010 02:20:54 Sylvain Joyeux wrote:
>> On 08/30/2010 02:09 PM, Peter Soetens wrote:
>>> On Monday 30 August 2010 14:03:39 Peter Soetens wrote:
>>>> On Monday 30 August 2010 07:27:41 Sylvain Joyeux wrote:
>>>>> On 08/29/2010 01:31 AM, Peter Soetens wrote:
>>>>>> On Saturday 28 August 2010 23:33:57 Peter Soetens wrote:
>>>>>>> I'm testing typegen with the TaskBrowser, but I'm stuck because of
>>>>>>> the given type names. These have the form /Namespace/Type or /Type.
>>>>>>> The '/' character is not a valid part of an identifier. Also
>>>>>>> /std/vector<Bar> would be problematic due to the<...> in the
>>>>>>> name.
>>>>>>>
>>>>>>> Is there a way we can resolve this ? Are these names used by the
>>>>>>> ruby/typelib tooling ?
>>>>>>>
>>>>>>> The easiest way would be another option to typegen imho, but it could
>>>>>>> also be an opportunity to improve the scripting a bit in order to
>>>>>>> understand scopes, such that something that doesn't clash in C++
>>>>>>> won't clash in typekit space either.
>>>>>>
>>>>>> I have updated the RTT scripting such that a typename may also have
>>>>>> these characters: /<>
>>>>>>
>>>>>> It seems to work... but maybe dropping the leading '/' from typenames
>>>>>> might be a bit easier on the eyes ?
>>>>>
>>>>> Typenames in typelib should stay the same so that they are totally
>>>>> unambiguous. So it is not an option to remove the leading / from the
>>>>> type names. Removing it could be done at display time, though.
>>>>
>>>> But can't it be removed from the type name in the RTT::TypeInfo
>>>> registration ?
>>>>
>>>> C++ typename: std::vector<double>
>>>> typelib typename: /std/vector<double>
>>>> Orocos type: std/vector<double>
>>>> foo type: std.vector<double>
>>>>
>>>> What does it mean to have a typename that does not start with a '/' ?
>>>> How is the typename represented in ruby ?
>>
>> Not related to ruby but to typelib. Typelib uses '/' as a scoping
>> mechanism and differs between absolute typenames and relative typenames
>> (since you can 'open' namespaces the same way than in C++)
>
> I don't understand yet why the typename in the RTT needs to be the same as the
> typename in typelib, while the typename in ruby does not need to be the same.
> Does it mean your other tools use the typelib name directly, ie, users at dfki
> write /std/vector<double> at places ?
>
>>
>>> On second thought, I'd prefer the Orocos type to be std.vector<double>,
>>> since dots are generally used to scope in the rtt scripting language.
>>
>> Yes, and typelib generally used '/' to scope the types. This is a
>>
>> That would be ambiguous with the dot of the method calls, no ?
>
> No. It's similar to what other languages have, scoping in a package (ie
> namespace) with dots and scoping in an object with dots. The parser can
> distinguish this.
>
> I'll try to work around the current constraint that you impose, But I'd still
> like to know why/when the typelib internal name is exposed. It's new syntax,
> it may lead to confusion. when both forms are available.
Basically, the problem is that the Ruby tools (ruby scripting, data
logging, log file interpretation) expect the RTT type name to be
identical to the Typelib name, so that they can search the typelib
registry without having to do type name transformation.
The only two that are exposed to the user are the log files and the
scripting. In my experience, nobody had any problem having different
notations. People *already* have to match multiple scoping schemes when
they change languages.
Obviously, there are two ways to fix the issue: either the ruby tools do
the transformation, or have the scripting do it for itself.
Another way would be for me to drop all the boost/serialize stuff in
typegen-generated code and reimplement the base TypeInfo using typelib
when typegen is used. I actually plan to do that (at least optionally)
when I come back from vacations. If I do that, I can introduce a
getTypelibName in the TypeInfo subclasses I generate and get the name
from there.
Sylvain