Re: rttlua does not support enum types as arguments for operations

On Thu, Mar 14, 2013 at 6:07 PM, Markus Klotzbuecher
<[email protected]> wrote:
> On Thu, Mar 14, 2013 at 05:43:01PM +0100, Peter Soetens wrote:
>> On Thu, Mar 14, 2013 at 5:28 PM, Markus Klotzbuecher
>> <[email protected]> wrote:
>> > On Thu, Mar 14, 2013 at 05:01:41PM +0100, Peter Soetens wrote:
>> >> On Thu, Mar 14, 2013 at 4:53 PM, Ruben Smits
>> >> <[email protected]> wrote:
>> >> > Hi,
>> >> >
>> >> > I've got an enum type for which I created a typekit using typegen and an
>> >> > extra plugin to add these enums to the GlobalTypeRepository of RTT.
>> >> >
>> >> > I have a component that uses this enum as an argument type. Everything goes
>> >> > fine using the OCL Taskbrowser, I can call my operation using the enum taken
>> >> > from the global repository.
>> >> >
>> >> > The same however fails using rttlua with the following error:
>> >> >
>> >> > ```
>> >> >> component.operation("string",rtt.globals.MYENUM)
>> >> >
>> >> > /home/rsmits/orocos_toolchain/ocl/bin/rttlua-gnulinux:
>> >> > .../orocos_toolchain/ocl/lua/modules/rttlib.lua:716: Operation.call:
>> >> > argument 2 is not assignable.
>> >> >
>> >> > ```
>> >> >
>> >> > Does anyone have an idea why this happens? Is this due to the fact that I
>> >> > take the value from the GlobalRepository?
>> >>
>> >> It's due to the fact that it accidentally worked for primitive types
>> >> (int,float,...) and not for all other types.
>> >>
>> >> Patch in attachment that copies the constant over to a value data
>> >> source and uses that down the road.
>> >>
>> >> Fine to push Markus ?
>> >
>> > Hmm, in which other code paths might this occur? For the globals
>> > assigment it's not a problem, but could this happen in a rt-critical
>> > paths? If that's possible it should not happen silently.
>>
>> Now I see...you're right, this can't happen in the rt-critical path.
>
> It can or not?

I meant: the patch is not allowed to do this since it's in the critical path.

>
>> We'll need a better solution.
>
> Would it work if the operation argument were const?

No since we're set-referencing it, independent of the actual argument
type. We might invent a ConstReference which
accepts a non-assignable datasource in setReference(), but I wonder if
this creates more problems than it solves...

>
> It's not a real solution, but I guess one could create a new Variable
> of the same type and assign the global constant to it, prior to
> invoking the operation...

Indeed.

Peter
-- 
Orocos-Dev mailing list
[email protected]
http://lists.mech.kuleuven.be/mailman/listinfo/orocos-dev