On 2013-05-02 11:42-0700 Alan W. Irwin wrote:

> I will now move on to updating the DocBook API documentation for the
> plshade* and pllegend arguments, and also propagating the changed
> width arguments for those routines for the remaining swig-related languages
> (Java, Lua, and Octave) I committed to support through this change.

All DONE as of revision 12331.  Default build has now been tested with the
"test_noninteractive" target.

So here are the language bindings which are currently enabled for that
default build:

Language Bindings:
ENABLE_f77:             OFF             ENABLE_f95:             ON
ENABLE_cxx:             OFF             ENABLE_java:            ON
ENABLE_python:          ON              ENABLE_octave:          ON
ENABLE_tcl:             ON              ENABLE_itcl:            ON
ENABLE_tk:              ON              ENABLE_itk:             ON
ENABLE_pdl:             OFF             ENABLE_wxwidgets:       ON
ENABLE_ada:             OFF             ENABLE_d:               OFF
ENABLE_ocaml:           ON              ENABLE_lua:             ON
ENABLE_qt:              ON              ENABLE_pyqt4:           ON

f77 should remain OFF and should soon be removed.  pdl is external and
that depends on how soon Doug Hunt will be able to adjust his perl/pdl
bindings for PLplot for this plshade* and pllegend C API change.  I
encourage others here to deal with propagation of these C API changes
to the bindings and examples of the remaining languages that are still
disabled by default above, i.e., Ada, C++, and D.

The results from the test_diff_psc target (which is invoked along with
other tests from the test_noninteractive target) shows all is well for
the above enabled languages except for example 16 where the PostScript
results for all language bindigns differred from the corresponding C
results.  In that case, I also did a special local test where the
plcolorbar call was temporarily dropped from C example 16, and that
gave complete consistency with all other languages for that example
_except_ (Hez should take note of this) for the OCaml example 16 which
apparently needs non-plcolorbar work to bring it into consistency with
the C example 16 without plcolorbar calls.  So the conclusion from
this experiment is that stabilization of the plcolorbar API and
propagation of it to all the language bindings and example 16 will
solve all these example 16 issues other than the non-plcolorbar issue
noted above for OCaml example 16.

If Hez gives his agreement to my proposed plcolorbar API change, then
I can get that plcolorbar propagation process started (including
propagation to example 16) for the languages whose bindings are
generated by swig.  And I am willing to go through that process
again if he implements his further proposed API change.

I am also waiting for Andrew's answer to my question about dropping
our support for Numeric.

But otherwise, I am done with my current PLplot contributions, and I
am planning to go back tomorrow to my other active project which is
writing up some interesting scientific results concerning time
ephemerides which I have demonstrated with the timeephem/te_gen
software.

<off-topic>
   The summary there is clock rates have a well-known general
   relativistic correction which te_gen calculates. That correction
   depends on the local gravitational field which is dominated by the
   effects of the masses of the Sun, Moon, and planets and the
   distances of those objects from the Earth as a function of time.
   But asteroids (which are rather low-mass solar system objects
   compared to planets) also have a very small effect on the
   gravitational field near the Earth, and it turns out that effect is
   on the edge of detectability for the most accurate clocks!  I think
   it is really cool that clocks have been developed with such a high
   degree of accuracy which is why I am sharing this result with you.
</off-topic>

I will quickly bring this post back to PLplot topics again by saying
all my figures for that paper have used pllegend quite successfully
and have been generated with the pdfcairo device. Such PDF figures can
be directly included into scientific papers using the latex graphicx
package and the pdflatex command that directly produces a PDF version
of the paper.  The resulting figures in that PDF version of the paper
look really sharp compared to the somewhat more blurry results you get
if you use PLplot to generate figures with the epscairo (or any other
PostScript) device and attempt to include those PostScript results in
the paper using either the latex or pdflatex commands.  So in sum, use
PDF figures (generated with pdfcairo), the latex graphicx package, and
the pdflatex command to generate PDF documents with absolutely the
best-looking embedded graphics.

Alan

__________________________
Alan W. Irwin

Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).

Programming affiliations with the FreeEOS equation-of-state
implementation for stellar interiors (freeeos.sf.net); the Time
Ephemerides project (timeephem.sf.net); PLplot scientific plotting
software package (plplot.sf.net); the libLASi project
(unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
and the Linux Brochure Project (lbproject.sf.net).
__________________________

Linux-powered Science
__________________________

------------------------------------------------------------------------------
Get 100% visibility into Java/.NET code with AppDynamics Lite
It's a free troubleshooting tool designed for production
Get down to code-level detail for bottlenecks, with <2% overhead.
Download for free and get started troubleshooting in minutes.
http://p.sf.net/sfu/appdyn_d2d_ap2
_______________________________________________
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel

Reply via email to