[info-sather] Browser bug. Release pre-announcement.

[Sather User]

Hi, Fadi.  Hi, Jean-Pierre Dussault, if you are still around.

I have finally stumbled across the bug that you have both reported
(Fadi a year or so ago, Jean-Pierre in a message to this list dated 15
Aug 2008).  It is present in my own fork (currently at 1.2b10) which
will be released fairly shortly as the next GNU Sather version.

All I can say in defence of my delayed recognition is that the browser
has worked AFAIK in all my own applications, including Tcl/Tk-based
graphical ones.  But I've been taking a different and less
sophisticated approach in those cases, embedding Tcl/Tk scripts within
the Sather code as string constants and doing Tcl_Eval on them, rather
than relying purely on stuff like Library/System/TclTk/tkRaster.c to
make Tcl/Tk library calls.  Still, I've been making such calls.

E.g. in one case I have

class MAIN is
   const str_value:STR:=
        "tsv::set globs Work $env(MY_VERY_OWN_JOBDIR)\n"
        "cd [tsv::get globs Work]\n"
...
         "colrewind\n"
         "puts \"colmore = [colmore]\"\n"
         "while {[colmore]} {\n"
         "        puts -nonewline \"colcode is [colleft] = \"\n"
         "        set ucs_code [colrightadv]\n"
         "        set squiz [format %c $ucs_code]\n"
         "        puts $squiz\n"
        "}\n";
...
   main is
...
      tk_typed_var.Tcl_ResetResult;
      vi:=tk_typed_var.Tcl_Eval(str_value);
      return tk_typed_var.OK
   end;

where str_value is a 4690-line string constant, including some comment
lines, say roughly 4500 LOC.  Everything starting with "col" in the
last lines of the string is a new Tcl command implemented in Sather.
They relate to sequential traversal of a Sather array set up and
populated before Tcl_Eval() is called, the problem being, that the
so-called "array" of Tcl is a really a mapping from hashed keys to
data (corresponding to the Sather MAP and FMAP classes), not good for
sequential traversal.  (In Tcl 8.5 there is a "dictionary" which
apparently is a true array, but the backward-compatibility of Tcl 8.5
is bad.)

So, this browser bug looks serious and deep, will I guess take a year
to fix, but its presence in both the old GNU series and my fork,
independently derived from the ICSI 1.2b release, indicates that it
was an ICSI blunder, not something introduced by previous GNU maintainers.

Yet not so serious, because it's very specific to the -tcltk platform
option, not to Sather-compiled graphical applications in general.  The
ldd of my compiled executable of the above is:

        linux-gate.so.1 =>  (0xffffe000)
        libtkimgps1.4.so => /usr/local/lib/Img1.4/libtkimgps1.4.so
(0xb7f11000)
        libtkimgtiff1.4.so => /usr/local/lib/Img1.4/libtkimgtiff1.4.so
(0xb7f04000)
        libtkimgbmp1.4.so => /usr/local/lib/Img1.4/libtkimgbmp1.4.so
(0xb7f00000)
        libtkimgraw1.4.so => /usr/local/lib/Img1.4/libtkimgraw1.4.so
(0xb7efa000)
        libtkimgjpeg1.4.so => /usr/local/lib/Img1.4/libtkimgjpeg1.4.so
(0xb7ef5000)
        libdl.so.2 => /lib/libdl.so.2 (0xb7ef1000)
        libX11.so.6 => /usr/X11R6/lib/libX11.so.6 (0xb7e23000)
        libpthread.so.0 => /lib/libpthread.so.0 (0xb7e0a000)
        libgdbm.so.3 => /usr/lib/libgdbm.so.3 (0xb7e04000)
        libm.so.6 => /lib/libm.so.6 (0xb7dde000)
        libc.so.6 => /lib/libc.so.6 (0xb7c7a000)
        /lib/ld-linux.so.2 (0xb7f3a000)

and that involves statically-linked libtcl and libtk (and a
statically-linked sather compiler, different from the current GNU
sather.  The libpthread only arises because of the tsv::set etc.,
i.e. Tcl/Tk threads are being used).

So, NEWS: (okay, Pre-Announcement:)

There will shortly (in a few weeks) be a release of GNU Sather
consisting of the latest beta in my fork.  It won't have fixed the bug
identified by Jean-Pierre and Fadi, but it will have a number of new
classes which will make it easier to use (e.g. a GETOPT class that is
an interface to libc's getopt_long() and getopt_long_only(), DIR and
LSTAT classes to make file and disk use easier, a DBMS class and I
think more).

In particular, for those prepared to take the admittedly slow Tcl
script eval approach (scripts can be short and selectively eval'd, of
course) there will be, side-by-side with the directory
Library/System/TclTk, the directory Library/System/TclTk_noplatform in
which there will be TCL, TK and TKIMG classes, the latter containing
Tkimgtiff_Init, Tkimgps_Init, Tkimgraw_Init, Tkimgjpeg_Init,
Tkimgpng_Init and Tkimgbmp_Init.  Oh, and I notice there, in the wrong
place (tkimg.sa in the last-mentioned directory) the line:
Thread_Init:INT is return C_TKIMG::Thread_Init(interp) end;

There will be autoconf configuration which will look for the presence
of tcl and tk on the system, and the normal compile will automatically
compile the browser if they are discoverable, rather than requiring
you to do a separate "make optional".  This works for versions 8.4.19
and 8.6b2 of Tcl/Tk.

So, the browser bug won't be fixed, as I say, this bug, many years old,
will take about a year to fix (guess), but I hope you will find the
next release a reasonable stop-gap.

-- 
Michael Talbot-Wilson