[GRASS5] Need testers for tcltkgrass update for 5.7

[Michael Barton]

Glynn,

This sounds like a plan. I'll go ahead and commit menu.tcl and gui.tcl it as
is now (Moritz had no problems with it either). I think this kind of
scripting within GRASS is potentially quite useful. I wonder how many people
use it in GRASS 5.3? To revive scripting, all commands would have to
eventually be set up to write to stdout, correct?

Michael

On 8/18/04 7:04 AM, "Glynn Clements" <glynn.clements at virgin.net> wrote:

> 
> Michael Barton wrote:
> 
>>>> I'll check this version on my Mac also and look it over. I'll wait to
>>>> commit
>>>> this until I hear back from Moritz (or anyone else who wants to weigh in on
>>>> this). I need to understand which commands need which of the spawn, run,
>>>> and
>>>> term procedures and why.
>>> 
>>> Well, in general, anything which performs interaction on the terminal
>>> needs to use "term", anything else which runs indefinitely needs to
>>> use "spawn", and the rest (i.e. anything which isn't interactive and
>>> which doesn't run indefinitely) can use "run".
>> 
>> OK. I understand this distinction and can see what the differences are
>> between the execute, spawn, and run procedures.
>> 
>> But now I suppose I betray my ignorance. If I call a normal GRASS 5.7
>> command with no argument (i.e., it is parsed by G_gui() and autogenerates an
>> interactive tcltk dialog) through either the spawn or run procedures it
>> *appears* to work the same as if I called it via the execute procedure. Is
>> there a problem in doing this? Why can't I just use run, for example, to
>> call all GRASS programs except those that require an xterm?
> 
> Future expansion.
> 
> Essentially, I want to allow for the possibility of adding a feature
> to G_parser/G_gui such that, when the program is being run from
> tcltkgrass, rather than G_gui() generating Tcl/Tk code and feeding it
> directly to wish, it would write it to stdout, and tcltkgrass would
> read and execute the generated code.
> 
> This would allow tcltkgrass to implement features such as scripting,
> command history, etc, as tcltkgrass would get to see the user's
> argument values.
> 
> Implementing this would essentially boil down to:
> 
> 1. Adding an option to G_gui() to write the code to stdout rather than
> calling popen("$GRASS_WISH").
> 
> 2. Adding a global switch (e.g. --tcltk) to G_parser(), which makes
> use of 1.
> 
> 3. Copying the relevant portions of lib/gis/gui.tcl into tcltkgrass'
> gui.tcl, with any necessary modifications.
> 
> 4. Changing the execute procedure to e.g.:
> 
> proc execute {cmd} {
>    eval [exec -- $cmd --tcltk 2>@ stderr]
> }
> 
> So, execute would simply invoke the program to get the Tcl/Tk code for
> the dialog, then evaluate it. The actual execution of the program
> (with arguments) would occur when the user clicked the dialog's "Run"
> button.
> 
> In short, while execute currently looks very much like spawn,
> ultimately it could look very different.
> 
>>> The "runs indefinitely" is actually quite tricky. Primarily because
>>> running multiple GRASS programs concurrently is problematic. If you
>>> start a long-running program such as v.digit, it's debatable whether
>>> you should be allowed to run anything else until it finishes.
>>> 
>>> From the perspective of neatness, it would be better for the UI to
>>> remain functional, but to inhibit the execution of new commands
>>> (except those which are always safe, e.g. g.manual) than to simply
>>> "hang" until the command completes. However, implementing that would
>>> be non-trivial; you would need to start all commands in the
>>> background, then manually check for termination (and I have no idea
>>> how to do that in Tcl).
>>> 
>>> And the ideal, i.e. only allowing further commands to be run if they
>>> are "compatible" with outstanding commands is, I suspect, so complex
>>> as to be practically impossible.
>> 
>> Is the possibility of running incompatible commands really a potential
>> problem? If so, maybe there is a way around it and satisfying at least some
>> of the conditions you mention above. I've not yet run into this kind of
>> incompatibility probably because in actually working with GRASS, I often
>> 'run' several commands, but then leave them 'paused' at the opening dialog.
>> I then switch back and forth between commands so that I am actually running
>> only a single command at a time, rather than running them concurrently in
>> the full sense. I suspect that this is what most people do most of the time.
> 
> OK, that usage isn't an issue. It's only when the commands are
> actually "running" (i.e. modifying the mapset directory) that the
> issues arise.
> 
>> Under such circumstances, could pressing the 'run' button on the dialog box
>> also inhibit the execution of other commands except for 'safe' ones? If so,
>> this would work for most commands, I think, without compromising the
>> functionality of the UI. Notable exceptions would be d.m, d.mon, and nviz.
> 
> That would work; however:
> 
> 1. It would require that tcltkgrass was managing the dialogs, as
> described above.
> 
> 2. To actually implement mutual exclusion, you would need to either:
> 
> a) have the Run button execute the command in the foreground (without
> the trailing "&"), or
> 
> b) find some way of determining when a background command has
> completed.
> 
> The problem with 1 is that the UI will remain unresponsive (it won't
> even redraw itself) while the command runs, which is ugly.
> 
> The problem with 2 is that I don't know how to do this in Tcl. When
> the last argument to exec is "&", it returns the process identifier(s)
> for the command, but I don't see a Tcl version of waitpid().
> 
>>> AFAICT, if you supply one or more arguments on the command-line,
>>> G_gui() (or the old interactive() if GRASS_UI_TERM is set) is never
>>> called. So I can't see any point in allowing the "execute" procedure
>>> to accept arguments (it would be trivial to support, though).
>> 
>> Hmm. But it seems that commands without arguments can 'run' or 'spawn' like
>> commands that need arguments and still manage to go through G_gui(). Given
>> this, is there still a need for the 'execute' procedure?
>> 
>> If I call a GRASS command via the command line shell, it is somehow parsed
>> correctly--going to a G_gui() dialog or an interactive xterm if there are no
>> arguments, or performing its function if there are arguments. Is it a
>> limitation of tcltk that prevents this parser (i.e., that correctly routes
>> different kinds of calls from the command line) from operating in the same
>> way in this context? Sorry if I'm being dense, but this discussion has been
>> very helpful in better understanding how this operates.
> 
> See my comments regarding "execute" above.
> 
> I initially described the idea a couple of days ago in response to
> your comment about scripting not working:
> 
> : From: Glynn Clements <glynn.clements at virgin.net>
> : Subject: Re: [GRASS5] Need testers for tcltkgrass update for 5.7
> : Date: Mon, 16 Aug 2004 14:41:32 +0100
> : Message-ID: <16672.47500.961075.166905 at cerise.nosuchdomain.co.uk>
> : 
> : > The only thing that doesn't work is scripting. I'm not sure whether this
> is
> : > a function of GRASS 5.7 (and that I should take it out of the menu
> : > altogether) or it  is simply broken at the moment. If anyone has a clue,
> let
> : > me know.
> : 
> : The old tcltkgrass constructed and handled the dialogs itself, so it
> : got to see the actual command line. The new version simply runs the
> : command without arguments; the command generates the dialog, reads the
> : arguments, then re-executes itself, without tcltkgrass ever getting to
> : see the arguments.
> : 
> : To make tcltkgrass scripting work, G_gui() would need to e.g. write
> : the Tcl/Tk code to stdout so that it could be executed by tcltkgrass.
> : I.e. something like --html-description but which generates Tcl/Tk code
> : rather than HTML.
> 
> However, I didn't really make clear the connection between this and
> the "execute" procedure.
> 
> -- 
> Glynn Clements <glynn.clements at virgin.net>

______________________________
Michael Barton, Professor & Curator
School of Human Origins, Cultures, & Societies
Arizona State University
Tempe, AZ  85287-2402
USA

voice: 480-965-6262; fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton