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