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 it.
best regards,
Anne
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 can guide me in improving it.
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.
--
Glynn Clements <glynn@gclements.plus.com>
Hi,
2009/7/29 Glynn Clements <glynn@gclements.plus.com>:
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 GRASS 7, e.g. option->answer as
'union' (int, double, char *). 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).
Martin
--
Martin Landa <landa.martin gmail.com> * http://gama.fsv.cvut.cz/~landa
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 GRASS 7, e.g. option->answer as
'union' (int, double, char *).
opt->answer can also be a list of values when opt->multiple == TRUE.
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 parser.c.
--
Glynn Clements <glynn@gclements.plus.com>
Hi,
2009/7/31 Glynn Clements <glynn@gclements.plus.com>:
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 parser.c.
right, I meant e.g.
v.info bus layer=x
should print at least warning that 'x' is not valid integer value.
Martin
--
Martin Landa <landa.martin gmail.com> * http://gama.fsv.cvut.cz/~landa
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 parser.c.right, I meant e.g.
v.info bus layer=x
should print at least warning that 'x' is not valid integer value.
I misread the code; it's only used if opt->options is present.
I'll look into this.
--
Glynn Clements <glynn@gclements.plus.com>
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_an_opt() in parser.c.
>
> right, I meant e.g.
>
> v.info bus layer=x
>
> should print at least warning that 'x' is not valid integer value.I misread the code; it's only used if opt->options is present.
I'll look into this.
In r38629, options are checked regardless of whether opt->options is present.
--
Glynn Clements <glynn@gclements.plus.com>
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
exists but points to an empty string), but if would be better to have the
parser take care of that. are there cases where it might be valid?
d.module text="" ??
(e.g. mental typo during trial & error / up-arrow history editing in bash)
also, vaguely related: one thing I've never been clear on:
what is the reason to use G_done_msg(" "); instead of G_done_msg(""); ?
thanks,
Hamish
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 currently
there are some module checks for that sort of thing (opt->answer pointer
exists but points to an empty string), but if would be better to have the
parser take care of that. are there cases where it might be valid?
d.module text="" ??
It might be valid.
However: one problem with a module wanting to distinguish between an
option being omitted and it having the empty string as a value is
that, AFAICT, the GUI doesn't allow you to pass an empty string. If
you specify a value, it passes the option; if you leave the value
field blank, it doesn't pass the option.
For shell scripts, it might be convenient to allow passing an empty
string instead of omitting an option. It's much easier to pass an
option with a possibly-empty value than to conditionally pass an
option.
also, vaguely related: one thing I've never been clear on:
what is the reason to use G_done_msg(" "); instead of G_done_msg(""); ?
No idea.
--
Glynn Clements <glynn@gclements.plus.com>