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