On 01/03/2014 05:59 PM, Alan W. Irwin wrote:
> 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
I'm afraid I'm going to bow out of being a go between here. Hopefully
the SWIG and Octave folks can work it out. As it stands it seems like
SWIG may drop Octave support if there is no resolution.
For the time being I'm disabling plplot Octave support in Fedora Rawhide
(F21).
--
Orion Poplawski
Technical Manager 303-415-9701 x222
NWRA/CoRA Division FAX: 303-415-9702
3380 Mitchell Lane or...@cora.nwra.com
Boulder, CO 80301 http://www.cora.nwra.com
------------------------------------------------------------------------------
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
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel
