Hamish wrote:
> > In r38629, options are checked regardless of whether opt->options is
> > present.
>
>
> if someone does:
>
> g.module string_opt1= string_opt2=foo
>
> or string_opt1="" should it catch that as an error?
Not in the parser; an empty string is still a string.
> I know current
Glynn wrote:
> In r38629, options are checked regardless of whether opt->options is
> present.
if someone does:
g.module string_opt1= string_opt2=foo
or string_opt1="" should it catch that as an error? I know currently
there are some module checks for that sort of thing (opt->answer pointer
exi
Glynn Clements wrote:
> > >> In this regard also check given value
> > >> by the parser. Then the parser could print a warning when the user
> > >> enter option value which cannot be casted to the given data type (e.g.
> > >> string for integer option).
> > >
> > > It already does this; see check
Martin Landa wrote:
> >> In this regard also check given value
> >> by the parser. Then the parser could print a warning when the user
> >> enter option value which cannot be casted to the given data type (e.g.
> >> string for integer option).
> >
> > It already does this; see check_an_opt() in p
Hi,
2009/7/31 Glynn Clements :
>> In this regard also check given value
>> by the parser. Then the parser could print a warning when the user
>> enter option value which cannot be casted to the given data type (e.g.
>> string for integer option).
>
> It already does this; see check_an_opt() in pa
Martin Landa wrote:
> > The ->answer field in "struct Option" is a char*; it can only hold a
> > string. Similarly, that's all that g.parser can pass to a script. It's
> > up to the module or script to parse these to integers or floats where
> > appropriate.
>
> would make sense to change it in
Hi,
2009/7/29 Glynn Clements :
> The ->answer field in "struct Option" is a char*; it can only hold a
> string. Similarly, that's all that g.parser can pass to a script. It's
> up to the module or script to parse these to integers or floats where
> appropriate.
would make sense to change it in GR
Anne Ghisla wrote:
> may I ask why does parser() cast all options arguments as strings
> instead of keeping their types?
> In v.krige.py addon I recast integer options in line 544, before calling
> R functions.
> I also had a look at parser code, but with little success. I'd be glad
> if anyone c
Hi all,
may I ask why does parser() cast all options arguments as strings
instead of keeping their types?
In v.krige.py addon I recast integer options in line 544, before calling
R functions.
I also had a look at parser code, but with little success. I'd be glad
if anyone can guide me in improving
