PLplot

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
__________________________

On Jan 29, 2008 8:18 PM, Alan W. Irwin <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.

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

On 2008-01-29 22:54-0500 Hezekiah M. Carty wrote:

> On Jan 29, 2008 8:18 PM, Alan W. Irwin <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.
>
> 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
__________________________

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
> Plplot-devel@...
> 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: smekal@...
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

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

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

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
__________________________

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

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
__________________________

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: smekal@...
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

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

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

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

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

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
__________________________

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
__________________________

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
> Plplot-devel@...
> https://lists.sourceforge.net/lists/listinfo/plplot-devel
>

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
__________________________

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
__________________________

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

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
__________________________

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

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: smekal@...
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

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
__________________________

On Mon, Feb 11, 2008 at 07:29:12PM -0800, Alan Irwin wrote:
> 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.  :-)

Thanks for the neat solution Alan. Works fine for me on Ubuntu Gutsy.

Andrew