Subject: Re: [ublas] ublas status for 1.56
From: Matthew Musto (matthew.musto_at_[hidden])
Date: 2014-07-29 19:29:52
Thanks for the update Nasos.
All of my development is on MSVC12, so... I guess I was blind to the fact
that gcc on Linux was working pretty well in development. My eyes only
went to the compiler I cared about :) Once you merge the checked_iterator
fix for MSVC would it be as simple as moving replacing the 1.56 library
folder with that from the development branch or are there other
On Tue, Jul 29, 2014 at 8:51 AM, Nasos Iliopoulos <nasos_i_at_[hidden]>
> this is the state of develop:
> I did an effort in the spring to clean up the the tests. As you can see
> the develop branch is pretty much done and there are no issues on intel and
> gcc compilers and hardly a few on mingw. clang should be ok with some
> exceptions that seem to fail without reason on darwin (on linux all clan
> compilers compile without failures).
> What remains is probably not worth the time and in many cases it is
> because of issues with other boost libraries. See for example:
> I still have to upload a checked_iterator fix for MSVC to clean some more
> tests. Unfortunately though with MSVC I am not sure if we will be able to
> go all green because of certain intricacies with mapped containers.
> I think David plans to incorporate those changes in the next release.
> On 07/28/2014 06:07 PM, Matthew Musto wrote:
> Hi guys,
> I understand that ublas development did not align with the 1.56 release
> cycle and instead you are focused on making 1.57 a solid release.
> I was curious if I could get an estimate of when the development branch
> of boost would have a version of ublas which passes all of the regression
> tests. Also, once that is the case, would I be able to merge the ublas
> directory into my existing 1.56 local copy?
> Thanks much,
> Matthew Musto
> ublas mailing listublas_at_[hidden]http://lists.boost.org/mailman/listinfo.cgi/ublas
> Sent to: athanasios.iliopoulos.ctr.gr_at_[hidden]
> ublas mailing list
> Sent to: matthew.musto_at_[hidden]
-- -------------------- Matthew Musto matthew.musto_at_[hidden]