From: Alan W. I. <ir...@be...> - 2007-09-24 22:38:39
|
Andrew (Ross) and Hazen, there are some questions for you below. To help with the process of nailing down the date of the stable release, I thought it would be worthwhile to summarize the PLplot issues that have recently been mentioned on list. 1. Second-page problem for gd.c where the letters became blurry and certain lines completely disappeared. 2. plptex3 issue with the interpretation of the sign of the just parameter for Hershey fonts (but modern fonts are fine). Shown by second and third pages of example 28 when using Hershey fonts. 3. plptex3 transformation issues (shown by first page of example 28). 4. replace -dev png with -dev pngcairo in script to generate website examples. 5. Incompatibilities between recent versions of octave and our octave interface. 6. Bounding box issues with the cairo devices. 7. More Ada examples. Here are my comments/questions about each of these issues. 1. Andrew (Roach) has fixed this issue. 2. and 3. Hazen is looking at these issues. Hazen, once you are finished with that evaluation could you comment on what you think is possible before the stable release? 4. I will take responsibility for this issue but, Hazen, I would like you to test my changes fairly soon after I make then so please get in touch off list about a mutually convenient day for working on this issue. 5. The octave interface works fine for me on Debian sarge (oldstable) with octave 2.1.69. I don't know whether it works for the version 2.1.73-13 of octave (which is part of Debian stable, testing, and unstable versions) and various 2.9.x versions of octave on Debian stable, testing, and unstable. >From Orion's Fedora results I assume 2.9.x is currently problematic on all Debian versions. Andrew (Ross), since you are our octave expert could you comment on the octave version problem and the best way you think we should solve it? This is fairly urgent because PLplot is the only free software plotting package available for octave. (There is also gnuplot still available in Debian, but it's long-term feature in Debian is in doubt because the developers there are beginning to realize that gnuplot is not free software.) 6. Hazen and I have discussed a possible solution for this issue, but I have no time to work on that solution before the release. Also, delay/benign neglect is probably a good strategy in this case because there is a possibility of a new API in cairo which will make this issue much easier to deal with. 7. I have recently committed some new Ada examples by Jerry, but my understanding is he may be able to implement even more Ada examples depending on his time constraints and exactly when the stable release occurs. To summarize the above, there are still some on-going issues that have been brought up recently on the list, but whether they are resolved or not before the stable release is completely up to the individuals involved (except for issue 1 which has been fixed and issue 4 where I have firm plans to deal with it). Please comment if there is anything I missed or you have an update on what you would like to do before the stable 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 libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ |
From: Andrew R. <and...@us...> - 2007-09-25 17:11:44
|
Sorry for my silence over the last couple of weeks, but I've been snowed under at work. Plplot works fine with all 2.1.xx versions of octave I have tried. It certainly works fine with 2.1.73 on Ubuntu feisty. It does not work on octave 2.9.x. I've tried 2.9.9 on Ubuntu feisty. This is a different version to that tested by other users. More worryingly I seem to have different errors to other reports on the list. Various things seem to have changed which will require rewriting some of the octave parts of the bindings. I have been pondering the best way of doing this in a compatible manner. It might be cleanest to have different versions of the bindings depending on the octave version. I am sure I can sort this, but I'm not sure of the timeframe. It's personally important to me, so I will try to devote some time to it. How long are we looking at until the release? There is also a psttf.c issue Alan reported to me recently which I would like to look into before the release. Andrew On Mon, Sep 24, 2007 at 03:36:58PM -0700, Alan Irwin wrote: > Andrew (Ross) and Hazen, there are some questions for you below. > > To help with the process of nailing down the date of the stable release, I > thought it would be worthwhile to summarize the PLplot issues that have > recently been mentioned on list. > > 1. Second-page problem for gd.c where the letters became blurry and > certain lines completely disappeared. > > 2. plptex3 issue with the interpretation of the sign of the just parameter > for Hershey fonts (but modern fonts are fine). Shown by second and > third pages of example 28 when using Hershey fonts. > > 3. plptex3 transformation issues (shown by first page of example 28). > > 4. replace -dev png with -dev pngcairo in script to generate website > examples. > > 5. Incompatibilities between recent versions of octave and our octave > interface. > > 6. Bounding box issues with the cairo devices. > > 7. More Ada examples. > > Here are my comments/questions about each of these issues. > > 1. Andrew (Roach) has fixed this issue. > > 2. and 3. Hazen is looking at these issues. Hazen, once you are finished > with that evaluation could you comment on what you think is possible before > the stable release? > > 4. I will take responsibility for this issue but, Hazen, I would like you to > test my changes fairly soon after I make then so please get in touch off > list about a mutually convenient day for working on this issue. > > 5. The octave interface works fine for me on Debian sarge (oldstable) with > octave 2.1.69. I don't know whether it works for the version 2.1.73-13 of > octave (which is part of Debian stable, testing, and unstable versions) and > various 2.9.x versions of octave on Debian stable, testing, and unstable. > >From Orion's Fedora results I assume 2.9.x is currently problematic on all > Debian versions. Andrew (Ross), since you are our octave expert could you > comment on the octave version problem and the best way you think we should > solve it? This is fairly urgent because PLplot is the only free software > plotting package available for octave. (There is also gnuplot still > available in Debian, but it's long-term feature in Debian is in doubt > because the developers there are beginning to realize that gnuplot is not > free software.) > > 6. Hazen and I have discussed a possible solution for this issue, but I have > no time to work on that solution before the release. Also, delay/benign > neglect is probably a good strategy in this case because there is a > possibility of a new API in cairo which will make this issue much easier to > deal with. > > 7. I have recently committed some new Ada examples by Jerry, but my > understanding is he may be able to implement even more Ada examples > depending on his time constraints and exactly when the stable release > occurs. > > To summarize the above, there are still some on-going issues that have been > brought up recently on the list, but whether they are resolved or not before > the stable release is completely up to the individuals involved (except for > issue 1 which has been fixed and issue 4 where I have firm plans to deal > with it). > > Please comment if there is anything I missed or you have an update on > what you would like to do before the stable 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 libLASi project (unifont.org/lasi); the Loads of > Linux Links project (loll.sf.net); and the Linux Brochure Project > (lbproject.sf.net). > __________________________ > > Linux-powered Science > __________________________ > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2005. > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > _______________________________________________ > Plplot-devel mailing list > Plp...@li... > https://lists.sourceforge.net/lists/listinfo/plplot-devel > |
From: Alan W. I. <ir...@be...> - 2007-09-25 20:00:59
|
On 2007-09-25 18:11+0100 Andrew Ross wrote: > > Sorry for my silence over the last couple of weeks, but I've been snowed > under at work. No problem. I have a lot of calls on my time as well at the moment which is why my current PLplot contributions are limited to extremely short projects (such as testing changes done by others) that I can just squeeze in. > > Plplot works fine with all 2.1.xx versions of octave I have tried. It > certainly works fine with 2.1.73 on Ubuntu feisty. According to http://www.gnu.org/software/octave/download.html, 2.1.73 is now considered to be the stable version of octave with no further changes contemplated in the 2.1.x series so I am really glad that you have confirmed our current octave bindings work for that case. > It does not work on > octave 2.9.x. I've tried 2.9.9 on Ubuntu feisty. This is a different > version to that tested by other users. More worryingly I seem to have > different errors to other reports on the list. Various things seem to > have changed which will require rewriting some of the octave parts of > the bindings. I have been pondering the best way of doing this in a > compatible manner. It might be cleanest to have different versions of the > bindings depending on the octave version. I am sure I can sort this, but > I'm not sure of the timeframe. It's personally important to me, so I > will try to devote some time to it. Well, from the URL above the octave testing version has the remark "(you probably want this)". So I suggest you designate our current interface (which we know works for 2.1.73) as the "octave stable interface" and create a modified octave interface called our "octave testing interface" that works for the octave testing version (currently 2.9.14). Hopefully, that version won't change too often, and there will be no changes required to our octave testing interface when there is a change in the version number designated as octave testing. Of course this strategy means our octave testing interface _might_ not work for early 2.9.x versions that are in distributions (e.g., 2.9.9 in Ubuntu feisty). If that turns out to be the case, you can cover that off by disabling the octave testing interface unless exactly the right version that you have tested has been installed (usually by specifically downloading and building it for those who want to be on the absolute cutting edge). This strategy should take care of cutting edge octave users but not interfere with access to PLplot for octave since presumably every recent distro will have packages for octave stable = 2.1.73. However, an octave testing interface would be nice to have as well since it will gradually lead to an octave 3.0 interface for us when the 2.9.x series finally converges to 3.0. > There is also a psttf.c issue Alan reported to me recently which I would > like to look into before the release. Apparently from your commit message remarks you have now fixed the positioning issue. Thanks. Also, you do not confirm the segfault issue I found (which may simply mean my pango stack made from source downloads and builds does not include some key fixes that are in the distro versions or has some incompatible libraries in the stack). So I think we should ignore the segfault issue unless it shows up again when I update my system (probably still at least another month from now) from Debian oldstable to testing. > [out of order] How long are we looking at until the > release? That's the big question. This morning I finished up the desired changes in the files that create the website examples, but those rather extensive changes still have to be tested by Hazen to make sure good-looking results are produced on his platform. All the other issues I mentioned are fixed, put off until after 5.8.0, or in the "would be nice" category (e.g., more Ada examples). I believe the octave testing interface is probably in the "would be nice" category as well because of the current octave stable interface that will work as a good alternative. Therefore, here is what I suggest with regard to the release timing. Hazen, once you have confirmed my recent changes produce good-looking web site examples why don't you go ahead and set a release date for 5.8.0-RC1 that is the earliest that is convenient for you (say this weekend or the next). Then if Jerry can come through with more Ada examples or Andrew can put together the proposed octave testing interface before that release date, then fine, but otherwise those issues can be dealt with after the release of 5.8.0. (I am assuming here that only minimal differences will be allowed between 5.8.0-RC1 and the 5.8.0. Ideally, those differences will be just the version number changes. However, if some showstopper bug was found in the week or so of testing from our users for 5.8.0-RC1, then obviously that fix should go into 5.8.0 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 libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ |
From: Orion P. <or...@co...> - 2007-09-25 20:35:15
|
Alan W. Irwin wrote: > On 2007-09-25 18:11+0100 Andrew Ross wrote: > >> It does not work on >> octave 2.9.x. I've tried 2.9.9 on Ubuntu feisty. This is a different >> version to that tested by other users. More worryingly I seem to have >> different errors to other reports on the list. Various things seem to >> have changed which will require rewriting some of the octave parts of >> the bindings. I have been pondering the best way of doing this in a >> compatible manner. It might be cleanest to have different versions of the >> bindings depending on the octave version. I am sure I can sort this, but >> I'm not sure of the timeframe. It's personally important to me, so I >> will try to devote some time to it. > > Well, from the URL above the octave testing version has the remark "(you > probably want this)". So I suggest you designate our current interface > (which we know works for 2.1.73) as the "octave stable interface" and create > a modified octave interface called our "octave testing interface" that works > for the octave testing version (currently 2.9.14). Hopefully, that version > won't change too often, and there will be no changes required to our octave > testing interface when there is a change in the version number designated > as octave testing. > > Of course this strategy means our octave testing interface _might_ not work > for early 2.9.x versions that are in distributions (e.g., 2.9.9 in Ubuntu > feisty). If that turns out to be the case, you can cover that off by > disabling the octave testing interface unless exactly the right version that > you have tested has been installed (usually by specifically downloading and > building it for those who want to be on the absolute cutting edge). This > strategy should take care of cutting edge octave users but not interfere > with access to PLplot for octave since presumably every recent distro will > have packages for octave stable = 2.1.73. However, an octave testing > interface would be nice to have as well since it will gradually lead to an > octave 3.0 interface for us when the 2.9.x series finally converges to 3.0. Here's what I have on the octave front. 2.1.X is ancient. Fedora has been on 2.9.X since at least Fedora 5. I've got a (patched) plplot-octave 5.7.3 package that works with 2.9.9 (so would 5.7.4, just haven't released an update for F7). Somewhere between 9 and 14 they rewrote the plotting code. Suggestion I received for redoing plplot is: --- I think the way to address this given the huge difference between Octave 2.9.9 and 2.9.14 graphics is just to dump the existing plplot code, and just use it as a basis to write a new __go_draw_axes.m and drawnow.m function. That's basically all that needs replacing to override the gnuplot interface now. If the plplot versions of these two functions are on the path before the gnuplot versions, then Octave will plot with plplot.. --- I haven't had a chance to look at this, but indeed you quickly go down a rathole trying to fixup the existing plplot code to work. octave is very close to a 3.0 release, maybe only 1 or 2 more 2.9.X releases to go, so the interface as it is now should be stable for a while. -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA/CoRA Division FAX: 303-415-9702 3380 Mitchell Lane or...@co... Boulder, CO 80301 http://www.cora.nwra.com |
From: Alan W. I. <ir...@be...> - 2007-09-25 21:32:35
|
Hi Orion: Thanks for all that additional octave information, especially the information about the large differences between 2.9.9 and 2.9.14. I have some comments and questions in response to what you said. Does latest Fedora have an octave 2.1.x package available? We currently support that version and if that version of octave were available presumably some Fedora users would still be using it and could take advantage of PLplot. That is extremely good news that 2.9.14 is so close to 3.0, and I hope this encourages Andrew to make an octave interface corresponding to that version. What 2.9.x versions are available for latest Fedora? If only octave 2.9.9 is available, then probably the best thing to do is to continue with your patch for 2.9.9 for fedora but not propagate that to upstream PLplot (since I don't think we want to have three different octave interfaces). If octave testing (2.9.14) is available for latest Fedora, that would be an additional encouragement for Andrew to work on an interface corresponding to 2.9.14. This shows I have been playing with PLplot for too many years, but I remember when 2.0.x was the stable version of octave and 2.1.x was cutting edge. :-) 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 libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ |
From: Orion P. <or...@co...> - 2007-09-25 21:50:32
|
Alan W. Irwin wrote: > Hi Orion: > > Does latest Fedora have an octave 2.1.x package available? We currently > support that version and if that version of octave were available presumably > some Fedora users would still be using it and could take advantage of > PLplot. > No, Fedora is bleeding edge :-) > That is extremely good news that 2.9.14 is so close to 3.0, and I > hope this encourages Andrew to make an octave interface corresponding to > that version. > > What 2.9.x versions are available for latest Fedora? If only octave 2.9.9 is > available, then probably the best thing to do is to continue with your patch > for 2.9.9 for fedora but not propagate that to upstream PLplot (since I > don't think we want to have three different octave interfaces). If octave > testing (2.9.14) is available for latest Fedora, that would be an additional > encouragement for Andrew to work on an interface corresponding to 2.9.14. F7 has 2.9.9, and I think we're stuck there for the time being. 2.9.14 is in current Fedora development, which will be F8 shortly. Final devel freeze is coming up fast. At the moment plplot will ship with the octave interface disabled unless we get it fixed. Perhaps another place to look might be at the graceplot package in octave forge: http://octave.sourceforge.net/graceplot/index.html -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA/CoRA Division FAX: 303-415-9702 3380 Mitchell Lane or...@co... Boulder, CO 80301 http://www.cora.nwra.com |
From: Alan W. I. <ir...@be...> - 2007-09-25 23:33:52
|
On 2007-09-25 15:50-0600 Orion Poplawski wrote: > 2.9.14 is in current Fedora development, which will be F8 shortly. Final > devel freeze is coming up fast. At the moment plplot will ship with the > octave interface disabled unless we get it fixed. > > Perhaps another place to look might be at the graceplot package in octave > forge: > > http://octave.sourceforge.net/graceplot/index.html That says octave version >= 2.9.7 so it may not yet be tested for 2.9.14. Furthermore, if this is related to the grace package (formerly the xmgr plotter), then it is only 2D. I also assume gnuplot is not an alternative for Fedora 8 octave because of the non-free licensing issues for gnuplot (which is completely unrelated to GNU). So to get plotting into Fedora octave the only alternative seems to be modifying our current PLplot octave interface so that it works for 2.9.14. However, I do agree time is really short (devel freeze coming up 9 days from now according to http://fedoraproject.org/wiki/Releases/Schedule?action=show&redirect=Core%2FSchedule) if there is any chance at all of getting this into Fedora 8. Andrew, considering all the other demands on your time is there any chance on such a short time scale? 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 libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ |
From: Orion P. <or...@co...> - 2007-09-26 17:49:58
|
Alan W. Irwin wrote: > On 2007-09-25 15:50-0600 Orion Poplawski wrote: > > I also assume gnuplot is not an alternative for Fedora 8 octave because of > the non-free licensing issues for gnuplot (which is completely unrelated to > GNU). > Well, gnuplot is still in F8 at the moment. > So to get plotting into Fedora octave the only alternative seems to be > modifying our current PLplot octave interface so that it works for 2.9.14. > However, I do agree time is really short (devel freeze coming up 9 days from > now according to > http://fedoraproject.org/wiki/Releases/Schedule?action=show&redirect=Core%2FSchedule) > if there is any chance at all of getting this into Fedora 8. > > Andrew, considering all the other demands on your time > is there any chance on such a short time scale? We can also get it in as an update after F8 ships if needed. -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA/CoRA Division FAX: 303-415-9702 3380 Mitchell Lane or...@co... Boulder, CO 80301 http://www.cora.nwra.com |
From: Hazen B. <hba...@ma...> - 2007-10-01 01:04:38
|
On Sep 24, 2007, at 6:36 PM, Alan W. Irwin wrote: > 2. plptex3 issue with the interpretation of the sign of the just > parameter > for Hershey fonts (but modern fonts are fine). Shown by second and > third pages of example 28 when using Hershey fonts. > https://lists.sourceforge.net/lists/listinfo/plplot-devel This should be fixed in v7914. I was not correctly calculating the text reference point for the Hershey fonts. -Hazen |