On 2014-01-03 15:07-0700 Orion Poplawski wrote:
> On 12/31/2013 06:50 PM, Alan W. Irwin wrote:
>> Hi Orion:
>>
>> Thanks for doing that suggested experiment. More below
>> in context.
>>
>> On 2013-12-31 16:52-0700 Orion Poplawski wrote:
>>
>>> On 12/31/2013 11:56 AM, Alan W. Irwin wrote:
>>>> On 2013-12-30 13:42-0700 Orion Poplawski wrote:
>>>>
>>>>> Ah, you hit the nail on the head - they dropped OCTAVE_API_VERSION_NUMBER
>>>>> completely. I've sent an email to the octave developers asking why.
>>>>
>>>> To see if there are any more octave-3.8.0 issues beyond this one, I
>>>> suggest you temporarily add
>>>>
>>>> #define OCTAVE_API_VERSION_NUMBER 49
>>>>
>>>> to the generated bindings/octave/plplot_octaveOCTAVE_wrap.cxx
>>>> file and see how far you get with
>>>
>>> cd /home/orion/fedora/plplot/plplot-5.9.11/fedora/bindings/octave &&
>>> /usr/lib64/ccache/c++ -DHAVE_CONFIG_H -Dplplot_octave_EXPORTS -O2 -g -pipe
>>> -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -fexceptions
>>> -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches
>>> -m64
>>> -mtune=generic -fPIC -I/home/orion/fedora/plplot/plplot-5.9.11/include
>>> -I/home/orion/fedora/plplot/plplot-5.9.11/lib/qsastime
>>> -I/home/orion/fedora/plplot/plplot-5.9.11/fedora
>>> -I/home/orion/fedora/plplot/plplot-5.9.11/fedora/include
>>> -I/home/orion/fedora/plplot/plplot-5.9.11/fedora/bindings/octave
>>> -I/usr/include/octave-3.8.0 -I/usr/include/octave-3.8.0/octave
>>> -I/home/orion/fedora/plplot/plplot-5.9.11/bindings/swig-support -o
>>> CMakeFiles/plplot_octave.dir/plplot_octaveOCTAVE_wrap.cxx.o -c
>>> /home/orion/fedora/plplot/plplot-5.9.11/fedora/bindings/octave/plplot_octaveOCTAVE_wrap.cxx
>>>
>>> /home/orion/fedora/plplot/plplot-5.9.11/fedora/bindings/octave/plplot_octaveOCTAVE_wrap.cxx:
>>>
>>> In member function ‘virtual dim_vector octave_swig_type::dims() const’:
>>> /home/orion/fedora/plplot/plplot-5.9.11/fedora/bindings/octave/plplot_octaveOCTAVE_wrap.cxx:1183:46:
>>>
>>> error: ‘class octave_value’ has no member named ‘is_real_nd_array’
>>> } else if (out.is_matrix_type() || out.is_real_nd_array() ||
>>> out.is_numeric_type() ) {
>>> ^
>>
>> "is_real_nd_array" is only used in a function that is provided by swig
>> (as opposed to C++ interface code supplied by PLplot). So I would
>> summarize this issue as a backwards-incompatible Octave change (or
>> bug) that is confounding swig very similar to the missing
>> OCTAVE_API_VERSION_NUMBER #define.
>>
>> Again, I think the Octave developers should be consulted about this to
>> see whether this is a bug or an intended backwards-incompatible change
>> in the Octave C++ library API.
>
> According to the octave folks, "is_real_nd_array()" was intentionally removed,
> and may indeed have only ever returned "false".
>
> octave upstream seems adverse to re-adding OCTAVE_API_VERSION_NUMBER.
>
> I have gotten no response yet to my swig bug:
> https://sourceforge.net/p/swig/bugs/1353/
>
I found via google the octave threads at
http://octave.1599824.n4.nabble.com/Why-no-more-OCTAVE-API-VERSION-NUMBER-td4660468.html
and
http://octave.1599824.n4.nabble.com/Any-documentation-of-changes-to-libinterp-API-td4660492.html
where octave developers replied to your two reports, and I agree with
your conclusion that it looks like they will do nothing to rescind
those backwards incompatibilities.
> [out of order]I may be able to put some hacks into the Fedora swig package to
> work around
> these problems, but I rather avoid it.
>
> Any suggestions for how to proceed?
For the PLplot build system it should be straightforward to create an
Octave version test. Also, I am pretty sure that swig users are
allowed to redefine any core swig functionality. Thus, for any Octave
version greater than 3.6.4, we would want to #define
OCTAVE-API-VERSION-NUMBER and simply copy the the swig core
functionality that currently uses is_real_nd_array() and modify it to
drop that call. But I don't understand OOP well enough to figure out
the code unit that needs to be copied so I hope you or Andrew can
figure that out (or figure out some other simpler means of effectively
dropping that call to is_real_nd_array()).
> Have you had any luck with the swig folks?
I haven't tried yet since I think your bug report will need to be
supplemented if we attempt to follow the above plan to modify PLplot
so it will work properly with Octave-3.8.0. Once 3.8.0 works for us,
you should update that bug report with a patch to swig that takes all
measures we discover need to be made in the PLplot case. At that point
I would be willing to bring up your bug report on the swig mailing
list. There is nothing like a patch (no matter how crude/brute force)
to focus and attract discussion.
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
__________________________
------------------------------------------------------------------------------
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
