From: <hba...@ma...> - 2006-03-23 03:27:29
|
On Mar 22, 2006, at 1:58 PM, Alan W. Irwin wrote: > willing to step forward to manage that release process? By a nasty > coincidence all three former release managers (including me) cannot > contribute much to PLplot for at least the next 6 months because of > other > commitments of our time so we really do need another volunteer to step > forward to take responsibility for the release. I'll volunteer. I don't have the time immediately, but I should be able to start on it in about 2 weeks. best, -Hazen |
From: Hazen B. <hba...@ma...> - 2006-04-04 00:56:15
|
On Apr 3, 2006, at 6:25 PM, mj...@br... wrote: >> d) the xform example function? It doesn't seem to be exported, but it >> is listed in plplot.h. > > That clearly had something to do with utils/xform.c. I think it > was part of > the library at one time that got excised & relegated to an example, > but the > decl remained behind. Seems kinda bogus. Ok, I'll remove this unless anyone objects. >> Finally I'd like to get some thoughts on what is probably a fairly >> major change for the next version. My proposal is to change plexit() >> so that you could, via the optional user exit handler, set plexit() >> so that it did not in fact call exit(). Trapping this exit() call is >> not easy in all languages (any?) and is a bit of a pain when you are >> trying to use plplot from another program as it will also cause that >> program to exit as well. However, I can also see that there might be >> a fair number of things that were counting on plexit() to exit that >> might be surprised to still be running. > > Already there, use plsexit() to provide an exit handler. You can > use it to do > whatever custom exit handling you need then return to let to let > plplot exit > normally, or just never return to preempt the exit entirely. I was concerned that not returning from this call would leave plplot in a bit of nebulous state, but I guess I should just try and see what happens. Thanks! -Hazen |
From: <mj...@br...> - 2006-04-04 09:18:28
|
Hazen Babcock writes: > > On Apr 3, 2006, at 6:25 PM, mj...@br... wrote: > > Already there, use plsexit() to provide an exit handler. You can > > use it to do > > whatever custom exit handling you need then return to let to let > > plplot exit > > normally, or just never return to preempt the exit entirely. > > I was concerned that not returning from this call would leave plplot > in a bit of nebulous state, but I guess I should just try and see > what happens. Thanks! Well, it might. :) An error serious enough to quit out was generated, after all. But in a multi plotting widget GUI app, one at least has the option to catch the error & forget about that plplot stream as it might be toast, and start using another one. Sure there will be memory loss & possibly files left open but from a usability standpoint it's nice to have the option to ignore the error and continue in some restricted and/or alternate way. That said, there probably is room for some effort in categorizing the various plexit's used by the code into recoverable vs nonrecoverable, and doing some sanity restoration work on the recoverable variants. Seems like a significant amount of work tho. -- Maurice LeBrun mj...@br... |
From: Alan W. I. <ir...@be...> - 2006-03-23 06:01:37
|
On 2006-03-22 22:27-0500 hba...@ma... wrote: > > On Mar 22, 2006, at 1:58 PM, Alan W. Irwin wrote: > >> willing to step forward to manage that release process? By a nasty >> coincidence all three former release managers (including me) cannot >> contribute much to PLplot for at least the next 6 months because of other >> commitments of our time so we really do need another volunteer to step >> forward to take responsibility for the release. > > I'll volunteer. I don't have the time immediately, but I should be able to > start on it in about 2 weeks. Excellent news, indeed. Thanks, Hazen, for volunteering to do this. Alan __________________________ Alan W. Irwin email: ir...@be... phone: 250-727-2902 Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); PLplot scientific plotting software package (plplot.org); the Yorick front-end to PLplot (yplot.sf.net); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ |
From: <hba...@ma...> - 2006-03-30 03:16:43
|
Questions: 1. Version number? 5.5.4? 2. What versions of autotools should I use? As I recall there were some issues with this last time around. I'm going to build plplot on a Debian box, if that makes any difference. 3. What has changed that we haven't documented? Besides a new driver (wxwidgets), have there been other changes that should make it into the release notes / documentation? 4. Lately I've been working on Lisp bindings for plplot & have been spending a fair amount of time reading plplot.h & plplot-5.5.3.pdf. In so doing, I've noticed a few things that might be better documented: a) plmap & plmeridians, these are pretty easy to use but they might be worth a few words in plplot.pdf. b) plfshade, it looks like a function for making shade plots of functions but it isn't very clear what sorts of arguments that it expects. Does anyone have an example of it in use? c) plsfile, should the file pointer be a pointer to a "binary" file or an "ascii" file? Does it matter? d) the xform example function? It doesn't seem to be exported, but it is listed in plplot.h. I can fill in the documentation for (a), but I'll need some help with b,c & d. Despite not knowing much at all about what I'm doing, I hope to get the release out by the end of April at the latest. I will start this weekend, so please commit any last minute changes soon. Finally I'd like to get some thoughts on what is probably a fairly major change for the next version. My proposal is to change plexit() so that you could, via the optional user exit handler, set plexit() so that it did not in fact call exit(). Trapping this exit() call is not easy in all languages (any?) and is a bit of a pain when you are trying to use plplot from another program as it will also cause that program to exit as well. However, I can also see that there might be a fair number of things that were counting on plexit() to exit that might be surprised to still be running. best, -Hazen |
From: Alan W. I. <ir...@be...> - 2006-03-30 07:46:21
|
On 2006-03-29 22:16-0500 hba...@ma... wrote: > > Questions: > 1. Version number? 5.5.4? This depends mostly on what naming convention you want to use during the time that you will be the release manager. The 5.5.3 tarball has been downloaded more than 6000 times (a new record) with very few bugs found by all those users. So although it has been advertised as one of a series of development releases leading up to our next stable release of 5.6.0, in fact, it already is a stable release (or at least as stable as anything that we have released before). However, if you want to stick with the current advertised convention, then calling the next (presumably stable) release 5.6.0 is the correct thing to do. > 2. What versions of autotools should I use? As I recall there were some > issues with this last time around. I'm going to build plplot on a Debian > box, if that makes any difference. After 5.5.3, Geoffrey had problems replicating results I obtained on my system, and it turned out to be due to version inconsistencies between patched Debian autotools (used both on my system and for the release tarball) and his autotools versions. I want to avoid such misunderstandings in the future so I think from now on we should use versions everybody has access to. Thus, I recommend using the latest unpatched stable autotools versions released from http://ftp.gnu.org/gnu/. Currently, those are http://ftp.gnu.org/gnu/autoconf/autoconf-2.59.tar.gz, http://ftp.gnu.org/gnu/automake/automake-1.9.6.tar.gz, and http://ftp.gnu.org/gnu/libtool/libtool-1.5.22.tar.gz. I haven't built these particular versions, but in the past when I have done builds from previous versions it was completely straightforward. You simply have to build and install in the order autoconf, automake, then libtool, use a common install prefix for all of them, and make sure that $prefix/bin was (first) on your PATH so there is no interference with the build and install process from the installed distro versions of the autotools. (Better yet, to really make sure there is no interference, purge the installed distro versions from your system before building the autotools.) You could use the default /usr/local for $prefix, but I prefer a special install prefix (e.g., /usr/local/autotools) unique to the autotools. If you could please save the output of cf/bootstrap.sh (which completely describes the autotools versions used) in the release notes, then there will be no ambiguity about what autotools versions were used to create the release tarball, and it should be straightforward for any developer to replicate the release tarball from the cvs version of date. > 3. What has changed that we haven't documented? Besides a new driver > (wxwidgets), have there been other changes that should make it into the > release notes / documentation? It has been so long since the last release, I doubt anybody can remember. Part of the release process is to generate a ChangeLog automatically from the cvs commit messages. For example, I used to do this with the cvs2cl -l "-d< today" --stdout > ChangeLog.test command, although there may be a better method to do that now that Rafael or Tom Duck (the two release managers after me) can recommend. Anyhow, I would scan through the automatically generated ChangeLog to see what has been done in detail since 5.5.3, then do a grand summary (in a sentence or so per important change) in README.release. Hope these responses to your questions help and good luck with the release. Alan __________________________ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); PLplot scientific plotting software package (plplot.org); the Yorick front-end to PLplot (yplot.sf.net); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ |
From: <hba...@ma...> - 2006-04-03 03:05:57
|
On Mar 30, 2006, at 2:46 AM, Alan W. Irwin wrote: > we have released before). However, if you want to stick with the > current > advertised convention, then calling the next (presumably stable) > release > 5.6.0 is the correct thing to do. Ok. 5.6.0 it is. > If you could please save the output of cf/bootstrap.sh (which > completely > describes the autotools versions used) in the release notes, then > there will > be no ambiguity about what autotools versions were used to create the > release tarball, and it should be straightforward for any developer to > replicate the release tarball from the cvs version of date. Sure. This reminds that there was some discussion about whether the release notes should just cover the current version, or whether they should also have the previous versions release notes appended. Was that resolved? > Part of the release process is to generate a ChangeLog > automatically from > the cvs commit messages. For example, I used to do this with the > cvs2cl -l > "-d< today" --stdout > ChangeLog.test command, although there may be a Ok. Unfortunately developer CVS access at Sourceforge is currently down so I didn't make much headway this weekend beyond figuring out how to build the documentation. -Hazen |
From: Alan W. I. <ir...@be...> - 2006-04-03 04:58:30
|
On 2006-04-02 23:05-0400 hba...@ma... wrote: > > On Mar 30, 2006, at 2:46 AM, Alan W. Irwin wrote: > >> we have released before). However, if you want to stick with the current >> advertised convention, then calling the next (presumably stable) release >> 5.6.0 is the correct thing to do. > > Ok. 5.6.0 it is. > >> If you could please save the output of cf/bootstrap.sh (which completely >> describes the autotools versions used) in the release notes, then there >> will >> be no ambiguity about what autotools versions were used to create the >> release tarball, and it should be straightforward for any developer to >> replicate the release tarball from the cvs version of date. > > Sure. This reminds that there was some discussion about whether the release > notes should just cover the current version, or whether they should also have > the previous versions release notes appended. Was that resolved? Yes. One section of README.release has changes relative to our last developmental release, PLplot-5.5.3 while another has overall changes relative to our last stable release, PLplot-5.3.1. I think if we do development releases in the future, we should use that two-track system again. However, for now since this release is stable, I think you can drop the first section (which presumably only includes redundant information with the second section) and simply state the overall changes since our last stable release, PLplot-5.3.1. > >> Part of the release process is to generate a ChangeLog automatically from >> the cvs commit messages. For example, I used to do this with the cvs2cl >> -l >> "-d< today" --stdout > ChangeLog.test command, although there may be a > > Ok. Unfortunately developer CVS access at Sourceforge is currently down so I > didn't make much headway this weekend beyond figuring out how to build the > documentation. I remember just how difficult it used to be to build the documentation so I am pleased it is so much easier now. From the sourceforge status page it looks like the cvs issue is due to hardware troubles. Hopefully, they will get it straightened out in a hurry since there an awful lot of projects (including PLplot) that depend on that system. Alan __________________________ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); PLplot scientific plotting software package (plplot.org); the Yorick front-end to PLplot (yplot.sf.net); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ |
From: Arjen M. <arj...@wl...> - 2006-04-03 07:00:34
|
>> >> Ok. Unfortunately developer CVS access at Sourceforge is currently >> down so I didn't make much headway this weekend beyond figuring out >> how to build the documentation. > > > I remember just how difficult it used to be to build the documentation > so I > am pleased it is so much easier now. > >> From the sourceforge status page it looks like the cvs issue is due to > > hardware troubles. Hopefully, they will get it straightened out in a > hurry > since there an awful lot of projects (including PLplot) that depend on > that > system. Where did you find that information? I tried to look up a page about it, but could not find anything. (One might think they would send an email out to all those developers to keep them up-to-date or perhaps show it in a more conspicuous location or else I have missed it altogether!) Regards, Arjen |
From: Alan W. I. <ir...@be...> - 2006-04-03 15:07:50
|
On 2006-04-03 08:56+0200 Arjen Markus wrote: >>> From the sourceforge status page it looks like the cvs issue is due to >> >> hardware troubles. Hopefully, they will get it straightened out in a >> hurry >> since there an awful lot of projects (including PLplot) that depend on >> that >> system. > > Where did you find that information? I tried to look up a page about it, > but could not find anything. (One might think they would send an email > out to all those developers to keep them up-to-date or perhaps show it > in a more conspicuous location or else I have missed it altogether!) > > Regards, > > Arjen Click on the "get support" link that appears at the bottom right of virtually every SF page. Then click on the Site Status page link that appears in the last paragraph. ==> http://sourceforge.net/docs/A04/ This particular route to finding this link is not obvious, but as far as I know this is the only current way to find it (if you don't bookmark it). This morning's expanded report on the CVS status sounds like it is going to take quite an effort to restore service, and they are taking this opportunity to do some reorganization to eliminate the single point of failure that caused the current outage. Maurice, is your cvs backup viable, i.e., can you do a cvs checkout from it? It would probably be worthwhile to do a comparison between that checkout and a checkout from SF (using "diff -Naur" between the two source trees) once they restore service. Alan __________________________ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); PLplot scientific plotting software package (plplot.org); the Yorick front-end to PLplot (yplot.sf.net); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ |
From: <mj...@br...> - 2006-04-03 21:58:35
|
Alan W. Irwin writes: > This morning's expanded report on the CVS status sounds like it is going to > take quite an effort to restore service, and they are taking this > opportunity to do some reorganization to eliminate the single point of > failure that caused the current outage. Maurice, is your cvs backup viable, > i.e., can you do a cvs checkout from it? It would probably be worthwhile to > do a comparison between that checkout and a checkout from SF (using "diff > -Naur" between the two source trees) once they restore service. I have it, the whole project repo in a tar.bz2 file: -rw-r--r-- 1 root root 8210254 Mar 22 16:39 plplot-cvsroot.20060402.tar.bz2 (my last weekly backup, but the daily is the same since there haven't been any commits recently, at least none that have shown up). I'll see if anything changes after service is restored. -- Maurice LeBrun mj...@br... |
From: <mj...@br...> - 2006-04-03 22:06:42
|
Alan W. Irwin writes: > On 2006-04-02 23:05-0400 hba...@ma... wrote: > > Sure. This reminds that there was some discussion about whether the release > > notes should just cover the current version, or whether they should also have > > the previous versions release notes appended. Was that resolved? > > Yes. One section of README.release has changes relative to our last > developmental release, PLplot-5.5.3 while another has overall changes > relative to our last stable release, PLplot-5.3.1. I think if we do > development releases in the future, we should use that two-track system > again. However, for now since this release is stable, I think you can drop > the first section (which presumably only includes redundant information with > the second section) and simply state the overall changes since our last > stable release, PLplot-5.3.1. I would also like to see the old ones archived somewhere instead of just deleted. Sure you can get to old copies by cvs but that's always convenient. It's all written already.. just needs to be copied into an archive file.. provides a nice history of what was done for what release. -- Maurice LeBrun mj...@br... |
From: Alan W. I. <ir...@be...> - 2006-04-04 01:30:05
|
On 2006-04-03 17:06-0500 mj...@br... wrote: > I would also like to see the old ones archived somewhere instead of just > deleted. Sure you can get to old copies by cvs but that's always convenient. > It's all written already.. just needs to be copied into an archive > file.. provides a nice history of what was done for what release. Just to remind those on list not familiar with the process, for the releases early in the 5.x series, the release notes were written exclusively by the release manager, but recently to reduce R.M. load we have been working on them together by using the README.release file under CVS control. Those recent release notes are written into each release tarball so they can always be recreated from that or cvs. Finally, those release notes are also uploaded separately as part of the file release process and archived at http://sourceforge.net/project/showfiles.php?group_id=2915&package_id=2865 (click on the various notes links to see what we have). Apparently, those go back to the era when the release manager was writing the release notes so that archive is actually probably our most historically complete one for the release notes from the 5.x series. Maurice, does that archive satisfy your needs or is there some additional archive format for the release notes that you want the RM to maintain? Alan __________________________ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); PLplot scientific plotting software package (plplot.org); the Yorick front-end to PLplot (yplot.sf.net); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ |
From: <mj...@br...> - 2006-04-04 09:21:05
|
Alan W. Irwin writes: > On 2006-04-03 17:06-0500 mj...@br... wrote: > > > I would also like to see the old ones archived somewhere instead of just > > deleted. Sure you can get to old copies by cvs but that's always convenient. > > It's all written already.. just needs to be copied into an archive > > file.. provides a nice history of what was done for what release. > > Just to remind those on list not familiar with the process, for the releases > early in the 5.x series, the release notes were written exclusively by the > release manager, but recently to reduce R.M. load we have been working on > them together by using the README.release file under CVS control. Those > recent release notes are written into each release tarball so they can > always be recreated from that or cvs. Finally, those release notes are also > uploaded separately as part of the file release process and archived at > http://sourceforge.net/project/showfiles.php?group_id=2915&package_id=2865 > (click on the various notes links to see what we have). Apparently, those > go back to the era when the release manager was writing the release notes so > that archive is actually probably our most historically complete one for the > release notes from the 5.x series. > > Maurice, does that archive satisfy your needs or is there some additional > archive format for the release notes that you want the RM to maintain? Well, I was thinking of a simple archival file that contains all the old release notes, something one could grep through & browse offline if so desired. Just cat <current_release_notes> >> <archival_file> & cvs commit, prior to overwriting <current_release_notes>. Couldn't get much simpler. -- Maurice LeBrun mj...@br... |
From: Alan W. I. <ir...@be...> - 2006-04-04 17:56:04
|
On 2006-04-04 04:20-0500 mj...@br... wrote: > Alan W. Irwin writes: > > Maurice, does that archive satisfy your needs or is there some additional > > archive format for the release notes that you want the RM to maintain? > > Well, I was thinking of a simple archival file that contains all the old > release notes, something one could grep through & browse offline if so > desired. Just > > cat <current_release_notes> >> <archival_file> > > & cvs commit, prior to overwriting <current_release_notes>. Couldn't get much > simpler. That sounds like a reasonable plan to me. However, I am sure you will agree we want to reduce the load on the RM as much as possible. Therefore, will you do the work of starting up this idea by wgetting all the non-vacant 5.x series release notes from SF and doing all the appropriate cats and cvs commits? Once that is done just the way you like it (for example, you may decide to put the release notes in reverse chronological order into the file so the latest is on top and you may want to include some separator between each release entry), then the on-going work for the RM to continue the scheme should be minimal. Along these same lines of making the new RM's job easier, Tom, would you be willing to share your latest notes of the release process with Hazen? That is probably a file we should have under CVS control as well. Alan __________________________ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); PLplot scientific plotting software package (plplot.org); the Yorick front-end to PLplot (yplot.sf.net); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ |
From: <hba...@ma...> - 2006-04-07 02:30:15
|
On Apr 4, 2006, at 1:55 PM, Alan W. Irwin wrote: > Along these same lines of making the new RM's job easier, Tom, > would you be > willing to share your latest notes of the release process with > Hazen? That > is probably a file we should have under CVS control as well. This would be very helpful. So far I have: 1) Generate the configure file using autotools. 2) Finalize & build the documentation. 3) Create README.release for the new release. I'm unclear on whether this is changes since the last release (i.e. 5.5.3) or since the last stable release (which was?). 4) Add (Append?) current release notes onto a to be created record of past release notes. Do we have a name for this file? Maybe ChangeLog? The current file name ChangeLog seems to date from 2003... I don't mind creating this file for the 5x series of releases if I can get the following info 1) what order (i.e. most recent first or oldest first?) 2) the cvs command to get older versions of files is? 5) Tar everything together for people to download and check over prior to releasing it on Sourceforge. Anything else? best, -Hazen |
From: <mj...@br...> - 2006-04-03 22:25:35
|
hba...@ma... writes: > > Questions: > 4. Lately I've been working on Lisp bindings for plplot & have been > spending a fair amount of time reading plplot.h & plplot-5.5.3.pdf. > In so doing, I've noticed a few things that might be better documented: > c) plsfile, should the file pointer be a pointer to a "binary" file > or an "ascii" file? Does it matter? Doesn't matter on *ix. On systems where maybe it does matter, it should match the type of the output file. So binary for most, but e.g. ps is text. > d) the xform example function? It doesn't seem to be exported, but it > is listed in plplot.h. That clearly had something to do with utils/xform.c. I think it was part of the library at one time that got excised & relegated to an example, but the decl remained behind. Seems kinda bogus. > Finally I'd like to get some thoughts on what is probably a fairly > major change for the next version. My proposal is to change plexit() > so that you could, via the optional user exit handler, set plexit() > so that it did not in fact call exit(). Trapping this exit() call is > not easy in all languages (any?) and is a bit of a pain when you are > trying to use plplot from another program as it will also cause that > program to exit as well. However, I can also see that there might be > a fair number of things that were counting on plexit() to exit that > might be surprised to still be running. Already there, use plsexit() to provide an exit handler. You can use it to do whatever custom exit handling you need then return to let to let plplot exit normally, or just never return to preempt the exit entirely. -- Maurice LeBrun mj...@br... |