[GRASS5] some code cleanup?

GRASS GIS GRASS GIS developer
1

Hello everyone,

In my work of this week I found some annoyities in GRASS source code,
version 6.1 cvs (updated on Monday), that could be easily removed for
the sake of consistency.

Case 1. In the aprox. 300 GRASS commands, the following ones don't
honour the "--help" parameter (instead, they try to run): g.setproj,
i.ortho.photo, v.build.all, d.rast.edit, d.redraw, i.class, i.points
(and I get the message: "ERROR: The parser doesn't work here.") and
i.vpoints.

Moreover, the last five also complain if a graphics monitor is not
running, although the "--help" parameter should work without it.

BTW, Why the help messages go throught stderr instead stdout??

Case 2. There exists the help file, but the command doesn't build.
That is the case for: db.createdb, db.databases, db.dropdb and
db.droptable.

Case 3. There exist the directory, maybe with a Makefile, but the
command doesn't appear later: i.ask (in fact, it compiles but install
process put it in GRASS /etc directory instead /bin directory; is it
an internal command? it has no help), i.find (the same happens; it
goes to GRASS /etc directory), r3.mapcalculator (renamed to
r3.mapcalc?), r3.showdspf, r.carve, r.grow2, r.le, r.mask,
r.terraflow, r.univar2, s.in.ascii, s.out.ascii, v.in.dwg, v.lrs and
v.mapcalc.

Case 4. Also related to a previous message from Ari Jolma, I tried to
use the SWIG interface generation for GRASS and found that in file
"gisdefs.h" several function prototypes are defined, but the functions
are never implemented (or yet deprecated) in the GRASS source tree.

They are: G_ask_datum_params(), G_def_window(),
G_ellipsoid_grid_dist(), G_ellipsoid_grid_dist() (defined twice),
lzw_decode(), lzw_expand(), G_lzw_nof_read_bytes(),
G_lzw_max_used_bits(), G_lzw_set_bits(), G_lzw_compress(),
G_lzw_expand(), G_lzw_compress_count_only_array(),
G_lzw_compress_count_only_file(), G_lzw_write(),
G_lzw_write_noCompress(), G_lzw_test_status(), G_lzw_read2(),
G_lzw_read(), G_lzw_transfer_compress(), G_lzw_transfer_expand(),
G_open_support_old(), G_fopen_support_old(), G_open_support_new() and
G_fopen_support_new().

Also, in file "gis.h" the object CELL_NODATA is defined but never used in GRASS.

Hope it helps someone,

M.

--
-- marcos boullón magán

2

In my work of this week I found some annoyities in GRASS source code,
version 6.1 cvs (updated on Monday), that could be easily removed for
the sake of consistency.

"easily removed" may not be so easy.

Case 1. In the aprox. 300 GRASS commands, the following ones don't
honour the "--help" parameter (instead, they try to run): g.setproj,
i.ortho.photo, v.build.all, d.rast.edit, d.redraw, i.class, i.points
(and I get the message: "ERROR: The parser doesn't work here.") and
i.vpoints.

check the online help pages for modules missing a description.

I just fixed r.digit to use the parser, there was code there to catch
"--help" ...

BTW, Why the help messages go throught stderr instead stdout??

--help and bad_option= are treated the same, and warnings are sent to
stderr so you can do fine grain redirections, e.g.

r.out map > answers.txt

and get the data output to your file and error messages to the screen.
Or you can save the messages and send the data to /dev/null ...
Sometimes there are 1000s of warnings which hide the answer you are
looking for.
It's very useful.

I agree that with --help the "data" output is the descriptive text.
For a bad option parameter it isn't.

see also --html-description, --interface-description, and --tcltk

Hamish

3

marcos boullón magán wrote:

Case 3. There exist the directory, maybe with a Makefile, but the
command doesn't appear later: i.ask (in fact, it compiles but install
process put it in GRASS /etc directory instead /bin directory; is it
an internal command? it has no help), i.find (the same happens; it
goes to GRASS /etc directory),

These are internal commands.

r3.mapcalculator (renamed to r3.mapcalc?),

I don't know why r3.mapcalculator isn't installed, but r3.mapcalc is
built from the same directory as r.mapcalc. r.mapcalculator and
r3.mapcalculator are scripts which use the parser so that d.m/gis.m
can interface with them.

r3.showdspf,

I think it's been made redundant by NVIZ.

r.grow2,

r.grow2 is installed as r.grow. The original r.grow is no longer
present; the directory retains its name to preserve CVS history.

r.terraflow,

r.terraflow is only built if C++ support is enabled (--with-cxx).

Case 4. Also related to a previous message from Ari Jolma, I tried to
use the SWIG interface generation for GRASS and found that in file
"gisdefs.h" several function prototypes are defined, but the functions
are never implemented (or yet deprecated) in the GRASS source tree.

They are: G_ask_datum_params(), G_def_window(),
G_ellipsoid_grid_dist(), G_ellipsoid_grid_dist() (defined twice),
lzw_decode(), lzw_expand(), G_lzw_nof_read_bytes(),
G_lzw_max_used_bits(), G_lzw_set_bits(), G_lzw_compress(),
G_lzw_expand(), G_lzw_compress_count_only_array(),
G_lzw_compress_count_only_file(), G_lzw_write(),
G_lzw_write_noCompress(), G_lzw_test_status(), G_lzw_read2(),
G_lzw_read(), G_lzw_transfer_compress(), G_lzw_transfer_expand(),
G_open_support_old(), G_fopen_support_old(), G_open_support_new() and
G_fopen_support_new().

The LZW compression was removed a long time ago due to patent issues.
I don't know about the others.

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