From: Jerry <lan...@qw...> - 2007-09-28 08:46:50
|
I'd like to raise a possibility about a better way to handle the Ada bindings. Here's the deal. There has been a recent new standard for the Ada language, known frequently as Ada 2005, Ada 05, Ada 2007 or Ada 07. (The most frequent is Ada 2005 although the standard was not officially approved until 2007, as I understand it. The first Ada is known as Ada 83.) Ada 2007 has added a numerics capability described in the Ada Reference Manual in Annex G.3. It provides, among other things, "official" declarations for vectors and matrices. I want to let the PLplot bindings use those declarations if the user is using an Ada 2007 compiler; otherwise, I declare them myself in the bindings. There are only two lines of declarations but the the "with" clauses need to be adjusted in several files. ("with" is a little like "include" in C.) I could just leave my own declarations in, even for Ada 2007 compilers, but I really want to take advantage of the language to the maximum extent possible, and to reduce the likelihood of there being confusion (in the Ada 2007 case) of whether the user needs to use my declarations or the Annex G.3 declarations. The way that I have handled this so far is to comment lines in or out as necessary. The bindings as included in PLplot so far have been for Ada 95. For my own use (non-PLplot development), I edit the source code to be compatible with Ada 2007. I don't think this is a good solution. I asked the comp.lang.ada list about this. There were several solutions offered and several of them depended on using GNAT functionality that lies outside the compiler proper. (GNAT is gnu Ada.) For example, a GNAT preprocessor was mentioned as was a GNAT project file which would select different source files depending on the compiler type. In writing the bindings, I have not made them GNAt- dependent except for one little spot which should be easy to fix--I would prefer to not add more GNAT dependency by requiring a GNAt preprocessor or GNAT project file but rather keep the bindings so that they work for any Ada compiler. Since the c.l.a. list strongly suggested, in any case, multiple source files, it seems to me that we could take one of two routes. One is for me to supply two sets of files, one that compiles with Ada 95 and one that compiles with Ada 2007. Since there are already a number of files (three bindings of two files each and two auxiliary files), I would do this by a bit of sed trickery, I suppose--sort of a little non-GNAT preprocessor. This would require some kludgey file naming but should work. The other way, very similar, would for me to keep the same number of binding files and let the build system take care of the sed stuff and create derived files with standardized names. These two approaches also have the advantage that nobody has to bother themselves with any extra-compiler GNAT stuff. The differences in the sources for the two scenarios is really quite small. I could figure out how to write the source files to make the sed easy, and create the sed myself, but someone else would need to incorporate it into the build system. I suppose, if necessary, we could just supply Ada 95 bindings since there probably aren't very many people using Ada 2007 yet. I haven't thought through this very much mainly because I don't know what is necessary or possible with the build system or how much work this would require. However, I want to bring this up because I realized that I think that I have been inadvertently (and ignorantly) ignoring this problem. Sorry for making a fuss this close to a release. I wouldn't mind if this issue slipped past the pending release, but would prefer to see it resolved. Jerry |
From: Alan W. I. <ir...@be...> - 2007-09-28 17:46:17
|
On 2007-09-28 01:46-0700 Jerry wrote: > [...]Since the c.l.a. list strongly suggested, in any case, multiple > source files, it seems to me that we could take one of two routes. > One is for me to supply two sets of files, one that compiles with Ada > 95 and one that compiles with Ada 2007. Since there are already a > number of files (three bindings of two files each and two auxiliary > files), I would do this by a bit of sed trickery, I suppose--sort of > a little non-GNAT preprocessor. This would require some kludgey file > naming but should work. > > The other way, very similar, would for me to keep the same number of > binding files and let the build system take care of the sed stuff and > create derived files with standardized names. > > These two approaches also have the advantage that nobody has to > bother themselves with any extra-compiler GNAT stuff. The differences > in the sources for the two scenarios is really quite small. I could > figure out how to write the source files to make the sed easy, and > create the sed myself, but someone else would need to incorporate it > into the build system. Here is what I believe is needed from the CMake perspective in order to deal with versioned Ada bindings. (1) Add an OPTION command to cmake/modules/ada.cmake which allows the user to specify if they have an ada system that is capable of Ada 2007. See example below. (2) It is a trivial matter for cmake to configure Ada bindings files using the CONFIGURE_FILE command. A most extensive example of a file to be configured is test/plplot-test.sh.cmake. The CONFIGURE_FILE command in test/CMakeLists.txt replaces the many different place-holders (variables surrounded by @ signs) by the value of the corresponding CMake variable, and it would be straightforward to set up something similar in bindings/ada/CMakeLists.txt. This placeholder replacement functionality is similar to the sed approach you outlined above but with the advantage that it is native to cmake. Jerry, to get this rolling what I need from you are the configurable Ada bindings files with @CMake_variable_name@ placeholders in them. You should send that as a normal patch on the existing bindings files. You should also send me a list of the placeholder CMake variable names (please start each one of them with ADA so they don't clash with other CMake variable names) and the strings those placeholders should be changed to in the two cases of HAVE_ADA_2007=OFF or ON. To make life simple for me, please put this into a patch for cmake/modules/ada.cmake. The changes should look like this: option(HAVE_ADA_2007 "Ada 2007?" OFF) if(HAVE_ADA_2007) set(ADA_whatever1 "replacement string for Ada 2007 case") ... else(HAVE_ADA_2007) set(ADA_whatever1 "replacement string for non Ada 2007 case") ... endif(HAVE_ADA_2007) where you should replace the ADA_whatever1 variable with a series of the appropriate placeholder variable names that you have embedded into the Ada bindings files. Once you send me the requested patch there will be more for me to do to get this all to work, but it should be straightforward. 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 __________________________ |
From: Alan W. I. <ir...@be...> - 2007-10-14 17:05:08
|
On 2007-09-28 10:45-0700 Alan W. Irwin wrote: > On 2007-09-28 01:46-0700 Jerry wrote: >> >> The other way, very similar, would for me to keep the same number of >> binding files and let the build system take care of the sed stuff and >> create derived files with standardized names.[...] > > Here is what I believe is needed from the CMake perspective in order to > deal with versioned Ada bindings. [...] > Once you send me the requested patch there will be more for me to do > to get this all to work, but it should be straightforward. Jerry did send me the requested patch, and I have just finished the additional work to get this integrated into our build system. The result is that all bindings/ada/*.ad?.cmake files in the source tree are configurable now and cmake puts the configured Ada source results (without .cmake suffix) into the corresponding directory in the build tree with the build system adjusted appropriately to account for the new location. The changed build system for Ada bindings and examples seems to work fine on my platform (Debian oldstable), and I have committed these changes as of revision 7929. Those who have tested Ada before on your platforms, please test again since a stable release is coming soon. The only Ada issue I am aware of at this time is Ada example 5 has different colours than the corresponding C example. The colour setting for example 5 is completely straightforward so it's probable that this issue is caused by some subtle colour bug in the Ada bindings used by example 5. Anyhow, Jerry is still working on tracking down this issue. I don't think the 5.8.0-RC1 and 5.8.0 releases should be delayed by this issue (in case Jerry cannot fix it in time for the releases) since the Ada bindings and examples are classified as experimental in any case. Assuming the platform testing of these Ada changes and the platform testing (especially Orion's Fedora platform) of the recent octave changes goes well, I think we are ready for the release of 5.8.0-RC1 (to be followed a week or so later by 5.8.0 if the testing of the release candidate shows no showstopper issues). Hazen, what are your timing constraints for these releases? 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 __________________________ |
From: Hazen B. <hba...@ma...> - 2007-10-17 01:21:35
|
On Oct 14, 2007, at 1:03 PM, Alan W. Irwin wrote: > On 2007-09-28 10:45-0700 Alan W. Irwin wrote: > > Assuming the platform testing of these Ada changes and the platform > testing > (especially Orion's Fedora platform) of the recent octave changes > goes well, > I think we are ready for the release of 5.8.0-RC1 (to be followed a > week or > so later by 5.8.0 if the testing of the release candidate shows no > showstopper issues). > > Hazen, what are your timing constraints for these releases? How about this coming weekend for RC1? -Hazen |
From: Alan W. I. <ir...@be...> - 2007-10-17 02:29:24
|
On 2007-10-16 21:18-0400 Hazen Babcock wrote: > > On Oct 14, 2007, at 1:03 PM, Alan W. Irwin wrote: > >> On 2007-09-28 10:45-0700 Alan W. Irwin wrote: >> >> Assuming the platform testing of these Ada changes and the platform >> testing >> (especially Orion's Fedora platform) of the recent octave changes goes >> well, >> I think we are ready for the release of 5.8.0-RC1 (to be followed a week >> or >> so later by 5.8.0 if the testing of the release candidate shows no >> showstopper issues). >> >> Hazen, what are your timing constraints for these releases? > > How about this coming weekend for RC1? I am not aware of any active PLplot development work right now so unless somebody speaks up quickly this coming weekend sounds fine to me. I encourage everybody here to do as much platform testing as possible between now and RC1. We have had a recent bad report for 5.7.4 on Cygwin so I especially hope those here with access to that platform will test 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 __________________________ |