From: Hazen B. <hba...@ma...> - 2008-01-28 01:29:11
|
Hello, Any objections to development release 5.9.0 coming out on the weekend of February 9-10th? -Hazen |
From: Alan W. I. <ir...@be...> - 2008-01-30 01:19:04
|
On 2008-01-27 20:26-0500 Hazen Babcock wrote: > > Hello, > > Any objections to development release 5.9.0 coming out on the weekend > of February 9-10th? Just to let the others here know, that suggested time for the next release arose out of off-list discussions between Hazen, Andrew (Ross), and me. Hazen, since nobody has objected let's finalize on that date for the release. Today, I finished up the Ada install tree infrastructure support I wanted to do. Other issues I am currently working on are the following: * libLASi/psttf segfaults rather than nice recovery and continuation when the pango library throws an error for certain types of glyphs that it doesn't support (I hope Andrew can help with this issue as well). * Parallel builds ("make -j 2" recently quick working for me again). * A python single-precision issue that is going to take deeper understanding of swig/python to deal with. I don't think the release should be delayed for any of these issues, but I think the chances are reasonable that I will be able to deal with these issues comfortably before the above deadline. 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: Hezekiah M. C. <hc...@at...> - 2008-01-30 03:54:25
|
On Jan 29, 2008 8:18 PM, Alan W. Irwin <ir...@be...> wrote: > On 2008-01-27 20:26-0500 Hazen Babcock wrote: > > > > > Hello, > > > > Any objections to development release 5.9.0 coming out on the weekend > > of February 9-10th? > > Just to let the others here know, that suggested time for the next release > arose out of off-list discussions between Hazen, Andrew (Ross), and me. > Hazen, since nobody has objected let's finalize on that date for the > release. Will this 5.9.0 release mark a freeze of new features for the 5.10 release? I would like to try to integrate the OCaml PLplot bindings in to the official distribution if possible. Would they have to be in before the 5.9.0 release, or could they be merged in after? Hez -- Hezekiah M. Carty Graduate Research Assistant University of Maryland Department of Atmospheric and Oceanic Science |
From: Alan W. I. <ir...@be...> - 2008-01-30 06:15:59
|
On 2008-01-29 22:54-0500 Hezekiah M. Carty wrote: > On Jan 29, 2008 8:18 PM, Alan W. Irwin <ir...@be...> wrote: >> On 2008-01-27 20:26-0500 Hazen Babcock wrote: >> >>> >>> Hello, >>> >>> Any objections to development release 5.9.0 coming out on the weekend >>> of February 9-10th? >> >> Just to let the others here know, that suggested time for the next release >> arose out of off-list discussions between Hazen, Andrew (Ross), and me. >> Hazen, since nobody has objected let's finalize on that date for the >> release. > > Will this 5.9.0 release mark a freeze of new features for the 5.10 > release? I would like to try to integrate the OCaml PLplot bindings > in to the official distribution if possible. Would they have to be in > before the 5.9.0 release, or could they be merged in after? Good question. This will be the first development release in a series that will come out every few months or so leading up to the next stable release at some unspecified date in the future (probably at minimum a year from our last stable release [5.8.0] which occurred a few months ago). In many ways the distinction between our stable releases and development releases is fairly artificial since most of the changes we do are additions (such as new bindings) which do not disturb what worked before. So we have no need for feature freezes at the present time, and you are welcome to donate your work to the PLplot software project (under the LGPL) whenever you feel ready. Of course, earlier in the series of development releases that lead up to the stable release is better than later. In sum, our release procedure is quite informal, but it seems to work OK for us. 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: Werner S. <sm...@ia...> - 2008-01-30 07:20:19
|
Hi, the only thing I want to finish before this release is, that wxPLplotdemo.cpp is built with the c++ demos during plplot compilation if BUILD_TEST=ON. Reason is, that the makefile which is generated and copied during the make install stage only works if pkg-config is available, which is not the case for Mac OS X and Windows, though it's possible to install it. But at least for Windows that's not practical. I tried to modify the makefile so that it works also for windows, but actually we would need to write a CMakeLists.txt, since you could have different compiler, etc. In order to advertise plplot on the wxwidgets mailing list I want to provide a short demo which everybody can try out easily (which is the case if you manage to compile plplot with wxWidgets support :) ). Therefore I want to have wxPLplotdemo compiled during the BUILD_TEST=ON stage (only if wxWidgets was found). It should be fairly trivial to change the CMakeLists.txt in examples\c++, but are there any objections to that? Regards, Werner Alan W. Irwin wrote: > On 2008-01-27 20:26-0500 Hazen Babcock wrote: > >> Hello, >> >> Any objections to development release 5.9.0 coming out on the weekend >> of February 9-10th? > > Just to let the others here know, that suggested time for the next release > arose out of off-list discussions between Hazen, Andrew (Ross), and me. > Hazen, since nobody has objected let's finalize on that date for the > release. > > Today, I finished up the Ada install tree infrastructure support I wanted to > do. Other issues I am currently working on are the following: > > * libLASi/psttf segfaults rather than nice recovery and continuation when > the pango library throws an error for certain types of glyphs that it > doesn't support (I hope Andrew can help with this issue as well). > > * Parallel builds ("make -j 2" recently quick working for me again). > > * A python single-precision issue that is going to take deeper understanding > of swig/python to deal with. > > I don't think the release should be delayed for any of these issues, > but I think the chances are reasonable that I will be able to deal with > these issues comfortably before the above deadline. > > 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 2008. > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > _______________________________________________ > Plplot-devel mailing list > Plp...@li... > https://lists.sourceforge.net/lists/listinfo/plplot-devel -- Dr. Werner Smekal Institut fuer Allgemeine Physik Technische Universitaet Wien Wiedner Hauptstr 8-10 A-1040 Wien Austria email: sm...@ia... web: http://www.iap.tuwien.ac.at/~smekal phone: +43-(0)1-58801-13463 (office) +43-(0)1-58801-13469 (laboratory) fax: +43-(0)1-58801-13499 |
From: Andrew R. <and...@us...> - 2008-01-30 11:43:42
|
On Wed, Jan 30, 2008 at 08:20:11AM +0100, Werner Smekal wrote: > Hi, > > the only thing I want to finish before this release is, that > wxPLplotdemo.cpp is built with the c++ demos during plplot compilation > if BUILD_TEST=ON. Reason is, that the makefile which is generated and > copied during the make install stage only works if pkg-config is > available, which is not the case for Mac OS X and Windows, though it's > possible to install it. But at least for Windows that's not practical. > > I tried to modify the makefile so that it works also for windows, but > actually we would need to write a CMakeLists.txt, since you could have > different compiler, etc. In order to advertise plplot on the wxwidgets > mailing list I want to provide a short demo which everybody can try out > easily (which is the case if you manage to compile plplot with wxWidgets > support :) ). Therefore I want to have wxPLplotdemo compiled during the > BUILD_TEST=ON stage (only if wxWidgets was found). > > It should be fairly trivial to change the CMakeLists.txt in > examples\c++, but are there any objections to that? No objections from me. We do compile other additional examples this way. > > Just to let the others here know, that suggested time for the next release > > arose out of off-list discussions between Hazen, Andrew (Ross), and me. > > Hazen, since nobody has objected let's finalize on that date for the > > release. > > > > Today, I finished up the Ada install tree infrastructure support I wanted to > > do. Other issues I am currently working on are the following: > > > > * libLASi/psttf segfaults rather than nice recovery and continuation when > > the pango library throws an error for certain types of glyphs that it > > doesn't support (I hope Andrew can help with this issue as well). > > > > * Parallel builds ("make -j 2" recently quick working for me again). > > > > * A python single-precision issue that is going to take deeper understanding > > of swig/python to deal with. > > > > I don't think the release should be delayed for any of these issues, > > but I think the chances are reasonable that I will be able to deal with > > these issues comfortably before the above deadline. My list of issues - char * to const char * tidy up should now be done. Please report any warnings still outstanding. - New API additions for date / time axes and alpha transparency. Done for C, C++, f77, f95, java, python, octave. Still need implementing for ada and tcl. - Examples 29 and 30. Done for C, C++, f77, f95, java, octave. Still need implementing for python, ada, tcl. Still some issues tidying up system time handling for java and maybe fortran? None of these are show stoppers, but it would be nice to get all bindings up to date. While looking at the examples I also noticed the tcl examples are falling behind. Any tcl fans volunteering for some porting work? We have also not ported example 27 (the spirograph plots) at all. Is anyone intending more work on this example or is it now declared "stable"? Andrew |
From: Andrew R. <and...@us...> - 2008-01-30 11:56:11
|
On Wed, Jan 30, 2008 at 11:43:18AM +0000, Andrew Ross wrote: > My list of issues > > - New API additions for date / time axes and alpha transparency. > Done for C, C++, f77, f95, java, python, octave. Still need implementing > for ada and tcl. Forgot to say that currently only cairo, gd and wxwidget drivers have transparency support. There are some issues with gd that I know of. Support for other drivers (where possible) would be good. This is really a wish-list item though. Andrew |
From: Alan W. I. <ir...@be...> - 2008-01-30 21:49:54
|
On 2008-01-30 08:20+0100 Werner Smekal wrote: > Hi, > > the only thing I want to finish before this release is, that > wxPLplotdemo.cpp is built with the c++ demos during plplot compilation > if BUILD_TEST=ON. Reason is, that the makefile which is generated and > copied during the make install stage only works if pkg-config is > available, which is not the case for Mac OS X and Windows, though it's > possible to install it. But at least for Windows that's not practical. Actually, pkg-config works on both Mac OS X and windows (see further discussion below). > > I tried to modify the makefile so that it works also for windows, but > actually we would need to write a CMakeLists.txt, since you could have > different compiler, etc. In order to advertise plplot on the wxwidgets > mailing list I want to provide a short demo which everybody can try out > easily (which is the case if you manage to compile plplot with wxWidgets > support :) ). Therefore I want to have wxPLplotdemo compiled during the > BUILD_TEST=ON stage (only if wxWidgets was found). > > It should be fairly trivial to change the CMakeLists.txt in > examples\c++, but are there any objections to that? None, and please go ahead. My view is ctest on Unix is a developer build-tree convenience to quickly test changes without having to do an install, while the install tree tests are for both developers and users to show (a) that their system is installed properly and (b) how to compile applications with pkg-config that use any of the PLplot libraries. I hope we eventually move to this same philosophy for our windows users as well rather than relying on the build tree with our libraries and font/map data scattered all over in inconvenient locations. Our Mac OS X developers have reported good results for the install-tree tests so pkg-config must work right out of the box for them. I think we have also had good reports of install tree tests for Cygwin. Anyhow, a special Cygwin version of pkg-config is available from http://cygwin.com/cgi-bin2/package-cat.cgi?file=pkg-config%2Fpkg-config-0.20-1&grep=pkg-config For windows (with MinGW or Microsoft compilers), pkg-config is available from http://www.gimp.org/~tml/gimp/win32/downloads.html and/or http://www.gtk.org/download-windows.html. The Unix man page for pkg-config mentions windows options such as --msvc-syntax which apparently delivers -L and -l flags in a form which the microsoft compilers can understand. Also, I assume you would need some alternative (perhaps nmake?) to the "make" approach we currently use to build the installed examples on Unix and Cygwin. However, I think all the pieces are available on windows to build the install-tree examples, but we just need to convince a windows developer to put it all together so the install-tree concept is completely supported on windows. Werner, I hope the above information/encouragement convinces you to at least try and get the install tree working for windows with pkg-config after you are completely satisfied with ctest on windows. 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: Werner S. <sm...@ia...> - 2008-01-31 11:02:32
|
Hi, On 30.01.2008, at 22:49, Alan W. Irwin wrote: > On 2008-01-30 08:20+0100 Werner Smekal wrote: > >> Hi, >> >> the only thing I want to finish before this release is, that >> wxPLplotdemo.cpp is built with the c++ demos during plplot >> compilation >> [.....] >> It should be fairly trivial to change the CMakeLists.txt in >> examples\c++, but are there any objections to that? > > None, and please go ahead. I made the corresponding changes and wxPLplotDemo.cpp is now compiled together with the other cpp examples if the cmake option BUILD_TEST is set to ON. I made also minor changes to wxPLplotDemo.cpp so that this demo will run on Linux/Mac OS X/Windows. > > My view is ctest on Unix is a developer build-tree convenience to > quickly > test changes without having to do an install, while the install tree > tests > are for both developers and users to show (a) that their system is > installed > [......] > approach we currently use to build the installed examples on Unix and > Cygwin. However, I think all the pieces are available on windows to > build > the install-tree examples, but we just need to convince a windows > developer > to put it all together so the install-tree concept is completely > supported > on windows. I'll try it, but pkg-config is really not used usually by Windows developers. On the other hand it is not too complicated to install and I don't see any other possibility. Regards, Werner -- Dr. Werner Smekal Institut fuer Allgemeine Physik Technische Universitaet Wien Wiedner Hauptstr 8-10 A-1040 Wien Austria email: sm...@ia... web: http://www.iap.tuwien.ac.at/~smekal phone: +43-(0)1-58801-13463 (office), +43-(0)1-58801-13469 (laboratory) fax: +43-(0)1-58801-13499 |
From: Jerry <lan...@qw...> - 2008-01-31 01:03:31
|
On Jan 30, 2008, at 4:43 AM, Andrew Ross wrote: > - New API additions for date / time axes and alpha transparency. > Done for C, C++, f77, f95, java, python, octave. Still need > implementing > for ada and tcl. What are the new subprogram names etc. associated with these? Jerry |
From: Alan W. I. <ir...@be...> - 2008-01-31 01:03:31
|
I have just completed some additional testing for the release (all with the -DENABLE_ada=ON -DBUILD_TEST=ON options and all with my specially built pango/cairo stack which includes python but not Numpy so the python part of the testing was automatically turned off). I tested three different configurations on my Debian testing platform. (1) default (which corresponds to -DENABLE_DYNDRIVERS=ON, -DBUILD_SHARED_LIBS=ON) (2) -DENABLE_DYNDRIVERS=OFF, -DBUILD_SHARED_LIBS=ON (3) -DENABLE_DYNDRIVERS=OFF, -DBUILD_SHARED_LIBS=OFF N.B. this case excludes testing of java, octave, (and python) because they require shared libraries. Also, for this case the compiled examples are large (2.2M each) since the libplplot code (including device code) is embedded in each separately compiled example. For cases (1) and (2), the build-tree build and the installed examples build showed no warnings except the known extensive warning issues with the java examples for my gcj/gij case. Thanks, Andrew, for your recent extensive work on getting rid of all those warnings! For case (3) some additional warnings occurred for bindings/tk/plframe.c:2648 and drivers/tk.c:1453 (repeated more than 100 times for some reason) with the message tmpnam is dangerous, better use mkstemp Is this large set of warnings easy to fix? For case (3) there was also an install-tree build error for wxPLplotDemo with the following message: /home/software/plplot_cvs/installcmake/lib/libplplotd.a(wxwidgets.o): In function wxCreateApp()': /home/software/plplot_cvs/HEAD/plplot_cmake/drivers/wxwidgets.cpp:366: multiple definition of wxCreateApp()' Werner, I suspect the problem is you use wxCreateApp() as part of #define IMPLEMENT_PLAPP_NO_MAIN(appname), but that (somehow?) conflicts with use of this function in #define IMPLEMENT_APP_NO_MAIN(appname) in /usr/include/wx-2.6/wx/app.h. However, I am no expert at such deep (at least for me) C++ questions, and it could be something else. Anyhow, could you please fix this problem for the -DBUILD_SHARED_LIBS=OFF case? ctest and install tree tests worked fine for all cases except for the known segfault issues for psttfc for two of our examples for my particular set of installed fonts. For the install-tree tests, I exercised plplot-test.sh (which in turn exercises various non-interactive devices) and also did a number of interactive tests of -dev tk, -dev gcw, the gnomecanvas examples, and the wxPLplotDemo example. All seems well. This success was despite the tremendous complexity of linking when all devices are part of our core library for configurations (2) and (3) above. To illustrate this complexity, here is the ldd result for our core library for configuration (2). linux-vdso.so.1 => (0x00007fffd35fd000) libpangocairo-1.0.so.0 => /home/software/pango_stack/install/lib64/libpangocairo-1.0.so.0 (0x00002ba2d78f0000) libpango-1.0.so.0 => /home/software/pango_stack/install/lib64/libpango-1.0.so.0 (0x00002ba2d7afb000) libcairo.so.2 => /home/software/pango_stack/install/lib64/libcairo.so.2 (0x00002ba2d7d3e000) libgobject-2.0.so.0 => /home/software/pango_stack/install/lib64/libgobject-2.0.so.0 (0x00002ba2d7fbb000) libgmodule-2.0.so.0 => /home/software/pango_stack/install/lib64/libgmodule-2.0.so.0 (0x00002ba2d81fe000) libdl.so.2 => /lib/libdl.so.2 (0x00002ba2d8413000) libglib-2.0.so.0 => /home/software/pango_stack/install/lib64/libglib-2.0.so.0 (0x00002ba2d8617000) libSM.so.6 => /usr/lib/libSM.so.6 (0x00002ba2d88e2000) libICE.so.6 => /usr/lib/libICE.so.6 (0x00002ba2d8aea000) libX11.so.6 => /usr/lib/libX11.so.6 (0x00002ba2d8d05000) libXext.so.6 => /usr/lib/libXext.so.6 (0x00002ba2d8f0f000) libgnomeprintui-2-2.so.0 => /usr/lib/libgnomeprintui-2-2.so.0 (0x00002ba2d9020000) libgnomeprint-2-2.so.0 => /usr/lib/libgnomeprint-2-2.so.0 (0x00002ba2d9266000) libz.so.1 => /usr/lib/libz.so.1 (0x00002ba2d93d8000) libgnomecanvas-2.so.0 => /usr/lib/libgnomecanvas-2.so.0 (0x00002ba2d95ef000) libxml2.so.2 => /home/software/pango_stack/install/lib64/libxml2.so.2 (0x00002ba2d9824000) libart_lgpl_2.so.2 => /usr/lib/libart_lgpl_2.so.2 (0x00002ba2d9b65000) libgtk-x11-2.0.so.0 => /usr/lib/libgtk-x11-2.0.so.0 (0x00002ba2d9c7c000) libgdk-x11-2.0.so.0 => /usr/lib/libgdk-x11-2.0.so.0 (0x00002ba2da234000) libatk-1.0.so.0 => /usr/lib/libatk-1.0.so.0 (0x00002ba2da4cc000) libgdk_pixbuf-2.0.so.0 => /usr/lib/libgdk_pixbuf-2.0.so.0 (0x00002ba2da6ed000) libfreetype.so.6 => /usr/lib/libfreetype.so.6 (0x00002ba2da907000) libgd.so.2 => /usr/lib/libgd.so.2 (0x00002ba2dab85000) libpng12.so.0 => /usr/lib/libpng12.so.0 (0x00002ba2dadca000) libjpeg.so.62 => /usr/lib/libjpeg.so.62 (0x00002ba2dafee000) libtcl8.5.so.0 => /usr/lib/libtcl8.5.so.0 (0x00002ba2db211000) libtk8.5.so.0 => /usr/lib/libtk8.5.so.0 (0x00002ba2db520000) libLASi.so.0 => /home/software/lasi_svn/install/lib/libLASi.so.0 (0x00002ba2db85e000) libpangoft2-1.0.so.0 => /home/software/pango_stack/install/lib64/libpangoft2-1.0.so.0 (0x00002ba2dba71000) libwx_gtk2u_core-2.6.so.0 => /usr/lib/libwx_gtk2u_core-2.6.so.0 (0x00002ba2dbca3000) libwx_baseu-2.6.so.0 => /usr/lib/libwx_baseu-2.6.so.0 (0x00002ba2dc226000) libm.so.6 => /lib/libm.so.6 (0x00002ba2dc56f000) libcsirocsa.so.0 => /home/software/plplot_cvs/installcmake/lib/libcsirocsa.so.0 (0x00002ba2dc7f0000) libcsironn.so.0 => /home/software/plplot_cvs/installcmake/lib/libcsironn.so.0 (0x00002ba2dc9f9000) libqhull.so.5 => /usr/lib/libqhull.so.5 (0x00002ba2dcc04000) libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0x00002ba2dce56000) libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x00002ba2dd161000) libpthread.so.0 => /lib/libpthread.so.0 (0x00002ba2dd379000) libc.so.6 => /lib/libc.so.6 (0x00002ba2dd594000) libfontconfig.so.1 => /home/software/pango_stack/install/lib64/libfontconfig.so.1 (0x00002ba2dd8f2000) libXrender.so.1 => /usr/lib/libXrender.so.1 (0x00002ba2ddb27000) /lib64/ld-linux-x86-64.so.2 (0x0000555555554000) libXau.so.6 => /usr/lib/libXau.so.6 (0x00002ba2ddd30000) libXdmcp.so.6 => /usr/lib/libXdmcp.so.6 (0x00002ba2dde33000) libXinerama.so.1 => /usr/lib/libXinerama.so.1 (0x00002ba2ddf38000) libXi.so.6 => /usr/lib/libXi.so.6 (0x00002ba2de03a000) libXrandr.so.2 => /usr/lib/libXrandr.so.2 (0x00002ba2de243000) libXcursor.so.1 => /usr/lib/libXcursor.so.1 (0x00002ba2de44b000) libXcomposite.so.1 => /usr/lib/libXcomposite.so.1 (0x00002ba2de655000) libXdamage.so.1 => /usr/lib/libXdamage.so.1 (0x00002ba2de857000) libXfixes.so.3 => /usr/lib/libXfixes.so.3 (0x00002ba2de95a000) libgailutil.so.18 => /usr/lib/libgailutil.so.18 (0x00002ba2dea5f000) libXpm.so.4 => /usr/lib/libXpm.so.4 (0x00002ba2dec68000) libXss.so.1 => /usr/lib/libXss.so.1 (0x00002ba2dee79000) libXft.so.2 => /usr/lib/libXft.so.2 (0x00002ba2def7d000) libexpat.so.1 => /usr/lib/libexpat.so.1 (0x00002ba2df090000) libgthread-2.0.so.0 => /home/software/pango_stack/install/lib64/libgthread-2.0.so.0 (0x00002ba2df2b4000) librt.so.1 => /lib/librt.so.1 (0x00002ba2df4b8000) libtiff.so.4 => /usr/lib/libtiff.so.4 (0x00002ba2df6c1000) That's a hell of a lot of libraries that are referenced by our core library when the device drivers become part of that core library. It's amazing our build system works at all for the complex linking conditions for configurations (2) and (3)! Note the references to the special install locations for my system /home/software/pango_stack/install/lib64/ /home/software/lasi_svn/install/lib/ /home/software/plplot_cvs/installcmake which are all handled properly and automatically with rpath. I have been pleasantly surprised by these mostly good test results since it has been a while since I have looked at configurations (2) and (3) above or done any interactive testing. 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...> - 2008-02-01 18:21:16
|
On Wed, Jan 30, 2008 at 05:02:46PM -0800, Alan Irwin wrote: > > For case (3) some additional warnings occurred for > bindings/tk/plframe.c:2648 and drivers/tk.c:1453 (repeated more than 100 > times for some reason) with the message > > tmpnam is dangerous, better use mkstemp > > Is this large set of warnings easy to fix? This is a link-time warning, which is why it only appears with the statically linked case. tmpfile is the best portable way of opening temporary files. It returns an open file descriptor rather than a file name. This avoids the various race conditions inherent in tmpnam. We use this elsewhere in plplot. Unfortunately these two cases are not easily changed. plframe.c opens a temporary file, writes to it, then calls an external print command with the temporary file name. We need the name to do this. We could use mkstemp in this case, which returns a file descriptor and a file name, avoiding the race conditions. Unfortunately this is not portable (windows doesn't have it I believe). I could implement this through suitable #ifdef's. drivers/tk.c uses the temporary file name to open a FIFO pipe. Neither tmpfile nor mkstemp can do this so I see no alternative to using tmpnam. Well the alternative is a fixed name, which is even worse to my mind. When we use tmpnam we ensure that the file is correctly created and opened and exit if not so the use should(?) be secure. A denial of service attack would be possible in theory I suppose. Unfortunately a search on the web hasn't shown an easy way of disabling the warning. Andrew |
From: Andrew R. <and...@us...> - 2008-01-31 15:20:20
|
On Wed, Jan 30, 2008 at 06:03:33PM -0700, Jerry wrote: > > On Jan 30, 2008, at 4:43 AM, Andrew Ross wrote: > > > - New API additions for date / time axes and alpha transparency. > > Done for C, C++, f77, f95, java, python, octave. Still need > > implementing > > for ada and tcl. > > What are the new subprogram names etc. associated with these? See the README.release file for details. The new API functions are pltimefmt plscmap0a plscmap1a plscmap1la plgcol0a plgcolbga plscol0a plscolbga The new examples are 29 and 30. Is this what you wanted to know? Andrew |
From: Jerry <lan...@qw...> - 2008-01-31 21:44:46
|
On Jan 31, 2008, at 8:19 AM, Andrew Ross wrote: > On Wed, Jan 30, 2008 at 06:03:33PM -0700, Jerry wrote: >> >> On Jan 30, 2008, at 4:43 AM, Andrew Ross wrote: >> >>> - New API additions for date / time axes and alpha transparency. >>> Done for C, C++, f77, f95, java, python, octave. Still need >>> implementing >>> for ada and tcl. >> >> What are the new subprogram names etc. associated with these? > > See the README.release file for details. The new API functions are > > pltimefmt > plscmap0a > plscmap1a > plscmap1la > plgcol0a > plgcolbga > plscol0a > plscolbga > > The new examples are 29 and 30. > > Is this what you wanted to know? > > Andrew > Yes. Thanks. These functions don't yet appear in the docs, at least not at http://plplot.sourceforge.net/docbook-manual/plplot-html-5.8.0/. Jerry |
From: Andrew R. <and...@us...> - 2008-01-31 22:46:28
|
On Thu, Jan 31, 2008 at 02:44:49PM -0700, Jerry wrote: > > On Jan 31, 2008, at 8:19 AM, Andrew Ross wrote: > > > See the README.release file for details. The new API functions are > > > > pltimefmt > > plscmap0a > > plscmap1a > > plscmap1la > > plgcol0a > > plgcolbga > > plscol0a > > plscolbga > > > > The new examples are 29 and 30. > > > > Is this what you wanted to know? > > > > Andrew > > > Yes. Thanks. These functions don't yet appear in the docs, at least > not at http://plplot.sourceforge.net/docbook-manual/plplot-html-5.8.0/. > > Jerry The online documentation is for the latest release (5.8.0). The new functions have been introduced since then. They should be fully documented in svn. Once 5.9.0 is released the online version will be updated. Andrew |
From: Alan W. I. <ir...@be...> - 2008-02-01 21:15:41
|
On 2008-02-01 18:20-0000 Andrew Ross wrote: > On Wed, Jan 30, 2008 at 05:02:46PM -0800, Alan Irwin wrote: >> >> For case (3) some additional warnings occurred for >> bindings/tk/plframe.c:2648 and drivers/tk.c:1453 (repeated more than 100 >> times for some reason) with the message >> >> tmpnam is dangerous, better use mkstemp >> >> Is this large set of warnings easy to fix? > > This is a link-time warning, which is why it only appears with the > statically linked case. > > tmpfile is the best portable way of opening temporary files. It returns > an open file descriptor rather than a file name. This avoids the various > race conditions inherent in tmpnam. We use this elsewhere in plplot. > Unfortunately these two cases are not easily changed. > > plframe.c opens a temporary file, writes to it, then calls an external > print command with the temporary file name. We need the name to do this. > We could use mkstemp in this case, which returns a file descriptor and a > file name, avoiding the race conditions. Unfortunately this is not > portable (windows doesn't have it I believe). I could implement this > through suitable #ifdef's. > > drivers/tk.c uses the temporary file name to open a FIFO pipe. Neither > tmpfile nor mkstemp can do this so I see no alternative to using tmpnam. > Well the alternative is a fixed name, which is even worse to my mind. > > When we use tmpnam we ensure that the file is correctly created and > opened and exit if not so the use should(?) be secure. A denial of > service attack would be possible in theory I suppose. > > Unfortunately a search on the web hasn't shown an easy way of disabling > the warning. Thanks, Andrew, for your research into this issue. It sounds like the status quo (and living with the resulting warning messages) is the correct course to take unless a better option becomes available in the future. 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: Alan W. I. <ir...@be...> - 2008-02-05 22:54:52
|
On 2008-01-29 17:18-0800 Alan W. Irwin wrote: > [...]Other issues I am currently working on are the following: > > * libLASi/psttf segfaults rather than nice recovery and continuation when > the pango library throws an error for certain types of glyphs that it > doesn't support (I hope Andrew can help with this issue as well). > > * Parallel builds ("make -j 2" recently quick working for me again). > > * A python single-precision issue that is going to take deeper understanding > of swig/python to deal with. > > I don't think the release should be delayed for any of these issues, > but I think the chances are reasonable that I will be able to deal with > these issues comfortably before the above deadline. Here is the current status for these three issues. * Andrew, has been able to generate segfaults for a pure libLASi test case for a particular font set he has on a Debian testing system. Once we can find out what font it is and replicate that exact problem on other systems we might be able to improve the robustness of libLASi against font errors. There may be additional changes required in drivers/psttf.cc as well to make it more robust against errors passed from libLASi. Of course, we want to work on the pure libLASi case to start (since that is simpler) so it is unlikely we will get to the psttf.cc changes (if required) before the forthcoming PLplot release this weekend. * I have made a lot of progress on the parallel builds issue, but I am currently stuck. "make -j N" works fine for N values I have sampled from 2 to 20 and with many different CMake configurations, IF I exclude java from the build. However, there are problems in most cases if java is included in the parallel build. For example, "make -j 2" fails for the simple configuration case of no devices other than ps, and no bindings other than C++ and java. In comparison, python (also generated by swig) succeeds for all the many configurations I have tested (including excluding all devices other than ps and excluding all bindings other than C++ and python). I am currently stuck though because even for the test case where if I remove all the *.java and *.class stuff so that the only part of the java build that occurs is the C part (which is virtually identical to the working C part of the python parallel build), the parallel build still fails for java. Recall that the special dependency rule that must be satisfied in order to make parallel builds work for CMake is that two independent targets (i.e., with no target dependencies between them) cannot depend directly or indirectly on the same files. Visual spotting of such dependency issues in CMake code can be problematic for long dependency chains, and the situation is made worse because sometimes such dependency issues do not generate parallel build errors because of an accident of timing, hardware, or whatever. Nevertheless, the consistently good parallel builds I get for python and the consistently bad parallel builds I get for java (even when its been modified to be essentially identical with the python case) is a strong indication that something deeper (such as a dependency issue introduced by the swig module for just the java case) might be wrong. Anyhow, my next step is to dig into the java part of the swig module code to see if I can spot anything even though it seems like a long shot. Meanwhile, I would appreciate it if you made your own parallel build tests to make sure my particular dual-processor hardware, software stack, and configuration didn't accidentally miss parallel build problems in the non-java parts of our build. * Because I have been stuck on the parallel build issue, I doubt very much I will get to the python precision issue before our 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...> - 2008-02-05 23:31:45
|
Alan, I suspect the java parallel build issues are partly my fault. I think there are implicit java dependencies in the way the files are compiled - the order is important. This is mostly because cmake didn't seem to properly support java dependency checking. I'd check that out as a first step. We can probably make the dependencies explicit to solve the problem. In the meantime I'll try to keep on looking at the lasi issues. Andrew On Tue, Feb 05, 2008 at 02:50:05PM -0800, Alan Irwin wrote: > On 2008-01-29 17:18-0800 Alan W. Irwin wrote: > > > [...]Other issues I am currently working on are the following: > > > > * libLASi/psttf segfaults rather than nice recovery and continuation when > > the pango library throws an error for certain types of glyphs that it > > doesn't support (I hope Andrew can help with this issue as well). > > > > * Parallel builds ("make -j 2" recently quick working for me again). > > > > * A python single-precision issue that is going to take deeper understanding > > of swig/python to deal with. > > > > I don't think the release should be delayed for any of these issues, > > but I think the chances are reasonable that I will be able to deal with > > these issues comfortably before the above deadline. > > Here is the current status for these three issues. > > * Andrew, has been able to generate segfaults for a pure libLASi test case > for a particular font set he has on a Debian testing system. Once we can > find out what font it is and replicate that exact problem on other systems > we might be able to improve the robustness of libLASi against font errors. > There may be additional changes required in drivers/psttf.cc as well to > make it more robust against errors passed from libLASi. Of course, we > want to work on the pure libLASi case to start (since that is simpler) so > it is unlikely we will get to the psttf.cc changes (if required) before > the forthcoming PLplot release this weekend. > > * I have made a lot of progress on the parallel builds issue, but I am > currently stuck. "make -j N" works fine for N values I have sampled from 2 > to 20 and with many different CMake configurations, IF I exclude java from > the build. However, there are problems in most cases if java is included > in the parallel build. For example, "make -j 2" fails for the simple > configuration case of no devices other than ps, and no bindings other than > C++ and java. In comparison, python (also generated by swig) succeeds for > all the many configurations I have tested (including excluding all devices > other than ps and excluding all bindings other than C++ and python). > > I am currently stuck though because even for the test case where if I > remove all the *.java and *.class stuff so that the only part of the java > build that occurs is the C part (which is virtually identical to the > working C part of the python parallel build), the parallel build still > fails for java. > > Recall that the special dependency rule that must be satisfied in order to > make parallel builds work for CMake is that two independent targets (i.e., > with no target dependencies between them) cannot depend directly or > indirectly on the same files. Visual spotting of such dependency issues > in CMake code can be problematic for long dependency chains, and the > situation is made worse because sometimes such dependency issues do not > generate parallel build errors because of an accident of timing, hardware, > or whatever. Nevertheless, the consistently good parallel builds I get > for python and the consistently bad parallel builds I get for java (even > when its been modified to be essentially identical with the python case) > is a strong indication that something deeper (such as a dependency issue > introduced by the swig module for just the java case) might be wrong. > Anyhow, my next step is to dig into the java part of the swig module code > to see if I can spot anything even though it seems like a long shot. > > Meanwhile, I would appreciate it if you made your own parallel build tests > to make sure my particular dual-processor hardware, software stack, and > configuration didn't accidentally miss parallel build problems in the > non-java parts of our build. > > * Because I have been stuck on the parallel build issue, I doubt very much > I will get to the python precision issue before our 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 2008. > 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...> - 2008-02-06 20:27:18
|
On 2008-02-05 23:29-0000 Andrew Ross wrote: > > Alan, > > I suspect the java parallel build issues are partly my fault. I think > there are implicit java dependencies in the way the files are > compiled - the order is important. This is mostly because cmake > didn't seem to properly support java dependency checking. I'd check > that out as a first step. We can probably make the dependencies > explicit to solve the problem. My brain sometimes comes up with good ideas while I am sleeping (and sometimes when I am awake as well.... :-) ). Anyhow, I woke up this morning with the realization that another difference between python and java is that java examples are built rather than just being scripts as in the python case. Thus, I tried turning off the java example builds, and for the very first time plplotjavac_wrap.so could be built in parallel without issues. So that was a big step forward. So I have been up against two separate dependency issues (one in the java bindings for the built class files and one in the java examples) that were giving a confusing mish-mash of errors for parallel builds. Now that I can separate the two dependency issues, it has become much easier to track down the problems. And yes, you were right that the class files have to be built in a particular order since, e.g., plplotjavac.java has references to PLGraphicsIn. I have now done a lot of grepping to determine such dependencies and put in some CMake logic to implement such class dependencies. Please check my work (revision 8218) to make sure my grepping (and limited knowledge of Java) found the correct list of class dependencies. Early indications for this dependency work are good because the fix seems to sort out the parallel build issues for the java bindings on my hardware platform which is another big step forward. Note, there are still parallel build issues remaining if the java examples are built, but now that there is no interference from java bindings dependency issues, I am confident it will be straightforward to fix. 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: Alan W. I. <ir...@be...> - 2008-02-06 22:37:13
|
On 2008-02-06 12:25-0800 Alan W. Irwin wrote: > [...Y]ou were right that the class files have to be built in a > particular order since, e.g., plplotjavac.java has references to > PLGraphicsIn. I have now done a lot of grepping to determine such > dependencies and put in some CMake logic to implement such class > dependencies. Please check my work (revision 8218) to make sure my grepping > (and limited knowledge of Java) found the correct list of class > dependencies. Early indications for this dependency work are good because > the fix seems to sort out the parallel build issues for the java bindings on > my hardware platform which is another big step forward. > > Note, there are still parallel build issues remaining if the java examples are > built, but now that there is no interference from java bindings dependency > issues, I am confident it will be straightforward to fix. A redundant and poorly implemented test was being done for the java examples for whether the plplot_core target had been built. Removal of that test appeared to solve the last of the parallel build issues. I followed up with extensive testing of a number of configurations including a full build of PLplot software and documentation with "make -j N" for a variety of N values. All seemed well until a very specific combination (no documentation build, full software build, N=4) turned up another kind of class file dependency that I had missed due to my lack of Java knowledge. revision 8220 puts in the necessary extra class file dependencies, and all seems well again. However, it appears test results critically depend on the hardware, value of N, and type of configuration so the fact that everything seems clean for me now is just an encouraging indication I have addressed all the parallel build issues, but this good result is not definitive. Thus, I strongly encourage everybody to routinely use the parallel build option not only as a matter of convenience (quicker builds on multi-processore boxes) but also to make sure we don't introduce any new dependency issues or have any issues that are currently hidden for my present hardware (two processors), software platform, and PLplot configuration. To summarize the current release status, we can now strike the parallel build issue from the list (subject to parallel-build testing results from others). That leaves the psttf/libLASI segfaults, the python single-precision issue, and the recently introduced wxwidgets issue. I plan to spend my remaining PLplot time before the release this weekend helping Andrew with the psttf/libLASi segfault issue. There are no guarantees we will get done before the release, but we can live with that. I am going to let the python single-precision issue slide until after the release since I feel the psttf issue should have higher priority. Based on past experience, I am sure Werner will quickly sort out the wxwidgets issue. 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...> - 2008-02-07 11:06:30
|
On Wed, Feb 06, 2008 at 02:36:04PM -0800, Alan Irwin wrote: > > A redundant and poorly implemented test was being done for the java examples > for whether the plplot_core target had been built. Removal of that test > appeared to solve the last of the parallel build issues. Excellent news. > To summarize the current release status, we can now strike the parallel > build issue from the list (subject to parallel-build testing results from > others). That leaves the psttf/libLASI segfaults, the python > single-precision issue, and the recently introduced wxwidgets issue. > > I plan to spend my remaining PLplot time before the release this weekend > helping Andrew with the psttf/libLASi segfault issue. There are no > guarantees we will get done before the release, but we can live with that. I > am going to let the python single-precision issue slide until after the > release since I feel the psttf issue should have higher priority. Based on > past experience, I am sure Werner will quickly sort out the wxwidgets issue. I am confident the segfault issue is a problem with LASi. I know the cause. I have committed a temporary workaround to the lasi svn repo which should stop the segfault. It will just ignore the troublesome glyphs. Alan, could you check this works for you. No plplot changes should be necessary. Andrew |
From: Werner S. <sm...@ia...> - 2008-02-08 08:49:25
|
Hi Alan, > Thus, I strongly encourage everybody to routinely use the parallel > build > option not only as a matter of convenience (quicker builds on > multi-processore boxes) but also to make sure we don't introduce any > new > dependency issues or have any issues that are currently hidden for my > present hardware (two processors), software platform, and PLplot > configuration. I played a little with parallel builds on my double code mac and there were no obvious problems. Compile time dropped from 30 seconds to about 20-22 seconds for the variours make -j N cases. I don't have a full blown plplot configuration here, but so far this looks very promising. Thank you very much for the effort! Regards, Werner > 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 > __________________________ -- Dr. Werner Smekal Institut fuer Allgemeine Physik Technische Universitaet Wien Wiedner Hauptstr 8-10 A-1040 Wien Austria email: sm...@ia... web: http://www.iap.tuwien.ac.at/~smekal phone: +43-(0)1-58801-13463 (office), +43-(0)1-58801-13469 (laboratory) fax: +43-(0)1-58801-13499 |
From: Alan W. I. <ir...@be...> - 2008-02-07 18:38:36
|
On 2008-02-07 11:06-0000 Andrew Ross wrote: > I am confident the segfault issue is a problem with LASi. I know the > cause. I have committed a temporary workaround to the lasi svn repo > which should stop the segfault. It will just ignore the troublesome > glyphs. Alan, could you check this works for you. No plplot changes > should be necessary. Yes, it works fine now. Thanks for the libLASi fix. For those not subscribed to lasi-devel, I hope to make a libLASi release later today so that many/most -dev psttf users will benefit from Andrew's fix which I view as a fundamental safety check rather than a temporary workaround since it does the logical thing (produces a blank) if pango/cairo/fontconfig delivers anything but an outline font glyph (which is the only form of glyph that libLASi can use). -dev wxwidgets builds again as well for the 2.6.x version of wxwidgets. Thanks, Werner! I will deal with the python single-precision issue later. Thus, from my perspective it appears we are ready for the PLplot release this weekend. 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...> - 2008-02-07 19:51:46
|
On Thu, Feb 07, 2008 at 10:37:01AM -0800, Alan Irwin wrote: > > I will deal with the python single-precision issue later. > > Thus, from my perspective it appears we are ready for the PLplot release > this weekend. I have just one more issue related to building the documentation. If I build it on my Debian or Ubuntu systems all the ligatures in the pdf get messed up. This starts with the ff in Geoff on the title page - rather embarasing. This is an encoding problem. Rafael has committed a patch for Debian (debian/patches/09_pdftex-EC-encoding.dpatch) to fix this by changing the encoding file EC.enc to ec.enc. This works for me. Apparently the change is as a result of the file name changing in the switch from tetex to texlive. Before commiting this to the main archive I wanted to check what happened on other people's systems - in particular Hazen who gets to build the documentation for each release. Andrew |
From: Alan W. I. <ir...@be...> - 2008-02-12 03:29:12
|
On 2008-02-07 19:51-0000 Andrew Ross wrote: > On Thu, Feb 07, 2008 at 10:37:01AM -0800, Alan Irwin wrote: >> >> I will deal with the python single-precision issue later. >> >> Thus, from my perspective it appears we are ready for the PLplot release >> this weekend. > > I have just one more issue related to building the documentation. If I > build it on my Debian or Ubuntu systems all the ligatures in the pdf get > messed up. This starts with the ff in Geoff on the title page - rather > embarasing. This is an encoding problem. Rafael has committed a patch for > Debian (debian/patches/09_pdftex-EC-encoding.dpatch) to fix this by > changing the encoding file EC.enc to ec.enc. This works for me. > Apparently the change is as a result of the file name changing in the > switch from tetex to texlive. > > Before commiting this to the main archive I wanted to check what > happened on other people's systems - in particular Hazen who gets to > build the documentation for each release. I still have access to a Debian sarge system, and the file location there is /usr/share/texmf/dvips/base/EC.enc while for Debian testing the file location is /usr/share/texmf-texlive/fonts/enc/dvips/base/ec.enc. As part of a different investigation off-list with Hazen, I recently saw the results of his documentation build on the dedicated Debian system (sarge?) that he uses to build our documentation for the website. Apparently, that system still uses EC.enc. You can see the results of that doc build at the newly uploaded http://plplot.sourceforge.net/docbook-manual/plplot-html-5.9.0/, and the "Geoff" ligatures look OK to my eyes. >From other off-list discussions with Hazen, I think it is going to be a while before he reinstalls that system with modern Debian so probably the best way to deal with this issue is to use our build system to configure either EC.enc or ec.enc depending on what is available on the system (with a direct check of the above location for EC.enc, and if it isn't there assume the file is called ec.enc). Accordingly I configured all the changes that are in the Debian patch in revision 8241 using the above simple test, and the resulting ligatures in plplot-5.9.0.pdf look good on my Debian testing system. Hazen will you test that it works for you on your old Debian platform (i.e., doc/docbook/src/pdftex.map is configured with EC.enc on your system)? Also, will you double-check by looking for any strange-looking ligatures (the "ff" in Geoff's name) in plplot-5.9.0.pdf. Thanks, Geoff, for having such a testworthy name. :-) TIA 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 __________________________ |