Quantcast

[1.64] [ublas] Broken/regession due to Boost.Serialization changes

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

[1.64] [ublas] Broken/regession due to Boost.Serialization changes

Boost - Dev mailing list
Hi,

since the 1.64 release including e.g. boost/numeric/ublas/matrix.hpp
gives an error like "no member named 'make_array' in namespace
'boost::serialization'", according to the official(?) test overview
(http://www.boost.org/development/tests/master/developer/numeric-ublas.html)
on a lot of systems.

There have been discussions on this mailing list in Nov/Dec 2016
probably at least related to this ([boost] [serialization][ublas][test]
failures in serialization causing regressions) and in Feb 2017 ([boost]
[serialization][uBlas] Serialization still breaking anything that uses
uBlas?), also there are several pull requests on GitHub, e.g.
https://github.com/boostorg/ublas/pull/46.

(I assume you are aware of this already, but I wonder why there was a
release with a regression like this, maybe due to a maintainer missing?
How are cases like these handled?)

Thanks!

(Sorry if this is a double post but the list address seemed to change
from @wowbagger.crest.iu.edu to @lists.boost.org so I tried again.)

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [1.64] [ublas] Broken/regession due to Boost.Serialization changes

Boost - Dev mailing list
On 4/21/17 4:25 PM, Peppard via Boost wrote:

> Hi,
>
> since the 1.64 release including e.g. boost/numeric/ublas/matrix.hpp
> gives an error like "no member named 'make_array' in namespace
> 'boost::serialization'", according to the official(?) test overview
> (http://www.boost.org/development/tests/master/developer/numeric-ublas.html)
> on a lot of systems.
>
> There have been discussions on this mailing list in Nov/Dec 2016
> probably at least related to this ([boost] [serialization][ublas][test]
> failures in serialization causing regressions) and in Feb 2017 ([boost]
> [serialization][uBlas] Serialization still breaking anything that uses
> uBlas?), also there are several pull requests on GitHub, e.g.
> https://github.com/boostorg/ublas/pull/46.
>
> (I assume you are aware of this already, but I wonder why there was a
> release with a regression like this, maybe due to a maintainer missing?
> How are cases like these handled?)
>
> Thanks!
>
> (Sorry if this is a double post but the list address seemed to change
> from @wowbagger.crest.iu.edu to @lists.boost.org so I tried again.)
>
> _______________________________________________
> Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
>


Hmmm - I was pretty sure this was fixed the last release. I'm also
pretty sure that I merged the the develop branch into the master of the
serialization library. I certainly remember doing so.  But now that I
look at the master branch of ublas, I see the failures.  I'll look into it.

Robert Ramey


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [1.64] [ublas] Broken/regession due to Boost.Serialization changes

Marcel Raad
In reply to this post by Boost - Dev mailing list
Boost - Dev mailing list wrote
since the 1.64 release including e.g. boost/numeric/ublas/matrix.hpp
gives an error like "no member named 'make_array' in namespace
'boost::serialization'", according to the official(?) test overview
(http://www.boost.org/development/tests/master/developer/numeric-ublas.html)
on a lot of systems.
I've also been hit by this and created a pull request for uBLAS:
https://github.com/uBLAS/ublas/pull/55

Unfortunately I only tested the Betas with MSVC, which just ignores the template that doesn't compile anymore, and then the error surfaced only when compiling with clang.

Marcel
Loading...