Re: specfiles for drivers

Hi Paul,

I've been mulling over the idea of a graphical utility to help launch Player
for a while now, I think it'd be a great tool for beginners.  Consequently,
I've been trying to learn PyGTK (and, by proxy, python) to give myself a
base for developing something like this.  I wanted to take it further and
create a utility that will actually run the server, but stuff like this
would need to be in place to enable config file sanity-checking. 

The doxygen descriptions are a good start, but I agree that they don't have
enough information to do a lot of neat things (rules for required/optional
interfaces, valid value ranges for numerical config options, etc).  It'd be
redundant to include all that information in two places, maybe we could come
up with some sort of parser for the interface descriptions that generates
doxygen information at build time.

Perhaps you should start a wiki page to hammer out the details of this
proposal.  I'm interested in working on this as well.

Rich

-----Original Message-----
From: Paul Osmialowski [mailto:[email protected]] 
Sent: Wednesday, June 09, 2010 5:15 PM
To: [email protected]
Subject: [Playerstage-developers] specfiles for drivers

Hello developers,

I was thinking about building some visual graphical utility for creating 
and maintaining Player configuration files (it may look like logisim 
program - boxes are player drivers, each with its own icon, lines are 
provides/requires dependency). As I am learning Python (never too late for 
it), I was considering to use tkinter canvas widget as a base for whole 
thing.

My main problem here is that somehow I need to prepare database of all 
drivers with their provided and required interfaces and all command-line 
options. No one did it so far. I know that there is doxygen description 
added to each driver code, however this is still not well structured and 
not always up to date (see my latest cameracompress patch waiting on a 
tracker). I think there are more great ideas that cannot be implemented 
due to lack of structured driver definitions (at least I have some).
I guess one day we need to prepare spec files for every driver and expect 
spec files for drivers submitted by contributors. As I prefer LISP-derived 
s-expressions over XML, my proposal is that it may look like these two 
examples:

cameracompress.spec file:

(def-driver cameracompress
   (license "GPL")
   (brief "jpeg compression and decompression routines")
   (provide
     (brief "Compressed image data is provided via a camera device.")
     camera nokey always
   )
   (def-option check_timestamps
     integer
     (default 0)
     (brief "If non-zero, timestamps are checked so only new images are
compressed and published.")
   )
   (def-option save
     integer
     (default 0)
     (brief "If non-zero, uncompressed images are saved to disk (with a
.jpeg extension)")
   )
   (def-option image_quality
     float
     (default 0.8)
     (brief "Image quality for JPEG compression")
   )
   (require
     camera always nokey
     (brief "Image data to be compressed is read from a camera device.")
   )
)

or more sophisticated robotracker.spec file:

(robotracker
   (brief "Robot tracker that updates vectormap layer with shapes of given 
robots.")
   (provide opaque always nokey (brief "not used, however it must be 
provided"))
   (require vectormap always nokey (brief "map data accessibility"))
   (def-option names (string-tuple 32) must-provide "non-empty list of 
robot names (vectormap layer objects)")
   (require-multi 32 position2d always (multikey (option names)))
   (def-option shape_x (float-tuple 2) (default (-0.01 0.01)))
   (def-option shape_y (float-tuple 2) (default (-0.01 0.01)))
   (def-option interval float (default -0.01) (brief "mimimal interval 
between map updates"))
   (def-option min_x_change float (default -0.01) (brief "minimum change on 
X-axis to assume robot has moved"))
   (def-option min_y_change float (default -0.01) (brief "minimum change on 
Y-axis to assume robot has moved"))
   (def-option layer_name string (default "NONE") (brief "minimum change on 
Y-axis to assume robot has moved"))
   (def-option workspaces_name (default "NONE") (brief "if not set to 
\"NONE\" this is the name of vectormap layer that will be filled-up with 
robots extents"))
   (def-option depletion_zone (default 0.0) (brief "length of additional 
depletion zone in robot workspace"))
   (def-option first2last_extent_name (default "NONE") (brief "if not set 
to \"NONE\" this is the name of additional vectormap object that will be 
added to workspaces layer to denote ex
   (license "GPL")
)

What do you think about that?

Paul


----------------------------------------------------------------------------
--
ThinkGeek and WIRED's GeekDad team up for the Ultimate 
GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the 
lucky parental unit.  See the prize list and enter to win: 
http://p.sf.net/sfu/thinkgeek-promo
_______________________________________________
Playerstage-developers mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/playerstage-developers


------------------------------------------------------------------------------
ThinkGeek and WIRED's GeekDad team up for the Ultimate 
GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the 
lucky parental unit.  See the prize list and enter to win: 
http://p.sf.net/sfu/thinkgeek-promo