From: Geoffrey F. <fu...@ac...> - 2000-05-12 19:28:54
|
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: /ano...@ft...:/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 plp...@pl..., 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 fu...@ac... 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 |
From: Vince D. <vi...@sa...> - 2000-05-17 21:21:00
|
Some time soon I'm going to try to tackle the task of integrating my changes into 5.0. My changes are quite varied, so hopefully I'll be able to split them into a number of separate, independent patches. However, before I start that, I have a couple of questions: (i) Does plplot support building any form of loadable extension for Tcl/Tk? (i.e. a shared library Plxxx50.so which can be loaded into Tcl/Tk via 'load Plxxx50'). (ii) Does plplot support cross-compilation (particularly for a cygwin hosted system to build linux executables)? (iii) Is there any configure/makefile support for non-unix based platforms? cheers, -- Vince p.s. Does plplot 5 fix the 'M = J' bug evident in the standard font library (but not the extended font lib)? |
From: Geoffrey F. <fu...@ac...> - 2000-05-17 21:39:21
|
Vince Darley writes: > Some time soon I'm going to try to tackle the task of integrating my > changes into 5.0. Please remember, new feature development goes on 5.1 (the cvs head). 5.0 is supposed to be a stabilization release, for minor bug fixes. > My changes are quite varied, so hopefully I'll be able > to split them into a number of separate, independent patches. However, > before I start that, I have a couple of questions: > > (i) Does plplot support building any form of loadable extension for > Tcl/Tk? (i.e. a shared library Plxxx50.so which can be loaded into Tcl/Tk > via 'load Plxxx50'). No, not at this time. This is an obviously desirable improvment. > (ii) Does plplot support cross-compilation (particularly for a cygwin > hosted system to build linux executables)? I don't know how to answer that question. I've used cross tools before (for other things). Ordinarily I am accustomed to just using a particular gcc at a cerain path location, or mabye a stock gcc with a special -B or -V option to pick out the cross tool components. To this extent--that is, just asuming your cross tool gcc/binutils are in your path--it should "just work". If you need some more specific kind of support, please elaborate. > (iii) Is there any configure/makefile support for non-unix based > platforms? Historically, Mac, OS/2, DOS/DJGPP and Amiga ports have all been done through a seperate makefile, independent of the unixoid configure at the top of the tree. I've never gotten around to building on NT yet, but if I did, I would start by seeing if the existing configure script would work okay on a cygwin platform. > p.s. Does plplot 5 fix the 'M = J' bug evident in the standard font > library (but not the extended font lib)? I haven't looked into the matter. -- Geoffrey Furnish Actel Corporation fu...@ac... 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 |
From: Vince D. <vi...@sa...> - 2000-05-18 00:24:25
|
On Wed, 17 May 2000, Geoffrey Furnish wrote: > Vince Darley writes: > > Some time soon I'm going to try to tackle the task of integrating my > > changes into 5.0. > > Please remember, new feature development goes on 5.1 (the cvs head). > 5.0 is supposed to be a stabilization release, for minor bug fixes. Sure! I just mean the task of producing sensible patches which you and the rest of the plplot dev. team can decide whether to include or not, at whatever version number is appropriate. > > My changes are quite varied, so hopefully I'll be able > > to split them into a number of separate, independent patches. However, > > before I start that, I have a couple of questions: > > > > (i) Does plplot support building any form of loadable extension for > > Tcl/Tk? (i.e. a shared library Plxxx50.so which can be loaded into Tcl/Tk > > via 'load Plxxx50'). > > No, not at this time. This is an obviously desirable improvment. I'll probably try to create patches first which simply add cross-platform Tk support to Plplot, and later work on adding things like this (since I haven't compiled this code on unix for at least 3 years, my makefiles are probably rather grotty). > > (ii) Does plplot support cross-compilation (particularly for a cygwin > > hosted system to build linux executables)? > > I don't know how to answer that question. I've used cross tools > before (for other things). Ordinarily I am accustomed to just using a > particular gcc at a cerain path location, or mabye a stock gcc with a > special -B or -V option to pick out the cross tool components. To > this extent--that is, just asuming your cross tool gcc/binutils are in > your path--it should "just work". If you need some more specific kind > of support, please elaborate. I mean so I can carry out a complete ./configure ; make on my windoze box, yet have the executables generated work on whatever target I specify (e.g. linux, solaris etc). My simple tests didn't make it clear whether this would really work or not (supposedly Tcl 8.x has a nice cross-compilation ability, but I haven't really used that either). > > (iii) Is there any configure/makefile support for non-unix based > > platforms? > > Historically, Mac, OS/2, DOS/DJGPP and Amiga ports have all been done > through a seperate makefile, independent of the unixoid configure at > the top of the tree. I've never gotten around to building on NT yet, > but if I did, I would start by seeing if the existing configure script > would work okay on a cygwin platform. I tried, and it doesn't look too good (not too bad either, though!). Various problems arose (such as 'gcc not present', even though it is the only compiler which is present). I'll have to see what I can do. I'm not really sure of the best step forward from here! I have a bunch of code which has worked at varying times over the last 5 years on Solaris/MacOS/Windows with various versions of Tk, and is currently in constant use with Tk 8.3.1 on WinNT. However I don't have access to a linux machine I can actually do development on, so I don't really see a sensible path to preparing useful patches without at least some help from someone else: anyone willing to offer their services as a guinea pig? One approach I'm considering is that the core pl code should be compiled into a shared library with the existing makefiles, and that the tcl/tk dependent stuff should use it's own makefiles using the 'TEA' (Tcl Extension Architecture) framework developed by the Tcl community which should make it easy to turn 'C-code + pllibs + Tcl installation' into something which will compile under any platform where Tcl/Tk works. Perhaps this should be step 5, not step 1 however. Advice appreciated! cheers, Vince > > p.s. Does plplot 5 fix the 'M = J' bug evident in the standard font > > library (but not the extended font lib)? > > I haven't looked into the matter. When I run the plplot demos (admittedly on windoze, with my shared lib version of plplot loaded into tcl), I find that in demo 6, looking at the uppercase letters, from 70-80, the sequence is J K L J N, i.e. M has been substituted by J. I actually put together a nice little script one case use to run all the demos from a Tk interface. You'll need to modify the 'package require Plplot' line, but beyond that it should work wherever you can get 'plframe': # RunDemos.tcl #--------------------------------------------------------------------- # Source this file into a working Tk interpreter to run all the demos # this file should be in plplot/examples/tcl/ # # Vince Darley # vi...@sa... # #--------------------------------------------------------------------- lappend auto_path [pwd] package require Plplot plframe .p grid .p -columnspan 5 -sticky news grid rowconfigure . 0 -weight 1 for {set i 0} {$i < 5} {incr i} { grid columnconfigure . $i -weight 1 } # turn on pauses .p cmd plspause 1 button .bexit -text "Quit" -command exit button .bshell -text "Shell" -command "console show" set buttons [list .bexit .bshell] for {set i 1} {$i <= [llength [glob x*.tcl]]} {incr i} { set demo x[format "%02d" $i] button .b$i -text "Demo $i" -command "$demo .p" lappend buttons .b$i if {[llength $buttons] == 5} { eval grid $buttons -sticky ew set buttons {} } } if {[llength $buttons]} { eval grid $buttons -sticky ew } |
From: Geoffrey F. <fu...@ac...> - 2000-05-18 20:13:43
|
Vince Darley writes: > > > My changes are quite varied, so hopefully I'll be able to > > > split them into a number of separate, independent patches. > > > However, before I start that, I have a couple of questions: > > > > > > (i) Does plplot support building any form of loadable > > > extension for Tcl/Tk? (i.e. a shared library Plxxx50.so which > > > can be loaded into Tcl/Tk via 'load Plxxx50'). > > > > No, not at this time. This is an obviously desirable improvment. > > I'll probably try to create patches first which simply add > cross-platform Tk support to Plplot, and later work on adding > things like this (since I haven't compiled this code on unix for at > least 3 years, my makefiles are probably rather grotty). By this to you mean owrk on your "tkwin" driver? > > > (ii) Does plplot support cross-compilation (particularly for a cygwin > > > hosted system to build linux executables)? > > > > I don't know how to answer that question. I've used cross tools > > before (for other things). Ordinarily I am accustomed to just using a > > particular gcc at a cerain path location, or mabye a stock gcc with a > > special -B or -V option to pick out the cross tool components. To > > this extent--that is, just asuming your cross tool gcc/binutils are in > > your path--it should "just work". If you need some more specific kind > > of support, please elaborate. > > I mean so I can carry out a complete ./configure ; make on my windoze box, > yet have the executables generated work on whatever target I specify (e.g. > linux, solaris etc). My simple tests didn't make it clear whether this > would really work or not (supposedly Tcl 8.x has a nice cross-compilation > ability, but I haven't really used that either). Unless you have evidence to the contrary, it is my belief that this is simply a matter of chosing the gcc/binutils (putting them in your path) which generate buidl products for the target environment. The only nit I can think of--is this what you're asking about?--is the issue where configure runs little test compiles to try to psychoanalyze the system. In some cases it only tries to /compile/ things, but perhaps there are cases where it also tries to run the resulting executable. That would be a problem. I don't know if there are cases where PLplot's configure script does or not. If you find that there are, I would be willing to try to help you develop ways to circumvent this. > > > (iii) Is there any configure/makefile support for non-unix based > > > platforms? > > > > Historically, Mac, OS/2, DOS/DJGPP and Amiga ports have all been done > > through a seperate makefile, independent of the unixoid configure at > > the top of the tree. I've never gotten around to building on NT yet, > > but if I did, I would start by seeing if the existing configure script > > would work okay on a cygwin platform. > > I tried, and it doesn't look too good (not too bad either, though!). > Various problems arose (such as 'gcc not present', even though it is the > only compiler which is present). I'll have to see what I can do. Well, the overall autoconf mechanism is certainly known to work on cygwin. All the GNU file and text utils that come with cygwin are done that way for one thing. Also, XEmacs works the same way (using an autoconf-generated configure script). So it definitely can be done. If there are shortcomings in PLplot's configure script, they probably arise from the non-existence of NT cases in the various switch blocks in plplot/cf/sysloc.cf and sysconf.cf. I think it shouldn't really be too hard to just visually scan that file and see what is missing/wrong for NT. I have an NT box here at Actel, I just never use it... :-). > I'm not really sure of the best step forward from here! I have a bunch of > code which has worked at varying times over the last 5 years on > Solaris/MacOS/Windows with various versions of Tk, and is currently in > constant use with Tk 8.3.1 on WinNT. However I don't have access to a > linux machine I can actually do development on, so I don't really see a > sensible path to preparing useful patches without at least some help from > someone else: anyone willing to offer their services as a guinea pig? My suggestions: Get a cvs client for NT. I have one on my little-used NT box here. I forget where I got it. I either compiled it myself, or perhaps I got it from one of the various NT unix-goods stockpile sites. There is somebody who has XEmacs, X11, etc, maybe I got it from there. Anyway, once you have your NT cvs client, you can do an anonymous checkout of the plplot sources from cvs.plplot.org, straight to your NT box. Hack that code to your liking, then run cvs diff, and send in the patches. In this mechanical respect, I don't think working on NT is much different from unix. I have certainly been able to successfully make similar fixes to Actel code from my NT box here. > One approach I'm considering is that the core pl code should be compiled > into a shared library with the existing makefiles, and that the tcl/tk > dependent stuff should use it's own makefiles using the 'TEA' (Tcl > Extension Architecture) framework developed by the Tcl community which > should make it easy to turn 'C-code + pllibs + Tcl installation' into > something which will compile under any platform where Tcl/Tk works. > Perhaps this should be step 5, not step 1 however. Advice appreciated! I am definitely in favor of a TEA-based approach. As it happens, I downloaded the TEA docs that I could find just last week, and was starting to look into that myself before I became distracted. Not sure when I could return to it myself at this point, but I definitely agree that this is the desired plan of attack. -- Geoffrey Furnish Actel Corporation fu...@ac... 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 |
From: Phil A. <ph...@ge...> - 2000-05-18 20:28:59
|
Geoffrey Furnish writes: > My suggestions: > > Get a cvs client for NT. I have one on my little-used NT box here. I > forget where I got it. I either compiled it myself, or perhaps I got > it from one of the various NT unix-goods stockpile sites. There is > somebody who has XEmacs, X11, etc, maybe I got it from there. > For pointers on the compilation, check out two links at: http://www.hirmke.de/software/develop/gnuwin32/cygwin/ porters/Hirmke_Michael/GNUWin32-links.html : http://www.hirmke.de/software/develop/gnuwin32/cygwin/ porters/Wilson_Charles_S/V1.1/cvs-1.10/cvs-1.10-1-cygwin1.1.README http://www.hirmke.de/software/develop/gnuwin32/cygwin/ porters/van_Woerkom_Marc_E_E/cvs-1.10-cygwin.README Phil |
From: Vince D. <vi...@sa...> - 2000-05-20 01:06:01
|
Making progress on breaking out my changes. The first step seems to be to get something with Tcl/plplot to build properly using the TEA framework for Tcl extensions. On that front I've prepared the necessary configure.in/makefile.in which allow the 'Matrix' piece of Plplot to be compiled as a standalone Tcl extension (shared library which can be loaded into Tcl, via 'load' or 'package require Matrix'). The necessary changes are tiny (but more will be required when I begin to tackle the real pl-tcl and pl-tk parts of plplot). However it would be useful if someone could verify that this actually works on some unix platform (it works fine on Windows under cygwin). All that should be required is: autoconf ./configure make make install And then in a tcl or tk shell, try package require Matrix which should return '0.1' and make the 'matrix' command available. The only complication to the above is that you might need to specify some directories to './configure'. This is documented in a readme in my changes. If you'd like to try, please grab 'pltcl.patch' and 'tcltk.tar.gz' from ftp://ftp.ucsd.edu/pub/alpha/tcl/extensions/ (please ignore the other plplot related stuff in there!) 'pltcl.patch' is a cvs-extracted diff to be applied to the files in bindings/tcl (very minor changes to plplot 5.1 from cvs) 'tcltk.tar.gz' is a NEW directory, to be placed alongside bindings/tcl and bindings/tk. The idea is that it will contain the TEA compliant configure/makefile stuff to build Tcl/Tk extensions using the source code in the rest of plplot. There is a readme in that directory. I stress: this works 'out of the box' in cygwin, and ought to (if the TEA designers got it right) work similarly on unix. You will need a reasonably modern version of Tcl/Tk installed (e.g. 8.1-8.3). The resulting shared library should be loadable into _any_ Tcl release 8.1 or newer. cheers, -- Vince <http://www.santafe.edu/~vince> |
From: Vince D. <vi...@sa...> - 2000-05-20 02:36:04
|
For the more ambitious, I've now added 'pltcltk.tar.gz' to that same ftp directory (and a slightly updated pltcl.patch). 'pltcltk.tar.gz' is another TEA directory which can compile all of plplot's 'tcl' 'src' and 'drivers' directories (well, not all the drivers), and link everything into a 'Pltcl' shared library which you can load into Tcl. Again, 'autoconf, configure, make, make install' should allow you to do 'package require Pltcl' from inside a tcl shell. This code uses the headers in 'tmp' generates by the standard Plplot configuration. I don't yet know how to compile TEA compliant Tk extensions (my real goal),... cheers, -- Vince <http://www.santafe.edu/~vince> |
From: Vince D. <vi...@sa...> - 2000-05-20 07:54:54
|
With some help from some scriptics folk, I have a Plplot-tk more or less working. You can grab all of this stuff from: ftp://ftp.ucsd.edu/pub/alpha/tcl/extensions/plplot/ pltcl.patch -- minor patch to bindings/tcl pltk.patch -- minor patch to bindings/tk tcltk.tar.gz -- config/make files for 'Matrix' shared lib pltcltk.tar.gz -- config/make files for Pltcl shared lib pltk.tar.gz -- config/make files for Pltk shared lib. Readme.txt -- brief description. Untar any one of the .tar.gz archives into 'bindings', cd into there and type: autoconf ./configure (possibly with some flags) make make install and they should work. Once this stuff seems to work I can integrate my source code changes with a fair confidence that they won't break things. -- Vince <http://www.santafe.edu/~vince> |