[GRASS-dev] Re: winGRASS

[Paul Kelly]

Hello Moritz
Better late than never to respond to some of these issues.
(Sorry about that last mail; sent it far too soon...)

On Mon, 18 Dec 2006, Moritz Lennert wrote:

> Here are some more issues:
>
[...]
> Did that. I also added a 'set GRASS_WISH=' command in grass63.bat, as it
> didn't seem to find my wish command.

Right. init.bat will need to be changed to set GRASS_WISH by default I
think - I was under the impression that it only needed to be set if the
wish executable wasn't in the path, but there seem to be places in gis.m
and nviz that rely on it being set and crash if it isn't. FWIW with the
Activestate Tcl/Tk that I was using there are executables named both
wish.exe and wish84.exe, which are identical. With the MinGW Tcl/Tk there
is only wish84.exe.


> Now, to go on:
>
> - I had hoped that Radim's patch for dbmi_client
> (http://grass.itc.it/pipermail/grass5/2006-December/028118.html) might
> solve the issue I've had with the db protocol errors, but apparently this
> is not the case. When I push the 'show the attribute columns' in a vector
> panel, I still get
>
> *******
> Displaying column types/names for database connection of layer 1:
> dbmi: Protocol error
>
> Cannot open table <streams>
> ********
>
> and a 'v.db.select' on the same map gives me:
>
> ********
> 'vector/streams' was found in more mapsets (also found in user1).
> dbmi: Protocol error
>
> Cannot open select cursor
> *********
>
> Radim, as you have been working on this these days, do you have an idea
> what might be wrong ?

I can confirm similar problems. I tried to import a Shapefile with
v.in.ogr. I went quite deep into debugging it and got nowhere at all,
although I should have taken better notes. I did confirm though that
compiling the library with -mwindows as Radim suggested on the list made
no difference either. I think trying with a different database, PostgreSQL
perhaps is the next big step to debugging this. See if the behaviour is
the same as with dbf and if not we can isolate it a bit more.
(Markus, this is what you were asking about what would be the next step
towards solving this.)

> - I noticed that I can close the com.exe window and still continue using
> grass. Is there any reason to keep this open ? If not, is there a way to
> close it automatically ? Just a question of not multiplying unnecessary
> windows.

It is running init.bat. When gis.m exits then etc/clean_temp will be run
to clean up the temporary files. It is possible to minmise it (by editing
the properties of the shortcut to grass63.bat) but I don't know how to
make it disappear.

> - Help does not work. In individual command windows, the help button is
> desactivated. In layer panels in the main GIS Manager window, when I push
> the help button, I get:
>
> child process exited abnormally
> child process exited abnormally
>    while executing
> "exec -- g.manual d.vect >& NUL:"
>    ("eval" body line 1)
>    invoked from within
> "eval [list exec -- $cmd] $args >& $devnull"
>    (procedure "run" line 8)
>    invoked from within
> "run g.manual d.vect"
>    ("uplevel" body line 1)
>    invoked from within
> "uplevel \#0 $cmd"
>    (procedure "Button::_release" line 18)
>    invoked from within
> "Button::_release .mainframe.frame.pw1.f1.frame.sw.sf.frame.fr.name.e"
>    (command bound to event)
>

This was due to g.parser assuming the shell (c:\msys\1.0\bin\sh.exe) that
it needed to run g.manual (required for all the help) was in the path. I
have since changed the way it operates on Windows to first check the
environment variable GRASS_SH before looking for sh.exe in the path. So
the help should work now.

> - export map canvas to graphics file:
>
> couldn't execute "rm": no such file or directory
> couldn't execute "rm": no such file or directory
>    while executing
> "exec rm $path.ppm"
>    ("jpg" arm line 7)
>    invoked from within
> "switch $type {
>                       "ppm" {
>                               return
>                       }
>                       "tif" {
>                               exec gdal_translate $path.ppm $path.tif -of GTI$
>                               exec rm $path.ppm
>                       }
>                       "bmp" {
>                               e..."
>    (procedure "MapToolBar::savefile" line 22)
>    invoked from within
> "MapToolBar::savefile jpg 50"
>    (menu invoke)
>
> So, graphics file gets created, but the original ppm file is not erased.

I think Michael has fixed those occurences of exec rm now so the Tcl file
delete function is used. So it should be OK.

Another outstanding issue is Nviz. It was working on Windows for a while
(looked great with Michael's new user interface improvements) but since 
Bob changed it back to the script startup rather than running the nviz.exe
executable directly it no longer works on Windows. In fact I recently 
tried to revert those changes and found it still wouldn't work; got stuck 
at the Please Wait screen. A pity, because there is probably very little 
needs changed to have it working again.

There are also a few other things that need tidying up. Having backslashes
instead of forward slashes in the setting of WINGISBASE in grass63.bat is
an obvious one. Should be really simple with use of sed in the Makefile
but I couldn't get it to work.

More later.

Paul