On 2007-07-02 01:02-0700 Jerry wrote: > > On Jul 1, 2007, at 7:49 PM, Alan W. Irwin wrote: > >> Thus, by analogy with the python case I feel the Ada thin binding >> should be >> completely ignored in both the thick and traditional examples. Of >> course, >> by ignoring the thin binding in the examples we lose the option of >> using the >> full-argument variation of the function calls in the examples, but >> that is a >> good thing since the redacted form in the traditional and thick >> interfaces >> makes more sense, and I don't think we currently use the full-argument >> variation right now in any case. Of course, to make ignoring the thin >> interface in the examples work, you would have to define >> PL_PARSE_FULL and >> String_80 directly for the traditional binding, but I assume that >> is all you >> would have to do, and the change should therefore be easy for you to >> implement. > > This is probably a good policy since we're so close anyway. There are > maybe a dozen subprograms that I would pull from thin binding and put > into the the other two bindings. There are also all of the constants > in the thin binding that would need to be viewable in the two main > bindings. These constants are from two sources: the DEFINEs from the > C source and the constants that I added to add a bit of abstraction > to several integers which do not represent inherently integer > quantities (e.g., Red is not 1). It looks like there are 79 such > constants. I should be able to pull those out and put them into the > main bindings, while leaving them behind in the thin binding (and > thus having the thin binding be nearly-exact correspondence to the C > code) as they are now protected by the thin binding's namespace.
Propagating the abstract constants that are DEFINEd in our C source to the thick and traditional bindings sounds like the right thing to do. However, we should discuss your additional abstracted constants. For example, I suggest you should drop all the colour abstraction since that is actually misleading. plcol0(1) says use the first index of colour map0 for all future plotting (lines, etc.) that involves cmap0. By default the first index of cmap0 refers to a red colour, but that first index (or any other index in cmap0) can easily be changed to a different colour using, e.g., plscol0 (http://plplot.sourceforge.net/docbook-manual/plplot-html-5.7.3/plscol0.html). So with colour abstraction you could end up with the situation that plcol0(Red) sets future line drawing to a blue colour! (Aside: If your remaining constant abstractions are useful, then I believe they should be in the C code. Do you have a list of abstracted constants (sans colours, see above) that we could look at for possible inclusion in the C code?) > > Of course the thin binding will still have to be accessed with the > "with PLplot_Thin" clause. Of course, that's true for the code in the thick and traditional bindings, but does Ada demand such a clause in the examples once all references to the thin binding are completely eliminated from the examples? (Just curious about the answer here. I would like to eliminate the clause if Ada does not require it, but if for some reason Ada does require it in our examples, then I can live with it.) 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 DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ _______________________________________________ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
