[GRASS-dev] Re: [GRASS-user] GRASS6.3 on Windows

been trying the latest GRASS 6.3 on windows O/S.
NVIZ on D.M gives error
'couldnt execute NVIZ'
NVIZ on map display just doesnt work..
Nothing happens when you click on it.

This is one of the few items on the Windows native GRASS that doesn't work
(apparently some infuriating problems with attribute databases too).

Glynn Clements

2007-08-07 19:20:23 UTC

been trying the latest GRASS 6.3 on windows O/S.
NVIZ on D.M gives error
'couldnt execute NVIZ'
NVIZ on map display just doesnt work..
Nothing happens when you click on it.

This is one of the few items on the Windows native GRASS that doesn't work
(apparently some infuriating problems with attribute databases too).

Bob Covill

2007-08-07 19:39:39 UTC

been trying the latest GRASS 6.3 on windows O/S.
NVIZ on D.M gives error
'couldnt execute NVIZ'
NVIZ on map display just doesnt work..
Nothing happens when you click on it.

This is one of the few items on the Windows native GRASS that doesn't work
(apparently some infuriating problems with attribute databases too).

Glynn Clements

2007-08-08 07:54:34 UTC

I've added an nviz.bat script for use on Windows; I've also fixed the
Makefile to ensure that the binary gets the .exe extension.

This implements one of the suggestion I made for Windows back on May 19,
2007 (Subj.: Nviz on native Windows). I guess no one had tested them??

Presumably not.

This has always been the biggest problem with the Windows and MacOSX
ports. Most developers don't use those platforms, and most of the
people who do use them aren't developers.

The other suggestion was try directly running nviz2.2_script ....

Another way, which may be a better solution for windows is to edit the
nviz2.2_script file and replace "#!/nviz -f" with "#!
$GISBASE/etc/nviz2.2/nviz -f". You may need to enter the full path for
$GISBASE. After editing the file copy it to $GISBASE/bin/nviz
(overwriting the old nviz script). Make sure it is executable. Run
nviz (formerly nviz2.2_script).

Anything involving "#!" won't work natively on Windows.

Also, anything involving MSys' bash is asking for trouble. Real
portability will likely only be obtained by scrapping the use of
Bourne shell in favour of e.g. Python.

--
Glynn Clements <***@gclements.plus.com>

Paul Kelly

2007-08-08 18:49:00 UTC

Done that. Yep, it's the script; MSys strikes again.
I've added an nviz.bat script for use on Windows; I've also fixed the
Makefile to ensure that the binary gets the .exe extension.

That's excellent - I can confirm that it works again for me too. Somehow I
thought there was something else - I tried reverting to the way it was
before but couldn't get it working again. But didn't think of adding a
separate script start for Windows.

I found another issue with the use of the cat command in part of an NVIZ
Tcl script which I've also fixed, and it seems to be working well now.
Grepping for "exec" in the other scripts I see a few more hackish-looking
things that will need to be fixed to get all the NVIZ functionality
working on Windows though.

Paul

Moritz Lennert

2007-08-20 15:37:06 UTC

I've added an nviz.bat script for use on Windows; I've also fixed the
Makefile to ensure that the binary gets the .exe extension.

That's excellent - I can confirm that it works again for me too. Somehow I
thought there was something else - I tried reverting to the way it was
before but couldn't get it working again. But didn't think of adding a
separate script start for Windows.
I found another issue with the use of the cat command in part of an NVIZ
Tcl script which I've also fixed, and it seems to be working well now.
Grepping for "exec" in the other scripts I see a few more hackish-looking
things that will need to be fixed to get all the NVIZ functionality
working on Windows though.

Just checked out latest CVS and recompiled, and now I get the following
when I try to launch nviz from the menu (File -> 3D Rendering -> NVIZ):

child killed: SIGABRT
while executing
"exec -- $program --tcltk"
(procedure "run_ui" line 6)
invoked from within
"run_ui $cmd"
(procedure "execute" line 3)
invoked from within
"execute nviz "
(menu invoke)

When I display the spearfish DEM in a display window and then click on the
nviz button of that window, nothing happens. No error messages, nothing
except for a brief appearance of r.info.exe in the Windows task manager.

Moritz

Paul Kelly

2007-08-20 20:38:41 UTC

I've added an nviz.bat script for use on Windows; I've also fixed the
Makefile to ensure that the binary gets the .exe extension.

That's excellent - I can confirm that it works again for me too. Somehow I
thought there was something else - I tried reverting to the way it was
before but couldn't get it working again. But didn't think of adding a
separate script start for Windows.
I found another issue with the use of the cat command in part of an NVIZ
Tcl script which I've also fixed, and it seems to be working well now.
Grepping for "exec" in the other scripts I see a few more hackish-looking
things that will need to be fixed to get all the NVIZ functionality
working on Windows though.

Just checked out latest CVS and recompiled, and now I get the following
child killed: SIGABRT
while executing
"exec -- $program --tcltk"
(procedure "run_ui" line 6)
invoked from within
"run_ui $cmd"
(procedure "execute" line 3)
invoked from within
"execute nviz "
(menu invoke)
When I display the spearfish DEM in a display window and then click on the
nviz button of that window, nothing happens. No error messages, nothing
except for a brief appearance of r.info.exe in the Windows task manager.

Hello Moritz,
Works for me starting it both those ways, and also from command-line. I
even tried make distclean and compiling from scratch in case there was
something I'd manually fixed that kept it working on my system. So I don't
know what could be up with yours. Maybe you have an old nviz.exe lying
around in your PATH somewhere that is getting picked up when the GUI runs
"nviz", instead of Glynn's new nviz.bat?

A couple of side-notes though:
1) In general the GUI is terrible at catching and reporting errors from
modules it calls in the background and this leads to cryptic error
messages or nothing happening all over the place. IMHO it is a really
pervasive problem that definitely needs fixed in the next GUI. Hopefully
it already is there (ISTR discussions about every call to a GRASS module
going through some other function where the error trapping could
presumably be added, to avoid code repetition).

2) When the displayed layers start up in NVIZ the colour of the displayed
vector map isn't preserved. I'm guessing this is because it can't be
specified on the command-line, but perhaps the code that starts NVIZ using
the displayed layers should write a temporary NVIZ state file and then
start NVIZ with that file? I've no idea how complicated that would be to
do though. E.g. might be better only focussing on it in the new GUI.

I would love the functionality of NVIZ (most of which is implemented using
the gsurf library AIUI), to be available from the command-line as well as
through the Tcl/Tk interface. Would be cool to be able to generate 3-D
images with specified observer location and attitude and so on from a
shell script (or scripting language of your choice), rather than having to
do it with Tcl scripting in NVIZ.

Paul

Moritz Lennert

2007-08-25 22:04:54 UTC

Post by Moritz Lennert
Just checked out latest CVS and recompiled, and now I get the following

[...]

Post by Moritz Lennert
When I display the spearfish DEM in a display window and then click on the
nviz button of that window, nothing happens. No error messages, nothing
except for a brief appearance of r.info.exe in the Windows task manager.

You are still using the May version of your library binaries ? Which
version of tcl/tk ?

Post by Paul Kelly
So I don't
know what could be up with yours.

Just recompiled after distclean. I don't get the error message anymore
(don't know if this has anything to do with Michael's "cathing" efforts).
Now when I try to access nviz vie the File menu, it opens an empty wish
window entitled 'dialog0' and nothing else happens. When I try to launch
from the map diplay window, nothing happens at all.

Moritz Lennert

2007-08-25 22:23:23 UTC

Post by Moritz Lennert
Just checked out latest CVS and recompiled, and now I get the following

[...]

Post by Moritz Lennert
Just recompiled after distclean. I don't get the error message anymore
(don't know if this has anything to do with Michael's "cathing" efforts).
Now when I try to access nviz vie the File menu, it opens an empty wish
window entitled 'dialog0' and nothing else happens. When I try to launch
from the map diplay window, nothing happens at all.

Paul Kelly

2007-09-02 11:22:13 UTC

Maybe if someone could try my 20070825 binaries from
http://moritz.homelinux.org/grass/wingrass/ to see if the same problem
appears ?

I tried them and didn't have any problems. Starting nviz from gis.m File
menu, button in display window and command-line all worked fine. I unset
my PATH first so it's using the libraries you have included in the
distribution (I haven't compiled new ones recently anyway) and I'm still
using the Activestate Tcl. I think for a proper Beta WinGRASS release we
should compile our own Tcl/Tk and include that though to make it easy and
reliably compatible.

Paul

Moritz Lennert

2007-09-02 19:54:25 UTC

Maybe if someone could try my 20070825 binaries from
http://moritz.homelinux.org/grass/wingrass/ to see if the same problem
appears ?

I tried them and didn't have any problems. Starting nviz from gis.m File
menu, button in display window and command-line all worked fine.

I just recompiled and everything works fine as well. No idea where the
problem came from...

Post by Paul Kelly
I think for a proper Beta WinGRASS release we
should compile our own Tcl/Tk and include that though to make it easy and
reliably compatible.

Yes, sounds like a good idea in order to have one "installer" that
includes everything.

Moritz

Michael Barton

2007-08-07 19:23:23 UTC

Hot dog!!

Thanks a million.

Michael

been trying the latest GRASS 6.3 on windows O/S.
NVIZ on D.M gives error
'couldnt execute NVIZ'
NVIZ on map display just doesnt work..
Nothing happens when you click on it.

This is one of the few items on the Windows native GRASS that doesn't work
(apparently some infuriating problems with attribute databases too).

Moritz Lennert

2007-08-08 09:07:51 UTC

Thanks Glynn,

I won't be able to provide new binaries before Aug. 20, so whoever wants
to try this before will have to compile themselves.

Moritz

Post by Michael Barton
Hot dog!!
Thanks a million.
Michael

been trying the latest GRASS 6.3 on windows O/S.
NVIZ on D.M gives error
'couldnt execute NVIZ'
NVIZ on map display just doesnt work..
Nothing happens when you click on it.

This is one of the few items on the Windows native GRASS that doesn't work
(apparently some infuriating problems with attribute databases too).

Glynn Clements

2007-08-08 12:28:26 UTC

I've added an nviz.bat script for use on Windows; I've also fixed the
Makefile to ensure that the binary gets the .exe extension.

I won't be able to provide new binaries before Aug. 20, so whoever wants
to try this before will have to compile themselves.

Nothing needs to be compiled. The only changes required are to add the
the nviz.bat script to the $GISBASE/bin directory and rename the nviz
binary (in $GISBASE/etc/nviz2.2) to nviz.exe.

The nviz.bat script is just:

"%GISBASE%\etc\nviz2.2\nviz.exe" -f "%GISBASE%\etc\nviz2.2\scripts\nviz2.2_script" %*

--
Glynn Clements <***@gclements.plus.com>

Michael Barton

2007-08-21 19:14:04 UTC

Post by Paul Kelly
Hello Moritz,
Works for me starting it both those ways, and also from command-line. I
even tried make distclean and compiling from scratch in case there was
something I'd manually fixed that kept it working on my system. So I don't
know what could be up with yours. Maybe you have an old nviz.exe lying
around in your PATH somewhere that is getting picked up when the GUI runs
"nviz", instead of Glynn's new nviz.bat?
1) In general the GUI is terrible at catching and reporting errors from
modules it calls in the background and this leads to cryptic error
messages or nothing happening all over the place. IMHO it is a really
pervasive problem that definitely needs fixed in the next GUI. Hopefully
it already is there (ISTR discussions about every call to a GRASS module
going through some other function where the error trapping could
presumably be added, to avoid code repetition).

Actually, error trapping is pretty good in the GUI now, except for NVIZ (but
which doesn't run much in the way of GRASS commands anyway). There are traps
around all (or perhaps nearly all) GRASS commands that run through the GUI
that will kick out any GRASS errors to the terminal or a message box.

However, on top of that are GUI errors. TclTk does a pretty good job of
reporting these, but they only make sense if you understand TclTk of course.
At least they are not obscure error codes.

Post by Paul Kelly
2) When the displayed layers start up in NVIZ the colour of the displayed
vector map isn't preserved. I'm guessing this is because it can't be
specified on the command-line, but perhaps the code that starts NVIZ using
the displayed layers should write a temporary NVIZ state file and then
start NVIZ with that file? I've no idea how complicated that would be to
do though. E.g. might be better only focussing on it in the new GUI.

This probably complicated, but I really don't know as I don't understand
these files. Probably Bob or Helena does.

Post by Paul Kelly
I would love the functionality of NVIZ (most of which is implemented using
the gsurf library AIUI), to be available from the command-line as well as
through the Tcl/Tk interface. Would be cool to be able to generate 3-D
images with specified observer location and attitude and so on from a
shell script (or scripting language of your choice), rather than having to
do it with Tcl scripting in NVIZ.

Issuing commands to have an output file created is not a problem. Getting an
image to *display somewhere* is the problem. NVIZ is a display/visualization
application which displays images in a TclTk/OpenGL canvas. That is how the
rest of the GUI works now (i.e., a TclTk canvas, albeit without openGL). To
display something in a TclTk canvas requires TclTk scripting. A wxPython
canvas requires wxPython scripting; a Java canvas needs Java scripting, and
so on. The only reason it appears that you can type a command and have it
display in GRASS outside of this is that GRASS also has display drivers that
can send an image to an old-style xterminal (textronic emulation I think).
In other words, displaying an image in a "GRASS canvas" requires GRASS
scripting.

You could write code that would let you type in stuff and translate that
into TclTk script commands needed to display the output in a TclTk canvas.
We've done with with wxPython, where it's a bit easier to do, but still
something of a chore (since modern GUI's usually assume that you want to use
a GUI to display something in their canvases).

In fact it is possible to write NVIZ script code that can do pretty much
what you want. I don't know how to do it, but you should be able type script
commands to control the visualization and open NVIZ with this script (Maybe
you can even cat these into NVIZ in a *nix system--though I don't know if
this is possible or not).

This is what d.nviz does--or would do if it wasn't broken.

Michael

Post by Paul Kelly
Paul

__________________________________________
Michael Barton, Professor of Anthropology
Director of Graduate Studies
School of Human Evolution & Social Change
Center for Social Dynamics and Complexity
Arizona State University

phone: 480-965-6213
fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton

Paul Kelly

2007-08-22 11:22:38 UTC

Actually, error trapping is pretty good in the GUI now, except for NVIZ (but
which doesn't run much in the way of GRASS commands anyway). There are traps

Well maybe I was being a bit overly dramatic, but running
grep "exec " *.tcl | grep -v catch | wc -l
in the gis.m directory still reveals 72 lines where exec is used without a
corresponding catch. Not very scientific and perhaps not important in most
cases - but if a single command (be it a GRASS module or system command)
is not available or not working for some reason it could really make the
difference between somebody tearing their hair out for a day or finding
the source of a problem quickly.

Post by Michael Barton
around all (or perhaps nearly all) GRASS commands that run through the GUI
that will kick out any GRASS errors to the terminal or a message box.

Note that I'm not talking here about "expected" errors that come from bad
user data or some kind of error that's handled by G_fatal_error() or
whatever inside a GRASS command - I'm thinking more of unexpected errors
caused perhaps by a library not being installed properly or files being
corrupted on the user's system. Perhaps it's not a big deal right now and
perhaps Python will make it much easier to do than Tcl or even do it
automatically.

[...]

This probably complicated, but I really don't know as I don't understand
these files. Probably Bob or Helena does.

I had a quick look and they're straightforward enough as they correspond
directly with the widgets in the panels in NVIZ. But could do with much
better documentation. And not worth working on either seeing we're looking
to get rid of NVIZ and replace it with a better interface to the gsurf
library.

Issuing commands to have an output file created is not a problem. Getting an
image to *display somewhere* is the problem. NVIZ is a display/visualization
application which displays images in a TclTk/OpenGL canvas. That is how the
rest of the GUI works now (i.e., a TclTk canvas, albeit without openGL). To
display something in a TclTk canvas requires TclTk scripting. A wxPython
canvas requires wxPython scripting; a Java canvas needs Java scripting, and
so on. The only reason it appears that you can type a command and have it
display in GRASS outside of this is that GRASS also has display drivers that
can send an image to an old-style xterminal (textronic emulation I think).
In other words, displaying an image in a "GRASS canvas" requires GRASS
scripting.
You could write code that would let you type in stuff and translate that
into TclTk script commands needed to display the output in a TclTk canvas.
We've done with with wxPython, where it's a bit easier to do, but still
something of a chore (since modern GUI's usually assume that you want to use
a GUI to display something in their canvases).
In fact it is possible to write NVIZ script code that can do pretty much
what you want. I don't know how to do it, but you should be able type script
commands to control the visualization and open NVIZ with this script (Maybe
you can even cat these into NVIZ in a *nix system--though I don't know if
this is possible or not).

What I was getting at is that you don't have to use NVIZ and/or Tcl/Tk to
create 3-D views in GRASS. NVIZ is just a Tcl/Tk interface to the gsurf
library (lib/ogsf) which is written in C. So my idea was to write some new
C modules that link against libgrass_ogsf and duplicate the functionality
of NVIZ but in a much more easily scriptable way. I'll keep quiet about it
again though unless I actually get time to see how easy it is to do, as I
really am not too sure how much work it would be.

Paul

Glynn Clements

2007-08-24 03:48:39 UTC

Post by Paul Kelly
Works for me starting it both those ways, and also from command-line. I
even tried make distclean and compiling from scratch in case there was
something I'd manually fixed that kept it working on my system. So I don't
know what could be up with yours. Maybe you have an old nviz.exe lying
around in your PATH somewhere that is getting picked up when the GUI runs
"nviz", instead of Glynn's new nviz.bat?
1) In general the GUI is terrible at catching and reporting errors from
modules it calls in the background and this leads to cryptic error
messages or nothing happening all over the place. IMHO it is a really
pervasive problem that definitely needs fixed in the next GUI. Hopefully
it already is there (ISTR discussions about every call to a GRASS module
going through some other function where the error trapping could
presumably be added, to avoid code repetition).

Actually, error trapping is pretty good in the GUI now, except for NVIZ (but
which doesn't run much in the way of GRASS commands anyway). There are traps

Post by Michael Barton
around all (or perhaps nearly all) GRASS commands that run through the GUI
that will kick out any GRASS errors to the terminal or a message box.

A catch only helps if you do something useful once you've caught the
exception.

If the caller is relying upon the procedure to return information, and
the inability to execute the program means that the information cannot
be obtained, then there isn't any practical alternative to allow the
exception to propagate up to the caller.

Sometimes it may be worthwhile catching an exception just so that you
can re-throw the exception with additional data. But in the case of
exec failing, the specific error (e.g. "unable to load shared library
libfoo.so") needs to be retained.

Post by Michael Barton
In fact it is possible to write NVIZ script code that can do pretty much
what you want. I don't know how to do it, but you should be able type script
commands to control the visualization and open NVIZ with this script (Maybe
you can even cat these into NVIZ in a *nix system--though I don't know if
this is possible or not).

One thing to bear in mind is that you still need OpenGL. In practice,
this means that any such scripts need access to a GLX-capable X
server.

Also, you need to create the drawing "canvas" (a pBuffer or GLXPixmap
will suffice *if* the server supports them, otherwise you need to
create a window).

Alternatively, you can use an OSMesa context if you have OSMesa and
your libGL supports it (i.e. you have the standard X.org libGL, not
nVidia's version).

--
Glynn Clements <***@gclements.plus.com>

Paul Kelly

2007-08-24 22:27:05 UTC

Post by Glynn Clements
A catch only helps if you do something useful once you've caught the
exception.
If the caller is relying upon the procedure to return information, and
the inability to execute the program means that the information cannot
be obtained, then there isn't any practical alternative to allow the
exception to propagate up to the caller.
Sometimes it may be worthwhile catching an exception just so that you
can re-throw the exception with additional data. But in the case of
exec failing, the specific error (e.g. "unable to load shared library
libfoo.so") needs to be retained.

Yes sorry I wasn't clear = I meant keeping the stderr output as well as catching the error, and then something along the lines of displaying it in a pop-up dialog to the user - if the program just failed then a pop-up dialog would say that but if there was also an informational error message it would be displayed in the pop-up and could be a valuable hint as to the source of the problem. I did a bit of that in the recent changes I made to the way g.proj was run in the background when creating a new location during the gis_set.tcl startup - that's where the idea was coming from.

Michael Barton

2007-08-22 14:58:13 UTC

This sounds like it would be really nice. My dream is to find a way to
'seamlessly' (overused buzzword, but appropriate here) integrate 2D views
with 2.5-3D views in the GRASS display system, so that it is just another
way to look at the same geospatial data rather than needing to launch a new
module.

Please keep thinking about it.

Michael

Post by Paul Kelly
What I was getting at is that you don't have to use NVIZ and/or Tcl/Tk to
create 3-D views in GRASS. NVIZ is just a Tcl/Tk interface to the gsurf
library (lib/ogsf) which is written in C. So my idea was to write some new
C modules that link against libgrass_ogsf and duplicate the functionality
of NVIZ but in a much more easily scriptable way. I'll keep quiet about it
again though unless I actually get time to see how easy it is to do, as I
really am not too sure how much work it would be.

__________________________________________
Michael Barton, Professor of Anthropology
Director of Graduate Studies
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

Michael Barton

2007-08-22 15:01:22 UTC

Post by Paul Kelly
Well maybe I was being a bit overly dramatic, but running
grep "exec " *.tcl | grep -v catch | wc -l
in the gis.m directory still reveals 72 lines where exec is used without a
corresponding catch. Not very scientific and perhaps not important in most
cases - but if a single command (be it a GRASS module or system command)
is not available or not working for some reason it could really make the
difference between somebody tearing their hair out for a day or finding
the source of a problem quickly.

Thanks for the analysis Paul. I'm wondering where all these are? I'll try to
re-run it and see. You are right about the difficulty of trapping the other
kind of errors though. The fact that they are often a couple levels down
from the GUI error traps, and may not generate particularly intelligent
stderr messages in the first place makes this especially hard. We need some
help with this.

Michael

__________________________________________
Michael Barton, Professor of Anthropology
Director of Graduate Studies
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

Michael Barton

2007-08-24 06:15:43 UTC

I've gone through and wrapped in catch statements all GRASS commands worth
wrapping (and probably some not worth it).

I also did a bit of cleanup to the help routines that I ran across.

I also added Carlos' get info buttons to the raster and vector layer panels.
These are quite handy.

There is a bug in v.what such that it kicks out the wrong stuff with its GUI
interface description. Only shows up from the GUI, but it would be nice if
it could be fixed.

Anything else GUI-wise broken and fixable that anyone has noticed?

Michael

Post by Paul Kelly
1) In general the GUI is terrible at catching and reporting errors from
modules it calls in the background and this leads to cryptic error
messages or nothing happening all over the place. IMHO it is a really
pervasive problem that definitely needs fixed in the next GUI. Hopefully
it already is there (ISTR discussions about every call to a GRASS module
going through some other function where the error trapping could
presumably be added, to avoid code repetition).

Actually, error trapping is pretty good in the GUI now, except for NVIZ (but
which doesn't run much in the way of GRASS commands anyway). There are traps

__________________________________________
Michael Barton, Professor of Anthropology
Director of Graduate Studies
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

Helena Mitasova

2007-08-24 21:06:15 UTC

Post by Michael Barton
I've gone through and wrapped in catch statements all GRASS commands worth
wrapping (and probably some not worth it).
I also did a bit of cleanup to the help routines that I ran across.
I also added Carlos' get info buttons to the raster and vector layer panels.
These are quite handy.
There is a bug in v.what such that it kicks out the wrong stuff with its GUI
interface description. Only shows up from the GUI, but it would be nice if
it could be fixed.
Anything else GUI-wise broken and fixable that anyone has noticed?

There still seems to be a nviz GUI redesign related problem
(it may be due to my set up, but Paul said
that he has a problem with Save state on his freshly checked GRASS CVS
too.)

I have compared nviz in 6.2.1 that had older interface and Save State
works there (at least to some extent) with 6.3 and the state
files are indeed different - in 6.3 the light data are missing and the
order of saved settings is different (the later may not matter).
But the real problem is that nviz in 6.3
cannot read the saved settings and I get the following error:

Diagnostic: wrong # args: should be "set varName ?newValue?" -- Load
procedure for panel main may not be defined
Diagnostic: invalid command name "Nviz_720 752_load" -- Load procedure
for panel 720 752 may not be defined
Diagnostic: invalid command name "Nviz_22.0_load" -- Load procedure for
panel 22.0 may not be defined
Diagnostic: invalid command name "Nviz_4.462_load" -- Load procedure
for panel 4.462 may not be defined
Diagnostic: invalid command name "Nviz_379.50_load" -- Load procedure
for panel 379.50 may not be defined
Diagnostic: invalid command name "Nviz_0.504 0.984_load" -- Load
procedure for panel 0.504 0.984 may not be defined
Diagnostic: invalid command name "Nviz_1_load" -- Load procedure for
panel 1 may not be defined
Diagnostic: invalid command name "Nviz_234.500000 234.500000
120.363991_load" -- Load procedure for panel 234.500000 234.500000
120.363991 may not be defined

There is also a problem with scripts - I don't think it is directly in
the file sequencing tool as I assume that it has not been touched, but
some of the recent changes must have affected handling of map names:

section of nviz script created by file sequencing tool

old that worked:

if {$iloop4 < 8} then {
if {[lsearch {} $iloop4] == -1} then {
if {[lsearch {} $iloop4] > -1} then {
SendScriptLine "lappend NVIZ_BLANK_MAPS [ExtractMapID $mhandle6]"
} else {
SendScriptLine "$mhandle6 set_att color [lindex {***@indyfi
***@indyfi ***@indyfi ***@indyfi ***@indyfi
***@indyfi ***@indyfi ***@indyfi} $iloop4]"
}

new that does not work for obvious reasons (full path instead of
***@mapset) :

if {$iloop3 < 1} then {
if {[lsearch {} $iloop3] == -1} then {
if {[lsearch {} $iloop3] > -1} then {
SendScriptLine "lappend NVIZ_BLANK_MAPS [ExtractMapID $mhandle4]"
} else {
SendScriptLine "$mhandle4 set_att topo [lindex
{/local/home/helena/grassdata07/nc_spm_05/user1/cell/***@user1} $iloop3]"

The reason for the above problem seems to be that the save fields
function saves full path instead of ***@mapset

/local/home/helena/limg/grassbook/dynsurf.state.nviz
2
Surface
Topography
surf*1185562518
1
/local/home/helena/grassdata07/nc_spm_05/user1/cell/***@user1
Surface
Color
surf*1185562518
5
/local/home/helena/grassdata07/nc_spm_05/user1/cell/***@user1
/local/home/helena/grassdata07/nc_spm_05/user1/cell/***@user1
/local/home/helena/grassdata07/nc_spm_05/user1/cell/***@user1
/local/home/helena/grassdata07/nc_spm_05/user1/cell/***@user1
/local/home/helena/grassdata07/nc_spm_05/user1/cell/***@user1

the old field file has just
***@user1
***@user1

I am hoping that the fix is not too complex,

Helena

Post by Michael Barton
Michael

Actually, error trapping is pretty good in the GUI now, except for NVIZ (but
which doesn't run much in the way of GRASS commands anyway). There are traps

__________________________________________
Michael Barton, Professor of Anthropology
Director of Graduate Studies
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
_______________________________________________
grass-dev mailing list
http://grass.itc.it/mailman/listinfo/grass-dev

Hamish

2007-08-24 09:59:50 UTC

Post by Michael Barton
Anything else GUI-wise broken and fixable that anyone has noticed?

Before 6.3.0 is released I'd like to finish off this wish:

Lat/Lon locations should format the Map Display statusbar x,y string into
45°59.9999'S 170°59.9999'W, not as decimal -45.999999 170.999999.

http://wald.intevation.org/tracker/index.php?func=detail&aid=401

(I had previously committed code to reformat non-lat/lon coord text to a steady
'%.3f'; I just left lat/lon as '%.6f' or so but feel that's unfinished)

I have an idea or two how to do this slightly more efficiently than the
suggested code in the wish report (ie a few less lines in the mouse movement
update loop), but maybe the CPU overhead per mouse movement isn't as bad as I
expect and I'm stuck in a 4MHz 8086 mentality.

Feel free to have a stab at it if you like; I filed it as a wish as I was
having trouble finding the time to implement it, but didn't want it abandoned.
By the same token, I'd like it to be in 6.3.0 as that may be the last chance
for new TclTk features to be widely used.

There remains an unanswered question if "\xB0" produces a degree symbol on all
platforms.

test:
$ echo puts "90\xB0" | wish

Hamish

____________________________________________________________________________________
Fussy? Opinionated? Impossible to please? Perfect. Join Yahoo!'s user panel and lay it on us. http://surveylink.yahoo.com/gmrs/yahoo_panel_invite.asp?a=7

Glynn Clements

2007-08-25 20:11:17 UTC

Post by Hamish
There remains an unanswered question if "\xB0" produces a degree symbol on all
platforms.
$ echo puts "90\xB0" | wish

\xB0 is a degree symbol in ISO-8859-1. If you're using another
encoding (e.g. UTF-8), you need to use something else. Some encodings
(e.g. ISO-8859-5 = Cyrillic) don't have a degree symbol.

--
Glynn Clements <***@gclements.plus.com>

Michael Barton

2007-08-24 23:48:15 UTC

This is what I've done. For simplicity and to get it done fast, I've just
sent the error to the terminal. A popup would be better in most cases, but a
bit more work.

Michael

Post by Paul Kelly
Yes sorry I wasn't clear = I meant keeping the stderr output as well as
catching the error, and then something along the lines of displaying it in a
pop-up dialog to the user - if the program just failed then a pop-up dialog
would say that but if there was also an informational error message it would
be displayed in the pop-up and could be a valuable hint as to the source of
the problem. I did a bit of that in the recent changes I made to the way
g.proj was run in the background when creating a new location during the
gis_set.tcl startup - that's where the idea was coming from.

Michael Barton

2007-08-25 05:45:28 UTC

Post by Hamish

Post by Michael Barton
Anything else GUI-wise broken and fixable that anyone has noticed?

Lat/Lon locations should format the Map Display statusbar x,y string into
45°59.9999'S 170°59.9999'W, not as decimal -45.999999 170.999999.
http://wald.intevation.org/tracker/index.php?func=detail&aid=401
(I had previously committed code to reformat non-lat/lon coord text to a
steady
'%.3f'; I just left lat/lon as '%.6f' or so but feel that's unfinished)
I have an idea or two how to do this slightly more efficiently than the
suggested code in the wish report (ie a few less lines in the mouse movement
update loop), but maybe the CPU overhead per mouse movement isn't as bad as I
expect and I'm stuck in a 4MHz 8086 mentality.
Feel free to have a stab at it if you like; I filed it as a wish as I was
having trouble finding the time to implement it, but didn't want it abandoned.
By the same token, I'd like it to be in 6.3.0 as that may be the last chance
for new TclTk features to be widely used.
There remains an unanswered question if "\xB0" produces a degree symbol on all
platforms.

This is one reason I haven't pursued this. The other is that for many GIS
uses, decimal degrees are easier to work with than degrees minutes
seconds--even though the latter might look nicer.

Post by Hamish
$ echo puts "90\xB0" | wish

I tried this and it didn't work. Nothing printed in the wish screen. But it
may be the test rather than the \xB0 code. Also need to try on Windows.

Michael

Post by Hamish
Hamish
______________________________________________________________________________
______
Fussy? Opinionated? Impossible to please? Perfect. Join Yahoo!'s user panel
and lay it on us. http://surveylink.yahoo.com/gmrs/yahoo_panel_invite.asp?a=7

__________________________________________
Michael Barton, Professor of Anthropology
Director of Graduate Studies
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

Agustin Diez Castillo

2007-08-25 08:46:54 UTC

Post by Michael Barton
This is one reason I haven't pursued this. The other is that for many GIS
uses, decimal degrees are easier to work with than degrees minutes
seconds--even though the latter might look nicer.

Post by Hamish
$ echo puts "90\xB0" | wish

On a PPC iMac it works on a system term but not on a xterm where the space becomes an "
"A"
90°

Hamish

2007-08-27 09:33:40 UTC

Post by Hamish
Lat/Lon locations should format the Map Display statusbar x,y string into
45°59.9999'S 170°59.9999'W, not as decimal -45.999999 170.999999.
http://wald.intevation.org/tracker/index.php?func=detail&aid=401

This is one reason I haven't pursued this. The other is that for many GIS
uses, decimal degrees are easier to work with than degrees minutes
seconds--even though the latter might look nicer.

I had intended to put in code for all of DDD.DDDDDD (already there),
DDD^MM.MMMM', and DDD^MM'SS.SSS", then tell the mouse fn to use the
DM.MMM fn. Idea was in future someone can make that a radio button option
in a setup screen without too much effort.

To me, DDD MM.MMMM is the most useyul as that's what GPSs commonly
provide.

Post by Hamish
There remains an unanswered question if "\xB0" produces a degree symbol
on all platforms.
$ echo puts "90\xB0" | wish

I tried this and it didn't work. Nothing printed in the wish screen. But
it may be the test rather than the \xB0 code. Also need to try on Windows.

look on the terminal, not in the wish screen.

Post by Michael Barton
\xB0 is a degree symbol in ISO-8859-1. If you're using another
encoding (e.g. UTF-8), you need to use something else. Some encodings
e.g. ISO-8859-5 = Cyrillic) don't have a degree symbol.

How do other softwares deal with this?
Would one UTF-8 code cover all of UTF-8 or just one locale? ie if we test
locale we can cover both ISO-8859-1 and UTF-8 which would cover the
majority of users, for everyone else we could just make it a blank space.

Do tcl/tk text objects have any support for superscripts/tex? I'm
thinking a lower case "o" placed way up high, ^{o}.

Hamish

Glynn Clements

2007-08-27 19:28:35 UTC

Post by Hamish

Post by Glynn Clements
\xB0 is a degree symbol in ISO-8859-1. If you're using another
encoding (e.g. UTF-8), you need to use something else. Some encodings
e.g. ISO-8859-5 = Cyrillic) don't have a degree symbol.

GUI toolkits often use Unicode internally, in which case, there isn't
a problem (so long as the user's font has a degree symbol).

For locale-based text (e.g. terminal I/O), this can be handled by the
message catalogues; strings won't contain a degree sign in a locale
whose encoding doesn't support it.

Obviously, this requires that you get the string from a message
catalogue in the first place.

Post by Hamish
Do tcl/tk text objects have any support for superscripts/tex? I'm
thinking a lower case "o" placed way up high, ^{o}.

This is available in "text" widgets, but not elsewhere (e.g. text
objects in a canvas widget, or labels).

Current versions of Tk use Unicode internally, but you need to use
"encoding system utf-8" before sourcing a UTF-8 script (by default,
scripts are read according to the locale's encoding).

--
Glynn Clements <***@gclements.plus.com>

Michael Barton

2007-08-25 14:55:43 UTC

Helena,

If you can tell me where this is in all the NVIZ code, I'll take a look at
it.

Michael

Post by Helena Mitasova

There still seems to be a nviz GUI redesign related problem
(it may be due to my set up, but Paul said
that he has a problem with Save state on his freshly checked GRASS CVS
too.)
I have compared nviz in 6.2.1 that had older interface and Save State
works there (at least to some extent) with 6.3 and the state
files are indeed different - in 6.3 the light data are missing and the
order of saved settings is different (the later may not matter).
But the real problem is that nviz in 6.3
Diagnostic: wrong # args: should be "set varName ?newValue?" -- Load
procedure for panel main may not be defined
Diagnostic: invalid command name "Nviz_720 752_load" -- Load procedure
for panel 720 752 may not be defined
Diagnostic: invalid command name "Nviz_22.0_load" -- Load procedure for
panel 22.0 may not be defined
Diagnostic: invalid command name "Nviz_4.462_load" -- Load procedure
for panel 4.462 may not be defined
Diagnostic: invalid command name "Nviz_379.50_load" -- Load procedure
for panel 379.50 may not be defined
Diagnostic: invalid command name "Nviz_0.504 0.984_load" -- Load
procedure for panel 0.504 0.984 may not be defined
Diagnostic: invalid command name "Nviz_1_load" -- Load procedure for
panel 1 may not be defined
Diagnostic: invalid command name "Nviz_234.500000 234.500000
120.363991_load" -- Load procedure for panel 234.500000 234.500000
120.363991 may not be defined
There is also a problem with scripts - I don't think it is directly in
the file sequencing tool as I assume that it has not been touched, but
section of nviz script created by file sequencing tool
if {$iloop4 < 8} then {
if {[lsearch {} $iloop4] == -1} then {
if {[lsearch {} $iloop4] > -1} then {
SendScriptLine "lappend NVIZ_BLANK_MAPS [ExtractMapID $mhandle6]"
} else {
}
new that does not work for obvious reasons (full path instead of
if {$iloop3 < 1} then {
if {[lsearch {} $iloop3] == -1} then {
if {[lsearch {} $iloop3] > -1} then {
SendScriptLine "lappend NVIZ_BLANK_MAPS [ExtractMapID $mhandle4]"
} else {
SendScriptLine "$mhandle4 set_att topo [lindex
} $iloop3]"
The reason for the above problem seems to be that the save fields
/local/home/helena/limg/grassbook/dynsurf.state.nviz
2
Surface
Topography
surf*1185562518
1
Surface
Color
surf*1185562518
5
the old field file has just
I am hoping that the fix is not too complex,
Helena

Post by Michael Barton
Michael

Actually, error trapping is pretty good in the GUI now, except for NVIZ
(but
which doesn't run much in the way of GRASS commands anyway). There are
traps

__________________________________________
Michael Barton, Professor of Anthropology
Director of Graduate Studies
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
_______________________________________________
grass-dev mailing list
http://grass.itc.it/mailman/listinfo/grass-dev

__________________________________________
Michael Barton, Professor of Anthropology
Director of Graduate Studies
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

Michael Barton

2007-08-25 16:42:19 UTC

Helena,

I did some poking around in the nviz code.

It looks like the state is being saved correctly, with only the ***@mapset
name (no paths). Position is always coming up 000 000 000, so that seems
wrong. This is called by the line

puts $file_hook "[Nsurf$i get_trans]"

This is a C command and I don't know if it is correct or not. "get_trans"
seems like an odd name for a command to get position.

Reading in the state file is probably the big issue. This is the part of the
code that reads a file.

proc load_state_aux { new_file} {
global Nv_

if {[catch {set file_hook [open $new_file r]} error_code] != 0} then {
display_error "While opening file: $error_code"
return
}

# Close all panels fist
Nv_closeAllPanels

# First line before panel data contains the name of the panel which
# saved the data. Use this name to build the command which will
# read in the data and call the appropriate routine.
while {[gets $file_hook i] != -1} {
set cmd_name "Nviz_$i"
append cmd_name "_load"
if {[catch {$cmd_name $file_hook} error_code] != 0} then {
puts "Diagnostic: $error_code -- Load procedure for panel $i
may not be defined"
}
}

...

As best I can tell, it is *supposed* to look for the beginning of a section
related to an nviz panel (e.g., "surf" relates to panel_surf.tcl) and launch
that panel.

However, AFAICT, the loading loop, beginning with "while", parses every line
in a state file and attempts to convert it into a command named
"Nviz_[name]_load", where [name] is the state file line. "Nviz_surf_load"
is valid, but a command created from the logical name of the surface is not,
generating this error on my system...

"Diagnostic: invalid command name "Nviz_surf*1188058769_load" -- Load
procedure for panel surf*1188058769 may not be defined"

The loop also sends the whole state file to the load command for each
correct panel section it identifies, rather than sending it only the
relevant parts. That is, the surface panel also gets all the stuff for
vector lines, lighting, etc. even though it cannot parse this, generating
more error codes.

When I tried to touch up NVIZ last December, I didn't mess with the
scripting or state saving/loading. So I don't know if anyone else changed
this code. But I don't see how it could possibly work the way it is written.
If this is the same code that is in 6.1 I don't know how that worked either.

Michael

__________________________________________
Michael Barton, Professor of Anthropology
Director of Graduate Studies
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

Michael Barton

2007-08-25 20:11:37 UTC

Here is an example of what a state file is like for a raster surface and
vector lines map.

1
surf*1188064015
map ***@PERMANENT
0
map ***@PERMANENT
0
unset
0
unset
const 60.000000
unset
#888888
0.000000 0.000000 0.000000
3 3
2 2
poly
grid_surf
gouraud
1
vect*1188064015
***@PERMANENT
#0000ff
2
1
surf*1188064015
0
0
400 400
34.0
1.615
6333.66
0.304 0.696
1
9480.000000 6975.000000 1453.245850

The line BEFORE the line starting surf* or vect* is where a new group of
parameters go that need to be read by a panel.

For example, panel_surf.tcl needs to read everything from the first line
(with the number 1, indicating that there is only 1 surface to deal with),
up to the line BEFORE "vect*1188064015" (another number 1), where the
information on the vector starts. This makes it hard to parse this file into
the parts that need to go to the separate panel modules.

It looks like it was doing this before by simply letting the general load
procedure and each panel load procedure generate umpteen error messages to
the terminal while picking out the stuff that each could use from the whole
file. This could get mixed up very easily.

What's needed is a way to delimit each section: surf, vect, lights, etc. A
very easy way to do this would be to begin each section with "start surf" or
"start vect" and end with "end surf" or "end vect", and so on.

But of course this means changing the format of nviz state files a little.
Old files won't be readable without adding start and stop section. On the
other hand, they're not readable now and I really wonder how well they could
be read in the past with this kind of format.

What is your opinion on this?

Michael

__________________________________________
Michael Barton, Professor of Anthropology
Director of Graduate Studies
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

Michael Barton

2007-08-25 20:35:39 UTC

Perhaps the only thing to do with some consistency is to write as

180 45' 30"

leaving the degree symbol implied. I don't know if that is very satisfactory
or not. Would it be confusing?

Michael

Post by Hamish
There remains an unanswered question if "\xB0" produces a degree symbol on
all
platforms.
$ echo puts "90\xB0" | wish

\xB0 is a degree symbol in ISO-8859-1. If you're using another
encoding (e.g. UTF-8), you need to use something else. Some encodings
(e.g. ISO-8859-5 = Cyrillic) don't have a degree symbol.

__________________________________________
Michael Barton, Professor of Anthropology
Director of Graduate Studies
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

Maciej Sieczka

2007-08-26 18:42:09 UTC

Post by Michael Barton
Perhaps the only thing to do with some consistency is to write as
180 45' 30"

How about 180:45:30.0E? Same format as g.region -l uses.

Maciek

Michael Barton

2007-08-25 23:02:17 UTC

Moritz,

Update /gui/tcltk/gis.m/runandoutput.tcl from the cvs and see what happens.
I just made a change, suggested by Glynn, that fixed similar symptoms for
with with another command (v.what). v.what was kicking out extraneous
information when it launched and creating an identical dialog. I've
separated out stderr from the normal stdout information when commands are
launched from the menu and it works fine now.

Also, are you doing nviz from the menu (opens nviz dialog) or nviz from the
map display with a active raster map (launches nviz with the raster)?

Michael

Post by Moritz Lennert
Just checked out latest CVS and recompiled, and now I get the following

[...]

Post by Moritz Lennert
When I display the spearfish DEM in a display window and then click on
the
nviz button of that window, nothing happens. No error messages, nothing
except for a brief appearance of r.info.exe in the Windows task manager.

You are still using the May version of your library binaries ? Which
version of tcl/tk ?

Post by Paul Kelly
So I don't
know what could be up with yours.

Moritz Lennert

2007-08-26 19:24:58 UTC

Post by Paul Kelly
Moritz,
Update /gui/tcltk/gis.m/runandoutput.tcl from the cvs and see what happens.

Still the same problem.

Post by Paul Kelly
Also, are you doing nviz from the menu (opens nviz dialog) or nviz from the
map display with a active raster map (launches nviz with the raster)?

Both: when calling it from the menus, I just get the dialog0 window. When
I call it from the map display, I get no reaction whatsoever.

I'll install my binaries on a different windows machine tomorrow to see
what happens.

Moritz

Post by Paul Kelly
Michael

Post by Moritz Lennert
Just checked out latest CVS and recompiled, and now I get the following

[...]

Post by Moritz Lennert
When I display the spearfish DEM in a display window and then click on
the
nviz button of that window, nothing happens. No error messages, nothing
except for a brief appearance of r.info.exe in the Windows task manager.

You are still using the May version of your library binaries ? Which
version of tcl/tk ?

Post by Paul Kelly
So I don't
know what could be up with yours.

Paul Kelly

2007-08-31 20:27:40 UTC

Hello Michael

Post by Paul Kelly
Moritz,
Update /gui/tcltk/gis.m/runandoutput.tcl from the cvs and see what happens.
I just made a change, suggested by Glynn, that fixed similar symptoms for
with with another command (v.what). v.what was kicking out extraneous
information when it launched and creating an identical dialog. I've
separated out stderr from the normal stdout information when commands are
launched from the menu and it works fine now.

As far as I can see there in that latest change you're redirecting stderr
to /dev/null. So now there will be no output for the catch command to
catch in case of an error - so printing out the error message is
pointless. In any case a popup dialog should be a better option than
printing to the terminal where the user might not notice it until later -
or in future there may not even be a terminal, e.g. in WinGRASS but maybe
we'll change that.

I'd suggest using the catch command something as follows (this is adapting
what's in epsg_option.tcl):

catch {set code [exec -- $program --tcltk]} errMsg

if {[lindex $::errorCode 0] eq "CHILDSTATUS"} {
DialogGen .wrnDlg [G_msg "Error running command!"] warning \
[format [G_msg "%s returned the following message:\n%s"] $program $errMsg] \
0 OK
} elseif {$errMsg != ""} {
DialogGen .wrnDlg [format [G_msg "Informational output from %s"] $program] info \
[format [G_msg "%s returned the following informational message:\n%s"] $program $errMsg] \
0 OK
}
}

DialogGen is a nice little routine in gis_set.tcl that pops up a dialog
box. There are some comments in gis_set.tcl on how to use it.

Please note that I'm not saying this is what you should do, nor that I
necessarily recommend doing it now - my original comments about catching
errors properly where really just suggestions about something that we
should look out for in the future, as I thought it would be too much work
do do it thoroughly and properly now so soon before 6.3.0 without
introducing new unexpected behaviour and so on.

Possible problems with and notes about the above code:
- With the catch where it is - I'm not sure if it actually catches the
"exec" command or just the "set" command
- Checking the return status of the command is better than checking the
return value of catch, because, as we've seen lots of times - Tcl will
assume an error has happened if *any* output is written to stderr - a
usage convention not shared by GRASS.
- Output issued to stderr but when the command has exited successfully
should be handled by the second block of the if statement, and popped up
for the user to read and then continue.
- To be neater and less confusing to the user, the possiblity of a command
exiting with a non-zero return code but not writing anything to stderr
should probably also be handled.

Paul

Glynn Clements

2007-09-01 17:37:11 UTC

Post by Michael Barton
Update /gui/tcltk/gis.m/runandoutput.tcl from the cvs and see what happens.
I just made a change, suggested by Glynn, that fixed similar symptoms for
with with another command (v.what). v.what was kicking out extraneous
information when it launched and creating an identical dialog. I've
separated out stderr from the normal stdout information when commands are
launched from the menu and it works fine now.

Right.

The reason for the redirect was to prevent extraneous stderr output
from being treated as an error (v.what was calling R_open_driver()
before the G_parser() call; with direct rendering, this caused the PNG
driver startup text ("PNG: GRASS_TRUECOLOR status: ..." etc) to be
written to stderr.

I've fixed v.what not to do this. The map= option is now always
required; it won't try to get a default from the current monitor.

A few display (d.*) commands still do this, but those don't get run
from the menus, so this shouldn't be an issue. This isn't an issue for
wxGRASS, as Python has better subprocess management.

Post by Paul Kelly
- Output issued to stderr but when the command has exited successfully
should be handled by the second block of the if statement, and popped up
for the user to read and then continue.

I'm not sure that you get that option. If the command writes to
stderr, exec fails. I don't think that it's guaranteed that the
command will be run to completion, so I wouldn't want to rely upon it.

Post by Paul Kelly
- To be neater and less confusing to the user, the possiblity of a command
exiting with a non-zero return code but not writing anything to stderr
should probably also be handled.

In this particular case, there are only really two possibilities:
either the command's interface description was successfully retrieved,
or it wasn't. It probably isn't worth trying to discern between
different types of failure.

--
Glynn Clements <***@gclements.plus.com>

Helena Mitasova

2007-08-26 15:52:26 UTC

I forgot to cc to grassdev list so here is my response to Michael
Helena

Date: August 26, 2007 12:46:50 AM EDT
Subject: Re: [GRASS-dev] Re: [GRASS-user] GRASS6.3 on Windows, nviz
Michael,
I think that you are right with your diagnosis of the problem.
It is really in reading - GRASS6.2.1 (dec. 2006) correctly reads
state files saved by 6.2.1 but also those saved by 6.3 (april 2007)
(although the 6.3 is missing the light info, but size of the window
and viewing position is loaded correctly in 6.2.1).
GRASS6.3 cannot read correctly neither the 6.2.1 file nor 6.3 file.
But even in 6.2.1 the state file can be loaded only at the beginning
to have any effect - e.g.
nviz elevation
Load state -> teststate.nviz
works
but if you are working in nviz and then want to load it again -
it would not resize the window - this may be actually intentional,
I don't remember.
As for the suggestion to change the formatting of the state file -
that would be good
to post to users list to see whether that would be concern
(it should be easy to update an existing state file).
Both the state file issue and the names of the files in the file
sequencing tool
would be very useful to solve so that the landscape evolution can be
visualized as dynamic surface. We can even
have multiple surfaces - one showing terrain with erosion and the
second one showing
the changing land use with the people represented by dynamic point
symbols.
What do you use for viewing the landscape evolution now?
thanks a lot for looking into this, it would be great to have this
capability back
as we now have quite a bit of data from various projects and the book
that would be nice to show as dynamic surfaces,
Helena
Helena Mitasova
Dept. of Marine, Earth and Atm. Sciences
1125 Jordan Hall, NCSU Box 8208,
Raleigh NC 27695
http://skagit.meas.ncsu.edu/~helena/

Post by Michael Barton
Here is an example of what a state file is like for a raster
surface and
vector lines map.
1
surf*1188064015
0
0
unset
0
unset
const 60.000000
unset
#888888
0.000000 0.000000 0.000000
3 3
2 2
poly
grid_surf
gouraud
1
vect*1188064015
#0000ff
2
1
surf*1188064015
0
0
400 400
34.0
1.615
6333.66
0.304 0.696
1
9480.000000 6975.000000 1453.245850
The line BEFORE the line starting surf* or vect* is where a new
group of
parameters go that need to be read by a panel.
For example, panel_surf.tcl needs to read everything from the
first line
(with the number 1, indicating that there is only 1 surface to
deal with),
up to the line BEFORE "vect*1188064015" (another number 1), where the
information on the vector starts. This makes it hard to parse this
file into
the parts that need to go to the separate panel modules.
It looks like it was doing this before by simply letting the
general load
procedure and each panel load procedure generate umpteen error
messages to
the terminal while picking out the stuff that each could use from
the whole
file. This could get mixed up very easily.
What's needed is a way to delimit each section: surf, vect,
lights, etc. A
very easy way to do this would be to begin each section with
"start surf" or
"start vect" and end with "end surf" or "end vect", and so on.
But of course this means changing the format of nviz state files a
little.
Old files won't be readable without adding start and stop section.
On the
other hand, they're not readable now and I really wonder how well
they could
be read in the past with this kind of format.
What is your opinion on this?
Michael
__________________________________________
Michael Barton, Professor of Anthropology
Director of Graduate Studies
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

Bob Covill

2007-08-27 12:02:12 UTC

Hi Micheal;

You might recall the eamil I sent last November, indicating that the
load/save State File was broken.

In the email I suggested changing the state file to an XML based file.
This would allow greater portability to newer nviz viewer(s). It would
be more flexible as features are added to a nviz viewer. It could also
support saving and loading the keyframe animations. With XML a program
could also added the creates "State Files" with a set view. For example
load raster "elevation" with 5x exag. and view from azi. 195 deg. and
altitude 45 deg..

--
Bob

Post by Helena Mitasova
I forgot to cc to grassdev list so here is my response to Michael
Helena

_______________________________________________
grass-dev mailing list
http://grass.itc.it/mailman/listinfo/grass-dev

--
Bob Covill
Tekmap Consulting

email:***@tekmap.ns.ca
web: www.tekmap.ns.ca

Michael Barton

2007-08-26 22:17:01 UTC

This could work too and has the advantage of being consistent with d:m:s in
another GRASS context.

An important question...is showing d:m:s for the spot under the arrow cursor
significantly more useful than showing decimal degrees?

Michael

Post by Maciej Sieczka

Post by Michael Barton
Perhaps the only thing to do with some consistency is to write as
180 45' 30"

How about 180:45:30.0E? Same format as g.region -l uses.
Maciek

__________________________________________
Michael Barton, Professor of Anthropology
Director of Graduate Studies
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

Michael Barton

2007-08-27 16:33:46 UTC

I don't know enough about xml (either creating or parsing in TclTk) to
implement this, although it sounds like a viable idea otherwise.

Michael

Post by Bob Covill
Hi Micheal;
You might recall the eamil I sent last November, indicating that the
load/save State File was broken.
In the email I suggested changing the state file to an XML based file.
This would allow greater portability to newer nviz viewer(s). It would
be more flexible as features are added to a nviz viewer. It could also
support saving and loading the keyframe animations. With XML a program
could also added the creates "State Files" with a set view. For example
load raster "elevation" with 5x exag. and view from azi. 195 deg. and
altitude 45 deg..
--
Bob

Post by Helena Mitasova
I forgot to cc to grassdev list so here is my response to Michael
Helena

_______________________________________________
grass-dev mailing list
http://grass.itc.it/mailman/listinfo/grass-dev

Glynn Clements

2007-08-27 19:31:02 UTC

Post by Michael Barton
I don't know enough about xml (either creating or parsing in TclTk) to
implement this, although it sounds like a viable idea otherwise.

As NVIZ is a hybrid C+Tcl/Tk application, you can use an external
library (e.g. libxml) for parsing.

Parsing XML in Tcl isn't viable, IMHO.

--
Glynn Clements <***@gclements.plus.com>

Michael Barton

2007-08-28 18:43:16 UTC

AFAICT, the current situation is that NVIZ will not properly read the state
file that it writes. To 'fix' it to read it with the current file format and
code approach will result in an incomplete 'fix' in that it still won't read
parts of the state file properly.

XML is a potentially good idea, but requires an external library AND I don't
know XML well enough to implement this.

I *think* I can fix it so that NVIZ in GRASS 6.3 can properly read and
configure itself from a state file. BUT, I need to change the state file
format a little bit to make it parseable. Basically, I need to add section
delimiters (e.g., "start surf", "end surf").

Should I go ahead and do this if I can?

Alternatively, if someone else would like to take this on, I'd be more than
happy.

Michael

Post by Michael Barton
I don't know enough about xml (either creating or parsing in TclTk) to
implement this, although it sounds like a viable idea otherwise.

As NVIZ is a hybrid C+Tcl/Tk application, you can use an external
library (e.g. libxml) for parsing.
Parsing XML in Tcl isn't viable, IMHO.

Dylan Beaudette

2007-08-28 19:09:24 UTC

Post by Michael Barton
AFAICT, the current situation is that NVIZ will not properly read the state
file that it writes. To 'fix' it to read it with the current file format
and code approach will result in an incomplete 'fix' in that it still won't
read parts of the state file properly.
XML is a potentially good idea, but requires an external library AND I
don't know XML well enough to implement this.

My 2 cents here. If we are using XML in other parts of GRASS (via external
parsing libs) I think that it would be good to standardize on some flavor of
XML for any misc. things like the NVIZ state file. XML is simple to read in a
text editor, simple to parse with external tools, and simple to read/write
with the appropriate libs.

Post by Michael Barton
I *think* I can fix it so that NVIZ in GRASS 6.3 can properly read and
configure itself from a state file. BUT, I need to change the state file
format a little bit to make it parseable. Basically, I need to add section
delimiters (e.g., "start surf", "end surf").

This would be fairly simple in XML:

<surface>
<id>1</id>
<name>elevation</name>
<source>***@mapset></source>
<colormap>***@mapset</colormap>

... other properties
</surface>

this type of construct could be used to define all of the pieces in the
statefile, so that they can be *directly* read from the document tree:

get/set methods work on:
surface->id->property->value

Post by Michael Barton
Should I go ahead and do this if I can?
Alternatively, if someone else would like to take this on, I'd be more than
happy.

thats the kicker... I do not know enough about XML in a C environment to do
this / and a MS thesis is looming over my head right now... Sorry!

Thanks for the hard work Michael,

Dylan

Post by Michael Barton
Michael

Post by Michael Barton
I don't know enough about xml (either creating or parsing in TclTk) to
implement this, although it sounds like a viable idea otherwise.

As NVIZ is a hybrid C+Tcl/Tk application, you can use an external
library (e.g. libxml) for parsing.
Parsing XML in Tcl isn't viable, IMHO.

__________________________________________
Michael Barton, Professor of Anthropology
Director of Graduate Studies
School of Human Evolution & Social Change
Center for Social Dynamics and Complexity
Arizona State University
phone: 480-965-6213
fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton
_______________________________________________
grass-dev mailing list
http://grass.itc.it/mailman/listinfo/grass-dev

--
Dylan Beaudette
Soils and Biogeochemistry Graduate Group
University of California at Davis
530.754.7341

Michael Barton

2007-08-29 15:32:35 UTC

Post by Dylan Beaudette

snip snip ...

Post by Dylan Beaudette
thats the kicker... I do not know enough about XML in a C environment to do
this / and a MS thesis is looming over my head right now... Sorry!

Indeed! Summer is over and my time is short too.

Unless someone that does have expertise in XML and time to do it is out
there, I propose to fix this with minimal changes in the current, simple
ascii state file for the upcoming 6.3 release.

We should rethink this for any subsequent releases, including 7. I don't
want to keep saying that we'll do it better in wxPython, but there are
available xml parsers there (e.g., SAX) that would make this easier. But
again, it will depend on available expertise.

Michael

__________________________________________
Michael Barton, Professor of Anthropology
Director of Graduate Studies
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

Bob Covill

2007-08-29 17:07:00 UTC

Post by Dylan Beaudette

snip snip ...

Post by Dylan Beaudette
thats the kicker... I do not know enough about XML in a C environment to do
this / and a MS thesis is looming over my head right now... Sorry!

If there is an easy fix, you may as well apply it for the upcoming
release. There is probably no point in adding an XML parser to the TCL
interface, as its days are probably numbered.

Post by Michael Barton
We should rethink this for any subsequent releases, including 7. I don't
want to keep saying that we'll do it better in wxPython, but there are
available xml parsers there (e.g., SAX) that would make this easier. But
again, it will depend on available expertise.

A number of UI's (GTK(glib), C#, ...) have their own XML parser which
could be taken advantage of when nviz is moved to a new interface. As a
proof of concept I have been playing around with the OpenGL GTK
interface GtkGLExt ( http://www.k-3d.org/gtkglext/Main_Page ) to view
and navigate GRASS data via ogsf. It works fine.

--
Bob

Glynn Clements

2007-08-30 02:56:41 UTC

Post by Dylan Beaudette
thats the kicker... I do not know enough about XML in a C environment to do
this / and a MS thesis is looming over my head right now... Sorry!

If there is an easy fix, you may as well apply it for the upcoming
release. There is probably no point in adding an XML parser to the TCL
interface, as its days are probably numbered.

Agreed. If wxPython is used for a new interface, the core Python
libraries include XML parsing.

Personally, I'd suggest using an interpreted language for programs
which are primarily user interfaces. It makes it much easier for users
to add tweaks for their specific needs. FWIW, wxPython includes a
GLCanvas class (analogous to Togl).

Do you have any code available? In terms of replacing NVIZ, it would
be useful to have a relatively simple example of how to use the OGSF
library; NVIZ itself is far too complex for that.

--
Glynn Clements <***@gclements.plus.com>

Bob Covill

2007-08-30 14:24:45 UTC

Post by Dylan Beaudette
thats the kicker... I do not know enough about XML in a C environment to do
this / and a MS thesis is looming over my head right now... Sorry!

If there is an easy fix, you may as well apply it for the upcoming
release. There is probably no point in adding an XML parser to the TCL
interface, as its days are probably numbered.

Agreed. If wxPython is used for a new interface, the core Python
libraries include XML parsing.

Unfortunately, I have never successfully compiled the the version of
wxPython required for the GRASS UI. I have tried a couple of times, but
eventually given up!

Post by Glynn Clements
Do you have any code available? In terms of replacing NVIZ, it would
be useful to have a relatively simple example of how to use the OGSF
library; NVIZ itself is far too complex for that.

I have uploaded my grass_gtk Glade project which includes the ogsf code
to http://www.tekmap.ns.ca/tekmap_download/grass_gtk.tar.bz2 . The ogsf
calls are made in src/visualization. These include ogsf initialization,
raster loading, vector loading, setting lights, fast draw, and full
draw, navigation, etc. For example, to load a raster ....
new_id = GS_new_surface();
ret = GS_load_att_map(new_id, name, ATT_TOPO);
...
calc resolutions
...
GS_set_drawres(new_id, max2, max2, max, max);
GS_set_drawmode(new_id, DM_GOURAUD | DM_POLY | DM_GRID_SURF );
ret = GS_load_att_map(new_id, name, ATT_COLOR); /* set color */
ret = GS_set_att_const(new_id, ATT_TRANSP, 0.0);
GS_set_global_exag(5.0);
GS_set_focus_center_map(new_id);

To move to a view position ...
tmp[0] = 100.;
tmp[1] = 100.;
tmp[2] = 2500.;
GS_moveto(tmp);

Hope this helps.

--
Bob

Michael Barton

2007-08-30 15:17:27 UTC

Thanks for making this available Bob. There has been considerable progress
recently in compiling wxPython on various systems by folks on the dev list,
and a number of new pre-compiled packages out.

What kind system are you using? Maybe there is someone who can help.

Michael

Post by Bob Covill
I have uploaded my grass_gtk Glade project which includes the ogsf code
to http://www.tekmap.ns.ca/tekmap_download/grass_gtk.tar.bz2 . The ogsf
calls are made in src/visualization. These include ogsf initialization,
raster loading, vector loading, setting lights, fast draw, and full
draw, navigation, etc. For example, to load a raster ....
new_id = GS_new_surface();
ret = GS_load_att_map(new_id, name, ATT_TOPO);
...
calc resolutions
...
GS_set_drawres(new_id, max2, max2, max, max);
GS_set_drawmode(new_id, DM_GOURAUD | DM_POLY | DM_GRID_SURF );
ret = GS_load_att_map(new_id, name, ATT_COLOR); /* set color */
ret = GS_set_att_const(new_id, ATT_TRANSP, 0.0);
GS_set_global_exag(5.0);
GS_set_focus_center_map(new_id);
To move to a view position ...
tmp[0] = 100.;
tmp[1] = 100.;
tmp[2] = 2500.;
GS_moveto(tmp);
Hope this helps.
--
Bob

__________________________________________
Michael Barton, Professor of Anthropology
Director of Graduate Studies
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

Michael Barton

2007-08-31 23:33:51 UTC

Paul,

Post by Paul Kelly
Hello Michael

My understanding from Glynn (perhaps wrong) is that a *real* error will
actually show up and be caught by TclTk, but not non-error information sent
to stderr.

I agree about preferring a message box. I can't really say I was being lazy,
but I wanted to get all statements caught right away, and it was a large
number to go through.

Post by Paul Kelly
I'd suggest using the catch command something as follows (this is adapting
catch {set code [exec -- $program --tcltk]} errMsg
if {[lindex $::errorCode 0] eq "CHILDSTATUS"} {
DialogGen .wrnDlg [G_msg "Error running command!"] warning \
[format [G_msg "%s returned the following message:\n%s"] $program
$errMsg] \
0 OK
} elseif {$errMsg != ""} {
DialogGen .wrnDlg [format [G_msg "Informational output from %s"]
$program] info \
[format [G_msg "%s returned the following informational
message:\n%s"] $program $errMsg] \
0 OK
}
}
DialogGen is a nice little routine in gis_set.tcl that pops up a dialog
box. There are some comments in gis_set.tcl on how to use it.

I've seen it, but would probably use the native tk_messageBox. It takes
about the same amount of code in the original program.

I started to put this in, but the problem with the mixing of stdout and
stderr for non-errors resulted in a message box that ran off the screen with
extraneous output from a problematic GRASS command. So I decided that until
that was fixed I'd just re-route all catch output to the terminal. And it
was also faster to do all the needed catch statements that way.

Post by Paul Kelly
Please note that I'm not saying this is what you should do, nor that I
necessarily recommend doing it now - my original comments about catching
errors properly where really just suggestions about something that we
should look out for in the future, as I thought it would be too much work
do do it thoroughly and properly now so soon before 6.3.0 without
introducing new unexpected behaviour and so on.

Understood. My time has become considerably shorter of course, and I been
trying to fix some other issues. Hopefully as they get fewer, it may be
possible to in a batch, go in and add some kind of dialog or messagebox for
error code. It would be cleaner and more professional looking to do that.

Post by Paul Kelly
- With the catch where it is - I'm not sure if it actually catches the
"exec" command or just the "set" command

It catches the exec command in this case. The set receives any error
message.

Post by Paul Kelly
- Checking the return status of the command is better than checking the
return value of catch, because, as we've seen lots of times - Tcl will
assume an error has happened if *any* output is written to stderr - a
usage convention not shared by GRASS.

I *think* this is solved by redirecting the original output to devnull

Again, I *think* that we will now only get an error message with a real
error. The user should not have to read a message and click OK if there is
no error.

Post by Paul Kelly
- To be neater and less confusing to the user, the possiblity of a command
exiting with a non-zero return code but not writing anything to stderr
should probably also be handled.

I suppose that this could be dealt with by if {$error != ""} { ...create the
messagebox...}

Thanks again for the thoughtful comments.

Michael

__________________________________________
Michael Barton, Professor of Anthropology
Director of Graduate Studies
School of Human Evolution & Social Change
Center for Social Dynamics and Complexity
Arizona State University

phone: 480-965-6213
fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton

Michael Barton

2007-09-01 19:40:04 UTC

Right.

Maybe this is not what you mean, but I intentionally generated an error to
test this by adding a typo to the menu command to call v.what (made it
"v.whats"). The error message came back as 'v.whats not found'.

So it looks like this will return at least some error messages.

Michael

Post by Glynn Clements
The reason for the redirect was to prevent extraneous stderr output
from being treated as an error (v.what was calling R_open_driver()
before the G_parser() call; with direct rendering, this caused the PNG
driver startup text ("PNG: GRASS_TRUECOLOR status: ..." etc) to be
written to stderr.
I've fixed v.what not to do this. The map= option is now always
required; it won't try to get a default from the current monitor.
A few display (d.*) commands still do this, but those don't get run
from the menus, so this shouldn't be an issue. This isn't an issue for
wxGRASS, as Python has better subprocess management.

__________________________________________
Michael Barton, Professor of Anthropology
Director of Graduate Studies
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

Glynn Clements

2007-09-02 05:04:29 UTC

Right.

Maybe this is not what you mean, but I intentionally generated an error to
test this by adding a typo to the menu command to call v.what (made it
"v.whats"). The error message came back as 'v.whats not found'.
So it looks like this will return at least some error messages.

That error is generated by Tcl itself. Errors generated by the command
(or the loader, e.g. "unable to load shared library") will still be
discarded. AFAICT, the only solution to that would be to redirect
stderr to a file, then include its contents in the event of an error.

--
Glynn Clements <***@gclements.plus.com>

Maris Nartiss

2007-09-02 08:14:36 UTC

Sorry for jumping-in.
I may be not following hard enough, but I just tested error catching
in lib/init/file_option.tcl proc fileOpt::create_loc and it works in
both cases:
1) Try to create new location from GDAL unsupported file -> outputs
g.proj error;
2) Move all GDAL libs to some other place and then try to create new
location -> outputs "shared library not found" error.
IMHO both of them are most common errors and having reported to user
in some user-friendly way is good thing. Any other common problem that
should be tested?

Alltough Glynns suggestion about redirecting GRASS error messages ALSO
to some error.log file would be a good idea as this file could be a
must for (crash) bug reporting. Only as a non-programmer I see some
difficulties:
1) How multiple processes (modules) can append data to that file in sane way;
2) When enable such functionality? I.E. g.env set=ERRLOG=true
3) What else needs to be written to such file? I.E. command history,
arch, GRASS version...

Just my 0.02$,
Maris.

Paul Kelly

2007-09-02 11:11:34 UTC

Hello Maris

Post by Maris Nartiss
Sorry for jumping-in.
I may be not following hard enough, but I just tested error catching
in lib/init/file_option.tcl proc fileOpt::create_loc and it works in
1) Try to create new location from GDAL unsupported file -> outputs
g.proj error;
2) Move all GDAL libs to some other place and then try to create new
location -> outputs "shared library not found" error.
IMHO both of them are most common errors and having reported to user
in some user-friendly way is good thing. Any other common problem that
should be tested?

Yes I think it works quite well there. I copied some of what you did in
file_option.tcl for my recent improvements to epsg_option.tcl. The way I
see it is that because the catch function takes an optional argument - a
variable to catch whatever is written to stderr - there is no need to
redirect stderr to a file. In effect we use the catch command to "catch"
the stderr output.

DialogGen works well for popping up clear error messages with the same
look and file as the rest of the GUI (in fact I changed it so the border
on the OK button looks the same as the other buttons in gis_set.tcl and
associated dialogs). tk_messageBox (on Windows anyway) resulted in a
dialog box with a totally different look and feel and to me at least it
seemed a bit inconsistent in regard to which windows it popped up in front
of. I wouldn't recommend using it - I changed a couple of occurences of it
in epsg_option.tcl to use DialogGen instead.

Paul

Glynn Clements

2007-09-02 11:57:50 UTC

Post by Maris Nartiss
Alltough Glynns suggestion about redirecting GRASS error messages ALSO
to some error.log file would be a good idea as this file could be a
must for (crash) bug reporting. Only as a non-programmer I see some
1) How multiple processes (modules) can append data to that file in sane way;
2) When enable such functionality? I.E. g.env set=ERRLOG=true
3) What else needs to be written to such file? I.E. command history,
arch, GRASS version...

I wasn't talking about writing to a "log" file, but a temporary file
which would be used for a single command.

The problem is that Tcl's "exec" command considers it an error if a
subprocess writes anything to stderr. However, a number of modules
write warnings or even just informational messages to stderr as well
as writing machine-readable output to stdout.

There are several possibilities, all of which have drawbacks:

1. If stderr isn't redirected, any warnings or messages will cause the
command to fail.

2. If stderr redirected to /dev/null (or nul: on Windows), actual
error messages which could identify the cause of the problem will be
lost.

3. Merging stderr with stdout isn't an option if stdout is to be
passed to another program which is expecting data in a particular
format.

4. If stderr is redirected to gis.m's stderr (typically the terminal),
messages may be ignored if the user doesn't normally use the terminal.
Also, this requires that gis.m actually has a stderr, which isn't
necessarily the case if gis.m is launched via the desktop (e.g. the
"Start Menu" etc).

5. Redirecting stderr to a file then reading it afterwards requires
additional code.

--
Glynn Clements <***@gclements.plus.com>

Paul Kelly

2007-09-02 12:28:40 UTC

That's true - however the error-detecting code in file_option.tcl doesn't
use the return value of catch to determine whether an error has occured or
not - instead it checks the global variable errorcode to see if the
command just run has exited with an error or not.
e.g. something like this:
catch {exec g.proj -c georef=$filepath location=$fileLocation} errMsg
if {[lindex $::errorCode 0] eq "CHILDSTATUS"} {
# Pop-up error dialog here.

It seems to work well but perhaps mightn't cover all eventualities?

Paul

Michael Barton

2007-09-03 06:57:06 UTC

I just put in a large number of error message boxes instead of routing
errors to the terminal.

In general, it has generally seemed like a better idea to use a built in
TclTk tool like tk_messageBox if one was available, than to use a custom
function that we have to maintain to do the same thing. In the x11 version I
use on my Mac, I kind of like the looks of tk_messageBox better than
DialogGen, but that's just a matter of personal opinion.

But I don't have a sense of what the difference between the two is on
Windows and would always like to have a better looking interface. It might
be nice to have error reporting have a consistent look across the entire
program--either DialogGen or tk_messageBox. And if there is a general
preference to the custom function (DialogGen) I don't feel that strongly
about it either way--as long as someone else wants to change over the 130+
of tk_messageBox dialogs I just installed ;-).

On a different error trap note...anyone have a feel for whether it's
worthwhile to use this check for all error traps?

if {[lindex $::errorCode 0] eq "CHILDSTATUS"} {

if it returns better information, it might be worth the effort.

Cheers
Michael

Post by Paul Kelly
Hello Maris

Yes I think it works quite well there. I copied some of what you did in
file_option.tcl for my recent improvements to epsg_option.tcl. The way I
see it is that because the catch function takes an optional argument - a
variable to catch whatever is written to stderr - there is no need to
redirect stderr to a file. In effect we use the catch command to "catch"
the stderr output.
DialogGen works well for popping up clear error messages with the same
look and file as the rest of the GUI (in fact I changed it so the border
on the OK button looks the same as the other buttons in gis_set.tcl and
associated dialogs). tk_messageBox (on Windows anyway) resulted in a
dialog box with a totally different look and feel and to me at least it
seemed a bit inconsistent in regard to which windows it popped up in front
of. I wouldn't recommend using it - I changed a couple of occurences of it
in epsg_option.tcl to use DialogGen instead.
Paul

__________________________________________
Michael Barton, Professor of Anthropology
Director of Graduate Studies
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

Maris Nartiss

2007-09-03 09:38:31 UTC

Hi,

when I wrote additional error trapping for GRASS startup screen I used
DialogGen as it was already used there. Now maybe it's time to ask -
why DialogGen instead of plain tk_messageBox? Is there some reason why
startup screen uses DialoGen and not tk native widgets? Probably we
should get rid of DialogGen popups in startup screen too.

About errorCode You can read more in TCL/Tk docs:
http://www.tcl.tk/man/tcl8.4/TclCmd/tclvars.htm#M18

Just my 0.02,
Maris.

Post by Michael Barton
I just put in a large number of error message boxes instead of routing
errors to the terminal.
In general, it has generally seemed like a better idea to use a built in
TclTk tool like tk_messageBox if one was available, than to use a custom
function that we have to maintain to do the same thing. In the x11 version I
use on my Mac, I kind of like the looks of tk_messageBox better than
DialogGen, but that's just a matter of personal opinion.
But I don't have a sense of what the difference between the two is on
Windows and would always like to have a better looking interface. It might
be nice to have error reporting have a consistent look across the entire
program--either DialogGen or tk_messageBox. And if there is a general
preference to the custom function (DialogGen) I don't feel that strongly
about it either way--as long as someone else wants to change over the 130+
of tk_messageBox dialogs I just installed ;-).
On a different error trap note...anyone have a feel for whether it's
worthwhile to use this check for all error traps?
if {[lindex $::errorCode 0] eq "CHILDSTATUS"} {
if it returns better information, it might be worth the effort.
Cheers
Michael

Glynn Clements

2007-09-03 14:11:06 UTC

If you find yourself typing 130+ instances of near-identical code,
that should be a clue that you should add some more infrastrcture.

For a start, if you add:

proc errorBox {msg} {
tk_messageBox -type ok -icon error -title [G_msg "Error"] -message $msg
}

you would be able to replace e.g.:

tk_messageBox -type ok -icon error -title [G_msg "Error"] \
-message [G_msg "Error creating tempfile: $error"]

(of which I see at least 102 occurrences) with just:

errorBox [G_msg "Error creating tempfile: $error"]

[
BTW, this usage of G_msg is probably incorrect, as the entire message,
including $error, will be used as the key. It should probably be:

errorBox "[G_msg {Error creating tempfile}]: $error"

or even:

errorBox "[G_msg {Error creating tempfile}]: [G_msg $error]"

so that "Error creating tempfile" and the error message will be
translated independently. This means that you only need A+B
translations instead of A*B. The second G_msg is only necessary if
Tcl/Tk error messages aren't already localised by Tcl/Tk.

Note that the situation is different with C, where "%s" is included
literally in the message key. In Tcl, $error will be substituted
before the message is translated.
]

Beyond that, the common error-trapping idioms for exec can be
incorporated into functions, e.g. (untested):

proc execNoError {cmd args} {
if {[catch {set result [eval exec [list $cmd] $args]} result]} {
tk_messageBox -type ok -icon error -title [G_msg "Error"] -message [G_msg $result]
# force the caller to return
uplevel 1 return
}
return $result
}

This would allow simple cases to avoid explicit error handling
altogether.

--
Glynn Clements <***@gclements.plus.com>

Michael Barton

2007-09-03 17:27:54 UTC

If you find yourself typing 130+ instances of near-identical code,
that should be a clue that you should add some more infrastrcture.
proc errorBox {msg} {
tk_messageBox -type ok -icon error -title [G_msg "Error"] -message $msg
}
tk_messageBox -type ok -icon error -title [G_msg "Error"] \
-message [G_msg "Error creating tempfile: $error"]
errorBox [G_msg "Error creating tempfile: $error"]

Agreed that this reduces the number of characters in the code. But it isn't
much different timewise for cutting and pasting. It would make it easier to
globally format all error messages in the future.

Post by Glynn Clements
[
BTW, this usage of G_msg is probably incorrect, as the entire message,
errorBox "[G_msg {Error creating tempfile}]: $error"
errorBox "[G_msg {Error creating tempfile}]: [G_msg $error]"
so that "Error creating tempfile" and the error message will be
translated independently. This means that you only need A+B
translations instead of A*B. The second G_msg is only necessary if
Tcl/Tk error messages aren't already localised by Tcl/Tk.
Note that the situation is different with C, where "%s" is included
literally in the message key. In Tcl, $error will be substituted
before the message is translated.
]

This is important to know for internationalization. Probably worth going
back and redoing. An error function probably wouldn't have made this any
easier unfortunately.

Post by Glynn Clements
Beyond that, the common error-trapping idioms for exec can be
proc execNoError {cmd args} {
if {[catch {set result [eval exec [list $cmd] $args]} result]} {
tk_messageBox -type ok -icon error -title [G_msg "Error"] -message [G_msg
$result]
# force the caller to return
uplevel 1 return
}
return $result
}
This would allow simple cases to avoid explicit error handling
altogether.

In retrospect, it would have been better to have a single command processing
function that used arguments or flags to merge the multiple ones now in the
TclTk GUI (run, run_ui, execute, ...) and handle error trapping at the same
time--as per Hamish' comments in a related thread and as we're doing with
cmd.Command in wxgrass. It's quite a bit of work to go back and fix this in
TclTk. If we were keeping the TclTk GUI into the future, it would definitely
be worth the effort. I'm not sure it is now, given that we're switching to
wxPython.

Michael

__________________________________________
Michael Barton, Professor of Anthropology
Director of Graduate Studies
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

Glynn Clements

2007-09-03 20:24:52 UTC

Post by Glynn Clements
If you find yourself typing 130+ instances of near-identical code,
that should be a clue that you should add some more infrastrcture.
proc errorBox {msg} {
tk_messageBox -type ok -icon error -title [G_msg "Error"] -message $msg
}
tk_messageBox -type ok -icon error -title [G_msg "Error"] \
-message [G_msg "Error creating tempfile: $error"]
errorBox [G_msg "Error creating tempfile: $error"]

It isn't about the time required to enter the code in the first place.
It's about being able to subsequently change the behaviour for all
instances by modifying a single function rather than 100+ copies.

IOW: abstraction. Keep the details of error handling in one place (or
a few places), and have the individual instances simply request that
an error be handled.

Beyond that, it's not uncommon for large projects to have substantial
hierarchies of "stub" functions for common operations, simply to
categorise the flows. E.g.:

void handle_file_read_error(const char *msg) {
handle_file_error(msg);
}

void handle_file_write_error(const char *msg) {
handle_file_error(msg);
}

void handle_file_error(const char *msg) {
handle_io_error(msg);
}

void handle_io_error(const char *msg) {
handle_error(msg);
}

void handle_error(const char *msg) {
/* the real work is done here */
}

As it stands, this offers no advantage over either calling
handle_error() directly or, at the other extreme, simply inlining the
error handling.

But in practice, code seldom gets written then left untouched for the
rest of its days. When it comes to making changes, the above structure
means that you can change the handling of a particular category of
cases without being limited to a choice of either modifying
handle_error() (and affecting every case), or having to manually
modify individual occurrences.

Post by Glynn Clements
Beyond that, the common error-trapping idioms for exec can be
proc execNoError {cmd args} {
if {[catch {set result [eval exec [list $cmd] $args]} result]} {
tk_messageBox -type ok -icon error -title [G_msg "Error"] -message [G_msg $result]
# force the caller to return
uplevel 1 return
}
return $result
}
This would allow simple cases to avoid explicit error handling
altogether.

This is an area where a hierarchy similar to the above would be
applicable. A single level (one function called directly from
throughout the code) won't suffice. Even without the "term" case
(legacy programs requiring an xterm), you probably need one case for
display commands, one for "normal" computational commands run from the
menus, one for obtaining the interface description with --tcltk, etc.

At the lowest level, you would have one command, either with a lot of
options or which is little more than "exec" itself.

For any additional steps which it might perform, there is probably
some case where you would want to avoid that. To handle that, you
either provide options to enable/disable the additional functionality,
or have multiple higher-level functions which provide the additional
functionality, or some combination of the two. Specific cases either
use the appropriate set of options or call the appropriate
higher-level version.

E.g. for display commands, you probably wouldn't want errors to
reported through dialogs. If the user sets an option which causes most
display commands to fail, they won't want to have to individually
acknowledge a dozen error dialogs before they can correct the problem.

[Remember when web browsers would pop up an error dialog whenever an
error occurred? The current behaviour of reporting the problem in the
frame is a lot less annoying.]

--
Glynn Clements <***@gclements.plus.com>

Michael Barton

2007-09-03 19:23:47 UTC

I think that DialogGen was written a long time ago, before tk_messageBox
existed.

Michael

Post by Maris Nartiss
Hi,
when I wrote additional error trapping for GRASS startup screen I used
DialogGen as it was already used there. Now maybe it's time to ask -
why DialogGen instead of plain tk_messageBox? Is there some reason why
startup screen uses DialoGen and not tk native widgets? Probably we
should get rid of DialogGen popups in startup screen too.
http://www.tcl.tk/man/tcl8.4/TclCmd/tclvars.htm#M18
Just my 0.02,
Maris.

__________________________________________
Michael Barton, Professor of Anthropology
Director of Graduate Studies
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

Michael Barton

2007-09-05 04:19:01 UTC

Here's the generic error function I planning to add. It seems to work pretty
good. Let me know if you see any problems or can suggest further
enhancements. I'm going to put it into gm.tcl where it will be available to
all GUI modules except gis_set.tcl (which runs before everything else, but
is not sourced by the main GUI).

proc Gm::errmsg { error args } {
# send error report and optional message (args) to tk_messageBox

set message ""

if { $args != ""} {
set message [G_msg [join $args]]
append message ": "
}

tk_messageBox -type ok -icon error -title [G_msg "Error"] \
-message "$message[G_msg $error]"
uplevel 1 return

};

Michael

Post by Glynn Clements
proc errorBox {msg} {
tk_messageBox -type ok -icon error -title [G_msg "Error"] -message $msg
}
tk_messageBox -type ok -icon error -title [G_msg "Error"] \
-message [G_msg "Error creating tempfile: $error"]
errorBox [G_msg "Error creating tempfile: $error"]
[
BTW, this usage of G_msg is probably incorrect, as the entire message,
errorBox "[G_msg {Error creating tempfile}]: $error"
errorBox "[G_msg {Error creating tempfile}]: [G_msg $error]"
so that "Error creating tempfile" and the error message will be
translated independently. This means that you only need A+B
translations instead of A*B. The second G_msg is only necessary if
Tcl/Tk error messages aren't already localised by Tcl/Tk.
Note that the situation is different with C, where "%s" is included
literally in the message key. In Tcl, $error will be substituted
before the message is translated.
]

__________________________________________
Michael Barton, Professor of Anthropology
Director of Graduate Studies
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

Glynn Clements

2007-09-05 16:27:46 UTC

Post by Michael Barton
Here's the generic error function I planning to add. It seems to work pretty
good. Let me know if you see any problems or can suggest further
enhancements. I'm going to put it into gm.tcl where it will be available to
all GUI modules except gis_set.tcl (which runs before everything else, but
is not sourced by the main GUI).
proc Gm::errmsg { error args } {
# send error report and optional message (args) to tk_messageBox
set message ""
if { $args != ""} {
set message [G_msg [join $args]]
append message ": "
}
tk_messageBox -type ok -icon error -title [G_msg "Error"] \
-message "$message[G_msg $error]"
uplevel 1 return
};

I'm not sure that it's appropriate for the translation to be done
here; the caller has a better understanding of where the message
boundaries lie.

If it's done here, each arg should probably be translated
individually; the caller can always join any arguments which should be
translated as a whole. Even then, there's no option to have a portion
which doesn't get translated.

--
Glynn Clements <***@gclements.plus.com>

Michael Barton

2007-09-06 06:01:46 UTC

I'm not sure that it's appropriate for the translation to be done
here; the caller has a better understanding of where the message
boundaries lie.

It seems cleaner to work with in the scripts if we only need to put in the
error variable and a text string. This way ensures that the message gets
translated.

Is there someone out there with a non-english system that could test whether
this is a problem?

Post by Glynn Clements
If it's done here, each arg should probably be translated
individually; the caller can always join any arguments which should be
translated as a whole. Even then, there's no option to have a portion
which doesn't get translated.

Like this???

proc Gm::errmsg { error args } {
# send error report and optional message (args) to tk_messageBox
set message ""
for arg in $args {

if { $arg != "" } {
append message "$arg "
}
}

append message ": "

tk_messageBox -type ok -icon error -title [G_msg "Error"] \
-message "$message[G_msg $error]"
uplevel 1 return

};

Only formatting drawback is that the end result will have "string string : "
(space before colon). Not a huge problem I guess.

You are right. A downside of enforcing translation within the function,
rather than relying on it to be done in the original script, is that the
whole thing gets translated. I'm not sure if this is really a problem with
short, optional error messages in reality.

Michael
__________________________________________
Michael Barton, Professor of Anthropology
Director of Graduate Studies
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

Glynn Clements

2007-09-07 20:30:37 UTC

I meant to pass each individual arg to G_msg then join the result,
i.e. replace:

if { $args != ""} {
set message [G_msg [join $args]]
append message ": "
}

with:

if { $args != ""} {
set trans {}
foreach msg $args {
lappend trans [G_msg $msg]
}
set message [G_msg [join $trans]]
append message ": "
}

Post by Michael Barton
You are right. A downside of enforcing translation within the function,
rather than relying on it to be done in the original script, is that the
whole thing gets translated. I'm not sure if this is really a problem with
short, optional error messages in reality.

The problem occurs if the error message includes variable components,
e.g. "unable to open $filename" or "error executing $prog".

Only the fixed portions should be translated (otherwise the message
catalogue would need an entry for every possible string), then the
variable portions should be inserted afterwards.

If the variable portions occur in the middle of the string, you would
want something like:

set template [G_msg {unable to open $filename for reading}]
set message [subst -nobackslashes -nocommands $template]

Actually, this could be done in the error handling procedure, using
"uplevel" to allow "subst" to use variables from the caller.

Ultimately, I still think that it's better to have the caller perform
the translation. In C code, the _() macro is always applied to the
literal string; we don't make G_fatal_error() call _().

Apart from anything else, it makes it easier to identify strings which
require translation ("grep G_msg").

--
Glynn Clements <***@gclements.plus.com>

Michael Barton

2007-09-07 22:49:45 UTC

OK. I see what you mean.

Michael

I meant to pass each individual arg to G_msg then join the result,
if { $args != ""} {
set message [G_msg [join $args]]
append message ": "
}
if { $args != ""} {
set trans {}
foreach msg $args {
lappend trans [G_msg $msg]
}
set message [G_msg [join $trans]]
append message ": "
}

The problem occurs if the error message includes variable components,
e.g. "unable to open $filename" or "error executing $prog".
Only the fixed portions should be translated (otherwise the message
catalogue would need an entry for every possible string), then the
variable portions should be inserted afterwards.
If the variable portions occur in the middle of the string, you would
set template [G_msg {unable to open $filename for reading}]
set message [subst -nobackslashes -nocommands $template]
Actually, this could be done in the error handling procedure, using
"uplevel" to allow "subst" to use variables from the caller.
Ultimately, I still think that it's better to have the caller perform
the translation. In C code, the _() macro is always applied to the
literal string; we don't make G_fatal_error() call _().
Apart from anything else, it makes it easier to identify strings which
require translation ("grep G_msg").

Michael Barton

2007-09-09 04:09:31 UTC

I redid this last night to follow this model. It's in the cvs now.

Michael