[GRASS-dev] Re: [GRASS GIS] #1031: More specific parameter information in command line help

[GRASS GIS]

#1031: More specific parameter information in command line help
--------------------------+-------------------------------------------------
  Reporter:  huhabla      |       Owner:  grass-dev at lists.osgeo.org
      Type:  enhancement  |      Status:  new                      
  Priority:  minor        |   Milestone:  7.0.0                    
 Component:  libgis       |     Version:  svn-trunk                
Resolution:               |    Keywords:  parser, help             
  Platform:  All          |         Cpu:  All                      
--------------------------+-------------------------------------------------
Comment (by huhabla):

 Replying to [comment:13 glynn]:
 > Replying to [comment:10 martinl]:
 >
 [snip]
 >
 > So e.g.:
 >
 > {{{
 > opt->type = T_union(2,
 >       T_integer_subrange(1, 99, 2),
 >       T_string_enumeration(2, "all", "none"));
 > }}}
 >
 > would allow the option value to be any odd integer between 1 and 99
 inclusive or the strings "all" or "none".

 That sounds brilliant!
 I have implemented a simple prototype, to get an idea how this may work.
 Files are attached. Do you think my implementation points in the right
 direction?

 >
 > Variadic functions could either use a prefixed count or a NULL
 terminator (but the latter won't work for numbers).
 >
 > You would also need dependent base types, e.g. "column name within the
 database table associated with the map specified by the input= option".

 I am not sure if i understand that, What is the benefit of dependent base
 type?

 >
 > When it comes to parsing, you could implement such types using a generic
 mechanism using a callback function to enumerate or validate allowed
 values; however, we need to think about how this interacts with the GUI.

 The implementation i attached uses a simple callback to generically prints
 the content of the type structures. The callback will be attached while
 memory allocation.

 {{{

 struct T_type {
   enum T_TYPES type;
   void *p; /*Pointer to a type structure*/
   void (*print)(struct T_type*);
 };

 struct Option {
   struct T_type *key;
   struct T_type *type;
   struct T_type *description;
   struct T_type *answer;
 };

 struct Option* T_define_option()
 {
   struct Option *opt;

   opt = (struct Option*)calloc(1, sizeof(struct Option));
   opt->key = NULL;
   opt->type = NULL;
   opt->description = NULL;
   opt->answer = NULL;

   return opt;
 }

 struct T_type* T_real_subrange(double first, enum T_BOOL first_inclusive,
 double last, enum T_BOOL last_inclusive)
 {
   struct T_type *t;
   struct T_type_real_subrange *it;

   t =  T_type_alloc();

   it = (struct T_type_real_subrange*)calloc(1, sizeof(struct
 T_type_real_subrange));
   it->first = first;
   it->last = last;
   it->first_inclusive = first_inclusive;
   it->last_inclusive = last_inclusive;

   t->type = REAL_SUBRANGE;
   t->p = it;
   t->print = T_real_subrange_print;

   return t;
 }

 void T_real_subrange_print(struct T_type* type)
 {
   struct T_type_real_subrange* p;
   p = (struct T_type_real_subrange*)type->p;
   if(p) {
     fprintf(stderr, "first: %f\n", p->first);
     fprintf(stderr, "last: %f\n", p->last);
     fprintf(stderr, "first_include: %i\n", p->first_inclusive);
     fprintf(stderr, "last_include: %i\n", p->last_inclusive);
   }

   return;
 }

   struct Option *opt5 = T_define_option();
   opt5->key = T_string("val");
   opt5->type = T_real_subrange(100.0, True, 200.0, True);
   opt5->description = T_string("Values in between");
   //Print the content to stdout
   opt5->key->print(opt5->key);
   opt5->description->print(opt5->description);
   opt5->type->print(opt5->type);

 //This will bw the result at stdout:
 val
 Values in between
 first: 100.000000
 last: 200.000000
 first_include: 1
 last_include: 1

 }}}

 >
 > One possibility would be:
 >
 > T_dependent(Type* (*callback)(int argc, char**argv), char* opt0 [, char*
 opt1, ...])
 >
 > The parser would provide an option to expand an option's type given a
 partial list of option values, e.g.
 >
 > {{{
 > d.vect --expand=rgb_column map=inmap
 > }}}
 >
 > would convert the rgb_column= option's dependent type to a fixed
 enumeration of the available columns for the specified input map.

 Well, sorry, you lost me at this point.
 But i think i will catch up, if you could add more examples. :)

 I think your approach has enormous potential, but i am also concerned that
 it may be to complicated for grass module programmers?

-- 
Ticket URL: <http://trac.osgeo.org/grass/ticket/1031#comment:14>
GRASS GIS <http://grass.osgeo.org>