[GRASS-dev] displaying (slightly) broken raster maps in gis.m

GRASS GIS GRASS GIS developer
1

We noticed gis.m will not display a raster map if the cats/ file is
missing but d.rast will.

is this something to fix, or nothing to worry about?

(mapset was broken after bulk copy via FAT32 external hard drive problems)

Hamish

2

Gis.m is just a wrapper for d.rast. So I'm not sure why one should display a
map and the other one won't.

???

Michael
__________________________________________
Michael Barton, Professor of Anthropology
School of Human Evolution & Social Change
Center for Social Dynamics & Complexity
Arizona State University

phone: 480-965-6213
fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton

From: Hamish <hamish_nospam@yahoo.com>
Date: Fri, 7 Jul 2006 20:35:55 +1200
To: grass5 <grass-dev@grass.itc.it>
Subject: [GRASS-dev] displaying (slightly) broken raster maps in gis.m

We noticed gis.m will not display a raster map if the cats/ file is
missing but d.rast will.

is this something to fix, or nothing to worry about?

(mapset was broken after bulk copy via FAT32 external hard drive problems)

Hamish

3

Michael Barton wrote:

> We noticed gis.m will not display a raster map if the cats/ file is
> missing but d.rast will.
>
> is this something to fix, or nothing to worry about?
>
> (mapset was broken after bulk copy via FAT32 external hard drive problems)

Gis.m is just a wrapper for d.rast. So I'm not sure why one should display a
map and the other one won't.

gis.m/raster.tcl seems to do a bit more than just run d.rast.

BTW, looking at that code, I note that the failure to treat commands
as lists appears to be a common problem within gis.m, e.g.:

    set cmd "d.rast map=$opt($id,1,map)"

    # overlay
    if { $opt($id,1,overlay) } {
        append cmd " -o"
    }

[snip]

    # raster query
    if { $opt($id,1,rastquery) != "" } {
        append cmd " {$querytype=$opt($id,1,rastquery)}"
    }
    
    # background color
    if { $opt($id,1,bkcolor) != "" } {
        append cmd " bg=$opt($id,1,bkcolor)"
    }

Although this particular case should work (certainly, none of the
arguments can contain spaces, and I don't think that they can contain
braces), in general you should be using list operations, e.g.:

    set cmd [list d.rast map=$opt($id,1,map)]

    # overlay
    if { $opt($id,1,overlay) } {
        lappend cmd -o
    }

[snip]

    # raster query
    if { $opt($id,1,rastquery) != "" } {
        lappend cmd $querytype=$opt($id,1,rastquery)
    }
    
    # background color
    if { $opt($id,1,bkcolor) != "" } {
        lappend cmd bg=$opt($id,1,bkcolor)
    }

Etc.

Whilst it is technically sufficient to use list operations only where
necessary, that requires you to actually consider whether or not they
are necessary. As most of the time they aren't necessary, overlooking
the few cases where they /are/ necessary (e.g. filenames, SQL "WHERE"
clauses etc) becomes almost inevitable.

--
Glynn Clements <glynn@gclements.plus.com>

4

Glynn and Hamish,

Checking in. It sounds like it would be good to shift most command stuff to
lists as you suggested earlier.

Most of the raster layer option just uses d.rast. However, if you want to do
a color drape and put something into the drape map field, it switches to
d.his.

Michael
__________________________________________
Michael Barton, Professor of Anthropology
School of Human Evolution & Social Change
Center for Social Dynamics & Complexity
Arizona State University

phone: 480-965-6213
fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton

From: Glynn Clements <glynn@gclements.plus.com>
Date: Sat, 8 Jul 2006 08:49:46 +0100
To: Michael Barton <Michael.Barton@asu.edu>
Cc: Hamish <hamish_nospam@yahoo.com>, grass5 <grass-dev@grass.itc.it>
Subject: Re: [GRASS-dev] displaying (slightly) broken raster maps in gis.m

Michael Barton wrote:

We noticed gis.m will not display a raster map if the cats/ file is
missing but d.rast will.

is this something to fix, or nothing to worry about?

(mapset was broken after bulk copy via FAT32 external hard drive problems)

Gis.m is just a wrapper for d.rast. So I'm not sure why one should display a
map and the other one won't.

gis.m/raster.tcl seems to do a bit more than just run d.rast.

BTW, looking at that code, I note that the failure to treat commands
as lists appears to be a common problem within gis.m, e.g.:

    set cmd "d.rast map=$opt($id,1,map)"

    # overlay
    if { $opt($id,1,overlay) } {
        append cmd " -o"
    }

[snip]

    # raster query
    if { $opt($id,1,rastquery) != "" } {
        append cmd " {$querytype=$opt($id,1,rastquery)}"
    }
    
    # background color
    if { $opt($id,1,bkcolor) != "" } {
        append cmd " bg=$opt($id,1,bkcolor)"
    }

Although this particular case should work (certainly, none of the
arguments can contain spaces, and I don't think that they can contain
braces), in general you should be using list operations, e.g.:

    set cmd [list d.rast map=$opt($id,1,map)]

    # overlay
    if { $opt($id,1,overlay) } {
        lappend cmd -o
    }

[snip]

    # raster query
    if { $opt($id,1,rastquery) != "" } {
        lappend cmd $querytype=$opt($id,1,rastquery)
    }
    
    # background color
    if { $opt($id,1,bkcolor) != "" } {
        lappend cmd bg=$opt($id,1,bkcolor)
    }

Etc.

Whilst it is technically sufficient to use list operations only where
necessary, that requires you to actually consider whether or not they
are necessary. As most of the time they aren't necessary, overlooking
the few cases where they /are/ necessary (e.g. filenames, SQL "WHERE"
clauses etc) becomes almost inevitable.

--
Glynn Clements <glynn@gclements.plus.com>

5

Glynn,

I've removed all extraneous 'eval exec' syntax from gism I think, with the
exception of the procedures in runandoutput.tcl (attached here for
convenience because it's small). If I try to clean up the run and runcmd
procedures here, d.mon bombs in the gism startup. I don't know whether it is
due to writing to /dev/null or because of d.mon. Could you take a look and
offer any suggestions? Thanks.

Michael
__________________________________________
Michael Barton, Professor of Anthropology
School of Human Evolution & Social Change
Center for Social Dynamics & Complexity
Arizona State University

phone: 480-965-6213
fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton

From: Glynn Clements <glynn@gclements.plus.com>
Date: Sat, 8 Jul 2006 08:49:46 +0100
To: Michael Barton <Michael.Barton@asu.edu>
Cc: Hamish <hamish_nospam@yahoo.com>, grass5 <grass-dev@grass.itc.it>
Subject: Re: [GRASS-dev] displaying (slightly) broken raster maps in gis.m

Michael Barton wrote:

We noticed gis.m will not display a raster map if the cats/ file is
missing but d.rast will.

is this something to fix, or nothing to worry about?

(mapset was broken after bulk copy via FAT32 external hard drive problems)

Gis.m is just a wrapper for d.rast. So I'm not sure why one should display a
map and the other one won't.

gis.m/raster.tcl seems to do a bit more than just run d.rast.

BTW, looking at that code, I note that the failure to treat commands
as lists appears to be a common problem within gis.m, e.g.:

    set cmd "d.rast map=$opt($id,1,map)"

    # overlay
    if { $opt($id,1,overlay) } {
        append cmd " -o"
    }

[snip]

    # raster query
    if { $opt($id,1,rastquery) != "" } {
        append cmd " {$querytype=$opt($id,1,rastquery)}"
    }
    
    # background color
    if { $opt($id,1,bkcolor) != "" } {
        append cmd " bg=$opt($id,1,bkcolor)"
    }

Although this particular case should work (certainly, none of the
arguments can contain spaces, and I don't think that they can contain
braces), in general you should be using list operations, e.g.:

    set cmd [list d.rast map=$opt($id,1,map)]

    # overlay
    if { $opt($id,1,overlay) } {
        lappend cmd -o
    }

[snip]

    # raster query
    if { $opt($id,1,rastquery) != "" } {
        lappend cmd $querytype=$opt($id,1,rastquery)
    }
    
    # background color
    if { $opt($id,1,bkcolor) != "" } {
        lappend cmd bg=$opt($id,1,bkcolor)
    }

Etc.

Whilst it is technically sufficient to use list operations only where
necessary, that requires you to actually consider whether or not they
are necessary. As most of the time they aren't necessary, overlooking
the few cases where they /are/ necessary (e.g. filenames, SQL "WHERE"
clauses etc) becomes almost inevitable.

--
Glynn Clements <glynn@gclements.plus.com>

(attachments)

runandoutput.tcl (7.05 KB)

6

Michael Barton wrote:

I've removed all extraneous 'eval exec' syntax from gism I think, with the
exception of the procedures in runandoutput.tcl (attached here for
convenience because it's small). If I try to clean up the run and runcmd
procedures here, d.mon bombs in the gism startup. I don't know whether it is
due to writing to /dev/null or because of d.mon. Could you take a look and
offer any suggestions? Thanks.

proc run {cmd args} {
  # This and runcmd are being used to run command in the background
  # These used to go to stdout and stderr
  # but we don't want to pollute that console.
  # eval exec -- $cmd $args >@ stdout 2>@ stderr
  eval exec -- $cmd $args >& /dev/null
}

proc runcmd {cmd args} {
  global gronsole

  set ci [$gronsole annotate $cmd [list gism running]]

  eval run $cmd $args

  $gronsole remove_tag $ci running
}

Cases like this, where the arguments are passed as single list, have
to use eval, as exec expects each command-line argument to be a
separate argument. If you removed the eval, it would pass the entire
argument list as a single argument, which won't work.

This isn't a problem, as the "args" syntax (where a procedure's last
parameter is named "args") is guaranteed to construct the list
correctly.

The main point is to apply the same principles to run/runcmd as to
exec, i.e. either pass individual arguments or, if you need to use
e.g. "eval runcmd $cmd $args", ensure that the argument list is
constructed using list operations rather than string concatenation.

--
Glynn Clements <glynn@gclements.plus.com>

7

OK. Then I think I've got it done. I'll commit it next week.

Michael
__________________________________________
Michael Barton, Professor of Anthropology
School of Human Evolution & Social Change
Center for Social Dynamics & Complexity
Arizona State University

phone: 480-965-6213
fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton

From: Glynn Clements <glynn@gclements.plus.com>
Date: Sun, 16 Jul 2006 01:20:40 +0100
To: Michael Barton <michael.barton@asu.edu>
Cc: Hamish <hamish_nospam@yahoo.com>, grass5 <grass-dev@grass.itc.it>
Subject: Re: [GRASS-dev] displaying (slightly) broken raster maps in gis.m

Michael Barton wrote:

I've removed all extraneous 'eval exec' syntax from gism I think, with the
exception of the procedures in runandoutput.tcl (attached here for
convenience because it's small). If I try to clean up the run and runcmd
procedures here, d.mon bombs in the gism startup. I don't know whether it is
due to writing to /dev/null or because of d.mon. Could you take a look and
offer any suggestions? Thanks.

proc run {cmd args} {
# This and runcmd are being used to run command in the background
# These used to go to stdout and stderr
# but we don't want to pollute that console.
# eval exec -- $cmd $args >@ stdout 2>@ stderr
eval exec -- $cmd $args >& /dev/null
}

proc runcmd {cmd args} {
global gronsole

set ci [$gronsole annotate $cmd [list gism running]]

eval run $cmd $args

$gronsole remove_tag $ci running
}

Cases like this, where the arguments are passed as single list, have
to use eval, as exec expects each command-line argument to be a
separate argument. If you removed the eval, it would pass the entire
argument list as a single argument, which won't work.

This isn't a problem, as the "args" syntax (where a procedure's last
parameter is named "args") is guaranteed to construct the list
correctly.

The main point is to apply the same principles to run/runcmd as to
exec, i.e. either pass individual arguments or, if you need to use
e.g. "eval runcmd $cmd $args", ensure that the argument list is
constructed using list operations rather than string concatenation.

--
Glynn Clements <glynn@gclements.plus.com>