Re: [boost] [serialization][ublas][test] failures in serialization causing regressions

Subject: Re: [boost] [serialization][ublas][test] failures in serialization causing regressions
From: Barend Gehrels (barend_at_[hidden])
Date: 2016-12-06 15:22:46

Hi Robert,

Op 27-11-2016 om 23:58 schreef Robert Ramey:
> On 11/27/16 1:24 PM, Barend Gehrels wrote:
>> Hi Robert,
>>
>>
>> Op 27-11-2016 om 3:03 schreef Robert Ramey:
>>> On 11/26/16 5:23 PM, Robert Ramey wrote:
>>>> On 11/26/16 1:31 PM, Barend Gehrels wrote:
>>>>>> The regression matrix in develop of Boost.Geometry contains many 
>>>>>> new >
>>>>> compilation failures due to:
>>>>>>
>>>>>>
>>>>>> 1) : D:\t08\run\boost_root\boost/serialization/array.hpp(25) : error
>>>>> C2039: 'array' : is not a member of 'std'
>>>>>>
>>>>>> 2):
>>>>>> ../boost/numeric/ublas/storage.hpp: In member function ???void
>>>>> boost::numeric::ublas::unbounded_array<T, ALLOC>::serialize(Archive&,
>>>>> unsigned int)???:
>>>>>> ../boost/numeric/ublas/storage.hpp:331:18: error: 
>>>>>> ???make_array??? is
>>>>> not a member of ???boost::serialization???
>>>>>>              ar & serialization::make_array(data_, s);and a
>>>>>>
>>>>>>
>>>>>> The master is still OK.
>>>>>>
>>>>>> Can this be solved?
>>>>>
>>>>> Ping! This is still the case!
>>>>> Robert, can you explain this?
>>>>>
>>>>> It is (of course) not only geometry failing, also ublas or (if there
>>>>> are) other libraries with ublas dependencies:
>>>>> http://www.boost.org/development/tests/develop/developer/numeric-ublas.html 
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> All yellow!
>>>>
>>>> It looks to me that these test are using std::array and the 
>>>> compiler is
>>>> not supporting C++11+
>>>>
>>>> I don't think this has anything to do with the serialization library.
>>>>
>>>
>>> OK - I've looked at this a little bit.
>>>
>>> I made adjustments to more easily support all C++ compilers from C++98
>>> to C++14 + and to factor common code from vector, valarray, native
>>> arrays, and who knows what else.  One of the things this entailed was
>>> to put the implementation of an "array_wrapper" in a separate file.
>>> This is more general than the concept of an "array".  It also includes
>>> the definition of "make_array" which perhaps should be called
>>> make_array_wrapper.
>>>
>>> So I think the best would be for ublas / storage to replace
>>>
>>> #include boost/serialization/array.hpp
>>>
>>> with
>>>
>>> #include boost/serialization/array_wrapper.hpp
>>>
>>> A word of caution - I'm actually not quite done with this but I don't
>>> think the array_wapper concept/definition will change so I think it is
>>> safe to make this change.  Unfortunately, this will mean that
>>> serialization and ublas will have to be merged to the master at the
>>> same time.  I realize that this is not ideal - but still ...
>>
>> Thanks for investigating. Your advice to replace it in ublas looks good
>> - however, I don't know who is responsible for it and if it will be done
>> on short term. Maybe we can prepare a PR for them. And indeed, then we
>> have the merge problem. Are there people from Ublas on the list? I
>> modified the subject to draw more attention.
>>
>> Regards, Barend
>
> Actually I really need to look at this a little more carefully.
>
> Originally boost/serialization/array.hpp was for C++ native arrays.
> Now it's morphed to be std::array.  Over the years stuff got added: 
> fast serialization of bit serializable arrays, c++11 <array>, 
> array_wrapper concept, std::vector, valarray and who knows what else.
> I'm generally against modification of the interface but do refactor 
> from time to time to deal with all this.  And of course this is what 
> happens when people actually start to depend upon the library.  As I 
> said, I need to look at this some more - perhaps it's possible / 
> better to adjust the contents of boost/serialization/array.hpp.

For your information:

Because it is only in develop and not in master, it is currently not a 
problem for users. It was inconvenient for us (checking regressions) but 
luckily there were some columns not affected, and in the meantime I 
merged to master again and that looks good.

Per release 1.64 we, as Boost.Geometry, will stop using Ublas. We 
currently use it only internally for matrix inversion and products, and 
will do that with Boost.QVM. That is basically already applied (but not 
yet submitted), but it is too late for this release, and not necessary 
because master is OK.

Regards, Barend