I have heard that a recent update to g.region accidentally made the –g flag unusable by itself. This would probably kill the GUI at startup. I’ve also heard that this is being fixed soon.
Michael
On 1/2/07 10:09 AM, “grassuser-request@grass.itc.it” grassuser-request@grass.itc.it wrote:
Send grassuser mailing list submissions to
grassuser@grass.itc.it
To subscribe or unsubscribe via the World Wide Web, visit
http://grass.itc.it/mailman/listinfo/grassuser
or, via email, send a message with subject or body ‘help’ to
grassuser-request@grass.itc.it
You can reach the person managing the list at
grassuser-owner@grass.itc.it
When replying, please edit your Subject line so it is more specific
than “Re: Contents of grassuser digest…”
Today’s Topics:
- Re: Grass cvs server down? (Stephan Holl)
- Re: GRASS entry Springer Encyclopedia of GIS (Stuart Edwards)
- v.surf.rst (Abbott, Dawn)
- Re: replacing cat values of a vector map with another
(Jachym Cepicky)
- Re: replacing cat values of a vector map with another
(Maciej Sieczka)
- gis.m window still disappears (Gerald Nelson)
- Re: replacing cat values of a vector map with another
(Jachym Cepicky)
- Re: gis.m window still disappears (Paulick Consult)
- Re: gis.m window still disappears (Gerald Nelson)
- Re: gis.m window still disappears (Paul Kelly)
grassuser mailing list
grassuser@grass.itc.it
http://grass.itc.it/mailman/listinfo/grassuser
Michael Barton, Professor of Anthropology
School of Human Evolution & Social Change
Center for Social Dynamics & Complexity
Arizona State University
phone: 480-965-6213
fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton
Hi Michael,
yes, it was fixed in CVS today, see [1].
Regards, Martin
[1] http://grass.itc.it/pipermail/grass-dev/2007-January/028299.html
2007/1/2, Michael Barton <michael.barton@asu.edu>:
I have heard that a recent update to g.region accidentally made the –g flag
unusable by itself. This would probably kill the GUI at startup. I've also
heard that this is being fixed soon.
Michael
On 1/2/07 10:09 AM, "grassuser-request@grass.itc.it"
<grassuser-request@grass.itc.it> wrote:
Send grassuser mailing list submissions to
grassuser@grass.itc.it
To subscribe or unsubscribe via the World Wide Web, visit
http://grass.itc.it/mailman/listinfo/grassuser
or, via email, send a message with subject or body 'help' to
grassuser-request@grass.itc.it
You can reach the person managing the list at
grassuser-owner@grass.itc.it
When replying, please edit your Subject line so it is more specific
than "Re: Contents of grassuser digest..."
________________________________
Today's Topics:
1. Re: Grass cvs server down? (Stephan Holl)
2. Re: GRASS entry Springer Encyclopedia of GIS (Stuart Edwards)
3. v.surf.rst (Abbott, Dawn)
4. Re: replacing cat values of a vector map with another
(Jachym Cepicky)
5. Re: replacing cat values of a vector map with another
(Maciej Sieczka)
6. gis.m window still disappears (Gerald Nelson)
7. Re: replacing cat values of a vector map with another
(Jachym Cepicky)
8. Re: gis.m window still disappears (Paulick Consult)
9. Re: gis.m window still disappears (Gerald Nelson)
10. Re: gis.m window still disappears (Paul Kelly)
________________________________
_______________________________________________
grassuser mailing list
grassuser@grass.itc.it
http://grass.itc.it/mailman/listinfo/grassuser
__________________________________________
Michael Barton, Professor of Anthropology
School of Human Evolution & Social Change
Center for Social Dynamics & Complexity
Arizona State University
phone: 480-965-6213
fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton
_______________________________________________
grassuser mailing list
grassuser@grass.itc.it
http://grass.itc.it/mailman/listinfo/grassuser
--
Martin Landa <landa.martin@gmail.com> * http://gama.fsv.cvut.cz/~landa *
Hello Martin,
Under normal circumstances, the fix whereby -g still works but outputs a warning would work fine - EXCEPT (because of a bug/feature/limitation in Tcl), when GRASS commands are run from Tcl scripts stderr and stdout have to be merged. So the warning (which goes to stderr) interferes with the parseable output (which goes to stdout) meaning that unfortunately outputing a warning isn't a workable solution really 
Paul
On Tue, 2 Jan 2007, Martin Landa wrote:
Hi Michael,
yes, it was fixed in CVS today, see [1].
Regards, Martin
[1] http://grass.itc.it/pipermail/grass-dev/2007-January/028299.html
2007/1/2, Michael Barton <michael.barton@asu.edu>:
I have heard that a recent update to g.region accidentally made the ?g flag
unusable by itself. This would probably kill the GUI at startup. I've also
heard that this is being fixed soon.
Michael
On 1/2/07 10:09 AM, "grassuser-request@grass.itc.it"
<grassuser-request@grass.itc.it> wrote:
Send grassuser mailing list submissions to
grassuser@grass.itc.it
To subscribe or unsubscribe via the World Wide Web, visit
http://grass.itc.it/mailman/listinfo/grassuser
or, via email, send a message with subject or body 'help' to
grassuser-request@grass.itc.it
You can reach the person managing the list at
grassuser-owner@grass.itc.it
When replying, please edit your Subject line so it is more specific
than "Re: Contents of grassuser digest..."
________________________________
Today's Topics:
1. Re: Grass cvs server down? (Stephan Holl)
2. Re: GRASS entry Springer Encyclopedia of GIS (Stuart Edwards)
3. v.surf.rst (Abbott, Dawn)
4. Re: replacing cat values of a vector map with another
(Jachym Cepicky)
5. Re: replacing cat values of a vector map with another
(Maciej Sieczka)
6. gis.m window still disappears (Gerald Nelson)
7. Re: replacing cat values of a vector map with another
(Jachym Cepicky)
8. Re: gis.m window still disappears (Paulick Consult)
9. Re: gis.m window still disappears (Gerald Nelson)
10. Re: gis.m window still disappears (Paul Kelly)
________________________________
_______________________________________________
grassuser mailing list
grassuser@grass.itc.it
http://grass.itc.it/mailman/listinfo/grassuser
__________________________________________
Michael Barton, Professor of Anthropology
School of Human Evolution & Social Change
Center for Social Dynamics & Complexity
Arizona State University
phone: 480-965-6213
fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton
_______________________________________________
grassuser mailing list
grassuser@grass.itc.it
http://grass.itc.it/mailman/listinfo/grassuser
--
Martin Landa <landa.martin@gmail.com> * http://gama.fsv.cvut.cz/~landa *
_______________________________________________
grassuser mailing list
grassuser@grass.itc.it
http://grass.itc.it/mailman/listinfo/grassuser
On Tue, 2 Jan 2007, Paul Kelly wrote:
Hello Martin,
Under normal circumstances, the fix whereby -g still works but outputs a warning would work fine - EXCEPT (because of a bug/feature/limitation in Tcl), when GRASS commands are run from Tcl scripts stderr and stdout have to be merged. So the warning (which goes to stderr) interferes with the parseable output (which goes to stdout) meaning that unfortunately outputing
Actually, to make things even more complicated, that's *not* what's happening here. gis.m (actually mapcanvas.tcl) is running g.region -g *without* merging stdout and stderr, and it was the fact that anything at all (in this case the warning) was being written to stderr that was making Tcl bomb out completely. I think in this situation it may be preferable to work around the problem in mapcanvas.tcl:
if I change line 1056 of gui/tcltk/gis.m/mapcanvas.tcl to the following:
if {![catch {open [concat "|g.region" "-ug" $args "|& $env(GISBASE)/etc/grocat"] r} input]} {
i.e. adding "|& $env(GISBASE)/etc/grocat" at the end of the command line,
then stdout and stderr will be merged and Tcl won't bomb out. The only problem then is that the call to "regexp" on the next line doesn't check the return value. (The warning message obviously isn't parseable, so it should just skip over it.) If the return value of regexp was checked there, and the key/value not assigned using "set" if regexp returned false, the gis.m startup would probably be a little bit more robust.
But the other issue is of course - should we be changing the meaning of the g.region -g flag at all? Why not keep it as it is and add the new functionality (key=value output in combination with any other flag) to a totally new flag, to reduce confusion and enhance backwards compatibility?
Paul