plplot-devel — Technical discussion about PLplot development

Re: [Plplot-devel] Comprehensive testing: OpenSuse-13.2: finding stuff

[Alan W. I. <ir...@be...>]

On 2015-04-05 11:55-0700 Alan W. Irwin wrote:

> On 2015-04-05 11:14-0000 Arjen Markus wrote:
>
>> Hi Alan,
>>
>>
>>
>> Attached is the stderr/stdout output from the script.
>>
>>
>>
>> The script itself was:
>>
>>
>>
>> export PATH=/cygdrive/d/plplot-svn/comprehensive_test_disposeable/shared/install_tree/bin:$PATH
>>
>> export PATH=/cygdrive/d/plplot-svn/comprehensive_test_disposeable/shared/install_tree/lib/plplot5.10.0/drivers:$PATH
>>
>> ../plplot-git/scripts/comprehensive_test.sh --do_test_traditional_install_tree no --do_test_interactive no
>>
>>
>>
>> I am not sure if both extensions of the PATH variable are required, but at least with the two it worked. At the very least the second was required.
>
> Although the above brute-force changes to the PATH, may work, there
> are not ideal since they impose install-tree results on build-tree
> tests.

> [...]I think the solution is to drop this problematic logic completely and
> instead introduce one more option to the script called
> --manipulate_PATH which defaults to no but which Windows platform
> users should specify as yes. But I will deal with that issue
> post-release, and for now the Cygwin results you have obtained with
> the above brute-force approach are good enough.

Hi Arjen:

I think I have found a good bash shell method of automatically detecting any
windows platform (using the "exe" suffix that occurs for the bash
fullpathname on all Windows platforms).  So there is no need for the
user to specify whether Windows PATH manipulation is needed or not
and therefore no need to implement the above --manipulate_PATH option
for the script.

As of commit id 13a3baa, I have changed the script to implement the
automatic Windows platform detection described above.  That means path
manipulations will automatically occur on all Windows platforms within
the script and there is no longer any need to use brute-force PATH
changes before running the script on Cygwin (or any other Windows
platform).

Could you let me know if the fix works (i.e., by running the script
with no special brute-force PATH manipulations beforehand). This might
also be a good opportunity for you to permanently remove some of the
constraints on your prior successful Cygwin test.  For example, note
(E) on your current test report at
<https://sourceforge.net/p/plplot/wiki/Testing_PLplot/#Testing%20Reports>
implies if you install swig on your Cygwin platform, the Java, Python,
Octave, and Lua components of PLplot will be included in your
comprehensive testing (assuming you have the development versions of
those software packages already installed).

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
__________________________

Re: [Plplot-devel] Release status: call for comprehensive testing

[Alan W. I. <ir...@be...>]

On 2015-04-10 21:54+0100 Andrew Ross wrote:

>
> Hazen,
>
> That's interesting, and at odds with my tests a week or so back on Kubuntu
> 14.10. Can you confirm which flavour and version of Ubuntu you are using?
> Also, I assume this is with Qt4 and not Qt5?

Hi Andrew:

The answers to your questions have been scattered a bit in different
threads so to collect them together for you here, Hazen used Qt4.8.6,
and Lubuntu, and today he said he was pretty sure the version was
14.04.2 LTS. And he recently attached a detailed valgrind report that
showed all sorts of invalid reads for one of the qt devices on his
Lubuntu platform.  (Interestingly, the invalid reads occurred during
initialization rather than the cases we have looked at in the past
where invalid reads occurred at plend.)

So if you run that specific valgrind test on your own kubuntu version
and do not confirm the severe memory management errors, then that is a
pretty clear demonstration of a Lubuntu Qt bug, and if the Qt
packaging for Lubuntu is identical to that used for every other
variant besides Kubuntu, then it is likely a non-Kubuntu Ubuntu bug.

Since there is only a 6-month difference between 14.04.2 LTS and 14.10
and we never appear to get such severe memory management issues for at
least two variants of Debian (which sticks pretty close to the
upstream version of Qt) there is a decent chance this bug has nothing
to do with upstream Qt and instead is due to some difference in
patching between the Lubuntu Qt patches that are applied and the
Kubuntu patches that are applied to the upstream version. Anyhow,
those package patches and the equivalent package patches for the
Debian cases are the first place I would look for a relevant
difference between the various versions that work, and the one or more
(Lubuntu and possibly Ubuntu) versions that do not.

If you can pin this issue down to a package patch that was applied or
not, that is well worth a bug report to Ubuntu since it is in our
interest to have Qt working properly on all variants of Ubuntu.

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
__________________________

Re: [Plplot-devel] Comprehensive testing reports

[Hazen B. <hba...@ma...>]

On 04/13/2015 06:29 PM, Alan W. Irwin wrote:
> On 2015-04-13 13:51-0400 Hazen Babcock wrote:
>
>> On 04/12/2015 08:23 AM, Alan W. Irwin wrote:
>>> On 2015-04-11 21:05-0400 Hazen Babcock wrote:
>>>
>>>> It worked fine without the Qt components. Is there an output file that
>>>> I should send?
>>>
>>> Excellent news on the Lubuntu front.
>>>
>>> To answer your question, please send a compressed tarball containing
>>> _all_ environment variables (you can capture a complete list of those
>>> from bash using printenv >& printenv.out); the script output that you
>>> capture with
>>>
>>> scripts/comprehensive_test.sh >& comprehensive_test.sh.out
>>
>> My lubuntu testing results are attached.
>
> I have identified your platform there as Lubuntu without any version
> string.  If you can identify the Lubuntu version you are using, I
> would like to add it to the report.

I believe that it is "14.04.2 LTS"

-Hazen

Re: [Plplot-devel] Comprehensive testing reports

[Alan W. I. <ir...@be...>]

On 2015-04-13 13:51-0400 Hazen Babcock wrote:

> On 04/12/2015 08:23 AM, Alan W. Irwin wrote:
>> On 2015-04-11 21:05-0400 Hazen Babcock wrote:
>> 
>>> It worked fine without the Qt components. Is there an output file that
>>> I should send?
>> 
>> Excellent news on the Lubuntu front.
>> 
>> To answer your question, please send a compressed tarball containing
>> _all_ environment variables (you can capture a complete list of those
>> from bash using printenv >& printenv.out); the script output that you
>> capture with
>> 
>> scripts/comprehensive_test.sh >& comprehensive_test.sh.out
>
> My lubuntu testing results are attached.

Hi Hazen:

Thanks very much for the requested tarball of information concerning
your comprehensive test of PLplot on Lubuntu.  I have
used that information and the prior information you gave about
hardware version (via uname result) and Qt4 version to create the
latest version of
<https://sourceforge.net/p/plplot/wiki/Testing_PLplot/#Testing%20reports>.

I have identified your platform there as Lubuntu without any version
string.  If you can identify the Lubuntu version you are using, I
would like to add it to the report.

The (g) notes for your platform were derived from your cmake.out file.
In future as time permits you should be able to remove those
limitations on your comprehensive test by installing the mentioned
system components.

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
__________________________

Re: [Plplot-devel] Comprehensive testing reports

[Alan W. I. <ir...@be...>]

On 2015-04-13 14:11-0400 Hazen Babcock wrote:

> On 04/12/2015 08:23 AM, Alan W. Irwin wrote:
>> 
>>> 
>>> Why do you think these Qt components fail in the tests, but work fine
>>> if they are run independently? What is the testing framework doing
>>> that is not being done from the command line?
>> 
>> My guess is nothing explictly different is being done.  Instead, you
>> are dealing with a severe memory management issue which can sometimes
>> (by accident) be symptomless and sometimes can result in segfaults. So
>> segfaults typically imply severe memory management issues, but the
>> converse is not always true. The only completely reliable way I know
>> of to identify severe memory management issues is using valgrind to
>> run the examples.  If such a valgrind run (say on examples/c/x00c -dev
>> pngwidget -o test.png -fam) shows severe memory management issues,
>> then the Qt libraries on Lubuntu are the likely source of this issue.
>> However, if that valgrind run shows no severe memory management issue,
>> but you are getting segfaults on the x00 example with ctest (either
>> run by hand after running "make all" or via the script), then that
>> would be a strong indication that there is something wrong with either
>> our ctest setup or our script.
>
> I've attached my some lubuntu valgrind results for pngqt vs pngcairo.
>
> valgrind ./x00c -dev pngqt -o test.png -fam >& png_qt.txt
> valgrind ./x00c -dev pngcairo -o test.png -fam >& png_cairo.txt
>
> Severe memory management issues means errors greater than 0 in the final 
> ERROR SUMMARY line?

Yes.  Valgrind detecting all those invalid reads is never a good thing even though
this particular way of running the examples gave a symptomless (no segfault) result
by chance.

According to <http://en.wikipedia.org/wiki/Lubuntu>, Lubuntu is an
official Ubuntu variant (unlike Kubuntu which is slightly unofficial).
Just speculating here, but I wonder if Andrew's good results on
Kubuntu are because that deploys a KDE desktop which necessarily means
they must be careful that Qt (heavily used by KDE) is built correctly
while the rest of the Ubuntu variants might be less than careful with
their Qt build since it is only lightly used by those variants?

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
__________________________

Re: [Plplot-devel] Comprehensive testing reports

[Hazen B. <hba...@ma...>]

On 04/12/2015 08:23 AM, Alan W. Irwin wrote:
>
>>
>> Why do you think these Qt components fail in the tests, but work fine
>> if they are run independently? What is the testing framework doing
>> that is not being done from the command line?
>
> My guess is nothing explictly different is being done.  Instead, you
> are dealing with a severe memory management issue which can sometimes
> (by accident) be symptomless and sometimes can result in segfaults. So
> segfaults typically imply severe memory management issues, but the
> converse is not always true. The only completely reliable way I know
> of to identify severe memory management issues is using valgrind to
> run the examples.  If such a valgrind run (say on examples/c/x00c -dev
> pngwidget -o test.png -fam) shows severe memory management issues,
> then the Qt libraries on Lubuntu are the likely source of this issue.
> However, if that valgrind run shows no severe memory management issue,
> but you are getting segfaults on the x00 example with ctest (either
> run by hand after running "make all" or via the script), then that
> would be a strong indication that there is something wrong with either
> our ctest setup or our script.

I've attached my some lubuntu valgrind results for pngqt vs pngcairo.

valgrind ./x00c -dev pngqt -o test.png -fam >& png_qt.txt
valgrind ./x00c -dev pngcairo -o test.png -fam >& png_cairo.txt

Severe memory management issues means errors greater than 0 in the final 
ERROR SUMMARY line? Anyway, it looks like there is some problem with Qt 
and QGtkStyle on lubuntu.

-Hazen

Re: [Plplot-devel] Comprehensive testing reports

[Hazen B. <hba...@ma...>]

On 04/12/2015 08:23 AM, Alan W. Irwin wrote:
> On 2015-04-11 21:05-0400 Hazen Babcock wrote:
>
>> It worked fine without the Qt components. Is there an output file that
>> I should send?
>
> Excellent news on the Lubuntu front.
>
> To answer your question, please send a compressed tarball containing
> _all_ environment variables (you can capture a complete list of those
> from bash using printenv >& printenv.out); the script output that you
> capture with
>
> scripts/comprehensive_test.sh >& comprehensive_test.sh.out

My lubuntu testing results are attached.

-Hazen

[Plplot-devel] Making PLplot releases easier in future

[Alan W. I. <ir...@be...>]

I was confident in early February that the planned release date of
February 28th for PLplot-5.11.0 would be straightforward to achieve,
but obviously the release was delayed 6 weeks beyond that date by a
number of factors. I would prefer to avoid such factors if at all
possible in the future since a sliding release date is extremely
difficult for volunteer developers to adjust to.  All of us have lots
of other things going on in our lives, but with a fixed release date
that everybody knows in advance it is fairly likely most of us can
make an effort for the last week of the release to help get it out the
door.  But all that potential cooperation is out the window when that
single critical week stretches (ouch!) into 7 weeks.

As release manager I have to take responsibility to provide the
guidance to avoid such an issue in the future so below I discuss some
general lessons I have learned from this bad experience, and the
remedies I plan to adopt so this experience is not repeated for
future releases.

Here are the lessons:

1. Keep release cycles short.

Adopting that lesson reduces the chances of regressions creeping in
and creating surprises (as occurred for this release) that
tend to indefinitely delay the release.

2. Create definitive benchmark comprehensive tests for all platforms
accessible to us.

Adopting that lesson will make it much easier for us to detect
regressions in the future.

3. Master branch should be primarily used for bug fixing in
preparation for the next release.

So all major PLplot changes should be implemented on local topic
branches which are shared with those interested in helping with the
initial testing using the "git format-patch"/"git am" approach
mentioned in README.developers.  Only when a topic has completely
matured (i.e., all bugs discovered by initial testing have been fixed)
should it be pushed to master branch for testing and debugging by a
larger group.

4. Pushes of major topics to the master branch should be done
only relatively early in release cycles.

That gives important time for the "testing and debugging by
a larger group" referred to above to take place.

Here are the specific remedies I propose:

1'. Consistent with lesson 1, I propose to get the next release out in
4 months (by mid-August) _at the latest_.  However, an earlier bug-fix
release (say called 5.11.1) that contains only bug fixes and not major
changes is certainly possible if a lot of bug fixing gets done soon.

@Everybody:

Through release testing we uncovered a number of bugs discussed on
this mailing list that we had to put off fixing until post-release.
The time to deal with those known bugs is now.

2'. Consistent with lesson 2, I have already (in a different post)
strongly encouraged everybody here to run
scripts/comprehensive_test.sh on the platforms you have access to and
report those benchmark results to me and/or
<http://sourceforge.net/p/plplot/wiki/Testing_PLplot/#Testing%20Reports>.
When that testing clearly reveals comprehensive_testing.sh issues
(such as Arjen having to brute-force Cygwin to get that script to run)
or build-system issues, I certainly plan to either provide the fix or
provide strong support for finding the fix.

3'. I am going to encourage everybody to use the lesson 3 approach for
further major developments.  This immediately applies to both Arjen
(currently working on a fortran binding rewrite) and Jim (currently
working on major changes to plmeta/plrender and possibly plbuf).

@Arjen and Jim: does this lesson 3 approach work for you?

4'. Consistent with lesson 4, I think pushes of important topics
to the master branch should only be done in the first month
of a release cycle.

@Arjen and Jim:

To be specific I plan to adopt May 9th as the deadline for pushing of
major mature topics to master.  So if you make that deadline, your
work will get into the next release, but if your other time
commitments make it impossible for you to make that deadline, then
please continue to mature your topics as time permits and aim to push
your major topics to master in the first month of the subsequent
release cycle.

@Everybody:

I hope these lessons I have learned and my specific plans to conform
to these lessons makes sense to everybody here.  But if not, I would
welcome further discussion of your own ideas for making the release
process a lot easier for both you and me.

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
__________________________

Re: [Plplot-devel] PLplot-5.11.0 has been released

[Alan W. I. <ir...@be...>]

P.S. The freeze is gone so I look forward to lots of pushes to the
master branch from you guys in the near 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); 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
__________________________

[Plplot-devel] Comprehensive testing reports

[Alan W. I. <ir...@be...>]

On 2015-04-11 21:05-0400 Hazen Babcock wrote:

> It worked fine without the Qt components. Is there an output file that I 
> should send?

Excellent news on the Lubuntu front.

To answer your question, please send a compressed tarball containing
_all_ environment variables (you can capture a complete list of those
from bash using printenv >& printenv.out); the script output that you
capture with

scripts/comprehensive_test.sh >& comprehensive_test.sh.out

; and all shared, nondynamic, and static output_dir contents.  Here are
the files collected in those directories by the script on my own platform:

software@raven> ls ../comprehensive_test_disposeable/*/output_tree/
../comprehensive_test_disposeable/nondynamic/output_tree/:
clean.out                   installed_clean.out                make.out                 traditional_clean.out
clean_ctest_plot_files.out  installed_cmake.out                make_install.out         traditional_make_interactive.out
cmake.out                   installed_make_interactive.out     make_interactive.out     traditional_make_noninteractive.out
ctest.out                   installed_make_noninteractive.out  make_noninteractive.out

../comprehensive_test_disposeable/shared/output_tree/:
clean.out                   installed_clean.out                make.out                 traditional_clean.out
clean_ctest_plot_files.out  installed_cmake.out                make_install.out         traditional_make_interactive.out
cmake.out                   installed_make_interactive.out     make_interactive.out     traditional_make_noninteractive.out
ctest.out                   installed_make_noninteractive.out  make_noninteractive.out

../comprehensive_test_disposeable/static/output_tree/:
clean.out                   installed_clean.out                make.out                 traditional_clean.out
clean_ctest_plot_files.out  installed_cmake.out                make_install.out         traditional_make_interactive.out
cmake.out                   installed_make_interactive.out     make_interactive.out     traditional_make_noninteractive.out
ctest.out                   installed_make_noninteractive.out  make_noninteractive.out

The Qt information you gave before is quite helpful for the report
which I intend to put together concerning Qt segfaults. And so is the
uname info which identifies your hardware as x86_64. (a.k.a AMD64 to
give AMD their due for coming up with that hardware design before
Intel copied it).

However, it would be good if you could also identify the exact Lubuntu
version you are using.  According to
<http://en.wikipedia.org/wiki/Lubuntu> that version number likely
ranges somewhere from 10.04 to 15.04.  On my Debian system, I
can get the Debian version from
/etc/debian_version

which yields 7.8 ==> 8th minor variant of 7th (Debian Wheezy) release
of Debian.

Do you have an equivalent file on your system which identifies the
Lubuntu version?

>
> Why do you think these Qt components fail in the tests, but work fine if they 
> are run independently? What is the testing framework doing that is not being 
> done from the command line?

My guess is nothing explictly different is being done.  Instead, you
are dealing with a severe memory management issue which can sometimes
(by accident) be symptomless and sometimes can result in segfaults. So
segfaults typically imply severe memory management issues, but the
converse is not always true. The only completely reliable way I know
of to identify severe memory management issues is using valgrind to
run the examples.  If such a valgrind run (say on examples/c/x00c -dev
pngwidget -o test.png -fam) shows severe memory management issues,
then the Qt libraries on Lubuntu are the likely source of this issue.
However, if that valgrind run shows no severe memory management issue,
but you are getting segfaults on the x00 example with ctest (either
run by hand after running "make all" or via the script), then that
would be a strong indication that there is something wrong with either
our ctest setup or our script.

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
__________________________

[Plplot-devel] PLplot-5.11.0 has been released

[Alan W. I. <ir...@be...>]

I am happy to report that the PLplot-5.11.0 release process has been
completed.  For more details such as download location, follow the
link at plplot.sf.net to the news item concerning this release.  We
encourage everyone on this mailing list to try this new release.  Once
you have downloaded, gpg-verified, and unpacked the
plplot-5.11.0.tar.gz file, you should pay close attention to the
README.release file since that file contains the all-important notes
for this release.

I thank all the developers that helped with this release, and I would
especially like to point out the meta-contribution made by Hazen
Babcock who suggested (and subsequently followed up with a large
degree of practical help with the transition once we made the
decision) that we move from svn to git as our revision control system
during this release cycle.  From my git newbie perspective last year I
felt that transition slowed PLplot development initially as we all got
used to git, but now I have a lot more git experience, I think it is a
tremendous tool to help our development.  For example, I sense our
pace of development now is much faster than before because of git, and
because of that and because of git features I personally enjoy using,
I would certainly never want to go back to svn.

Enjoy PLplot-5.11.0!

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
__________________________

Re: [Plplot-devel] Release status: last major uncertainty removed

[Alan W. I. <ir...@be...>]

I am happy to report that the epa_built "plplot_lite" comprehensive
test on the MinGW/MSYS/Wine platform completed in 30 hours.  One
component of this test had to be repeated to get good results (see
note (K) at
<https://sourceforge.net/p/plplot/wiki/Testing_PLplot/#Testing%20Reports>).
That repeated test and the rest of the comprehensive tests all gave no
errors so I judge this result to be a success.

Arjen has encountered that parallel-build issue with MSYS before so
from now on (as stated in note (K)) I think we should turn off all
parallel aspects of epa_build on MSYS using the epa_build cmake option
-DNUMBER_PARALLEL_JOBS:STRING=1 which will likely double the time
required to finish this test again in my case (a two-cpu box).  Note,
you should _not_ use this option for Cygwin or MinGW-w64/MSYS2 where
parallel builds should work just fine and make the comprehensive test
finish much more quickly on machines that have more than one cpu.

With regard to the release status, this successful comprehensive test
result for MinGW/MSYS2/Wine removes the last major uncertainty with
this release and the remainder of the release process should just be
"turning the crank" using the instructions in
README.Release_Manager_Cookbook.  So I am hoping my next post here (in
a few hours) will be a report of the actual release.  Meanwhile, (and
of course) the hard freeze on commits to the master branch still exists.

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
__________________________

Re: [Plplot-devel] Release status: call for comprehensive testing

[Hazen B. <hba...@ma...>]

On 04/10/2015 09:06 PM, Alan W. Irwin wrote:
> On 2015-04-10 12:29-0400 Hazen Babcock wrote:
>
>>>
>>> That's a fairly sparse but still acceptable comprehensive test result
>>> for
>>> this release, but to start the next release cycle properly I strongly
>>> encourage everybody here to learn to run the
>>> scripts/comprehensive_test.sh bash script to completion on all
>>> platforms accessible to you (taking the approach that you should
>>> disable any PLplot component that has errors in order to get the
>>> script to complete).  Such tests are encouraged for essentially all
>>> platforms (e.g, MSVC, Cygwin, MinGW/MSYS, MinGW-w64/MSYS2, Mac OS X,
>>> all varieties of Linux distributions, and other Unices).
>>
>> I just tried to run the non-interactive comprehensive tests on lubuntu
>> without success. Perhaps it is because I'm not running the tests
>> properly? The QT devices that are causing the problems work fine if I
>> run them by hand. I looked on the sourceforge wiki but I could not
>> find and instructions on how to do this. Attached is what I tried and
>> the results of the test.
>
> Hi Hazen:
>
> Thanks for helping out with comprehensive testing.
>
> To answer your question, you should look at
> <https://sourceforge.net/p/plplot/wiki/Testing_PLplot/> in general and
> <https://sourceforge.net/p/plplot/wiki/Testing_PLplot/#Comprehensive%20testing>
>
> and
> https://sourceforge.net/p/plplot/wiki/Testing_PLplot/#Testing%20Reports>
> in specific for directions and results concerning comprehensive testing.
>
> The script results require no special setup other than what you do for
> your hand-crafted builds.  Greg had similar problems (but on the
> OpenSUSE platform) with segfaults for all Qt related ctest results.
>
> I suspect these severe memory management issues (which sometimes but
> not always will generate segfaults like you and Greg have seen) have
> nothing to do with PLplot but are instead due to bad Qt libraries or
> bad Qt library dependencies on some platforms. In contrast to your
> result and Greg's I have looked hard at qt results with valgrind on
> Debian stable, and they have no severe memory management issues with
> Qt4.8, and I think Andrew has done the same for his various Debian and
> Ubuntu platforms.  Andrew and I do have different severe memory
> management results for the Qt5 case; I get them with the epa_build of
> Qt5, and he does not for several different distros.  But Qt4 has
> always been completely reliable in this regard for us _for the
> platforms we have access to_.  But this is obviously not the case for
> you and Greg.
>
> Anyhow, for now we are just trying to keep track of exactly which
> platforms have good qt results with Qt4.8 and which do not.  However, we
> are
> also interested in exactly which components of PLplot work for all our
> different major configurations (shared libraries/dynamic devices,
> shared libraries/non-dynamic devices, and static libraries/non-dynamic
> devices. Thus, please try to get the script to finish
> with components removed that are giving trouble.  (I gave that same
> advice to Greg).
>
> So, for example, to
> drop everything Qt related you should specify
>
> --cmake_added_options "DEFAULT_NO_QT_DEVICES=ON -DENABLE_qt=OFF"
>
> when attempting to run scripts/comprehensive_testing.sh again.
>
> Once you get that script to complete, we will note in the
> corresponding report on the Wiki exactly which components had to be
> dropped and why.

It worked fine without the Qt components. Is there an output file that I 
should send?

Why do you think these Qt components fail in the tests, but work fine if 
they are run independently? What is the testing framework doing that is 
not being done from the command line?

-Hazen

Re: [Plplot-devel] Release status: call for comprehensive testing

[Alan W. I. <ir...@be...>]

On 2015-04-10 21:54+0100 Andrew Ross wrote:

> [Hazen's poor qt result is] at odds with my tests a week or so back on Kubuntu
> 14.10.

Hi Andrew:

Could you please report the details of those good comprehensive test
results at
<https://sourceforge.net/p/plplot/wiki/Testing_PLplot/#Testing%20Reports>

Thanks in advance.

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
__________________________

Re: [Plplot-devel] Release status: call for comprehensive testing

[Alan W. I. <ir...@be...>]

On 2015-04-10 12:29-0400 Hazen Babcock wrote:

>> 
>> That's a fairly sparse but still acceptable comprehensive test result for
>> this release, but to start the next release cycle properly I strongly
>> encourage everybody here to learn to run the
>> scripts/comprehensive_test.sh bash script to completion on all
>> platforms accessible to you (taking the approach that you should
>> disable any PLplot component that has errors in order to get the
>> script to complete).  Such tests are encouraged for essentially all
>> platforms (e.g, MSVC, Cygwin, MinGW/MSYS, MinGW-w64/MSYS2, Mac OS X,
>> all varieties of Linux distributions, and other Unices).
>
> I just tried to run the non-interactive comprehensive tests on lubuntu 
> without success. Perhaps it is because I'm not running the tests properly? 
> The QT devices that are causing the problems work fine if I run them by hand. 
> I looked on the sourceforge wiki but I could not find and instructions on how 
> to do this. Attached is what I tried and the results of the test.

Hi Hazen:

Thanks for helping out with comprehensive testing.

To answer your question, you should look at
<https://sourceforge.net/p/plplot/wiki/Testing_PLplot/> in general and
<https://sourceforge.net/p/plplot/wiki/Testing_PLplot/#Comprehensive%20testing>
and
https://sourceforge.net/p/plplot/wiki/Testing_PLplot/#Testing%20Reports>
in specific for directions and results concerning comprehensive testing.

The script results require no special setup other than what you do for
your hand-crafted builds.  Greg had similar problems (but on the
OpenSUSE platform) with segfaults for all Qt related ctest results.

I suspect these severe memory management issues (which sometimes but
not always will generate segfaults like you and Greg have seen) have
nothing to do with PLplot but are instead due to bad Qt libraries or
bad Qt library dependencies on some platforms. In contrast to your
result and Greg's I have looked hard at qt results with valgrind on
Debian stable, and they have no severe memory management issues with
Qt4.8, and I think Andrew has done the same for his various Debian and
Ubuntu platforms.  Andrew and I do have different severe memory
management results for the Qt5 case; I get them with the epa_build of
Qt5, and he does not for several different distros.  But Qt4 has
always been completely reliable in this regard for us _for the
platforms we have access to_.  But this is obviously not the case for
you and Greg.

Anyhow, for now we are just trying to keep track of exactly which
platforms have good qt results with Qt4.8 and which do not.  However, we are
also interested in exactly which components of PLplot work for all our
different major configurations (shared libraries/dynamic devices,
shared libraries/non-dynamic devices, and static libraries/non-dynamic
devices. Thus, please try to get the script to finish
with components removed that are giving trouble.  (I gave that same
advice to Greg).

So, for example, to
drop everything Qt related you should specify

--cmake_added_options "DEFAULT_NO_QT_DEVICES=ON -DENABLE_qt=OFF"

when attempting to run scripts/comprehensive_testing.sh again.

Once you get that script to complete, we will note in the
corresponding report on the Wiki exactly which components had to be
dropped and why.

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
__________________________

Re: [Plplot-devel] Release status: call for comprehensive testing

[Hazen B. <hba...@ma...>]

On 04/10/2015 04:54 PM, Andrew Ross wrote:
>
> Hazen,
>
> That's interesting, and at odds with my tests a week or so back on Kubuntu
> 14.10. Can you confirm which flavour and version of Ubuntu you are using?
> Also, I assume this is with Qt4 and not Qt5?
>

Andrew,

This is what I have:
hb ~$ uname -a
Linux hbabcock-laptop2 3.13.0-49-generic #81-Ubuntu SMP Tue Mar 24 
19:29:48 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux

hb ~$ qmake --version
QMake version 2.01a
Using Qt version 4.8.6 in /usr/lib/x86_64-linux-gnu

-Hazen

Re: [Plplot-devel] Release status: call for comprehensive testing

[Andrew R. <and...@us...>]

Hazen,

That's interesting, and at odds with my tests a week or so back on Kubuntu
14.10. Can you confirm which flavour and version of Ubuntu you are using?
Also, I assume this is with Qt4 and not Qt5?

Andrew

On Fri, Apr 10, 2015 at 12:29:15PM -0400, Hazen Babcock wrote:
> >
> >That's a fairly sparse but still acceptable comprehensive test result for
> >this release, but to start the next release cycle properly I strongly
> >encourage everybody here to learn to run the
> >scripts/comprehensive_test.sh bash script to completion on all
> >platforms accessible to you (taking the approach that you should
> >disable any PLplot component that has errors in order to get the
> >script to complete).  Such tests are encouraged for essentially all
> >platforms (e.g, MSVC, Cygwin, MinGW/MSYS, MinGW-w64/MSYS2, Mac OS X,
> >all varieties of Linux distributions, and other Unices).
> 
> I just tried to run the non-interactive comprehensive tests on lubuntu
> without success. Perhaps it is because I'm not running the tests properly?
> The QT devices that are causing the problems work fine if I run them by
> hand. I looked on the sourceforge wiki but I could not find and instructions
> on how to do this. Attached is what I tried and the results of the test.
> 
> best,
> -Hazen
> 

Re: [Plplot-devel] Release status: call for comprehensive testing

[Hazen B. <hba...@ma...>]

>
> That's a fairly sparse but still acceptable comprehensive test result for
> this release, but to start the next release cycle properly I strongly
> encourage everybody here to learn to run the
> scripts/comprehensive_test.sh bash script to completion on all
> platforms accessible to you (taking the approach that you should
> disable any PLplot component that has errors in order to get the
> script to complete).  Such tests are encouraged for essentially all
> platforms (e.g, MSVC, Cygwin, MinGW/MSYS, MinGW-w64/MSYS2, Mac OS X,
> all varieties of Linux distributions, and other Unices).

I just tried to run the non-interactive comprehensive tests on lubuntu 
without success. Perhaps it is because I'm not running the tests 
properly? The QT devices that are causing the problems work fine if I 
run them by hand. I looked on the sourceforge wiki but I could not find 
and instructions on how to do this. Attached is what I tried and the 
results of the test.

best,
-Hazen

[Plplot-devel] Release status: call for comprehensive testing

[Alan W. I. <ir...@be...>]

I have just (as of commit id 99fe5f0) finished the part of
README.Release_Manager_Cookbook entitled "Create (a preliminary
version of) the release tarball and check the result for errors".

No errors were discovered during this process, and I have had success
doing everything before this step in README.Release_Manager_Cookbook
so this means current master tip should be very close to release
ready.

Accordingly, I plan to start a fairly broad (including all soft
dependencies of plplot_lite thanks to epa_build) comprehensive test of
of PLplot on MinGW/MSYS/Wine within the hour.  Due to the slow nature
of Wine, that test will take roughly 3 days if it completes without
failures. Therefore, the release should occur Monday if that test
succeeds.  I think there is a pretty good chance of that because of my
prior success with this test a year ago, and Arjen's recent success
with a narrower comprehensive test of MinGW/MSYS on Microsoft Windows.
But if that test fails, I will view that as a release-critical
regression and delay the release until the problem is fixed.

Therefore, at the time when this current release finally occurs we
should have good comprehensive test reports for Debian stable (one I
have done directly and one I have done via epa_build), Cygwin (Arjen),
and MinGW/MSYS (one by Arjen, and the current one planned by me).

That's a fairly sparse but still acceptable comprehensive test result for
this release, but to start the next release cycle properly I strongly
encourage everybody here to learn to run the
scripts/comprehensive_test.sh bash script to completion on all
platforms accessible to you (taking the approach that you should
disable any PLplot component that has errors in order to get the
script to complete).  Such tests are encouraged for essentially all
platforms (e.g, MSVC, Cygwin, MinGW/MSYS, MinGW-w64/MSYS2, Mac OS X,
all varieties of Linux distributions, and other Unices).

I believe that effort is important since those results would establish
important benchmarks to guard against platform regressions during the
course of the next release cycle and also us to fix some of those
build-system platform-dependent issues during the next release cycle.
Finally, reporting such results at
<https://sourceforge.net/p/plplot/wiki/Testing_PLplot/#Testing%20Reports>
now or in the early parts of the next release cycle would certainly
encourage others to try PLplot-5.11.0 on the platforms that are
reported at that URL.

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
__________________________

[Plplot-devel] Download statistics for 5.10.0

[Alan W. I. <ir...@be...>]

To get a feel for how popular PLplot is you should go to the file
release area for 5.10.0 and click on the "Downloads/week" statistics
menu item which allows you to change that statistic to any date
range, plot download counts versus time, OS counts for a given time
range, country of origin counts
for a given time range, etc.

I have just done that, and it turns our there are ~8000 downloads of
plplot-5.10.0 since its release 14 months ago.  Binary use of PLplot
on Linux and Mac OS X free software distributions is typically larger
than that download statistic.  Which means our efforts to get out the
next release of plplot-5.11.0 has a very large potential audience.

If you look at OS, Unknown + Linux is 50%, Windows is 43
per cent, Mac OS X is 7%, and the rest round to 0%.  Mentally
assigning Unknown to the Linux OS is probably a pretty safe assumption
since Linux has so many different methods (e.g., wget, curl, sftp, and
different browsers) you can use for downloads, and SF heuristics for
determining OS likely assign Unknown OS to many of those download
methods.  But number 1 versus 2 doesn't really matter; the important
point is both Linux and Windows are very important to us, and I am
glad we have strong contingents of developers who support those
platforms.

The one obvious negative in those download statistics is the relative
small fraction of PLplot users on Mac OS X even though that platform
is used a lot (in my experience) by scientists.  Perhaps binary use
there is a lot higher than download+build use.  But I would feel a lot
better about the Mac OS X situation if, for example, we had
comprehensive testing results for that platform supporting the idea
that PLplot builds are a straightforward experience on that platform.

If you look at country of origin, those downloads occurred for ~100
different countries (or ~60 different countries if you only count
those with more than 10 downloads during the 14 months). China, Japan,
India, Russia, and Korea are in the top 15 countries so I think the
word is beginning to spread that our internationalization capabilities
(i.e., the CTL [complex text layout] capabilities available for our
cairo, qt, and svg device drivers) are working well for those who want
to annotate their plots in their native language script.

Anyhow, these download statistics for 5.10.0 provide a lot of food for
thought and are a nice motivator for me to finish up
the 5.11.0 release!

Alan
__________________________
Alan W. Irwin

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

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

Linux-powered Science
__________________________

Re: [Plplot-devel] Comprehensive testing: reports

[Arjen M. <Arj...@de...>]

Hi Alan,



I have reviewed your report and added some nuances (the doubly quoted notes). The new notes C'' and F'' are the ones we should be tackling post-release, I think.



Regards,



Arjen

> -----Original Message-----
> From: Alan W. Irwin [mailto:ir...@be...]
> Sent: Tuesday, April 07, 2015 11:14 PM
> To: Arjen Markus
> Cc: PLplot development list
> Subject: Comprehensive testing: reports
>
> Hi Arjen:
>
> Please review the part of
> <https://sourceforge.net/p/plplot/wiki/Testing_PLplot/#Testing%20Reports>
> that summarizes your MinGW/MSYS tests and Cygwin tests and update if
> necessary

DISCLAIMER: This message is intended exclusively for the addressee(s) and may contain confidential and privileged information. If you are not the intended recipient please notify the sender immediately and destroy this message. Unauthorized use, disclosure or copying of this message is strictly prohibited. The foundation 'Stichting Deltares', which has its seat at Delft, The Netherlands, Commercial Registration Number 41146461, is not liable in any way whatsoever for consequences and/or damages resulting from the improper, incomplete and untimely dispatch, receipt and/or content of this e-mail.

Re: [Plplot-devel] Comprehensive testing: reports

[Arjen M. <Arj...@de...>]

Hi Alan,



> -----Original Message-----
> From: Alan W. Irwin [mailto:ir...@be...]
> Sent: Tuesday, April 07, 2015 11:14 PM
> To: Arjen Markus
> Cc: PLplot development list
> Subject: Comprehensive testing: reports
>
> Hi Arjen:
>
> Please review the part of
> <https://sourceforge.net/p/plplot/wiki/Testing_PLplot/#Testing%20Reports>
> that summarizes your MinGW/MSYS tests and Cygwin tests and update if
> necessary.  For example, I was guessing (note (a)) about the hardware type used for
> your tests.  Also, please add a note (B) to your MinGW/MSYS report if in fact that
> was the reason you didn't try interactive tests in that case (as opposed to deciding to
> drop the interactive part of the MinGW/MSYS tests to speed them up which requires
> no note).
>
I will have a look at this.

Regards,

Arjen





DISCLAIMER: This message is intended exclusively for the addressee(s) and may contain confidential and privileged information. If you are not the intended recipient please notify the sender immediately and destroy this message. Unauthorized use, disclosure or copying of this message is strictly prohibited. The foundation 'Stichting Deltares', which has its seat at Delft, The Netherlands, Commercial Registration Number 41146461, is not liable in any way whatsoever for consequences and/or damages resulting from the improper, incomplete and untimely dispatch, receipt and/or content of this e-mail.

[Plplot-devel] Comprehensive testing: reports

[Alan W. I. <ir...@be...>]

Hi Arjen:

Please review the part of 
<https://sourceforge.net/p/plplot/wiki/Testing_PLplot/#Testing%20Reports>
that summarizes your MinGW/MSYS tests and Cygwin tests and update if
necessary.  For example, I was guessing (note (a)) about the hardware
type used for your tests.  Also, please add a note (B) to your
MinGW/MSYS report if in fact that was the reason you didn't try
interactive tests in that case (as opposed to deciding to drop the
interactive part of the MinGW/MSYS tests to speed them up which requires no
note).

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
__________________________

Re: [Plplot-devel] Comprehensive testing: OpenSuse-13.2: finding stuff

[Arjen M. <Arj...@de...>]

Hi Alan,



> -----Original Message-----
> From: Alan W. Irwin [mailto:ir...@be...]
>
> Thanks very much for that help with comprehensive testing on the MinGW/MSYS
> platform.  And the extra result you included with the tarball which was the script
> actually used to set up the environment variables for the test was very helpful as well.
> Post-release we should try and figure out why you need to do that massaging, and
> use --do_test_interactive no while I do not. That is a narrow (since many soft
> dependencies of PLplot are missing) but still extremely useful comprehensive test
> result for MinGW/MSYS which I will post to the wiki.
>

I gave priority to getting the comprehensive tests to run over completeness ;).

> Just out of curiosity, roughly how much time did this comprehensive test take to
> complete?  I bet it was substantially less than the ~3 days a similar test takes on
> Wine!
>
Well, my tests - once they were running - took something like one or two hours, which makes it a lot more practical to do of course.

Regards,

Arjen



DISCLAIMER: This message is intended exclusively for the addressee(s) and may contain confidential and privileged information. If you are not the intended recipient please notify the sender immediately and destroy this message. Unauthorized use, disclosure or copying of this message is strictly prohibited. The foundation 'Stichting Deltares', which has its seat at Delft, The Netherlands, Commercial Registration Number 41146461, is not liable in any way whatsoever for consequences and/or damages resulting from the improper, incomplete and untimely dispatch, receipt and/or content of this e-mail.

Re: [Plplot-devel] Comprehensive testing: OpenSuse-13.2: finding stuff

[Alan W. I. <ir...@be...>]

On 2015-04-05 14:13-0000 Arjen Markus wrote:

> Hi Alan,
>
>
>
> I had some time today, so I decided to put some effort into the comprehensive test for MinGW/MSYS. Please see the attached tarball. Things are looking good, even though this case requires a wee bit of massaging.

Hi Arjen:

Thanks very much for that help with comprehensive testing on the
MinGW/MSYS platform.  And the extra result you included with the
tarball which was the script actually used to set up the environment
variables for the test was very helpful as well. Post-release we
should try and figure out why you need to do that massaging, and use
--do_test_interactive no while I do not. That is a narrow (since many
soft dependencies of PLplot are missing) but still extremely useful
comprehensive test result for MinGW/MSYS which I will post to the
wiki.

Just out of curiosity, roughly how much time did this comprehensive test take
to complete?  I bet it was substantially less than the ~3 days a similar
test takes on Wine!

Note I still intend to do that long Wine test before the release.  The
previous time I did that test was early in this release cycle roughly
a year ago.  At that point, both --do_test_traditional_install_tree
yes --do_test_interactive yes worked for me (the former because
pkg-config was available to me via epa_build), and epa_build provided
some important PLplot soft dependencies (i.e, dependencies which are
not absolutely critical but which enhance the power of PLplot) such as
swig, pkg-config, qhull, Tcl, and shapelib. Also, I was able to get
the python binding and examples to work using a downloaded binary
python for Windows.  So I ended up doing a comprehensive test of
PLplot on MinGW/MSYS using a substantial number of PLplot components,
and I feel it is important to repeat that test to make sure no
regressions in those good results for those components have been
introduced in this release cycle.

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
__________________________