On Feb 28, 2008, at 2:47 AM, grass-dev-request@lists.osgeo.org wrote:
Date: Thu, 28 Feb 2008 10:25:43 +0100
From: Moritz Lennert <mlennert@club.worldonline.be>
Subject: Re: [GRASS-dev] 'g.gui wxpython' won't work in wingrass as
wxgui is a shell script
To: Martin Landa <landa.martin@gmail.com>
Cc: Glynn Clements <glynn@gclements.plus.com>, GRASS devel
<grass-dev@grass.itc.it>
Message-ID: <47C67E17.8070305@club.worldonline.be>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
On 27/02/08 21:05, Martin Landa wrote:
Hi,
2008/2/21, Glynn Clements <glynn@gclements.plus.com>:
Moritz Lennert wrote:
as wxgui is a shell script, g.gui wxpython (which does:
else if (strcmp(type->answer, "wxpython") == 0) {
sprintf (progname, "%s/etc/wxpython/scripts/wxgui", G_gisbase());
if (rc_file->answer) {
G_spawn(progname, "wxgui", rc_file->answer, NULL);
)
will not work.
since gis.m and d.m are also shell scripts, g.gui tcltk|oldtcktk will
not work too(?)
I have never tried d.m, but for gis.m there is a gis.m.bat replacement
[1] which directly call the tcltk code.
There is one problem, when you run `g.gui wxpython`, the program is
waiting for thread termination. So you cannot use xterm when wxGUI is
running. I am not sure how to fix it since I am not so familiar with
G_spawn*.
I guess you will have to fork before you G_spawn ?
Moritz
[1]
http://trac.osgeo.org/grass/browser/grass/trunk/gui/tcltk/gis.m/gis.m.bat
I thought the whole reason to have a C-based g.gui was to avoid the use of *nix specific bash shell scripts for launching GUI's. That way they would work on all systems without the hack of having to rewrite *.sh as a *.bat. Why can't the C-code just do the job of the old shell scripts and directly launch the GUI code in TclTk or wxPython.
The shell scripts are only a convenience anyway, as these could be launched from the GRASS command line with a bit more complicated command--e.g., python "$GISBASE/etc/wxpython/wxgui.py" &
The name of the initialization module for each GUI (e.g., wxguy.py in wxPython) could be set to a variable in init.sh (or its successor) to avoid hard coding it in C.
Michael
Michael Barton <michael.barton@asu.edu> writes:
[...]
> I thought the whole reason to have a C-based g.gui was to avoid the
> use of *nix specific bash shell scripts for launching GUI's. That way
> they would work on all systems without the hack of having to rewrite
> *.sh as a *.bat. Why can't the C-code just do the job of the old
> shell scripts and directly launch the GUI code in TclTk or wxPython.
> The shell scripts are only a convenience anyway, as these could be
> launched from the GRASS command line with a bit more complicated
> command--e.g., python "$GISBASE/etc/wxpython/wxgui.py" &
> The name of the initialization module for each GUI (e.g., wxguy.py in
> wxPython) could be set to a variable in init.sh (or its successor) to
> avoid hard coding it in C.
It may be a stupid question, but what scripting language is
proposed to replace POSIX Shell in GRASS? The GRASS environment
seems to benefit a lot from relying on a Shell-like language.
E. g., I could hardly imagine using any language other than
Shell for the following:
$ g.mlist type=rast pattern=2008-\*-temperature \
(while read r ; do
s="$r"-celsius ; r.mapcalc "\"$s\" = \"$r\" - 273.15" ; \
done)
(Surely, there's an Olin Shivers et al work [1, 2], but it seems
to me that Shell is a bit easier to explain to a non-programmer
than Scheme [3, 4].)
[1] http://www.scsh.net/
[2] http://www.scsh.net/resources/commander-s.html
[3] http://www.r6rs.org/
[4] http://www.schemers.org/
Ivan Shmakov wrote:
> I thought the whole reason to have a C-based g.gui was to avoid the
> use of *nix specific bash shell scripts for launching GUI's. That way
> they would work on all systems without the hack of having to rewrite
> *.sh as a *.bat. Why can't the C-code just do the job of the old
> shell scripts and directly launch the GUI code in TclTk or wxPython.
> The shell scripts are only a convenience anyway, as these could be
> launched from the GRASS command line with a bit more complicated
> command--e.g., python "$GISBASE/etc/wxpython/wxgui.py" &
> The name of the initialization module for each GUI (e.g., wxguy.py in
> wxPython) could be set to a variable in init.sh (or its successor) to
> avoid hard coding it in C.
It may be a stupid question, but what scripting language is
proposed to replace POSIX Shell in GRASS?
Python.
The GRASS environment
seems to benefit a lot from relying on a Shell-like language.
E. g., I could hardly imagine using any language other than
Shell for the following:
$ g.mlist type=rast pattern=2008-\*-temperature \
(while read r ; do
s="$r"-celsius ; r.mapcalc "\"$s\" = \"$r\" - 273.15" ; \
done)
Interactive command-line use will continue to be through whichever
shell the user prefers, typically bash on Unix (maybe with the odd csh
user) and cmd.exe on Windows (with bash for people who prefer Unix but
have to use Windows).
But Unix shells suck as programming languages. The only reason to use
Bourne shell for scripts is the fact that an interpreter is guaranteed
to be present on every Unix system. But as GRASS is no longer limited
to Unix, that's no longer an advantage.
--
Glynn Clements <glynn@gclements.plus.com>
Glynn Clements <glynn@gclements.plus.com> writes:
[...]
>> It may be a stupid question, but what scripting language is proposed
>> to replace POSIX Shell in GRASS?
> Python.
ACK, thanks.
>> The GRASS environment seems to benefit a lot from relying on a
>> Shell-like language. E. g., I could hardly imagine using any
>> language other than Shell for the following:
>> $ g.mlist type=rast pattern=2008-\*-temperature \
>> (while read r ; do
>> s="$r"-celsius ; r.mapcalc "\"$s\" = \"$r\" - 273.15" ; \
>> done)
Since I don't know Python, could you please show me the script
like the above rewritten in it?
> Interactive command-line use will continue to be through whichever
> shell the user prefers, typically bash on Unix (maybe with the odd
> csh user) and cmd.exe on Windows
I wonder, how the script above could be rewritten for cmd.exe?
> (with bash for people who prefer Unix but have to use Windows).
> But Unix shells suck as programming languages.
Well, perhaps. But its orientation towards calling external
programs (and the GRASS modules are to be external in the
foreseeable future?) is a property which the majority of the
programming languages (at least of the set I know) don't posess.
> The only reason to use Bourne shell for scripts is the fact that an
> interpreter is guaranteed to be present on every Unix system. But as
> GRASS is no longer limited to Unix, that's no longer an advantage.
Ivan Shmakov wrote:
>> It may be a stupid question, but what scripting language is proposed
>> to replace POSIX Shell in GRASS?
> Python.
ACK, thanks.
>> The GRASS environment seems to benefit a lot from relying on a
>> Shell-like language. E. g., I could hardly imagine using any
>> language other than Shell for the following:
>> $ g.mlist type=rast pattern=2008-\*-temperature \
>> (while read r ; do
>> s="$r"-celsius ; r.mapcalc "\"$s\" = \"$r\" - 273.15" ; \
>> done)
Since I don't know Python, could you please show me the script
like the above rewritten in it?
mlist = Popen(["g.mlist", "type=rast", "pattern=2008-*-temperature"], stdout=PIPE)
for line in mlist.stdout:
map = line.rstrip()
call(["r.mapcalc", "\"%s-celsius\" = \"%s\" - 273.15" % (map, map)])
mlist.stdout.close()
> Interactive command-line use will continue to be through whichever
> shell the user prefers, typically bash on Unix (maybe with the odd
> csh user) and cmd.exe on Windows
I wonder, how the script above could be rewritten for cmd.exe?
I wouldn't suggest using cmd.exe for scripts. If you want portability,
use e.g. Python; if you don't, VB would probably be preferable to
cmd.exe.
> (with bash for people who prefer Unix but have to use Windows).
> But Unix shells suck as programming languages.
Well, perhaps. But its orientation towards calling external
programs (and the GRASS modules are to be external in the
foreseeable future?) is a property which the majority of the
programming languages (at least of the set I know) don't posess.
This is an advantage for interactive usage. For scripts, having to
explicitly type exec/spawn/popen/etc really isn't an issue. If
actually typing the script takes most of the time, you aren't spending
enough time thinking about what you're typing.
--
Glynn Clements <glynn@gclements.plus.com>