hi,
i've "lua-fied" allmost everything of my current project
but...
*I want to set an attribute in my statemachines, which is currently unsupported?! (only properties, but I don't want to change it to a property)
something like:
CMWyGlobal = peertable.Scene:getAttribute("CartesianMotion_Wy_global")
CMWyGlobal:set(1.0)
*in the old rtt syntax I could initialize a kdl rotationmatrix with RPY angles like: kdl_rot=KDL.Rotation(3.14159265,0.0,1.57)
but this isn't possible with lua, correct?
You have to give all matrix values:
kdl_rot:fromtab( {X_z=0,Z_y=1,Y_y=-0.000796327,X_y=0,Y_z=1,Z_z=0.000796327,Y_x=0,Z_x=0,X_x=-1} )
(which are btw ordered in a strange way if you print the value (like above))
Can I put some feature requests somewhere?
nick
lua wishlist
Hi Nick,
On Thu, May 26, 2011 at 07:00:47PM +0200, Dominick Vanthienen wrote:
>
> i've "lua-fied" allmost everything of my current project
> but...
> *I want to set an attribute in my statemachines, which is currently unsupported?! (only properties, but I don't want to change it to a property)
> something like:
> CMWyGlobal = peertable.Scene:getAttribute("CartesianMotion_Wy_global")
> CMWyGlobal:set(1.0)
Your observation is right, rttlua does not support attributes. The
reason is not because it would be difficult to add, but rather than at
the OROCOS developers meeting last year it was agreed upon to
consolidate attributes and properties. I still think this would be the
right thing to do, because
1. The differences are subtle and confuse a lot of people
2. The fact that such an entity can be stored persistant or not is a
secondary characteristic that is achieved by some optional additional code
(e.g. the marshalling service, ruby or lua bindings).
So unless the decision to merge these is revoked it does not make
sense to add code for something scheduled for removal.
> *in the old rtt syntax I could initialize a kdl rotationmatrix with RPY angles like: kdl_rot=KDL.Rotation(3.14159265,0.0,1.57)
> but this isn't possible with lua, correct?
No, but this is something I would like to support (and would probably
would be easy to do).
> You have to give all matrix values:
> kdl_rot:fromtab( {X_z=0,Z_y=1,Y_y=-0.000796327,X_y=0,Y_z=1,Z_z=0.000796327,Y_x=0,Z_x=0,X_x=-1} )
> (which are btw ordered in a strange way if you print the value (like above))
Lua can inspect the structure of composite data, but naturally doesn't
know about what order make sense. However it can be easily
refined (see here
http://www.orocos.org/wiki/orocos/toolchain/LuaCookbook#toc49 )
Attached a small Lua module to illustrate how to add "pretty printing"
for the examples of KDL.Vector, KDL.Rotation and KDL.Frame.
> Can I put some feature requests somewhere?
Please add them here:
http://www.orocos.org/wiki/orocos/toolchain/LuaFeatureRequests
:-)
Thanks!
Markus
lua wishlist
On 05/27/2011 11:36 AM, Markus Klotzbuecher wrote:
> Hi Nick,
>
> On Thu, May 26, 2011 at 07:00:47PM +0200, Dominick Vanthienen wrote:
>> i've "lua-fied" allmost everything of my current project
>> but...
>> *I want to set an attribute in my statemachines, which is currently unsupported?! (only properties, but I don't want to change it to a property)
>> something like:
>> CMWyGlobal = peertable.Scene:getAttribute("CartesianMotion_Wy_global")
>> CMWyGlobal:set(1.0)
> Your observation is right, rttlua does not support attributes. The
> reason is not because it would be difficult to add, but rather than at
> the OROCOS developers meeting last year it was agreed upon to
> consolidate attributes and properties. I still think this would be the
> right thing to do, because
> 1. The differences are subtle and confuse a lot of people
> 2. The fact that such an entity can be stored persistant or not is a
> secondary characteristic that is achieved by some optional additional code
> (e.g. the marshalling service, ruby or lua bindings).
>
> So unless the decision to merge these is revoked it does not make
> sense to add code for something scheduled for removal.
>
>> *in the old rtt syntax I could initialize a kdl rotationmatrix with RPY angles like: kdl_rot=KDL.Rotation(3.14159265,0.0,1.57)
>> but this isn't possible with lua, correct?
> No, but this is something I would like to support (and would probably
> would be easy to do).
>
>> You have to give all matrix values:
>> kdl_rot:fromtab( {X_z=0,Z_y=1,Y_y=-0.000796327,X_y=0,Y_z=1,Z_z=0.000796327,Y_x=0,Z_x=0,X_x=-1} )
>> (which are btw ordered in a strange way if you print the value (like above))
> Lua can inspect the structure of composite data, but naturally doesn't
> know about what order make sense. However it can be easily
> refined (see here
> http://www.orocos.org/wiki/orocos/toolchain/LuaCookbook#toc49 )
>
> Attached a small Lua module to illustrate how to add "pretty printing"
> for the examples of KDL.Vector, KDL.Rotation and KDL.Frame.
thanx for the file, little remark: kdl has a very unusual habit to call X_y the First column, 2nd row (so X is column, y is row) in contrast to the more common row_column
notation
so in the attached file should the matrix be transposed ;)
>> Can I put some feature requests somewhere?
> Please add them here:
>
> http://www.orocos.org/wiki/orocos/toolchain/LuaFeatureRequests
>
> :-)
>
> Thanks!
> Markus
lua wishlist
On 05/27/2011 01:54 PM, Dominick Vanthienen wrote:
>
>
> On 05/27/2011 11:36 AM, Markus Klotzbuecher wrote:
>> Hi Nick,
>>
>> On Thu, May 26, 2011 at 07:00:47PM +0200, Dominick Vanthienen wrote:
>>> i've "lua-fied" allmost everything of my current project
>>> but...
>>> *I want to set an attribute in my statemachines, which is currently unsupported?! (only properties, but I don't want to change it to a property)
>>> something like:
>>> CMWyGlobal = peertable.Scene:getAttribute("CartesianMotion_Wy_global")
>>> CMWyGlobal:set(1.0)
>> Your observation is right, rttlua does not support attributes. The
>> reason is not because it would be difficult to add, but rather than at
>> the OROCOS developers meeting last year it was agreed upon to
>> consolidate attributes and properties. I still think this would be the
>> right thing to do, because
>> 1. The differences are subtle and confuse a lot of people
>> 2. The fact that such an entity can be stored persistant or not is a
>> secondary characteristic that is achieved by some optional additional code
>> (e.g. the marshalling service, ruby or lua bindings).
>>
>> So unless the decision to merge these is revoked it does not make
>> sense to add code for something scheduled for removal.
>>
>>> *in the old rtt syntax I could initialize a kdl rotationmatrix with RPY angles like: kdl_rot=KDL.Rotation(3.14159265,0.0,1.57)
>>> but this isn't possible with lua, correct?
>> No, but this is something I would like to support (and would probably
>> would be easy to do).
>>
>>> You have to give all matrix values:
>>> kdl_rot:fromtab( {X_z=0,Z_y=1,Y_y=-0.000796327,X_y=0,Y_z=1,Z_z=0.000796327,Y_x=0,Z_x=0,X_x=-1} )
>>> (which are btw ordered in a strange way if you print the value (like above))
>> Lua can inspect the structure of composite data, but naturally doesn't
>> know about what order make sense. However it can be easily
>> refined (see here
>> http://www.orocos.org/wiki/orocos/toolchain/LuaCookbook#toc49 )
>>
>> Attached a small Lua module to illustrate how to add "pretty printing"
>> for the examples of KDL.Vector, KDL.Rotation and KDL.Frame.
> thanx for the file, little remark: kdl has a very unusual habit to call X_y the First column, 2nd row (so X is column, y is row) in contrast to the more common row_column
> notation
> so in the attached file should the matrix be transposed ;)
see patch below
>>> Can I put some feature requests somewhere?
>> Please add them here:
>>
>> http://www.orocos.org/wiki/orocos/toolchain/LuaFeatureRequests
>>
>> :-)
>>
>> Thanks!
>> Markus
--- kdlppOLD.lua 2011-05-27 14:08:27.964170039 +0200
+++ kdlpp.lua 2011-05-27 14:02:38.084170039 +0200
@@ -21,9 +21,9 @@
-- KDL.Rotation
function KDL_Rotation_tostr(rot)
- return ("%s %s %s\n%s %s %s\n%s %s %s"):format(padn(rot.X_x), padn(rot.X_y),padn(rot.X_z),
- padn(rot.Y_x), padn(rot.Y_y),padn(rot.Y_z),
- padn(rot.Z_x), padn(rot.Z_y),padn(rot.Z_z))
+ return ("%s %s %s\n%s %s %s\n%s %s %s"):format(padn(rot.X_x), padn(rot.Y_x),padn(rot.Z_x),
+ padn(rot.X_y), padn(rot.Y_y),padn(rot.Z_y),
+ padn(rot.X_z), padn(rot.Y_z),padn(rot.Z_z))
end
-- KDL.Frame
@@ -32,9 +32,9 @@
[[%s %s %s %s
%s %s %s %s
%s %s %s %s
-%s %s %s %s]]):format(padn(f.M.X_x), padn(f.M.X_y),padn(f.M.X_z), padn(f.p.X),
- padn(f.M.Y_x), padn(f.M.Y_y),padn(f.M.Y_z), padn(f.p.Y),
- padn(f.M.Z_x), padn(f.M.Z_y),padn(f.M.Z_z), padn(f.p.Z),
+%s %s %s %s]]):format(padn(f.M.X_x), padn(f.M.Y_x),padn(f.M.Z_x), padn(f.p.X),
+ padn(f.M.X_y), padn(f.M.Y_y),padn(f.M.Z_y), padn(f.p.Y),
+ padn(f.M.X_z), padn(f.M.Y_z),padn(f.M.Z_z), padn(f.p.Z),
padn(0), padn(0), padn(0), padn(1))
end
lua wishlist
On Thu, 26 May 2011, Dominick Vanthienen wrote:
> hi,
>
> i've "lua-fied" allmost everything of my current project
> but...
> *I want to set an attribute in my statemachines, which is currently unsupported?! (only properties, but I don't want to change it to a property)
> something like:
> CMWyGlobal = peertable.Scene:getAttribute("CartesianMotion_Wy_global")
> CMWyGlobal:set(1.0)
> *in the old rtt syntax I could initialize a kdl rotationmatrix with RPY angles like: kdl_rot=KDL.Rotation(3.14159265,0.0,1.57)
> but this isn't possible with lua, correct?
> You have to give all matrix values:
> kdl_rot:fromtab( {X_z=0,Z_y=1,Y_y=-0.000796327,X_y=0,Y_z=1,Z_z=0.000796327,Y_x=0,Z_x=0,X_x=-1} )
> (which are btw ordered in a strange way if you print the value (like above))
>
> Can I put some feature requests somewhere?
Please, don't ask the Lua maintainer to turn the Lua support in Orocos into
a full-fledged scripting language, kitchen sink included! I don't like to
see the project go there: Lua should do Coordination, and nothing more. All
"useful stuff" should be done by calling non-Lua functionalities, not by
extending Lua to copy that stuff...
For example: the Coordination should _not_ do data communication, let alone
encode algorithms that compute when to fire events or transition states.
All these computations should reside in "computational slaves" (hopefully
the components that _are_ already there computing the functionality in the
system!), and not in the FSM.
I've seen way too many projects loose there competitive advantage by trying
to hit every nail by the (nice but limited, by design!) hammer they have...
> nick
Herman
lua wishlist
On Thu, May 26, 2011 at 07:10:21PM +0200, Herman Bruyninckx wrote:
> On Thu, 26 May 2011, Dominick Vanthienen wrote:
>
> > hi,
> >
> > i've "lua-fied" allmost everything of my current project
> > but...
> > *I want to set an attribute in my statemachines, which is currently unsupported?! (only properties, but I don't want to change it to a property)
> > something like:
> > CMWyGlobal = peertable.Scene:getAttribute("CartesianMotion_Wy_global")
> > CMWyGlobal:set(1.0)
> > *in the old rtt syntax I could initialize a kdl rotationmatrix with RPY angles like: kdl_rot=KDL.Rotation(3.14159265,0.0,1.57)
> > but this isn't possible with lua, correct?
> > You have to give all matrix values:
> > kdl_rot:fromtab( {X_z=0,Z_y=1,Y_y=-0.000796327,X_y=0,Y_z=1,Z_z=0.000796327,Y_x=0,Z_x=0,X_x=-1} )
> > (which are btw ordered in a strange way if you print the value (like above))
> >
> > Can I put some feature requests somewhere?
>
> Please, don't ask the Lua maintainer to turn the Lua support in Orocos into
> a full-fledged scripting language, kitchen sink included! I don't like to
> see the project go there: Lua should do Coordination, and nothing more. All
> "useful stuff" should be done by calling non-Lua functionalities, not by
> extending Lua to copy that stuff...
Exactly! Thats the Lua philosophy!
> For example: the Coordination should _not_ do data communication, let alone
> encode algorithms that compute when to fire events or transition states.
> All these computations should reside in "computational slaves" (hopefully
> the components that _are_ already there computing the functionality in the
> system!), and not in the FSM.
Yes, Coordination delegates the computations. However, here Nick is
only using Coordination to do initial ocnfiguration, hence the need to
set an attribute.
> I've seen way too many projects loose there competitive advantage by trying
> to hit every nail by the (nice but limited, by design!) hammer they have...
Yes, and we're not falling into that trap :-)
Markus
lua wishlist
On Fri, 27 May 2011, Markus Klotzbuecher wrote:
> On Thu, May 26, 2011 at 07:10:21PM +0200, Herman Bruyninckx wrote:
>> On Thu, 26 May 2011, Dominick Vanthienen wrote:
>>
>>> hi,
>>>
>>> i've "lua-fied" allmost everything of my current project
>>> but...
>>> *I want to set an attribute in my statemachines, which is currently unsupported?! (only properties, but I don't want to change it to a property)
>>> something like:
>>> CMWyGlobal = peertable.Scene:getAttribute("CartesianMotion_Wy_global")
>>> CMWyGlobal:set(1.0)
>>> *in the old rtt syntax I could initialize a kdl rotationmatrix with RPY angles like: kdl_rot=KDL.Rotation(3.14159265,0.0,1.57)
>>> but this isn't possible with lua, correct?
>>> You have to give all matrix values:
>>> kdl_rot:fromtab( {X_z=0,Z_y=1,Y_y=-0.000796327,X_y=0,Y_z=1,Z_z=0.000796327,Y_x=0,Z_x=0,X_x=-1} )
>>> (which are btw ordered in a strange way if you print the value (like above))
>>>
>>> Can I put some feature requests somewhere?
>>
>> Please, don't ask the Lua maintainer to turn the Lua support in Orocos into
>> a full-fledged scripting language, kitchen sink included! I don't like to
>> see the project go there: Lua should do Coordination, and nothing more. All
>> "useful stuff" should be done by calling non-Lua functionalities, not by
>> extending Lua to copy that stuff...
>
> Exactly! Thats the Lua philosophy!
>
>> For example: the Coordination should _not_ do data communication, let alone
>> encode algorithms that compute when to fire events or transition states.
>> All these computations should reside in "computational slaves" (hopefully
>> the components that _are_ already there computing the functionality in the
>> system!), and not in the FSM.
>
> Yes, Coordination delegates the computations. However, here Nick is
> only using Coordination to do initial ocnfiguration, hence the need to
> set an attribute.
>
>> I've seen way too many projects loose there competitive advantage by trying
>> to hit every nail by the (nice but limited, by design!) hammer they have...
>
> Yes, and we're not falling into that trap :-)
I would like to see a proof of that... Because this is the trap that I see
growing before our noses: Lua was introduced in RTT for the sole purpose of
doing Coordination, not needing much "data processing" capabilities at all.
Now, the trend is growing to use Lua for a very different purpose, namely
as the scripting language for doing dynamci deployment. And it is via this
backdoor that the "featuritis" creeps in. Please, let's use another
language for the deployment scripting! Nothing wroing with Python there,
since there is no hard realtime need. Also nothing wrong with Java, since
that's where "the big masses" are (including Eclipse support...).
> Markus
Herman
lua wishlist
On Fri, May 27, 2011 at 11:50:01AM +0200, Herman Bruyninckx wrote:
> On Fri, 27 May 2011, Markus Klotzbuecher wrote:
>
> > On Thu, May 26, 2011 at 07:10:21PM +0200, Herman Bruyninckx wrote:
> >> On Thu, 26 May 2011, Dominick Vanthienen wrote:
> >>
> >>> hi,
> >>>
> >>> i've "lua-fied" allmost everything of my current project
> >>> but...
> >>> *I want to set an attribute in my statemachines, which is currently unsupported?! (only properties, but I don't want to change it to a property)
> >>> something like:
> >>> CMWyGlobal = peertable.Scene:getAttribute("CartesianMotion_Wy_global")
> >>> CMWyGlobal:set(1.0)
> >>> *in the old rtt syntax I could initialize a kdl rotationmatrix with RPY angles like: kdl_rot=KDL.Rotation(3.14159265,0.0,1.57)
> >>> but this isn't possible with lua, correct?
> >>> You have to give all matrix values:
> >>> kdl_rot:fromtab( {X_z=0,Z_y=1,Y_y=-0.000796327,X_y=0,Y_z=1,Z_z=0.000796327,Y_x=0,Z_x=0,X_x=-1} )
> >>> (which are btw ordered in a strange way if you print the value (like above))
> >>>
> >>> Can I put some feature requests somewhere?
> >>
> >> Please, don't ask the Lua maintainer to turn the Lua support in Orocos into
> >> a full-fledged scripting language, kitchen sink included! I don't like to
> >> see the project go there: Lua should do Coordination, and nothing more. All
> >> "useful stuff" should be done by calling non-Lua functionalities, not by
> >> extending Lua to copy that stuff...
> >
> > Exactly! Thats the Lua philosophy!
> >
> >> For example: the Coordination should _not_ do data communication, let alone
> >> encode algorithms that compute when to fire events or transition states.
> >> All these computations should reside in "computational slaves" (hopefully
> >> the components that _are_ already there computing the functionality in the
> >> system!), and not in the FSM.
> >
> > Yes, Coordination delegates the computations. However, here Nick is
> > only using Coordination to do initial ocnfiguration, hence the need to
> > set an attribute.
> >
> >> I've seen way too many projects loose there competitive advantage by trying
> >> to hit every nail by the (nice but limited, by design!) hammer they have...
> >
> > Yes, and we're not falling into that trap :-)
>
> I would like to see a proof of that... Because this is the trap that I see
> growing before our noses: Lua was introduced in RTT for the sole purpose of
> doing Coordination, not needing much "data processing" capabilities at all.
> Now, the trend is growing to use Lua for a very different purpose, namely
> as the scripting language for doing dynamci deployment. And it is via this
Coordination and dynamic deployment are strongly related. For this
reason the "mechanism" to support coordination (like starting and
stopping components, (re) connecting ports etc.) are also suitable for
deployment. The nice thing about implementing DSLs in scripting
languages like Lua or Ruby is that new solutions can be explored
_without_ bloating core RTT.
> backdoor that the "featuritis" creeps in. Please, let's use another
> language for the deployment scripting! Nothing wroing with Python there,
> since there is no hard realtime need. Also nothing wrong with Java, since
> that's where "the big masses" are (including Eclipse support...).
I disagree that using Python or Java would have any advantage
here. These are only "other" general purpose languages and adding
bindings for them would be a lot of work with no real gain. On the
other side I think it would be beneficial to use a standardized model
of deployment supported by Eclipse. But that's a question about the
right model, not the right language.
Markus
lua wishlist
On Fri, 27 May 2011, Markus Klotzbuecher wrote:
> On Fri, May 27, 2011 at 11:50:01AM +0200, Herman Bruyninckx wrote:
>> On Fri, 27 May 2011, Markus Klotzbuecher wrote:
>>
>>> On Thu, May 26, 2011 at 07:10:21PM +0200, Herman Bruyninckx wrote:
>>>> On Thu, 26 May 2011, Dominick Vanthienen wrote:
>>>>
>>>>> hi,
>>>>>
>>>>> i've "lua-fied" allmost everything of my current project
>>>>> but...
>>>>> *I want to set an attribute in my statemachines, which is currently unsupported?! (only properties, but I don't want to change it to a property)
>>>>> something like:
>>>>> CMWyGlobal = peertable.Scene:getAttribute("CartesianMotion_Wy_global")
>>>>> CMWyGlobal:set(1.0)
>>>>> *in the old rtt syntax I could initialize a kdl rotationmatrix with RPY angles like: kdl_rot=KDL.Rotation(3.14159265,0.0,1.57)
>>>>> but this isn't possible with lua, correct?
>>>>> You have to give all matrix values:
>>>>> kdl_rot:fromtab( {X_z=0,Z_y=1,Y_y=-0.000796327,X_y=0,Y_z=1,Z_z=0.000796327,Y_x=0,Z_x=0,X_x=-1} )
>>>>> (which are btw ordered in a strange way if you print the value (like above))
>>>>>
>>>>> Can I put some feature requests somewhere?
>>>>
>>>> Please, don't ask the Lua maintainer to turn the Lua support in Orocos into
>>>> a full-fledged scripting language, kitchen sink included! I don't like to
>>>> see the project go there: Lua should do Coordination, and nothing more. All
>>>> "useful stuff" should be done by calling non-Lua functionalities, not by
>>>> extending Lua to copy that stuff...
>>>
>>> Exactly! Thats the Lua philosophy!
>>>
>>>> For example: the Coordination should _not_ do data communication, let alone
>>>> encode algorithms that compute when to fire events or transition states.
>>>> All these computations should reside in "computational slaves" (hopefully
>>>> the components that _are_ already there computing the functionality in the
>>>> system!), and not in the FSM.
>>>
>>> Yes, Coordination delegates the computations. However, here Nick is
>>> only using Coordination to do initial ocnfiguration, hence the need to
>>> set an attribute.
>>>
>>>> I've seen way too many projects loose there competitive advantage by trying
>>>> to hit every nail by the (nice but limited, by design!) hammer they have...
>>>
>>> Yes, and we're not falling into that trap :-)
>>
>> I would like to see a proof of that... Because this is the trap that I see
>> growing before our noses: Lua was introduced in RTT for the sole purpose of
>> doing Coordination, not needing much "data processing" capabilities at all.
>> Now, the trend is growing to use Lua for a very different purpose, namely
>> as the scripting language for doing dynamci deployment. And it is via this
>
> Coordination and dynamic deployment are strongly related. For this
> reason the "mechanism" to support coordination (like starting and
> stopping components, (re) connecting ports etc.) are also suitable for
> deployment. The nice thing about implementing DSLs in scripting
> languages like Lua or Ruby is that new solutions can be explored
> _without_ bloating core RTT.
As long as you stick to the DSL that does the FSM, I am fully with you. But
as soon as you start adding 'data operations', I am not! I want to have a
DSL that can be formally verified, from which code can be generated, and
that has no possible side effects.
What you are now supporting users to add is against all these design
specifications...
>> backdoor that the "featuritis" creeps in. Please, let's use another
>> language for the deployment scripting! Nothing wroing with Python there,
>> since there is no hard realtime need. Also nothing wrong with Java, since
>> that's where "the big masses" are (including Eclipse support...).
>
> I disagree that using Python or Java would have any advantage
> here. These are only "other" general purpose languages and adding
> bindings for them would be a lot of work with no real gain. On the
> other side I think it would be beneficial to use a standardized model
> of deployment supported by Eclipse. But that's a question about the
> right model, not the right language.
Both. For users like Nick, the language _is_ the model. So, let's not make
it so damned easy for them to screw up the model, by adding "stuff" to the
DSL meta language.
> Markus
Herman
lua wishlist
On Fri, May 27, 2011 at 12:39:53PM +0200, Herman Bruyninckx wrote:
> On Fri, 27 May 2011, Markus Klotzbuecher wrote:
> > On Fri, May 27, 2011 at 11:50:01AM +0200, Herman Bruyninckx wrote:
> >> On Fri, 27 May 2011, Markus Klotzbuecher wrote:
> >>> On Thu, May 26, 2011 at 07:10:21PM +0200, Herman Bruyninckx wrote:
...
> >>>> I've seen way too many projects loose there competitive advantage by trying
> >>>> to hit every nail by the (nice but limited, by design!) hammer they have...
> >>>
> >>> Yes, and we're not falling into that trap :-)
> >>
> >> I would like to see a proof of that... Because this is the trap that I see
> >> growing before our noses: Lua was introduced in RTT for the sole purpose of
> >> doing Coordination, not needing much "data processing" capabilities at all.
> >> Now, the trend is growing to use Lua for a very different purpose, namely
> >> as the scripting language for doing dynamci deployment. And it is via this
> >
> > Coordination and dynamic deployment are strongly related. For this
> > reason the "mechanism" to support coordination (like starting and
> > stopping components, (re) connecting ports etc.) are also suitable for
> > deployment. The nice thing about implementing DSLs in scripting
> > languages like Lua or Ruby is that new solutions can be explored
> > _without_ bloating core RTT.
>
> As long as you stick to the DSL that does the FSM, I am fully with you. But
> as soon as you start adding 'data operations', I am not! I want to have a
How do you define data operations? If you mean accessing and modifying
data objects, then how could a Statemachine do anything useful
without? Almost any coordination needs to invoke some operation with
some arguments... moveTo(pos), sendevent(event) etc.
> DSL that can be formally verified, from which code can be generated, and
> that has no possible side effects.
> What you are now supporting users to add is against all these design
> specifications...
>
> >> backdoor that the "featuritis" creeps in. Please, let's use another
> >> language for the deployment scripting! Nothing wroing with Python there,
> >> since there is no hard realtime need. Also nothing wrong with Java, since
> >> that's where "the big masses" are (including Eclipse support...).
> >
> > I disagree that using Python or Java would have any advantage
> > here. These are only "other" general purpose languages and adding
> > bindings for them would be a lot of work with no real gain. On the
> > other side I think it would be beneficial to use a standardized model
> > of deployment supported by Eclipse. But that's a question about the
> > right model, not the right language.
>
> Both. For users like Nick, the language _is_ the model. So, let's not make
> it so damned easy for them to screw up the model, by adding "stuff" to the
> DSL meta language.
But both are separate: the FSM DSL is (indentionally!) independent and
agnostic of RTT. It may use the primitives provided by the framework
bindings. If is is bad practice to use a certain primitive (which
could indeed be the case!) the constraint to prevent this should not
be added at either of the _mechanisms_ FSM-DSL or rttlua bindings;
here we should follow the Unix best practice:
"UNIX was not designed to stop you from doing stupid things, because
that would also stop you from doing clever things." - Doug Gwyn
The right place for constraining the user, IMHO, would be the
graphical modeling toolchain.
Would you agree?
Markus
lua wishlist
On Fri, 27 May 2011, Markus Klotzbuecher wrote:
> On Fri, May 27, 2011 at 12:39:53PM +0200, Herman Bruyninckx wrote:
>> On Fri, 27 May 2011, Markus Klotzbuecher wrote:
>>> On Fri, May 27, 2011 at 11:50:01AM +0200, Herman Bruyninckx wrote:
>>>> On Fri, 27 May 2011, Markus Klotzbuecher wrote:
>>>>> On Thu, May 26, 2011 at 07:10:21PM +0200, Herman Bruyninckx wrote:
> ...
>>>>>> I've seen way too many projects loose there competitive advantage by trying
>>>>>> to hit every nail by the (nice but limited, by design!) hammer they have...
>>>>>
>>>>> Yes, and we're not falling into that trap :-)
>>>>
>>>> I would like to see a proof of that... Because this is the trap that I see
>>>> growing before our noses: Lua was introduced in RTT for the sole purpose of
>>>> doing Coordination, not needing much "data processing" capabilities at all.
>>>> Now, the trend is growing to use Lua for a very different purpose, namely
>>>> as the scripting language for doing dynamci deployment. And it is via this
>>>
>>> Coordination and dynamic deployment are strongly related. For this
>>> reason the "mechanism" to support coordination (like starting and
>>> stopping components, (re) connecting ports etc.) are also suitable for
>>> deployment. The nice thing about implementing DSLs in scripting
>>> languages like Lua or Ruby is that new solutions can be explored
>>> _without_ bloating core RTT.
>>
>> As long as you stick to the DSL that does the FSM, I am fully with you. But
>> as soon as you start adding 'data operations', I am not! I want to have a
>
> How do you define data operations? If you mean accessing and modifying
> data objects, then how could a Statemachine do anything useful
> without? Almost any coordination needs to invoke some operation with
> some arguments... moveTo(pos), sendevent(event) etc.
No: it should send out _events_ that let other components do these
things, or configure them.
>> DSL that can be formally verified, from which code can be generated, and
>> that has no possible side effects.
>> What you are now supporting users to add is against all these design
>> specifications...
>>
>>>> backdoor that the "featuritis" creeps in. Please, let's use another
>>>> language for the deployment scripting! Nothing wroing with Python there,
>>>> since there is no hard realtime need. Also nothing wrong with Java, since
>>>> that's where "the big masses" are (including Eclipse support...).
>>>
>>> I disagree that using Python or Java would have any advantage
>>> here. These are only "other" general purpose languages and adding
>>> bindings for them would be a lot of work with no real gain. On the
>>> other side I think it would be beneficial to use a standardized model
>>> of deployment supported by Eclipse. But that's a question about the
>>> right model, not the right language.
>>
>> Both. For users like Nick, the language _is_ the model. So, let's not make
>> it so damned easy for them to screw up the model, by adding "stuff" to the
>> DSL meta language.
>
> But both are separate: the FSM DSL is (indentionally!) independent and
> agnostic of RTT. It may use the primitives provided by the framework
> bindings. If is is bad practice to use a certain primitive (which
> could indeed be the case!) the constraint to prevent this should not
> be added at either of the _mechanisms_ FSM-DSL or rttlua bindings;
> here we should follow the Unix best practice:
>
> "UNIX was not designed to stop you from doing stupid things, because
> that would also stop you from doing clever things." - Doug Gwyn
Hence, UNIX _never_ made it into MDE toolchains... The robotics world is
a bit (too) full of guys-on-UNIX-steroids... UNIX worked well 40 years ago.
It still does, but not in an MDE world.
> The right place for constraining the user, IMHO, would be the
> graphical modeling toolchain.
>
> Would you agree?
That is the easiest part yes. But this toolchaain will be practically
useless since we stimulate all the functionality contributors to screw the
modelling separations...
> Markus
Herman
lua wishlist
On Sat, May 28, 2011 at 12:21:47AM +0200, Herman Bruyninckx wrote:
> On Fri, 27 May 2011, Markus Klotzbuecher wrote:
>
> > On Fri, May 27, 2011 at 12:39:53PM +0200, Herman Bruyninckx wrote:
> >> On Fri, 27 May 2011, Markus Klotzbuecher wrote:
> >>> On Fri, May 27, 2011 at 11:50:01AM +0200, Herman Bruyninckx wrote:
> >>>> On Fri, 27 May 2011, Markus Klotzbuecher wrote:
> >>>>> On Thu, May 26, 2011 at 07:10:21PM +0200, Herman Bruyninckx wrote:
> > ...
> >>>>>> I've seen way too many projects loose there competitive advantage by trying
> >>>>>> to hit every nail by the (nice but limited, by design!) hammer they have...
> >>>>>
> >>>>> Yes, and we're not falling into that trap :-)
> >>>>
> >>>> I would like to see a proof of that... Because this is the trap that I see
> >>>> growing before our noses: Lua was introduced in RTT for the sole purpose of
> >>>> doing Coordination, not needing much "data processing" capabilities at all.
> >>>> Now, the trend is growing to use Lua for a very different purpose, namely
> >>>> as the scripting language for doing dynamci deployment. And it is via this
> >>>
> >>> Coordination and dynamic deployment are strongly related. For this
> >>> reason the "mechanism" to support coordination (like starting and
> >>> stopping components, (re) connecting ports etc.) are also suitable for
> >>> deployment. The nice thing about implementing DSLs in scripting
> >>> languages like Lua or Ruby is that new solutions can be explored
> >>> _without_ bloating core RTT.
> >>
> >> As long as you stick to the DSL that does the FSM, I am fully with you. But
> >> as soon as you start adding 'data operations', I am not! I want to have a
> >
> > How do you define data operations? If you mean accessing and modifying
> > data objects, then how could a Statemachine do anything useful
> > without? Almost any coordination needs to invoke some operation with
> > some arguments... moveTo(pos), sendevent(event) etc.
>
> No: it should send out _events_ that let other components do these
> things, or configure them.
You know I agree and would prefer FSM to communicate purely
event/message based, however in practice this is difficult because of
the following reasons:
1. most of the existing components are not implemented this way, but
offer synchronous or asynchronous operations. Of course these can
be refactored and indeed several already have been, nevertheless it
must be possible to deal with legacy.
2. multi-argument operations require definition/generation of new
types: take for instance a simple trajectory generator which takes
three arguments: start and end pose and a duration. To turn this
call into a "command event" a new type containing these three
fields needs to be defined/implemented/generated. Extra effort,
previously not required.
3. Most importantly, unless you "discretize the world", events will
always carry a "continuous data payload": in the trajectory
generator example the poses and duration. Hence even in a pure
event driven system data operations are necessary.
> >> DSL that can be formally verified, from which code can be generated, and
> >> that has no possible side effects.
> >> What you are now supporting users to add is against all these design
> >> specifications...
> >>
> >>>> backdoor that the "featuritis" creeps in. Please, let's use another
> >>>> language for the deployment scripting! Nothing wroing with Python there,
> >>>> since there is no hard realtime need. Also nothing wrong with Java, since
> >>>> that's where "the big masses" are (including Eclipse support...).
> >>>
> >>> I disagree that using Python or Java would have any advantage
> >>> here. These are only "other" general purpose languages and adding
> >>> bindings for them would be a lot of work with no real gain. On the
> >>> other side I think it would be beneficial to use a standardized model
> >>> of deployment supported by Eclipse. But that's a question about the
> >>> right model, not the right language.
> >>
> >> Both. For users like Nick, the language _is_ the model. So, let's not make
> >> it so damned easy for them to screw up the model, by adding "stuff" to the
> >> DSL meta language.
> >
> > But both are separate: the FSM DSL is (indentionally!) independent and
> > agnostic of RTT. It may use the primitives provided by the framework
> > bindings. If is is bad practice to use a certain primitive (which
> > could indeed be the case!) the constraint to prevent this should not
> > be added at either of the _mechanisms_ FSM-DSL or rttlua bindings;
> > here we should follow the Unix best practice:
> >
> > "UNIX was not designed to stop you from doing stupid things, because
> > that would also stop you from doing clever things." - Doug Gwyn
>
> Hence, UNIX _never_ made it into MDE toolchains... The robotics world is
> a bit (too) full of guys-on-UNIX-steroids... UNIX worked well 40 years ago.
> It still does, but not in an MDE world.
>
> > The right place for constraining the user, IMHO, would be the
> > graphical modeling toolchain.
> >
> > Would you agree?
>
> That is the easiest part yes. But this toolchaain will be practically
> useless since we stimulate all the functionality contributors to screw the
> modelling separations...
It is trivially possible to restrict the primitives that can be used
in a DSL. However, it is not yet clear to me which ones "screw the
separations" and this should be excluded.
Markus
lua wishlist
On Sat, 28 May 2011, Markus Klotzbuecher wrote:
> On Sat, May 28, 2011 at 12:21:47AM +0200, Herman Bruyninckx wrote:
>> On Fri, 27 May 2011, Markus Klotzbuecher wrote:
>>
>>> On Fri, May 27, 2011 at 12:39:53PM +0200, Herman Bruyninckx wrote:
>>>> On Fri, 27 May 2011, Markus Klotzbuecher wrote:
>>>>> On Fri, May 27, 2011 at 11:50:01AM +0200, Herman Bruyninckx wrote:
>>>>>> On Fri, 27 May 2011, Markus Klotzbuecher wrote:
>>>>>>> On Thu, May 26, 2011 at 07:10:21PM +0200, Herman Bruyninckx wrote:
>>> ...
>>>>>>>> I've seen way too many projects loose there competitive advantage by trying
>>>>>>>> to hit every nail by the (nice but limited, by design!) hammer they have...
>>>>>>>
>>>>>>> Yes, and we're not falling into that trap :-)
>>>>>>
>>>>>> I would like to see a proof of that... Because this is the trap that I see
>>>>>> growing before our noses: Lua was introduced in RTT for the sole purpose of
>>>>>> doing Coordination, not needing much "data processing" capabilities at all.
>>>>>> Now, the trend is growing to use Lua for a very different purpose, namely
>>>>>> as the scripting language for doing dynamci deployment. And it is via this
>>>>>
>>>>> Coordination and dynamic deployment are strongly related. For this
>>>>> reason the "mechanism" to support coordination (like starting and
>>>>> stopping components, (re) connecting ports etc.) are also suitable for
>>>>> deployment. The nice thing about implementing DSLs in scripting
>>>>> languages like Lua or Ruby is that new solutions can be explored
>>>>> _without_ bloating core RTT.
>>>>
>>>> As long as you stick to the DSL that does the FSM, I am fully with you. But
>>>> as soon as you start adding 'data operations', I am not! I want to have a
>>>
>>> How do you define data operations? If you mean accessing and modifying
>>> data objects, then how could a Statemachine do anything useful
>>> without? Almost any coordination needs to invoke some operation with
>>> some arguments... moveTo(pos), sendevent(event) etc.
>>
>> No: it should send out _events_ that let other components do these
>> things, or configure them.
>
> You know I agree and would prefer FSM to communicate purely
> event/message based, however in practice this is difficult because of
> the following reasons:
>
> 1. most of the existing components are not implemented this way, but
> offer synchronous or asynchronous operations. Of course these can
> be refactored and indeed several already have been, nevertheless it
> must be possible to deal with legacy.
Legacy is a reality indeed. But dealing with legacy should not, I repeat,
not, compromise the MDE future of Orocos. In that case, let's stop now,
because the project is going to be dead anyway in a couple of more
legacy-before-everything years.
So, the real question we face is: how to keep both goals nicely
separated..? The obvious answer is:
1. support legacy for your current major version;
2. make sure the legacy does not trickle down in your new major version.
3. be clever enough to do both 1. and 2., without making the refactoring
from 1. to 2. impossible.
You are helping users with 1., I am trying to scare away everyone from 1.,
because of 2. We should both work together to provide a "this is how you
_should_ do it" answer to all requesters for 1. Which we have to do for 3.
anyway.
At the end of this message, there is a concrete suggestion about 3.
> 2. multi-argument operations require definition/generation of new
> types: take for instance a simple trajectory generator which takes
> three arguments: start and end pose and a duration. To turn this
> call into a "command event" a new type containing these three
> fields needs to be defined/implemented/generated. Extra effort,
> previously not required.
So, events should carry no data! The data is in the data flows, the events
in the event flow. A Coordination state machine component should only work
with event flows. In other words, a Coordinator should never exchange any
"commands" with whichever other Component.
> 3. Most importantly, unless you "discretize the world", events will
> always carry a "continuous data payload": in the trajectory
> generator example the poses and duration. Hence even in a pure
> event driven system data operations are necessary.
Of course! But those data operations are on the data flows between
Computational components, _not_ on the event flows between the Coordinator
and the Computational components. _That_ is separation of concerns! :-)
>>>> DSL that can be formally verified, from which code can be generated, and
>>>> that has no possible side effects.
>>>> What you are now supporting users to add is against all these design
>>>> specifications...
>>>>
>>>>>> backdoor that the "featuritis" creeps in. Please, let's use another
>>>>>> language for the deployment scripting! Nothing wroing with Python there,
>>>>>> since there is no hard realtime need. Also nothing wrong with Java, since
>>>>>> that's where "the big masses" are (including Eclipse support...).
>>>>>
>>>>> I disagree that using Python or Java would have any advantage
>>>>> here. These are only "other" general purpose languages and adding
>>>>> bindings for them would be a lot of work with no real gain. On the
>>>>> other side I think it would be beneficial to use a standardized model
>>>>> of deployment supported by Eclipse. But that's a question about the
>>>>> right model, not the right language.
>>>>
>>>> Both. For users like Nick, the language _is_ the model. So, let's not make
>>>> it so damned easy for them to screw up the model, by adding "stuff" to the
>>>> DSL meta language.
>>>
>>> But both are separate: the FSM DSL is (indentionally!) independent and
>>> agnostic of RTT. It may use the primitives provided by the framework
>>> bindings. If is is bad practice to use a certain primitive (which
>>> could indeed be the case!) the constraint to prevent this should not
>>> be added at either of the _mechanisms_ FSM-DSL or rttlua bindings;
>>> here we should follow the Unix best practice:
>>>
>>> "UNIX was not designed to stop you from doing stupid things, because
>>> that would also stop you from doing clever things." - Doug Gwyn
>>
>> Hence, UNIX _never_ made it into MDE toolchains... The robotics world is
>> a bit (too) full of guys-on-UNIX-steroids... UNIX worked well 40 years ago.
>> It still does, but not in an MDE world.
>>
>>> The right place for constraining the user, IMHO, would be the
>>> graphical modeling toolchain.
>>>
>>> Would you agree?
>>
>> That is the easiest part yes. But this toolchaain will be practically
>> useless since we stimulate all the functionality contributors to screw the
>> modelling separations...
>
> It is trivially possible to restrict the primitives that can be used
> in a DSL.
Yes. So we should make these things clear, and provide the explicit
software support for it.
> However, it is not yet clear to me which ones "screw the
> separations" and this should be excluded.
The 'data carrying events' are the ones that screw things up for keeping
the Coordination separated from the Computations.
In addition, the current situation, users (and obviously also most
developers) do not see the distinction between "Lua as a Coordination DSL"
and "Lua as an RTT scripting language", and that's also screwing up things
for the former.
Concrete constructive suggestion:
- let's start formalizing the Coordination rFSM now, in such a way that a
tool can check whether only "pure" coordination language constructs are
being used.
- let's write a documentation document that explains the differences
between "Lua as a Coordination DSL" and "Lua as an RTT scripting
language", including guidelines for users about how to work with both.
This document will be core of our PhD anyway! (Otherwise, nobody will be
impressed by it :-)
It is also time to carry the discussion over to orocos-dev, in the form of
the first draft of the mentioned document, with an invitation for comments.
A second step could be to use the result as a RFC for the
Robot Engineering Task Force <https://retf.info />...
> Markus
Herman
lua wishlist [continuted from orocos-users]
On Sat, May 28, 2011 at 05:48:06PM +0200, Herman Bruyninckx wrote:
> On Sat, 28 May 2011, Markus Klotzbuecher wrote:
>
> > On Sat, May 28, 2011 at 12:21:47AM +0200, Herman Bruyninckx wrote:
> >> On Fri, 27 May 2011, Markus Klotzbuecher wrote:
> >>
> >>> On Fri, May 27, 2011 at 12:39:53PM +0200, Herman Bruyninckx wrote:
> >>>> On Fri, 27 May 2011, Markus Klotzbuecher wrote:
> >>>>> On Fri, May 27, 2011 at 11:50:01AM +0200, Herman Bruyninckx wrote:
> >>>>>> On Fri, 27 May 2011, Markus Klotzbuecher wrote:
> >>>>>>> On Thu, May 26, 2011 at 07:10:21PM +0200, Herman Bruyninckx wrote:
> >>> ...
> >>>>>>>> I've seen way too many projects loose there competitive advantage by trying
> >>>>>>>> to hit every nail by the (nice but limited, by design!) hammer they have...
> >>>>>>>
> >>>>>>> Yes, and we're not falling into that trap :-)
> >>>>>>
> >>>>>> I would like to see a proof of that... Because this is the trap that I see
> >>>>>> growing before our noses: Lua was introduced in RTT for the sole purpose of
> >>>>>> doing Coordination, not needing much "data processing" capabilities at all.
> >>>>>> Now, the trend is growing to use Lua for a very different purpose, namely
> >>>>>> as the scripting language for doing dynamci deployment. And it is via this
> >>>>>
> >>>>> Coordination and dynamic deployment are strongly related. For this
> >>>>> reason the "mechanism" to support coordination (like starting and
> >>>>> stopping components, (re) connecting ports etc.) are also suitable for
> >>>>> deployment. The nice thing about implementing DSLs in scripting
> >>>>> languages like Lua or Ruby is that new solutions can be explored
> >>>>> _without_ bloating core RTT.
> >>>>
> >>>> As long as you stick to the DSL that does the FSM, I am fully with you. But
> >>>> as soon as you start adding 'data operations', I am not! I want to have a
> >>>
> >>> How do you define data operations? If you mean accessing and modifying
> >>> data objects, then how could a Statemachine do anything useful
> >>> without? Almost any coordination needs to invoke some operation with
> >>> some arguments... moveTo(pos), sendevent(event) etc.
> >>
> >> No: it should send out _events_ that let other components do these
> >> things, or configure them.
> >
> > You know I agree and would prefer FSM to communicate purely
> > event/message based, however in practice this is difficult because of
> > the following reasons:
> >
> > 1. most of the existing components are not implemented this way, but
> > offer synchronous or asynchronous operations. Of course these can
> > be refactored and indeed several already have been, nevertheless it
> > must be possible to deal with legacy.
>
> Legacy is a reality indeed. But dealing with legacy should not, I repeat,
> not, compromise the MDE future of Orocos. In that case, let's stop now,
> because the project is going to be dead anyway in a couple of more
> legacy-before-everything years.
>
> So, the real question we face is: how to keep both goals nicely
> separated..? The obvious answer is:
> 1. support legacy for your current major version;
> 2. make sure the legacy does not trickle down in your new major version.
> 3. be clever enough to do both 1. and 2., without making the refactoring
> from 1. to 2. impossible.
>
> You are helping users with 1., I am trying to scare away everyone from 1.,
> because of 2. We should both work together to provide a "this is how you
> _should_ do it" answer to all requesters for 1. Which we have to do for 3.
> anyway.
Ok, fine! The challenge with this however, is to convince the
substantial group of people which strongly disagrees that a particular
primitive actually is legacy, and not a really neat feature.
> At the end of this message, there is a concrete suggestion about 3.
>
> > 2. multi-argument operations require definition/generation of new
> > types: take for instance a simple trajectory generator which takes
> > three arguments: start and end pose and a duration. To turn this
> > call into a "command event" a new type containing these three
> > fields needs to be defined/implemented/generated. Extra effort,
> > previously not required.
>
> So, events should carry no data! The data is in the data flows, the events
> in the event flow. A Coordination state machine component should only work
> with event flows. In other words, a Coordinator should never exchange any
> "commands" with whichever other Component.
>
> > 3. Most importantly, unless you "discretize the world", events will
> > always carry a "continuous data payload": in the trajectory
> > generator example the poses and duration. Hence even in a pure
> > event driven system data operations are necessary.
>
> Of course! But those data operations are on the data flows between
> Computational components, _not_ on the event flows between the Coordinator
> and the Computational components. _That_ is separation of concerns! :-)
I am not convinced that a Coordination FSM can only coordinate using
pure events (by pure i mean: carrying only identity, nothing more) and
be practically useful. But we can easily find out who is right by
looking at the various existing coordination FSM (which do use and
manipulate data) and see how well these could be refactored according
to your suggestion :-)
> >>>> DSL that can be formally verified, from which code can be generated, and
> >>>> that has no possible side effects.
> >>>> What you are now supporting users to add is against all these design
> >>>> specifications...
> >>>>
> >>>>>> backdoor that the "featuritis" creeps in. Please, let's use another
> >>>>>> language for the deployment scripting! Nothing wroing with Python there,
> >>>>>> since there is no hard realtime need. Also nothing wrong with Java, since
> >>>>>> that's where "the big masses" are (including Eclipse support...).
> >>>>>
> >>>>> I disagree that using Python or Java would have any advantage
> >>>>> here. These are only "other" general purpose languages and adding
> >>>>> bindings for them would be a lot of work with no real gain. On the
> >>>>> other side I think it would be beneficial to use a standardized model
> >>>>> of deployment supported by Eclipse. But that's a question about the
> >>>>> right model, not the right language.
> >>>>
> >>>> Both. For users like Nick, the language _is_ the model. So, let's not make
> >>>> it so damned easy for them to screw up the model, by adding "stuff" to the
> >>>> DSL meta language.
> >>>
> >>> But both are separate: the FSM DSL is (indentionally!) independent and
> >>> agnostic of RTT. It may use the primitives provided by the framework
> >>> bindings. If is is bad practice to use a certain primitive (which
> >>> could indeed be the case!) the constraint to prevent this should not
> >>> be added at either of the _mechanisms_ FSM-DSL or rttlua bindings;
> >>> here we should follow the Unix best practice:
> >>>
> >>> "UNIX was not designed to stop you from doing stupid things, because
> >>> that would also stop you from doing clever things." - Doug Gwyn
> >>
> >> Hence, UNIX _never_ made it into MDE toolchains... The robotics world is
> >> a bit (too) full of guys-on-UNIX-steroids... UNIX worked well 40 years ago.
> >> It still does, but not in an MDE world.
> >>
> >>> The right place for constraining the user, IMHO, would be the
> >>> graphical modeling toolchain.
> >>>
> >>> Would you agree?
> >>
> >> That is the easiest part yes. But this toolchaain will be practically
> >> useless since we stimulate all the functionality contributors to screw the
> >> modelling separations...
> >
> > It is trivially possible to restrict the primitives that can be used
> > in a DSL.
>
> Yes. So we should make these things clear, and provide the explicit
> software support for it.
>
> > However, it is not yet clear to me which ones "screw the
> > separations" and this should be excluded.
>
> The 'data carrying events' are the ones that screw things up for keeping
> the Coordination separated from the Computations.
> In addition, the current situation, users (and obviously also most
> developers) do not see the distinction between "Lua as a Coordination DSL"
> and "Lua as an RTT scripting language", and that's also screwing up things
> for the former.
The distinction might indeed not be so clear. However Lua is not a
"Coordination DSL"! There are three orthogonal things here:
1. rFSM: which _is_ a Coordination DSL (built in Lua for some
reasons) and can make use of bindings to various robotic
frameworks such as rttlua but also roslua (see below).
2. Lua: a general purpose scripting language which focusses on
embeddability and extensibilty and is suitable for building DSL.
3. the rttlua bindings which allow to use a subset of the RTT
concepts within Lua.
> Concrete constructive suggestion:
> - let's start formalizing the Coordination rFSM now, in such a way that a
> tool can check whether only "pure" coordination language constructs are
> being used.
> - let's write a documentation document that explains the differences
> between "Lua as a Coordination DSL" and "Lua as an RTT scripting
> language", including guidelines for users about how to work with both.
In terms of documentation I have started to document "good use" in
terms of the LuaCookbook, but it's an ongoing effort.
> This document will be core of our PhD anyway! (Otherwise, nobody will be
> impressed by it :-)
Agreed :-)
Best regards
Markus
lua wishlist [continuted from orocos-users]
On Mon, 30 May 2011, Markus Klotzbuecher wrote:
> On Sat, May 28, 2011 at 05:48:06PM +0200, Herman Bruyninckx wrote:
>> On Sat, 28 May 2011, Markus Klotzbuecher wrote:
>>
>>> On Sat, May 28, 2011 at 12:21:47AM +0200, Herman Bruyninckx wrote:
>>>> On Fri, 27 May 2011, Markus Klotzbuecher wrote:
>>>>
>>>>> On Fri, May 27, 2011 at 12:39:53PM +0200, Herman Bruyninckx wrote:
>>>>>> On Fri, 27 May 2011, Markus Klotzbuecher wrote:
>>>>>>> On Fri, May 27, 2011 at 11:50:01AM +0200, Herman Bruyninckx wrote:
>>>>>>>> On Fri, 27 May 2011, Markus Klotzbuecher wrote:
>>>>>>>>> On Thu, May 26, 2011 at 07:10:21PM +0200, Herman Bruyninckx wrote:
>>>>> ...
>>>>>>>>>> I've seen way too many projects loose there competitive advantage by trying
>>>>>>>>>> to hit every nail by the (nice but limited, by design!) hammer they have...
>>>>>>>>>
>>>>>>>>> Yes, and we're not falling into that trap :-)
>>>>>>>>
>>>>>>>> I would like to see a proof of that... Because this is the trap that I see
>>>>>>>> growing before our noses: Lua was introduced in RTT for the sole purpose of
>>>>>>>> doing Coordination, not needing much "data processing" capabilities at all.
>>>>>>>> Now, the trend is growing to use Lua for a very different purpose, namely
>>>>>>>> as the scripting language for doing dynamci deployment. And it is via this
>>>>>>>
>>>>>>> Coordination and dynamic deployment are strongly related. For this
>>>>>>> reason the "mechanism" to support coordination (like starting and
>>>>>>> stopping components, (re) connecting ports etc.) are also suitable for
>>>>>>> deployment. The nice thing about implementing DSLs in scripting
>>>>>>> languages like Lua or Ruby is that new solutions can be explored
>>>>>>> _without_ bloating core RTT.
>>>>>>
>>>>>> As long as you stick to the DSL that does the FSM, I am fully with you. But
>>>>>> as soon as you start adding 'data operations', I am not! I want to have a
>>>>>
>>>>> How do you define data operations? If you mean accessing and modifying
>>>>> data objects, then how could a Statemachine do anything useful
>>>>> without? Almost any coordination needs to invoke some operation with
>>>>> some arguments... moveTo(pos), sendevent(event) etc.
>>>>
>>>> No: it should send out _events_ that let other components do these
>>>> things, or configure them.
>>>
>>> You know I agree and would prefer FSM to communicate purely
>>> event/message based, however in practice this is difficult because of
>>> the following reasons:
>>>
>>> 1. most of the existing components are not implemented this way, but
>>> offer synchronous or asynchronous operations. Of course these can
>>> be refactored and indeed several already have been, nevertheless it
>>> must be possible to deal with legacy.
>>
>> Legacy is a reality indeed. But dealing with legacy should not, I repeat,
>> not, compromise the MDE future of Orocos. In that case, let's stop now,
>> because the project is going to be dead anyway in a couple of more
>> legacy-before-everything years.
>>
>> So, the real question we face is: how to keep both goals nicely
>> separated..? The obvious answer is:
>> 1. support legacy for your current major version;
>> 2. make sure the legacy does not trickle down in your new major version.
>> 3. be clever enough to do both 1. and 2., without making the refactoring
>> from 1. to 2. impossible.
>>
>> You are helping users with 1., I am trying to scare away everyone from 1.,
>> because of 2. We should both work together to provide a "this is how you
>> _should_ do it" answer to all requesters for 1. Which we have to do for 3.
>> anyway.
>
> Ok, fine! The challenge with this however, is to convince the
> substantial group of people which strongly disagrees that a particular
> primitive actually is legacy, and not a really neat feature.
That's a challenge indeed. And the only "weight" I can bring behind my
arguments is that I have made the featuritis error myself too many times,
and I don't want to go there anymore. If the majority of stakeholders in
RTT want to do it differently, they will kill the long-term goals.
I would prefer to have the discussions on technical grounds, so _if_ you
agree on 5C separation of concerns, you _have_ to agree with me that
"Computations" do not belong in "Coordination", don't you? Hence, adding
Lua support for data flow and operations should not be done.
>> At the end of this message, there is a concrete suggestion about 3.
>>
>>> 2. multi-argument operations require definition/generation of new
>>> types: take for instance a simple trajectory generator which takes
>>> three arguments: start and end pose and a duration. To turn this
>>> call into a "command event" a new type containing these three
>>> fields needs to be defined/implemented/generated. Extra effort,
>>> previously not required.
>>
>> So, events should carry no data! The data is in the data flows, the events
>> in the event flow. A Coordination state machine component should only work
>> with event flows. In other words, a Coordinator should never exchange any
>> "commands" with whichever other Component.
>>
>>> 3. Most importantly, unless you "discretize the world", events will
>>> always carry a "continuous data payload": in the trajectory
>>> generator example the poses and duration. Hence even in a pure
>>> event driven system data operations are necessary.
>>
>> Of course! But those data operations are on the data flows between
>> Computational components, _not_ on the event flows between the Coordinator
>> and the Computational components. _That_ is separation of concerns! :-)
>
> I am not convinced that a Coordination FSM can only coordinate using
> pure events (by pure i mean: carrying only identity, nothing more) and
If you mean with "identity" that an event carries a name that identifies
its origin, I agree.
> be practically useful. But we can easily find out who is right by
> looking at the various existing coordination FSM (which do use and
> manipulate data) and see how well these could be refactored according
> to your suggestion :-)
Good!
>>>>>> DSL that can be formally verified, from which code can be generated, and
>>>>>> that has no possible side effects.
>>>>>> What you are now supporting users to add is against all these design
>>>>>> specifications...
>>>>>>
>>>>>>>> backdoor that the "featuritis" creeps in. Please, let's use another
>>>>>>>> language for the deployment scripting! Nothing wroing with Python there,
>>>>>>>> since there is no hard realtime need. Also nothing wrong with Java, since
>>>>>>>> that's where "the big masses" are (including Eclipse support...).
>>>>>>>
>>>>>>> I disagree that using Python or Java would have any advantage
>>>>>>> here. These are only "other" general purpose languages and adding
>>>>>>> bindings for them would be a lot of work with no real gain. On the
>>>>>>> other side I think it would be beneficial to use a standardized model
>>>>>>> of deployment supported by Eclipse. But that's a question about the
>>>>>>> right model, not the right language.
>>>>>>
>>>>>> Both. For users like Nick, the language _is_ the model. So, let's not make
>>>>>> it so damned easy for them to screw up the model, by adding "stuff" to the
>>>>>> DSL meta language.
>>>>>
>>>>> But both are separate: the FSM DSL is (indentionally!) independent and
>>>>> agnostic of RTT. It may use the primitives provided by the framework
>>>>> bindings. If is is bad practice to use a certain primitive (which
>>>>> could indeed be the case!) the constraint to prevent this should not
>>>>> be added at either of the _mechanisms_ FSM-DSL or rttlua bindings;
>>>>> here we should follow the Unix best practice:
>>>>>
>>>>> "UNIX was not designed to stop you from doing stupid things, because
>>>>> that would also stop you from doing clever things." - Doug Gwyn
>>>>
>>>> Hence, UNIX _never_ made it into MDE toolchains... The robotics world is
>>>> a bit (too) full of guys-on-UNIX-steroids... UNIX worked well 40 years ago.
>>>> It still does, but not in an MDE world.
>>>>
>>>>> The right place for constraining the user, IMHO, would be the
>>>>> graphical modeling toolchain.
>>>>>
>>>>> Would you agree?
>>>>
>>>> That is the easiest part yes. But this toolchaain will be practically
>>>> useless since we stimulate all the functionality contributors to screw the
>>>> modelling separations...
>>>
>>> It is trivially possible to restrict the primitives that can be used
>>> in a DSL.
>>
>> Yes. So we should make these things clear, and provide the explicit
>> software support for it.
>>
>>> However, it is not yet clear to me which ones "screw the
>>> separations" and this should be excluded.
>>
>> The 'data carrying events' are the ones that screw things up for keeping
>> the Coordination separated from the Computations.
>> In addition, the current situation, users (and obviously also most
>> developers) do not see the distinction between "Lua as a Coordination DSL"
>> and "Lua as an RTT scripting language", and that's also screwing up things
>> for the former.
>
> The distinction might indeed not be so clear. However Lua is not a
> "Coordination DSL"! There are three orthogonal things here:
>
> 1. rFSM: which _is_ a Coordination DSL (built in Lua for some
> reasons) and can make use of bindings to various robotic
> frameworks such as rttlua but also roslua (see below).
>
> 2. Lua: a general purpose scripting language which focusses on
> embeddability and extensibilty and is suitable for building DSL.
>
> 3. the rttlua bindings which allow to use a subset of the RTT
> concepts within Lua.
Good summary, to which I completely agree. But the users
commenting/requesting on the mailing list do not make this difference: they
just see "Lua", irrespective of the structure that you and I put into the
(to be decoupled) uses of Lua in. Do you have the same feeling?
>> Concrete constructive suggestion:
>> - let's start formalizing the Coordination rFSM now, in such a way that a
>> tool can check whether only "pure" coordination language constructs are
>> being used.
>> - let's write a documentation document that explains the differences
>> between "Lua as a Coordination DSL" and "Lua as an RTT scripting
>> language", including guidelines for users about how to work with both.
>
> In terms of documentation I have started to document "good use" in
> terms of the LuaCookbook, but it's an ongoing effort.
Much appreciated!
>> This document will be core of our PhD anyway! (Otherwise, nobody will be
>> impressed by it :-)
>
> Agreed :-)
>
> Best regards
> Markus
Herman
lua wishlist [continuted from orocos-users]
On Mon, May 30, 2011 at 10:32:37AM +0200, Herman Bruyninckx wrote:
> On Mon, 30 May 2011, Markus Klotzbuecher wrote:
>
> > On Sat, May 28, 2011 at 05:48:06PM +0200, Herman Bruyninckx wrote:
> >> On Sat, 28 May 2011, Markus Klotzbuecher wrote:
> >>
> >>> On Sat, May 28, 2011 at 12:21:47AM +0200, Herman Bruyninckx wrote:
> >>>> On Fri, 27 May 2011, Markus Klotzbuecher wrote:
> >>>>
> >>>>> On Fri, May 27, 2011 at 12:39:53PM +0200, Herman Bruyninckx wrote:
> >>>>>> On Fri, 27 May 2011, Markus Klotzbuecher wrote:
> >>>>>>> On Fri, May 27, 2011 at 11:50:01AM +0200, Herman Bruyninckx wrote:
> >>>>>>>> On Fri, 27 May 2011, Markus Klotzbuecher wrote:
> >>>>>>>>> On Thu, May 26, 2011 at 07:10:21PM +0200, Herman Bruyninckx wrote:
> >>>>> ...
> >>>>>>>>>> I've seen way too many projects loose there competitive advantage by trying
> >>>>>>>>>> to hit every nail by the (nice but limited, by design!) hammer they have...
> >>>>>>>>>
> >>>>>>>>> Yes, and we're not falling into that trap :-)
> >>>>>>>>
> >>>>>>>> I would like to see a proof of that... Because this is the trap that I see
> >>>>>>>> growing before our noses: Lua was introduced in RTT for the sole purpose of
> >>>>>>>> doing Coordination, not needing much "data processing" capabilities at all.
> >>>>>>>> Now, the trend is growing to use Lua for a very different purpose, namely
> >>>>>>>> as the scripting language for doing dynamci deployment. And it is via this
> >>>>>>>
> >>>>>>> Coordination and dynamic deployment are strongly related. For this
> >>>>>>> reason the "mechanism" to support coordination (like starting and
> >>>>>>> stopping components, (re) connecting ports etc.) are also suitable for
> >>>>>>> deployment. The nice thing about implementing DSLs in scripting
> >>>>>>> languages like Lua or Ruby is that new solutions can be explored
> >>>>>>> _without_ bloating core RTT.
> >>>>>>
> >>>>>> As long as you stick to the DSL that does the FSM, I am fully with you. But
> >>>>>> as soon as you start adding 'data operations', I am not! I want to have a
> >>>>>
> >>>>> How do you define data operations? If you mean accessing and modifying
> >>>>> data objects, then how could a Statemachine do anything useful
> >>>>> without? Almost any coordination needs to invoke some operation with
> >>>>> some arguments... moveTo(pos), sendevent(event) etc.
> >>>>
> >>>> No: it should send out _events_ that let other components do these
> >>>> things, or configure them.
> >>>
> >>> You know I agree and would prefer FSM to communicate purely
> >>> event/message based, however in practice this is difficult because of
> >>> the following reasons:
> >>>
> >>> 1. most of the existing components are not implemented this way, but
> >>> offer synchronous or asynchronous operations. Of course these can
> >>> be refactored and indeed several already have been, nevertheless it
> >>> must be possible to deal with legacy.
> >>
> >> Legacy is a reality indeed. But dealing with legacy should not, I repeat,
> >> not, compromise the MDE future of Orocos. In that case, let's stop now,
> >> because the project is going to be dead anyway in a couple of more
> >> legacy-before-everything years.
> >>
> >> So, the real question we face is: how to keep both goals nicely
> >> separated..? The obvious answer is:
> >> 1. support legacy for your current major version;
> >> 2. make sure the legacy does not trickle down in your new major version.
> >> 3. be clever enough to do both 1. and 2., without making the refactoring
> >> from 1. to 2. impossible.
> >>
> >> You are helping users with 1., I am trying to scare away everyone from 1.,
> >> because of 2. We should both work together to provide a "this is how you
> >> _should_ do it" answer to all requesters for 1. Which we have to do for 3.
> >> anyway.
> >
> > Ok, fine! The challenge with this however, is to convince the
> > substantial group of people which strongly disagrees that a particular
> > primitive actually is legacy, and not a really neat feature.
>
> That's a challenge indeed. And the only "weight" I can bring behind my
> arguments is that I have made the featuritis error myself too many times,
> and I don't want to go there anymore. If the majority of stakeholders in
> RTT want to do it differently, they will kill the long-term goals.
>
> I would prefer to have the discussions on technical grounds, so _if_ you
> agree on 5C separation of concerns, you _have_ to agree with me that
> "Computations" do not belong in "Coordination", don't you? Hence, adding
I agree! (... but find the recursiveness of the concept tricky: for a
Coordinator all coordinated entities are computations, even though
these might themselves be sub-ordinate coordinators coordinating
lower-level compuations themselves).
A standard controller component involves coordination:
1. read current pos
2. read desired pos
3. apply control law with user defined parameters
4. write result to port
Apart from 3. this is really intra-component coordination.
> Lua support for data flow and operations should not be done.
I don't agree here: there is a difference between using ports to raise
events and using operations to coordinate components vs. implementing
computations using Lua. I also do not see an why we should treat data
and events differently, the semantics depend on the perspective and
context! For instance a piece of data might only mean "next setpoint"
to a computation, but to a saftey coordinator receiving the same value
at a particular time might signify a serious event requiring immediate
action. Keeping events and data separate would needlessly complicate
such a subsystem.
...
> >>>>>> DSL that can be formally verified, from which code can be generated, and
> >>>>>> that has no possible side effects.
> >>>>>> What you are now supporting users to add is against all these design
> >>>>>> specifications...
> >>>>>>
> >>>>>>>> backdoor that the "featuritis" creeps in. Please, let's use another
> >>>>>>>> language for the deployment scripting! Nothing wroing with Python there,
> >>>>>>>> since there is no hard realtime need. Also nothing wrong with Java, since
> >>>>>>>> that's where "the big masses" are (including Eclipse support...).
> >>>>>>>
> >>>>>>> I disagree that using Python or Java would have any advantage
> >>>>>>> here. These are only "other" general purpose languages and adding
> >>>>>>> bindings for them would be a lot of work with no real gain. On the
> >>>>>>> other side I think it would be beneficial to use a standardized model
> >>>>>>> of deployment supported by Eclipse. But that's a question about the
> >>>>>>> right model, not the right language.
> >>>>>>
> >>>>>> Both. For users like Nick, the language _is_ the model. So, let's not make
> >>>>>> it so damned easy for them to screw up the model, by adding "stuff" to the
> >>>>>> DSL meta language.
> >>>>>
> >>>>> But both are separate: the FSM DSL is (indentionally!) independent and
> >>>>> agnostic of RTT. It may use the primitives provided by the framework
> >>>>> bindings. If is is bad practice to use a certain primitive (which
> >>>>> could indeed be the case!) the constraint to prevent this should not
> >>>>> be added at either of the _mechanisms_ FSM-DSL or rttlua bindings;
> >>>>> here we should follow the Unix best practice:
> >>>>>
> >>>>> "UNIX was not designed to stop you from doing stupid things, because
> >>>>> that would also stop you from doing clever things." - Doug Gwyn
> >>>>
> >>>> Hence, UNIX _never_ made it into MDE toolchains... The robotics world is
> >>>> a bit (too) full of guys-on-UNIX-steroids... UNIX worked well 40 years ago.
> >>>> It still does, but not in an MDE world.
> >>>>
> >>>>> The right place for constraining the user, IMHO, would be the
> >>>>> graphical modeling toolchain.
> >>>>>
> >>>>> Would you agree?
> >>>>
> >>>> That is the easiest part yes. But this toolchaain will be practically
> >>>> useless since we stimulate all the functionality contributors to screw the
> >>>> modelling separations...
> >>>
> >>> It is trivially possible to restrict the primitives that can be used
> >>> in a DSL.
> >>
> >> Yes. So we should make these things clear, and provide the explicit
> >> software support for it.
> >>
> >>> However, it is not yet clear to me which ones "screw the
> >>> separations" and this should be excluded.
> >>
> >> The 'data carrying events' are the ones that screw things up for keeping
> >> the Coordination separated from the Computations.
> >> In addition, the current situation, users (and obviously also most
> >> developers) do not see the distinction between "Lua as a Coordination DSL"
> >> and "Lua as an RTT scripting language", and that's also screwing up things
> >> for the former.
> >
> > The distinction might indeed not be so clear. However Lua is not a
> > "Coordination DSL"! There are three orthogonal things here:
> >
> > 1. rFSM: which _is_ a Coordination DSL (built in Lua for some
> > reasons) and can make use of bindings to various robotic
> > frameworks such as rttlua but also roslua (see below).
> >
> > 2. Lua: a general purpose scripting language which focusses on
> > embeddability and extensibilty and is suitable for building DSL.
> >
> > 3. the rttlua bindings which allow to use a subset of the RTT
> > concepts within Lua.
>
> Good summary, to which I completely agree. But the users
> commenting/requesting on the mailing list do not make this difference: they
> just see "Lua", irrespective of the structure that you and I put into the
> (to be decoupled) uses of Lua in. Do you have the same feeling?
Yes! But so far I saw no danger in this. If it turns out that some
primitives must be considered harmful for some DSLs, then we indeed
must make these different use cases much more clear.
Markus
lua wishlist [continuted from orocos-users]
On Mon, 30 May 2011, Markus Klotzbuecher wrote:
[... cutting away some "legacy" of this thread...]
>> I would prefer to have the discussions on technical grounds, so _if_ you
>> agree on 5C separation of concerns, you _have_ to agree with me that
>> "Computations" do not belong in "Coordination", don't you? Hence, adding
>
> I agree! (... but find the recursiveness of the concept tricky: for a
> Coordinator all coordinated entities are computations, even though
> these might themselves be sub-ordinate coordinators coordinating
> lower-level compuations themselves).
True. But why exactly would that be a "tricky" recursiveness?
> A standard controller component involves coordination:
>
> 1. read current pos
> 2. read desired pos
> 3. apply control law with user defined parameters
> 4. write result to port
No: this is the normal data flow. That is, no discrete decisions have to be
taken, since it is the _discretized_ version of the analog control
activity. (I see many people being confused by the difference between
"discretized" and "discrete" behaviour...)
> Apart from 3. this is really intra-component coordination.
No: intra-component data flow.
>> Lua support for data flow and operations should not be done.
>
> I don't agree here: there is a difference between using ports to raise
> events and using operations to coordinate components vs. implementing
> computations using Lua. I also do not see an why we should treat data
> and events differently, the semantics depend on the perspective and
> context!
Hence(!), they _are_ different. The context and perspective do make a
difference. Not from the _infrastructure_ point of view, but from the
semantic modelling.
> For instance a piece of data might only mean "next setpoint"
> to a computation, but to a saftey coordinator receiving the same value
> at a particular time might signify a serious event requiring immediate
> action. Keeping events and data separate would needlessly complicate
> such a subsystem.
No: the behaviour of the safety coordinator that you mention is that it
runs an "constraint estimator" which fires an event as soon as a predefined
threshold has been violated. The latter is definitely _not_ data flow, the
former ("setpoint control") is.
[...]
>>> The distinction might indeed not be so clear. However Lua is not a
>>> "Coordination DSL"! There are three orthogonal things here:
>>>
>>> 1. rFSM: which _is_ a Coordination DSL (built in Lua for some
>>> reasons) and can make use of bindings to various robotic
>>> frameworks such as rttlua but also roslua (see below).
>>>
>>> 2. Lua: a general purpose scripting language which focusses on
>>> embeddability and extensibilty and is suitable for building DSL.
>>>
>>> 3. the rttlua bindings which allow to use a subset of the RTT
>>> concepts within Lua.
>>
>> Good summary, to which I completely agree. But the users
>> commenting/requesting on the mailing list do not make this difference: they
>> just see "Lua", irrespective of the structure that you and I put into the
>> (to be decoupled) uses of Lua in. Do you have the same feeling?
>
> Yes! But so far I saw no danger in this.
Than you have learned something! :-)
> If it turns out that some primitives must be considered harmful for some
> DSLs, then we indeed must make these different use cases much more clear.
I think so. But this requires some more thought. The easiest would be to
define the separate DSLs on the "meta model" level, and introduce users to
them in this way. Then there can still be (the same) Lua _implementations_
(= model languages) for each of the meta-model DSLs. What you did with rFSM
is, in my opinion, a "best practice" in this case: the rFSM metamodel
_nowhere_ has a "data flow" semantic tag, which is fine.
> Markus
Herman
lua wishlist [continuted from orocos-users]
On Mon, May 30, 2011 at 01:38:02PM +0200, Herman Bruyninckx wrote:
> On Mon, 30 May 2011, Markus Klotzbuecher wrote:
>
> [... cutting away some "legacy" of this thread...]
> >> I would prefer to have the discussions on technical grounds, so _if_ you
> >> agree on 5C separation of concerns, you _have_ to agree with me that
> >> "Computations" do not belong in "Coordination", don't you? Hence, adding
> >
> > I agree! (... but find the recursiveness of the concept tricky: for a
> > Coordinator all coordinated entities are computations, even though
> > these might themselves be sub-ordinate coordinators coordinating
> > lower-level compuations themselves).
>
> True. But why exactly would that be a "tricky" recursiveness?
A (composite) component might include several aspects of the 5C, but
yet be treated a simple computation by a superposed coordinator. Maybe
its only me finding that tricky.
> > A standard controller component involves coordination:
> >
> > 1. read current pos
> > 2. read desired pos
> > 3. apply control law with user defined parameters
> > 4. write result to port
>
> No: this is the normal data flow. That is, no discrete decisions have to be
> taken, since it is the _discretized_ version of the analog control
> activity. (I see many people being confused by the difference between
> "discretized" and "discrete" behaviour...)
Ah, interesting. And you would define Coordination only as discrete
decision making and not discrete behavior itself? I also don't think
the above is discretized (which to me implies sth. continuous
transformed to something discret), as the above discrete steps are
indeed being executed by a controller component.
Nevertheless, you are right that the above lacks any discrete
reasoning. But for a slightly advanced component such reasoning would
immediately become necessary: for instance introduce the requirement
that if the (very fancy) control algorithm fails to produce a result
within a certain timeframe, the component shall fall back on simple
algorithm to be able to produce a result. Voila: discrete reasoning!
> > Apart from 3. this is really intra-component coordination.
> No: intra-component data flow.
>
> >> Lua support for data flow and operations should not be done.
> >
> > I don't agree here: there is a difference between using ports to raise
> > events and using operations to coordinate components vs. implementing
> > computations using Lua. I also do not see an why we should treat data
> > and events differently, the semantics depend on the perspective and
> > context!
>
> Hence(!), they _are_ different. The context and perspective do make a
> difference. Not from the _infrastructure_ point of view, but from the
> semantic modelling.
Agreed. And implementationwise this forbids separating event and
dataflow primitives.
> > For instance a piece of data might only mean "next setpoint"
> > to a computation, but to a saftey coordinator receiving the same value
> > at a particular time might signify a serious event requiring immediate
> > action. Keeping events and data separate would needlessly complicate
> > such a subsystem.
> No: the behaviour of the safety coordinator that you mention is that it
> runs an "constraint estimator" which fires an event as soon as a predefined
> threshold has been violated. The latter is definitely _not_ data flow, the
> former ("setpoint control") is.
Ok, I agree that in this case it would likely make sense to use such a
separate constraint estimator component to transform the dataflow
stream to events.
> [...]
> >>> The distinction might indeed not be so clear. However Lua is not a
> >>> "Coordination DSL"! There are three orthogonal things here:
> >>>
> >>> 1. rFSM: which _is_ a Coordination DSL (built in Lua for some
> >>> reasons) and can make use of bindings to various robotic
> >>> frameworks such as rttlua but also roslua (see below).
> >>>
> >>> 2. Lua: a general purpose scripting language which focusses on
> >>> embeddability and extensibilty and is suitable for building DSL.
> >>>
> >>> 3. the rttlua bindings which allow to use a subset of the RTT
> >>> concepts within Lua.
> >>
> >> Good summary, to which I completely agree. But the users
> >> commenting/requesting on the mailing list do not make this difference: they
> >> just see "Lua", irrespective of the structure that you and I put into the
> >> (to be decoupled) uses of Lua in. Do you have the same feeling?
> >
> > Yes! But so far I saw no danger in this.
>
> Than you have learned something! :-)
I still don't see the danger, but realize the possibility of its
existence :-)
> > If it turns out that some primitives must be considered harmful for some
> > DSLs, then we indeed must make these different use cases much more clear.
>
> I think so. But this requires some more thought. The easiest would be to
> define the separate DSLs on the "meta model" level, and introduce users to
> them in this way. Then there can still be (the same) Lua _implementations_
> (= model languages) for each of the meta-model DSLs. What you did with rFSM
> is, in my opinion, a "best practice" in this case: the rFSM metamodel
> _nowhere_ has a "data flow" semantic tag, which is fine.
This sounds like the right way to do it, as that way the constraints
are introduced at the meta modeling level, where they belong IMO.
We're slowly starting to agree.
Markus
lua wishlist [continuted from orocos-users]
On Mon, 30 May 2011, Markus Klotzbuecher wrote:
> On Mon, May 30, 2011 at 01:38:02PM +0200, Herman Bruyninckx wrote:
>> On Mon, 30 May 2011, Markus Klotzbuecher wrote:
>>
>> [... cutting away some "legacy" of this thread...]
>>>> I would prefer to have the discussions on technical grounds, so _if_ you
>>>> agree on 5C separation of concerns, you _have_ to agree with me that
>>>> "Computations" do not belong in "Coordination", don't you? Hence, adding
>>>
>>> I agree! (... but find the recursiveness of the concept tricky: for a
>>> Coordinator all coordinated entities are computations, even though
>>> these might themselves be sub-ordinate coordinators coordinating
>>> lower-level compuations themselves).
>>
>> True. But why exactly would that be a "tricky" recursiveness?
>
> A (composite) component might include several aspects of the 5C, but
> yet be treated a simple computation by a superposed coordinator. Maybe
> its only me finding that tricky.
I find that a nice example of "information hiding done right".
>>> A standard controller component involves coordination:
>>>
>>> 1. read current pos
>>> 2. read desired pos
>>> 3. apply control law with user defined parameters
>>> 4. write result to port
>>
>> No: this is the normal data flow. That is, no discrete decisions have to be
>> taken, since it is the _discretized_ version of the analog control
>> activity. (I see many people being confused by the difference between
>> "discretized" and "discrete" behaviour...)
>
> Ah, interesting. And you would define Coordination only as discrete
> decision making and not discrete behavior itself?
Of course!
> I also don't think
> the above is discretized (which to me implies sth. continuous
> transformed to something discret), as the above discrete steps are
> indeed being executed by a controller component.
It _is_ discretized, believe me.
> Nevertheless, you are right that the above lacks any discrete
> reasoning. But for a slightly advanced component such reasoning would
> immediately become necessary: for instance introduce the requirement
> that if the (very fancy) control algorithm fails to produce a result
> within a certain timeframe, the component shall fall back on simple
> algorithm to be able to produce a result. Voila: discrete reasoning!
That _is_ indeed discrete reasoning, once again triggered by a "monitoring
algorithm".
>>> Apart from 3. this is really intra-component coordination.
>> No: intra-component data flow.
>>
>>>> Lua support for data flow and operations should not be done.
>>>
>>> I don't agree here: there is a difference between using ports to raise
>>> events and using operations to coordinate components vs. implementing
>>> computations using Lua. I also do not see an why we should treat data
>>> and events differently, the semantics depend on the perspective and
>>> context!
>>
>> Hence(!), they _are_ different. The context and perspective do make a
>> difference. Not from the _infrastructure_ point of view, but from the
>> semantic modelling.
>
> Agreed. And implementationwise this forbids separating event and
> dataflow primitives.
>
>>> For instance a piece of data might only mean "next setpoint"
>>> to a computation, but to a saftey coordinator receiving the same value
>>> at a particular time might signify a serious event requiring immediate
>>> action. Keeping events and data separate would needlessly complicate
>>> such a subsystem.
>> No: the behaviour of the safety coordinator that you mention is that it
>> runs an "constraint estimator" which fires an event as soon as a predefined
>> threshold has been violated. The latter is definitely _not_ data flow, the
>> former ("setpoint control") is.
>
> Ok, I agree that in this case it would likely make sense to use such a
> separate constraint estimator component to transform the dataflow
> stream to events.
I this case, and in any other case where the task has "constraint
violations to be monitored.
>> [...]
>>>>> The distinction might indeed not be so clear. However Lua is not a
>>>>> "Coordination DSL"! There are three orthogonal things here:
>>>>>
>>>>> 1. rFSM: which _is_ a Coordination DSL (built in Lua for some
>>>>> reasons) and can make use of bindings to various robotic
>>>>> frameworks such as rttlua but also roslua (see below).
>>>>>
>>>>> 2. Lua: a general purpose scripting language which focusses on
>>>>> embeddability and extensibilty and is suitable for building DSL.
>>>>>
>>>>> 3. the rttlua bindings which allow to use a subset of the RTT
>>>>> concepts within Lua.
>>>>
>>>> Good summary, to which I completely agree. But the users
>>>> commenting/requesting on the mailing list do not make this difference: they
>>>> just see "Lua", irrespective of the structure that you and I put into the
>>>> (to be decoupled) uses of Lua in. Do you have the same feeling?
>>>
>>> Yes! But so far I saw no danger in this.
>>
>> Than you have learned something! :-)
>
> I still don't see the danger, but realize the possibility of its
> existence :-)
>
>>> If it turns out that some primitives must be considered harmful for some
>>> DSLs, then we indeed must make these different use cases much more clear.
>>
>> I think so. But this requires some more thought. The easiest would be to
>> define the separate DSLs on the "meta model" level, and introduce users to
>> them in this way. Then there can still be (the same) Lua _implementations_
>> (= model languages) for each of the meta-model DSLs. What you did with rFSM
>> is, in my opinion, a "best practice" in this case: the rFSM metamodel
>> _nowhere_ has a "data flow" semantic tag, which is fine.
>
> This sounds like the right way to do it, as that way the constraints
> are introduced at the meta modeling level, where they belong IMO.
>
> We're slowly starting to agree.
We have always agreed, but did not realise exactly why... :-)
> Markus
Herman
lua wishlist [continuted from orocos-users]
On Monday 30 May 2011 10:32:37 Herman Bruyninckx wrote:
> On Mon, 30 May 2011, Markus Klotzbuecher wrote:
> > On Sat, May 28, 2011 at 05:48:06PM +0200, Herman Bruyninckx wrote:
> >> On Sat, 28 May 2011, Markus Klotzbuecher wrote:
> >>> On Sat, May 28, 2011 at 12:21:47AM +0200, Herman Bruyninckx wrote:
> >>>> On Fri, 27 May 2011, Markus Klotzbuecher wrote:
> >>>>> On Fri, May 27, 2011 at 12:39:53PM +0200, Herman Bruyninckx wrote:
> >>>>>> On Fri, 27 May 2011, Markus Klotzbuecher wrote:
> >>>>>>> On Fri, May 27, 2011 at 11:50:01AM +0200, Herman Bruyninckx wrote:
> >>>>>>>> On Fri, 27 May 2011, Markus Klotzbuecher wrote:
> >>>>>>>>> On Thu, May 26, 2011 at 07:10:21PM +0200, Herman Bruyninckx wrote:
> >>>>> ...
> >>>>>
> >>>>>>>>>> I've seen way too many projects loose there competitive
> >>>>>>>>>> advantage by trying to hit every nail by the (nice but limited,
> >>>>>>>>>> by design!) hammer they have...
> >>>>>>>>>
> >>>>>>>>> Yes, and we're not falling into that trap :-)
> >>>>>>>>
> >>>>>>>> I would like to see a proof of that... Because this is the trap
> >>>>>>>> that I see growing before our noses: Lua was introduced in RTT
> >>>>>>>> for the sole purpose of doing Coordination, not needing much
> >>>>>>>> "data processing" capabilities at all. Now, the trend is growing
> >>>>>>>> to use Lua for a very different purpose, namely as the scripting
> >>>>>>>> language for doing dynamci deployment. And it is via this
> >>>>>>>
> >>>>>>> Coordination and dynamic deployment are strongly related. For this
> >>>>>>> reason the "mechanism" to support coordination (like starting and
> >>>>>>> stopping components, (re) connecting ports etc.) are also suitable
> >>>>>>> for deployment. The nice thing about implementing DSLs in
> >>>>>>> scripting languages like Lua or Ruby is that new solutions can be
> >>>>>>> explored _without_ bloating core RTT.
> >>>>>>
> >>>>>> As long as you stick to the DSL that does the FSM, I am fully with
> >>>>>> you. But as soon as you start adding 'data operations', I am not! I
> >>>>>> want to have a
> >>>>>
> >>>>> How do you define data operations? If you mean accessing and
> >>>>> modifying data objects, then how could a Statemachine do anything
> >>>>> useful without? Almost any coordination needs to invoke some
> >>>>> operation with some arguments... moveTo(pos), sendevent(event) etc.
> >>>>
> >>>> No: it should send out _events_ that let other components do these
> >>>> things, or configure them.
> >>>
> >>> You know I agree and would prefer FSM to communicate purely
> >>> event/message based, however in practice this is difficult because of
> >>> the following reasons:
> >>>
> >>> 1. most of the existing components are not implemented this way, but
> >>>
> >>> offer synchronous or asynchronous operations. Of course these can
> >>> be refactored and indeed several already have been, nevertheless it
> >>> must be possible to deal with legacy.
> >>
> >> Legacy is a reality indeed. But dealing with legacy should not, I
> >> repeat, not, compromise the MDE future of Orocos. In that case, let's
> >> stop now, because the project is going to be dead anyway in a couple of
> >> more legacy-before-everything years.
> >>
> >> So, the real question we face is: how to keep both goals nicely
> >> separated..? The obvious answer is:
> >> 1. support legacy for your current major version;
> >> 2. make sure the legacy does not trickle down in your new major version.
> >> 3. be clever enough to do both 1. and 2., without making the refactoring
> >>
> >> from 1. to 2. impossible.
> >>
> >> You are helping users with 1., I am trying to scare away everyone from
> >> 1., because of 2. We should both work together to provide a "this is
> >> how you _should_ do it" answer to all requesters for 1. Which we have
> >> to do for 3. anyway.
> >
> > Ok, fine! The challenge with this however, is to convince the
> > substantial group of people which strongly disagrees that a particular
> > primitive actually is legacy, and not a really neat feature.
>
> That's a challenge indeed. And the only "weight" I can bring behind my
> arguments is that I have made the featuritis error myself too many times,
> and I don't want to go there anymore. If the majority of stakeholders in
> RTT want to do it differently, they will kill the long-term goals.
>
> I would prefer to have the discussions on technical grounds, so _if_ you
> agree on 5C separation of concerns, you _have_ to agree with me that
> "Computations" do not belong in "Coordination", don't you? Hence, adding
> Lua support for data flow and operations should not be done.
I don't agree.
First objection (not from a user perspective): the events are based on
dataFlow (they come over dataports).
Second objection: computations indeed don't belong in the LuaRFSM but why is
it wrong to provide support for the Lua programming language?
Again: As a user I want to use the same programming language as much as
possible but ofcourse I'm willing to separate my coding according to the 5C's!
>
> >> At the end of this message, there is a concrete suggestion about 3.
> >>
> >>> 2. multi-argument operations require definition/generation of new
> >>>
> >>> types: take for instance a simple trajectory generator which takes
> >>> three arguments: start and end pose and a duration. To turn this
> >>> call into a "command event" a new type containing these three
> >>> fields needs to be defined/implemented/generated. Extra effort,
> >>> previously not required.
> >>
> >> So, events should carry no data! The data is in the data flows, the
> >> events in the event flow. A Coordination state machine component should
> >> only work with event flows. In other words, a Coordinator should never
> >> exchange any "commands" with whichever other Component.
> >>
> >>> 3. Most importantly, unless you "discretize the world", events will
> >>>
> >>> always carry a "continuous data payload": in the trajectory
> >>> generator example the poses and duration. Hence even in a pure
> >>> event driven system data operations are necessary.
> >>
> >> Of course! But those data operations are on the data flows between
> >> Computational components, _not_ on the event flows between the
> >> Coordinator and the Computational components. _That_ is separation of
> >> concerns! :-)
> >
> > I am not convinced that a Coordination FSM can only coordinate using
> > pure events (by pure i mean: carrying only identity, nothing more) and
>
> If you mean with "identity" that an event carries a name that identifies
> its origin, I agree.
>
> > be practically useful. But we can easily find out who is right by
> > looking at the various existing coordination FSM (which do use and
> > manipulate data) and see how well these could be refactored according
> > to your suggestion :-)
>
> Good!
>
> >>>>>> DSL that can be formally verified, from which code can be generated,
> >>>>>> and that has no possible side effects.
> >>>>>> What you are now supporting users to add is against all these design
> >>>>>> specifications...
> >>>>>>
> >>>>>>>> backdoor that the "featuritis" creeps in. Please, let's use
> >>>>>>>> another language for the deployment scripting! Nothing wroing
> >>>>>>>> with Python there, since there is no hard realtime need. Also
> >>>>>>>> nothing wrong with Java, since that's where "the big masses" are
> >>>>>>>> (including Eclipse support...).
> >>>>>>>
> >>>>>>> I disagree that using Python or Java would have any advantage
> >>>>>>> here. These are only "other" general purpose languages and adding
> >>>>>>> bindings for them would be a lot of work with no real gain. On the
> >>>>>>> other side I think it would be beneficial to use a standardized
> >>>>>>> model of deployment supported by Eclipse. But that's a question
> >>>>>>> about the right model, not the right language.
> >>>>>>
> >>>>>> Both. For users like Nick, the language _is_ the model. So, let's
> >>>>>> not make it so damned easy for them to screw up the model, by
> >>>>>> adding "stuff" to the DSL meta language.
> >>>>>
> >>>>> But both are separate: the FSM DSL is (indentionally!) independent
> >>>>> and agnostic of RTT. It may use the primitives provided by the
> >>>>> framework bindings. If is is bad practice to use a certain primitive
> >>>>> (which could indeed be the case!) the constraint to prevent this
> >>>>> should not be added at either of the _mechanisms_ FSM-DSL or rttlua
> >>>>> bindings; here we should follow the Unix best practice:
> >>>>>
> >>>>> "UNIX was not designed to stop you from doing stupid things, because
> >>>>> that would also stop you from doing clever things." - Doug Gwyn
> >>>>
> >>>> Hence, UNIX _never_ made it into MDE toolchains... The robotics world
> >>>> is a bit (too) full of guys-on-UNIX-steroids... UNIX worked well 40
> >>>> years ago. It still does, but not in an MDE world.
> >>>>
> >>>>> The right place for constraining the user, IMHO, would be the
> >>>>> graphical modeling toolchain.
> >>>>>
> >>>>> Would you agree?
> >>>>
> >>>> That is the easiest part yes. But this toolchaain will be practically
> >>>> useless since we stimulate all the functionality contributors to screw
> >>>> the modelling separations...
> >>>
> >>> It is trivially possible to restrict the primitives that can be used
> >>> in a DSL.
> >>
> >> Yes. So we should make these things clear, and provide the explicit
> >> software support for it.
> >>
> >>> However, it is not yet clear to me which ones "screw the
> >>> separations" and this should be excluded.
> >>
> >> The 'data carrying events' are the ones that screw things up for keeping
> >> the Coordination separated from the Computations.
> >> In addition, the current situation, users (and obviously also most
> >> developers) do not see the distinction between "Lua as a Coordination
> >> DSL" and "Lua as an RTT scripting language", and that's also screwing
> >> up things for the former.
> >
> > The distinction might indeed not be so clear. However Lua is not a
> > "Coordination DSL"! There are three orthogonal things here:
> >
> > 1. rFSM: which _is_ a Coordination DSL (built in Lua for some
> >
> > reasons) and can make use of bindings to various robotic
> > frameworks such as rttlua but also roslua (see below).
> >
> > 2. Lua: a general purpose scripting language which focusses on
> >
> > embeddability and extensibilty and is suitable for building DSL.
> >
> > 3. the rttlua bindings which allow to use a subset of the RTT
> >
> > concepts within Lua.
>
> Good summary, to which I completely agree. But the users
> commenting/requesting on the mailing list do not make this difference: they
> just see "Lua", irrespective of the structure that you and I put into the
> (to be decoupled) uses of Lua in. Do you have the same feeling?
As a user I don't agree.
Some users are willing to take into account the 5Cs and the decoupling you
propose. They however don't want to learn 5 different programming languages to
support each of the C's. As a user I really object to introduce a different
programming language for every concern. Rather give the users some good
examples (or best practices) that show how you can separate the 5Cs in
practice.
>
> >> Concrete constructive suggestion:
> >> - let's start formalizing the Coordination rFSM now, in such a way that
> >> a
> >>
> >> tool can check whether only "pure" coordination language constructs
> >> are being used.
> >>
> >> - let's write a documentation document that explains the differences
> >>
> >> between "Lua as a Coordination DSL" and "Lua as an RTT scripting
> >> language", including guidelines for users about how to work with
> >> both.
> >
> > In terms of documentation I have started to document "good use" in
> > terms of the LuaCookbook, but it's an ongoing effort.
>
> Much appreciated!
>
> >> This document will be core of our PhD anyway! (Otherwise, nobody will be
> >> impressed by it :-)
> >
> > Agreed :-)
As I'm reading the discussion I really think we should make the separation
between the programming language (for instance LUA) and the functionality
provided (for instance state machines for coordination).
According to me there is not need to use a different programming language for
every functionality (or C).
Tinne
lua wishlist [continuted from orocos-users]
On Mon, 30 May 2011, Tinne De Laet wrote:
> On Monday 30 May 2011 10:32:37 Herman Bruyninckx wrote:
>> On Mon, 30 May 2011, Markus Klotzbuecher wrote:
>>> On Sat, May 28, 2011 at 05:48:06PM +0200, Herman Bruyninckx wrote:
>>>> On Sat, 28 May 2011, Markus Klotzbuecher wrote:
>>>>> On Sat, May 28, 2011 at 12:21:47AM +0200, Herman Bruyninckx wrote:
>>>>>> On Fri, 27 May 2011, Markus Klotzbuecher wrote:
>>>>>>> On Fri, May 27, 2011 at 12:39:53PM +0200, Herman Bruyninckx wrote:
>>>>>>>> On Fri, 27 May 2011, Markus Klotzbuecher wrote:
>>>>>>>>> On Fri, May 27, 2011 at 11:50:01AM +0200, Herman Bruyninckx wrote:
>>>>>>>>>> On Fri, 27 May 2011, Markus Klotzbuecher wrote:
>>>>>>>>>>> On Thu, May 26, 2011 at 07:10:21PM +0200, Herman Bruyninckx wrote:
>>>>>>> ...
>>>>>>>
>>>>>>>>>>>> I've seen way too many projects loose there competitive
>>>>>>>>>>>> advantage by trying to hit every nail by the (nice but limited,
>>>>>>>>>>>> by design!) hammer they have...
>>>>>>>>>>>
>>>>>>>>>>> Yes, and we're not falling into that trap :-)
>>>>>>>>>>
>>>>>>>>>> I would like to see a proof of that... Because this is the trap
>>>>>>>>>> that I see growing before our noses: Lua was introduced in RTT
>>>>>>>>>> for the sole purpose of doing Coordination, not needing much
>>>>>>>>>> "data processing" capabilities at all. Now, the trend is growing
>>>>>>>>>> to use Lua for a very different purpose, namely as the scripting
>>>>>>>>>> language for doing dynamci deployment. And it is via this
>>>>>>>>>
>>>>>>>>> Coordination and dynamic deployment are strongly related. For this
>>>>>>>>> reason the "mechanism" to support coordination (like starting and
>>>>>>>>> stopping components, (re) connecting ports etc.) are also suitable
>>>>>>>>> for deployment. The nice thing about implementing DSLs in
>>>>>>>>> scripting languages like Lua or Ruby is that new solutions can be
>>>>>>>>> explored _without_ bloating core RTT.
>>>>>>>>
>>>>>>>> As long as you stick to the DSL that does the FSM, I am fully with
>>>>>>>> you. But as soon as you start adding 'data operations', I am not! I
>>>>>>>> want to have a
>>>>>>>
>>>>>>> How do you define data operations? If you mean accessing and
>>>>>>> modifying data objects, then how could a Statemachine do anything
>>>>>>> useful without? Almost any coordination needs to invoke some
>>>>>>> operation with some arguments... moveTo(pos), sendevent(event) etc.
>>>>>>
>>>>>> No: it should send out _events_ that let other components do these
>>>>>> things, or configure them.
>>>>>
>>>>> You know I agree and would prefer FSM to communicate purely
>>>>> event/message based, however in practice this is difficult because of
>>>>> the following reasons:
>>>>>
>>>>> 1. most of the existing components are not implemented this way, but
>>>>>
>>>>> offer synchronous or asynchronous operations. Of course these can
>>>>> be refactored and indeed several already have been, nevertheless it
>>>>> must be possible to deal with legacy.
>>>>
>>>> Legacy is a reality indeed. But dealing with legacy should not, I
>>>> repeat, not, compromise the MDE future of Orocos. In that case, let's
>>>> stop now, because the project is going to be dead anyway in a couple of
>>>> more legacy-before-everything years.
>>>>
>>>> So, the real question we face is: how to keep both goals nicely
>>>> separated..? The obvious answer is:
>>>> 1. support legacy for your current major version;
>>>> 2. make sure the legacy does not trickle down in your new major version.
>>>> 3. be clever enough to do both 1. and 2., without making the refactoring
>>>>
>>>> from 1. to 2. impossible.
>>>>
>>>> You are helping users with 1., I am trying to scare away everyone from
>>>> 1., because of 2. We should both work together to provide a "this is
>>>> how you _should_ do it" answer to all requesters for 1. Which we have
>>>> to do for 3. anyway.
>>>
>>> Ok, fine! The challenge with this however, is to convince the
>>> substantial group of people which strongly disagrees that a particular
>>> primitive actually is legacy, and not a really neat feature.
>>
>> That's a challenge indeed. And the only "weight" I can bring behind my
>> arguments is that I have made the featuritis error myself too many times,
>> and I don't want to go there anymore. If the majority of stakeholders in
>> RTT want to do it differently, they will kill the long-term goals.
>>
>> I would prefer to have the discussions on technical grounds, so _if_ you
>> agree on 5C separation of concerns, you _have_ to agree with me that
>> "Computations" do not belong in "Coordination", don't you? Hence, adding
>> Lua support for data flow and operations should not be done.
>
> I don't agree.
> First objection (not from a user perspective): the events are based on
> dataFlow (they come over dataports).
That's one of these "legacy" things: _because_ the underlying transport is
basically the same, this was allowed to "shine through" to the users, and
now they are not making the distinction anymore between "data carrying"
messages and "event" messages. In other words, the first step towards
"decay" of the nice decoupling models.
> Second objection: computations indeed don't belong in the LuaRFSM but why is
> it wrong to provide support for the Lua programming language?
> Again: As a user I want to use the same programming language as much as
> possible but ofcourse I'm willing to separate my coding according to the 5C's!
There is nothing wrong with these things, but the Orocos design has to be
such that users can _only_ do it right. That's not the case now, as far as
I can see. (And I confess I do not see everything.)
>>>> At the end of this message, there is a concrete suggestion about 3.
>>>>
>>>>> 2. multi-argument operations require definition/generation of new
>>>>>
>>>>> types: take for instance a simple trajectory generator which takes
>>>>> three arguments: start and end pose and a duration. To turn this
>>>>> call into a "command event" a new type containing these three
>>>>> fields needs to be defined/implemented/generated. Extra effort,
>>>>> previously not required.
>>>>
>>>> So, events should carry no data! The data is in the data flows, the
>>>> events in the event flow. A Coordination state machine component should
>>>> only work with event flows. In other words, a Coordinator should never
>>>> exchange any "commands" with whichever other Component.
>>>>
>>>>> 3. Most importantly, unless you "discretize the world", events will
>>>>>
>>>>> always carry a "continuous data payload": in the trajectory
>>>>> generator example the poses and duration. Hence even in a pure
>>>>> event driven system data operations are necessary.
>>>>
>>>> Of course! But those data operations are on the data flows between
>>>> Computational components, _not_ on the event flows between the
>>>> Coordinator and the Computational components. _That_ is separation of
>>>> concerns! :-)
>>>
>>> I am not convinced that a Coordination FSM can only coordinate using
>>> pure events (by pure i mean: carrying only identity, nothing more) and
>>
>> If you mean with "identity" that an event carries a name that identifies
>> its origin, I agree.
>>
>>> be practically useful. But we can easily find out who is right by
>>> looking at the various existing coordination FSM (which do use and
>>> manipulate data) and see how well these could be refactored according
>>> to your suggestion :-)
>>
>> Good!
>>
>>>>>>>> DSL that can be formally verified, from which code can be generated,
>>>>>>>> and that has no possible side effects.
>>>>>>>> What you are now supporting users to add is against all these design
>>>>>>>> specifications...
>>>>>>>>
>>>>>>>>>> backdoor that the "featuritis" creeps in. Please, let's use
>>>>>>>>>> another language for the deployment scripting! Nothing wroing
>>>>>>>>>> with Python there, since there is no hard realtime need. Also
>>>>>>>>>> nothing wrong with Java, since that's where "the big masses" are
>>>>>>>>>> (including Eclipse support...).
>>>>>>>>>
>>>>>>>>> I disagree that using Python or Java would have any advantage
>>>>>>>>> here. These are only "other" general purpose languages and adding
>>>>>>>>> bindings for them would be a lot of work with no real gain. On the
>>>>>>>>> other side I think it would be beneficial to use a standardized
>>>>>>>>> model of deployment supported by Eclipse. But that's a question
>>>>>>>>> about the right model, not the right language.
>>>>>>>>
>>>>>>>> Both. For users like Nick, the language _is_ the model. So, let's
>>>>>>>> not make it so damned easy for them to screw up the model, by
>>>>>>>> adding "stuff" to the DSL meta language.
>>>>>>>
>>>>>>> But both are separate: the FSM DSL is (indentionally!) independent
>>>>>>> and agnostic of RTT. It may use the primitives provided by the
>>>>>>> framework bindings. If is is bad practice to use a certain primitive
>>>>>>> (which could indeed be the case!) the constraint to prevent this
>>>>>>> should not be added at either of the _mechanisms_ FSM-DSL or rttlua
>>>>>>> bindings; here we should follow the Unix best practice:
>>>>>>>
>>>>>>> "UNIX was not designed to stop you from doing stupid things, because
>>>>>>> that would also stop you from doing clever things." - Doug Gwyn
>>>>>>
>>>>>> Hence, UNIX _never_ made it into MDE toolchains... The robotics world
>>>>>> is a bit (too) full of guys-on-UNIX-steroids... UNIX worked well 40
>>>>>> years ago. It still does, but not in an MDE world.
>>>>>>
>>>>>>> The right place for constraining the user, IMHO, would be the
>>>>>>> graphical modeling toolchain.
>>>>>>>
>>>>>>> Would you agree?
>>>>>>
>>>>>> That is the easiest part yes. But this toolchaain will be practically
>>>>>> useless since we stimulate all the functionality contributors to screw
>>>>>> the modelling separations...
>>>>>
>>>>> It is trivially possible to restrict the primitives that can be used
>>>>> in a DSL.
>>>>
>>>> Yes. So we should make these things clear, and provide the explicit
>>>> software support for it.
>>>>
>>>>> However, it is not yet clear to me which ones "screw the
>>>>> separations" and this should be excluded.
>>>>
>>>> The 'data carrying events' are the ones that screw things up for keeping
>>>> the Coordination separated from the Computations.
>>>> In addition, the current situation, users (and obviously also most
>>>> developers) do not see the distinction between "Lua as a Coordination
>>>> DSL" and "Lua as an RTT scripting language", and that's also screwing
>>>> up things for the former.
>>>
>>> The distinction might indeed not be so clear. However Lua is not a
>>> "Coordination DSL"! There are three orthogonal things here:
>>>
>>> 1. rFSM: which _is_ a Coordination DSL (built in Lua for some
>>>
>>> reasons) and can make use of bindings to various robotic
>>> frameworks such as rttlua but also roslua (see below).
>>>
>>> 2. Lua: a general purpose scripting language which focusses on
>>>
>>> embeddability and extensibilty and is suitable for building DSL.
>>>
>>> 3. the rttlua bindings which allow to use a subset of the RTT
>>>
>>> concepts within Lua.
>>
>> Good summary, to which I completely agree. But the users
>> commenting/requesting on the mailing list do not make this difference: they
>> just see "Lua", irrespective of the structure that you and I put into the
>> (to be decoupled) uses of Lua in. Do you have the same feeling?
>
> As a user I don't agree.
> Some users are willing to take into account the 5Cs and the decoupling you
> propose. They however don't want to learn 5 different programming languages to
> support each of the C's. As a user I really object to introduce a different
> programming language for every concern. Rather give the users some good
> examples (or best practices) that show how you can separate the 5Cs in
> practice.
First of all, the _real_ users will, eventually, only see what the
toolchain provides. Currently, we only have _developers_. And yes, they
will have to learn five different "programming languages", but each of them
will be deceptively simple.
>>>> Concrete constructive suggestion:
>>>> - let's start formalizing the Coordination rFSM now, in such a way that
>>>> a
>>>>
>>>> tool can check whether only "pure" coordination language constructs
>>>> are being used.
>>>>
>>>> - let's write a documentation document that explains the differences
>>>>
>>>> between "Lua as a Coordination DSL" and "Lua as an RTT scripting
>>>> language", including guidelines for users about how to work with
>>>> both.
>>>
>>> In terms of documentation I have started to document "good use" in
>>> terms of the LuaCookbook, but it's an ongoing effort.
>>
>> Much appreciated!
>>
>>>> This document will be core of our PhD anyway! (Otherwise, nobody will be
>>>> impressed by it :-)
>>>
>>> Agreed :-)
>
> As I'm reading the discussion I really think we should make the separation
> between the programming language (for instance LUA) and the functionality
> provided (for instance state machines for coordination).
Indeed. But this separation should be _enforcable_ (at least in the
toolchain), and not rely on discipline by good developers. The latter has
chosen not to work, since most developers do not have that discipline.
> According to me there is not need to use a different programming language for
> every functionality (or C).
There are definitely different concepts to be represented, hence a
different "programming language". We should start using the moniker "DSL",
instead of programming language. The same language _could_ be below the
DSLs, but the concrete progamming language should be (enforceably!)
invisible, and only the strict DSLs should be used.
> Tinne
Thanks for your "user" inputs!
Herman
lua wishlist [continuted from orocos-users]
On Monday 30 May 2011 11:07:39 Herman Bruyninckx wrote:
> On Mon, 30 May 2011, Tinne De Laet wrote:
> > On Monday 30 May 2011 10:32:37 Herman Bruyninckx wrote:
> >> On Mon, 30 May 2011, Markus Klotzbuecher wrote:
> >>> On Sat, May 28, 2011 at 05:48:06PM +0200, Herman Bruyninckx wrote:
> >>>> On Sat, 28 May 2011, Markus Klotzbuecher wrote:
> >>>>> On Sat, May 28, 2011 at 12:21:47AM +0200, Herman Bruyninckx wrote:
> >>>>>> On Fri, 27 May 2011, Markus Klotzbuecher wrote:
> >>>>>>> On Fri, May 27, 2011 at 12:39:53PM +0200, Herman Bruyninckx wrote:
> >>>>>>>> On Fri, 27 May 2011, Markus Klotzbuecher wrote:
> >>>>>>>>> On Fri, May 27, 2011 at 11:50:01AM +0200, Herman Bruyninckx wrote:
> >>>>>>>>>> On Fri, 27 May 2011, Markus Klotzbuecher wrote:
> >>>>>>>>>>> On Thu, May 26, 2011 at 07:10:21PM +0200, Herman Bruyninckx
wrote:
> >>>>>>> ...
> >>>>>>>
> >>>>>>>>>>>> I've seen way too many projects loose there
> >>>>>>>>>>>> competitive
> >>>>>>>>>>>> advantage by trying to hit every nail by the (nice
> >>>>>>>>>>>> but limited, by design!) hammer they have...
> >>>>>>>>>>>
> >>>>>>>>>>> Yes, and we're not falling into that trap :-)
> >>>>>>>>>>
> >>>>>>>>>> I would like to see a proof of that... Because this is
> >>>>>>>>>> the trap
> >>>>>>>>>> that I see growing before our noses: Lua was
> >>>>>>>>>> introduced in RTT
> >>>>>>>>>> for the sole purpose of doing Coordination, not
> >>>>>>>>>> needing much
> >>>>>>>>>> "data processing" capabilities at all. Now, the trend
> >>>>>>>>>> is growing
> >>>>>>>>>> to use Lua for a very different purpose, namely as the
> >>>>>>>>>> scripting
> >>>>>>>>>> language for doing dynamci deployment. And it is via
> >>>>>>>>>> this
> >>>>>>>>>
> >>>>>>>>> Coordination and dynamic deployment are strongly
> >>>>>>>>> related. For this reason the "mechanism" to support
> >>>>>>>>> coordination (like starting and stopping components,
> >>>>>>>>> (re) connecting ports etc.) are also suitable for
> >>>>>>>>> deployment. The nice thing about implementing DSLs in
> >>>>>>>>> scripting languages like Lua or Ruby is that new
> >>>>>>>>> solutions can be explored _without_ bloating core RTT.
> >>>>>>>>
> >>>>>>>> As long as you stick to the DSL that does the FSM, I am
> >>>>>>>> fully with
> >>>>>>>> you. But as soon as you start adding 'data operations', I
> >>>>>>>> am not! I want to have a
> >>>>>>>
> >>>>>>> How do you define data operations? If you mean accessing and
> >>>>>>> modifying data objects, then how could a Statemachine do
> >>>>>>> anything
> >>>>>>> useful without? Almost any coordination needs to invoke some
> >>>>>>> operation with some arguments... moveTo(pos),
> >>>>>>> sendevent(event) etc.
> >>>>>>
> >>>>>> No: it should send out _events_ that let other components do
> >>>>>> these
> >>>>>> things, or configure them.
> >>>>>
> >>>>> You know I agree and would prefer FSM to communicate purely
> >>>>> event/message based, however in practice this is difficult
> >>>>> because of
> >>>>> the following reasons:
> >>>>>
> >>>>> 1. most of the existing components are not implemented this way,
> >>>>> but
> >>>>>
> >>>>> offer synchronous or asynchronous operations. Of course
> >>>>> these can
> >>>>> be refactored and indeed several already have been,
> >>>>> nevertheless it
> >>>>> must be possible to deal with legacy.
> >>>>
> >>>> Legacy is a reality indeed. But dealing with legacy should not, I
> >>>> repeat, not, compromise the MDE future of Orocos. In that case,
> >>>> let's
> >>>> stop now, because the project is going to be dead anyway in a
> >>>> couple of more legacy-before-everything years.
> >>>>
> >>>> So, the real question we face is: how to keep both goals nicely
> >>>> separated..? The obvious answer is:
> >>>> 1. support legacy for your current major version;
> >>>> 2. make sure the legacy does not trickle down in your new major
> >>>> version. 3. be clever enough to do both 1. and 2., without making
> >>>> the refactoring
> >>>>
> >>>> from 1. to 2. impossible.
> >>>>
> >>>> You are helping users with 1., I am trying to scare away everyone
> >>>> from
> >>>> 1., because of 2. We should both work together to provide a "this
> >>>> is
> >>>> how you _should_ do it" answer to all requesters for 1. Which we
> >>>> have
> >>>> to do for 3. anyway.
> >>>
> >>> Ok, fine! The challenge with this however, is to convince the
> >>> substantial group of people which strongly disagrees that a
> >>> particular
> >>> primitive actually is legacy, and not a really neat feature.
> >>
> >> That's a challenge indeed. And the only "weight" I can bring behind my
> >> arguments is that I have made the featuritis error myself too many
> >> times, and I don't want to go there anymore. If the majority of
> >> stakeholders in RTT want to do it differently, they will kill the
> >> long-term goals.
> >>
> >> I would prefer to have the discussions on technical grounds, so _if_
> >> you
> >> agree on 5C separation of concerns, you _have_ to agree with me that
> >> "Computations" do not belong in "Coordination", don't you? Hence,
> >> adding
> >> Lua support for data flow and operations should not be done.
> >
> > I don't agree.
> > First objection (not from a user perspective): the events are based on
> > dataFlow (they come over dataports).
>
> That's one of these "legacy" things: _because_ the underlying transport is
> basically the same, this was allowed to "shine through" to the users, and
> now they are not making the distinction anymore between "data carrying"
> messages and "event" messages. In other words, the first step towards
> "decay" of the nice decoupling models.
>
> > Second objection: computations indeed don't belong in the LuaRFSM but
> > why is it wrong to provide support for the Lua programming language?
> > Again: As a user I want to use the same programming language as much as
> > possible but ofcourse I'm willing to separate my coding according to the
> > 5C's!
>
> There is nothing wrong with these things, but the Orocos design has to be
> such that users can _only_ do it right. That's not the case now, as far as
> I can see. (And I confess I do not see everything.)
>
> >>>> At the end of this message, there is a concrete suggestion about
> >>>> 3.
> >>>>
> >>>>> 2. multi-argument operations require definition/generation of
> >>>>> new
> >>>>>
> >>>>> types: take for instance a simple trajectory generator
> >>>>> which takes
> >>>>> three arguments: start and end pose and a duration. To
> >>>>> turn this
> >>>>> call into a "command event" a new type containing these
> >>>>> three
> >>>>> fields needs to be defined/implemented/generated. Extra
> >>>>> effort,
> >>>>> previously not required.
> >>>>
> >>>> So, events should carry no data! The data is in the data flows,
> >>>> the
> >>>> events in the event flow. A Coordination state machine component
> >>>> should only work with event flows. In other words, a Coordinator
> >>>> should never exchange any "commands" with whichever other
> >>>> Component.
> >>>>
> >>>>> 3. Most importantly, unless you "discretize the world", events
> >>>>> will
> >>>>>
> >>>>> always carry a "continuous data payload": in the
> >>>>> trajectory
> >>>>> generator example the poses and duration. Hence even in a
> >>>>> pure
> >>>>> event driven system data operations are necessary.
> >>>>
> >>>> Of course! But those data operations are on the data flows between
> >>>> Computational components, _not_ on the event flows between the
> >>>> Coordinator and the Computational components. _That_ is separation
> >>>> of
> >>>> concerns! :-)
> >>>
> >>> I am not convinced that a Coordination FSM can only coordinate using
> >>> pure events (by pure i mean: carrying only identity, nothing more)
> >>> and
> >>
> >> If you mean with "identity" that an event carries a name that
> >> identifies
> >> its origin, I agree.
> >>
> >>> be practically useful. But we can easily find out who is right by
> >>> looking at the various existing coordination FSM (which do use and
> >>> manipulate data) and see how well these could be refactored
> >>> according
> >>> to your suggestion :-)
> >>
> >> Good!
> >>
> >>>>>>>> DSL that can be formally verified, from which code can be
> >>>>>>>> generated, and that has no possible side effects.
> >>>>>>>> What you are now supporting users to add is against all
> >>>>>>>> these design specifications...
> >>>>>>>>
> >>>>>>>>>> backdoor that the "featuritis" creeps in. Please,
> >>>>>>>>>> let's use
> >>>>>>>>>> another language for the deployment scripting! Nothing
> >>>>>>>>>> wroing
> >>>>>>>>>> with Python there, since there is no hard realtime
> >>>>>>>>>> need. Also
> >>>>>>>>>> nothing wrong with Java, since that's where "the big
> >>>>>>>>>> masses" are
> >>>>>>>>>> (including Eclipse support...).
> >>>>>>>>>
> >>>>>>>>> I disagree that using Python or Java would have any
> >>>>>>>>> advantage
> >>>>>>>>> here. These are only "other" general purpose languages
> >>>>>>>>> and adding
> >>>>>>>>> bindings for them would be a lot of work with no real
> >>>>>>>>> gain. On the other side I think it would be beneficial
> >>>>>>>>> to use a standardized model of deployment supported by
> >>>>>>>>> Eclipse. But that's a question about the right model,
> >>>>>>>>> not the right language.
> >>>>>>>>
> >>>>>>>> Both. For users like Nick, the language _is_ the model.
> >>>>>>>> So, let's
> >>>>>>>> not make it so damned easy for them to screw up the model,
> >>>>>>>> by
> >>>>>>>> adding "stuff" to the DSL meta language.
> >>>>>>>
> >>>>>>> But both are separate: the FSM DSL is (indentionally!)
> >>>>>>> independent
> >>>>>>> and agnostic of RTT. It may use the primitives provided by
> >>>>>>> the
> >>>>>>> framework bindings. If is is bad practice to use a certain
> >>>>>>> primitive (which could indeed be the case!) the constraint
> >>>>>>> to prevent this should not be added at either of the
> >>>>>>> _mechanisms_ FSM-DSL or rttlua bindings; here we should
> >>>>>>> follow the Unix best practice:
> >>>>>>>
> >>>>>>> "UNIX was not designed to stop you from doing stupid things,
> >>>>>>> because that would also stop you from doing clever things."
> >>>>>>> - Doug Gwyn
> >>>>>>
> >>>>>> Hence, UNIX _never_ made it into MDE toolchains... The
> >>>>>> robotics world is a bit (too) full of
> >>>>>> guys-on-UNIX-steroids... UNIX worked well 40 years ago. It
> >>>>>> still does, but not in an MDE world.
> >>>>>>
> >>>>>>> The right place for constraining the user, IMHO, would be
> >>>>>>> the
> >>>>>>> graphical modeling toolchain.
> >>>>>>>
> >>>>>>> Would you agree?
> >>>>>>
> >>>>>> That is the easiest part yes. But this toolchaain will be
> >>>>>> practically useless since we stimulate all the functionality
> >>>>>> contributors to screw the modelling separations...
> >>>>>
> >>>>> It is trivially possible to restrict the primitives that can be
> >>>>> used
> >>>>> in a DSL.
> >>>>
> >>>> Yes. So we should make these things clear, and provide the
> >>>> explicit
> >>>> software support for it.
> >>>>
> >>>>> However, it is not yet clear to me which ones "screw the
> >>>>> separations" and this should be excluded.
> >>>>
> >>>> The 'data carrying events' are the ones that screw things up for
> >>>> keeping the Coordination separated from the Computations.
> >>>> In addition, the current situation, users (and obviously also most
> >>>> developers) do not see the distinction between "Lua as a
> >>>> Coordination
> >>>> DSL" and "Lua as an RTT scripting language", and that's also
> >>>> screwing
> >>>> up things for the former.
> >>>
> >>> The distinction might indeed not be so clear. However Lua is not a
> >>> "Coordination DSL"! There are three orthogonal things here:
> >>>
> >>> 1. rFSM: which _is_ a Coordination DSL (built in Lua for some
> >>>
> >>> reasons) and can make use of bindings to various robotic
> >>> frameworks such as rttlua but also roslua (see below).
> >>>
> >>> 2. Lua: a general purpose scripting language which focusses on
> >>>
> >>> embeddability and extensibilty and is suitable for building
> >>> DSL.
> >>>
> >>> 3. the rttlua bindings which allow to use a subset of the RTT
> >>>
> >>> concepts within Lua.
> >>
> >> Good summary, to which I completely agree. But the users
> >> commenting/requesting on the mailing list do not make this difference:
> >> they just see "Lua", irrespective of the structure that you and I put
> >> into the (to be decoupled) uses of Lua in. Do you have the same
> >> feeling?
> >
> > As a user I don't agree.
> > Some users are willing to take into account the 5Cs and the decoupling
> > you propose. They however don't want to learn 5 different programming
> > languages to support each of the C's. As a user I really object to
> > introduce a different programming language for every concern. Rather
> > give the users some good examples (or best practices) that show how you
> > can separate the 5Cs in practice.
>
> First of all, the _real_ users will, eventually, only see what the
> toolchain provides. Currently, we only have _developers_. And yes, they
> will have to learn five different "programming languages", but each of them
> will be deceptively simple.
>
> >>>> Concrete constructive suggestion:
> >>>> - let's start formalizing the Coordination rFSM now, in such a way
> >>>> that a
> >>>>
> >>>> tool can check whether only "pure" coordination language
> >>>> constructs
> >>>> are being used.
> >>>>
> >>>> - let's write a documentation document that explains the
> >>>> differences
> >>>>
> >>>> between "Lua as a Coordination DSL" and "Lua as an RTT
> >>>> scripting
> >>>> language", including guidelines for users about how to work
> >>>> with
> >>>> both.
> >>>
> >>> In terms of documentation I have started to document "good use" in
> >>> terms of the LuaCookbook, but it's an ongoing effort.
> >>
> >> Much appreciated!
> >>
> >>>> This document will be core of our PhD anyway! (Otherwise, nobody
> >>>> will be impressed by it :-)
> >>>
> >>> Agreed :-)
> >
> > As I'm reading the discussion I really think we should make the
> > separation between the programming language (for instance LUA) and the
> > functionality provided (for instance state machines for coordination).
>
> Indeed. But this separation should be _enforcable_ (at least in the
> toolchain), and not rely on discipline by good developers. The latter has
> chosen not to work, since most developers do not have that discipline.
>
> > According to me there is not need to use a different programming
> > language for every functionality (or C).
>
> There are definitely different concepts to be represented, hence a
> different "programming language". We should start using the moniker "DSL",
> instead of programming language. The same language _could_ be below the
> DSLs, but the concrete progamming language should be (enforceably!)
> invisible, and only the strict DSLs should be used.
Ok, I agree on this one. But that also means that the original message from
Nick to extend the rttlua bindings was not wrong. He was not asking to
extend/change the Coordination DSL (rFSM), but only to extend the rttlua
bindings.
> > Tinne
>
> Thanks for your "user" inputs!
>
> Herman
-- Ruben
lua wishlist [continuted from orocos-users]
On Mon, 30 May 2011, Ruben Smits wrote:
> On Monday 30 May 2011 11:07:39 Herman Bruyninckx wrote:
>> On Mon, 30 May 2011, Tinne De Laet wrote:
>>> On Monday 30 May 2011 10:32:37 Herman Bruyninckx wrote:
>>>> On Mon, 30 May 2011, Markus Klotzbuecher wrote:
>>>>> On Sat, May 28, 2011 at 05:48:06PM +0200, Herman Bruyninckx wrote:
>>>>>> On Sat, 28 May 2011, Markus Klotzbuecher wrote:
>>>>>>> On Sat, May 28, 2011 at 12:21:47AM +0200, Herman Bruyninckx wrote:
>>>>>>>> On Fri, 27 May 2011, Markus Klotzbuecher wrote:
>>>>>>>>> On Fri, May 27, 2011 at 12:39:53PM +0200, Herman Bruyninckx wrote:
>>>>>>>>>> On Fri, 27 May 2011, Markus Klotzbuecher wrote:
>>>>>>>>>>> On Fri, May 27, 2011 at 11:50:01AM +0200, Herman Bruyninckx wrote:
>>>>>>>>>>>> On Fri, 27 May 2011, Markus Klotzbuecher wrote:
>>>>>>>>>>>>> On Thu, May 26, 2011 at 07:10:21PM +0200, Herman Bruyninckx
> wrote:
>>>>>>>>> ...
>>>>>>>>>
>>>>>>>>>>>>>> I've seen way too many projects loose there
>>>>>>>>>>>>>> competitive
>>>>>>>>>>>>>> advantage by trying to hit every nail by the (nice
>>>>>>>>>>>>>> but limited, by design!) hammer they have...
>>>>>>>>>>>>>
>>>>>>>>>>>>> Yes, and we're not falling into that trap :-)
>>>>>>>>>>>>
>>>>>>>>>>>> I would like to see a proof of that... Because this is
>>>>>>>>>>>> the trap
>>>>>>>>>>>> that I see growing before our noses: Lua was
>>>>>>>>>>>> introduced in RTT
>>>>>>>>>>>> for the sole purpose of doing Coordination, not
>>>>>>>>>>>> needing much
>>>>>>>>>>>> "data processing" capabilities at all. Now, the trend
>>>>>>>>>>>> is growing
>>>>>>>>>>>> to use Lua for a very different purpose, namely as the
>>>>>>>>>>>> scripting
>>>>>>>>>>>> language for doing dynamci deployment. And it is via
>>>>>>>>>>>> this
>>>>>>>>>>>
>>>>>>>>>>> Coordination and dynamic deployment are strongly
>>>>>>>>>>> related. For this reason the "mechanism" to support
>>>>>>>>>>> coordination (like starting and stopping components,
>>>>>>>>>>> (re) connecting ports etc.) are also suitable for
>>>>>>>>>>> deployment. The nice thing about implementing DSLs in
>>>>>>>>>>> scripting languages like Lua or Ruby is that new
>>>>>>>>>>> solutions can be explored _without_ bloating core RTT.
>>>>>>>>>>
>>>>>>>>>> As long as you stick to the DSL that does the FSM, I am
>>>>>>>>>> fully with
>>>>>>>>>> you. But as soon as you start adding 'data operations', I
>>>>>>>>>> am not! I want to have a
>>>>>>>>>
>>>>>>>>> How do you define data operations? If you mean accessing and
>>>>>>>>> modifying data objects, then how could a Statemachine do
>>>>>>>>> anything
>>>>>>>>> useful without? Almost any coordination needs to invoke some
>>>>>>>>> operation with some arguments... moveTo(pos),
>>>>>>>>> sendevent(event) etc.
>>>>>>>>
>>>>>>>> No: it should send out _events_ that let other components do
>>>>>>>> these
>>>>>>>> things, or configure them.
>>>>>>>
>>>>>>> You know I agree and would prefer FSM to communicate purely
>>>>>>> event/message based, however in practice this is difficult
>>>>>>> because of
>>>>>>> the following reasons:
>>>>>>>
>>>>>>> 1. most of the existing components are not implemented this way,
>>>>>>> but
>>>>>>>
>>>>>>> offer synchronous or asynchronous operations. Of course
>>>>>>> these can
>>>>>>> be refactored and indeed several already have been,
>>>>>>> nevertheless it
>>>>>>> must be possible to deal with legacy.
>>>>>>
>>>>>> Legacy is a reality indeed. But dealing with legacy should not, I
>>>>>> repeat, not, compromise the MDE future of Orocos. In that case,
>>>>>> let's
>>>>>> stop now, because the project is going to be dead anyway in a
>>>>>> couple of more legacy-before-everything years.
>>>>>>
>>>>>> So, the real question we face is: how to keep both goals nicely
>>>>>> separated..? The obvious answer is:
>>>>>> 1. support legacy for your current major version;
>>>>>> 2. make sure the legacy does not trickle down in your new major
>>>>>> version. 3. be clever enough to do both 1. and 2., without making
>>>>>> the refactoring
>>>>>>
>>>>>> from 1. to 2. impossible.
>>>>>>
>>>>>> You are helping users with 1., I am trying to scare away everyone
>>>>>> from
>>>>>> 1., because of 2. We should both work together to provide a "this
>>>>>> is
>>>>>> how you _should_ do it" answer to all requesters for 1. Which we
>>>>>> have
>>>>>> to do for 3. anyway.
>>>>>
>>>>> Ok, fine! The challenge with this however, is to convince the
>>>>> substantial group of people which strongly disagrees that a
>>>>> particular
>>>>> primitive actually is legacy, and not a really neat feature.
>>>>
>>>> That's a challenge indeed. And the only "weight" I can bring behind my
>>>> arguments is that I have made the featuritis error myself too many
>>>> times, and I don't want to go there anymore. If the majority of
>>>> stakeholders in RTT want to do it differently, they will kill the
>>>> long-term goals.
>>>>
>>>> I would prefer to have the discussions on technical grounds, so _if_
>>>> you
>>>> agree on 5C separation of concerns, you _have_ to agree with me that
>>>> "Computations" do not belong in "Coordination", don't you? Hence,
>>>> adding
>>>> Lua support for data flow and operations should not be done.
>>>
>>> I don't agree.
>>> First objection (not from a user perspective): the events are based on
>>> dataFlow (they come over dataports).
>>
>> That's one of these "legacy" things: _because_ the underlying transport is
>> basically the same, this was allowed to "shine through" to the users, and
>> now they are not making the distinction anymore between "data carrying"
>> messages and "event" messages. In other words, the first step towards
>> "decay" of the nice decoupling models.
>>
>>> Second objection: computations indeed don't belong in the LuaRFSM but
>>> why is it wrong to provide support for the Lua programming language?
>>> Again: As a user I want to use the same programming language as much as
>>> possible but ofcourse I'm willing to separate my coding according to the
>>> 5C's!
>>
>> There is nothing wrong with these things, but the Orocos design has to be
>> such that users can _only_ do it right. That's not the case now, as far as
>> I can see. (And I confess I do not see everything.)
>>
>>>>>> At the end of this message, there is a concrete suggestion about
>>>>>> 3.
>>>>>>
>>>>>>> 2. multi-argument operations require definition/generation of
>>>>>>> new
>>>>>>>
>>>>>>> types: take for instance a simple trajectory generator
>>>>>>> which takes
>>>>>>> three arguments: start and end pose and a duration. To
>>>>>>> turn this
>>>>>>> call into a "command event" a new type containing these
>>>>>>> three
>>>>>>> fields needs to be defined/implemented/generated. Extra
>>>>>>> effort,
>>>>>>> previously not required.
>>>>>>
>>>>>> So, events should carry no data! The data is in the data flows,
>>>>>> the
>>>>>> events in the event flow. A Coordination state machine component
>>>>>> should only work with event flows. In other words, a Coordinator
>>>>>> should never exchange any "commands" with whichever other
>>>>>> Component.
>>>>>>
>>>>>>> 3. Most importantly, unless you "discretize the world", events
>>>>>>> will
>>>>>>>
>>>>>>> always carry a "continuous data payload": in the
>>>>>>> trajectory
>>>>>>> generator example the poses and duration. Hence even in a
>>>>>>> pure
>>>>>>> event driven system data operations are necessary.
>>>>>>
>>>>>> Of course! But those data operations are on the data flows between
>>>>>> Computational components, _not_ on the event flows between the
>>>>>> Coordinator and the Computational components. _That_ is separation
>>>>>> of
>>>>>> concerns! :-)
>>>>>
>>>>> I am not convinced that a Coordination FSM can only coordinate using
>>>>> pure events (by pure i mean: carrying only identity, nothing more)
>>>>> and
>>>>
>>>> If you mean with "identity" that an event carries a name that
>>>> identifies
>>>> its origin, I agree.
>>>>
>>>>> be practically useful. But we can easily find out who is right by
>>>>> looking at the various existing coordination FSM (which do use and
>>>>> manipulate data) and see how well these could be refactored
>>>>> according
>>>>> to your suggestion :-)
>>>>
>>>> Good!
>>>>
>>>>>>>>>> DSL that can be formally verified, from which code can be
>>>>>>>>>> generated, and that has no possible side effects.
>>>>>>>>>> What you are now supporting users to add is against all
>>>>>>>>>> these design specifications...
>>>>>>>>>>
>>>>>>>>>>>> backdoor that the "featuritis" creeps in. Please,
>>>>>>>>>>>> let's use
>>>>>>>>>>>> another language for the deployment scripting! Nothing
>>>>>>>>>>>> wroing
>>>>>>>>>>>> with Python there, since there is no hard realtime
>>>>>>>>>>>> need. Also
>>>>>>>>>>>> nothing wrong with Java, since that's where "the big
>>>>>>>>>>>> masses" are
>>>>>>>>>>>> (including Eclipse support...).
>>>>>>>>>>>
>>>>>>>>>>> I disagree that using Python or Java would have any
>>>>>>>>>>> advantage
>>>>>>>>>>> here. These are only "other" general purpose languages
>>>>>>>>>>> and adding
>>>>>>>>>>> bindings for them would be a lot of work with no real
>>>>>>>>>>> gain. On the other side I think it would be beneficial
>>>>>>>>>>> to use a standardized model of deployment supported by
>>>>>>>>>>> Eclipse. But that's a question about the right model,
>>>>>>>>>>> not the right language.
>>>>>>>>>>
>>>>>>>>>> Both. For users like Nick, the language _is_ the model.
>>>>>>>>>> So, let's
>>>>>>>>>> not make it so damned easy for them to screw up the model,
>>>>>>>>>> by
>>>>>>>>>> adding "stuff" to the DSL meta language.
>>>>>>>>>
>>>>>>>>> But both are separate: the FSM DSL is (indentionally!)
>>>>>>>>> independent
>>>>>>>>> and agnostic of RTT. It may use the primitives provided by
>>>>>>>>> the
>>>>>>>>> framework bindings. If is is bad practice to use a certain
>>>>>>>>> primitive (which could indeed be the case!) the constraint
>>>>>>>>> to prevent this should not be added at either of the
>>>>>>>>> _mechanisms_ FSM-DSL or rttlua bindings; here we should
>>>>>>>>> follow the Unix best practice:
>>>>>>>>>
>>>>>>>>> "UNIX was not designed to stop you from doing stupid things,
>>>>>>>>> because that would also stop you from doing clever things."
>>>>>>>>> - Doug Gwyn
>>>>>>>>
>>>>>>>> Hence, UNIX _never_ made it into MDE toolchains... The
>>>>>>>> robotics world is a bit (too) full of
>>>>>>>> guys-on-UNIX-steroids... UNIX worked well 40 years ago. It
>>>>>>>> still does, but not in an MDE world.
>>>>>>>>
>>>>>>>>> The right place for constraining the user, IMHO, would be
>>>>>>>>> the
>>>>>>>>> graphical modeling toolchain.
>>>>>>>>>
>>>>>>>>> Would you agree?
>>>>>>>>
>>>>>>>> That is the easiest part yes. But this toolchaain will be
>>>>>>>> practically useless since we stimulate all the functionality
>>>>>>>> contributors to screw the modelling separations...
>>>>>>>
>>>>>>> It is trivially possible to restrict the primitives that can be
>>>>>>> used
>>>>>>> in a DSL.
>>>>>>
>>>>>> Yes. So we should make these things clear, and provide the
>>>>>> explicit
>>>>>> software support for it.
>>>>>>
>>>>>>> However, it is not yet clear to me which ones "screw the
>>>>>>> separations" and this should be excluded.
>>>>>>
>>>>>> The 'data carrying events' are the ones that screw things up for
>>>>>> keeping the Coordination separated from the Computations.
>>>>>> In addition, the current situation, users (and obviously also most
>>>>>> developers) do not see the distinction between "Lua as a
>>>>>> Coordination
>>>>>> DSL" and "Lua as an RTT scripting language", and that's also
>>>>>> screwing
>>>>>> up things for the former.
>>>>>
>>>>> The distinction might indeed not be so clear. However Lua is not a
>>>>> "Coordination DSL"! There are three orthogonal things here:
>>>>>
>>>>> 1. rFSM: which _is_ a Coordination DSL (built in Lua for some
>>>>>
>>>>> reasons) and can make use of bindings to various robotic
>>>>> frameworks such as rttlua but also roslua (see below).
>>>>>
>>>>> 2. Lua: a general purpose scripting language which focusses on
>>>>>
>>>>> embeddability and extensibilty and is suitable for building
>>>>> DSL.
>>>>>
>>>>> 3. the rttlua bindings which allow to use a subset of the RTT
>>>>>
>>>>> concepts within Lua.
>>>>
>>>> Good summary, to which I completely agree. But the users
>>>> commenting/requesting on the mailing list do not make this difference:
>>>> they just see "Lua", irrespective of the structure that you and I put
>>>> into the (to be decoupled) uses of Lua in. Do you have the same
>>>> feeling?
>>>
>>> As a user I don't agree.
>>> Some users are willing to take into account the 5Cs and the decoupling
>>> you propose. They however don't want to learn 5 different programming
>>> languages to support each of the C's. As a user I really object to
>>> introduce a different programming language for every concern. Rather
>>> give the users some good examples (or best practices) that show how you
>>> can separate the 5Cs in practice.
>>
>> First of all, the _real_ users will, eventually, only see what the
>> toolchain provides. Currently, we only have _developers_. And yes, they
>> will have to learn five different "programming languages", but each of them
>> will be deceptively simple.
>>
>>>>>> Concrete constructive suggestion:
>>>>>> - let's start formalizing the Coordination rFSM now, in such a way
>>>>>> that a
>>>>>>
>>>>>> tool can check whether only "pure" coordination language
>>>>>> constructs
>>>>>> are being used.
>>>>>>
>>>>>> - let's write a documentation document that explains the
>>>>>> differences
>>>>>>
>>>>>> between "Lua as a Coordination DSL" and "Lua as an RTT
>>>>>> scripting
>>>>>> language", including guidelines for users about how to work
>>>>>> with
>>>>>> both.
>>>>>
>>>>> In terms of documentation I have started to document "good use" in
>>>>> terms of the LuaCookbook, but it's an ongoing effort.
>>>>
>>>> Much appreciated!
>>>>
>>>>>> This document will be core of our PhD anyway! (Otherwise, nobody
>>>>>> will be impressed by it :-)
>>>>>
>>>>> Agreed :-)
>>>
>>> As I'm reading the discussion I really think we should make the
>>> separation between the programming language (for instance LUA) and the
>>> functionality provided (for instance state machines for coordination).
>>
>> Indeed. But this separation should be _enforcable_ (at least in the
>> toolchain), and not rely on discipline by good developers. The latter has
>> chosen not to work, since most developers do not have that discipline.
>>
>>> According to me there is not need to use a different programming
>>> language for every functionality (or C).
>>
>> There are definitely different concepts to be represented, hence a
>> different "programming language". We should start using the moniker "DSL",
>> instead of programming language. The same language _could_ be below the
>> DSLs, but the concrete progamming language should be (enforceably!)
>> invisible, and only the strict DSLs should be used.
>
> Ok, I agree on this one. But that also means that the original message from
> Nick to extend the rttlua bindings was not wrong. He was not asking to
> extend/change the Coordination DSL (rFSM), but only to extend the rttlua
> bindings.
For use in the Coordination state machine... I qoute from his original posting:
"*I want to set an attribute in my statemachines, which is currently
unsupported?! (only properties, but I don't want to change it to a property)
something like:
CMWyGlobal = peertable.Scene:getAttribute("CartesianMotion_Wy_global")
CMWyGlobal:set(1.0)
"
And_ we still have no idea how to keep Lua-as-a-programming-language
invisibly hidden behind the screens.
Herman
lua wishlist [continuted from orocos-users]
On Mon, May 30, 2011 at 12:59:55PM +0200, Herman Bruyninckx wrote:
> On Mon, 30 May 2011, Ruben Smits wrote:
>
> > On Monday 30 May 2011 11:07:39 Herman Bruyninckx wrote:
> >> On Mon, 30 May 2011, Tinne De Laet wrote:
> >>> On Monday 30 May 2011 10:32:37 Herman Bruyninckx wrote:
> >>>> On Mon, 30 May 2011, Markus Klotzbuecher wrote:
> >>>>> On Sat, May 28, 2011 at 05:48:06PM +0200, Herman Bruyninckx wrote:
> >>>>>> On Sat, 28 May 2011, Markus Klotzbuecher wrote:
> >>>>>>> On Sat, May 28, 2011 at 12:21:47AM +0200, Herman Bruyninckx wrote:
> >>>>>>>> On Fri, 27 May 2011, Markus Klotzbuecher wrote:
> >>>>>>>>> On Fri, May 27, 2011 at 12:39:53PM +0200, Herman Bruyninckx wrote:
> >>>>>>>>>> On Fri, 27 May 2011, Markus Klotzbuecher wrote:
> >>>>>>>>>>> On Fri, May 27, 2011 at 11:50:01AM +0200, Herman Bruyninckx wrote:
> >>>>>>>>>>>> On Fri, 27 May 2011, Markus Klotzbuecher wrote:
> >>>>>>>>>>>>> On Thu, May 26, 2011 at 07:10:21PM +0200, Herman Bruyninckx
> > wrote:
> >>>>>>>>> ...
> >>>>>>>>>
> >>>>>>>>>>>>>> I've seen way too many projects loose there
> >>>>>>>>>>>>>> competitive
> >>>>>>>>>>>>>> advantage by trying to hit every nail by the (nice
> >>>>>>>>>>>>>> but limited, by design!) hammer they have...
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> Yes, and we're not falling into that trap :-)
> >>>>>>>>>>>>
> >>>>>>>>>>>> I would like to see a proof of that... Because this is
> >>>>>>>>>>>> the trap
> >>>>>>>>>>>> that I see growing before our noses: Lua was
> >>>>>>>>>>>> introduced in RTT
> >>>>>>>>>>>> for the sole purpose of doing Coordination, not
> >>>>>>>>>>>> needing much
> >>>>>>>>>>>> "data processing" capabilities at all. Now, the trend
> >>>>>>>>>>>> is growing
> >>>>>>>>>>>> to use Lua for a very different purpose, namely as the
> >>>>>>>>>>>> scripting
> >>>>>>>>>>>> language for doing dynamci deployment. And it is via
> >>>>>>>>>>>> this
> >>>>>>>>>>>
> >>>>>>>>>>> Coordination and dynamic deployment are strongly
> >>>>>>>>>>> related. For this reason the "mechanism" to support
> >>>>>>>>>>> coordination (like starting and stopping components,
> >>>>>>>>>>> (re) connecting ports etc.) are also suitable for
> >>>>>>>>>>> deployment. The nice thing about implementing DSLs in
> >>>>>>>>>>> scripting languages like Lua or Ruby is that new
> >>>>>>>>>>> solutions can be explored _without_ bloating core RTT.
> >>>>>>>>>>
> >>>>>>>>>> As long as you stick to the DSL that does the FSM, I am
> >>>>>>>>>> fully with
> >>>>>>>>>> you. But as soon as you start adding 'data operations', I
> >>>>>>>>>> am not! I want to have a
> >>>>>>>>>
> >>>>>>>>> How do you define data operations? If you mean accessing and
> >>>>>>>>> modifying data objects, then how could a Statemachine do
> >>>>>>>>> anything
> >>>>>>>>> useful without? Almost any coordination needs to invoke some
> >>>>>>>>> operation with some arguments... moveTo(pos),
> >>>>>>>>> sendevent(event) etc.
> >>>>>>>>
> >>>>>>>> No: it should send out _events_ that let other components do
> >>>>>>>> these
> >>>>>>>> things, or configure them.
> >>>>>>>
> >>>>>>> You know I agree and would prefer FSM to communicate purely
> >>>>>>> event/message based, however in practice this is difficult
> >>>>>>> because of
> >>>>>>> the following reasons:
> >>>>>>>
> >>>>>>> 1. most of the existing components are not implemented this way,
> >>>>>>> but
> >>>>>>>
> >>>>>>> offer synchronous or asynchronous operations. Of course
> >>>>>>> these can
> >>>>>>> be refactored and indeed several already have been,
> >>>>>>> nevertheless it
> >>>>>>> must be possible to deal with legacy.
> >>>>>>
> >>>>>> Legacy is a reality indeed. But dealing with legacy should not, I
> >>>>>> repeat, not, compromise the MDE future of Orocos. In that case,
> >>>>>> let's
> >>>>>> stop now, because the project is going to be dead anyway in a
> >>>>>> couple of more legacy-before-everything years.
> >>>>>>
> >>>>>> So, the real question we face is: how to keep both goals nicely
> >>>>>> separated..? The obvious answer is:
> >>>>>> 1. support legacy for your current major version;
> >>>>>> 2. make sure the legacy does not trickle down in your new major
> >>>>>> version. 3. be clever enough to do both 1. and 2., without making
> >>>>>> the refactoring
> >>>>>>
> >>>>>> from 1. to 2. impossible.
> >>>>>>
> >>>>>> You are helping users with 1., I am trying to scare away everyone
> >>>>>> from
> >>>>>> 1., because of 2. We should both work together to provide a "this
> >>>>>> is
> >>>>>> how you _should_ do it" answer to all requesters for 1. Which we
> >>>>>> have
> >>>>>> to do for 3. anyway.
> >>>>>
> >>>>> Ok, fine! The challenge with this however, is to convince the
> >>>>> substantial group of people which strongly disagrees that a
> >>>>> particular
> >>>>> primitive actually is legacy, and not a really neat feature.
> >>>>
> >>>> That's a challenge indeed. And the only "weight" I can bring behind my
> >>>> arguments is that I have made the featuritis error myself too many
> >>>> times, and I don't want to go there anymore. If the majority of
> >>>> stakeholders in RTT want to do it differently, they will kill the
> >>>> long-term goals.
> >>>>
> >>>> I would prefer to have the discussions on technical grounds, so _if_
> >>>> you
> >>>> agree on 5C separation of concerns, you _have_ to agree with me that
> >>>> "Computations" do not belong in "Coordination", don't you? Hence,
> >>>> adding
> >>>> Lua support for data flow and operations should not be done.
> >>>
> >>> I don't agree.
> >>> First objection (not from a user perspective): the events are based on
> >>> dataFlow (they come over dataports).
> >>
> >> That's one of these "legacy" things: _because_ the underlying transport is
> >> basically the same, this was allowed to "shine through" to the users, and
> >> now they are not making the distinction anymore between "data carrying"
> >> messages and "event" messages. In other words, the first step towards
> >> "decay" of the nice decoupling models.
> >>
> >>> Second objection: computations indeed don't belong in the LuaRFSM but
> >>> why is it wrong to provide support for the Lua programming language?
> >>> Again: As a user I want to use the same programming language as much as
> >>> possible but ofcourse I'm willing to separate my coding according to the
> >>> 5C's!
> >>
> >> There is nothing wrong with these things, but the Orocos design has to be
> >> such that users can _only_ do it right. That's not the case now, as far as
> >> I can see. (And I confess I do not see everything.)
> >>
> >>>>>> At the end of this message, there is a concrete suggestion about
> >>>>>> 3.
> >>>>>>
> >>>>>>> 2. multi-argument operations require definition/generation of
> >>>>>>> new
> >>>>>>>
> >>>>>>> types: take for instance a simple trajectory generator
> >>>>>>> which takes
> >>>>>>> three arguments: start and end pose and a duration. To
> >>>>>>> turn this
> >>>>>>> call into a "command event" a new type containing these
> >>>>>>> three
> >>>>>>> fields needs to be defined/implemented/generated. Extra
> >>>>>>> effort,
> >>>>>>> previously not required.
> >>>>>>
> >>>>>> So, events should carry no data! The data is in the data flows,
> >>>>>> the
> >>>>>> events in the event flow. A Coordination state machine component
> >>>>>> should only work with event flows. In other words, a Coordinator
> >>>>>> should never exchange any "commands" with whichever other
> >>>>>> Component.
> >>>>>>
> >>>>>>> 3. Most importantly, unless you "discretize the world", events
> >>>>>>> will
> >>>>>>>
> >>>>>>> always carry a "continuous data payload": in the
> >>>>>>> trajectory
> >>>>>>> generator example the poses and duration. Hence even in a
> >>>>>>> pure
> >>>>>>> event driven system data operations are necessary.
> >>>>>>
> >>>>>> Of course! But those data operations are on the data flows between
> >>>>>> Computational components, _not_ on the event flows between the
> >>>>>> Coordinator and the Computational components. _That_ is separation
> >>>>>> of
> >>>>>> concerns! :-)
> >>>>>
> >>>>> I am not convinced that a Coordination FSM can only coordinate using
> >>>>> pure events (by pure i mean: carrying only identity, nothing more)
> >>>>> and
> >>>>
> >>>> If you mean with "identity" that an event carries a name that
> >>>> identifies
> >>>> its origin, I agree.
> >>>>
> >>>>> be practically useful. But we can easily find out who is right by
> >>>>> looking at the various existing coordination FSM (which do use and
> >>>>> manipulate data) and see how well these could be refactored
> >>>>> according
> >>>>> to your suggestion :-)
> >>>>
> >>>> Good!
> >>>>
> >>>>>>>>>> DSL that can be formally verified, from which code can be
> >>>>>>>>>> generated, and that has no possible side effects.
> >>>>>>>>>> What you are now supporting users to add is against all
> >>>>>>>>>> these design specifications...
> >>>>>>>>>>
> >>>>>>>>>>>> backdoor that the "featuritis" creeps in. Please,
> >>>>>>>>>>>> let's use
> >>>>>>>>>>>> another language for the deployment scripting! Nothing
> >>>>>>>>>>>> wroing
> >>>>>>>>>>>> with Python there, since there is no hard realtime
> >>>>>>>>>>>> need. Also
> >>>>>>>>>>>> nothing wrong with Java, since that's where "the big
> >>>>>>>>>>>> masses" are
> >>>>>>>>>>>> (including Eclipse support...).
> >>>>>>>>>>>
> >>>>>>>>>>> I disagree that using Python or Java would have any
> >>>>>>>>>>> advantage
> >>>>>>>>>>> here. These are only "other" general purpose languages
> >>>>>>>>>>> and adding
> >>>>>>>>>>> bindings for them would be a lot of work with no real
> >>>>>>>>>>> gain. On the other side I think it would be beneficial
> >>>>>>>>>>> to use a standardized model of deployment supported by
> >>>>>>>>>>> Eclipse. But that's a question about the right model,
> >>>>>>>>>>> not the right language.
> >>>>>>>>>>
> >>>>>>>>>> Both. For users like Nick, the language _is_ the model.
> >>>>>>>>>> So, let's
> >>>>>>>>>> not make it so damned easy for them to screw up the model,
> >>>>>>>>>> by
> >>>>>>>>>> adding "stuff" to the DSL meta language.
> >>>>>>>>>
> >>>>>>>>> But both are separate: the FSM DSL is (indentionally!)
> >>>>>>>>> independent
> >>>>>>>>> and agnostic of RTT. It may use the primitives provided by
> >>>>>>>>> the
> >>>>>>>>> framework bindings. If is is bad practice to use a certain
> >>>>>>>>> primitive (which could indeed be the case!) the constraint
> >>>>>>>>> to prevent this should not be added at either of the
> >>>>>>>>> _mechanisms_ FSM-DSL or rttlua bindings; here we should
> >>>>>>>>> follow the Unix best practice:
> >>>>>>>>>
> >>>>>>>>> "UNIX was not designed to stop you from doing stupid things,
> >>>>>>>>> because that would also stop you from doing clever things."
> >>>>>>>>> - Doug Gwyn
> >>>>>>>>
> >>>>>>>> Hence, UNIX _never_ made it into MDE toolchains... The
> >>>>>>>> robotics world is a bit (too) full of
> >>>>>>>> guys-on-UNIX-steroids... UNIX worked well 40 years ago. It
> >>>>>>>> still does, but not in an MDE world.
> >>>>>>>>
> >>>>>>>>> The right place for constraining the user, IMHO, would be
> >>>>>>>>> the
> >>>>>>>>> graphical modeling toolchain.
> >>>>>>>>>
> >>>>>>>>> Would you agree?
> >>>>>>>>
> >>>>>>>> That is the easiest part yes. But this toolchaain will be
> >>>>>>>> practically useless since we stimulate all the functionality
> >>>>>>>> contributors to screw the modelling separations...
> >>>>>>>
> >>>>>>> It is trivially possible to restrict the primitives that can be
> >>>>>>> used
> >>>>>>> in a DSL.
> >>>>>>
> >>>>>> Yes. So we should make these things clear, and provide the
> >>>>>> explicit
> >>>>>> software support for it.
> >>>>>>
> >>>>>>> However, it is not yet clear to me which ones "screw the
> >>>>>>> separations" and this should be excluded.
> >>>>>>
> >>>>>> The 'data carrying events' are the ones that screw things up for
> >>>>>> keeping the Coordination separated from the Computations.
> >>>>>> In addition, the current situation, users (and obviously also most
> >>>>>> developers) do not see the distinction between "Lua as a
> >>>>>> Coordination
> >>>>>> DSL" and "Lua as an RTT scripting language", and that's also
> >>>>>> screwing
> >>>>>> up things for the former.
> >>>>>
> >>>>> The distinction might indeed not be so clear. However Lua is not a
> >>>>> "Coordination DSL"! There are three orthogonal things here:
> >>>>>
> >>>>> 1. rFSM: which _is_ a Coordination DSL (built in Lua for some
> >>>>>
> >>>>> reasons) and can make use of bindings to various robotic
> >>>>> frameworks such as rttlua but also roslua (see below).
> >>>>>
> >>>>> 2. Lua: a general purpose scripting language which focusses on
> >>>>>
> >>>>> embeddability and extensibilty and is suitable for building
> >>>>> DSL.
> >>>>>
> >>>>> 3. the rttlua bindings which allow to use a subset of the RTT
> >>>>>
> >>>>> concepts within Lua.
> >>>>
> >>>> Good summary, to which I completely agree. But the users
> >>>> commenting/requesting on the mailing list do not make this difference:
> >>>> they just see "Lua", irrespective of the structure that you and I put
> >>>> into the (to be decoupled) uses of Lua in. Do you have the same
> >>>> feeling?
> >>>
> >>> As a user I don't agree.
> >>> Some users are willing to take into account the 5Cs and the decoupling
> >>> you propose. They however don't want to learn 5 different programming
> >>> languages to support each of the C's. As a user I really object to
> >>> introduce a different programming language for every concern. Rather
> >>> give the users some good examples (or best practices) that show how you
> >>> can separate the 5Cs in practice.
> >>
> >> First of all, the _real_ users will, eventually, only see what the
> >> toolchain provides. Currently, we only have _developers_. And yes, they
> >> will have to learn five different "programming languages", but each of them
> >> will be deceptively simple.
> >>
> >>>>>> Concrete constructive suggestion:
> >>>>>> - let's start formalizing the Coordination rFSM now, in such a way
> >>>>>> that a
> >>>>>>
> >>>>>> tool can check whether only "pure" coordination language
> >>>>>> constructs
> >>>>>> are being used.
> >>>>>>
> >>>>>> - let's write a documentation document that explains the
> >>>>>> differences
> >>>>>>
> >>>>>> between "Lua as a Coordination DSL" and "Lua as an RTT
> >>>>>> scripting
> >>>>>> language", including guidelines for users about how to work
> >>>>>> with
> >>>>>> both.
> >>>>>
> >>>>> In terms of documentation I have started to document "good use" in
> >>>>> terms of the LuaCookbook, but it's an ongoing effort.
> >>>>
> >>>> Much appreciated!
> >>>>
> >>>>>> This document will be core of our PhD anyway! (Otherwise, nobody
> >>>>>> will be impressed by it :-)
> >>>>>
> >>>>> Agreed :-)
> >>>
> >>> As I'm reading the discussion I really think we should make the
> >>> separation between the programming language (for instance LUA) and the
> >>> functionality provided (for instance state machines for coordination).
> >>
> >> Indeed. But this separation should be _enforcable_ (at least in the
> >> toolchain), and not rely on discipline by good developers. The latter has
> >> chosen not to work, since most developers do not have that discipline.
> >>
> >>> According to me there is not need to use a different programming
> >>> language for every functionality (or C).
> >>
> >> There are definitely different concepts to be represented, hence a
> >> different "programming language". We should start using the moniker "DSL",
> >> instead of programming language. The same language _could_ be below the
> >> DSLs, but the concrete progamming language should be (enforceably!)
> >> invisible, and only the strict DSLs should be used.
> >
> > Ok, I agree on this one. But that also means that the original message from
> > Nick to extend the rttlua bindings was not wrong. He was not asking to
> > extend/change the Coordination DSL (rFSM), but only to extend the rttlua
> > bindings.
>
> For use in the Coordination state machine... I qoute from his original posting:
>
> "*I want to set an attribute in my statemachines, which is currently
> unsupported?! (only properties, but I don't want to change it to a property)
> something like:
> CMWyGlobal = peertable.Scene:getAttribute("CartesianMotion_Wy_global")
> CMWyGlobal:set(1.0)
> "
>
> And_ we still have no idea how to keep Lua-as-a-programming-language
> invisibly hidden behind the screens.
I think keeping Lua (the language) hidden can and should not be the
goal. The only thing we might want to hide is a subset of the RTT
bindings available to a particular DSL.
Markus
lua wishlist [continuted from orocos-users]
On Mon, 30 May 2011, Markus Klotzbuecher wrote:
[...]
>>>> There are definitely different concepts to be represented, hence a
>>>> different "programming language". We should start using the moniker "DSL",
>>>> instead of programming language. The same language _could_ be below the
>>>> DSLs, but the concrete progamming language should be (enforceably!)
>>>> invisible, and only the strict DSLs should be used.
>>>
>>> Ok, I agree on this one. But that also means that the original message from
>>> Nick to extend the rttlua bindings was not wrong. He was not asking to
>>> extend/change the Coordination DSL (rFSM), but only to extend the rttlua
>>> bindings.
>>
>> For use in the Coordination state machine... I qoute from his original posting:
>>
>> "*I want to set an attribute in my statemachines, which is currently
>> unsupported?! (only properties, but I don't want to change it to a property)
>> something like:
>> CMWyGlobal = peertable.Scene:getAttribute("CartesianMotion_Wy_global")
>> CMWyGlobal:set(1.0)
>> "
>>
>> And_ we still have no idea how to keep Lua-as-a-programming-language
>> invisibly hidden behind the screens.
>
> I think keeping Lua (the language) hidden can and should not be the
> goal. The only thing we might want to hide is a subset of the RTT
> bindings available to a particular DSL.
I don't see the difference between both approaches. Unless the latter is
part of a "meta model", and the former part of the "model language". Which
would (maybe) be fine with me. I say "maybe", because I would first like to
see how the DSLs really will look like.
Herman
lua wishlist
On Sat, May 28, 2011 at 05:48:06PM +0200, Herman Bruyninckx wrote:
...
> It is also time to carry the discussion over to orocos-dev, in the form of
> the first draft of the mentioned document, with an invitation for comments.
... continued on orocos-dev
> A second step could be to use the result as a RFC for the
> Robot Engineering Task Force <https://retf.info />...
Yes, this would be great.
Markus
lua wishlist
On Friday 27 May 2011 11:50:01 Herman Bruyninckx wrote:
> On Fri, 27 May 2011, Markus Klotzbuecher wrote:
> > On Thu, May 26, 2011 at 07:10:21PM +0200, Herman Bruyninckx wrote:
> >> On Thu, 26 May 2011, Dominick Vanthienen wrote:
> >>> hi,
> >>>
> >>> i've "lua-fied" allmost everything of my current project
> >>> but...
> >>> *I want to set an attribute in my statemachines, which is currently
> >>> unsupported?! (only properties, but I don't want to change it to a
> >>> property) something like:
> >>> CMWyGlobal =
> >>> peertable.Scene:getAttribute("CartesianMotion_Wy_global")
> >>> CMWyGlobal:set(1.0)
> >>> *in the old rtt syntax I could initialize a kdl rotationmatrix with
> >>> RPY angles like: kdl_rot=KDL.Rotation(3.14159265,0.0,1.57) but this
> >>> isn't possible with lua, correct?
> >>> You have to give all matrix values:
> >>> kdl_rot:fromtab(
> >>> {X_z=0,Z_y=1,Y_y=-0.000796327,X_y=0,Y_z=1,Z_z=0.000796327,Y_x=0,Z_x
> >>> =0,X_x=-1} ) (which are btw ordered in a strange way if you print
> >>> the value (like above))
> >>>
> >>> Can I put some feature requests somewhere?
> >>
> >> Please, don't ask the Lua maintainer to turn the Lua support in Orocos
> >> into a full-fledged scripting language, kitchen sink included! I
> >> don't like to see the project go there: Lua should do Coordination,
> >> and nothing more. All "useful stuff" should be done by calling
> >> non-Lua functionalities, not by extending Lua to copy that stuff...
> >
> > Exactly! Thats the Lua philosophy!
> >
> >> For example: the Coordination should _not_ do data communication, let
> >> alone encode algorithms that compute when to fire events or
> >> transition states. All these computations should reside in
> >> "computational slaves" (hopefully the components that _are_ already
> >> there computing the functionality in the system!), and not in the
> >> FSM.
> >
> > Yes, Coordination delegates the computations. However, here Nick is
> > only using Coordination to do initial ocnfiguration, hence the need to
> > set an attribute.
> >
> >> I've seen way too many projects loose there competitive advantage by
> >> trying to hit every nail by the (nice but limited, by design!) hammer
> >> they have...
> >
> > Yes, and we're not falling into that trap :-)
>
> I would like to see a proof of that... Because this is the trap that I see
> growing before our noses: Lua was introduced in RTT for the sole purpose of
> doing Coordination, not needing much "data processing" capabilities at all.
> Now, the trend is growing to use Lua for a very different purpose, namely
> as the scripting language for doing dynamci deployment. And it is via this
> backdoor that the "featuritis" creeps in. Please, let's use another
> language for the deployment scripting! Nothing wroing with Python there,
> since there is no hard realtime need. Also nothing wrong with Java, since
> that's where "the big masses" are (including Eclipse support...).
Isn't the main advantage of Lua that you can easily create DSL's? So what's
wrong with a Lua Deployment DSL. There's a big difference between using Lua for
deployment and rFSM for deployment (which should be possible too IMO)
Secondly, Lua is the only external scripting language that has RTT bindings
ATM that I know of. (Maybe also Ruby??) Why should we create new bindings for
another scripting language and duplicate almost all work that has been done
for the Lua bindings, instead of adding the missing bindings to RTT for Lua,
and create a Lua Deployment DSL?
> > Markus
>
> Herman
-- Ruben
lua wishlist
On Fri, 27 May 2011, Ruben Smits wrote:
> On Friday 27 May 2011 11:50:01 Herman Bruyninckx wrote:
>> On Fri, 27 May 2011, Markus Klotzbuecher wrote:
>>> On Thu, May 26, 2011 at 07:10:21PM +0200, Herman Bruyninckx wrote:
>>>> On Thu, 26 May 2011, Dominick Vanthienen wrote:
>>>>> hi,
>>>>>
>>>>> i've "lua-fied" allmost everything of my current project
>>>>> but...
>>>>> *I want to set an attribute in my statemachines, which is currently
>>>>> unsupported?! (only properties, but I don't want to change it to a
>>>>> property) something like:
>>>>> CMWyGlobal =
>>>>> peertable.Scene:getAttribute("CartesianMotion_Wy_global")
>>>>> CMWyGlobal:set(1.0)
>>>>> *in the old rtt syntax I could initialize a kdl rotationmatrix with
>>>>> RPY angles like: kdl_rot=KDL.Rotation(3.14159265,0.0,1.57) but this
>>>>> isn't possible with lua, correct?
>>>>> You have to give all matrix values:
>>>>> kdl_rot:fromtab(
>>>>> {X_z=0,Z_y=1,Y_y=-0.000796327,X_y=0,Y_z=1,Z_z=0.000796327,Y_x=0,Z_x
>>>>> =0,X_x=-1} ) (which are btw ordered in a strange way if you print
>>>>> the value (like above))
>>>>>
>>>>> Can I put some feature requests somewhere?
>>>>
>>>> Please, don't ask the Lua maintainer to turn the Lua support in Orocos
>>>> into a full-fledged scripting language, kitchen sink included! I
>>>> don't like to see the project go there: Lua should do Coordination,
>>>> and nothing more. All "useful stuff" should be done by calling
>>>> non-Lua functionalities, not by extending Lua to copy that stuff...
>>>
>>> Exactly! Thats the Lua philosophy!
>>>
>>>> For example: the Coordination should _not_ do data communication, let
>>>> alone encode algorithms that compute when to fire events or
>>>> transition states. All these computations should reside in
>>>> "computational slaves" (hopefully the components that _are_ already
>>>> there computing the functionality in the system!), and not in the
>>>> FSM.
>>>
>>> Yes, Coordination delegates the computations. However, here Nick is
>>> only using Coordination to do initial ocnfiguration, hence the need to
>>> set an attribute.
>>>
>>>> I've seen way too many projects loose there competitive advantage by
>>>> trying to hit every nail by the (nice but limited, by design!) hammer
>>>> they have...
>>>
>>> Yes, and we're not falling into that trap :-)
>>
>> I would like to see a proof of that... Because this is the trap that I see
>> growing before our noses: Lua was introduced in RTT for the sole purpose of
>> doing Coordination, not needing much "data processing" capabilities at all.
>> Now, the trend is growing to use Lua for a very different purpose, namely
>> as the scripting language for doing dynamci deployment. And it is via this
>> backdoor that the "featuritis" creeps in. Please, let's use another
>> language for the deployment scripting! Nothing wroing with Python there,
>> since there is no hard realtime need. Also nothing wrong with Java, since
>> that's where "the big masses" are (including Eclipse support...).
>
> Isn't the main advantage of Lua that you can easily create DSL's? So what's
> wrong with a Lua Deployment DSL. There's a big difference between using Lua for
> deployment and rFSM for deployment (which should be possible too IMO)
There is _indeed_ a big difference! But I know _for sure_ that each feature
that is added to Lua in RTT for the purposes of deployment is _also_ going
to be used in RTT for FSMs. And that's _not_ what I want to see happen.
Not yet another case of "Yes we can, so let's do it!".
> Secondly, Lua is the only external scripting language that has RTT bindings
> ATM that I know of. (Maybe also Ruby??) Why should we create new bindings for
> another scripting language and duplicate almost all work that has been done
> for the Lua bindings, instead of adding the missing bindings to RTT for Lua,
> and create a Lua Deployment DSL?
Because of the proven lack of discipline of framework users, to put it
mildly. And because it is going to become a maintenance nightmare for the
RTT FSMs: making the FSM DSL more powerful than it needs to be _invites_
people to come up with bad designs. And because deployment should be
_outsourced_ of Orocos as quickly as possible, to a professional tool with
much more critical mass. And because Orocos' main selling point is, and
should remain: lean and mean and hard realtime and interoperable with all
useful tools and frameworks that are not _absolutely needed_ for our hard
realtime focus.
I see the "myopic development community" syndrome showing up again. Been
there, seen that, too many times.
I have also been proven wrong, too many times, so please don't give up if
you think you have a good _technical_ argument.:-)
Human effort and "easiness" arguments, please don't apply :-)
Herman