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

[Glynn Clements]

Stephan Holl wrote:

> > > > > http://intevation.de/rt/webrt?serial_num=3117
> > > > 
> > > > I think I've fixed it in CVS.
> > > 
> > > <snip>
> > > 
> > > 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().
> 
> What do you mean by incorrect startup-code.

Each module should normally start with the following sequence of
function calls:

	G_gisinit
	G_define_module
	G_define_{flag,option,standard_option} (multiple calls)
	G_parser

Most other libgis functions should not be called until G_parser() has
returned (if it returns).

> Does this have any influence of their work?

Yes. If you run a module with e.g. --help, it shouldn't be attempting
to access $GISRC or the current mapset; it shouldn't require that
$GISRC or the current mapset are valid or even exist.

Until G_parser() has returned, the module doesn't know whether it's
actually being "executed", or merely being "probed" for information
about its interface.

> I am especially interested in v.in.ogrs
> behaviour since I am somewhat confused about its work.
> 
> (One one maschine it works OK, on another maschine it segfaults. The
> packages used on both maschines are identical...)

Most modules will get away with calling functions before G_parser()
has returned in the case where they are actually being executed. It's
usually the other cases (--help, --html-description, --tcltk etc)
which fail. The last one can be a problem for the UI.

However, this may change as time goes on. E.g. if G_parser() is
extended to allow various parameters to be overriden using switches,
querying those parameters (or anything which depends upon them) before
G_parser() returns will either fail or produce incorrect results.

Using switches is preferable to environment variables because some
languages (e.g. Tcl) don't allow you to set a specific environment for
each command. Instead, the caller has to modify its own environment
beforehand then revert it afterwards. This can cause race conditions,
e.g. if the command results in an error handler or event handler being
called before the caller has reverted its own environment.

-- 
Glynn Clements <glynn at gclements.plus.com>