To Andrew, Phil, and Jim: These starting three paragraph are new, but the rest of this post you have seen before under a slightly different subject line. But I am including "the rest" of this post now because it appears plplot-devel is working again, and I want everyone there to be aware of the changed release date that is alluded to in the last paragraph.
To be more specific about that, the new tentative release date is Wednesday, March 4th. The reason for this delay is I haven't had a chance to even start the preliminary steps in the release process yet (including most importantly comprehensive testing) because of mail troubles slowing down our communications and all the specific time-intensive testing I have been doing to help you guys figure out some of the remaining nastier wxwidgets/plbuf issues. In other words specific testing that bugs have been fixed for a particular build configuration is essential, but that has to be followed up with comprehensive testing to explore all the corner cases such as our three major configurations, and our three different build systems. Thus, I plan to start the release preliminaries now including comprehensive testing and if I have some early success with complete comprehensive checks for the Debian stable case, then I will start comprehensive testing on MinGW/MSYS/Wine and encourage others here to also start comprehensive testing on their accessible platforms following the directions in http://sourceforge.net/p/plplot/wiki/Testing_PLplot/ ==> Comprehensive testing. Of course, if our joint comprehensive testing reveals additional issues that need to be fixed before the release, then the release date might slide still further into the future. But I have been quite happy with the bug fixing that has been going on for the nastier wxwidgets/plbuf bugs we have encountered so far. Therefore, however long this release process takes is definitely going to be worth it! @Andrew: I didn't receive your recent e-mail concerning rt configuration, but spotted that message just now in the Plplot-devel archive, and I have also discovered all sorts of other mail disruption I have at this time with sending anything to SourceForge or with SourceForge sending anything to me. So it is very likely the release is going to be delayed beyond February 28th because of my mail troubles with SourceForge. Note my ir...@beluga.phys.uvic.ca e-mail address appears to work fine so if anybody here want to urgently reach me with regard to some release issue, use that address rather than any SourceForge-related one at this time. Also, to be fair, I am pretty far behind on my testing so that may delay the release for a few days even if SourceForge restores mail connectivity for me. I think I now understand why rt has to be explicitly mentioned for the wxPLViewer build (as you discovered on Ubuntu). As already noted by Jim, nm --undefined shows that wxPLViewer explicitly depends on U shm_open@@GLIBC_2.2.5 U shm_unlink@@GLIBC_2.2.5 and <http://linux.die.net/man/3/shm_open> indicates that on Linux they must be linked with -lrt. However, this explicit linking not needed with wxwidgets because it does not call either of the above functions (again according to nm). However, ldd shows that wxwidgets and wxPLViewer are linked to a library that itself is linked to rt on Debian stable which is why the linking of wxPLViewer scraped through for me on Debian stable. But that indirect link "save" did not apply for the Ubuntu libraries. The correct solution is, as always, to mention all libraries that are explicitly needed so I have now made that fix (commit id a01a677). @Phil: Sorry for conflating two e-mails, but "needs must" when I cannot communicate via SourceForge. There are some recent regressions in wxwidgets. 1. I noticed while testing the above fix that there are now affine transformation issues again for 3D plot labels for example 8 with -dev wxwidgets. The xwin, xcairo, and qtwidgets devices do not show this issue even when they are resized. (So I think that xwin experiment rules out the problem is in plbuf.) > From my and Andrew's recent superb experiences with git bisect, we highly recommend that method of finding the offending commit that caused the above issue. 2. There is now also a text rotation transformation issue for example 4 page 2 and example 26 page 2 for wxwidgets which was not there recently. You might not need git bisect for this one since I suspect it is the fairly recent example 3 rotation fix (by the way example 3 still looks fine) that caused the other issues. The above are strong "would be nice's" for the release if you back them up by looking at every example to make sure a fix for one example page does not cause issues for other example pages (like happened to create these latest two regressions). Of course, if a change like Andrew's recent fix to plbuf is necessary to fix all devices, then he obviously that has to be done even if it causes problems for wxwidgets (until the two wrongs making a right approach that worked before is fixed). But "git bisect" should tell the tale about the exact cause of the two regressions above. Another quite strong "would be nice" is to work out what is wrong with the exotic glyphs for example 24. Note there are only two missing glyphs (on page 4) for example 23 and none for examples 18 (pages 6 and 8) and 26 (page 2). To review, example 23 specifies the require glyphs with ascii escape sequences unique to PLplot which the core PLplot library translates into UCS4 (32-bit unsigned integer representation of unicode). The rest of the mentioned examples specify the glyphs with utf8 characters which the core PLplot library also translates into UCS4. The drivers then translate that UCS4 data into instructions to the various Qt4, pango/cairo, and wxwidgets libraries using generic font families such as "sans", "serif", and "mono", which those libraries translate into a search of all sans, serif, or mono system fonts to find the "best" system glyph to display that desired unicode character. So since wxwidgets appears to handle most unicode without issues, I am virtually positive that that system glyph search process is breaking down for the wxwidgets device for the exotic glyphs for example 24 and the 2 missing glyphs for example 23. Note, this did not happen for the old wxwidgets device for the default (wxGC?) backend that did not use the deprecated plfreetype method. (By the way, I am very happy to see no mention of freetype in the rewritten wxwidgets driver, and no mention of it in plbuf.) Finally, another strong "would be nice" is to rewrite drivers/README.wxwidgets which your work has completely outdated now (so it is positively misleading). And also please put a paragraph into README.Release describing your recent wxwidgets work. My own feeling is it will likely be at least mid-week next week (March 4th) before I will be ready to release for the reasons mentioned above, so this allows you extra time to do some of the above before 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); the Time Ephemerides project (timeephem.sf.net); PLplot scientific plotting software package (plplot.sf.net); 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 __________________________ ------------------------------------------------------------------------------ Dive into the World of Parallel Programming The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/ _______________________________________________ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
