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 To: plplot_general 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" To: plplot_general 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 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 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 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 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 , 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() (now plcol0() 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 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 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 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 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 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]