I'm running grass 6.0.2 on Fedora Core 5, and I also have povray 3.1
running on mpi with a small beowulf cluster.
I am interested in integrating povray connectivity into GRASS.
I am having issues with not being able to export a raster map to a
povray height field. I consistently get the error:
"ERROR: too many nested evaluations (Infinite loop ?)"
Any advice here would be appreciated.
Glen
On Mon, 15 May 2006 11:02:49 -0400
Glen Gardner <gardner@backserv.gsfc.nasa.gov> wrote:
I'm running grass 6.0.2 on Fedora Core 5, and I also have povray 3.1
running on mpi with a small beowulf cluster.I am interested in integrating povray connectivity into GRASS.
I am having issues with not being able to export a raster map to a
povray height field. I consistently get the error:"ERROR: too many nested evaluations (Infinite loop ?)"
Any advice here would be appreciated.
What command? Copy/paste please.
I assume you have this problem in GUI. What happens if you call it from
CLI?
Maciek
--------------------
W polskim Internecie s? setki milion?w stron. My przekazujemy Tobie tylko najlepsze z nich!
http://katalog.panoramainternetu.pl/
Glen,
Please don't reply to priv, let the others participate and benefit.
Also, please note Grass developers list address has changed to
grass-dev@grass.itc.it. See recent archives for details.
On Mon, 15 May 2006 13:32:39 -0400
Glen Gardner <gardner@backserv.gsfc.nasa.gov> wrote:
It happens with the gui . I do not know if cli gives the same
response.
Can you try it then?
for the gui the menus follow: File,Export,Raster map, POVray
height-field
This is r.out.pov Grass command (as you can see on the status bar in
the bottom of GIS Manager, when you hover the mouse over "POVray
height-field" entry).
So type r.out.pov with all the parameters set as needed, in the Grass
terminal (the CLI otherwords). Or just copy/paste the full command that
fails in GUI into the terminal, press Enter.
Does it work?
Please report back and submit your comments to this bug report:
http://intevation.de/rt/webrt?serial_num=3117
Best,
Maciek
--------------------
W polskim Internecie s? setki milion?w stron. My przekazujemy Tobie tylko najlepsze z nich!
http://katalog.panoramainternetu.pl/
I think I've fixed it in CVS. G_percent() was being called for each cell
instead of for each row of data, so the "percent done" bar was being
updated faster than the GUI could handle. Also did some other cleanup of
the code; spotted but didn't fix these errors:
fmt[20] unused and wrong. ( sprintf("%d",double) )
[I didn't remove it as I have absolutely no idea what this code is
trying to do.]
"bias" input parameter is unused and "hfBias" is used uninitialized.
[intended to be the same thing? note hfBias is used twice (in both
main() and processProfiles()), verticalScale is only used in
processProfiles()]
Further cleaning is badly needed by someone who understands it more.
[so don't close the bug]
should be functional now?
Hamish
Hamish wrote:
> http://intevation.de/rt/webrt?serial_num=3117
I think I've fixed it in CVS. G_percent() was being called for each cell
instead of for each row of data, so the "percent done" bar was being
updated faster than the GUI could handle.
In the worst case, this should just cause the module to run slowly.
Anything else indicates a bug in the GUI code which processes the
module's output.
Also did some other cleanup of
the code; spotted but didn't fix these errors:fmt[20] unused and wrong. ( sprintf("%d",double) )
[I didn't remove it as I have absolutely no idea what this code is
trying to do.]
Going back through the CVS history, fmt has never been used. My guess
is that r.out.pov was derived from a similar program which used a
textual output format. All of r.out.pov's output is binary.
"bias" input parameter is unused and "hfBias" is used uninitialized.
hfBias is implicitly initialised to zero. Only automatic variables
(local variables which aren't explicitly declared "static") need an
explicit initialiser.
[intended to be the same thing?
Probably; bias itself is unused.
--
Glynn Clements <glynn@gclements.plus.com>
On Tue, 16 May 2006 13:07:42 +1200
Hamish <hamish_nospam@yahoo.com> 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?
Maciek
--------------------
W polskim Internecie s? setki milion?w stron. My przekazujemy Tobie tylko najlepsze z nich!
http://katalog.panoramainternetu.pl/
Maciek Sieczka 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=2937Could 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().
--
Glynn Clements <glynn@gclements.plus.com>
Glynn Clements wrote:
Maciek Sieczka wrote:
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=2937Could 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().
Glynn,
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
Markus
> > http://intevation.de/rt/webrt?serial_num=3117
>
> I think I've fixed it in CVS.
[can someone who was seeing this bug test & report back?]
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=2937Could it be related?
I stick by my theory that tcl throws this error when it it is asked
to process a single string repeatedly in very quick succession.
G_percent() in r.out.pov and the error messages shown in bug report
#2937 both produce this behavior.
Hamish
Markus Neteler 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().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.
[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".
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().
[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
--
Glynn Clements <glynn@gclements.plus.com>
Hamish wrote:
> 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 stick by my theory that tcl throws this error when it it is asked
to process a single string repeatedly in very quick succession.
No. As the error message suggests, Tcl throws this error if the
evaluation stack gets too deep, which is normally due to infinite
recursion. E.g.:
% proc foo {} {foo}
% foo
too many nested evaluations (infinite loop?)
A less obvious case is calling "update" from within an event handler
(e.g. the fileevent handler for process output). If the events occur
more rapidly than they can be processed, each call to update will
result in a nested call to the event handler.
Looking at the code for lib/gtcltk/gronsole.tcl, I notice that:
1. Gronsole::execbg registers Gronsole::file_callback as a fileevent
handler.
2. Gronsole::file_callback calls Gronsole::readout.
3. Gronsole::readout calls Gronsole::output_to_gronsole.
4. Gronsole::output_to_gronsole calls Gronsole::progress.
5. Gronsole::progress calls ProgressBar::_modify (via the widget's
_modify method).
6. ProgressBar::_modify calls update. If more output is available,
this will result in a nested call to Gronsole::file_callback, and so
on.
The last point is the problem; it should rely upon the caller to call
update if necessary (for the fileevent handler, it isn't; the update
should be performed from the event loop when Gronsole::file_callback
returns).
Removing the update from ProgressBar::_modify should eliminate the
problem. Changing it to "update idletasks" might; I'm not sure whether
file events are treated as idle events.
If you don't want to modify the BWidget library, modify the
Gronsole::file_callback function to prevent nested evaluation, e.g.
namespace eval Gronsole {
variable _busy
...
set _busy 0
}
...
proc Gronsole::file_callback {path ci mark fh} {
variable _busy
if {$_busy} return
set _busy 1
# do stuff
set _busy 0
}
--
Glynn Clements <glynn@gclements.plus.com>
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.cThose 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
Hello Glynn,
On Tue, 16 May 2006 11:12:23 +0100 Glynn Clements
<glynn@gclements.plus.com> wrote:
Maciek Sieczka 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. Does this have any
influence of their work? 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...)
Thanks for elaborating on this.
stephan
Markus Neteler wrote:
> [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?
It's the first section (after "Introduction") in the libgis
documentation:
http://mpa.itc.it/markus/grass61progman/gislib.html#init
Library Initialization
It is mandatory that the system be initialized before any other
library routines are called.
int G_gisinit(char *program_name) initialize gis library
[snip]
I'm not sure that it can be made much clearer than that (especially as
"mandatory" is in bold type).
OTOH, the front page of the Programmer's Manual simply lists all of
the libraries in alphabetical order, with libgis treated as just one
of many libraries, when it's really rather more important than e.g.
the bitmap or btree libraries.
> 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.
Yes; those are the most common reasons/excuses for reading the state
before G_parser() returns.
This has already caused problems with e.g. --html-description,
requiring the construction of a temporary mapset in order to generate
the HTML pages, due to modules requiring a valid mapset simply to
generate help text, HTML pages or the Tcl/Tk UI code. ISTR that a few
modules tried to use the active monitor; I don't know if they have
been fixed yet.
> [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_interactiveQuestion: Why does d.vect work since G_gisinit() comes right
before G_parser()? Because the definition part is "clean"?
Yes. The G_define_* functions (and G_gettext(), used by the _() macro)
are (currently) sufficiently trivial that they don't depend upon
library initialisation. The only thing which could go wrong is if
G_malloc() fails to obtain enough memory for a Flag/Option struct
(which is highly unlikely).
--
Glynn Clements <glynn@gclements.plus.com>
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@gclements.plus.com>
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.[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".
Added some comments to lib/gis/parser.c about this for more visibility.
(non-doxygenized header)
I notice g.region has fallen afoul of this rule in the last 2 weeks.
If the change is to be made so stuff happening before G_parser() will
trigger a fatal error, can this wait until after 6.1.0 is released?
On the subject of 6.1.0, are there objections to declaring the feature
freeze in force /as of now/ and plan for a release date of 1 June?
We need to stop breaking and refactoring things for a little while.
AFAICT things have gotten *less* stable since the start of this month,
the original time the freeze was suggested to begin. And 6.1.0 is
overdue.
I would like to freeze everything but gis.m and the r.3D modules- I
don't want to kill the development momentum they currently enjoy. Gis.m
is important to have working well, and changes to the r3.* modules
shouldn't touch the rest of the package. Radim had mentioned he thought
it unpracticable to do a half-freeze. As the freeze will last until
6.2.0 is released in (guessing) 4-6 months time, we need to figure out
some solution - any new release is stalled until we do.
6.1.0 should be a CVS tag, development continues in CVS/HEAD, yes?
& 6.2.0 starts a new CVS branch.
The only important new thing I think needs to happen before 6.1.0 is to
finish any outstanding translation prep work, as suggested by Cedric,
http://article.gmane.org/gmane.comp.gis.grass.devel/12229
We also need to go through the bug tracker and increase the priority of
any bugs we consider Release-Critical for 6.2. I don't think we have any
true RC bugs: no active security bugs and fails-to-build stuff gets
fixed quickly, so I mean rough-edges like adding v.in.ogr split code and
lingering v.buffer warts. NVIZ segfault on Vector points save (#4377)
and cleaner d.labels text rotation too.
For kicks and giggles we could prepare 6.0.3 and 5.4.1 rc-1 at the same
time as 6.1.0, and release them soon after.
I'm not sure if this is fixed yet, but it would be very nice if 5.4.1
could ignore the extra 3D lines in a GRASS 6 mapset's WIND file
gracefully. The 5.4 release branch probably needs some merging from
grass5 HEAD; I think 6.0.x branch has been kept pretty much up to date.
??,
Hamish
Glynn Clements wrote:
It's the first section (after "Introduction") in the libgis
documentation:http://mpa.itc.it/markus/grass61progman/gislib.html#init
Library Initialization
...OTOH, the front page of the Programmer's Manual simply lists all of
the libraries in alphabetical order, with libgis treated as just one
of many libraries, when it's really rather more important than e.g.
the bitmap or btree libraries.
I have made libgis more outstanding now
(http://mpa.itc.it/markus/grass61progman/)
The file to change was lib/index.dox . All developers are kindly invited
to improve
the documentation (see .dox files in the source code).
Markus
Hamish wrote:
> 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.
>
> [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".Added some comments to lib/gis/parser.c about this for more visibility.
(non-doxygenized header)I notice g.region has fallen afoul of this rule in the last 2 weeks.
I noticed that g.region didn't comply (use of llinfo() and
G_{lat,lon}_format_string()) when I updated it to handle GRASS_REGION
and WIND_OVERRIDE, but I didn't realise that this was recent.
If the change is to be made so stuff happening before G_parser() will
trigger a fatal error, can this wait until after 6.1.0 is released?
Certainly.
In any case, the change would initially need to be done in such a way
that it could be disabled easily, in case it turns out that a
substantial proportion of modules don't comply (especially critical
ones such as g.region).
Intentionally triggering bugs as a mechanism to get them fixed only
works if it doesn't result in everyone just reverting to the previous
version.
On the subject of 6.1.0, are there objections to declaring the feature
freeze in force /as of now/ and plan for a release date of 1 June?
We need to stop breaking and refactoring things for a little while.
AFAICT things have gotten *less* stable since the start of this month,
the original time the freeze was suggested to begin. And 6.1.0 is
overdue.I would like to freeze everything but gis.m and the r.3D modules- I
don't want to kill the development momentum they currently enjoy. Gis.m
is important to have working well,
The main issue there is that gis.m development may highlight further
architectural problems within GRASS. IOW, you might find that making
specific features work (or fixing specific bugs) requires potentially
destabilising changes to core GRASS code.
I'm not sure if this is fixed yet, but it would be very nice if 5.4.1
could ignore the extra 3D lines in a GRASS 6 mapset's WIND file
gracefully. The 5.4 release branch probably needs some merging from
grass5 HEAD; I think 6.0.x branch has been kept pretty much up to date.
I suspect that we've reached the point where maintaining 5.x is
becoming impractical. I haven't looked at it in months; I haven't even
done "cvs update" since early February. Anything beyond trivial
bug-fixes would require climbing the learning curve again.
--
Glynn Clements <glynn@gclements.plus.com>
> > 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.
> >
> > [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".
>
> Added some comments to lib/gis/parser.c about this for more
> visibility. (non-doxygenized header)
>
> I notice g.region has fallen afoul of this rule in the last 2 weeks.I noticed that g.region didn't comply (use of llinfo() and
G_{lat,lon}_format_string()) when I updated it to handle GRASS_REGION
and WIND_OVERRIDE, but I didn't realise that this was recent.
The recent change was to call G__get_window() before G_parser() so that
the llinfo() fn doesn't depend on an uninitialised value.
http://freegis.org/cgi-bin/viewcvs.cgi/grass6/general/g.region/cmd/main.c
solution is probably to abandon the llinfo() string, it's nice but not
critical.
Hamish
> On the subject of 6.1.0, are there objections to declaring the
> feature freeze in force /as of now/ and plan for a release date of 1
> June? We need to stop breaking and refactoring things for a little
> while. AFAICT things have gotten *less* stable since the start of
> this month, the original time the freeze was suggested to begin. And
> 6.1.0 is overdue.
>
> I would like to freeze everything but gis.m and the r.3D modules- I
> don't want to kill the development momentum they currently enjoy.
> Gis.m is important to have working well,The main issue there is that gis.m development may highlight further
architectural problems within GRASS. IOW, you might find that making
specific features work (or fixing specific bugs) requires potentially
destabilising changes to core GRASS code.
I am sure further development will highlight other deficiencies, but we
live in an imperfect world and have to draw a line somewhere.
As I see it we have three choices:
* Feature freeze now. This doesn't mean stop work on gis.m, e.g.
disallow new buttons, but no new structural changes. For the next few
months we would have to be content with working around architectural
unfortunates. This means enthusiasm-killing slowdown & repetition of
work later on, but by then we should have a very clear idea of the
problem and a well thought out solution which could be swiftly
implemented. 
* Accept some level of instability in the 6.2-rc cycle, leading to a
more buggy 6.2.0. In this case perhaps do a monthly tag of 6.1.1, 6.1.2,
6.1.3 for three months, then declare a harder freeze. :-/
* Endless development, release 6.2 in 2009. 
I don't think declaring a freeze which still allows "structural changes
to libgis for gis.m only" is useful.
I am keen for a freeze as I was really impressed by how successful the
6.0 one was. As 6.1.0 will be a developement preview release, gis.m
doesn't have to be perfect for it -- I agree with the suggestions to
create a gisenv setting to allow d.m to be the primary GUI to
accommodate conservative users. That way 6.1.0 could in practice be used
as a stable version for "production use" (whatever that means).
> I'm not sure if this is fixed yet, but it would be very nice if
> 5.4.1 could ignore the extra 3D lines in a GRASS 6 mapset's WIND
> file gracefully. The 5.4 release branch probably needs some merging
> from grass5 HEAD; I think 6.0.x branch has been kept pretty much up
> to date.I suspect that we've reached the point where maintaining 5.x is
becoming impractical.
I agree we are past the point of developing 5.x. Certainly we can
and should backport small but important fixes to the 5.4.x branch.
As long as 5.4.1 contains the 3D WIND parms fix to make it forward-
compatible with GRASS 6 mapsets, I don't mind it being the last planned
version. Installing fftw 2.x and tcl 8.3, is a small cost if you want to
use an older version of GRASS, no need to update for them, 64bitness.
I haven't looked at it in months; I haven't even done "cvs update"
since early February. Anything beyond trivial bug-fixes would require
climbing the learning curve again.
Others have. What important bug fixes haven't been backported?
https://intevation.de/rt/webrt?q_status=resolved&q_queue=grass&q_area=grass6&display=Queue
possibles: bug #3100, 4045, 4145
The only other one that comes to mind is the small region raster lib fix
of a couple of months ago, but I wasn't involved in that so not sure.
Hamish