[Bug 789] New: OCL RTString constructor not work in scripting

Submitted by snrkiwi on Mon, 2010-10-18 17:00

RTT-dev

https://www.fmtc.be/bugzilla/orocos/show_bug.cgi?id=789

Summary: OCL RTString constructor not work in scripting
Product: OCL
Version: 1.10.2
Platform: All
OS/Version: All
Status: NEW
Severity: normal
Priority: P3
Component: Other
AssignedTo: orocos-dev [..] ...
ReportedBy: kiwi [dot] net [..] ...
CC: orocos-dev [..] ...
Estimated Hours: 0.0

Created an attachment (id=614)
--> (https://www.fmtc.be/bugzilla/orocos/attachment.cgi?id=614)
plugins/rtalloc: Add test case demonstrating failing rtstring construction

[parts of ML discussion follow]
[applies to RTT v2 most likely]

Attached patches add a test to OCL v1 to create rtstring instances in
scripting. The test fails to use rtstring ctor, and instead attempts to create
a string (ie std::string) first and then create rstring from that. This is bad.

Test implementation based on rtt/tests/state_test.cpp

Peter, this is based on the plugins/rtalloc that you pulled from my github into
rtt-2.0-mainline sometime ago. But as that isn't in v1 nor v2 masters, I can
only give you a test that works on my github repo. I can't base it on anything
from your git* AFAICT.

[peter comment]
That's probably because std::string is hardcoded in the parsers, and it
assumes every char* is going into a datasource of std::string. The only
solution seems to be to pass it as a char* into a registered constructor for
rt_string if a user writes it like this : rt_string("foo"), just like in C++.

[snrkiwi comment]
My test case has an example exactly like that, I believe. It fails.

[Bug 789] OCL RTString constructor not work in scripting

Submitted by snrkiwi on Sun, 2010-10-24 09:56.

https://www.fmtc.be/bugzilla/orocos/show_bug.cgi?id=789

--- Comment #1 from S Roderick <kiwi [dot] net [..] ...> 2010-10-18 18:29:19 ---
Created an attachment (id=615)
--> (https://www.fmtc.be/bugzilla/orocos/attachment.cgi?id=615)
plugins/rtalloc: Preliminary implementation of rtstring constructors

[Bug 789] OCL RTString constructor not work in scripting

Submitted by snrkiwi on Fri, 2011-05-13 13:16.

http://bugs.orocos.org/show_bug.cgi?id=789

--- Comment #2 from S Roderick <kiwi [dot] net [..] ...> 2011-05-13 15:15:46 CEST ---
This has become an incredibly constraining issue for us, so I'm bumping it up.

We need the ability to use real-time strings in state machines and scripts. As
Peter noted, the parser defaults to all char* values going into std::strings.
So how do we fix this?

We need the fix for v1, but it looks like the v1 and v2 parsing systems are
pretty much the same. So any fix we make for v2 should be back-portable to v1
(we can do that ourselves).

I've attached test cases demonstrating the problem for v2/toolchain. How do we
proceed to fix this issue? It looks to me that we need to monkey with
ValueParser to be able to deal with "char*" quantities, instead of directly
turning them into "string" quantities. I have some time to work on this, but I
could use some direction before diving into all the fun boost::spirit-fu that
is the RTT parsing system ... :-)

[Bug 789] OCL RTString constructor not work in scripting

Submitted by snrkiwi on Fri, 2011-05-13 13:20.

http://bugs.orocos.org/show_bug.cgi?id=789

S Roderick <kiwi [dot] net [..] ...> changed:

--- Comment #3 from S Roderick <kiwi [dot] net [..] ...> 2011-05-13 15:17:56 CEST ---
Created attachment 688
--> http://bugs.orocos.org/attachment.cgi?id=688
Test case

[Bug 789] OCL RTString constructor not work in scripting

Submitted by snrkiwi on Fri, 2011-05-13 13:20.

http://bugs.orocos.org/show_bug.cgi?id=789

--- Comment #4 from S Roderick <kiwi [dot] net [..] ...> 2011-05-13 15:18:39 CEST ---
Created attachment 689
--> http://bugs.orocos.org/attachment.cgi?id=689
Add rt_string constructor for completeness

Test cases still failing even with this patch

[Bug 789] OCL RTString constructor not work in scripting

Submitted by peter on Fri, 2011-05-20 10:40.

http://bugs.orocos.org/show_bug.cgi?id=789

Peter Soetens <peter [..] ...> changed:

--- Comment #5 from Peter Soetens <peter [..] ...> 2011-05-20 12:38:46 CEST ---
(In reply to comment #4)
> Created attachment 689 [details]
> Add rt_string constructor for completeness
>
> Test cases still failing even with this patch

I'll take a look at it.

Peter

[Bug 789] OCL RTString constructor not work in scripting

Submitted by peter on Fri, 2011-05-20 10:56.

http://bugs.orocos.org/show_bug.cgi?id=789

--- Comment #6 from Peter Soetens <peter [..] ...> 2011-05-20 12:53:03 CEST ---
(In reply to comment #2)
> This has become an incredibly constraining issue for us, so I'm bumping it up.
>
> We need the ability to use real-time strings in state machines and scripts. As
> Peter noted, the parser defaults to all char* values going into std::strings. So
> how do we fix this?
>
> We need the fix for v1, but it looks like the v1 and v2 parsing systems are
> pretty much the same. So any fix we make for v2 should be back-portable to v1
> (we can do that ourselves).
>
> I've attached test cases demonstrating the problem for v2/toolchain. How do we
> proceed to fix this issue? It looks to me that we need to monkey with
> ValueParser to be able to deal with "char*" quantities, instead of directly
> turning them into "string" quantities. I have some time to work on this, but I
> could use some direction before diving into all the fun boost::spirit-fu that is
> the RTT parsing system ... :-)

I have another idea... we could add a constructor for rt_string which takes a
'string const&' as argument. That way, the allocation of the string will be
done during parsing, stored in a ConstantDataSource, and passed by reference to
the rt_string, which uses the .c_str() to initialize itself with it (using
rt_malloc for space allocs).

This will work quickly in 2.x, since ConstantDataSource can return an
'rvalue()'. In 1.x, this is only possible for a ValueDataSource. So for 1.x, we
need to change the parser to use the latter, just for the sake of getting a
reference to the contents.

Peter

[Bug 789] OCL RTString constructor not work in scripting

Submitted by snrkiwi on Fri, 2011-05-20 12:33.

On May 20, 2011, at 06:53 , Peter Soetens wrote:

>
> http://bugs.orocos.org/show_bug.cgi?id=789
>
> --- Comment #6 from Peter Soetens <peter [..] ...> 2011-05-20 12:53:03 CEST ---
> (In reply to comment #2)
>> This has become an incredibly constraining issue for us, so I'm bumping it up.
>>
>> We need the ability to use real-time strings in state machines and scripts. As
>> Peter noted, the parser defaults to all char* values going into std::strings. So
>> how do we fix this?
>>
>> We need the fix for v1, but it looks like the v1 and v2 parsing systems are
>> pretty much the same. So any fix we make for v2 should be back-portable to v1
>> (we can do that ourselves).
>>
>> I've attached test cases demonstrating the problem for v2/toolchain. How do we
>> proceed to fix this issue? It looks to me that we need to monkey with
>> ValueParser to be able to deal with "char*" quantities, instead of directly
>> turning them into "string" quantities. I have some time to work on this, but I
>> could use some direction before diving into all the fun boost::spirit-fu that is
>> the RTT parsing system ... :-)
>
> I have another idea... we could add a constructor for rt_string which takes a
> 'string const&' as argument. That way, the allocation of the string will be
> done during parsing, stored in a ConstantDataSource, and passed by reference to
> the rt_string, which uses the .c_str() to initialize itself with it (using
> rt_malloc for space allocs).

That seems reasonable for v2. So that would cover any instance where the string initialization occurs at parse-time. What about when passing around rt-string variables? Are there any instance where it would bounce from a rt_string to a std::string and then back to rt_string? That kind of silent behaviour would be _awfully_ hard to track down ...

> This will work quickly in 2.x, since ConstantDataSource can return an
> 'rvalue()'. In 1.x, this is only possible for a ValueDataSource. So for 1.x, we
> need to change the parser to use the latter, just for the sake of getting a
> reference to the contents.

I think I see what you mean for v1 ... and I definitely looked at that code and noted the differences between the v1 and v2 implementations.
S

[Bug 789] OCL RTString constructor not work in scripting

Submitted by peter on Fri, 2011-05-20 13:28.

On Friday 20 May 2011 14:28:42 S Roderick wrote:
> On May 20, 2011, at 06:53 , Peter Soetens wrote:
> > http://bugs.orocos.org/show_bug.cgi?id=789
> >
> > --- Comment #6 from Peter Soetens <peter [..] ...> 2011-05-20
> > 12:53:03 CEST --- (In reply to comment #2)
> >
> >> This has become an incredibly constraining issue for us, so I'm bumping
> >> it up.
> >>
> >> We need the ability to use real-time strings in state machines and
> >> scripts. As Peter noted, the parser defaults to all char* values going
> >> into std::strings. So how do we fix this?
> >>
> >> We need the fix for v1, but it looks like the v1 and v2 parsing systems
> >> are pretty much the same. So any fix we make for v2 should be
> >> back-portable to v1 (we can do that ourselves).
> >>
> >> I've attached test cases demonstrating the problem for v2/toolchain. How
> >> do we proceed to fix this issue? It looks to me that we need to monkey
> >> with ValueParser to be able to deal with "char*" quantities, instead of
> >> directly turning them into "string" quantities. I have some time to
> >> work on this, but I could use some direction before diving into all the
> >> fun boost::spirit-fu that is the RTT parsing system ... :-)
> >
> > I have another idea... we could add a constructor for rt_string which
> > takes a 'string const&' as argument. That way, the allocation of the
> > string will be done during parsing, stored in a ConstantDataSource, and
> > passed by reference to the rt_string, which uses the .c_str() to
> > initialize itself with it (using rt_malloc for space allocs).
>
> That seems reasonable for v2. So that would cover any instance where the
> string initialization occurs at parse-time. What about when passing around
> rt-string variables? Are there any instance where it would bounce from a
> rt_string to a std::string and then back to rt_string? That kind of silent
> behaviour would be _awfully_ hard to track down ...

That won't happen. RTT itself is type agnostic. It was the parser that assumed
that a "..." sequence would be put in an std::string. Once you leave the
parser, rt_string remains rt_string.

However, because of our rt_string(string) constructor, we have defined an
conversion from string to rt_string, but not the other way around. So a method
that takes an rt_string and gets a string, can make use of that constructor,
given that we set the 'automatic_conversion' flag of addConstructor() to true.

We didn't do so, but I would advise for it. We could also add the inverse
constructor rt_string -> string, but I would never make that one automatic and
require the user to write string( the_rt_string ). What do you think ?

>
> > This will work quickly in 2.x, since ConstantDataSource can return an
> > 'rvalue()'. In 1.x, this is only possible for a ValueDataSource. So for
> > 1.x, we need to change the parser to use the latter, just for the sake
> > of getting a reference to the contents.
>
> I think I see what you mean for v1 ... and I definitely looked at that code
> and noted the differences between the v1 and v2 implementations. S

Peter

[Bug 789] OCL RTString constructor not work in scripting

Submitted by snrkiwi on Fri, 2011-05-20 14:04.

On May 20, 2011, at 09:26 , Peter Soetens wrote:

> On Friday 20 May 2011 14:28:42 S Roderick wrote:
>> On May 20, 2011, at 06:53 , Peter Soetens wrote:
>>> http://bugs.orocos.org/show_bug.cgi?id=789
>>>
>>> --- Comment #6 from Peter Soetens <peter [..] ...> 2011-05-20
>>> 12:53:03 CEST --- (In reply to comment #2)
>>>
>>>> This has become an incredibly constraining issue for us, so I'm bumping
>>>> it up.
>>>>
>>>> We need the ability to use real-time strings in state machines and
>>>> scripts. As Peter noted, the parser defaults to all char* values going
>>>> into std::strings. So how do we fix this?
>>>>
>>>> We need the fix for v1, but it looks like the v1 and v2 parsing systems
>>>> are pretty much the same. So any fix we make for v2 should be
>>>> back-portable to v1 (we can do that ourselves).
>>>>
>>>> I've attached test cases demonstrating the problem for v2/toolchain. How
>>>> do we proceed to fix this issue? It looks to me that we need to monkey
>>>> with ValueParser to be able to deal with "char*" quantities, instead of
>>>> directly turning them into "string" quantities. I have some time to
>>>> work on this, but I could use some direction before diving into all the
>>>> fun boost::spirit-fu that is the RTT parsing system ... :-)
>>>
>>> I have another idea... we could add a constructor for rt_string which
>>> takes a 'string const&' as argument. That way, the allocation of the
>>> string will be done during parsing, stored in a ConstantDataSource, and
>>> passed by reference to the rt_string, which uses the .c_str() to
>>> initialize itself with it (using rt_malloc for space allocs).
>>
>> That seems reasonable for v2. So that would cover any instance where the
>> string initialization occurs at parse-time. What about when passing around
>> rt-string variables? Are there any instance where it would bounce from a
>> rt_string to a std::string and then back to rt_string? That kind of silent
>> behaviour would be _awfully_ hard to track down ...
>
> That won't happen. RTT itself is type agnostic. It was the parser that assumed
> that a "..." sequence would be put in an std::string. Once you leave the
> parser, rt_string remains rt_string.
>
> However, because of our rt_string(string) constructor, we have defined an
> conversion from string to rt_string, but not the other way around. So a method
> that takes an rt_string and gets a string, can make use of that constructor,
> given that we set the 'automatic_conversion' flag of addConstructor() to true.

Right, and this is realtime because the std::string is created when parsing, and then we access it via c_str() when creating the rt_string when the script/state-machine is running.

> We didn't do so, but I would advise for it. We could also add the inverse
> constructor rt_string -> string, but I would never make that one automatic and
> require the user to write string( the_rt_string ). What do you think ?

That seems reasonable, because the non-realtime nature of this is the user's problem for using a "string" instead of "rt_string". So the following is correct?

// string -> rt_string == automatic conversion
// rt_string -> string ==  NOT automatic conversion
 
var string std
var rt_string rt
...
// OK but not realtime
std = methodReturningString()
// OK, automatic conversion, but not realtime due to creation of intermediate std::string
rt = methodReturningString()
 
// parser ERROR
std = methodReturningRtstring()
// OK, but not realtime
std = string(methodReturningRtstring())
// OK and realtime
rt = methodReturningRtstring()
 
// OK, automatic conversion for method call, but not realtime
transition someEventTakingString(std) if someMethodTakingRtstring(std) ...
// parser ERROR for event
transition someEventTakingRtstring(std) if someMethodTakingRtstring(std) ...
// parser ERROR for method call
transition someEventTakingRtstring(rt) if someMethodTakingRtstring(std) ...
// OK, not realtime
transition someEventTakingRtstring(rt) if someMethodTakingString(string(rt)) ...
// OK, realtime
transition someEventTakingRtstring(rt) if someMethodTakingRtstring(rt) ...

If we're in agreement here, then next week I'll add some extra test cases with the above.

You have no idea how much this will improve my coding life in v1 ....!! :-) ... once we've got this backported anyway ...
S

[Bug 789] OCL RTString constructor not work in scripting

Submitted by peter on Fri, 2011-05-20 14:20.

On Friday 20 May 2011 16:00:29 Stephen Roderick wrote:
> On May 20, 2011, at 09:26 , Peter Soetens wrote:
> > On Friday 20 May 2011 14:28:42 S Roderick wrote:
> >> On May 20, 2011, at 06:53 , Peter Soetens wrote:
> >>> http://bugs.orocos.org/show_bug.cgi?id=789
> >>>
> >>> --- Comment #6 from Peter Soetens <peter [..] ...> 2011-05-20
> >>> 12:53:03 CEST --- (In reply to comment #2)
> >>>
> >>>> This has become an incredibly constraining issue for us, so I'm
> >>>> bumping it up.
> >>>>
> >>>> We need the ability to use real-time strings in state machines and
> >>>> scripts. As Peter noted, the parser defaults to all char* values going
> >>>> into std::strings. So how do we fix this?
> >>>>
> >>>> We need the fix for v1, but it looks like the v1 and v2 parsing
> >>>> systems are pretty much the same. So any fix we make for v2 should be
> >>>> back-portable to v1 (we can do that ourselves).
> >>>>
> >>>> I've attached test cases demonstrating the problem for v2/toolchain.
> >>>> How do we proceed to fix this issue? It looks to me that we need to
> >>>> monkey with ValueParser to be able to deal with "char*" quantities,
> >>>> instead of directly turning them into "string" quantities. I have
> >>>> some time to work on this, but I could use some direction before
> >>>> diving into all the fun boost::spirit-fu that is the RTT parsing
> >>>> system ... :-)
> >>>
> >>> I have another idea... we could add a constructor for rt_string which
> >>> takes a 'string const&' as argument. That way, the allocation of the
> >>> string will be done during parsing, stored in a ConstantDataSource, and
> >>> passed by reference to the rt_string, which uses the .c_str() to
> >>> initialize itself with it (using rt_malloc for space allocs).
> >>
> >> That seems reasonable for v2. So that would cover any instance where the
> >> string initialization occurs at parse-time. What about when passing
> >> around rt-string variables? Are there any instance where it would
> >> bounce from a rt_string to a std::string and then back to rt_string?
> >> That kind of silent behaviour would be _awfully_ hard to track down ...
> >
> > That won't happen. RTT itself is type agnostic. It was the parser that
> > assumed that a "..." sequence would be put in an std::string. Once you
> > leave the parser, rt_string remains rt_string.
> >
> > However, because of our rt_string(string) constructor, we have defined an
> > conversion from string to rt_string, but not the other way around. So a
> > method that takes an rt_string and gets a string, can make use of that
> > constructor, given that we set the 'automatic_conversion' flag of
> > addConstructor() to true.
>
> Right, and this is realtime because the std::string is created when
> parsing, and then we access it via c_str() when creating the rt_string
> when the script/state-machine is running.

Exactly.

>
> > We didn't do so, but I would advise for it. We could also add the inverse
> > constructor rt_string -> string, but I would never make that one
> > automatic and require the user to write string( the_rt_string ). What do
> > you think ?
>
> That seems reasonable, because the non-realtime nature of this is the
> user's problem for using a "string" instead of "rt_string". So the
> following is correct?
>
>

> // string -> rt_string == automatic conversion
> // rt_string -> string ==  NOT automatic conversion
 
Yes, that's how I put it. However, looking at your examples below... I wonder 
if we're helping with not doing the automatic conversion in the second 
case...it's confusing and not always clear why one is automatic and the other 
is not.
 
> 
> var string std
> var rt_string rt
> ...
> // OK but not realtime
> std = methodReturningString()
> // OK, automatic conversion, but not realtime due to creation of
> intermediate std::string 
> rt = methodReturningString()
 
Ack
 
> 
> // parser ERROR
> std = methodReturningRtstring()
> // OK, but not realtime
> std = string(methodReturningRtstring())
> // OK and realtime
> rt = methodReturningRtstring()
 
Ack.
 
> 
> // OK, automatic conversion for method call, but not realtime
> transition someEventTakingString(std) if someMethodTakingRtstring(std) ...
> // parser ERROR for event
> transition someEventTakingRtstring(std) if someMethodTakingRtstring(std)
 
Yes.
 
> ... // parser ERROR for method call
> transition someEventTakingRtstring(rt) if someMethodTakingRtstring(std) ...
 
No ?
 
> // OK, not realtime
> transition someEventTakingRtstring(rt) if
> someMethodTakingString(string(rt)) ... 
 
Ack.
 
> // OK, realtime
> transition someEventTakingRtstring(rt) if someMethodTakingRtstring(rt) ...
>

Ack.

>
> If we're in agreement here, then next week I'll add some extra test cases
> with the above.

I have pushed a dozen patches to toolchain-2.3 with various tests and
additions.

>
> You have no idea how much this will improve my coding life in v1 ....!! :-)
> ... once we've got this backported anyway ... S

I don't foresee big issues, except the 1.x parser hack, which will make "foo"
= "bar" valid syntax...

Peter

[Bug 789] OCL RTString constructor not work in scripting

Submitted by snrkiwi on Sat, 2011-05-21 18:08.

On May 20, 2011, at 10:19 , Peter Soetens wrote:

> On Friday 20 May 2011 16:00:29 Stephen Roderick wrote:
>> On May 20, 2011, at 09:26 , Peter Soetens wrote:
>>> On Friday 20 May 2011 14:28:42 S Roderick wrote:
>>>> On May 20, 2011, at 06:53 , Peter Soetens wrote:
>>>>> http://bugs.orocos.org/show_bug.cgi?id=789
>>>>>
>>>>> --- Comment #6 from Peter Soetens <peter [..] ...> 2011-05-20
>>>>> 12:53:03 CEST --- (In reply to comment #2)
>>>>>
>>>>>> This has become an incredibly constraining issue for us, so I'm
>>>>>> bumping it up.
>>>>>>
>>>>>> We need the ability to use real-time strings in state machines and
>>>>>> scripts. As Peter noted, the parser defaults to all char* values going
>>>>>> into std::strings. So how do we fix this?
>>>>>>
>>>>>> We need the fix for v1, but it looks like the v1 and v2 parsing
>>>>>> systems are pretty much the same. So any fix we make for v2 should be
>>>>>> back-portable to v1 (we can do that ourselves).
>>>>>>
>>>>>> I've attached test cases demonstrating the problem for v2/toolchain.
>>>>>> How do we proceed to fix this issue? It looks to me that we need to
>>>>>> monkey with ValueParser to be able to deal with "char*" quantities,
>>>>>> instead of directly turning them into "string" quantities. I have
>>>>>> some time to work on this, but I could use some direction before
>>>>>> diving into all the fun boost::spirit-fu that is the RTT parsing
>>>>>> system ... :-)
>>>>>
>>>>> I have another idea... we could add a constructor for rt_string which
>>>>> takes a 'string const&' as argument. That way, the allocation of the
>>>>> string will be done during parsing, stored in a ConstantDataSource, and
>>>>> passed by reference to the rt_string, which uses the .c_str() to
>>>>> initialize itself with it (using rt_malloc for space allocs).
>>>>
>>>> That seems reasonable for v2. So that would cover any instance where the
>>>> string initialization occurs at parse-time. What about when passing
>>>> around rt-string variables? Are there any instance where it would
>>>> bounce from a rt_string to a std::string and then back to rt_string?
>>>> That kind of silent behaviour would be _awfully_ hard to track down ...
>>>
>>> That won't happen. RTT itself is type agnostic. It was the parser that
>>> assumed that a "..." sequence would be put in an std::string. Once you
>>> leave the parser, rt_string remains rt_string.
>>>
>>> However, because of our rt_string(string) constructor, we have defined an
>>> conversion from string to rt_string, but not the other way around. So a
>>> method that takes an rt_string and gets a string, can make use of that
>>> constructor, given that we set the 'automatic_conversion' flag of
>>> addConstructor() to true.
>>
>> Right, and this is realtime because the std::string is created when
>> parsing, and then we access it via c_str() when creating the rt_string
>> when the script/state-machine is running.
>
> Exactly.
>
>>
>>> We didn't do so, but I would advise for it. We could also add the inverse
>>> constructor rt_string -> string, but I would never make that one
>>> automatic and require the user to write string( the_rt_string ). What do
>>> you think ?
>>
>> That seems reasonable, because the non-realtime nature of this is the
>> user's problem for using a "string" instead of "rt_string". So the
>> following is correct?
>>
>>

>> // string -> rt_string == automatic conversion
>> // rt_string -> string ==  NOT automatic conversion
> 
> Yes, that's how I put it. However, looking at your examples below... I wonder 
> if we're helping with not doing the automatic conversion in the second 
> case...it's confusing and not always clear why one is automatic and the other 
> is not.
> 
>> 
>> var string std
>> var rt_string rt
>> ...
>> // OK but not realtime
>> std = methodReturningString()
>> // OK, automatic conversion, but not realtime due to creation of
>> intermediate std::string 
>> rt = methodReturningString()
> 
> Ack
> 
>> 
>> // parser ERROR
>> std = methodReturningRtstring()
>> // OK, but not realtime
>> std = string(methodReturningRtstring())
>> // OK and realtime
>> rt = methodReturningRtstring()
> 
> Ack.
> 
>> 
>> // OK, automatic conversion for method call, but not realtime
>> transition someEventTakingString(std) if someMethodTakingRtstring(std) ...
>> // parser ERROR for event
>> transition someEventTakingRtstring(std) if someMethodTakingRtstring(std)
> 
> Yes.
> 
>> ... // parser ERROR for method call
>> transition someEventTakingRtstring(rt) if someMethodTakingRtstring(std) ...
> 
> No ?
> 
>> // OK, not realtime
>> transition someEventTakingRtstring(rt) if
>> someMethodTakingString(string(rt)) ... 
> 
> Ack.
> 
>> // OK, realtime
>> transition someEventTakingRtstring(rt) if someMethodTakingRtstring(rt) ...
>>

>
> Ack.
>
>>
>> If we're in agreement here, then next week I'll add some extra test cases
>> with the above.
>
> I have pushed a dozen patches to toolchain-2.3 with various tests and
> additions.

Some additional test cases in attached patch.

NB the failure to shorten a rt_string using char access, in testRtstringCharAccess(). Not sure why that doesn't work

>> You have no idea how much this will improve my coding life in v1 ....!! :-)
>> ... once we've got this backported anyway ... S
>
> I don't foresee big issues, except the 1.x parser hack, which will make "foo"
> = "bar" valid syntax...

I will take a look at patching v1 this week.
S

[Bug 789] OCL RTString constructor not work in scripting

Submitted by snrkiwi on Tue, 2011-08-02 08:16.

http://bugs.orocos.org/show_bug.cgi?id=789

--- Comment #9 from S Roderick <kiwi [dot] net [..] ...> 2011-08-02 10:14:31 CEST ---
Created attachment 722
--> http://bugs.orocos.org/attachment.cgi?id=722
RTT v1 patch to allow std::string to be used alongside rt_string

[Bug 789] OCL RTString constructor not work in scripting

Submitted by snrkiwi on Tue, 2011-08-02 08:16.

http://bugs.orocos.org/show_bug.cgi?id=789

--- Comment #10 from S Roderick <kiwi [dot] net [..] ...> 2011-08-02 10:15:42 CEST ---
Created attachment 723
--> http://bugs.orocos.org/attachment.cgi?id=723
OCL v1 patch supplying real-time string

[Bug 789] OCL RTString constructor not work in scripting

Submitted by snrkiwi on Tue, 2011-08-02 08:20.

http://bugs.orocos.org/show_bug.cgi?id=789

--- Comment #11 from S Roderick <kiwi [dot] net [..] ...> 2011-08-02 10:16:43 CEST ---
Created attachment 724
--> http://bugs.orocos.org/attachment.cgi?id=724
OCL v1 patch supplying toolkit and transport plugins for rt_string

Supports use of rt_string in scripts and state machines.
Supports rt_string over CORBA.
Contains test cases.

[Bug 789] OCL RTString constructor not work in scripting

Submitted by snrkiwi on Fri, 2011-05-20 14:28.

On May 20, 2011, at 10:19 , Peter Soetens wrote:

>> // string -> rt_string == automatic conversion
>> // rt_string -> string ==  NOT automatic conversion
> 
> Yes, that's how I put it. However, looking at your examples below... I wonder 
> if we're helping with not doing the automatic conversion in the second 
> case...it's confusing and not always clear why one is automatic and the other 
> is not.
 
Yeah, it actually took me a while to work up those example test cases, and figure out what would happen. We might be digging ourselves into a hole ...
 
>> var string std
>> var rt_string rt
>> ...
>> // OK but not realtime
>> std = methodReturningString()
>> // OK, automatic conversion, but not realtime due to creation of
>> intermediate std::string 
>> rt = methodReturningString()
> 
> Ack
> 
>> 
>> // parser ERROR
>> std = methodReturningRtstring()
>> // OK, but not realtime
>> std = string(methodReturningRtstring())
>> // OK and realtime
>> rt = methodReturningRtstring()
> 
> Ack.
> 
>> 
>> // OK, automatic conversion for method call, but not realtime
>> transition someEventTakingString(std) if someMethodTakingRtstring(std) ...
>> // parser ERROR for event
>> transition someEventTakingRtstring(std) if someMethodTakingRtstring(std)
> 
> Yes.
> 
>> ... // parser ERROR for method call
>> transition someEventTakingRtstring(rt) if someMethodTakingRtstring(std) ...
> 
> No ?
 
Ahh, yeah, that is automatic conversion for the method call. So that is ok, and realtime (as we're accessing the std::string, not creating it. The non-realtime bit would be creation/population of that std::string).
 
>> // OK, not realtime
>> transition someEventTakingRtstring(rt) if
>> someMethodTakingString(string(rt)) ... 
> 
> Ack.
> 
>> // OK, realtime
>> transition someEventTakingRtstring(rt) if someMethodTakingRtstring(rt) ...
>>

>
> Ack.
>
>>
>> If we're in agreement here, then next week I'll add some extra test cases
>> with the above.
>
> I have pushed a dozen patches to toolchain-2.3 with various tests and
> additions.

Ok, I'll check them out when I get a chance

ROTFL ... I can't wait to see ML traffic for that one ...!! Guess the only blessing is that I'm one of the few fools remaining on v1 ... ;-)
S

[Bug 789] OCL RTString constructor not work in scripting

Submitted by peter on Fri, 2011-05-20 11:04.

http://bugs.orocos.org/show_bug.cgi?id=789

--- Comment #7 from Peter Soetens <peter [..] ...> 2011-05-20 13:02:23 CEST ---
Created attachment 691
--> http://bugs.orocos.org/attachment.cgi?id=691
v2.x : Fixes one unit test: testCreateRtstringFromRtString

In 2.x:
$ ./value_test
Running 4 test cases...
/home/kaltan/src/git/orocos-toolchain/rtt/tests/value_test.cpp(153): fatal
error in "testCreateRtstringFromCharPtr": Parse error at line 3: Semantic
error: Attempt to initialize rt_string s1 with a string, expected an integer
expression.

*** 1 failure detected in test suite "Master Test Suite"

The failing test would also fail with a plain string. It only accepts a
capacity, although we could make the parser smarter for that too.

For 1.x, the ValueParser still needs to be adapted...

[Bug 789] OCL RTString constructor not work in scripting

Submitted by peter on Fri, 2011-05-20 11:12.

http://bugs.orocos.org/show_bug.cgi?id=789

--- Comment #8 from Peter Soetens <peter [..] ...> 2011-05-20 13:11:44 CEST ---
(In reply to comment #7)
> Created attachment 691
> v2.x : Fixes one unit test: testCreateRtstringFromRtString
>
> In 2.x:
> $ ./value_test
> Running 4 test cases...
> /home/kaltan/src/git/orocos-toolchain/rtt/tests/value_test.cpp(153): fatal error
> in "testCreateRtstringFromCharPtr": Parse error at line 3: Semantic error:
> Attempt to initialize rt_string s1 with a string, expected an integer
> expression.
>
> *** 1 failure detected in test suite "Master Test Suite"
>
> The failing test would also fail with a plain string. It only accepts a
> capacity, although we could make the parser smarter for that too.
>
> For 1.x, the ValueParser still needs to be adapted...

So something similar/identical to this:

--- a/rtt/scripting/ValueParser.cpp
+++ b/rtt/scripting/ValueParser.cpp
@@ -230,7 +230,7 @@ namespace RTT
     // string will be in mcurstring, and we don't want it, so we
     // remove it..
     mcurstring.erase( mcurstring.end() - 1 );
-    ret = new ConstantDataSource<std::string>( mcurstring );
+    ret = new ValueDataSource<std::string>( mcurstring );
     //deleter.reset( ret );
     mcurstring.clear();
   }

Peter

OCL Home

OCL Download

OCL Documentation

[Bug 789] New: OCL RTString constructor not work in scripting