[GRASS5] Re: [GRASSLIST:4420] Re: bug fixes for tcltkgrass for GRASS 5.3

Maciek,

Previously these things all worked (except for r.resamp.rst, which is new
since I finished the menus late last Spring). I am guessing that changes to
the grass parser modules implemented over the summer have caused some of the
tcltkgrass modules in 5.3 to fail now.

To the list in general, it seems that a command with a flag will no longer
parse correctly in the tcltkgrass modules for 5.3. The odd thing is that
other arguments (at least one that I tried) do seem to parse OK. In a number
of cases, the flags were included with the command as a convenience.

I can add them as user options in the modules affected (I don't remember
which or how many at the moment), but does anyone have a clue why these are
not parsing now? The format is:

interface_build {
    {s.to.vect -p} 0
    {Converts a GRASS sites map to a GRASS vector map.}
    {entry input {Name of input site list:} 0 sites}
    {entry output {Name of new vector file:} 0 vector}
    {entry cat {String field in site_list to use in vector file
(default=1):} 0 ""}
}

It seems that the command string in brackets {s.to.vect -p} ought to parse
OK. Quoting it seems redundant. Any thoughts?

With respect to the scrolling, this is indeed an annoyance. It is NOT a
problem in GRASS 5.7 where module dialogs automatically scroll vertically or
horizontally as needed. There is a vertical scroll widget defined in gui.tcl
of tcltkgrass for 5.3, but I couldn't get it to work with modules. Perhaps
someone else would have better luck.

Michael

On 9/28/04 2:50 AM, "Maciek Sieczka" <werchowyna@pf.pl> wrote:

Michael,

thanks for fixing things
below I'm giving some comments and some more bugs I've found in the
tcltkgrass

2. After choosing GIS->Map type conversions->Sites to vector I'm
getting: couldn't execute "s.to.vect -p": no such file or directory

Fixed. Added option to enter or not enter metadata on new vector points
created. To do this, s.to.vect now opens in an xterm where you can enter
metadata if the -p flag is not checked.

"d.measure -s" also gives "couldn't execute (...)"
possible that more modules with a fixed "-" may behave the same if there are
any

IMO it uses a much different algorithm than s.surf.rst or v.surf.rst.
The only raster module utilizing regularized spline with tension is
r.resamp.rst (it'd be nice to have it in the tcltkgrass by the way).

how about about this module for r.resamp.rst some day?

3. There is no entry for v.surf.rst in the vector menu - only in the
raster menu.

Added module (already written by someone else) for v.surf.rst. Note that a
couple of options (anisotrophy and another) are left out because the
module is already as large as my screen and may not show up completely
on lower resolution screens. I don't know why there is not an option for a
vertical scroll-bar in the 5.3 menu module builder, but the modules are
limited (practically) to the vertical screen resolution.

in general this a pain
even if working in 1024x768 (which is not low I think) still some of the
menus are not visible in full extent
BTW it also considers the NVIZ (I put a bug report on this)

It may be recognized as a not very important issue but as to me it is a
bug - since tcltkgrass is supposed to be GUI and NVIZ means for
visualization as well then they should be fully functional according to all
the graphics features they put on the screen for the user.

I understand that there are technical limitations in what can be done using
the tcltk but for as a user I only see a bug which should be fixed.

BTW - what is the r.surf.idw2 for anyway when it is slower, less
universal and gives identical results. Strange... Ask Grass developers?

I don't know what the difference is either.

Can anybody say if there are any more diffrences between the r.surf.idw2
and *idw which justify both them being available?

and here a few more bugs:

1. r.surf.area should be r.surf.fractal propably because the output is:

Sorry, <out> is not a valid parameter
Sorry, <d> is not a valid parameter
Sorry, <n> is not a valid parameter

ERROR: Required parameter <input> not set:
(Raster file for surface.).

Description:
Surface area estimation for rasters.

Usage:
r.surf.area input=name [vscale=value]

Parameters:
   input Raster file for surface.
  vscale Vertical scale

2. Something's wrong with the r.surf.gauss. When anything given for
"Gaussian distribution mean" got:

Sorry, <d> is not a valid parameter

(...)

Usage:
r.surf.gauss out=name [mean=value] [sigma=value]

Parameters:
    out Name of the random surface to be produced
   mean Distribution mean
          default: 0.0
  sigma Standard deviation
          default: 1.0

3. If any "xyz" button pressed in the "d.3d" menu the result is as you can
see on the attached d3d_xyz.png. It's been the same since the first Grass
5.0 I've ever used .

4. "3d.views" doesn't work because there is no such thing in Grass 5.3 but
there is "3d.view.sh" which you propably mean.

5. After "OK" In the "Module font" I'm getting:

bad window path name ".s_proj"
bad window path name ".s_proj"
    while executing
"winfo children $path"
    (procedure "children" line 3)
    invoked from within
"children $path"
    (procedure "setfont" line 3)
    invoked from within
"setfont .$module $module_font"
    ("foreach" body line 1)
    invoked from within
"foreach module $module_list {setfont .$module $module_font} "
    invoked from within
".main_menu.mb9.m.m2 invoke active"
    ("uplevel" body line 1)
    invoked from within
"uplevel #0 [list $w invoke active]"
    (procedure "tk::MenuInvoke" line 47)
    invoked from within
"tk::MenuInvoke .main_menu.mb9.m.m2 1"
    (command bound to event)

Maciek

______________________________
Michael Barton, Professor of Anthropology
School of Human Diversity and Social Change
Arizona State University
Tempe, AZ 85287-2402
USA

voice: 480-965-6262; fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton

Michael Barton wrote:

Previously these things all worked (except for r.resamp.rst, which is new
since I finished the menus late last Spring). I am guessing that changes to
the grass parser modules implemented over the summer have caused some of the
tcltkgrass modules in 5.3 to fail now.

To the list in general, it seems that a command with a flag will no longer
parse correctly in the tcltkgrass modules for 5.3. The odd thing is that
other arguments (at least one that I tried) do seem to parse OK. In a number
of cases, the flags were included with the command as a convenience.

I can add them as user options in the modules affected (I don't remember
which or how many at the moment), but does anyone have a clue why these are
not parsing now? The format is:

interface_build {
    {s.to.vect -p} 0
    {Converts a GRASS sites map to a GRASS vector map.}
    {entry input {Name of input site list:} 0 sites}
    {entry output {Name of new vector file:} 0 vector}
    {entry cat {String field in site_list to use in vector file
(default=1):} 0 ""}
}

It seems that the command string in brackets {s.to.vect -p} ought to parse
OK. Quoting it seems redundant. Any thoughts?

I suspect that something is using "list" instead of "concat", e.g.:

  % set cmd {s.to.vect -p}
  % set arg foo
  % foreach word [list $cmd $arg] {puts $word}
  s.to.vect -p
  foo
  % foreach word [concat $cmd $arg] {puts $word}
  s.to.vect
  -p
  foo

Were there some changes made to deal with arguments which contain
spaces? That could explain it.

In order for commands with arguments in the module description to
work, the command (lindex $description 0) needs to be treated as a
list. But in order for arguments with spaces to work, they must be
treated as a single word.

E.g.:

  % set cmd {s.to.vect -p}
  % set arg {foo bar}
  % foreach word [list $cmd $arg] {puts $word}
  s.to.vect -p
  foo bar
  % foreach word [concat $cmd $arg] {puts $word}
  s.to.vect
  -p
  foo
  bar

The first is wrong, because it doesn't split the command. The second
is wrong because it splits the argument. You need to use concat but
"wrap" the argument:

  % foreach word [concat $cmd [list $arg]] {puts $word}
  s.to.vect
  -p
  foo bar

However, the 5.3 tcltkgrass is so complex that I'm not even going to
try to figure out what needs to be changed where. Also, essentially
the same problem can occur in lots of different ways (e.g. lappend,
append, eval, subst "$foo $bar", etc).

It's an inherent consequence of the fact that, in Tcl, everything is a
string (a list of strings is simultaneously both a string and a list
of strings).

Also, the use of variables whose values are variable names tends to
result in incomprehensible code; unfortunately, the 5.3 version of
tcltkgrass does a lot of that.

--
Glynn Clements <glynn.clements@virgin.net>

Glynn,

Given your explanation below, it seems that simplest thing is to treat the
few cases where flags are included with the GRASS 5.3 command in a
tcltkgrass module as user options. Then the flags are treated as arguments
that are parsed correctly. I'll try to ferret out which other ones need to
be changed over the weekend and do so.

Michael

On 9/28/04 6:40 PM, "Glynn Clements" <glynn.clements@virgin.net> wrote:

Michael Barton wrote:

Previously these things all worked (except for r.resamp.rst, which is new
since I finished the menus late last Spring). I am guessing that changes to
the grass parser modules implemented over the summer have caused some of the
tcltkgrass modules in 5.3 to fail now.

To the list in general, it seems that a command with a flag will no longer
parse correctly in the tcltkgrass modules for 5.3. The odd thing is that
other arguments (at least one that I tried) do seem to parse OK. In a number
of cases, the flags were included with the command as a convenience.

I can add them as user options in the modules affected (I don't remember
which or how many at the moment), but does anyone have a clue why these are
not parsing now? The format is:

interface_build {
    {s.to.vect -p} 0
    {Converts a GRASS sites map to a GRASS vector map.}
    {entry input {Name of input site list:} 0 sites}
    {entry output {Name of new vector file:} 0 vector}
    {entry cat {String field in site_list to use in vector file
(default=1):} 0 ""}
}

It seems that the command string in brackets {s.to.vect -p} ought to parse
OK. Quoting it seems redundant. Any thoughts?

I suspect that something is using "list" instead of "concat", e.g.:

% set cmd {s.to.vect -p}
% set arg foo
% foreach word [list $cmd $arg] {puts $word}
s.to.vect -p
foo
% foreach word [concat $cmd $arg] {puts $word}
s.to.vect
-p
foo

Were there some changes made to deal with arguments which contain
spaces? That could explain it.

In order for commands with arguments in the module description to
work, the command (lindex $description 0) needs to be treated as a
list. But in order for arguments with spaces to work, they must be
treated as a single word.

E.g.:

% set cmd {s.to.vect -p}
% set arg {foo bar}
% foreach word [list $cmd $arg] {puts $word}
s.to.vect -p
foo bar
% foreach word [concat $cmd $arg] {puts $word}
s.to.vect
-p
foo
bar

The first is wrong, because it doesn't split the command. The second
is wrong because it splits the argument. You need to use concat but
"wrap" the argument:

% foreach word [concat $cmd [list $arg]] {puts $word}
s.to.vect
-p
foo bar

However, the 5.3 tcltkgrass is so complex that I'm not even going to
try to figure out what needs to be changed where. Also, essentially
the same problem can occur in lots of different ways (e.g. lappend,
append, eval, subst "$foo $bar", etc).

It's an inherent consequence of the fact that, in Tcl, everything is a
string (a list of strings is simultaneously both a string and a list
of strings).

Also, the use of variables whose values are variable names tends to
result in incomprehensible code; unfortunately, the 5.3 version of
tcltkgrass does a lot of that.

______________________________
Michael Barton, Professor of Anthropology
School of Human Diversity and Social Change
Arizona State University
Tempe, AZ 85287-2402
USA

voice: 480-965-6262; fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton