From: Alan W. I. <ir...@be...> - 2002-09-30 21:03:52
|
Whenever we make enough significant changes in PLplot (and the current CVS HEAD definitely qualifies on that score in my opinion), then I start thinking about the timing for the next release date. After reviewing what still needs to be done to stabilize/generalize the current changes, I think we are looking at a release date in January at the earliest. I hasten to add that date is not chiseled in stone, and our group is small enough so we have always had a flexible and informal release system (a good thing IMHO). Nevertheless, I hope you keep that tentative date in mind as a motivator to get your changes and bug fixes into PLplot in the next few months. I now give you four lists of the combinations of major, minor, essential, and "would be nice" issues that I feel should be addressed. Feel free to add your favorite issues or your suggestions for changing categories. Also feel free to take on the ones I haven't put my name on (in fact take on the ones I have put my name on as well....;-)) The essential two reasons for bringing these lists of issues to your attention is (1) to help set priorities and (2) to ask for your help in solving the issues. In particular, help with the major, essential release issue of generalizing the Linux library linking scheme would be great, but if you only have a few hours to spare at a time, working on one of the several minor issues would be good as well. Major, essential (1) The major release issue is to get the library linking in good shape cross-platform. So if anybody wants to tackle any of the remaining problems (rationalizing the libraries some more, static drivers on Linux, static libraries on Linux, plus generalization of the Linux solution to cross-platform) that would be great. Unfortunately, just in the wrong time frame from the PLplot perspective my research collaborations have gotten much more intense over the last month or so with other people waiting for me to finish joint papers so it will be at least November before I can take on a large project like the remaining library linking stuff. But I am determined to finish it eventually if nobody else gets it done first. Major, "would be nice" (1) I understand Maurice plans to finish his changes to implement handling strings as strings in the metafile format. (2) Geoffrey plans to at least evaluate remaining fidelity problems. (3) I also hope Geoffrey gets a chance in the next few months (once he gets a break from his current work pressure) to at least look at plframe and the python/Tkinter front end. (4) Parallelogram problem for rotation which is not multiple of 90 deg. This is on the major list because Maurice doesn't think it will be simple to sort this out. Once this problem is sorted out, it should be possible to deal with the remaining rotation problems for the font handling, but I don't think it will be worth tackling those issues before the parallelogram core problem is straightened out. (5) There is still one issue holding back Olof et al from moving to our supported python interface for their pyqt GUI work. They require two output devices (one for the GUI and one to store results more permanently). I just checked that this was possible with -dev tk. I haven't looked at the plframe code that implements this functionality, but I speculate separate devices are opened for two different streams. I have classified this one as "Major, would be nice", but in fact a simple solution following what is done for -dev tk might be possible in which case this should be reclassified as minor, "would be nice" Minor, essential. (1) Some documentation backlog has built up which I would like to deal with before release. (2) If x08.tcl (or any other multi-page example) is executed first, then the first page is skipped. (3) tk cmap1 palette maniupulations no longer work. (4) ./xtk02 -f tk02 invalid command name "Pltkwin" while executing "Pltkwin .plw" (file "tk02" line 48) invoked from within "source tk02" and similarly for tk04. (5) Joao had trouble with cursors in example 1 for SuSe, Maurice does not with RH 7.3. I think I may have the problem (blue cross-hairs appear, but no numbers seem to be typed when you click). How do you generate the error, and what are the exact symptoms, again, Joao, and have you found a fix? (6) Permissions problem with generated plplot-config and plplot-test.sh in plplot/tmp. I don't know the proper autoconf method of fixing this. (7) bindings/tk/plcolor.tcl has execute permissions that should be removed. examples/tcl/stats.log should be made world-readable. Both these permission problems need access to the CVS repository to fix. Minor, "would be nice" (1) I plan to try to adjust our python interface from swig-1.3.1[1-3] to swig-2.0 if that is released before the PLplot release. (2) I have documented on this list many minor memory leaks found by valgrind throughout the dynloader area which should be cleaned up. (3) Finish Java API or else completely reimplement it with swig (which might be a much faster way of solving the problem). (4) debian subdirectory made part of HEAD so can build debs directly from HEAD. (5) fortran, C++, and octave "x" examples made consistent with the C, tcl, Java, and python examples as a test that the various front ends produce the same results. Alan email: ir...@be... 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 __________________________ |
From: <jc...@fe...> - 2002-10-01 13:32:40
|
On Monday 30 September 2002 22:03, Alan W. Irwin wrote: | Whenever we make enough significant changes in PLplot (and the | current CVS HEAD definitely qualifies on that score in my opinion), | then I start thinking about the timing for the next release date. =2E.. | Major, essential | | (1) The major release issue is to get the library linking in good | shape cross-platform. So if anybody wants to tackle any of the | remaining problems (rationalizing the libraries some more, static | drivers on Linux, static libraries on Linux, plus generalization of | the Linux solution to cross-platform) that would be great.=20 | Unfortunately, just in the wrong time frame from the PLplot | perspective my research collaborations have gotten much more intense | over the last month or so with other people waiting for me to finish | joint papers so it will be at least November before I can take on a | large project like the remaining library linking stuff. But I am | determined to finish it eventually if nobody else gets it done first. I start playing with this, but stopped. If my current plans of adding=20 contour lines to plotfc3d() fails, I might restart the attempt.=20 =2E.. | (5) Joao had trouble with cursors in example 1 for SuSe, Maurice does | not with RH 7.3. I think I may have the problem (blue cross-hairs | appear, but no numbers seem to be typed when you click). How do you | generate the error, and what are the exact symptoms, again, Joao, and | have you found a fix? I guess the problem was some incomplete rpm updates in my system. The=20 reported problem has gone without code changes. Joao |
From: Alan W. I. <ir...@be...> - 2002-10-01 17:34:09
|
On Tue, 1 Oct 2002, [iso-8859-1] Jo=E3o Cardoso wrote: > [...] current plans of adding > contour lines to plotfc3d() [...] I hope that effort is successful since I could certainly use that capabilit= y in my own research plots. I will put this as a "would be nice" on the list= =2E > ... > > | (5) Joao had trouble with cursors in example 1 for SuSe, Maurice does > | not with RH 7.3. I think I may have the problem (blue cross-hairs > | appear, but no numbers seem to be typed when you click). How do you > | generate the error, and what are the exact symptoms, again, Joao, and > | have you found a fix? > > I guess the problem was some incomplete rpm updates in my system. The > reported problem has gone without code changes. That's great. I will change the list accordingly. Here is a question for all development team members: Should I put my 4 list= s in the plplot/PROBLEMS file under CVS control? The current PROBLEMS file refers to problems that existed in the 1995 (!) version. AFAIK, none of the mentioned problems exist any more. Alan |
From: <jc...@fe...> - 2002-10-01 19:12:04
|
On Tuesday 01 October 2002 18:33, Alan W. Irwin wrote: =2E.. | Here is a question for all development team members: Should I put my | 4 lists in the plplot/PROBLEMS file under CVS control? The current | PROBLEMS file refers to problems that existed in the 1995 (!) | version. AFAIK, none of the mentioned problems exist any more. | | Alan YES! All reported and confirmed bugs and problems. Then, at release=20 time, its easy to check for them, clearing the solved ones, adding new=20 ones, etc. Joao |
From: Maurice L. <mj...@ga...> - 2002-10-01 21:33:01
|
Alan W. Irwin writes: > Here is a question for all development team members: Should I put my 4 lists > in the plplot/PROBLEMS file under CVS control? The current PROBLEMS file > refers to problems that existed in the 1995 (!) version. AFAIK, none of the > mentioned problems exist any more. Please do. -- Maurice LeBrun mj...@ga... Research Organization for Information Science and Technology of Japan (RIST) |
From: Alan W. I. <ir...@be...> - 2002-10-02 01:37:26
|
On Tue, 1 Oct 2002, Maurice LeBrun wrote: > Alan W. Irwin writes: > > Here is a question for all development team members: Should I put my 4 lists > > in the plplot/PROBLEMS file under CVS control? The current PROBLEMS file > > refers to problems that existed in the 1995 (!) version. AFAIK, none of the > > mentioned problems exist any more. > > Please do. Since Joao and Maurice have been so supportive of this, I did it. Please update PROBLEMS often as you find new bugs, solve old bugs, or introduce or complete new features. Alan |
From: <jc...@fe...> - 2002-10-02 12:52:50
|
On Wednesday 02 October 2002 02:37, Alan W. Irwin wrote: | On Tue, 1 Oct 2002, Maurice LeBrun wrote: | > Alan W. Irwin writes: | > > Here is a question for all development team members: Should I | > > put my 4 lists in the plplot/PROBLEMS file under CVS control?=20 | > > The current PROBLEMS file refers to problems that existed in the | > > 1995 (!) version. AFAIK, none of the mentioned problems exist | > > any more. | > | > Please do. | | Since Joao and Maurice have been so supportive of this, I did it. | | Please update PROBLEMS often as you find new bugs, solve old bugs, or | introduce or complete new features. shouldnt "introduce or complete new features" go to NEWS instead of=20 PROBLEMS? Joao |
From: Alan W. I. <ir...@be...> - 2002-10-02 14:35:35
|
On Wed, 2 Oct 2002, [iso-8859-1] Jo=E3o Cardoso wrote: > shouldnt "introduce or complete new features" go to NEWS instead of > PROBLEMS? Probably a better name for the file is CVS-STATUS. Feel free to change the name to that if you like, but I thought PROBLEMS was a good enough fit because the items concern bugs or missing features. Also my phrasing that you quoted above was unclear. Sorry, let me try agai= n with how I think PROBLEMS and NEWS should be used. Bugs go in PROBLEMS, and if you are actively working on a missing feature you should mention it in PROBLEMS as well. If you fix the bug or implement the feature then remove the item from PROBLEMS. If that success is newsworthy enough report your success in NEWS. Alan |
From: <jc...@fe...> - 2002-10-02 16:11:02
|
On Wednesday 02 October 2002 15:35, Alan W. Irwin wrote: | On Wed, 2 Oct 2002, [iso-8859-1] Jo=E3o Cardoso wrote: | > shouldnt "introduce or complete new features" go to NEWS instead of | > PROBLEMS? | | Probably a better name for the file is CVS-STATUS. Feel free to | change the name to that if you like, but I thought PROBLEMS was a | good enough fit because the items concern bugs or missing features. | | Also my phrasing that you quoted above was unclear. Sorry, let me | try again with how I think PROBLEMS and NEWS should be used. | | Bugs go in PROBLEMS, and if you are actively working on a missing | feature you should mention it in PROBLEMS as well. If you fix the bug | or implement the feature then remove the item from PROBLEMS. If that | success is newsworthy enough report your success in NEWS. | | Alan OK. For me, that as an user often compile from sources, having a NEWS file=20 is helpfull, to see if it is worth to compile/install a new release;=20 also the BUGS is helpfull, to see if a known bug has been solved. From=20 this perspective, the entries in BUGS that are solved should be marked=20 as solved, and not deleted. But I now understand that your intention=20 was only to maintain PROBLEMS as a CVS-STATUS. Joao |
From: Maurice L. <mj...@ga...> - 2002-10-04 08:21:33
|
Alan W. Irwin writes: > (1) The major release issue is to get the library linking in good shape > cross-platform. ... Agreed, 100%. I don't think the release is going anywhere without the linkage problems resolved. Jan for the release is doable, I think we may really need all that time tho. I for one have yet to get my main production code even working with the new plplot under Linux, not to mention the other systems I need to support. I'll put in work on it when I can, although there's features work I'd rather be doing.. :/ > (5) There is still one issue holding back Olof et al from moving to our > supported python interface for their pyqt GUI work. They require two output > devices (one for the GUI and one to store results more permanently). I just > checked that this was possible with -dev tk. I haven't looked at the > plframe code that implements this functionality, but I speculate separate > devices are opened for two different streams. I have classified this one as > "Major, would be nice", but in fact a simple solution following what is done > for -dev tk might be possible in which case this should be reclassified as > minor, "would be nice" I assume you're referring to "the normal plmkstrm/plcpstrm/plreplot/plend1 way of saving plots". Is this kind of stream duplication via API sufficient for their needs? Because otherwise one could clone a stream at the driver interface layer, directing it somewhere else (e.g. a file). I thought about putting in something like this years ago but didn't have a real need for it so it never materialized. -- Maurice LeBrun mj...@ga... Research Organization for Information Science and Technology of Japan (RIST) |
From: Maurice L. <mj...@ga...> - 2002-10-04 08:33:53
|
Maurice LeBrun writes: > Alan W. Irwin writes: > > (5) There is still one issue holding back Olof et al from moving to our > > supported python interface for their pyqt GUI work. They require two output > > devices (one for the GUI and one to store results more permanently). I just > > checked that this was possible with -dev tk. I haven't looked at the > > plframe code that implements this functionality, but I speculate separate > > devices are opened for two different streams. I have classified this one as > > "Major, would be nice", but in fact a simple solution following what is done > > for -dev tk might be possible in which case this should be reclassified as > > minor, "would be nice" > > I assume you're referring to "the normal plmkstrm/plcpstrm/plreplot/plend1 way > of saving plots". Is this kind of stream duplication via API sufficient for > their needs? > > Because otherwise one could clone a stream at the driver interface layer, > directing it somewhere else (e.g. a file). I thought about putting in > something like this years ago but didn't have a real need for it so it never > materialized. After rereading this, I thought this might have been a bit too obscure. The way of saving the current plot mentioned in my first paragraph is atomic, one that you use at the end of a page i.e. "save this page". So it arose in association with the extended plframe for its "save" or "print" commands. It has several problems: - only done at end of page - API or GUI driven -- not automatic - how to deal with end of page -- new file or same file? The cloned stream approach would associate one stream with another, such that every driver interface call to the original stream would go to the cloned stream as well. The appeal of this approach is that it would be virtually continuous, automatic, and you'd have all the standard plplot calls on the cloned stream. It'd also be easy (and fun) to test with the interactive drivers -- you'd just get multiple windows up on the screen, all displaying (theoretically) the same thing. -- Maurice LeBrun mj...@ga... Research Organization for Information Science and Technology of Japan (RIST) |