Hi Tim,

On Wed, Jun 15, 2011 at 02:59:55PM +0200, Tim Niemueller wrote:
> On 21.02.2011 17:32, Markus Klotzbuecher wrote:
> > Dear List,
> 
> Hi Markus.
> 
> Just catching up with emails from the ROS list.
> 
> > I just gave roslua a try and its working quite nicely. One smaller
> > problem I noticed is when printing some array types:
> > 
> > $ lua -lroslua
> > Lua 5.1.4  Copyright (C) 1994-2008 Lua.org, PUC-Rio
> >> twist = roslua.get_msgspec("geometry_msgs/Twist")
> >> t=twist:instantiate()
> >> t:print()
> > geometry_msgs/Twist
> > /home/mk/src/git/lua/roslua/src/roslua/msg_spec.lua:53: attempt to call method 'find' (a nil value)
> > stack traceback:
> >       /home/mk/src/git/lua/roslua/src/roslua/msg_spec.lua:53: in function 'is_array_type'
> >       /home/mk/src/git/lua/roslua/src/roslua/message.lua:259: in function 'print_value'
> >       /home/mk/src/git/lua/roslua/src/roslua/message.lua:285: in function 'print'
> >       stdin:1: in main chunk
> >       [C]: ?
> >>
> 
> Can you try with the latest version, I added several fixes since back
> then. Does that solve your problem?

The problem still exists (but the line numbers have changed):

[string "/home/mk/src/git/lua/roslua/src/roslua/msg_..."]:65: attempt to call method 'find' (a nil value)
stack traceback:
      [string "/home/mk/src/git/lua/roslua/src/roslua/msg_..."]:65: in function 'is_array_type'
      [string "/home/mk/src/git/lua/roslua/src/roslua/mess..."]:334: in function 'print_value'
      [string "/home/mk/src/git/lua/roslua/src/roslua/mess..."]:360: in function 'print'
      stdin:1: in main chunk
      [C]: ?

I can't pinpoint the exact problem, but it seems 'is_array_type(type)'
in msg_spec.lua:66 is receiving a table instead of a string, for which
no find method is defined.

> > Secondly I wondered if there is a more compact way to create messages
> > which contain submessages. For instance to create and fill a
> > "geometry_msgs/Twist" I did the following:
> > 
> > local Vector3=roslua.get_msgspec("geometry_msgs/Vector3")
> > 
> > local m = p.msgspec:instantiate() -- geometry_msgs/Twist message
> > local vec3lin = Vector3:instantiate()
> > local vec3ang = Vector3:instantiate()
> > 
> > vec3lin.values.x=x
> > vec3lin.values.y=y
> > vec3lin.values.z=z
> > vec3ang.values.x=xang
> > vec3ang.values.y=yang 
> > vec3ang.values.z=zang
> > 
> > m.values.linear = vec3lin
> > m.values.angular = vec3ang
> 
> This should no longer be necessary, can you please verify with the
> latest git version?
> 
> > Before that I tried 
> > 
> > m.values.linear.x = x
> > m.values.linear.y = y
> 
> This must be:
> m.values.linear.values.x = x

This works, thanks!

> I have added the values table to make the fields easier to distinguish
> from existing method names and fields. We might reconsider if this was a
> wise decision, because it is especially ugly for such nested types as this.
> 
> I'll think about it using a setter meta table to verify that only field
> are set. It might also be just a convenience redirect to the values
> table, or possibly a compatibility wrapper for some time.

I had the similar problem to support both ':' call and '.' indexing
syntax for complex types in Orocos RTT. I eventually solved as
outlined here

 http://lua-users.org/wiki/ObjectProperties

which is AFAICS what you describe.

Having a 'values' subfield is ok once you know it, but I think it
would improve the syntax and help new users a lot if you could just do
't.linear.x' ...

Best regards
Markus