From: Jerry <lan...@qw...> - 2006-10-25 23:30:00
Attachments:
Plplot_odd.pdf
|
I have encountered a repeatable problem when using my Ada binding to PLplot, and I'm wondering if it is something that I've done wrong with the binding. I've narrowed down a specific example, but the general problem is (a) the horizontal axis of 2D plots (linear or log, at least) is drawn purple, and (b) when there are more than a certain number of data points to be drawn, the purple line that overlays the horizontal axis swings up to the top of the plot and then back down to the axis. (Other glitch-types are possible, but this is typical.) In the specific case, I am drawing a single sine wave. When the number of points is 286 or less, there is no glitch. When the number of data points is 286 or more, the glitches appear at the right-hand side of the plot, with approximately one-half "cycle" of glitches for each point over 285. I'm working with OS X and the problem appears exactly the same whether using AquaTerm, X11, Postscript color file or Postscript monochrome (but obviously without the purple color). I believe I'm using 5.5.3. I've attached a PDF which shows the problem when the number of points is 297. With thousands of points, the upper part of the plot is essentially obscured by purple and some errant lines go downward and some even to the edge of the drawing region, beyond the "data part" of the plot. Jerry |
From: Alan W. I. <ir...@be...> - 2006-10-26 01:52:53
|
On 2006-10-25 16:29-0700 Jerry wrote: > I have encountered a repeatable problem when using my Ada binding to PLplot, > and I'm wondering if it is something that I've done wrong with the binding. I suggest the best general approach for debugging a new interface is to create or modify a C example to recreate the exact C library conditions that are giving you errors for your interface example. Assuming that the C example works and your interface example does not, that very much narrows the source of the problem to either the way you wrote your example in the interface language or the programming of the interface itself. In any case, for every new interface we strongly encourage making a complete set of standard examples following what is done in examples/c. The postscript result from each C example and the corresponding interface example should (ideally) be identical (although sometimes there are single-digit rounding differences). The approach of trying to mimic the simplest C examples and gradually moving to the more complicated ones often helps to isolate interface issues. Also, you might want to try valgrind. That is a great tool for figuring out memory management issues (if those happen to be the source of some/all of your difficulties). 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 Yorick front-end to PLplot (yplot.sf.net); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ |
From: Jerry <lan...@qw...> - 2006-10-27 22:47:09
|
On Oct 25, 2006, at 6:51 PM, Alan W. Irwin wrote: > On 2006-10-25 16:29-0700 Jerry wrote: > >> I have encountered a repeatable problem when using my Ada binding >> to PLplot, >> and I'm wondering if it is something that I've done wrong with the >> binding. > > I suggest the best general approach for debugging a new interface > is to > create or modify a C example to recreate the exact C library > conditions that > are giving you errors for your interface example. Assuming that the > C example works and your interface example does not, that very much > narrows > the source of the problem to either the way you wrote your example > in the > interface language or the programming of the interface itself. > > In any case, for every new interface we strongly encourage making a > complete > set of standard examples following what is done in examples/c. The > postscript result from each C example and the corresponding interface > example should (ideally) be identical (although sometimes there are > single-digit rounding differences). The approach of trying to > mimic the > simplest C examples and gradually moving to the more complicated > ones often > helps to isolate interface issues. > > Also, you might want to try valgrind. That is a great tool for > figuring out > memory management issues (if those happen to be the source of some/ > all of > your difficulties). > > Alan > __________________________ > Alan W. Irwin Problem solved. Operator error. Thanks for your comment. Jerry |