Re: specfiles for drivers

Hi Rich,

In a week or so, I plan to write more detailed description of this idea. 
Wiki preparation would be a good point to start. I think I can use one of 
my servers at PJIIT/PJWSTK for it, I have mediawiki working there.

Paul

On Thu, 10 Jun 2010, Rich Mattes wrote:

> 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
> _______________________________________________
> 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