Re: [Plplot-devel] version info, runalldemos.tcl, etc.

[Alan W. I. <ir...@be...>]

On Thu, 4 Jul 2002, Vince Darley wrote:

> I've committed changes which should resolve all of these issues, I think.

Thanks very much for these efforts.

The new way of dealing with PLPLOT_VERSION works fine and will make my life
much easier at release time.

./plserver
source ../examples/tk/runAllDemos.tcl

is almost entirely working now.

Interestingly, for this environment I get the same first-page skip bug if a
multi-page demo (such as 8) is plotted first.  Do you get that for your
non-plserver environment?  If not, that will be another clue for Maurice when
he attempts to figure out this long-standing bug.

One glitch in runAllDemos.tcl is the page button does
not work.  Here is the stack trace delivered by plserver

bad option "nextpage":  must be closelink, cmd, configure, draw, gcmap0, gcmap1, info, openlink, orient, page, print, redraw, save, scmap0, scmap1, scol0, scol1, view, xscroll, or yscroll
    while executing
".p.plwin nextpage"
    invoked from within
".bnextpage invoke"
    ("uplevel" body line 1)
    invoked from within
"uplevel #0 [list $w invoke]"
    (procedure "tkButtonUp" line 7)
    invoked from within
"tkButtonUp .bnextpage
"
    (command bound to event)

Also the shell button does not work

invalid command name "console"
    while executing
"console show"
    invoked from within
".cshell invoke"
    ("uplevel" body line 1)
    invoked from within
"uplevel #0 [list $w invoke]"
    (procedure "tkButtonUp" line 7)
    invoked from within
"tkButtonUp .cshell
"
    (command bound to event)

Finally, as a wish list item it would be nice to have the plot window
completely separate from the buttons (or the buttons much smaller so the
plot window is not so crowded on the screen).

I also tried runExtendedDemos.tcl since your commit message said it was
changed to work under plserver.  However, it doesn't.

./plserver
% source ../examples/tk/runExtendedDemos.tcl
invalid command name "Plplotwin"

The other remaining issue I forgot to mention last time was the
bindings/tcl/pltclgen perl script that won't work for you because of
line-ending issues.  I assume that should be straightforward since perl has
had to deal with these sorts of issues forever.  However, that will probably
take somebody familiar with perl (Geoffrey?) to figure this out.

> The bit I'm not 100% clear on is whether RunAllDemos.tcl will work with
> plserver, since I don't have a plserver to test on (I tried to compile
> plplot on sourceforge's compile farm, but couldn't get it to find tcl, tk
> and got some python compile errors (couldn't find 'swig' I think)).

Thanks for trying the compile farm, but it is probably a no-hoper except for
testing the very innermost core of plplot with just the postscript driver.

Yes, the compile farm probably didn't have swig at all or swig-1.1 rather
than the required swig-1.3. Of course you could have worked around that by
the --disable-python configure option. The missing tk and tcl headers (which
I assume is what the problem is) on the compile farm are the real
showstoppers. But for unknown reasons SF have a long track record of
excluding essential developer packages from their compile-farm machines.

<rant on>

A year ago when I complained about tk, tcl, and X (!) headers being missing,
on the compile farm boxes, the SF support people claimed it would be too
much work to download and install them.  I got a similar response when I
noticed some of their essential packages were way out of date and therefore
vulnerable to security holes.  Their responses were complete nonsense of
course since their compile farm box was a Debian machine where the packages
were just an apt-get away from being installed or updated to the latest
version.

Personally, I have never been impressed with sourceforge "support".  I
certainly like all the tools they give us to play with such as the forums,
mailing lists, file release area, cvs, webcvs, etc., but if anything goes
wrong you are largely on your own, and God help you if you ever want
anything extra (such as Tcl/Tk headers on the compile farm boxes).
Fundamentally, I believe the problem is they hired most of their staff
during the Linux bubble, and they got some really lame support people as a
result who have always had the senority and who have always set a really bad
tone of coming up with excuse after excuse for inaction.

Because their support is so bad I don't see much long-term viability for
SourceForge even if they could overcome their monetary losses.  SourceForge
do provide a lot of nice toys so I am willing to stick with them until their
demise, however.

<rant off>

In my opinion, if you had access to a low-end PC that is otherwise not used
for much you would be much better off converting it to Linux using say
RedHat 7.3 (a distribution used heavily by our astrogroup) or Debian woody
(my preferred distribution). Then you are in complete control and can
download anything you need.

But if you have no access to a box you could convert to Linux, then I am
here to help....

Alan