Re: Tcl/Tk 8.3 upgrade...

[Keith Seitz <keiths at cygnus dot com>]

On Tue, 12 Jun 2001, Ian Roxborough wrote:

> so I've been making progress on the Tcl/Tk upgrade, gdb/gdbtk
> was relatively plainless (ok, but who do I talk to about
> expect...).

Bwaaa haaa haaa. Good question... Don Libes?

> So there is only one more gdbtk testsuit failure with tcl/tk 8.3
> than with the current tcl/tk version:
>
>    gdb.gdbtk/srcwin.exp: variable balloon test (srcwin-5.1)

Does it produce a tcl error or just report some dorky number? You may have
to manually type in the test. The srcwin tests are notoriously bad... All
of our tests are NOT supposed to presume that previous tests have run,
but, alas, this practice is not widely adhered to.

I would recommend running the test by hand. Load insight, and look up the
proc do_test in util.tcl. You can specify the filename and the particular
test to run.

If all else fails, do what I do: run the test, but put messageboxes and
sleeps around the test to isolate it and see what is going on... :-)

> Are they any "how to reproduce" steps for the tests?  I tried what
> I thought the test was checking for (hold the mouse pointer
> over a variable and wait to see the balloon containing the variables
> value), but this worked, so I don't really know why this test is
> failing.

The variable balloon tests use a function in libgui to warp the cursor.
Perhaps this no longer works...

> The other problem with gdbtk is that it's using a hacked
> tcl_findLibrary.  I've got two solutions to this problem:
>
>  1) Rename the current tcl_findLibrary to gdb_findLibrary and
>  put it somewhere else.
>
>  2) Forget the hacked tcl_findLibrary and rename the gdbtk installed
>  library directory from ".../share/gdbtcl" to ".../share/gdb1.0". This
>  what I had been doing until I found out about the hacked tcl_findLibrary.

Are we really replacing the call to tcl_findLibrary in Tcl? Ouch... Well,
I understand WHY we are doing it (so that we can run from the build
directory), but there must surely be better ways to do it.

In either case, I don't like using the name "gdb1.0". If you go this
route, please use insight1.0 or gdbtk1.0. I am already considering
"purifying" the gdb repository by taking insight out and teaching gdb how
to deal with other toplevel UIs.

Keith