On 2011-01-03 00:33-0800 Alan W. Irwin wrote: > Here are the swig-generated octave bindings diff results as of revision > 11431: > > octave > Missing examples : 19 33 > Differing postscript output : 04 18 26 > Missing stdout : > Differing stdout :
Here are the same diff test results as of revision 11456 octave Missing examples : 19 Differing postscript output : 04 26 Missing stdout : Differing stdout : In particular note that example 33 (full of pllegend calls) has been implemented (starting from the python template for example 33) in octave and gives (with the swig-generated results since the matwrapped ones are unable to deal with the pllegend argument list) identical results to the corresponding C results. I plan to update octave examples 4 and 26 today (those updates also involve pllegend so I will be removing those examples from the matrapped list of examples to test) to eliminate the above differences for those examples. One octave issue I had to solve before I could produce the above results was the global symbol problem. Our octave examples currently contain some statements setting up variables to mimic the PLplot constants such as PL_NOTSET = -42.0 in x31c.m. The reason for such statements was the previous version of plplot_octave_def was much too limited and only set up a small subset of the global PLplot constants. I now generate plplot_octave_def from the #define's in bindings/swig-support/plplotcapi.i using a sed script which means, for example, the above statement can be replaced by global PL_NOTSET without having to refer to any specific value in the example. (This improvement should also work for the matwrapped case). This change made the implementation of example 33 much less error-prone because a large number of global PLplot constants are used in that example. Some concern has been expressed here before about how to interface the array of strings (const char **) arguments in pllegend for each language. When working on this question for octave, I realized this is an easy issue for most languages. All you have to do is copy a lot of what is done for that similar sort of argument for plstripc (which specifically has 4 elements rather than nlegend elements but otherwise is the same). So don't let that concern discourage you from creating pllegend API and updating examples 4 and 26 and creating example 33 to test and demonstrate pllegend for your favorite language. :-) Ironically, it turns out for the octave case that interfacing const char ** arguments was a new issue that had to be solved largely from scratch. For that language, plstripc has a different API which uses 4 character string arguments rather than the array of 4. Thus, I was breaking into new territory with pllegend. I started out with little familiarity with octave so it took me a while to figure out what to do, but I finally solved the issue as you can see above. There is still one more variation that needs doing with interfacing the const char ** arguments for octave. I got the above good result for example 33 using a charMatrix type of octave argument. Those type of chacter string arrays are the ones which most octave users are familiar with. However, such string arrays are clumsy to handle from the octave side (as you can see from x33c.m, where there is a lot of fooling around with the text and symbols matrices to get them to behave properly). The fundamental issue with this approach is unsigned char attributes have been imposed on what are considered to be numerical matrices with a uniform number of columns corresponding to the characters in the strings. So, for example, all character strings in the array are padded with blanks to equal the length of the longest character string in the array. An alternative, much more natural approach to using character string arrays from octave is to store the character strings as elements of an octave cell array. So implementing the char ** alternative for that style of string array storage is on my near-term octave agenda. familiar with octave. The final octave concern of interest to me is the lack of help results I mentioned previously for the swig-generated case. Andrew has kindly found a swig-based method of dealing with that issue which I hope to implement in the next few days. So in sum, I am going to be busy with the swig-generated bindings for octave for something like another week, but at least the end is finally in sight (except for the implementation of example 19 which I will be leaving for someone else to do). I also want to comment that through my experiments with octave, I now realize just what a powerful and useful platform it is which obviously deserves an absolutely first-class PLplot implementation. I feel we are well along toward that goal now. The Octave PLplot bindings and low-level (x??c.m) standard example fundamentals are obviously rounding into shape using a swig-based approach which has already gone substantially beyond what is possible with the matwrapped approach. Furthermore, Andrew has expressed interest off-list in making the high-level octave interface first class as well once he gets a breathing space to work on PLplot again, and that is an extremely encouraging sign for the future of PLplot on octave. 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 __________________________ ------------------------------------------------------------------------------ Gaining the trust of online customers is vital for the success of any company that requires sensitive data to be transmitted over the Web. Learn how to best implement a security strategy that keeps consumers' information secure and instills the confidence they need to proceed with transactions. http://p.sf.net/sfu/oracle-sfdevnl _______________________________________________ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
