[GRASS5] pre2 nviz & darwin -- part ii

hi helena:

nviz -q (with or without tcltkgrass running) very briefly flashes the "wait_ok" and nviz boxes, then gives the '"wait_ok" already exists in parent' error in the xterm. the nviz i/o box doesn't appear.

using the tcltkgrass menu for nviz pops up three windows (wait_ok, nviz i/o, and nviz), nviz i/o says: 'loading data,' 'update elev null mask,' 'loading data,' 'translating colors,' then ends with 'sorry, <el=> is ambiguous' (this "el=" is passed from the command line box in the nviz dialog and i can't edit it).

take care,
andy

p.s. please cc me as well, as i'm a digest lister. thanks.

it gives him the same error even if he just calls nviz -q, so it is not in
the name,
if I understand it correctly. Andy, does it open any of the windows when you
start nviz -q
(the graphics window, "please wait" window and then the tcltk interface)?

Helena

andy agena wrote:

hi helena:

nviz -q (with or without tcltkgrass running) very briefly flashes the
"wait_ok" and nviz boxes, then gives the '"wait_ok" already exists in
parent' error in the xterm. the nviz i/o box doesn't appear.

using the tcltkgrass menu for nviz pops up three windows (wait_ok, nviz
i/o, and nviz), nviz i/o says: 'loading data,' 'update elev null
mask,' 'loading data,' 'translating colors,' then ends with 'sorry,
<el=> is ambiguous' (this "el=" is passed from the command line box in
the nviz dialog and i can't edit it).

take care,
andy

p.s. please cc me as well, as i'm a digest lister. thanks.

Andy,

This sounds like a very unusual error. If I understand correctly, you
cannot start nviz with the command "nviz -q". You get the "already
exists ..." error you mention above. That error sounds like TCL cannot
address the window ID correctly. Are you running the session remotely
(telnet, etc)? Also, you may want to check and see if there are any
stale nviz's running. You can check this with something like "ps -aef |
grep NVWISH2.2".

If you have access to the program files you can edit the nviz tcltkgrass
startup module to change the "el=" option you mention above. The file to
edit is in $GISBASE/tcltkgrass/module and is entitled nviz. Simply
change the option "el" to any other legal value (anything from "e" to
"elevation"). You could also try these variations on the command line to
see what is going on.

Hope this helps.

--
Bob Covill

Tekmap Consulting

E-Mail: bcovill@tekmap.ns.ca

On Friday, October 26, 2001, at 02:53 PM, andy agena wrote:

nviz -q (with or without tcltkgrass running) very briefly flashes the "wait_ok" and nviz boxes, then gives the '"wait_ok" already exists in parent' error in the xterm. the nviz i/o box doesn't appear.

using the tcltkgrass menu for nviz pops up three windows (wait_ok, nviz i/o, and nviz), nviz i/o says: 'loading data,' 'update elev null mask,' 'loading data,' 'translating colors,' then ends with 'sorry, <el=> is ambiguous' (this "el=" is passed from the command line box in the nviz dialog and i can't edit it).

Hi guys,

I now get the same thing. Which is weird, because it was working here before I switched to my new dual-processor machine and installed Grass from my CD.

Here are the errors that I get after running nviz -q

[...snip...]
ERROR: window name "wait_ok" already exists in parent
child process exited abnormally
     while executing
"exec /usr/local/grass5/etc/nviz2.2/NVWISH2.2 -f /usr/local/grass5/etc/nviz2.2/scripts/nviz2.2_script -q -name NVIZ >&@stdout"
     ("eval" body line 1)
     invoked from within
"eval exec $env(GISBASE)/etc/nviz2.2/NVWISH2.2 -f $env(GISBASE)/etc/nviz2.2/scripts/nviz2.2_script $argv -name NVIZ >&@stdout"
     invoked from within
"if {$argv == ""} {
#no arguments
eval exec $env(GISBASE)/etc/nviz2.2/NVWISH2.2 -f $env(GISBASE)/etc/nviz2.2/scripts/nviz2.2_script -name NVIZ >&@stdo..."
     (file "/usr/local/grass5/bin/nviz" line 13)

Tcltkgrass operates normally.

Any ideas?

Thanks,

Jeshua Lacock http://OpenOSX.com
Programmer/Owner http://SierraMaps.com
Phone: (760) 935-4736 http://3dTopoMaps.com

hi bob:

On Friday, October 26, 2001, at 07:27 PM, Bob Covill wrote:

andy agena wrote:

hi helena:

nviz -q (with or without tcltkgrass running) very briefly flashes the
"wait_ok" and nviz boxes, then gives the '"wait_ok" already exists in
parent' error in the xterm. the nviz i/o box doesn't appear.

using the tcltkgrass menu for nviz pops up three windows (wait_ok, nviz
i/o, and nviz), nviz i/o says: 'loading data,' 'update elev null
mask,' 'loading data,' 'translating colors,' then ends with 'sorry,
<el=> is ambiguous' (this "el=" is passed from the command line box in
the nviz dialog and i can't edit it).

take care,
andy

p.s. please cc me as well, as i'm a digest lister. thanks.

Andy,

This sounds like a very unusual error. If I understand correctly, you
cannot start nviz with the command "nviz -q". You get the "already
exists ..." error you mention above. That error sounds like TCL cannot
address the window ID correctly.
Are you running the session remotely
(telnet, etc)? Also, you may want to check and see if there are any
stale nviz's running. You can check this with something like "ps -aef |
grep NVWISH2.2".

If you have access to the program files you can edit the nviz tcltkgrass
startup module to change the "el=" option you mention above. The file to
edit is in $GISBASE/tcltkgrass/module and is entitled nviz. Simply
change the option "el" to any other legal value (anything from "e" to
"elevation"). You could also try these variations on the command line to
see what is going on.

Hope this helps.

--
Bob Covill

Tekmap Consulting

E-Mail: bcovill@tekmap.ns.ca

hi bob:

On Friday, October 26, 2001, at 07:27 PM, Bob Covill wrote:

<snip>

Andy,

This sounds like a very unusual error. If I understand correctly, you
cannot start nviz with the command "nviz -q". You get the "already
exists ..." error you mention above. That error sounds like TCL cannot
address the window ID correctly. Are you running the session remotely
(telnet, etc)? Also, you may want to check and see if there are any
stale nviz's running. You can check this with something like "ps -aef |
grep NVWISH2.2".

i'm running it locally.

there's something weird happening with xwindows. when i 'grass5', there's some message that flashes briefly after choosing the location ('xterm...'). do you get this as well jeshua? (though your machine is probably too fast to see it). of course, i can't find where this message is logged, and it doesn't show up in the console (there is a message: "Warning: no access to tty (Inappropriate ioctl for device)." in the console).

Mapset <PERMANENT> in Location <spearfish>
GRASS 5.0.0pre2 > ps aux | grep nviz
andy 599 3.0 0.1 1112 196 std R+ 0:00.01 grep nviz

If you have access to the program files you can edit the nviz tcltkgrass
startup module to change the "el=" option you mention above. The file to
edit is in $GISBASE/tcltkgrass/module and is entitled nviz. Simply
change the option "el" to any other legal value (anything from "e" to
"elevation"). You could also try these variations on the command line to
see what is going on.

the contents of $GISBASE/tcltkgrass/module/nviz:

interface_build {
     {nviz} 1
     {Visualization tool.}
     {entry el {Name of existing raster map:} 0 raster}
     {entry ve {Name of existing vector map:} 0 vector
     {entry si {Name of existing sites map:} 0 sites}
}

which i changed to elevation, vector, and sites, respectively. same error.

any idea on where the weird 'xterm...' error might be logged?

take care,
andy

hi bob:

On Friday, October 26, 2001, at 07:27 PM, Bob Covill wrote:

<snip>

Andy,

This sounds like a very unusual error. If I understand correctly, you
cannot start nviz with the command "nviz -q". You get the "already
exists ..." error you mention above. That error sounds like TCL cannot
address the window ID correctly. Are you running the session remotely
(telnet, etc)? Also, you may want to check and see if there are any
stale nviz's running. You can check this with something like "ps -aef |
grep NVWISH2.2".

i'm running it locally.

there's something weird happening with xwindows. when i 'grass5', there's some message that flashes briefly after choosing the location ('xterm...'). do you get this as well jeshua? (though your machine is probably too fast to see it). of course, i can't find where this message is logged, and it doesn't show up in the console (there is a message: "Warning: no access to tty (Inappropriate ioctl for device)." in the console).

Mapset <PERMANENT> in Location <spearfish>
GRASS 5.0.0pre2 > ps aux | grep nviz
andy 599 3.0 0.1 1112 196 std R+ 0:00.01 grep nviz

If you have access to the program files you can edit the nviz tcltkgrass
startup module to change the "el=" option you mention above. The file to
edit is in $GISBASE/tcltkgrass/module and is entitled nviz. Simply
change the option "el" to any other legal value (anything from "e" to
"elevation"). You could also try these variations on the command line to
see what is going on.

the contents of $GISBASE/tcltkgrass/module/nviz:

interface_build {
     {nviz} 1
     {Visualization tool.}
     {entry el {Name of existing raster map:} 0 raster}
     {entry ve {Name of existing vector map:} 0 vector
     {entry si {Name of existing sites map:} 0 sites}
}

which i changed to elevation, vector, and sites, respectively. same error.

any idea on where the weird 'xterm...' error might be logged?

take care,
andy

andy agena wrote:

nviz -q (with or without tcltkgrass running) very briefly flashes the
"wait_ok" and nviz boxes, then gives the '"wait_ok" already exists in
parent' error in the xterm. the nviz i/o box doesn't appear.

using the tcltkgrass menu for nviz pops up three windows (wait_ok, nviz
i/o, and nviz), nviz i/o says: 'loading data,' 'update elev null
mask,' 'loading data,' 'translating colors,' then ends with 'sorry,
<el=> is ambiguous' (this "el=" is passed from the command line box in
the nviz dialog and i can't edit it).

I've found something which looks relevant.

In NVIZ_AppInit (nvizAppInit.c), Ninit() may be called twice. First:

    if (Tk_Init(interp) == TCL_ERROR) {
  /* Handle TCL/TK errors by passing to the G_parser
  ** Calls Ninit to spit out NVIZ usage message
  ** instead of TCL usage message
  */
    Ninit(interp, mainWindow);
  /*
  return TCL_ERROR;
  */
    }

then later:

    Ninit(interp, mainWindow);
  
    return TCL_OK;
  }

Ninit() calls Ninitdata(), which calls parse_command(), which:

1. Creates all of the options with G_define_option() then calls
G_parser(), hence the "ambigous" error (the second run will define all
of the options again, so the "el=..." argument will match both of the
"elevation" options).

2. Creates the .wait_ok window with:

      if (Tcl_Eval(interp, startup_script) != TCL_OK) {

where startup_script is:

  char startup_script =
  "toplevel .wait_ok\n\
  label .wait_ok.wait -text \"Please wait...\" -fg red -bg black\n\
  pack .wait_ok.wait -ipadx 20 -ipady 20 -expand 1 -fill both\n\
  wm geometry .wait_ok \"+800+50\"\n\
  wm geometry . \"+100+100\"\n\
  update\n\
  grab .wait_ok.wait";

In short, the symptoms which you describe are exactly what I would
expect to happen if Ninit() was called twice.

Try changing the first block of code above to e.g.:

    if (Tk_Init(interp) == TCL_ERROR) {
    fprintf(stderr, "Tk_Init failed\n");
    return TCL_ERROR;
    }

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

Jeshua Lacock wrote:

> nviz -q (with or without tcltkgrass running) very briefly flashes the
> "wait_ok" and nviz boxes, then gives the '"wait_ok" already exists in
> parent' error in the xterm. the nviz i/o box doesn't appear.
>
> using the tcltkgrass menu for nviz pops up three windows (wait_ok, nviz
> i/o, and nviz), nviz i/o says: 'loading data,' 'update elev null
> mask,' 'loading data,' 'translating colors,' then ends with 'sorry,
> <el=> is ambiguous' (this "el=" is passed from the command line box in
> the nviz dialog and i can't edit it).

I now get the same thing. Which is weird, because it was working here
before I switched to my new dual-processor machine and installed Grass
from my CD.

Revert src.contrib/GMSL/NVIZ2.2/src/nvizAppInit.c to version 1.1, i.e.

  cvs update -r 1.1 src.contrib/GMSL/NVIZ2.2/src/nvizAppInit.c

This won't fix the problem, but hopefully it will provide an
indication of why Tk_Init() failed.

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

On Saturday, October 27, 2001, at 10:00 AM, Glynn Clements wrote:

In short, the symptoms which you describe are exactly what I would
expect to happen if Ninit() was called twice.

Try changing the first block of code above to e.g.:

    if (Tk_Init(interp) == TCL_ERROR) {
    fprintf(stderr, "Tk_Init failed\n");
    return TCL_ERROR;
    }

Hi Glynn,

Thanks, I changed the code as you have kindly provided.

I then deleted the OBJ directory (in the nviz directory). Next I ran gmake5, gmakelinks5. I then deleted the nviz binary, followed by a make install in the /usr/src/grass directory.

But no matter what the nviz binary is dated oct 12 - the day I built the Pre2 binaries.

Do I have do do a make clean and reconfigure again? I would like to avoid recompiling the entire build again if it can be helped.

Thanks,

Jeshua Lacock http://OpenOSX.com
Programmer/Owner http://SierraMaps.com
Phone: (760) 935-4736 http://3dTopoMaps.com

Jeshua Lacock wrote:

On Saturday, October 27, 2001, at 10:00 AM, Glynn Clements wrote:

> In short, the symptoms which you describe are exactly what I would
> expect to happen if Ninit() was called twice.
>
> Try changing the first block of code above to e.g.:
>
> if (Tk_Init(interp) == TCL_ERROR) {
> fprintf(stderr, "Tk_Init failed\n");
> return TCL_ERROR;
> }

Hi Glynn,

Thanks, I changed the code as you have kindly provided.

I then deleted the OBJ directory (in the nviz directory). Next I ran
gmake5, gmakelinks5. I then deleted the nviz binary, followed by a make
install in the /usr/src/grass directory.

But no matter what the nviz binary is dated oct 12 - the day I built the
Pre2 binaries.

Do I have do do a make clean and reconfigure again? I would like to
avoid recompiling the entire build again if it can be helped.

Thanks,

Jeshua Lacock http://OpenOSX.com
Programmer/Owner http://SierraMaps.com
Phone: (760) 935-4736 http://3dTopoMaps.com

Jeshua,

You should probably run gmake5 -i (for install). The location to check
for the actual custom nviz wish binary is $GISBASE/etc/nivz2.2/. The
binary is entitled NVWISH2.2. The nviz program (nviz) found in
$GISBASE/bin is simply a script which invakes the NVWISH2.2 program.

Hope this helps.

--
Bob Covill

Tekmap Consulting
P.O. Box 2016 Fall River, N.S.
B2T 1K6
Canada

E-Mail: bcovill@tekmap.ns.ca
Phone: 902-860-1496
Fax: 902-860-1498

On Sunday, October 28, 2001, at 04:55 AM, Bob Covill wrote:

You should probably run gmake5 -i (for install). The location to check
for the actual custom nviz wish binary is $GISBASE/etc/nivz2.2/. The
binary is entitled NVWISH2.2. The nviz program (nviz) found in
$GISBASE/bin is simply a script which invakes the NVWISH2.2 program.

Thanks Bob,

That did the trick.

I then ran 'nviz -q'

and got the error:
_________________

Tk_Init failed
Application initialization failed: Can't find a usable tk.tcl in the following directories:
     /System/Library/Tcl/tk8.3 /usr/local/grass5/etc/lib/tk8.3 /usr/local/grass5/lib/tk8.3 /usr/local/grass5/etc/library /usr/local/grass5/library /usr/local/grass5/tk8.3/library /usr/local/tk8.3/library

This probably means that tk wasn't installed properly.

Error in startup script: can't read "src_boot": no such variable
_________________

So I made a symbolic link from /usr/local/lib/tk8.3 to /usr/local/grass5/etc/lib/tk8.3.

And NVIZ works again! Hooray! : )

Andy - perhaps all you need to do is create the symbolic link as:

   mkdir /usr/local/grass5/etc/lib
   ln -s /usr/local/lib/tk8.3 /usr/local/grass5/etc/lib/tk8.3

Please let us know.

Thanks again,

Jeshua Lacock http://OpenOSX.com
Programmer/Owner http://SierraMaps.com
Phone: (760) 935-4736 http://3dTopoMaps.com

Jeshua Lacock wrote:

Tk_Init failed
Application initialization failed: Can't find a usable tk.tcl in the
following directories:
     /System/Library/Tcl/tk8.3 /usr/local/grass5/etc/lib/tk8.3
/usr/local/grass5/lib/tk8.3 /usr/local/grass5/etc/library
/usr/local/grass5/library /usr/local/grass5/tk8.3/library
/usr/local/tk8.3/library

This probably means that tk wasn't installed properly.

Odd. "tcltkgrass" works, right? How about "wish"? If these work, that
suggests a problem with NVWISH2.2, which should be looked at.

Do you have any idea where NVWISH2.2 is getting that list of
directories from?

Also, I've reverted nvizAppInit.c; failure of Tk_Init() suggests a Tcl
error, so we want Tcl's error message.

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

On Sunday, October 28, 2001, at 02:47 PM, Glynn Clements wrote:

Tk_Init failed
Application initialization failed: Can't find a usable tk.tcl in the
following directories:
     /System/Library/Tcl/tk8.3 /usr/local/grass5/etc/lib/tk8.3
/usr/local/grass5/lib/tk8.3 /usr/local/grass5/etc/library
/usr/local/grass5/library /usr/local/grass5/tk8.3/library
/usr/local/tk8.3/library

This probably means that tk wasn't installed properly.

Odd. "tcltkgrass" works, right? How about "wish"? If these work, that
suggests a problem with NVWISH2.2, which should be looked at.

Hello Glynn,

Yes - Absolutely they both work with flying colors.

Do you have any idea where NVWISH2.2 is getting that list of
directories from?

Hmm - actually I don't. It is not from the path environment variable, though. I grepped the nviz2.2 and the nviz2.2/scripts directory for '/System/Library', with no matches.

Also, I've reverted nvizAppInit.c; failure of Tk_Init() suggests a Tcl
error, so we want Tcl's error message.

I think you lost me here. Should I revert the code back to before I edited it?

Yours,

Jeshua Lacock http://OpenOSX.com
Programmer/Owner http://SierraMaps.com
Phone: (760) 935-4736 http://3dTopoMaps.com

it worked for me as well, passing nviz elevation=elevation.dem.

And NVIZ works again! Hooray! : )

Andy - perhaps all you need to do is create the symbolic link as:

  mkdir /usr/local/grass5/etc/lib
  ln -s /usr/local/lib/tk8.3 /usr/local/grass5/etc/lib/tk8.3

Please let us know.

Jeshua Lacock wrote:

> Odd. "tcltkgrass" works, right? How about "wish"? If these work, that
> suggests a problem with NVWISH2.2, which should be looked at.

Yes - Absolutely they both work with flying colors.

That seems to suggest that Tcl/Tk itself is installed correctly.

Having looked at the NVWISH2.2 startup, I can't see any obvious reason
why it would fail when "wish" works. Although, calling Tk_MainWindow()
before Tk_Init() doesn't look right.

> Do you have any idea where NVWISH2.2 is getting that list of
> directories from?

Hmm - actually I don't. It is not from the path environment variable,
though. I grepped the nviz2.2 and the nviz2.2/scripts directory for
'/System/Library', with no matches.

That might be built into libtk.

As for the rest of the directories, I'm wondering if they're
constructed from the executable's pathname. That would explain why
it's looking in $GISBASE/etc.

Apart from /System/Library, the directories searched are:

/usr/local/grass5/etc/lib/tk8.3 = /usr/local/grass5/etc/nviz2.2/../lib/tk8.3
/usr/local/grass5/lib/tk8.3 = /usr/local/grass5/etc/nviz2.2/../../lib/tk8.3
/usr/local/grass5/etc/library = /usr/local/grass5/etc/nviz2.2/../library
/usr/local/grass5/library = /usr/local/grass5/etc/nviz2.2/../../library
/usr/local/grass5/tk8.3/library = /usr/local/grass5/etc/nviz2.2/../../tk8.3/library
/usr/local/tk8.3/library = /usr/local/grass5/etc/nviz2.2/../../../tk8.3/library

That could also explain why "wish" works; if "wish" is in
/usr/local/bin, the corresponding list of directories would be:

/usr/local/lib/tk8.3 = /usr/local/bin/../lib/tk8.3
/usr/lib/tk8.3 = /usr/local/bin/../../lib/tk8.3
/usr/local/library = /usr/local/bin/../library
/usr/library = /usr/local/bin/../../library
/usr/tk8.3/library = /usr/local/bin/../../tk8.3/library
/tk8.3/library = /usr/local/bin/../../../tk8.3/library

What happens if you copy NVWISH2.2 to some other directory, then run
it from there?

> Also, I've reverted nvizAppInit.c; failure of Tk_Init() suggests a Tcl
> error, so we want Tcl's error message.

I think you lost me here. Should I revert the code back to before I
edited it?

I was saying that the change which I suggested has been committed to
CVS.

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

On Sunday, October 28, 2001, at 05:37 PM, Glynn Clements wrote:

What happens if you copy NVWISH2.2 to some other directory, then run
it from there?

Hi Glynn,

After I moved NVWISH to it's parent directory, fired up Grass, and I typed nviz. It reported that NVWISH2.2 could not be found.

So changed to the directory where I moved it (etc/), ran NVWISH2.2 and I was prompted for a elevation file so I typed in topo (leics). I then choose defaults for the rest of the prompts and a NVWISH2.2 window appears and the command line freezes at "translating colors 99%".

If there is anything else you would like for me to try, please let me know.

Yours,

Jeshua Lacock http://OpenOSX.com
Programmer/Owner http://SierraMaps.com
Phone: (760) 935-4736 http://3dTopoMaps.com

Jeshua Lacock wrote:

> What happens if you copy NVWISH2.2 to some other directory, then run
> it from there?

Hi Glynn,

After I moved NVWISH to it's parent directory, fired up Grass, and I
typed nviz. It reported that NVWISH2.2 could not be found.

So changed to the directory where I moved it (etc/), ran NVWISH2.2 and I
was prompted for a elevation file so I typed in topo (leics). I then
choose defaults for the rest of the prompts and a NVWISH2.2 window
appears and the command line freezes at "translating colors 99%".

If there is anything else you would like for me to try, please let me
know.

What I meant was to move NVWISH2.2 to some completely unrelated
directory, then run NVWISH2.2 directly (rather than the "nviz"
script).

I'm trying to check whether the suspicion which I outlined in the the
previous message is correct, i.e. that Tk is using the executable's
pathname to guess the location of its library directory (for tk.tcl
etc).

E.g. run:

  mkdir $HOME/foo/bar/baz
  cp /usr/local/grass5/etc/nviz2.2/NVWISH2.2 $HOME/foo/bar/baz
  $HOME/foo/bar/baz/NVWISH2.2

and see which directories are listed in the resulting error message.

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