[GRASS-dev] Re: 'g.gui wxpython' won't work in wingrass as wxgui is a shell script

GRASS GRASS developer
1

On Mar 17, 2008, at 9:00 AM, grass-dev-request@lists.osgeo.org wrote:

Not really. Simple tasks can be done with just the GUI.

  One certainly won't go far only doing simple tasks.

Actually you can do some pretty complex stuff with the GUI. Try it.

More complex tasks really deserve a proper programming language. The
range inbetween, where bash is a reasonable solution, is actually
quite narrow.

  The only thing that I have to say in the defense of Bash is that
  the little languages always have a narrow, but not a negligible
  niche.

The thing that bash allows you to do is to chain together the same commands that you get in the GUI. That is, you can do the same stuff in the GUI that you can do by scripting, but it might take you a LOT longer to accomplish it.

Any scripting language that can interact with GRASS commands (i.e., most of them) can serve this same purpose. You can do it with Python, PERL, Java, TclTk, etc. Bash is handy because it comes preinstalled on Linux and Mac systems (and sh on earlier Unix systems) and was consistently available even when other scripting languages were not. It is only for this historical reason that it has become a standard for scripting in GRASS. IMHO, it's a pretty primitive and opaque programming language (e.g., you have to use another scripting language like awk to do floating point math). You can do a lot with it, but it is not easy to do or to deconstruct (or debug) what others have done. I say this in spite of having made a number of the existing GRASS Bash scripts, including some pretty complex ones (e.g., d.vect.thematic).

With GRASS 7 and opening up of GRASS for Windows, we have an opportunity to modernize scripting on GRASS (Note I am not a Windows user). There will always be people who script in Bash. It's great that one can do so. However, I think that it would benefit the community settle on a new scripting "standard" that is truly cross-platform and an easier, more up-to-date, powerful, and easier to use language. There are several good candidates for this, but Python has a number of pragmatic advantages in the current context.

What this means is that we need to have Python people volunteer to begin to rewrite existing Bash scripts in Python and begin writing any new scripts in that platform so that we can have the critical mass to encourage others to learn it and write in it. A couple people have started on this.

Michael

2

Michael Barton <michael.barton@asu.edu> writes:

>>> Not really. Simple tasks can be done with just the GUI.

>> One certainly won't go far only doing simple tasks.

> Actually you can do some pretty complex stuff with the GUI. Try it.

  Actually I've meant the ``... but it might take you a LOT
  longer...'' cases specifically here.

  Nowadays, it seems that even computer programmers, let alone
  users, have very little experience with programming [1].
  Consequently, even a simple ``show me a MODIS Total Totals index
  on a map'' task becomes unsolvable by adding a ``... for every
  day of july, 2007'' bit to it.

[1] http://www.stsc.hill.af.mil/CrossTalk/2008/01/0801DewarSchonberg.html

  Perhaps, my perception is influenced quite heavily by my
  experience with remote sensing (and to have 100 rasters per day
  for a monthly interval is hardly an untypical situation.) But I
  really believe that an ``average computer user'' is expected to
  know at least a couple of programming languages.

  Unfortunately, typical GUI cannot be easily programmed and thus
  (as it seems to me) discourages programming way too often.
  (Though the GRASS GUI seems to be on the right way to overcome
  this problem.)

>>> More complex tasks really deserve a proper programming language. The
>>> range inbetween, where bash is a reasonable solution, is actually
>>> quite narrow.

>> The only thing that I have to say in the defense of Bash is that
>> the little languages always have a narrow, but not a negligible
>> niche.

> The thing that bash allows you to do is to chain together the same
> commands that you get in the GUI. That is, you can do the same stuff
> in the GUI that you can do by scripting, but it might take you a LOT
> longer to accomplish it.

  Well, yes, but would one's actions be accurate after doing the
  same for 10 times? or 100 times? or 1000?

  Apart from the obvious unreliability of a tired user, any real
  life task has its time constraints.

> Any scripting language that can interact with GRASS commands (i.e.,
> most of them) can serve this same purpose. You can do it with Python,
> PERL, Java, TclTk, etc. Bash is handy because it comes preinstalled
> on Linux and Mac systems (and sh on earlier Unix systems) and was
> consistently available even when other scripting languages were not.
> It is only for this historical reason that it has become a standard
> for scripting in GRASS.

  Yes.

> IMHO, it's a pretty primitive and opaque programming language (e.g.,
> you have to use another scripting language like awk to do floating
> point math).

  That's quite a frequent practice (consider, e. g., `expr' in
  Tcl, or Cpp for C.) I don't think it should be afraid of.

> You can do a lot with it, but it is not easy to do or to deconstruct
> (or debug) what others have done. I say this in spite of having made
> a number of the existing GRASS Bash scripts, including some pretty
> complex ones (e.g., d.vect.thematic).

  Real programmers can write Shell in any language, I guess.

  To put it serious, it seems to me that the potential of the
  Shell wasn't fully exploited. (After all, where's that library
  of the Shell functions deemed useful for a GRASS programmer?)

> With GRASS 7 and opening up of GRASS for Windows, we have an
> opportunity to modernize scripting on GRASS (Note I am not a Windows
> user). There will always be people who script in Bash. It's great
> that one can do so.

  Yes, it certainly makes sense to support many different
  languages available for GRASS scripting.

> However, I think that it would benefit the community settle on a new
> scripting "standard" that is truly cross- platform and an easier,
> more up-to-date, powerful, and easier to use language. There are
> several good candidates for this, but Python has a number of
> pragmatic advantages in the current context.

  Indeed, it may be a reasonable decision. (Though it'd be
  interesting for me to know what are the particular problems with
  Tcl, which is both portable and was used in GRASS for quite some
  time?)

> What this means is that we need to have Python people volunteer to
> begin to rewrite existing Bash scripts in Python and begin writing
> any new scripts in that platform so that we can have the critical
> mass to encourage others to learn it and write in it. A couple people
> have started on this.

  I'm afraid that an attempt to rewrite /all/ the Shell scripts in
  Python will both take time and bring some mess along. Would
  you, e. g., consider an untested 100-lines Python substitute for
  a 50-lines Shell script (that's known to be working for years)
  to encourage anyone to write in Python?

  If there're particular strong points of Python, they're to be
  exploited first (is wxPython among the others?)

3

Ivan Shmakov <ivan@theory.asu.ru> writes:
Michael Barton <michael.barton@asu.edu> writes:

[...]

>> What this means is that we need to have Python people volunteer to
>> begin to rewrite existing Bash scripts in Python and begin writing
>> any new scripts in that platform so that we can have the critical
>> mass to encourage others to learn it and write in it. A couple
>> people have started on this.

> I'm afraid that an attempt to rewrite /all/ the Shell scripts in
> Python will both take time and bring some mess along. Would you,
> e. g., consider an untested 100-lines Python substitute for a
> 50-lines Shell script (that's known to be working for years) to
> encourage anyone to write in Python?

> If there're particular strong points of Python, they're to be
> exploited first (is wxPython among the others?)

  I may sound obvious here, but one more strong point could be
  added almost for free by exploiting an extended G_parser ().
  Namely, in order to ease the creation of ``smart'' wrappers, it
  may be allowed to introspect a GRASS module's CLI from Python.

  Furthermore, with introduction of an additional field, it may be
  allowed for a GRASS module to advertise its ``linearity'' on a
  particular field or fields. E. g., the following are
  equivalent:

$ g.remove rast=foo,bar,baz
$ g.remove rast=foo,bar ; g.remove rast=baz

  Thus a ``smart'' wrapper for `g.remove' should be allowed to run
  `g.remove' on ``chunks'' of a sufficiently large list to
  overcome the OS command line limits (if any.)

  Some ``smart'' wrappers for `g.mlist' and `r.mapcalc' would
  allow for something like:

   for rast in grass.g.mlist (["rast"], "2008-*-temperature"]):
       grass.r.mapcalc ("%s-celsius" % rast, "\"%s\" - 273.15" % rast)

  (BTW, does Python allow associative lists, or named arguments?)

  And there should be a module allowing one to use a Python
  function to perform raster arithmetic (like `r.mapcalc'), too.

  Surely, there're many other things that could be done to make
  Python quite a sophisticated platform for GRASS scripting. And
  I'm not certain that the time used to rewrite all the existing
  Shell scripts in Python cannot be spent better.

4

Ivan Shmakov wrote:

> IMHO, it's a pretty primitive and opaque programming language (e.g.,
> you have to use another scripting language like awk to do floating
> point math).

  That's quite a frequent practice (consider, e. g., `expr' in
  Tcl, or Cpp for C.) I don't think it should be afraid of.

At least Tcl's "expr" is actually part of the language. But Tcl isn't
a particularly good example here; very few languages have a separate
function for arithmetic.

> However, I think that it would benefit the community settle on a new
> scripting "standard" that is truly cross- platform and an easier,
> more up-to-date, powerful, and easier to use language. There are
> several good candidates for this, but Python has a number of
> pragmatic advantages in the current context.

  Indeed, it may be a reasonable decision. (Though it'd be
  interesting for me to know what are the particular problems with
  Tcl, which is both portable and was used in GRASS for quite some
  time?)

Tcl isn't much better than the Bourne shell as a language. The main
issue is its reliance upon textual substitution. Look at the number of
uses of "eval" and "subst" in e.g. gis.m; every one of those
demonstrates a deficiency in the language.

Textual substitution and "eval" make it easy to write code which only
"mostly" works, but falls down e.g. for values which contain syntactic
characters. E.g. it's common for code which deals with lists which
fails when list items contain spaces.

> What this means is that we need to have Python people volunteer to
> begin to rewrite existing Bash scripts in Python and begin writing
> any new scripts in that platform so that we can have the critical
> mass to encourage others to learn it and write in it. A couple people
> have started on this.

  I'm afraid that an attempt to rewrite /all/ the Shell scripts in
  Python will both take time and bring some mess along. Would
  you, e. g., consider an untested 100-lines Python substitute for
  a 50-lines Shell script (that's known to be working for years)
  to encourage anyone to write in Python?

The deficiences of the Bourne shell as a programming language are such
that I would tend to have more faith in a minimally-tested Python
re-write than in a shell script. Programs written in a real language
tend to either work or not work, while shell scripts tend to sort-of,
kind-of mostly work.

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

5

Glynn Clements <glynn@gclements.plus.com> writes:

>>> IMHO, it's a pretty primitive and opaque programming language
>>> (e.g., you have to use another scripting language like awk to do
>>> floating point math).

>> That's quite a frequent practice (consider, e. g., `expr' in Tcl, or
>> Cpp for C.) I don't think it should be afraid of.

> At least Tcl's "expr" is actually part of the language.

  So is Cpp, and Shell `expr', as long as POSIX is considered.

> But Tcl isn't a particularly good example here; very few languages
> have a separate function for arithmetic.

  There's nothing special in arithmetic. A separate little
  language may be employed for almost any task. And it may be
  implemented either at the core of the language, or as an
  extension.

>>> However, I think that it would benefit the community settle on a
>>> new scripting "standard" that is truly cross- platform and an
>>> easier, more up-to-date, powerful, and easier to use
>>> language. There are several good candidates for this, but Python
>>> has a number of pragmatic advantages in the current context.

>> Indeed, it may be a reasonable decision. (Though it'd be
>> interesting for me to know what are the particular problems with
>> Tcl, which is both portable and was used in GRASS for quite some
>> time?)

> Tcl isn't much better than the Bourne shell as a language. The main
> issue is its reliance upon textual substitution.

  Does it?

> Look at the number of uses of "eval" and "subst" in e.g. gis.m; every
> one of those demonstrates a deficiency in the language.

  Please forgive me if I sound too harsh here, but the gis.m
  source demonstrates the ignorance of its authors of the Tcl
  basics far better than the deficiency of the Tcl language.

  Please consider, e. g.:

% set a 2
2
% expr $a + 1
3
% expr { $a + 1 }
3
% set b "2 * 2"
2 * 2
% expr $a + 1
5
% expr { $a + 1 }
can't use non-numeric string as operand of "+"
%

  AFAIK, the use of `expr $x ...' was abolished as error-prone a
  while ago. The code using `expr { $x ... }', apart from being
  easier to understand and debug (since it doesn't rely on the
  textual substitution), also runs faster, as the whole form is
  byte-compiled just once (while `expr $x ...' is re-interpreted
  each time it's evaluated.)

  You may want to check the Tcler's Wiki [1] for the way how it
  works in Tcl.

> Textual substitution and "eval" make it easy to write code which only
> "mostly" works, but falls down e.g. for values which contain
> syntactic characters. E.g. it's common for code which deals with
> lists which fails when list items contain spaces.

  Yet again, please consider:

% set a "puts" ; set b "Hello, world!"
Hello, world!
% eval $a $b
can not find channel named "Hello,"
% eval [ list $a $b ]
Hello, world!
%

  The latter form is the one that is expected to be used most of
  the time. You may want to check [1] again.

  BTW, as the usual Tk `-command' option's argument is passed to
  `eval', the proper way to use a variable substitution in its
  argument is, e. g.:

    Button $row.b ... \
        -helptext [G_msg "labels file to display"] \
    -command [ list GmLabels::select_labels $id ]

  and not:

    Button $row.b ... \
        -helptext [G_msg "labels file to display"] \
    -command "GmLabels::select_labels $id"

  (To some extent, one may think of Tcl `eval' as operating on
  lists, and not strings.)

>>> What this means is that we need to have Python people volunteer to
>>> begin to rewrite existing Bash scripts in Python and begin writing
>>> any new scripts in that platform so that we can have the critical
>>> mass to encourage others to learn it and write in it. A couple
>>> people have started on this.

>> I'm afraid that an attempt to rewrite /all/ the Shell scripts in
>> Python will both take time and bring some mess along. Would you,
>> e. g., consider an untested 100-lines Python substitute for a
>> 50-lines Shell script (that's known to be working for years) to
>> encourage anyone to write in Python?

> The deficiences of the Bourne shell as a programming language are
> such that I would tend to have more faith in a minimally-tested
> Python re-write than in a shell script. Programs written in a real
> language tend to either work or not work, while shell scripts tend to
> sort-of, kind-of mostly work.

  This doesn't match my experience, as I've seen quite a few
  programs written in the ``real languages'' which are ``sort-of,
  kind-of mostly work.'' (May [2] serve as a recent example.)

  The better one knows a language, the less it will surprise him
  (and the others.)

[1] http://wiki.tcl.tk/
[2] http://trac.osgeo.org/grass/changeset/30281