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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.