[GRASS-dev] [GRASS GIS] #2409: last call for options keys consolidation

GRASS GIS trac at osgeo.org
Sat Dec 27 18:56:39 PST 2014


#2409: last call for options keys consolidation
----------------------------------+-----------------------------------------
 Reporter:  martinl               |       Owner:  grass-dev@…              
     Type:  task                  |      Status:  new                      
 Priority:  blocker               |   Milestone:  7.0.0                    
Component:  Default               |     Version:  unspecified              
 Keywords:  standardized options  |    Platform:  Unspecified              
      Cpu:  Unspecified           |  
----------------------------------+-----------------------------------------

Comment(by wenzeslaus):

 Replying to [comment:180 glynn]:
 > Replying to [comment:178 wenzeslaus]:
 >
 > > > r63765 generates a warning if GRASS_FULL_OPTION_NAMES is set (to
 anything) and the found string isn't an exact match for the given string.
 > >
 > > Thanks that's good but wouldn't be better to do just the `strcmp`
 comparison (to be faster) and fail (with fatal error) which would show
 these things in tests (errors are clearly visible, warning must be
 searched for in the output). I think the primary use-case for
 `GRASS_FULL_OPTION_NAMES` is when you actually want to find the long
 options and then it is just more effective to fail. The secondary use-
 case, I can think of, is making parsing faster which is only possible if
 this check is alternative, not addition. Do you have different opinion?
 (This is not necessary to decide before the release I belief because it is
 not real API considering the use-cases.)
 >
 > I just took the simplest route for now. I don't consider performance
 issues at this scale to be relevant.

 I was hitting some issues when I was calling some modules to do simple
 task many time, so I'm looking for ways how to decrease the cost of new
 processes but I don't have any benchmark for the option parsing.

 > Changing the G_warning() to G_fatal_error() would be trivial, if that's
 desired.

 Not sure about the others but it makes sense to me to switch to
 `G_fatal_error()`.

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



More information about the grass-dev mailing list