This new API in libgis is backported in r62395, r62408, and r62411.
On Wed, Sep 17, 2014 at 3:35 PM, Glynn Clements gl...@gclements.plus.com
wrote:
Anna Petrášová wrote:
The parser syntax for Python scripts is not really documented
anywhere, or am I missing something?
AFAICT, the only
Anna Petrášová wrote:
The parser syntax for Python scripts is not really documented
anywhere, or am I missing something?
AFAICT, the only documentation is in the form of examples in the
g.parser manual, and the documentation of the C interface in the
programming manual.
--
Glynn Clements
Huidae Cho wrote:
We also need to add option_rules or something to g.parser so that python
scripts can have access to these functions. Something like:
#%option_rules
#% exclusive: -a, -b
#% requires_all: opt1, opt2, -a
#%end
Done in r61994.
--
Glynn Clements gl...@gclements.plus.com
On Tue, Sep 16, 2014 at 8:07 AM, Glynn Clements gl...@gclements.plus.com
wrote:
Huidae Cho wrote:
We also need to add option_rules or something to g.parser so that python
scripts can have access to these functions. Something like:
#%option_rules
#% exclusive: -a, -b
#%
Hi,
On Tue, Jul 22, 2014 at 2:58 PM, Huidae Cho gras...@gmail.com wrote:
Hi,
Well, there are no equivalent functions in python yet. Other than that, I
think this new API is functionally satisfying and r.clump is using it. The
patch looks good to me. BTW, I prefer option= and -f.
could you
On Wed, Jun 25, 2014 at 2:09 AM, Huidae Cho gras...@gmail.com wrote:
We also need to add option_rules or something to g.parser so that python
scripts can have access to these functions. Something like:
#%option_rules
#% exclusive: -a, -b
#% requires_all: opt1, opt2, -a
#%end
On Fri,
Hi,
Well, there are no equivalent functions in python yet. Other than that, I
think this new API is functionally satisfying and r.clump is using it. The
patch looks good to me. BTW, I prefer option= and -f.
Regards,
Huidae
On Tue, Jul 22, 2014 at 1:53 PM, Anna Petrášová kratocha...@gmail.com
Anna Petrášová wrote:
is this new API now stable enough to be actually used in C modules? Should
we start to replace the manual checks in modules with these functions?
I think so.
I attached a patch which should fix this ticket [1]: when user doesn't type
any command arguments and the
If I understand this correctly, this will be very welcome!
Thanks
Michael
__
C. Michael Barton
Director, Center for Social Dynamics Complexity
Professor of Anthropology, School of Human Evolution Social Change
Head, Graduate Faculty in Complex Adaptive Systems
We also need to add option_rules or something to g.parser so that python
scripts can have access to these functions. Something like:
#%option_rules
#% exclusive: -a, -b
#% requires_all: opt1, opt2, -a
#%end
On Fri, Jun 20, 2014 at 9:59 PM, Huidae Cho gras...@gmail.com wrote:
Huidae Cho wrote:
I assume G__check_option_rules() is supposed to be called by G_parser().
Then, instead of calling G_fatal_error, it should append errors to
st-errors.
Okay; I presume that the intent is so that it will report all errors,
not just the first.
If so... for g.mlist we can
G_option_excludes() works for me.
On Fri, Jun 20, 2014 at 7:58 PM, Glynn Clements gl...@gclements.plus.com
wrote:
Huidae Cho wrote:
I assume G__check_option_rules() is supposed to be called by G_parser().
Then, instead of calling G_fatal_error, it should append errors to
st-errors.
Huidae Cho wrote:
I think we need two more functions:
// if the first option is present, all the other options must also be
present.
// same as multiple G_option_requires(first, opt)...
void G_option_requires_all(void *first, ...);
As you note, this can be
Glynn Clements wrote:
I'll make a start on this.
A first draft of the code has been added in r60871. Not tested yet.
--
Glynn Clements gl...@gclements.plus.com
___
grass-dev mailing list
grass-dev@lists.osgeo.org
Looks good to me. I'll try it with g.mlist/g.mremove later.
On Thu, Jun 19, 2014 at 10:58 AM, Glynn Clements gl...@gclements.plus.com
wrote:
Glynn Clements wrote:
I'll make a start on this.
A first draft of the code has been added in r60871. Not tested yet.
--
Glynn Clements
I assume G__check_option_rules() is supposed to be called by G_parser().
Then, instead of calling G_fatal_error, it should append errors to
st-errors. If so... for g.mlist we can define two different versions of
rules:
This version prints more correct errors because only present options/flags
I think we need two more functions:
// at most one option from a set
void G_option_exclusive(void *first, ...);
// at least one option from a set
void G_option_required(void *first, ...);
// if the first option is present, at least one of the other
Huidae Cho wrote:
Maybe, we can use variadic macros in C99 to remove the first name argument.
GRASS doesn't require C99. In general, we try to keep the hard
dependencies to a bare minimium, particularly in core functionality
such as libgis.
In any case, the stdarg.h requirement for an
Right, G_option_exclusive(void *first, ...) should work.
On Wed, Jun 11, 2014 at 6:43 AM, Glynn Clements gl...@gclements.plus.com
wrote:
Huidae Cho wrote:
Maybe, we can use variadic macros in C99 to remove the first name
argument.
GRASS doesn't require C99. In general, we try to keep
Huidae Cho wrote:
My implementation of the exclusive member, which you reverted, can handle
all these cases, I think. But since you reverted it, I think you didn't
agree with my interface or implementation?
Not really.
[I also wanted to be able to discuss this starting from a blank slate,
I somehow agree with you that my interface can be cryptic and requires some
interpretation because information is spread out. I think we can define
something like:
// at most one option from a set
void G_option_exclusive(const char *name, ...);
// at least one option from
Maybe, we can use variadic macros in C99 to remove the first name argument.
#define G_option_exclusive(...) G__option_exclusive(NULL, __VA_ARGS__)
On Mon, Jun 9, 2014 at 10:54 AM, Huidae Cho gras...@gmail.com wrote:
I somehow agree with you that my interface can be cryptic and requires
some
Interesting, actually this works better I think.
#define G_option_exclusive(...) G__option_exclusive(NULL, __VA_ARGS__, NULL)
G_option_exclusive(opt1, opt2, flag1); // no need for the first name and
last NULL arguments.
On Mon, Jun 9, 2014 at 11:13 AM, Huidae Cho gras...@gmail.com wrote:
On Mon, Jun 9, 2014 at 11:16 AM, Huidae Cho gras...@gmail.com wrote:
Interesting, actually this works better I think.
#define G_option_exclusive(...) G__option_exclusive(NULL, __VA_ARGS__,
NULL)
G_option_exclusive(opt1, opt2, flag1); // no need for the first name
and last NULL arguments.
My implementation of the exclusive member, which you reverted, can handle
all these cases, I think. But since you reverted it, I think you didn't
agree with my interface or implementation?
IMO, passing option/flag names to G_option_required() has its own
disadvantage because changing option/flag
Huidae Cho wrote:
I was thinking about the same thing. Maybe add char *exclusive_group to
Option and Flag and G_parser() takes care of exclusiveness?
There are two relatively straightforward cases for option
interdependencies:
1. At most one option from a set may be provided (mutual
Hi,
2014-06-04 19:17 GMT+02:00 svn_gr...@osgeo.org:
1. Consolite option/flag mutually exslusive messages.
it would be nice to solve it in the parser level...
Martin
--
Martin Landa * http://geo.fsv.cvut.cz/gwiki/Landa
___
grass-dev mailing list
I was thinking about the same thing. Maybe add char *exclusive_group to
Option and Flag and G_parser() takes care of exclusiveness?
On Wed, Jun 4, 2014 at 2:03 PM, Martin Landa landa.mar...@gmail.com wrote:
Hi,
2014-06-04 19:17 GMT+02:00 svn_gr...@osgeo.org:
1. Consolite option/flag
28 matches
Mail list logo
