[bug #3117] [GRASS-dev] povray and grass

[Markus Neteler]

On Wed, May 17, 2006 at 10:36:37AM +0100, Glynn Clements wrote:
> Markus Neteler wrote:
> > >>>>http://intevation.de/rt/webrt?serial_num=3117
> > >>
> > >>There are other modules that happen to fail due to "too many nested
> > >>evaluations (infinite loop?)" in GUI. Those I rememeber are v.in.ogr
> > >>and v.extract. See http://intevation.de/rt/webrt?serial_num=2937
> > >>
> > >>Could it be related?
> > >>
> > >
> > >I don't know, but I notice that both of those modules have incorrect
> > >startup code.
> > >
> > >v.in.ogr calls various GRASS functions before G_parser() has returned,
> > >while v.extract calls the G_define_* functions before calling
> > >G_gisinit().
> > 
> > numerous modules are using G_define_standard_option(). I don't see why
> > this should be a problem.
> > The function is in lib/gis/parser.c
> 
> Those functions aren't the problem. The problem with v.extract is that
> it's calling them before it calls G_gisinit(), which is supposed to be
> called before any other GRASS function.

OK. I have fixed the position of G_gisinit() in v.extract.
 
> [Apart from anything else, G_gisinit() sets the program name, which is
> used by G_fatal_error(), so anything which might cause G_fatal_error()
> to be called (i.e. almost everything) cannot safely be called before
> G_[no_]gisinit().]
> 
> I have no idea whether or not this actually causes problems at
> present; I'm just pointing out that it's a bug regardless of whether
> or not you happen to "get away with it".

Apparently this needs to be better documented. Where?

> OTOH, the bug in v.in.ogr is very likely to cause problems. In order
> for alternate execution modes (--help, --tcltk etc) to work, it is
> essential that the module doesn't attempt to actually do /anything/
> except declare its options until after G_parser() returns (/if/ it
> returns, which it won't if any of the alternate execution modes are
> used).
> 
> Module authors/maintainers need to stop overlooking this issue.
> 
> Based upon past experience, this may require that they are forced to
> stop overlooking this issue, e.g. by making most functions generate a
> fatal error if called before G_parser().

This might be a good idea to actually catch such problems.
Since there are often *many* authors/maintainers, and code sometimes
originates from 20 years back, we have to enforce it.

There are a couple of candidates which do calculations within
the parameter/flag definition part.

> [I suspect that this can be implemented by adding checks to a few core
> functions, e.g. G_getenv(), G_get_window() etc. Anything which doesn't
> call those is probably safe to call at any point.]
> 
> Future developments are likely to make this more important. E.g. it
> ought to be possible to override most GRASS state using command-line
> switches. Of course, command-line switches won't have any effect until
> G_parser() has been called. If a module calls GRASS functions which
> access such state prior to calling G_parser(), it will use the wrong
> state and thus get the wrong results.
> 
> Just in case it isn't clear, the only functions which can legitimately
> be called before G_parser are:
> 
> 	G_gisinit
> 	G_no_gisinit
> 	G_define_module
> 	G_define_flag
> 	G_define_option
> 	G_define_standard_option
> 	G_disable_interactive
>

Question: Why does d.vect work since G_gisinit() comes right
before G_parser()? Because the definition part is "clean"?

Markus