[GRASS-dev] [bug #4960] (grass) gis.m has menu entries for nonexisting modules

GRASS GIS GRASS GIS developer
1

this bug's URL: http://intevation.de/rt/webrt?serial_num=4960
-------------------------------------------------------------------------

Subject: gis.m has menu entries for nonexisting modules

Platform: GNU/Linux/x86
grass obtained from: Trento Italy site
grass binary for platform: Compiled from Sources
GRASS Version: 6.1.0RC1

gis.m menus contain menu entries for modules which are missing for some
reason.

i.e. if I compile grass without C++, I don't have r.terraflow, but I sill
will have menu entry for it.

Couldn't there be something like script which runs after all module
compilation (before make install?) and masks unavailable module entries?
Logic like "if (! `ls dist.i686-pc-linux-gnu/bin | grep
menu.tcl.module["foo"]`) then disable(comment out)". As I'm not scripting
guru, I can't write such script.

-------------------------------------------- Managed by Request Tracker

2

This should be a wish, not a bug.

Nice idea to have autogenerated menus. I've floated it a time or two and
others have mentioned it too. Maybe someone knows how to do it.

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

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

From: Request Tracker <grass-bugs@intevation.de>
Reply-To: Request Tracker <grass-bugs@intevation.de>
Date: Thu, 3 Aug 2006 13:52:39 +0200 (CEST)
To: <grass-dev@grass.itc.it>
Subject: [GRASS-dev] [bug #4960] (grass) gis.m has menu entries for
nonexisting modules

this bug's URL: http://intevation.de/rt/webrt?serial_num=4960
-------------------------------------------------------------------------

Subject: gis.m has menu entries for nonexisting modules

Platform: GNU/Linux/x86
grass obtained from: Trento Italy site
grass binary for platform: Compiled from Sources
GRASS Version: 6.1.0RC1

gis.m menus contain menu entries for modules which are missing for some
reason.

i.e. if I compile grass without C++, I don't have r.terraflow, but I sill
will have menu entry for it.

Couldn't there be something like script which runs after all module
compilation (before make install?) and masks unavailable module entries?
Logic like "if (! `ls dist.i686-pc-linux-gnu/bin | grep
menu.tcl.module["foo"]`) then disable(comment out)". As I'm not scripting
guru, I can't write such script.

-------------------------------------------- Managed by Request Tracker

3

Michael Barton napisa?(a):

This should be a wish, not a bug.

No, it shouldn't be a wish only because we don't know how to fix it
currently.

All the user knows is that he selects an entry in the gis.m or d.m and
he gets "command not found" or whatever other error. It is a bug for
him. For me too.

Nice idea to have autogenerated menus. I've floated it a time or two and
others have mentioned it too. Maybe someone knows how to do it.

I'm not trying to be wise ass or whatever. I don't know too. Just let's
not pretend bugs are not bugs.

Maciek

4

Michael Barton wrote:

> gis.m menus contain menu entries for modules which are missing for some
> reason.
>
> i.e. if I compile grass without C++, I don't have r.terraflow, but I sill
> will have menu entry for it.
>
> Couldn't there be something like script which runs after all module
> compilation (before make install?) and masks unavailable module entries?
> Logic like "if (! `ls dist.i686-pc-linux-gnu/bin | grep
> menu.tcl.module["foo"]`) then disable(comment out)". As I'm not scripting
> guru, I can't write such script.

This should be a wish, not a bug.

Actually, I'm not sure that it should even be a wish.

Leaving the menu entry in place lets the user know that certain
functionality is "available", even if they have to get a newer version
or compile GRASS themselves. If the menu entry is simply omitted, they
won't even consider that option.

Also, testing whether an executable is present isn't the same thing as
testing whether or not it can actually be run. It's arguably better to
treat all such problems in a similar manner (attempt to run the module
and show any specific errors to the user) than to treat specially the
case where the executable is absent.

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

5

Good points.

Michael
__________________________________________
Michael Barton, Professor of Anthropology
School of Human Evolution & Social Change
Center for Social Dynamics and 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: Thu, 3 Aug 2006 23:19:20 +0100
To: Michael Barton <michael.barton@asu.edu>
Cc: Paolo Cavallini via RT <grass-bugs@intevation.de>,
<grass-dev@grass.itc.it>
Subject: Re: [GRASS-dev] [bug #4960] (grass) gis.m has menu entries for
nonexisting modules

Michael Barton wrote:

gis.m menus contain menu entries for modules which are missing for some
reason.

i.e. if I compile grass without C++, I don't have r.terraflow, but I sill
will have menu entry for it.

Couldn't there be something like script which runs after all module
compilation (before make install?) and masks unavailable module entries?
Logic like "if (! `ls dist.i686-pc-linux-gnu/bin | grep
menu.tcl.module["foo"]`) then disable(comment out)". As I'm not scripting
guru, I can't write such script.

This should be a wish, not a bug.

Actually, I'm not sure that it should even be a wish.

Leaving the menu entry in place lets the user know that certain
functionality is "available", even if they have to get a newer version
or compile GRASS themselves. If the menu entry is simply omitted, they
won't even consider that option.

Also, testing whether an executable is present isn't the same thing as
testing whether or not it can actually be run. It's arguably better to
treat all such problems in a similar manner (attempt to run the module
and show any specific errors to the user) than to treat specially the
case where the executable is absent.

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

6

Maciek,

What goes into the menu at the moment is what is a standard, complete (not
minimal) GRASS installation, AFAICT. I try to leave out things that are not
normally compiled and modules that require the installation of a separate
program that does not come with GRASS (I used to leave out r.out.gdal, for
example, but GDAL is now a required dependency and it is on the menu).
However, this does not account for someone who compiles GRASS and decides
not to include some module. Nor can it easily do so. Also, other people
besides me also add to the menu occasionally, and I may miss what is a
standard, complete install--especially given the rapidly changing state of
the program.

A new program to autogenerate a menu based on what a user decides to compile
is a new feature; its lack is not a bug. In fact, it is more accurate to
treat the missing feature as a bug than the non-functional menu item for it.
Unless someone else writes a program to automatically generate a
menu--probably requiring significant reorganization of the menu system--it
is not going to happen anytime soon. In the long run, it's worthwhile to
have such a system to better keep up with GRASS development. But probably it
won't really be feasible to consider such a system until the switch to a new
GUI development platform, like wxPython, where GUI descriptors and menus can
be stored in XML format. I also agree with the sentiment of Glynn's
comments. There should be a standard GUI for a standard GRASS installation.
I menu item that doesn't do anything signals that the program is not
complete, not that the menu is faulty.

I appreciate your perspective on this. However, there are more than enough
bugs of things that are actually broken to keep us all busy. But that
doesn't mean that we should keep open to ways to improve the program too.

Cheers
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: Maciej Sieczka <tutey@o2.pl>
Date: Thu, 03 Aug 2006 22:23:26 +0200
To: Michael Barton <michael.barton@asu.edu>
Cc: <grass-bugs@intevation.de>, <grass-dev@grass.itc.it>
Subject: Re: [GRASS-dev] [bug #4960] (grass) gis.m has menu entries for
nonexisting modules

Michael Barton napisa?(a):

This should be a wish, not a bug.

No, it shouldn't be a wish only because we don't know how to fix it
currently.

All the user knows is that he selects an entry in the gis.m or d.m and
he gets "command not found" or whatever other error. It is a bug for
him. For me too.

Nice idea to have autogenerated menus. I've floated it a time or two and
others have mentioned it too. Maybe someone knows how to do it.

I'm not trying to be wise ass or whatever. I don't know too. Just let's
not pretend bugs are not bugs.

Maciek

7

Hi,

as I'm not coder but simple user, I can not understand why letting program to
fail with user UNfrendly error is good point. If there could be discussion
about showing or hiding unavailable menu items*, then I don't see any reason
why there should be no check against does such module (file) exists.

And second - I never understood how RT works (yea, it's definitely not
Bugzilla), so You probably missed my proposed 3line quickfix. So - please
take a look at it and say a word - does such user friendly error handling is
bad for GRASS?

Just my 3c to make GRASS better,
Maris.

On Friday 04 August 2006 01:19, Glynn Clements wrote:

Also, testing whether an executable is present isn't the same thing as
testing whether or not it can actually be run. It's arguably better to
treat all such problems in a similar manner (attempt to run the module
and show any specific errors to the user) than to treat specially the
case where the executable is absent.

Here are my first 3 lines in tcl/tk.
W0ps - just found bug - it will fail IF $program already contains full path to
executable ($GISBASE/etc/gm/scripts/FOO).

--- gui/tcltk/gis.m/runandoutput.tcl.orig 2006-07-22
12:29:48.000000000 +0300
+++ gui/tcltk/gis.m/runandoutput.tcl 2006-08-03 23:09:43.000000000 +0300
@@ -65,10 +65,15 @@
}

proc run_ui {cmd} {
- global dlg path
+ global dlg path env

     set program [lindex $cmd 0]

+ if { ![file executable $env(GISBASE)/bin/$program] } {
+ tk_messageBox -icon error -message [G_msg "Sorry, your GRASS
installation lacks module \"$program\""]
+ return
+ }
+
     set code [exec -- $program --tcltk]

     set path .dialog$dlg

8

Ma-ris Nartišs napisa?(a):

--- gui/tcltk/gis.m/runandoutput.tcl.orig 2006-07-22
12:29:48.000000000 +0300
+++ gui/tcltk/gis.m/runandoutput.tcl 2006-08-03 23:09:43.000000000 +0300
@@ -65,10 +65,15 @@
}

proc run_ui {cmd} {
- global dlg path
+ global dlg path env

     set program [lindex $cmd 0]

+ if { ![file executable $env(GISBASE)/bin/$program] } {
+ tk_messageBox -icon error -message [G_msg "Sorry, your GRASS
installation lacks module \"$program\""]
+ return
+ }
+
     set code [exec -- $program --tcltk]

     set path .dialog$dlg

Ma-ris,

Very good, in my opinion. Easy to implement and making user's life
easier. I'd like to see it applied.

Maybe let's add to the message: "See REQUIREMENTS.html/Optional
requirements for details." (or something like that)

Maciek

9

Me-Dàris Nartie-B¹s wrote:e-A

as I'm not coder but simple user, I can not understand why letting program to
fail with user UNfrendly error is good point.

It would certainly be useful to improve error messages. Apart from
anything else, errors arising from executing commands from a menu item
shouldn't include the Tcl backtrace, only the actual error.

If there could be discussion
about showing or hiding unavailable menu items*, then I don't see any reason
why there should be no check against does such module (file) exists.

As I said before, non-existence is only one possible problem. The
executable itself might exist, but it might require shared libraries
which are missing, or it may be a script which uses an executable
which doesn't exist.

> Also, testing whether an executable is present isn't the same thing as
> testing whether or not it can actually be run. It's arguably better to
> treat all such problems in a similar manner (attempt to run the module
> and show any specific errors to the user) than to treat specially the
> case where the executable is absent.

Here are my first 3 lines in tcl/tk.
W0ps - just found bug - it will fail IF $program already contains full path to
executable ($GISBASE/etc/gm/scripts/FOO).

--- gui/tcltk/gis.m/runandoutput.tcl.orig 2006-07-22
12:29:48.000000000 +0300
+++ gui/tcltk/gis.m/runandoutput.tcl 2006-08-03 23:09:43.000000000 +0300
@@ -65,10 +65,15 @@
}

proc run_ui {cmd} {
- global dlg path
+ global dlg path env

     set program [lindex $cmd 0]

+ if { ![file executable $env(GISBASE)/bin/$program] } {

Not everything is in $GISBASE/bin; some are in $GISBASE/scripts or
$GISBASE/etc/gm/script. Also, on Windows the file itself may have a
.exe suffix.

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

10

This looks like a good workaround to the issue of missing modules. If it
works, go ahead and commit it.

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

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

From: Maciej Sieczka <tutey@o2.pl>
Date: Fri, 04 Aug 2006 10:47:41 +0200
To: Ma-ris Narti¹s <maris.gis@gmail.com>
Cc: <grass-dev@grass.itc.it>
Subject: Re: [GRASS-dev] [bug #4960] (grass) gis.m has menu entries for
nonexisting modules

Ma-ris Narti¹s napisa?(a):

--- gui/tcltk/gis.m/runandoutput.tcl.orig 2006-07-22
12:29:48.000000000 +0300
+++ gui/tcltk/gis.m/runandoutput.tcl 2006-08-03 23:09:43.000000000 +0300
@@ -65,10 +65,15 @@
}

proc run_ui {cmd} {
- global dlg path
+ global dlg path env

     set program [lindex $cmd 0]

+ if { ![file executable $env(GISBASE)/bin/$program] } {
+ tk_messageBox -icon error -message [G_msg "Sorry, your GRASS
installation lacks module \"$program\""]
+ return
+ }
+
     set code [exec -- $program --tcltk]

     set path .dialog$dlg

Ma-ris,

Very good, in my opinion. Easy to implement and making user's life
easier. I'd like to see it applied.

Maybe let's add to the message: "See REQUIREMENTS.html/Optional
requirements for details." (or something like that)

Maciek

11

Glynn's right. I got ahead of myself in encouraging this fix. Making a
better error trapping is a good idea. However this script can't just look in
$GISBASE/bin, it also has to look in $GISBASE/scripts and $GISBASE/etc/gm(or
dm)/script.

Michael
__________________________________________
Michael Barton, Professor of Anthropology
School of Human Evolution & Social Change
Center for Social Dynamics and 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: Fri, 4 Aug 2006 15:21:53 +0100
To: M?ris Narti¹s <maris.gis@gmail.com>
Cc: <grass-dev@grass.itc.it>
Subject: Re: [GRASS-dev] [bug #4960] (grass) gis.m has menu entries for
nonexisting modules

Not everything is in $GISBASE/bin; some are in $GISBASE/scripts or
$GISBASE/etc/gm/script. Also, on Windows the file itself may have a
.exe suffix.

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

12

Michael Barton wrote:

Glynn's right. I got ahead of myself in encouraging this fix. Making a
better error trapping is a good idea. However this script can't just look in
$GISBASE/bin, it also has to look in $GISBASE/scripts and $GISBASE/etc/gm(or
dm)/script.

And, as I already mentioned, a given command may or may not have a
.exe suffix. E.g. in the MinGW versions which I've built, programs
only get a .exe suffix if they don't contain any dots. OTOH, it's
possible to build an executable with no dots and without a .exe
suffix, and equally possible for an individual Makefile to force a
.exe suffix on any executable.

More generally, trying to figure out in advance whether executing a
given command will succeed is the wrong approach. The only reliable
approach is to actually run the command and check whether or not it
did succeed. If it didn't succeed, figuring out why isn't entirely
straightforward, as the error message (corresponding to ENOENT) will
vary between platforms, and depend upon the user's locale settings.

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

13

I suppose a partial solution would be to at least check to see if the
command file listed in the menu exists in one of the 3 standard locations
and return something on the order of "This GRASS command is not installed".
It wouldn't help if it was installed but not executable.

Michael
__________________________________________
Michael Barton, Professor of Anthropology
School of Human Evolution & Social Change
Center for Social Dynamics and 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: Fri, 4 Aug 2006 22:56:35 +0100
To: Michael Barton <michael.barton@asu.edu>
Cc: M?ris Narti¹s <maris.gis@gmail.com>, <grass-dev@grass.itc.it>
Subject: Re: [GRASS-dev] [bug #4960] (grass) gis.m has menu entries for
nonexisting modules

Michael Barton wrote:

Glynn's right. I got ahead of myself in encouraging this fix. Making a
better error trapping is a good idea. However this script can't just look in
$GISBASE/bin, it also has to look in $GISBASE/scripts and $GISBASE/etc/gm(or
dm)/script.

And, as I already mentioned, a given command may or may not have a
.exe suffix. E.g. in the MinGW versions which I've built, programs
only get a .exe suffix if they don't contain any dots. OTOH, it's
possible to build an executable with no dots and without a .exe
suffix, and equally possible for an individual Makefile to force a
.exe suffix on any executable.

More generally, trying to figure out in advance whether executing a
given command will succeed is the wrong approach. The only reliable
approach is to actually run the command and check whether or not it
did succeed. If it didn't succeed, figuring out why isn't entirely
straightforward, as the error message (corresponding to ENOENT) will
vary between platforms, and depend upon the user's locale settings.

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

14

Michael Barton wrote:

I suppose a partial solution would be to at least check to see if the
command file listed in the menu exists in one of the 3 standard locations
and return something on the order of "This GRASS command is not installed".
It wouldn't help if it was installed but not executable.

The problem is that you need to err on the side of caution, i.e. only
disable the option if you can guarantee that the command will fail.
Otherwise you're introducing a real bug to fix a not-really-a-bug.

That's assuming that you consider disabling menu items to be a good
idea in the first place (which I don't).

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