I have built from source various releases of GRASS over the years with
relatively few problems. However, I just built/installed GRASS 6.3.0RC6
on a 64-bit Linux system (compiled with the 64-bit option turned on). I
did not receive any install errors. GRASS starts-up fine until I select
"Enter" (following selecting my location and mapset). Following this I
get a startup error message that reads: "Error setting region: child
process exited abnormally". The term window output looks like this:
GRASS 6.3.0RC6 (latlong_ohrfc):~/.ssh > Error in startup script: can't
read "parts(w)": no such variable
while executing
"set $parts(w) [expr round($parts(w)/$parts(ewres))*$parts(ewres)]"
(procedure "MapCanvas::zoom_gregion" line 16)
invoked from within
"MapCanvas::zoom_gregion $mon"
(procedure "MapCanvas::create" line 40)
invoked from within
"MapCanvas::create"
(procedure "Gm::startmon" line 11)
invoked from within
"Gm::startmon"
(procedure "Gm::create" line 79)
invoked from within
"Gm::create"
(procedure "main" line 30)
invoked from within
"main $argc $argv"
(file "/usr/local/grass-6.3.0RC6/etc/gm/gm.tcl" line 541)
Error in startup script: can't read "parts(w)": no such variable
while executing
"set $parts(w) [expr round($parts(w)/$parts(ewres))*$parts(ewres)]"
(procedure "MapCanvas::zoom_gregion" line 16)
invoked from within
"MapCanvas::zoom_gregion $mon"
(procedure "MapCanvas::create" line 40)
invoked from within
"MapCanvas::create"
(procedure "Gm::startmon" line 11)
invoked from within
"Gm::startmon"
(procedure "Gm::create" line 79)
invoked from within
"Gm::create"
(procedure "main" line 30)
invoked from within
"main $argc $argv"
(file "/usr/local/grass-6.3.0RC6/etc/gm/gm.tcl" line 541)
GRASS in the term window operates fine with command line input, but the
tcltk interface is DOA. What's interesting is that the tcltk output
window comes up and the medieval map slash window displays, but won't go
away until I click on the "OK" button which displays the error message.
Any ideas what's going on? I have 6.3 cvs on a different machine that
compiled & runs fine.
Regards,
Tom
__________________________________________
Michael Barton, Professor of Anthropology
Director of Graduate Studies
School of Human Evolution & Social Change
Center for Social Dynamics & Complexity
Arizona State University
> > GRASS 6.3.0RC6 (latlong_ohrfc):~/.ssh > Error in startup script:
> > can't read "parts(w)": no such variable
> > while executing
Michael:
> We've tried to trap this and provide better feedback, but if GDAL is
> broken/misinstalled/etc., this hits before any error trapping can be
> implemented.
Glynn:
AFAIK, this is due to g.region failing. It ought to be possible to
detect that g.region failed before you start trying to parse the
output.
And even if you can't detect the abnormal termination, you could
detect that the output is bogus.
Of course, that won't make everything work, but you could produce a
more useful error message.
It looks to see if the parts array was created. (the wording could still
be much improved... perhaps to "Check the g.region module" ?)
should that get an "exit" or "return" added after the error message?
or should it be thrown to the command line?
I had a weird problem with it when I tested it. I renamed bin/g.region
and created a new g.region with just the shebang & "exit 1" in it.
The splash startup historical map came up with the output window but then
froze. The splash map was stuck there until I went into the window
manager's (fluxbox) window list and selected "maximize" for the "Error"
window. Then I could see it (full screen) and hit [Ok] and get rid of the
splash screen and leave gis.m. I wrote this off as a fluxbox thing, but
maybe it needs to release the splash before it can make a new error
message popup box?
It looks to see if the parts array was created. (the wording could still
be much improved... perhaps to "Check the g.region module" ?)
should that get an "exit" or "return" added after the error message?
or should it be thrown to the command line?
I had a weird problem with it when I tested it. I renamed bin/g.region
and created a new g.region with just the shebang & "exit 1" in it.
The splash startup historical map came up with the output window but then
froze. The splash map was stuck there until I went into the window
manager's (fluxbox) window list and selected "maximize" for the "Error"
window. Then I could see it (full screen) and hit [Ok] and get rid of the
splash screen and leave gis.m. I wrote this off as a fluxbox thing, but
maybe it needs to release the splash before it can make a new error
message popup box?
__________________________________________
Michael Barton, Professor of Anthropology
Director of Graduate Studies
School of Human Evolution & Social Change
Center for Social Dynamics & Complexity
Arizona State University