Some of the discussion of the swig/octave incompatibilities is being
CC'd to the Plplot list (and therefore bouncing to me as list
coordinator). I don't promise to forward all of them, but this
particular message seemed quite important to me, where the octave
developers are going to provide (starting with 3.8.1) at least major,
minor, and patch integer version numbers that are useful for
preprocessing (as opposed to a concatanated version string that is
useless for preprocessing).
My hope is the Swig developers will eventually accept the compromise provided by
these new macros, and adjust swig accordingly. But this would be the
long-term solution and PLplot needs a short-term solution similar to the
one I described previously to deal with octave-3.8.0. Andrew?
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); the Time
Ephemerides project (timeephem.sf.net); PLplot scientific plotting
software package (plplot.sf.net); 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
__________________________
--- Begin Message ---
On 01/07/2014 06:24 AM, Jordi Gutiérrez Hermoso wrote:
-------- Original Message --------
Subject: [swig:bugs] #1353 Octave 3.8.0 support
Date: Sun, 05 Jan 2014 13:45:11 +0000
From: William Fulton <[email protected]>
Reply-To: [swig:bugs] <[email protected]>
To: [swig:bugs] <[email protected]>
APIs always change even if not intentional, someone will someday
mess up and we will need an API version number to fix these kind of
errors.
I don't understand. What use is an API version number if two
unintentionally different APIs have the same version number? Our
argument is that you can't trust API version numbers at all, which is
why you test for features, not numbers.
I checked in the following changeset:
http://hg.savannah.gnu.org/hgweb/octave/rev/b6b6e0dc700e
This will be part of the 3.8.1 release. So if
OCTAVE_API_VERSION_NUMBER is defined, you can do what you did before.
If you have OCTAVE_{MAJOR,MINOR,PATCH}, you can check for features in
3.8.1 and later. If none of these are defined, then you have 3.8.0.
At least the version number will change with each release. As Jordi
is trying to tell you, sometimes we have accidentally made changes and
forgotton to update the API version number. Well, nobody's perfect...
Of course, even the version number won't help with development
versions where pretty much anything goes and we certainly aren't
changing the version number for each hg commit, so I don't know how to
help you there. But then again, OCTAVE_API_VERSION_NUMBER was not
reliable for development versions either.
jwe
--- End Message ---
------------------------------------------------------------------------------
Rapidly troubleshoot problems before they affect your business. Most IT
organizations don't have a clear picture of how application performance
affects their revenue. With AppDynamics, you get 100% visibility into your
Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk
_______________________________________________
Plplot-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/plplot-devel
