[GRASS-dev] Re: winGRASS

[Markus Neteler]

Paul, Moritz, all,

I have added the vector-DB problem to
  
http://grass.gdf-hannover.de/wiki/WinGRASS_Current_Status#What_is_missing.3F
My suggestion is to maintain the list there updated.

Markus

Paul Kelly wrote on 02/07/2007 01:39 AM:
> 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
>
>
> _______________________________________________
> grass-dev mailing list
> grass-dev at grass.itc.it
> http://grass.itc.it/mailman/listinfo/grass-dev