[GRASS-dev] Re: winGRASS
Moritz Lennert
mlennert at club.worldonline.be
Thu Feb 8 18:14:43 EST 2007
On Wed, February 7, 2007 01:39, Paul Kelly wrote:
> On Mon, 18 Dec 2006, Moritz Lennert wrote:
>> - 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.)
Ok, so at least for me this will be one of the current priorities in
trying to debug.
>> - 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.
No, I still see exactly the same situation (with cvs from Feb. 5): greyed
out in individual module gui, error message in gis.m layer panel.
>
>> - 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.
Yes, works now.
- New thing in current (5/2) version: it seems that the grass63.bat file
is not adapted and copied to the bin directory during 'make install'.
Next to the db issues, I propose to actually work through the GDF tutorial
to test the functionalities in there. Should be a good starting point.
Moritz
More information about the grass-dev
mailing list