[Bug 714] New: KDL plugin constructor invalid
Submitted by snrkiwi on Mon, 2009-11-02 10:28 |
https://www.fmtc.be/bugzilla/orocos/show_bug.cgi?id=714
Summary: KDL plugin constructor invalid
Product: KDL
Version: kdl-trunk
Platform: All
OS/Version: All
Status: NEW
Severity: normal
Priority: P3
Component: Plugin
AssignedTo: orocos-dev [..] ...
ReportedBy: kiwi [dot] net [..] ...
CC: orocos-dev [..] ...
Estimated Hours: 0.0
Only the first version of the following works.
var vector v1 = vector(1.0, 2.0, 3.0) var vector v2(1.0, 2.0, 3.0)
The second version gives an error of the form
Attempt to initialize vector v2 with a double, expected an integer expression.
Should the 2nd constructor above not be possible? If not, then it appears to be
not possible to use KDL variables in state-machines/program-scripts within a
real-time component.
Same goes for rotation also.
[Bug 714] KDL plugin constructor invalid
https://www.fmtc.be/bugzilla/orocos/show_bug.cgi?id=714
Peter Soetens <peter [..] ...> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |peter [..] ...
--- Comment #1 from Peter Soetens <peter [..] ...> 2009-10-23 16:24:44 ---
(In reply to comment #0)
> Only the first version of the following works.
>
>
> The second version gives an error of the form
>
>
> Should the 2nd constructor above not be possible? If not, then it appears to be
> not possible to use KDL variables in state-machines/program-scripts within a
> real-time component.
>
> Same goes for rotation also.
The 'real-time' constraint only holds for string and array. The notation
Is always hard real-time for kdl vector, double, kdl frame etc. because they
don't allocate.
For the second notation, the parser expects a size hint, instead of a
constructor. I guess we could/should support both forms nevertheless.
Peter
[Bug 714] KDL plugin constructor invalid
On Oct 23, 2009, at 10:24 , Peter Soetens wrote:
> https://www.fmtc.be/bugzilla/orocos/show_bug.cgi?id=714
>
>
> Peter Soetens <peter [..] ...> changed:
>
> What |Removed |Added
> ----------------------------------------------------------------------------
> CC| |
> peter [..] ...
>
>
>
>
> --- Comment #1 from Peter Soetens <peter [..] ...>
> 2009-10-23 16:24:44 ---
> (In reply to comment #0)
>> Only the first version of the following works.
>>
>>
>> The second version gives an error of the form
>>
>>
>> Should the 2nd constructor above not be possible? If not, then it
>> appears to be
>> not possible to use KDL variables in state-machines/program-scripts
>> within a
>> real-time component.
>>
>> Same goes for rotation also.
>
> The 'real-time' constraint only holds for string and array. The
> notation
>
>
>
> Is always hard real-time for kdl vector, double, kdl frame etc.
> because they
> don't allocate.
If it hadn't been so late on a Friday, I would've noticed that myself
before posting. Sorry.
> For the second notation, the parser expects a size hint, instead of a
> constructor. I guess we could/should support both forms nevertheless.
A size hint? Is this something built in to the parser, vs specific to
that type?
Stephen
[Bug 714] KDL plugin constructor invalid
On Sat, Oct 24, 2009 at 19:47, S Roderick <kiwi [dot] net [..] ...> wrote:
...
>> For the second notation, the parser expects a size hint, instead of a
>> constructor. I guess we could/should support both forms nevertheless.
>
> A size hint? Is this something built in to the parser, vs specific to that
> type?
Every type (using TemplateTypeInfo) may define a 'constructor' that
takes a size hint. vector and string use this, but it is especially
from the old days where we didn't have constructors. The size hint is
evaluated at *parse time*, so it has a special meaning. Constructors
are evaluated at execution time (as one would logically expect).
Peter
[Bug 714] KDL plugin constructor invalid
http://bugs.orocos.org/show_bug.cgi?id=714
Ruben Smits <ruben [dot] smits [..] ...> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
CC| |ruben.smits@intermodalics.e
| |u
Resolution| |INVALID