OLDER-NEWS

This file is a concatanation of Major PLplot announcements (mostly about
releases) in reverse chronological order.

**************************************************************************
Version 5.0.2: Release announcement
**************************************************************************

From irwin@uvastro.phys.uvic.ca Thu Feb 15 09:40:02 2001
Date: Sat, 10 Feb 2001 14:22:30 -0800 (PST)
From: Alan W. Irwin <irwin@uvastro.phys.uvic.ca>
To: plplot_general <plplot-general@lists.sourceforge.net>
Subject: [Plplot-general] plplot-5.0.2 has been released

It has been a month since PLplot-5.0.1, and we thought another stable
release was appropriate at this time.

Get this new PLplot-5.0.2 as a tarball file release at
http://sourceforge.net/projects/plplot.  It was created from the current CVS
head which has benefited quite a lot from steady bug fixing over the last
month (for example, file familying now works, and the plmeta now properly
outputs to pipes).

Version 5.0.2 supersedes all previous versions. Please note that for
improved stability you should use the tarball release and not the CVS HEAD.
(We try things on the HEAD which might momentarily break plplot from time to
time.)

Note we also have some innovation in the new release as well as bug fixing.

(1) The python xw??.py examples should now work right out of the box without
fooling around with PYTHONPATH.

(2) Install file locations now conform to the FHS.  So, for example, you
will find the examples installed at $prefix/share/doc/plplot/examples.

(3) The content of the documentation source has been greatly improved from
5.0.1.  We have now completely finished going through the doc directory for
several generations of notes on various topics and incorporated all this
material (with substantial updates and expansions) into our docbook source.
The result is new docbook sections/chapters on devices, driver functions,
plrender and metafiles, familying, interactive output devices, color, and C
and fortran bindings. We have added API sections that are specialized to C
and fortran.  We have also added a bibliography and reorganized the material
so that all the reference material (bibliography and API sections) appear at
the back of the document.  We have now removed virtually all the old files
in doc so there is no longer the potential of getting confused with these
older generations of documentation.

We don't anticipate the addition of too many more chapters or sections to
the documentation, but some refinement of the existing chapters/sections
still needs to be done.  If you are interested in helping with this effort,
please contact yours truly (irwin@beluga.phys.uvic.ca).

(4) Our DocBook source can be built into PLplot documentation in a variety
of formats (currently html, dvi, postscript, pdf, info, and man).  Our CVS
does not have these files because they are generated rather than source
files.  However, you can always get the latest forms of these results from
http://www.plplot.org/resources/docbook-manual/, and for your convenience we
have also bundled these results into the doc directory of the 5.0.2 tarball.

Tests:

Release version 5.0.2 has been extensively tested on Debian potato with
double precision configured. The cdemos, cxxdemos (c++), fdemos (fortran),
tcldemos, tkdemos, and the new standalone xw??.py python demos all now work
well on potato. Similar tests show good results on RedHat 6.2 except for
Tcl/Tk whose 8.0 version on RH 6.2 is too old for us to support. We have not
yet upgraded our test box to RedHat 7.0 (which does include a Tcl/Tk/iTcl
version that we support), and until we do this upgrade, we would appreciate
any RedHat 7.0 reports our users could give us. Similar tests (excluding
Tcl/Tk and python because we would have had to download configure, build,
and install these packages ourselves) show good results on solaris (SunOS
5.6 Generic_105181-23 sun4u sparc SUNW,Ultra-2 = solaris 2.6).

Putting on my yplot (http://sourceforge.net/projects/yplot) hat momentarily,
I have also rebuilt yplot, the convenient yorick front end to plplot. The
new yplot version (to be released soon) is based on plplot-5.0.2 libraries,
and I have just confirmed it gives excellent results for a wide variety of
36 different scientific plots from my present research.

Please send bug reports, comments, and questions to this list, and
have fun (and profit) with the new 5.0.2 release of plplot!

Alan W. Irwin

email: irwin@beluga.phys.uvic.ca
phone: 250-727-2902	FAX: 250-721-7715
snail-mail:
Dr. Alan W. Irwin
Department of Physics and Astronomy,
University of Victoria, P.O. Box 3055,
Victoria, British Columbia, Canada, V8W 3P6
__________________________

Linux-powered astrophysics
__________________________


**************************************************************************
Version 5.0.1: Release announcement
**************************************************************************

From: "Alan W. Irwin" <irwin@uvastro.phys.uvic.ca>
To: plplot_general <plplot-general@lists.sourceforge.net>
Subject: [Plplot-general] plplot-5.0.1 has been released.
Date: Sat, 13 Jan 2001 08:59:42 -0800 (PST)

Get this new stable version as a tarball file release at
http://sourceforge.net/projects/plplot.  It was created from the current
CVS head which has benefited quite a lot from steady bug fixing over the
last few months.  Version 5.0.1 supersedes all previous versions.
(Please note that for stability you should use the tarball release and
not the CVS HEAD.  We ordinarily make no guarantees about the stability of
the HEAD since we want to be free to try things on the HEAD which might
break plplot from time to time.)

Note we also have some innovation in the new release as well as bug fixing.

(1) The documentation building process has been changed completely over to
DocBook 4.1 XML.  To see the nice html, postscript, pdf, dvi, info, and man
results of this effort, please look at
http://www.plplot.org/resources/docbook-manual/

(2) The content of the documentation source has been greatly improved from
previous versions.  However, more work is always needed on documentation
content, and if you have an interest in helping out with this aspect of
plplot, please contact yours truly (Alan W. Irwin).

(3) The header file style has been changed to be similar to that of X.  That
is every header file reference in source should have the prefix plplot, e.g.,

#include "plplot/plConfig.h"

This gives much less potential for nameclashes, if the headers are stored in,
e.g., /usr/include/plplot.  It also means that the -I parameter stays the
same as it was before on the compile line.

(4) The library names have been changed so they are in a more consistent style
now that gives more protection against nameclashes.  All library tags
(suffixes to the core name of libplplot, libplmatrix, etc.) are
now gone except for d for double precision and nothing for single precision
or the libplmatrix library (which is always single precision even if
you have configured double precision).  To indicate what the library names
that were used to build plrender, execute the installed
$prefix/bin/plplot_linkage.  On my current system this emits the following
line:
-L/usr/local/plplot/lib -lplplotd -lplmatrix -litk3.1 -ltk8.2 -litcl3.1
-ltcl8.2 -L/usr/X11R6/lib -lX11 -lvga -ldl -lm -lg2c -Wl,-rpath
-Wl,/usr/local/plplot/lib

Your system (if it isn't Debian potato) will have a different link line
emitted by $prefix/bin/plplot_linkage.  That is the one to use!

(5) Python now works! (at least in widgetless mode).  Configure python (which
happens by default), and try out the new widgetless examples, xw??.py.
You will like them!  These examples all require double precision.  Eventually,
we plan to add Tk widget capabilities to these examples.  Any help
would be appreciated.

(6) Fortran now works with double precision and Linux!  (It always worked
well with single precision before, but it is nice to have this generality.)

Tests:

Release version 5.0.1 has been extensively tested on Debian potato with double
precision configured. The cdemos, cxxdemos (c++), fdemos (fortran),
tcldemos, tkdemos, and the new standalone xw??.py python demos all now work
well on potato. Similar tests show good results on RedHat 6.2 except for
Tcl/Tk whose 8.0 version on RH 6.2 is too old for us to support. We have not
yet upgraded our test box to RedHat 7.0, and until we do, we would
appreciate any RedHat 7.0 reports our users could give us. We have also been
able to configure, build, and install the software on a solaris system, but
so far only minimalist testing has been done on that system.

Putting on my yplot (http://sourceforge.net/projects/yplot) hat momentarily,
I have recently rebuilt yplot, the convenient yorick front end to plplot.
The new yplot version (to be released soon) is based on plplot-5.0.1
libraries, and I have just confirmed it gives excellent results for a wide
variety of 36 different scientific plots from my present research.

Please send bug reports, comments, and questions to this list, and
have fun (and profit) with the new 5.0.1 release of plplot!

Alan

email: irwin@beluga.phys.uvic.ca
phone: 250-727-2902	FAX: 250-721-7715
snail-mail:
Dr. Alan W. Irwin
Department of Physics and Astronomy,
University of Victoria, P.O. Box 3055,
Victoria, British Columbia, Canada, V8W 3P6
__________________________

Linux-powered astrophysics
__________________________

**************************************************************************
Version 5.0.0: Release announcement
**************************************************************************

From: Geoffrey Furnish <furnish@actel.com>
Date: Fri, 12 May 2000 12:27:34 -0700 (PDT)
To: plplot-general@plplot.org
Subject: [Plplot-general] PLplot 5.0.0 is released

Greetings to all,

And you thought it would /NEVER/ happen.  :-).

I am pleased to announce that PLplot version 5.0.0 has been released.
The rest of this email will attempt to explain exactly what this means
in more detail.

First off, thanks to all the core team members who have helped with
various tasks that I could not attend to.  Not the least of which, is
the simple issue of deciding to do it, right now.

Now for a little background.  We are done with the 4.99 x, x=abc...
business, as well as the dated snapshots.  Dated snapshots are being
replaced by providing anonymous cvs access through plplot.org.  So
anyone who wants to track day-to-day development, or follow progress
on their patch submissions, etc, will be able to do that by using cvs.

In addition to that, we will provide real releases which are supposed
to be stable, or at least to get stable over a short time.  The
releasing naming conventions will follow the Linux tradition.  Even
releases are supposed to be stable, and only bug fixes and
stabilization patches will be applied to these.  Thus, 5.0.0 is the
first in this strain.  If people find minor little nits that need
fixing, this will result in 5.0.1, 5.0.2, etc.  We hope it doesn't get
too far...  Ongoing feature development will proceed in the 5.1
strain.

The release and versioning business is coordinated with cvs in the
following manner.  Stable releases go on a branch.  Ongoing
development continues on the cvs head.  To be really cvs technical, we
provide a branch point tag, a branch tag, and release tags.  So, to be
totally explicit, I did the following operations today when preparing
the 5.0.0 release:

1) cvs tag bp_v5_0
2) cvs rtag -b -r bp_v5_0 v5_0 plplot
3) cvs tag v5_0_0
4) cvs export -r v5_0_0 plplot
5) mv plplot/ plplot-5.0.0
6) tar cvzf plplot-5.0.0.tar.gz plplot-5.0.0/

Step 1 labels the state of the repository at the point in time when we
fork the 5.0 release branch.  The name of the branch point for the 5.0
release, is bp_v5_0.  Step 2 creates a cvs "branch tag" for referring
to the head of this branch.  The name of this tag is v5_0.  Step 3
creates a tag for the specific release 5.0.0, with tag name v5_0_0.
In the current case, there were no changes made between any of these
steps, so steps 1, 2, and 3 all refer to the same versions of the
files.  But as we move on from here, people who wish to participate in
stabilizing the 5.0 branch will need to check out the head of this
branch via:

    cvs co -r v5_0 plplot

Then they can do stabilization oriented development, submit context
diffs, and the core team will apply these patches, and eventually at
various points along the way, we will tag v5_0_1, v5_0_2, etc.  So,
the thing to understand here is that "v5_0" is the branch tag.  It is
a floating reference, which alwasy points to the head of this branch.
Non branch tags just refer to static file versions, labelling a single
specific collection of file versions for all of time.

Henceforth, the main line of deveopment, which we will call 5.1,
proceeds on the cvs head.  There is no branch tag for this.  To see
the ongoing develoment work on the 5.1 branch, just do:

    cvs co plplot

Use update to track ongoing work, etc.  We may possibly tag a few
interesting points along the way as v5_1_0, v5_1_1, etc, but there
will not be a branch tag for this.  Eventually, when 5.1 development
seems to have run its course, we will fork another branch for 5.2,
making a new branch point tag bp_v5_2, a branch tag v5_2 to refer to
the head of the branch holding the 5.2 release strain, and occasional
tags for specific 5.2.x releases.

Hopefully that is comprehensible to people with a cvs background.  See
the CVS faq for more background.  We'll try to put this kind of info
on the web site somewhere as we get better organized.

Anyway, in addition to the cvs access mechanisms described above, we
also are providing the 5.0.0 release as a .tar.gz file.  Steps 4, 5,
and 6 show exactly how this was created, guaranteeing that the
plplot-5.0.0.tar.gz file contains exactly the file versions that were
tagged as v5_0_0 in step 3, but omitting the CVS control information.
This tarball release is appropriate for people who just want the code
in a packaged form, and aren't interested in tracking the cvs
development specifically, or even in using cvs to fetch identified
versions.  This file has been uploaded to the plplot.org ftp site.
You can get it via:

    /anonymous@ftp.plplot.org:/pub/plplot/plplot-5.0.0.tar.gz

Eventually we will get the www.plplot.org web site updated to reflect
this, and also figure out how to identify this file release on the
sourceforge.net project page for plplot.  Someone will post messages
about that as we progress in these other areas.

Anyway, the bottom line is, right now you can get PLplot 5.0.0, either
by anonymous ftp, or by anonymous cvs.

Now for a word about the contents of 5.0.0.

The main thing that has happened over the past three years since I
escaped graduate school, is that we've been trying to fix bugs in the
autoconf support, and in the Tcl/Tk driver, and in color handling of
the X driver.  There have been a great many bugs rooted out of the
system over this period of time, and I would encourage all PLplot
users worldwide, to upgrade to 5.0.0 at this time.  This release is
known to work with 8.x strain Tcl/Tk releases, Itcl 3 releases, Python
1.5, etc.  The problems with X color management are believed to be
resolved in a manner that is generally satisfactory (there's always
room for improvement in this area, but the current state is a big leg
up over where it was before in the 4.99j or in the early snapshots).
And numerous patch submissions from users worldwide have been
integrated (although admittedly there are more outstanding, pending
core team review).  There is also a new Mac driver by Rob Managan.
Currently just the necessary source and doc files, but we will get his
Mac CW project support goods uploaded to ftp.plplot.org at some point
too.  So, there's been lots of improvement since the last release, and
I hope people will endeavor to upgrade to this new version.  If things
go wrong, please submit patches to sourceforge.net, and we'll work on
getting it stabilized.

In the midst of such endeavors, please note the distinction between
bug fixes to 5.0.x, and feature development for ongoing 5.1.  The new
stuff is going to go into 5.1.  5.0.x is really there just to have an
up to date stable and official release for those who don't want to
track ongoing development.  As such, don't expect major new features
to appear in 5.0.x releases, just fixes that relate to platform
support, minor bugs, etc.

So, what lays ahead for 5.1?  Well, like I said before, that depends a
lot on what people contribute.  My personal actions will focus in the
short term on better Tcl package participation and improved Python
module interaction.  But there are more drivers in the works, web
integration opportunities, more plot types, variations, and viewing
overhauls, etc, that various people have expressed interest in.  More
news as it happens.

Remember that you can track it all by subscribing to
plplot-cvs@plplot.org, or by reviewing the lists chronology in
geocrawler.  Or, you can use the cvs history command (also easily
accessible in Emacs fromt he version control pane), to see what people
are doing, track your patch submissions to see when they get in, etc.

Cheers to all,

--
Geoffrey Furnish            Actel Corporation        furnish@actel.com
Senior Staff Engineer      955 East Arques Ave       voice: 408-522-7528
Placement & Routing     Sunnyvale, CA   94086-4533   fax:   408-522-8041

"... because only those who write the code truly control the project."
						      -- Jamie Zawinski

_______________________________________________

**************************************************************************
Historic PLplot reorganization (at sourceforge) message
**************************************************************************

From: Geoffrey Furnish <furnish@actel.com>
Date: Wed, 12 Apr 2000 11:57:44 -0700 (PDT)
To: plplot-general@plplot.org
Subject: [Plplot-general] Welcome to the new era of PLplot!

Hello Everyone,

Welcome to the new era of PLplot!

With many apologies to all for the extreme delays that have been
incurred over the past months, it gives me great pleasure to be able
at this time, to finally provide details of the reorganization of the
PLplot project.

As most of you know, PLplot was hosted at dino.ph.utexas.edu during
the time that Maurice and I were employed at the Institute for Fusion
Studies, at the University of Texas at Austin.  dino continued as the
host for PLplot after we each moved on, but we were searching for a
suitable place to relocate the project.  As I am sure you all know,
the open source software movement has gained a lot of steam in recent
times, and there were a number of organizations willing to host
PLplot.  Of course we deeply appreciate the offers of sponsorship
tendered by all of these organizations.  However, it turned out that
the technical challenges of hosting a project like this, were not fully
appreciated by all such sponsoring agencies.  Curiously, we were a
little hobbled in a sense, by being just a hair ahead of the curve,
and wound up sinking significant amounts of effort into rehosting
PLplot at two sites that ultimately simply didn't have the
sophistication to quite bring the task to closure.

The final resting place, is sourceforge.net, operated by VA Linux.
PLplot now has its own domain, plplot.org, and a variety of services
accessible through this domain.  The domain is hosted by
sourceforge.net.  I will explain the current services available
through this domain below.  If anyone in the user base wants to thank
VA Linux for their sponsorship of the PLplot project, you could send
email to Chris DiBona <chris@valinux.com> to express your
appreciation.  Our web site will also contain attribution to this
effect, once we get it put together.

Now, on to the list of services provided through plplot.org.

First, the new official web site for PLplot is www.plplot.org.  Randy
is the web master, and will be bringing this up as time permits.  For
starters, he has imported the prior PLplot web site by Noel Gorelick,
and will be expanding from here.

Second, we now export the PLplot CVS repository via anonymous CVS at
cvs.plplot.org.  From now on, anyone will be able to obtain the latest
version of PLplot using anonymous CVS.  CVS  has become the darling
source control system of the open source movement, and deservedly so.
I won't take the time in this message to attempt to explain this in
detail.  There are other resources on the net, and at sourceforge.net
in particular, which do this job.  The very short story is that you
can do this:
    setenv CVSROOT :pserver:anonymous@cvs.plplot.org:/cvsroot/plplot
    cvs login
    <no password required, just hit return>
    cvs co plplot
Once you have done this, you will be able to track ongoing development
(if you wish) by doing a "cvs update" from time to time.

Third, there will be anonymous ftp as well.  We don't have anything up
there yet, so information will be forthcoming on this once we finally
put some files up there.  Probably we will put up the same files that
were on dino, providing the historical "releases", and in the future
we may make pacakged tarballs of future releases.  Anyway, more info
on that once there is something concrete to report.

Fourth, there is a new mailing list, "plplot-general@plplot.org".  All
subscribers to the old list (plplot@dino.ph.utexas.edu) have been
transfered to the new list.  Also, a few people who've sent me email
over the last fewmonths have been added as well (that is, the requests
I could still locate in my inbox :-).  You should've just received a
message from the list manager explaining to you how you can interact
with it.  Sourceforge.net uses "mailman", which is a bit different
from what we used before (majordomo), but there is plenty to like
about mailman if you haven't encountered it before.  Primarily it
interacts with subscribers through a web interface, so you have much
greater personal control over how it interacts with you.  In
particular, I hope that this will finally put an end to the
desperation "get me off this list" problem we were having before.
Please, if you want off, just go the mailman management page, and do
the job!  But you can also use it to control numerous delivery options
including digesting, etc.

One thing that we were not able to do, is to get the old majordomo
mailing list archives, directly imported into the new list manager.
We'll probably put those historic list archives up on the anon ftp
site somewhere so you can still get them if you want.  Anyway, mailing
list traffic from this point forward /is/ being archived, just not
combined with the old stuff.  Oh well.

Anyway, "plplot-general@plplot.org" supercedes the old list.  The old
one is down anyway as everyone probably knows.  The story on that is
that dino actually suffered a cataclysmic hardware failure last fall,
just as we were about to move off to sourceforge.  This resulted in
lost time as we scurried to restore the filesystems, recover the
PLplot cvs repository, etc.  If anybody wants to thank the IFS staffer
who exerted heroic effort to help us recover from this disaster, you
could send email to Jim Dibble <dibble@peaches.ph.utexas.edu>, to
express your gratitude.  He worked really hard to help dig us out of
that ditch.

Besides "plplot-general@plplot.org", there is also
"plplot-cvs@plplot.org", to which cvs commit messages will be sent
when developers with write access to the repository commit changes.
If you haven't used cvs before, let me just say that these commit
messages are an extremely valuable way to keep abreast of what is
going on in a software development project.  It results in a certain
amount of email, so if that bothers you, you won't want to be on that
list (or you should make sure you have a filtering agent so you can
control the inbound flux to your liking).  But if you just want to
have a very low-overhead way to keep tabs on what is going on, who's
done what when, who's patches have been applied to the repository,
etc, subscribing to plplot-cvs@plplot.org is an excellent idea.  If
you are one of the people who makes occasional patch submissions, you
might want to subscribe at least long enough to watch for when your
changes go in, for example.

Fifth, there is a "project page" at sourceforge.net:
       http://sourceforge.net/project/?group_id=2915
We will probably have a link to this somewhere on the www.plplot.org
home page.  Anyway, people who are tapped into how sourceforge works,
may find this useful.  Frankly, none of the current developers have a
clue what to do with all this stuff, so we're all learning here, and
will all have to collectively help educate ourselves about how to get
the most value out of this.  Anyway, one thing that is fairly easy to
access from here, is a browsable portal onto the CVS repository,
orchestrated through "CVS Web", modified by sourceforge.net.  There is
lots to explore at sourceforge.net, far more than I am even remotely
aware of or could convey in this message.  We will all have to learn
together how to best exploit this resource for the open source
community.

Finally, a word about people.  As long time participants on this
mailing list will remember, there has long been a lot of frustration
over the difficulty of getting patches into PLplot.  This has
primarily been a function of the fact that Maurice and I are both out
of the university scene now, holding down real day jobs with real
professional commitments, and simply haven't been able to provide the
bandwidth to support the pace of development of an open source project
like PLplot.  We (and here "we" means the entire PLplot community)
certainly appreciate and have benefited from the valuable
contributions offered by many over the years, but my personal failure
to rapidly incorporate everyone's work, has been a key liability for
the project.  Correcting this critical problem, was one of the primary
goals in seeking a rehosting arrangement for PLplot.

This vision has now FINALLY! been realized.  At this time, there are a
total of five people with write access to the repository:

myself
Maurice
Alan W. Irwin
James Phillips (randy)
Rafael Laboissiere

Alan and Rafael have been overhauling the documentation of late, and
that will be showing up for public consumption before long.  And Randy
is picking up the webmaster role.

Exactly how we will deal with inbound patch submissions has not been
fully worked out, but my point here is, at least /I/ am no longer the
bottleneck.  We have a publicly accessible host, we are exporting the
CVS repo through anoncvs, and we have multiple people who can act to
get patches applied.  These are the reasons for regarding this as the
dawn of the new era of PLplot.  I would like to take this chance to
publicly thank Alan, Randy and Rafael for joining Maurice and I in
this capacity, and for both the work they have already done, and will
be doing as we move forward.

it has been a long time in coming (too long), but I hope that all
PLplot users everywhere will share my enthusiasm as we enter the new
millenium with a revitalized PLplot project.

I suppose in closing, it would be good to say some words about what is
really going on with the software itself.  Curiously, this is the part
I am least able to address.  And in a strange but real sense, that is
the best part of this message.  I have no idea what is ahead of us.
It really just depends on what the world wide open source developer
community pulls out of their hats (keyboards).

Onward Ho!

--
Geoffrey Furnish            Actel Corporation        furnish@actel.com
Senior Staff Engineer      955 East Arques Ave       voice: 408-522-7528
Placement & Routing     Sunnyvale, CA   94086-4533   fax:   408-522-8041

"... because only those who write the code truly control the project."
						      -- Jamie Zawinski

_______________________________________________


**************************************************************************
Version 4.99i: Summary of major changes
**************************************************************************

Primarily a bug-fix release.  Major changes:

- Changed distribution status to GPL/LGPL.  See "Copyright".  Other
  administrative file name changes.

- Various small bugs in configure & build fixed.

- Bug in code to keep track of window world coordinates fixed (symptoms:
  core dump would occur after the 65th page if pleop() was used to end the
  page rather than pladv()).  Thanks to Ian Searle for providing a
  demonstration of the bug.

- Bugs fixed in core routines + TK driver handling of colormap when
  saturation = 0; i.e. grayscale plots.  Thanks to Radey Shouman for his
  help.

- Fixed a bug that was preventing the exponential label from showing up
  under certain circumstances (3-D plots).

- Conex device (tek emulator under DOS) driver support added in tek.c;
  contributed by Mark Olesen.

- Bug fixed in X driver that was causing a "Bad Match" error upon startup
  on some systems.

- Postscript driver:
    Fixed bug in current point update after state change.
    Fix to allow cmap1 color selections to appear in grayscale;
    contributed by Radey Shouman.

- Tk driver: Fix to allow a TK main window to be associated with each
  PLStream (so x14c now can use either the TK or DP driver), also fix to
  properly update plserver's X-driver when cmap state is
  changed.  Contributed by Radey Shouman.

- pltek: Now checks for the terminal type and provides some rudimentary
  decisions based on the TERM setting.  The xterm is unaffected, but with
  a terminal type of "tekterm", the 'Page >' prompt is printed on the
  graphics screen so that the plot can be seen without having pltek flash
  back to the text screen immediately.  Contributed by Mark Olesen.

- Updated DOS/EMX driver provided by Mark Olesen; see sys/dos/emx for
  more detail.

- Amiga driver: Updated to work with new version.  Now has configure
  script for SKsh users -- is now trivial to configure and build.  A
  fall-back Makefile is also provided.  Several bugs fixed, notably one in
  changing the screen mode.  A compiled version of the PLplot library
  (SAS/C 6.2, IEEE single precision floats, optimized) and plrender are
  now available in the ~ftp/plplot/amiga directory on dino.ph.utexas.edu.

- The "plpr" script (used when choosing "Print" from Tk driver) now
  defaults to using color postscript as output.

**************************************************************************
Version 4.99h: Summary of major changes
**************************************************************************

This was to be a quick bug fix update, but I got going on several major
changes plus addition of user contributions.  So there are some important
new capabilities as well as a lot of bug fixes.

Note: as a result of a lack of time, most of the DOS drivers and the Amiga
driver have not been upgraded to work with the new configure/build files.
The DOS DJGPP port is one exception.  So these are essentially useless
until these are done.  I will issue another beta as soon as these are
done, hopefully within a week or two.

------------------------------------------------------------------------
Configuration, building, and installation:

Completely new configuration script!  The new configure script is
built using GNU autoconf, and great care was taken in its construction.
Highlights:

1) It is capable of doing basically everything it did before.  Packages
   are included by typing e.g. --enable-tk or --disable-tk, etc.  Major
   options are set by typing e.g. --with-gcc or --without-opt, etc.  There
   is a startup file so you can customize on a per-site basis like before.
   Although now, shell variables are used to store settings rather than m4
   variables, and only are substituted in the various files at the end of
   the configure script.

2) The Makefile components are usable on non-Unix systems.  Notably the
   dependencies -- the Makefile is constructed by concatenating several
   text files together. The setting of configuration defaults on a
   non-Unix system is similarly easier than before.  Just keep around
   custom copies of plConfig.h and plDevs.h.  It's better to have
   'configure' build these for you, of course.

3) The configure script is fully automatic.  It should find all the major
   capabilities needed by PLplot if your system supports them, with no
   user intervention required.

4) The object file dependency list is now constructed using "gcc -MM"
   (like "makedepend", only better), making it much more robust.

5) Much better support for shared libraries.  Works under HPUX and SunOS
   now, with Solaris, Irix, OSF-1 probably not far behind if someone wants
   to fill in the details.  AIX probably I will get to, and Geoff has
   started on the Linux shared library build.

6) The new header file plConfig.h makes it much easier to get portable
   code, by concentrating all the hacks in one place and using configure
   to set them accordingly.

See the cf/README file for more info.  It works pretty much without
user intervention now, though.

------------------------------------------------------------------------
The second major addition: a Tcl PLplot API and interpreter.  This means
you can now make PLplot calls from Tcl.  An interpreter -- pltcl (an
extended tclsh) is provided.  Be sure to check out the demo programs as
follows:

foobar% pltcl
% source demos.tcl
% 1
% 2

etc, up through 7.  Not all PLplot C API calls are supported by the Tcl
API yet.

As part of this development a Tcl extension was created to handle matrices
(arrays).  Right now it supports 1-d, 2-d, and 3-d arrays.  Eventually
it will be improved a bit more and better documented and released to
the Tcl/TK community.  For now, read doc/tclMatrix.doc and check
out the Tcl demos.

------------------------------------------------------------------------

Other changes:

- Another major cleanup of the core source files.

- Ability to make point, line, and polygon plots in 3-d added.
  (Contributed by Geoff Furnish.)

- Changes to support returning the cursor location in world coordinates
  given a mouse click, if supported by the driver (only used by windows
  driver so far -- a lot of work remains for the rest of the package to
  use it).  Supports multiple windows per page, and gets the correct set
  of world coordinates for the plot selected.  Contributed by Paul
  Casteels.

- Function to plot map backgrounds added, where the map data is read from
  the specified map data file (examples provided).  Contributed by Wesley
  Ebisuzaki.

- Fast point plot ability added.  Call plpoin with code=-1 for a 4X or so
  speed increase in point plots.

- Search path for needed files improved and made more consistent.
  (Contributed by Mark Olesen).

- Can now save a plot from the Tk/DP driver and have the colors turn
  out correctly.

- Previous problems re: mono X displays fixed.

- Multiple sequential bop or eop's are now munged together, making it
  easier to avoid blank pages.

- Can now change the number of subpages at any time.

- Fixed problems in tek drivers caused by entering cbreak mode --
  this was fouling up user input (tty) requests.  Now it goes into cbreak
  mode when switching to the graphics screen, and back to canonical mode
  when switching to the text screen.  Also, this is all usable now on
  systems without an ANSI libc.

- Added new driver -- HP Laserjet III in HPGL emulation mode (lj_hpgl).
  Contributed by Conrad Steenberg.

- Greatly improved support for embedded plframe use (directly from
  plserver or a plframe-extended wish).  See tk01, tk02, tk03 for more
  info.  Many minor improvements and a few bugs squashed in the Tk driver.


**************************************************************************
Version 4.99g: Summary of major changes (gigantic update)
**************************************************************************

This was a very big update, sorry for the delay.  The changes may cause
some inconvenience, and while we can't promise an end to that :-), will
try to hold them to a minimum before the "big" 5.0 release.  As we get
closer, there are some changes we will make in the "now or never" frame of
mind, meant to positively affect future versions without causing too much
difficulty now.


- Document:

We have made substantial progress towards converting the (previously
LaTeX) document into LaTeXinfo.  This gives us the capability to have both
a high quality (yes, if you work at it hard enough) printed manual as well
as a hypertext-like online document, using info.  There are many info
readers around but the most famous is the one built into Emacs.  Both
documents are now available but still need considerable work, and
unfortunately are still largely based on information as of the beta
plplot4.0 series.  Based on the number and importance of the changes since
then, we an updated manual is desperately needed!  And it is coming...the
contents of the doc directory represents work in progress.


- configuration, building, and installation:

configure has been improved so that it runs more like GNU configure.  You
can run it from the root directory (although I don't necessarily advise
doing so) and use the GNU configure --prefix option for setting the
location to install PLplot (more useful).

THE DEFAULT INSTALL DIRECTORY PROCEDURE HAS BEEN CHANGED!!!!!
Now PLplot by default installs into:
	prefix-dir/
		bin/
		lib/
		include/
		doc/
		tcl/
It had to be done before it was too late.  Makefile overrides default
value of INSTALL_DIR if m4 macro PREFIX is defined.   Also check out
the script "mklinks".


- Tcl-DP driver added!

Yes, finally finished, and it works great everywhere but on Crays (sigh --
and I thought I fixed that in the Tcl-DP 3.1 distribution).  By using the
DP driver you bypass all the difficulties with using Xauth (or the
security problems of doing without it) in the TK driver.  The Tcl-DP
driver is much more usable.  It's even distributable -- tested between an
HP and a Sun (as server), and between an IBM RS-6000 and HP (as server).
Just specify -server_host (and -user if necessary), and it will try to
start up a plserver under your user account (need to have .rhost info set
appropriately).  Great at increasing responsiveness of the GUI, and screen
dumps always save to the local machine.


- TK interface improvements.

The TK interface (using either the TK or DP drivers) has been greatly
enhanced.  "plserver" can be used exactly like an extended "wish" now (the
TK windowing shell).  It has been extended to know about "plframe" widgets
and how to interact with the PLplot/TK/DP drivers.  There are documented
interfaces and demos now for building your own extended wish using the
plframe widget, as well as an illustration of direct plotting using PLplot
from Tcl (through the plframe widget).  Color map manipulation tools added
for cmap0 and cmap1.  Support for user-modifiable keystroke invocation of
menu items added.  The following are the defaults keymappings as set in
pldefaults.tcl, their meaning is clear:

    global key_zoom_select;	set key_zoom_select	"z"
    global key_zoom_reset;	set key_zoom_reset	"r"
    global key_print;		set key_print		"p"
    global key_save_again;	set key_save_again	"s"
    global key_scroll_right;	set key_scroll_right	"Right"
    global key_scroll_left;	set key_scroll_left	"Left"
    global key_scroll_up;	set key_scroll_up	"Up"
    global key_scroll_down;	set key_scroll_down	"Down"
    global key_scroll_slow;	set key_scroll_slow	"3"
    global key_scroll_fast;	set key_scroll_fast	"15"
    global key_scroll_faster;	set key_scroll_faster	"75"

The last three indicate the number of pixels to scroll each time one
keystroke is processed.  To get the "fast" setting, press Shift-cursor.
You get the "faster" setting by using shift-ctrl-cursor.


- Area fill support added.

Now you can do color (hardware) fills.  Only recognized on certain drivers
(postscript, all X-based drivers, all Tek4107 devices, and Amiga).
Tektronix devices even recognize hardware pattern fills (obtained by a
negative fill index).  Devices that don't know about hardware fills
automatically get a software pattern fill.


- Color map usage improved.

I have finally implemented the dual cmap0/cmap1 color scheme I have long
talked about.  cmap0 is typically for fixed colors, like axes, labels,
lines, etc.  Color 0 of cmap0 should now be the background!  It may not
always be enforced now but it eventually will be, as well as possible.
cmap1 is envisioned as a continuous tone color palette.  cmap0 contains
the "normal" colors that you set by plcol(<number>) (now plcol0(<number>)
is preferred).  cmap1 contains colors set indirectly, by specifying
"position in cmap1 space" -- a floating point number from 0 to 1 (previous
to that a mapping between position and color must have been specified).
This scheme has the advantage that you can take advantage of as many or
few colors as the output device supports.  For example, with postscript
which supports arbitrarily many colors (the printer itself is another
story), you can get 256 different colors, because that's as many as I
currently provide storage for.  On X-windows with 8 plane displays I get a
lot less with a shared colormap (custom colormap support is almost done),
maybe around 50-100, depending on window manager.  And this scheme is even
useful on as few as 16 colors, as is commonly available (Tek 4107
emulation is fairly common on the PC, Mac, and Amiga).  You do so by
limiting the number of colors in cmap0, leaving most for use in cmap1.
plshade() function enhanced to work with either color map -- see example
program x16c for a demonstration.

If at all possible, try to play with x16c using the TK or DP driver --
modifying the color map interactively is simply wonderful.  Especially try
modifying cmap1, and then loading in the alternate palettes cmap1b.pal and
cmap1c.pal (cmap1a.pal is the default), and play with it; you will get a
much better idea how it works while I get around to documenting it!


- Revamped Tek drivers, added explicit support for: Versaterm (Mac), and
VLT (Amiga).  [explicit mskermit(DOS) support was added in the last
release] Tek4107 driver improved to actually work on a real tek 4107
(thanks to Paul Kirschner).  Commands to set color palette now are sent
from PLplot.


- Postscript output behaves better with ghostview -- it actually
backspaces correctly (hey hey, finally).


- X driver: lots of changes to support color map1 and custom color
maps.  Right now does NOT use a custom color map by default since I didn't
think it was quite ready for the big time, especially as part of the
TK/DP driver.  There are some internal settings the adventurous can
play with.  Function added for capturing mouse events added (thanks to
Radey Shouman); this soon should lead to a way of returning world
coordinates at the mouse position.


- Improved DOS driver support (see Changes.log and the drivers)


- All source files handling API: replaced call to plexit() on simple
(recoverable) errors with simply printing the error message (via
plabort()) and returning.  Should help avoid loss of computer time in some
critical circumstances (during a long batch run, for example).


- behavior of exit handler changed to be more useful for users who want
greater control of execution.


- plus lots of bug fixes, memory leaks plugged, compilation warnings
eliminated, etc.


**************************************************************************
Version 4.99g notes distributed by e-mail:
**************************************************************************

From: Maurice LeBrun <mjl@dino.ph.utexas.edu>
Subject: Some comments on 4.99g
To: plplot-list@dino.ph.utexas.edu
Date: Fri, 27 May 94 4:32:26 CDT

Just some varied comments about this last release.

This release (PLplot 4.99g) was very long awaited, and very draining.
There have been several new capabilities that I thought were too crucial
to wait any longer before adding them, as well as many minor improvements,
bug fixes, and user-contributions.  There are a lot of energetic users-of
and contributers-to PLplot.  A bit to my surprise, I might say.  (But
then, recently when I talked to Sze Tan, the original author, he said the
same thing..)

No doubt there will be some difficulties encountered with this release.
There may have to be a bug fix release before long to fix problems, so
please let me know of difficulties.  It might help to post them to the
mailing list so that other people don't have to experience the same.

This is the last big release before 5.0, the rest I hope are relatively
minor updates.  With 5.0, we aim for (a) most known bugs to be killed, (b)
all capabilities we've been working on to be finished, (c) all significant
capabilities be documented, and (d) the package tested on all platforms
listed as "supported".  We are approaching this goal, but are a little
ways from it yet.  However you may still get your chance to help out :-).
More on that later.

Some comments on the new capabilities:

A big newbie is the Tcl-DP driver.  Fixes some of the inherent problems
in the TK driver send mechanism, and is distributable across a network.
It really works, I've tried it (for some configurations at least).
Nothing like zooming in on a plot at workstation speeds when the renderer
front-end is running on a machine half the world away (yes, I've even
done it between Texas and Japan).

Lots of cool improvements to the TK interface.  Check out the color
palette manipulation tools.  Certain menus have keystroke equivalents now
(e.g. hit 'z'), making simple operations much nicer (thanks, Dave, for the
suggestion).

Support for direct usage of the plframe widget as a Tcl/TK extension.
This is very important since Tcl/TK, especially when taking all the cool
extensions into account, is *THE* way to program X-based applications
(IMO).  Sophisticated user interfaces to scientific codes under X, using
the PLplot widget (among others) are just waiting to be built...

Color map 1 support -- this is designed to enable the type of continuous
color plots you can get in other graphics packages (e.g. I'm thinking of
NCSA Ximage) but in a more flexible way, allowing intuitive modification,
and display on a number of devices.  This capability comes in through the
new color palette -- cmap1, and you take a look at x16c to see the effect.
Preferably using multiple color (supported) devices, and for the best
effect using the TK or DP driver, playing with the color palette using the
new menu options.  Thanks again to Wesley Ebisuzaki for contributing
"plshade()", the function doing the shading here.  Note: plshade is the
best way for limited number of colors, but for a larger number of colors
(and grid points) a different algorithm would be optimal, something that
is more discrete.  At 0th approximation, you might try a function that
just fills each grid cell with a constant color.  Suggestions appreciated.
Also, the TK driver right now does not proper clip polygons (on zooms),
because the algorithm to do so hasn't been implemented.  Any interested
parties?

Work on the updated manual is underway and so far it's looking pretty good...

--
Maurice LeBrun    mjl@dino.ph.utexas.edu
Institute for Fusion Studies, University of Texas at Austin

Faire de la bonne cuisine demande un certain temps.  Si on vous fait
attendre, c'est pour mieux vous servir, et vous plaire.
                                [menu of restaurant Antoine, New Orleans]


**************************************************************************
Version 4.99d additional notes
**************************************************************************

From: Maurice LeBrun <mjl@dino.ph.utexas.edu>
Subject: Some comments about plplot 4.99d.
To: plplot-list@dino.ph.utexas.edu
Date: Wed, 27 Oct 93 17:08:53 CDT

I thought I'd mention a few other things in association with this latest
release.  There may be a smaller release before long, to address those
(hopefully minor) problems that arise.  Then I will take a break from
plplot development for a short while, and after that my major push will be
to update the document, a few more enhancements, and slow down a bit.

The TK driver was a tremendous push, but I expect it to be worth it.  It
has the basic functionality that I've always wanted, along with a huge
potential for customization.  It is my intention that people can build
arbitrary Tcl/TK applications that just happen to use plplot widgets to
plot into.  I plan to construct at least one demo of how to do such a
thing, and it will be interesting to see what kinds of variations people
come up with.  Tcl/TK programming is so easy that there should be lots (I
can't believe I was actually considering doing a Motif-based driver).
Writing a widget, on the other hand, is hard work, but now that's more or
less history.

Also, as I constructed the Tcl/TK driver I tried to add the required
increases in functionality to plplot in a rather generic way.  The stuff
you would ordinarily use a GUI for can typically be handled from the
command line in fact -- like page layout, zooms, and orientation
(independent of the output driver).  This is because of the new driver
interface functions that sit between the library proper and the driver.
They are located in plcore.c if you are interested, and do 4
transformations so far -- orientation (you can even rotate by a fractional
amount, but I never bothered making it come out perfect! :-), altering the
window into plot space (zoom), altering the window into device space
(page layout, good for adding margins), and global device coordinate
transformation (good for making page dumps to an arbitrary device).
Other windowing drivers should be able to use these facilities without
too much trouble.  Eventually I hope to intercept other commands at
the interface layer, and decide what to do based on the intelligence
of the driver.  This might be used to handle device dependent fonts,
hardware color fill, and so forth.

At this point, I'm feeling the need to release the package in a more
"official" way than I have in the past.  So my main priority will be to
bring the documentation up to sync with the rest of the package.  I would
also like to accomplish the first 4 or so things on my 'ToDo' list, and as
it should involve about 1/10 of the effort of the original TK driver (I
hope :-) expect it to happen in a much shorter time frame than the 8
months or so this release has taken.  I'll probably introduce some
compatibility problems at that time in an effort to consolidate, but after
5.0 will be very careful about breaking old software.

In another change, I would like to ask for volunteers to maintain versions
of plplot for specific platforms.  These people could get prerelease
versions in order to make whatever fixes are needed ahead of time.  We are
most likely to have the package be up-to-date on the following systems:
HP-UX, Linux; less likely on the following: SunOS, AIX, Unicos, Super-UX,
Amiga, and maybe not at all on any others.  It would be good for someone
to put in shared library support for any system that supports them (so far
I've only done it under HP-UX).  I am gradually moving away from
supporting the Amiga driver so could use some help here.  Geoff has
abandoned the DOS drivers and is leaning away from supporting the OS/2
driver, so here again target platform developers are needed.

--
Maurice LeBrun    mjl@dino.ph.utexas.edu
Institute for Fusion Studies, University of Texas at Austin

Faire de la bonne cuisine demande un certain temps.  Si on vous fait
attendre, c'est pour mieux vous servir, et vous plaire.
                                [menu of restaurant Antoine, New Orleans]




**************************************************************************
Version 4.99d pre-announcement plus assorted e-mail notes leading up to 4.99d
**************************************************************************

Pre-announcement
----------------

As I mentioned in the previous plplot beta update, I have been working on a
plplot TCL/TK driver under Unix/X (if you're not running Unix/X you might as
well skip this message).  Well, I am now far enough along that I can
confidently say it will see the light of day before too long, on the order of
weeks I hope.  It should be really nice, too, and am letting everybody know
ahead of time so that you can go get the TCL/TK distribution (if you don't
have it already) and start playing with it.  TCL is an embeddable interpreter
in the spirit of Perl, and TK a Motif-like toolkit.  They are free and very
high quality; furthermore, constructing the script language & interpreter
together with a toolkit appears to be an outrageously useful thing to do.
You have to try it to see why.  For more info, consult the substantial
documentation (and demos) for TCL/TK.  I have appended the FAQ to the end of
this message.  To quickly find the section on how to get TCL/TK and assorted
other stuff, search on the string "Tcl/Tk Package Catalog".

Moving on, the basic code is done and I am finally getting simple plots out.
What I have is the following:

User-code
       |
   plplot tk driver                         plserver
   TCL interpreter <------ tk send ------> interpreter
           |                                    |
       data writer  ---- named pipe -----> data reader
                                                 |
                                           child X window

The user-code and the renderer (tentatively called plserver, I may change
this) form a client/server relationship, and are separate processes.  Under
typical usage, where the user-code starts first, it forks (vfork on systems
that support it) and execs the renderer.  TCL/TK communication (via X
properties) is used between their embedded interpreters to send commands back
and forth (note: an extended version of TCL called TCL-DP allows sockets
to be used for this, and I will eventually try to extend the model to
allow distribution across a network).  The existence of an interpreter in
each process (actually each plplot stream that uses tk too) allows for
a very easy & robust method of sending commands between processes.
The data goes through via an alternate channel (fifo for now, maybe socket
later) for maximum speed.

Also I will support an alternate configuration where the server launches
applications, telling them what plplot widget to plot to.  Lots of nice
possibilities there.

By offloading the GUI-building code into a simple script language, it becomes
easy to build menus, buttons, scrollbars, etc.  All of these will be
configurable by the user, as well as the ability to map events (such as
button presses) to functions calls in your own program.  But you will need to
learn TCL/TK to get maximum benefit.  Even without additional effort,
however, you will be able to use the new driver's menus to do zooming, dump
to file, etc.

More later..

--
Maurice LeBrun    mjl@dino.ph.utexas.edu
Institute for Fusion Studies, University of Texas at Austin

Faire de la bonne cuisine demande un certain temps.  Si on vous fait
attendre, c'est pour mieux vous servir, et vous plaire.
                                [menu of restaurant Antoine, New Orleans]

From: Maurice J. LeBrun <mjl@dino.ph.utexas.edu>
Subject: slowness of the TK driver over the net
To: wdn@ctrss2.lanl.gov
Date: Thu, 19 Aug 93 11:24:46 CDT
Cc: furnish@dino.ph.utexas.edu, gray@dino.ph.utexas.edu,
        mjl@dino.ph.utexas.edu

>      Also, I used plrender to render a meta file on dino and display on
> ctrss2.  One thing that I noticed is that it seems to take much longer for
> the plots to be displayed running the tk driver than just the standard X
> driver.  Do you notice that locally on dino?  Also, do you have a good demo
> meta file lying around that I could grab and try?  I could not get plrender
> to go backwards with my meta file using the tk driver and wonder if it is
> because the meta file was generated by an ancient version of plplot.
>
> 		Dave

The current incarnation of the TK driver is going to run a bit slow
over a network because of the way messages are passed between the
user code and the renderer.  In this case plrender is the user code
and it forks the actual renderer.

The TK send command does IPC by storing messages in an X property
of the display.  This means that when running over a network, messages
must travel from the X client to the X server and then back again.
Kind of sick, I know.  So for the time being I recommend using the TK
driver primarily locally.

Eventually I will switch to a scheme where the renderer runs on the
display server.  I don't think there will be many changes required for
this to work.  The FIFO becomes a socket, and the TK send is replaced by
Tcl-DP's send (which uses sockets).  I have to work out how to start the
remote renderer.  Probably it could try doing a remsh (or rsh on systems
that don't have remsh), and if it fails for security or other reasons,
tell the user to start the renderer manually using some specified socket
for communication.  I don't feel like getting into all this now but that's
sort of how it will look.

--
Maurice LeBrun    mjl@dino.ph.utexas.edu
Institute for Fusion Studies, University of Texas at Austin

Faire de la bonne cuisine demande un certain temps.  Si on vous fait
attendre, c'est pour mieux vous servir, et vous plaire.
                                [menu of restaurant Antoine, New Orleans]

Date: Tue, 7 Sep 93 23:55:50 -0500
From: Maurice J. LeBrun <mjl@dino.ph.utexas.edu>
To: furnish@dino.ph.utexas.edu, gray@dino.ph.utexas.edu,
        mjl@dino.ph.utexas.edu, wdn@dino.ph.utexas.edu
Subject: CVS update notice

Update of /u/tpc/cvs/plplot/sys/unix
In directory dino:/u/mjl/devel/plplot4p99d/sys/unix

Modified Files:
	makefile.m4
Log Message:
Now passes in INSTALL_DIR as a string containing the installation
directory, typically /usr/local/plplot.  Files that get this information
include plfont.c (for use in the font search path), plserver.c (for use in
the autoload search path), and tk.c (to search for plserver befor the
fork/exec).  The environmental ${PLPLOT_DIR} is ALWAYS placed before
INSTALL_DIR in the search path in each case, so there is ready escape
from the tyranny of a hardwired location.


From: Maurice J. LeBrun <mjl@dino.ph.utexas.edu>
Subject: plplot libraries
To: furnish@dino.ph.utexas.edu, gray@dino.ph.utexas.edu,
        wdn@dino.ph.utexas.edu
Date: Fri, 16 Jul 93 23:54:30 CDT
Cc: mjl@dino.ph.utexas.edu


I finally got around to making a test that I was curious about.
I compiled plplot's x01c under a variety of configurations to see the
effect on executable size (on disk, stripped).  This is all under
HP/UX.

Xlib (shared)   Xlib (archive)  TK (archive)    size
-----------------------------------------------------
no		no		no		233 KB
yes		no		no		246 KB
no		yes		no		406 KB
yes		no		yes		754 KB
no		yes		yes		918 KB <- getting up there,
					 but still smaller than with Motif :-)

As can be seen, the penalty was almost zero when the shared X library was
used, and probably the same would occur if the TK library were made
shareable.  Although this doesn't mean there is no penalty for hooking up
with these libraries, it does amount to a big savings in disk space
(obviously), and I think even of run-time image if more than one app
using these libraries is running (since only one copy needs to be in
memory at a time).

Unfortunately it's still far from clear what libraries to retain in general.
For workstations, I'd say *usually* go with the full Xlib & TK version,
although it may be useful to provide libraries that have no X dependence.
For Crays it becomes more difficult.  Partly because UNICOS has no shared
libraries, and the libraries are bigger to boot.  But also it isn't clear
that the TK driver will even run with acceptable speed, never mind whether
running a GUI is appropriate use for a Cray (eventually the TK driver will
become distributed and this point will become moot).  So on the Cray, it's
tempting to provide libraries for use with the Xlib driver only, except that
plrender be built with the TK driver as well.  Probably I won't decide this
until I actually get TCL/TK up on the Crays and get to play with the TK
driver out there.

If one were to allow for the possibility of building all three libraries
it might look like the following:

libplplotf.a		no Xlib or TK
libplplotfX.a		Xlib only
libplplotftk.a		Xlib and TK

This would be nice from the user perspective if all sites followed this
convention.  You would have no problems getting the right one from your
makefile regardless of the system.  Or you could make a soft-link from
whichever one of these you really want to ~/lib/libplplotf.a if you really
want to simplify things.

But including the double precision versions you get 6 libraries.  Double it
again for shared library versions.  Yes, that's 12 -- and getting ridiculous.
Time to backtrack.

The system administrator is ultimately the arbiter of what goes on.  He
supposedly knows what libraries are the best match for his system and
user base, and is also ultimately responsible when things go wrong.

So, I think the best compromise both gives some consistency to the user
across multiple platforms while letting the sysadm tailor the choice of
libraries.  As I envision it there will always exist at least two libraries
-- libplplotf.a and libplplotd.a (actually one of these may be a softlink to
the other, such as on Crays where float==double).  These are then linked to
the libraries that are the best default for the system.

This is then:

(a) consistent -- the user can use libplplotf.a everywhere he goes with
reasonable results.  The one minor pain here is that the linkage may be
different from site to site, (-lX11 for the X driver, and -ltk -ltcl for the
TK driver).  So probably a file called libplplotf.doc should exist with
libplplotf.a that explains the linkage.

(b) flexible -- the system administrator can add as many custom libraries
as desired.  The users can either link against them explicitly or put
a soft-link from the desired library to ~/lib/libplplotf.a.  And you can
change the system default (say, if you change your mind or many people
request it) simply by changing a soft-link (and possibly building a new
library version).

The makefile will make the system administrator's job easier by adopting the
naming scheme mentioned above (something like libplplotfn.a for the library
without Xlib or TK, if I bother to support it).  The exact name doesn't
matter much since you'll be relying on softlinks to set the system defaults,
but it's good to be consistent.

Probably for now I'll just add the two new libraries libplplotftk.a and
libplplotdtk.a on workstations as I had previously planned.  The system
default libplplotf.a could be made to point to these eventually (on dino,
soonest, although I still have to check out the TK driver on Mark's
X-terminal).  On the Cray, I'll leave the system default as-is until I can
check out the TK driver on it.

Does this scheme sound reasonable to everyone?
--
Maurice LeBrun    mjl@dino.ph.utexas.edu
Institute for Fusion Studies, University of Texas at Austin

Faire de la bonne cuisine demande un certain temps.  Si on vous fait
attendre, c'est pour mieux vous servir, et vous plaire.
                                [menu of restaurant Antoine, New Orleans]