[GRASS5] More Mac OS X Tcltkgrass Tweaks

[Jeshua_Lacock]

Greetings,

I got the online help now working in the native Mac OS X environment.

In "gui.tcl", I changed:
      set html(netscape) "netscape"
      ..
      set html(pre) "file:"
      ..
      set cmd [list exec $html(netscape) -remote openURL\($url,new-window,$html(raise)\)]
        (and all instances of $html(netscape) -remote openURL)

To:
      set html(netscape) "/usr/local/bin/launchURL"
      ..
      set html(pre) "file://"
       ..
      set cmd [list exec $html(netscape) $url]

launchURL is a very simple Mac OS X (carbon) program that I wrote that will open the passed URL to the system's preferred browser (which the user may set in their "Internet System Preference"). The preference of opening a new window or to use the current window is also a OS X preference. I can supply the source code (with a Makefile) and or binaries if anyone is interested.

I also wrote a simple program to bring Wish to the foreground. Often when the GUI was launched it was not visible as it was often hidden behind a XTerm or other window(s), so the program I wrote just brings it to the front (both for connivence and to avoid potential confusion). I then added a couple lines to execute the program in a couple key locations (in gis_set.tcl and in tcltkgrass).

I can supply patches and source code, however, these are Mac OS X specific changes. There are actually quite a few Mac OS X changes that need to be made to the Tcl/Tk for Grass to function in the native Mac OS X environment.

At this point, I propose that a new configure switch is added for enabling the native Mac OS X version of the Tcl/Tk interface (some folks on Mac OS X may want to use the traditional *nix version of the interface and those using Darwin without the Aqua interface). Then the set of Mac OS X patches could be applied at configure time and the auxiliary Mac OS X support programs could be built. I would be happy to do most of the work and be responsible for it's maintenance. Any thoughts/comments?

Also, I am trying to eliminate the Mac OS X "console1" bug. and the following line in gui.tcl is the culprit:

     set name "| $name 2>@ stdout"

If I try to reproduce the problem in a new wish file, everything works. Since I can't reproduce the problem outside of Grass, it seems to me that something in the Tcl scripts must be breaking stdout (which very well could be a wish bug). It is really odd because the problem only occurs when the GUI is launched from Init.sh and not when tcltkgrass is launched manually from the Grass terminal. Any ideas? I would be willing to pay for some help. I was preparing a post for the MacTcl mail list, but I stopped short of posting it when I was not able to reproduce the error in a blank wish shell.

Thanks,

Jeshua Lacock __________________________
Programmer/Owner Phone: 760.935.4736
http://OpenOSX.com Fax: 760.935.4845
-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_

[Glynn_Clements]

Jeshua Lacock wrote:

At this point, I propose that a new configure switch is added for
enabling the native Mac OS X version of the Tcl/Tk interface (some
folks on Mac OS X may want to use the traditional *nix version of the
interface and those using Darwin without the Aqua interface). Then the
set of Mac OS X patches could be applied at configure time and the
auxiliary Mac OS X support programs could be built. I would be happy to
do most of the work and be responsible for it's maintenance. Any
thoughts/comments?

I would rather this was determined at run time.

Most of the things that configure is used for are compile-time issues.
However, Tcl/Tk is interpreted, so there isn't a "compile time".

IOW, tcltkgrass should be doing something like:

  if $use_aqua {
        set html(netscape) "/usr/local/bin/launchURL"
    ...
  } {
        set html(netscape) "netscape"
    ...
  }

Actually, the choice of browser should be more general; it should be
possible to use something other than netscape on other platforms.

Also, I am trying to eliminate the Mac OS X "console1" bug. and the
following line in gui.tcl is the culprit:

     set name "| $name 2>@ stdout"

If I try to reproduce the problem in a new wish file, everything works.
Since I can't reproduce the problem outside of Grass, it seems to me
that something in the Tcl scripts must be breaking stdout (which very
well could be a wish bug). It is really odd because the problem only
occurs when the GUI is launched from Init.sh and not when tcltkgrass is
launched manually from the Grass terminal. Any ideas? I would be
willing to pay for some help. I was preparing a post for the MacTcl
mail list, but I stopped short of posting it when I was not able to
reproduce the error in a blank wish shell.

The fact that it only occurs when tcltkgrass is launched from Init.sh
suggests a Mac issue. Have you tried this with a test case? I.e.
running a simple Tcl/Tk script which uses "open | ... 2>@ stdout" from
a shell script. Does it matter whether the script is run in the
background?

--
Glynn Clements <glynn.clements@virgin.net>

[Markus_Neteler1]

On Sun, Apr 27, 2003 at 09:51:07PM +0100, Glynn Clements wrote:
[...]

IOW, tcltkgrass should be doing something like:

  if $use_aqua {
        set html(netscape) "/usr/local/bin/launchURL"
    ...
  } {
        set html(netscape) "netscape"
    ...
  }

Actually, the choice of browser should be more general; it should be
possible to use something other than netscape on other platforms.

GRASS 5.1 comes with $GRASS_HTML_BROWSER which is defined in etc/Init.sh
as a cascade of tests for various browsers. Maybe not brilliant, but
working for now. This could be merged into the 5.0 code easily.

Markus

[Jeshua_Lacock]

On Sunday, April 27, 2003, at 01:51 PM, Glynn Clements wrote:

Jeshua Lacock wrote:

At this point, I propose that a new configure switch is added for
enabling the native Mac OS X version of the Tcl/Tk interface (some
folks on Mac OS X may want to use the traditional *nix version of the
interface and those using Darwin without the Aqua interface). Then the
set of Mac OS X patches could be applied at configure time and the
auxiliary Mac OS X support programs could be built. I would be happy to
do most of the work and be responsible for it's maintenance. Any
thoughts/comments?

I would rather this was determined at run time.

Most of the things that configure is used for are compile-time issues.
However, Tcl/Tk is interpreted, so there isn't a "compile time".

Well there are some Carbon C programs that I have written, currently: "launchURL" and "wishToFront"; which do require compiling (and a couple shell scripts which do not need compiling). They could be pre-compiled, however that seems to defeat the purpose distributing source code. I guess the Mac OS X specific binaries could be built on any detected Darwin build, and the Tcltkgrass changes could be determined at runtime.

IOW, tcltkgrass should be doing something like:

  if $use_aqua {
        set html(netscape) "/usr/local/bin/launchURL"
    ...
  } {
        set html(netscape) "netscape"
    ...
  }

Cool, that seems better to me, however it seems it would impart a small performance penalty for all the platforms. But, I would be happy to do whatever you recommend and It would be ideal to switch between the UNIX and aqua versions at runtime.

Actually, the choice of browser should be more general; it should be
possible to use something other than netscape on other platforms.

Sure, like I stated that is the case with the Mac OS X solution.

Can't the user can change the netscape option via "Config->Options->Configure"?

Also, I am trying to eliminate the Mac OS X "console1" bug. and the
following line in gui.tcl is the culprit:

     set name "| $name 2>@ stdout"

If I try to reproduce the problem in a new wish file, everything works.
Since I can't reproduce the problem outside of Grass, it seems to me
that something in the Tcl scripts must be breaking stdout (which very
well could be a wish bug). It is really odd because the problem only
occurs when the GUI is launched from Init.sh and not when tcltkgrass is
launched manually from the Grass terminal. Any ideas? I would be
willing to pay for some help. I was preparing a post for the MacTcl
mail list, but I stopped short of posting it when I was not able to
reproduce the error in a blank wish shell.

The fact that it only occurs when tcltkgrass is launched from Init.sh
suggests a Mac issue. Have you tried this with a test case? I.e.
running a simple Tcl/Tk script which uses "open | ... 2>@ stdout" from
a shell script. Does it matter whether the script is run in the
background?

When I run the following wish script manually from a terminal window:

     #!/bin/wish
     puts stdout "fooMAR"

fooMAR appears in the terminal.

When I add the same line to gui.tcl, right where the "set name... >@ stdout" offending line:
     puts stdout "fooMAR"

fooMAR will not appear when launched from Init.sh and the console1 error appears, but does functions normally and without error when I launch the GUI manually from the Terminal.

I also tried:
     open | d.rast map=spot.comp < /dev/null 2>@ stdout r

And, it seems as if the syntax is not quite right. To be honest, I am not entirely sure what the syntax should look like. It seems the pipe should not be there. Does that look right?

Also, I am able to successfully run in a test file:
    open ~/.tcltkgrass r

But, if in the same test file I instead try;
     open ~/.tcltkgrass < /dev/null 2>@ stdout r

I get there error:
     Error in startup script: wrong # args: should be "open fileName ?access? ?permissions?"
         while executing
     "open ~/.tcltkgrass < /dev/null 2>@ stdout r"
         (file "wishTest.tcl" line 4)

Thanks,

Jeshua Lacock __________________________
Programmer/Owner Phone: 760.935.4736
http://OpenOSX.com Fax: 760.935.4845
-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_

[Glynn_Clements]

Jeshua Lacock wrote:

>> At this point, I propose that a new configure switch is added for
>> enabling the native Mac OS X version of the Tcl/Tk interface (some
>> folks on Mac OS X may want to use the traditional *nix version of the
>> interface and those using Darwin without the Aqua interface). Then the
>> set of Mac OS X patches could be applied at configure time and the
>> auxiliary Mac OS X support programs could be built. I would be happy
>> to
>> do most of the work and be responsible for it's maintenance. Any
>> thoughts/comments?
>
> I would rather this was determined at run time.
>
> Most of the things that configure is used for are compile-time issues.
> However, Tcl/Tk is interpreted, so there isn't a "compile time".

Well there are some Carbon C programs that I have written, currently:
"launchURL" and "wishToFront"; which do require compiling (and a couple
shell scripts which do not need compiling). They could be pre-compiled,
however that seems to defeat the purpose distributing source code. I
guess the Mac OS X specific binaries could be built on any detected
Darwin build, and the Tcltkgrass changes could be determined at runtime.

OK; I didn't realise that you were suggesting including those
utilities with GRASS. If we were to do that, then it would be
configure's job to enable their compilation.

> Actually, the choice of browser should be more general; it should be
> possible to use something other than netscape on other platforms.

Sure, like I stated that is the case with the Mac OS X solution.

Can't the user can change the netscape option via
"Config->Options->Configure"?

Right; although I'm not sure that it will actually work with anything
other than netscape:

  set cmd [list exec $html(netscape) -remote openURL\($url,new-window,$html(raise)\)]

This will only work with programs which support the command-line
syntax which is used; which is probably just netscape.

A more portable approach would be to just have the entire command as a
single parameter.

Also, I suspect that making the URL prefix configurable is
unnecessary; AFAICT, it should always be "file://".

>> Also, I am trying to eliminate the Mac OS X "console1" bug. and the
>> following line in gui.tcl is the culprit:
>>
>> set name "| $name 2>@ stdout"
>>
>> If I try to reproduce the problem in a new wish file, everything
>> works.
>> Since I can't reproduce the problem outside of Grass, it seems to me
>> that something in the Tcl scripts must be breaking stdout (which very
>> well could be a wish bug). It is really odd because the problem only
>> occurs when the GUI is launched from Init.sh and not when tcltkgrass
>> is
>> launched manually from the Grass terminal. Any ideas? I would be
>> willing to pay for some help. I was preparing a post for the MacTcl
>> mail list, but I stopped short of posting it when I was not able to
>> reproduce the error in a blank wish shell.
>
> The fact that it only occurs when tcltkgrass is launched from Init.sh
> suggests a Mac issue. Have you tried this with a test case? I.e.
> running a simple Tcl/Tk script which uses "open | ... 2>@ stdout" from
> a shell script. Does it matter whether the script is run in the
> background?

When I run the following wish script manually from a terminal window:

     #!/bin/wish
     puts stdout "fooMAR"

fooMAR appears in the terminal.

What if you run it from a shell script? I.e.:

  #!/bin/sh
  /path/to/foomar.tcl

What if it's run in the background? I.e.

  #!/bin/sh
  /path/to/foomar.tcl &

This should mimic the way that tcltkgrass is run from Init.sh.

When I add the same line to gui.tcl, right where the "set name... >@
stdout" offending line:
     puts stdout "fooMAR"

fooMAR will not appear when launched from Init.sh and the console1
error appears, but does functions normally and without error when I
launch the GUI manually from the Terminal.

I also tried:
     open | d.rast map=spot.comp < /dev/null 2>@ stdout r

And, it seems as if the syntax is not quite right. To be honest, I am
not entirely sure what the syntax should look like. It seems the pipe
should not be there. Does that look right?

The entire command (starting with the pipe character) should be a
single argument to open, i.e.

  open {|d.rast map=spot.comp < /dev/null 2>@ stdout} r

Also, I am able to successfully run in a test file:
    open ~/.tcltkgrass r

But, if in the same test file I instead try;
     open ~/.tcltkgrass < /dev/null 2>@ stdout r

I get there error:
     Error in startup script: wrong # args: should be "open fileName
?access? ?permissions?"

Same problem; the "r" should be the second argument, and everything
else should be the first argument.

--
Glynn Clements <glynn.clements@virgin.net>

[Jeshua_Lacock]

On Monday, April 28, 2003, at 01:14 AM, Glynn Clements wrote:

Jeshua Lacock wrote:

At this point, I propose that a new configure switch is added for
enabling the native Mac OS X version of the Tcl/Tk interface (some
folks on Mac OS X may want to use the traditional *nix version of the
interface and those using Darwin without the Aqua interface). Then the
set of Mac OS X patches could be applied at configure time and the
auxiliary Mac OS X support programs could be built. I would be happy
to
do most of the work and be responsible for it's maintenance. Any
thoughts/comments?

I would rather this was determined at run time.

Most of the things that configure is used for are compile-time issues.
However, Tcl/Tk is interpreted, so there isn't a "compile time".

Well there are some Carbon C programs that I have written, currently:
"launchURL" and "wishToFront"; which do require compiling (and a couple
shell scripts which do not need compiling). They could be pre-compiled,
however that seems to defeat the purpose distributing source code. I
guess the Mac OS X specific binaries could be built on any detected
Darwin build, and the Tcltkgrass changes could be determined at runtime.

OK; I didn't realise that you were suggesting including those
utilities with GRASS. If we were to do that, then it would be
configure's job to enable their compilation.

Yes, absolutely, so what do you think I should do next?

Actually, the choice of browser should be more general; it should be
possible to use something other than netscape on other platforms.

Sure, like I stated that is the case with the Mac OS X solution.

Can't the user can change the netscape option via
"Config->Options->Configure"?

Right; although I'm not sure that it will actually work with anything
other than netscape:

  set cmd [list exec $html(netscape) -remote openURL\($url,new-window,$html(raise)\)]

This will only work with programs which support the command-line
syntax which is used; which is probably just netscape.

Ahh - gotcha.

A more portable approach would be to just have the entire command as a
single parameter.

Sure that makes sense, and that would be fine with launchURL.

Also, I suspect that making the URL prefix configurable is
unnecessary; AFAICT, it should always be "file://".

Also, I am trying to eliminate the Mac OS X "console1" bug. and the
following line in gui.tcl is the culprit:

When I run the following wish script manually from a terminal window:

     #!/bin/wish
     puts stdout "fooMAR"

fooMAR appears in the terminal.

What if you run it from a shell script? I.e.:

  #!/bin/sh
  /path/to/foomar.tcl
What if it's run in the background? I.e.

  #!/bin/sh
  /path/to/foomar.tcl &

This should mimic the way that tcltkgrass is run from Init.sh.

THANKS Glynn - YOU ROCK (as usual)!

The cause is from running it in the background in from a shell script. I removed the ampersand and everything is beautiful!

I will post a message on the Mac Wish list, now that I know what was causing the problem. As a temporary work around, I guess I can disable tcltkgrass from launching automatically and the user will just be required to start the GUI by pasting in 'tcltkgrass &'.

Thanks again,

Jeshua Lacock __________________________
Programmer/Owner Phone: 760.935.4736
http://OpenOSX.com Fax: 760.935.4845
-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_

[Jeshua_Lacock]

On Monday, April 28, 2003, at 02:40 AM, Jeshua Lacock wrote:

As a temporary work around, I guess I can disable tcltkgrass from launching automatically and the user will just be required to start the GUI by pasting in 'tcltkgrass &'.

Greetings,

I figured out a better work-around.

In Init.sh I changed:
     tcltk)
         tcltkgrass &

To:
     tcltk)
         echo "tcltkgrass" | sh &

And everything works just great (go figure)!

Thanks again,

Jeshua Lacock __________________________
Programmer/Owner Phone: 760.935.4736
http://OpenOSX.com Fax: 760.935.4845
-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_

[Glynn_Clements]

Jeshua Lacock wrote:

> As a temporary work around, I guess I can disable tcltkgrass from
> launching automatically and the user will just be required to start
> the GUI by pasting in 'tcltkgrass &'.

Greetings,

I figured out a better work-around.

In Init.sh I changed:
     tcltk)
         tcltkgrass &

To:
     tcltk)
         echo "tcltkgrass" | sh &

And everything works just great (go figure)!

However, I don't think that we should be modifying Init.sh to work
around problems with the MacOSX Tcl/Tk implementation.

Also, I'm not sure that the above really fixes the problem. AFAICT,
the whole point of the "2> @stdout" is so that stderr goes to the same
place as stdout, i.e. into the stream which is returned from the open
command, and *not* wish's stdout/stderr. But the nature of the problem
suggests that wish's stdout/stderr is getting involved.

If a command generates an error, do you get the error message in the
output window, or in the xterm? It should be the former.

--
Glynn Clements <glynn.clements@virgin.net>

[Jeshua_Lacock]

On Tuesday, April 29, 2003, at 02:56 AM, Glynn Clements wrote:

However, I don't think that we should be modifying Init.sh to work
around problems with the MacOSX Tcl/Tk implementation.

Hi Glynn,

Sure; as I stated it is just a work around, I guess I should have added "until the real issue is resolved".

Also, I'm not sure that the above really fixes the problem. AFAICT,
the whole point of the "2> @stdout" is so that stderr goes to the same
place as stdout, i.e. into the stream which is returned from the open
command, and *not* wish's stdout/stderr. But the nature of the problem
suggests that wish's stdout/stderr is getting involved.

If a command generates an error, do you get the error message in the
output window, or in the xterm? It should be the former.

Hmm, I am not sure if I completely understand, however, if I run the 'd.rast' GUI, provide a bogus file name, click run, I get a tcltk dialog titled 'd.rast output' that says:

                          d.rast output
                             Finished.
   ERROR: Raster map [fooMAR] not available

   Quit Save Clear

So, it seems to be capturing the errors as it should, and otherwise function normally, AFAICT.

Also if I choose Region->Display Region Settings, the settings properly appear in a new xterm.

Can you provide me an example of a specific program to try and what to expect in the shell?

Thanks,

Jeshua Lacock __________________________
Programmer/Owner Phone: 760.935.4736
http://OpenOSX.com Fax: 760.935.4845
-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_

[Glynn_Clements]

Jeshua Lacock wrote:

> Also, I'm not sure that the above really fixes the problem. AFAICT,
> the whole point of the "2> @stdout" is so that stderr goes to the same
> place as stdout, i.e. into the stream which is returned from the open
> command, and *not* wish's stdout/stderr. But the nature of the problem
> suggests that wish's stdout/stderr is getting involved.
>
> If a command generates an error, do you get the error message in the
> output window, or in the xterm? It should be the former.

Hmm, I am not sure if I completely understand, however, if I run the
'd.rast' GUI, provide a bogus file name, click run, I get a tcltk
dialog titled 'd.rast output' that says:

                          d.rast output
                             Finished.
   ERROR: Raster map [fooMAR] not available

   Quit Save Clear

So, it seems to be capturing the errors as it should, and otherwise
function normally, AFAICT.

That seems OK; so my guess was wrong.

In which case, it seems to be a plain Tcl/Tk bug (rather than an
incompatibility); wish's stderr/stdout shouldn't come into it.

Regardless of whether your test case (puts stdout ...) complains, the
gui.tcl case (open "|... 2>@ stdout" "r") shouldn't. These are two
completely different situations. Your test is writing to wish's
stdout, but gui.tcl is writing to a pipe which is created by the open
function.

The error in the test case could be legitimate. When a background
process writes to a terminal, the write may simply occur, or the
writing process may receive SIGTTOU (by default, this suspends the
process, but it can be caught). The actual behaviour is controlled by
the terminal driver, and can be set using "stty tostop" (writing
process receives SIGTTOU) or "stty -tostop" (write occurs with no
signal).

However, this isn't (or, rather, shouldn't be) relevant to the
behaviour of open with regard to pipes. The "2>@ stdout" should
duplicate the pipe which is used for the subprocess' stdout to the
subprocess' stderr; no terminals should be involved.

There is another possibility, though; something about that open
command might be causing wish itself to write to its stdout/stderr
(e.g. an error message); that would be expected to have the same
result as a simple "puts stdout ...".

Try changing your test script to e.g.

  #!/bin/wish
  set f [open "|ls -l 2>@ stdout" "r"]
  while {![eof $f]} {gets $f line}
  close $f
  exit

Also, try changing your terminal settings, with "stty -tostop".

Yet another thing to try is to wrap the open statement within a catch.

--
Glynn Clements <glynn.clements@virgin.net>