On 4/21/2016 1:24 AM, Vicente J. Botet Escriba wrote:

Le 20/04/2016 21:17, Vladimir Prus a écrit :

...

Boosters,

The master branch is now closed for all changes, except by permission from a release manager. Per schedule, the branch will be totally frozen on Saturday.

Hi,

I've come back from vacations (last Sunday) and I believed that the version 1.61 was already released.

I have fixed two major bugs and some doc issues that I would like to merge into the master branch.

Could I do the merge on Friday if the develop regressions are good?

Vicente, you've listed quite a large number of changes in your email, including some merge commits. This looks like too large change to merge when the master branch is closed. Possibly, you've copy-pasted something from GitHub interface, and it did not came across as intended. If you believe there are truly horrible bugs that would regress boost.thread, could you specifically list those bugs, along with commits fixing those bugs specifically - and we can cherry-pick those changes if so warranted.

The commits are the following: ... viboes https://github.com/boostorg/thread/commits/develop?author=viboes committed 12 minutes ago

In particular, the above appears to show all your commits on develop, not any particular commit, so it's hard to understand what you're proposing to merge. -- Vladimir Prus http://vladimirprus.com

Le 21/04/2016 19:17, Vicente J. Botet Escriba a écrit :

Le 21/04/2016 08:39, Vladimir Prus a écrit :

...

On 4/21/2016 1:24 AM, Vicente J. Botet Escriba wrote:

...

Le 20/04/2016 21:17, Vladimir Prus a écrit :

...

Boosters,

The master branch is now closed for all changes, except by permission from a release manager. Per schedule, the branch will be totally frozen on Saturday.

Hi,

I've come back from vacations (last Sunday) and I believed that the version 1.61 was already released.

I have fixed two major bugs and some doc issues that I would like to merge into the master branch.

Could I do the merge on Friday if the develop regressions are good?

Vicente,

you've listed quite a large number of changes in your email, including some merge commits. This looks like too large change to merge when the master branch is closed. Possibly, you've copy-pasted something from GitHub interface, and it did not came across as intended.

If you believe there are truly horrible bugs that would regress boost.thread, could you specifically list those bugs, along with commits fixing those bugs specifically - and we can cherry-pick those changes if so warranted.

...

The commits are the following: ... viboes https://github.com/boostorg/thread/commits/develop?author=viboes committed 12 minutes ago

In particular, the above appears to show all your commits on develop, not any particular commit, so it's hard to understand what you're proposing to merge.

Sorry, there were some pull merge that I need to fix and a lot of minor doc changes.

BTW this commit

* hiden typo (cosmetic) https://github.com/boostorg/thread/commit/640e1acb9836b2e0b74695b3b5baa52769...

https://github.com/boostorg/thread/commit/587ad425489ebac3d68a2ba64a8c201a9a...

The last one introduced two new files that are not used and I've removed in https://github.com/boostorg/thread/commit/2c3acef28131840bc96d57cbccc392bfbe...

* fix memory leak (BUG - robustness) https://github.com/boostorg/thread/commit/c7a5122fd3333800fd33f3407f6868a796...

https://github.com/boostorg/thread/commit/daae305bf77a84cb7446096ae31d610843...

https://github.com/boostorg/thread/commit/98dbc9da413d5b30cfb041338492da53f5...

* call interrupt only if joinable. (optimization cosmetic) https://github.com/boostorg/thread/commit/55a1325f303957d5637819432a40a70bfb...

* call on_desctruction on scoped_thread move assignment. (BUG - showstopper for scoped_thread )

https://github.com/boostorg/thread/commit/aab2891cdbc3c19ef492f16a7c473a4ccc...

The other are doc changes.

All the regressions that have run are ok. Almost all platforms have at lest a run. Can I merge this? Vicente

Le 23/04/2016 21:44, Vladimir Prus a écrit :

On 4/21/2016 8:17 PM, Vicente J. Botet Escriba wrote:

...

Le 21/04/2016 08:39, Vladimir Prus a écrit :

...

On 4/21/2016 1:24 AM, Vicente J. Botet Escriba wrote:

...

Le 20/04/2016 21:17, Vladimir Prus a écrit :

...

Boosters,

The master branch is now closed for all changes, except by permission from a release manager. Per schedule, the branch will be totally frozen on Saturday.

Hi,

I've come back from vacations (last Sunday) and I believed that the version 1.61 was already released.

I have fixed two major bugs and some doc issues that I would like to merge into the master branch.

Could I do the merge on Friday if the develop regressions are good?

Vicente,

you've listed quite a large number of changes in your email, including some merge commits. This looks like too large change to merge when the master branch is closed. Possibly, you've copy-pasted something from GitHub interface, and it did not came across as intended.

If you believe there are truly horrible bugs that would regress boost.thread, could you specifically list those bugs, along with commits fixing those bugs specifically - and we can cherry-pick those changes if so warranted.

...

The commits are the following: ... viboes https://github.com/boostorg/thread/commits/develop?author=viboes committed 12 minutes ago

In particular, the above appears to show all your commits on develop, not any particular commit, so it's hard to understand what you're proposing to merge.

Sorry, there were some pull merge that I need to fix and a lot of minor doc changes.

BTW this commit

I would prefer to do a global merge, but I understand it is too late.

...

* hiden typo (cosmetic) https://github.com/boostorg/thread/commit/640e1acb9836b2e0b74695b3b5baa52769...

https://github.com/boostorg/thread/commit/587ad425489ebac3d68a2ba64a8c201a9a...

The last one introduced two new files that are not used and I've removed in https://github.com/boostorg/thread/commit/2c3acef28131840bc96d57cbccc392bfbe...

I don't think that fixing a typo is a necessary patch at this point. Ok.

...

* fix memory leak (BUG - robustness) https://github.com/boostorg/thread/commit/c7a5122fd3333800fd33f3407f6868a796...

https://github.com/boostorg/thread/commit/daae305bf77a84cb7446096ae31d610843...

https://github.com/boostorg/thread/commit/98dbc9da413d5b30cfb041338492da53f5...

These seem safe and important, so you can cherry-pick them. For avoidance of doubt, I mean specifically using "git cherry-pick <commit>", where commit is one of 3 above. I have never used this way. I would try it now.

...

* call interrupt only if joinable. (optimization cosmetic) https://github.com/boostorg/thread/commit/55a1325f303957d5637819432a40a70bfb...

If it is cosmetic, can it wait for next release? Ok.

...

* call on_desctruction on scoped_thread move assignment. (BUG - showstopper for scoped_thread )

https://github.com/boostorg/thread/commit/aab2891cdbc3c19ef492f16a7c473a4ccc...

This one is a documentation change. Is it really showstopper, or you meant some other commit?

Sorry, it was https://github.com/boostorg/thread/commit/411798367b075a0e993010252eec81b846... I would include it if there is no objection. Best, Vicente

Le 23/04/2016 23:29, Vicente J. Botet Escriba a écrit :

...

Le 23/04/2016 21:44, Vladimir Prus a écrit :

...

On 4/21/2016 8:17 PM, Vicente J. Botet Escriba wrote:

...

Le 21/04/2016 08:39, Vladimir Prus a écrit :

...

On 4/21/2016 1:24 AM, Vicente J. Botet Escriba wrote:

...

Le 20/04/2016 21:17, Vladimir Prus a écrit : > > Boosters, > > The master branch is now closed for all changes, except by > permission from a release manager. > Per schedule, the branch will be totally frozen on Saturday. > Hi,

I've come back from vacations (last Sunday) and I believed that the version 1.61 was already released.

I have fixed two major bugs and some doc issues that I would like to merge into the master branch.

Could I do the merge on Friday if the develop regressions are good?

Vicente,

you've listed quite a large number of changes in your email, including some merge commits. This looks like too large change to merge when the master branch is closed. Possibly, you've copy-pasted something from GitHub interface, and it did not came across as intended.

If you believe there are truly horrible bugs that would regress boost.thread, could you specifically list those bugs, along with commits fixing those bugs specifically - and we can cherry-pick those changes if so warranted.

...

The commits are the following: ... viboes https://github.com/boostorg/thread/commits/develop?author=viboes committed 12 minutes ago

In particular, the above appears to show all your commits on develop, not any particular commit, so it's hard to understand what you're proposing to merge.

Sorry, there were some pull merge that I need to fix and a lot of minor doc changes.

BTW this commit

I would prefer to do a global merge, but I understand it is too late. Hr, I've forgotten that I did already a merge on master (without the

Le 23/04/2016 23:22, Vicente J. Botet Escriba a écrit : push evidently).

Is there a way to undo a merge locally? Otherwise I'm trying to update the whole repository again.

Could I apply the changes manually? const pthread_once_t pthread_once_init_value=PTHREAD_ONCE_INIT; struct BOOST_THREAD_DECL delete_epoch_tss_key_on_dlclose_t { delete_epoch_tss_key_on_dlclose_t() { } ~delete_epoch_tss_key_on_dlclose_t() { if(memcmp(&epoch_tss_key_flag, &pthread_once_init_value, sizeof(pthread_once_t))) { * void* data = (void*)pthread_getspecific(epoch_tss_key);** ** if (data)** ** delete_epoch_tss_data(data);** * pthread_key_delete(epoch_tss_key); } } }; struct delete_current_thread_tls_key_on_dlclose_t { delete_current_thread_tls_key_on_dlclose_t() { } ~delete_current_thread_tls_key_on_dlclose_t() { const boost::once_flag uninitialized = BOOST_ONCE_INIT; if (memcmp(¤t_thread_tls_init_flag, &uninitialized, sizeof(boost::once_flag))) { * void* data = pthread_getspecific(current_thread_tls_key);** ** if (data)** ** tls_destructor(data);** * pthread_key_delete(current_thread_tls_key); } } }; scoped_thread& operator=(BOOST_RV_REF(scoped_thread) x) { * CallableThread on_destructor;** ** ** on_destructor(t_);** * t_ = boost::move(BOOST_THREAD_RV(x).t_); return *this; } Best, Vicente

Le 24/04/2016 00:11, Vicente J. Botet Escriba a écrit :

Le 24/04/2016 00:06, Vicente J. Botet Escriba a écrit :

...

Le 23/04/2016 23:29, Vicente J. Botet Escriba a écrit :

...

...

Le 23/04/2016 21:44, Vladimir Prus a écrit :

...

On 4/21/2016 8:17 PM, Vicente J. Botet Escriba wrote:

...

Le 21/04/2016 08:39, Vladimir Prus a écrit : > On 4/21/2016 1:24 AM, Vicente J. Botet Escriba wrote: >> Le 20/04/2016 21:17, Vladimir Prus a écrit : >>> >>> Boosters, >>> >>> The master branch is now closed for all changes, except by >>> permission from a release manager. >>> Per schedule, the branch will be totally frozen on Saturday. >>> >> Hi, >> >> I've come back from vacations (last Sunday) and I believed that >> the version 1.61 was already released. > > >> I have fixed two major bugs and some doc issues that I would >> like to merge into the master branch. >> >> Could I do the merge on Friday if the develop regressions are >> good? > > Vicente, > > you've listed quite a large number of changes in your email, > including some merge commits. This > looks like too large change to merge when the master branch is > closed. Possibly, you've copy-pasted > something from GitHub interface, and it did not came across as > intended. > > If you believe there are truly horrible bugs that would regress > boost.thread, could you specifically > list those bugs, along with commits fixing those bugs > specifically - and we can cherry-pick those > changes if so warranted. > >> The commits are the following: > ... >> viboes >> https://github.com/boostorg/thread/commits/develop?author=viboes >> committed 12 minutes ago > > > In particular, the above appears to show all your commits on > develop, not any > particular commit, so it's hard to understand what you're > proposing to merge. >

Sorry, there were some pull merge that I need to fix and a lot of minor doc changes.

BTW this commit

I would prefer to do a global merge, but I understand it is too late. Hr, I've forgotten that I did already a merge on master (without the

Le 23/04/2016 23:22, Vicente J. Botet Escriba a écrit : push evidently).

Is there a way to undo a merge locally? Otherwise I'm trying to update the whole repository again.

Could I apply the changes manually?

const pthread_once_t pthread_once_init_value=PTHREAD_ONCE_INIT; struct BOOST_THREAD_DECL delete_epoch_tss_key_on_dlclose_t { delete_epoch_tss_key_on_dlclose_t() { } ~delete_epoch_tss_key_on_dlclose_t() { if(memcmp(&epoch_tss_key_flag, &pthread_once_init_value, sizeof(pthread_once_t))) { * void* data = (void*)pthread_getspecific(epoch_tss_key);** ** if (data)** ** delete_epoch_tss_data(data);** * pthread_key_delete(epoch_tss_key); } } };

struct delete_current_thread_tls_key_on_dlclose_t { delete_current_thread_tls_key_on_dlclose_t() { } ~delete_current_thread_tls_key_on_dlclose_t() { const boost::once_flag uninitialized = BOOST_ONCE_INIT; if (memcmp(¤t_thread_tls_init_flag, &uninitialized, sizeof(boost::once_flag))) { * void* data = pthread_getspecific(current_thread_tls_key);** ** if (data)** ** tls_destructor(data);** * pthread_key_delete(current_thread_tls_key); } } };

scoped_thread& operator=(BOOST_RV_REF(scoped_thread) x) { * CallableThread on_destructor;** ** ** on_destructor(t_);** * t_ = boost::move(BOOST_THREAD_RV(x).t_); return *this; }

Sorry for the format

const pthread_once_t pthread_once_init_value=PTHREAD_ONCE_INIT; struct BOOST_THREAD_DECL delete_epoch_tss_key_on_dlclose_t { delete_epoch_tss_key_on_dlclose_t() { } ~delete_epoch_tss_key_on_dlclose_t() { if(memcmp(&epoch_tss_key_flag, &pthread_once_init_value, sizeof(pthread_once_t))) { + void* data = (void*)pthread_getspecific(epoch_tss_key); + if (data) + delete_epoch_tss_data(data); pthread_key_delete(epoch_tss_key); } } };

struct delete_current_thread_tls_key_on_dlclose_t { delete_current_thread_tls_key_on_dlclose_t() { } ~delete_current_thread_tls_key_on_dlclose_t() { const boost::once_flag uninitialized = BOOST_ONCE_INIT; if (memcmp(¤t_thread_tls_init_flag, &uninitialized, sizeof(boost::once_flag))) { + void* data = pthread_getspecific(current_thread_tls_key); + if (data) + tls_destructor(data); pthread_key_delete(current_thread_tls_key); } } };

scoped_thread& operator=(BOOST_RV_REF(scoped_thread) x) { + CallableThread on_destructor; + + on_destructor(t_); t_ = boost::move(BOOST_THREAD_RV(x).t_); return *this; }

I have applied manually the changes https://github.com/boostorg/thread/commit/2494f3fc7a6dcaa990d2801ba7f91ffa37... Hopping this workaround doesn't disturb the release managers. Let me know if I should rollback this change, Vicente

Le 24/04/2016 13:57, Vladimir Prus a écrit :

On 4/24/2016 2:08 AM, Vicente J. Botet Escriba wrote:

...

...

I have applied manually the changes https://github.com/boostorg/thread/commit/2494f3fc7a6dcaa990d2801ba7f91ffa37...

Hopping this workaround doesn't disturb the release managers.

Vicente,

this commit seems OK to me for 1.61.0.

I would however suggest that you learn how to use 'git cherry-pick', since it will prove handy any time you'll need to apply a specific change to master branch in future.

Also, as you can see at the above URL, the title of your commit message was very long, and gets wrapped. It's best to stick to standard Git convention for commit messages, as documented at:

https://git-scm.com/book/ch5-2.html

which in particular suggest to limit the summary line to 50 characters.

Thanks,

Thanks Vladimir, I will try to be ready for the next occasion. Best, Vicente

Le 24/04/2016 00:40, Peter Dimov a écrit :

Vicente J. Botet Escriba wrote:

...

Hr, I've forgotten that I did already a merge on master (without the push evidently).

Is there a way to undo a merge locally?

If you're on the master branch,

git reset --hard origin/master

will discard all your local commits and will reset your master branch to the state of the remote master branch. Thanks Peter.

Vicente

On Fri, Apr 22, 2016 at 10:11 AM, Robert Ramey wrote:

On 4/20/16 12:17 PM, Vladimir Prus wrote:

...

Boosters,

The master branch is now closed for all changes, except by permission from a release manager. Per schedule, the branch will be totally frozen on Saturday.

Yesterday I was informed by a beta tester for version 1.61 of a regression in the master branch of the serialization library. This was not detected by any of my tests (as far as I know. The test matrix shows some failures, but doesn't reveal their cause). In any case it's a very serious issue. If this is released, xml archives created with this version may not be readable in the future.

I made a fix, tested it on the compilers I have at my disposal and pushed the changes to the develop branch. I did this yesterday in the hope of getting results on the develop branch test matrix so I could merge (after getting permission) today. But it seems that since I did the upload yesterday, no tests have been run on the develop branch. So I'm stuck. I could merge this directly to master - and I'm willing to do this if asked, but I would prefer to stick with my original plan.

I apologize for creating this problem. It's exactly the kind of thing that I give other people a hard time for.

I absolutely need to get this into the master before release.

Which commit is it? If it's small enough we likely would say yes.. And we are planning on testing final archives on Sunday. So you at least have through Saturday end of day (US day that is) to wait and see if some master test results run. -- -- Rene Rivera -- Grafik - Don't Assume Anything -- Robot Dreams - http://robot-dreams.net -- rrivera/acm.org (msn) - grafikrobot/aim,yahoo,skype,efnet,gmail

I'm willing to do whatever is most convenient for you guys. Ideally I'd like to see at least a few test results on develop, merge to master and see at least a few results there.

Running tests locally, msvc-14, 12 and 11 all pass. With msvc-10 there are 10 failures, but 7 shown on the test matrix, current failures are: test_map_unordered_text_archive test_map_unordered_text_warchive test_map_unordered_xml_archive test_map_unordered_xml_warchive test_map_unordered_binary_archive test_set_unordered_text_archive test_map_unordered_text_warchive test_map_unordered_xml_archive test_map_unordered_xml_warchive test_map_unordered_binary_archive These all look to be the "same" failure though, so I'm not sure why some of these seem to pass in the test matrix? GCC-5.3.0 mingw failures: test_native_array_xml_warchive test_registered_xml_warchive test_boost_array_xml_warchive test_non_default_ctor2_xml_warchive test_delete_pointer_xml_warchive test_unregistered_xml_warchive test_dll_simple GCC 5.3.0 C++14 mode: test_codecvt_null test_array_xml_warchive test_boost_array_xml_warchive test_native_array_xml_warchive test_binary_xml_warchive test_bitset_xml_warchive test_class_info_load_xml_warchive test_complex_xml_warchive test_contained_class_xml_warchive test_cyclic_pointers_xml_warchive test_delete_pointer_xml_warchive + lots more, all with the same failure as: http://www.boost.org/development/tests/develop/developer/output/timber-cygwi... Intel 16 win: Almost everything fails with linker errors. Let me know if there's anything I can do. HTH, John.

In any case, given that I haven't received any new information, I'll merge the change from develop into master.

+1

On 4/23/16 12:02 PM, Belcourt, Kenneth wrote:

Hi Robert,

I noticed that all the Boost.MPI and graph parallel tests that use serialization are broken on develop and master with an error similar to this:

In file included from libs/graph_parallel/src/mpi_process_group.cpp:14: In file included from ./boost/graph/distributed/mpi_process_group.hpp:30: In file included from ./boost/mpi.hpp:32: In file included from ./boost/mpi/skeleton_and_content.hpp:32: ./boost/mpi/detail/ignore_iprimitive.hpp:40:21: error: no template named 'array' in namespace 'boost::serialization'; did you mean simply 'array'? void load_array(serialization::array<T> &, unsigned int ) ^~~~~~~~~~~~~~~~~~~~ array ./boost/array.hpp:61:11: note: 'array' declared here class array { ^ fatal error: too many errors emitted, stopping now [-ferror-limit=] 1 warning and 20 errors generated.

"g++" -ftemplate-depth-128 -O3 -Wall -gdwarf-2 -fexceptions -Wno-inline -arch x86_64 -DBOOST_ALL_NO_LIB=1 -DBOOST_GRAPH_NO_LIB=1 -DNDEBUG -I"." -I"/Users/kbelco/Projects/local/openmpi-1.8.4/include" -I"libs/graph_parallel/src" -c -o "bin.v2/libs/graph_parallel/build/darwin-4.2.1/release/link-static/threading-multi/mpi_process_group.o" "libs/graph_parallel/src/mpi_process_group.cpp”

It’d be nice if serialization worked with MPI for the release, though I’m not sure it’s a show stopper.

This is unfortunate. It seems that no one is watching the boost mpi tests related to serialization. Does Boost MPI have a current maintainer? Does it need one? I'll take a look at this when we get 1.61 out the door It turns out that writing a custom archive is not as easy as it's cracked up to be. I think that there's some coupling between the interface and implementation which means that once in a while I've made changes somewhere which broke existing archives. That is, the archive API is not rigorously defined. As it happens, this illustrates another drum I've been beating on lately. The one which says waiting until the library is done to write the documentation makes for an ill designed library. But that's another thread. Robert Ramey

— Noel

_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Am Saturday 23 April 2016, 23:29:34 schrieb Belcourt, Kenneth:

...

On Apr 23, 2016, at 1:31 PM, Robert Ramey wrote: Does Boost MPI have a current maintainer? Does it need one?

Well, perhaps CMT in the future but, for now, I’ll try to bring it up to date.

This should be solved by https://github.com/boostorg/mpi/pull/30 Yours, Jürgen -- * Dipl.-Math. Jürgen Hunold ! * voice: ++49 4257 300 ! Fährstraße 1 * fax : ++49 4257 300 ! 31609 Balge/Sebbenhausen * jhunold@gmx.eu ! Germany

On Apr 24, 2016, at 9:43 AM, Jürgen Hunold wrote:

Am Saturday 23 April 2016, 23:29:34 schrieb Belcourt, Kenneth:

...

...

On Apr 23, 2016, at 1:31 PM, Robert Ramey wrote: Does Boost MPI have a current maintainer? Does it need one?

Well, perhaps CMT in the future but, for now, I’ll try to bring it up to date.

This should be solved by

https://github.com/boostorg/mpi/pull/30

Applied to develop, thanks so much for this. Any chance we could get this into the release once tests cycle? — Noel

Yours,

Jürgen -- * Dipl.-Math. Jürgen Hunold ! * voice: ++49 4257 300 ! Fährstraße 1 * fax : ++49 4257 300 ! 31609 Balge/Sebbenhausen * jhunold@gmx.eu ! Germany _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

On 25/04/2016 09:18, Vladimir Prus wrote:

On 4/25/2016 12:27 AM, Belcourt, Kenneth wrote:

...

...

On Apr 24, 2016, at 9:43 AM, Jürgen Hunold wrote:

Am Saturday 23 April 2016, 23:29:34 schrieb Belcourt, Kenneth:

...

...

On Apr 23, 2016, at 1:31 PM, Robert Ramey wrote: Does Boost MPI have a current maintainer?

Not that I know of, I used to give it a try but the modular git bjam mess made it impractical for me.

...

...

...

...

Does it need one?

...

...

...

Well, perhaps CMT in the future but, for now, I’ll try to bring it up to date.

This should be solved by

https://github.com/boostorg/mpi/pull/30

Applied to develop, thanks so much for this.

Any chance we could get this into the release once tests cycle?

No promises, but please post when tests do cycle. Also, I left inline comment on commit on GitHub, could you take a look?

On Apr 25, 2016, at 12:08 PM, Vladimir Prus wrote:

On 4/23/2016 10:02 PM, Belcourt, Kenneth wrote:

...

It’d be nice if serialization worked with MPI for the release, though I’m not sure it’s a show stopper.

What is the actual impact of this problem? E.g. which percentage of MPI users will find their code no longer compiling?

Fair question, no idea really. I know that Boost MPI's used on multiple projects where I work, though it’s easy enough for us to just skip using the 1.61 release to avoid breaking our MPI serialization code. Noel

On Apr 25, 2016, at 1:12 PM, Rene Rivera wrote:

On Mon, Apr 25, 2016 at 2:05 PM, Belcourt, Kenneth wrote:

...

...

On Apr 25, 2016, at 12:08 PM, Vladimir Prus wrote:

On 4/23/2016 10:02 PM, Belcourt, Kenneth wrote:

...

It’d be nice if serialization worked with MPI for the release, though I’m not sure it’s a show stopper.

What is the actual impact of this problem? E.g. which percentage of MPI users will find their code no longer compiling?

Fair question, no idea really. I know that Boost MPI's used on multiple projects where I work, though it’s easy enough for us to just skip using the 1.61 release to avoid breaking our MPI serialization code.

Sorry if my ignorance of how MPI shows :-) .. How much of MPI is usable with this problem? Is it usable at all? Is it partially usable?

The core of MPI works fine. You’ll only have problems if use the Boost MPI capability to serialize across the parallel machine. Noel

On Apr 26, 2016, at 2:36 AM, alainm wrote:

On 25/04/2016 21:12, Rene Rivera wrote:

...

On Mon, Apr 25, 2016 at 2:05 PM, Belcourt, Kenneth wrote:

...

...

...

It’d be nice if serialization worked with MPI for the release, though I’m not sure it’s a show stopper. What is the actual impact of this problem? E.g. which percentage of MPI users will find their code no longer compiling? Fair question, no idea really. I know that Boost MPI's used on multiple

On Apr 25, 2016, at 12:08 PM, Vladimir Prus wrote: On 4/23/2016 10:02 PM, Belcourt, Kenneth wrote: projects where I work, though it’s easy enough for us to just skip using the 1.61 release to avoid breaking our MPI serialization code.

Sorry if my ignorance of how MPI shows :-) .. How much of MPI is usable with this problem? Is it usable at all? Is it partially usable?

No part of Boost MPI is usable, meaning no code built on top of Boost.MPI will compile.

Just tried.

Yep, right you are. All of Boost.MPI depends on Boost.Serialization, that’s not ideal. Noel

On Tue, Apr 26, 2016 at 3:36 AM, alainm wrote:

On 25/04/2016 21:12, Rene Rivera wrote:

...

On Mon, Apr 25, 2016 at 2:05 PM, Belcourt, Kenneth wrote:

On Apr 25, 2016, at 12:08 PM, Vladimir Prus

...

...

wrote:

...

On 4/23/2016 10:02 PM, Belcourt, Kenneth wrote:

...

It’d be nice if serialization worked with MPI for the release, though

I’m not sure it’s a show stopper.

...

What is the actual impact of this problem? E.g. which percentage of MPI

users will find their code

...

no longer compiling?

Fair question, no idea really. I know that Boost MPI's used on multiple projects where I work, though it’s easy enough for us to just skip using the 1.61 release to avoid breaking our MPI serialization code.

Sorry if my ignorance of how MPI shows :-) .. How much of MPI is usable with this problem? Is it usable at all? Is it partially usable?

No part of Boost MPI is usable, meaning no code built on top of Boost.MPI will compile.

Just tried.

Thanks for the info.. But given that we don't have *any* test results with MPI passing (i.e. nothing on develop yet).. I'm afraid it's going to stay broken this release. -- -- Rene Rivera -- Grafik - Don't Assume Anything -- Robot Dreams - http://robot-dreams.net -- rrivera/acm.org (msn) - grafikrobot/aim,yahoo,skype,efnet,gmail

On 4/26/2016 9:01 PM, Belcourt, Kenneth wrote:

...

On Apr 26, 2016, at 11:47 AM, Rene Rivera wrote:

On Tue, Apr 26, 2016 at 3:36 AM, alainm wrote:

...

On 25/04/2016 21:12, Rene Rivera wrote:

...

On Mon, Apr 25, 2016 at 2:05 PM, Belcourt, Kenneth wrote:

On Apr 25, 2016, at 12:08 PM, Vladimir Prus

...

...

wrote:

...

On 4/23/2016 10:02 PM, Belcourt, Kenneth wrote:

> It’d be nice if serialization worked with MPI for the release, though > I’m not sure it’s a show stopper.

...

What is the actual impact of this problem? E.g. which percentage of MPI

users will find their code

...

no longer compiling?

Fair question, no idea really. I know that Boost MPI's used on multiple projects where I work, though it’s easy enough for us to just skip using the 1.61 release to avoid breaking our MPI serialization code.

Sorry if my ignorance of how MPI shows :-) .. How much of MPI is usable with this problem? Is it usable at all? Is it partially usable?

No part of Boost MPI is usable, meaning no code built on top of Boost.MPI will compile.

Just tried.

Thanks for the info.. But given that we don't have *any* test results with MPI passing (i.e. nothing on develop yet).. I'm afraid it's going to stay broken this release.

I just applied a patch that should get all of graph, graph_parallel, and MPI passing on develop. Tomorrow should be clean, if you can wait that long.

The most recent results for MPI are from April 20, are you sure we'll have any results tomorrow? What about graph and graph_parallel? Are they also broken in current master? -- Vladimir Prus http://vladimirprus.com

On Apr 26, 2016, at 1:14 PM, Vladimir Prus wrote:

On 4/26/2016 9:01 PM, Belcourt, Kenneth wrote:

...

...

On Apr 26, 2016, at 11:47 AM, Rene Rivera wrote:

On Tue, Apr 26, 2016 at 3:36 AM, alainm wrote:

...

On 25/04/2016 21:12, Rene Rivera wrote:

...

On Mon, Apr 25, 2016 at 2:05 PM, Belcourt, Kenneth wrote:

On Apr 25, 2016, at 12:08 PM, Vladimir Prus

...

> wrote:

> On 4/23/2016 10:02 PM, Belcourt, Kenneth wrote: > >> It’d be nice if serialization worked with MPI for the release, though >> > I’m not sure it’s a show stopper.

> What is the actual impact of this problem? E.g. which percentage of MPI > users will find their code

> no longer compiling? > Fair question, no idea really. I know that Boost MPI's used on multiple projects where I work, though it’s easy enough for us to just skip using the 1.61 release to avoid breaking our MPI serialization code.

Sorry if my ignorance of how MPI shows :-) .. How much of MPI is usable with this problem? Is it usable at all? Is it partially usable?

No part of Boost MPI is usable, meaning no code built on top of Boost.MPI will compile.

Just tried.

Thanks for the info.. But given that we don't have *any* test results with MPI passing (i.e. nothing on develop yet).. I'm afraid it's going to stay broken this release.

I just applied a patch that should get all of graph, graph_parallel, and MPI passing on develop. Tomorrow should be clean, if you can wait that long.

The most recent results for MPI are from April 20, are you sure we'll have any results tomorrow?

Yes, I’m running tests for both develop and master right now and they’ll post results here in a couple of hours.

What about graph and graph_parallel? Are they also broken in current master?

Graph should be fine in master. graph_parallel that depends on MPI is broken due to the serialization issue. There’s also an issue with graph_parallel where some examples don’t compile in master due, apparently, to some un-merged changes from develop. This issue was reported by Eisuke Kawashima. The upshot is that fixing MPI serialization in master will fix both MPI and graph_parallel. The graph_parallel/example breakage is less critical though at least one user is impacted by it. -— Noel

On Apr 26, 2016, at 1:31 PM, Vladimir Prus wrote:

On 4/26/2016 10:24 PM, Belcourt, Kenneth wrote:

...

Yes, I’m running tests for both develop and master right now and they’ll post results here in a couple of hours.

...

What about graph and graph_parallel? Are they also broken in current master?

Graph should be fine in master. graph_parallel that depends on MPI is broken due to the serialization issue. There’s also an issue with graph_parallel where some examples don’t compile in master due, apparently, to some un-merged changes from develop. This issue was reported by Eisuke Kawashima.

The upshot is that fixing MPI serialization in master will fix both MPI and graph_parallel. The graph_parallel/example breakage is less critical though at least one user is impacted by it.

Given that MPI and graph_parallel are entirely broken on master right now, please cherry-pick the serialization fix to master, either now or when the tests finish - it can't be worse for sure. We'll include the change in release.

Just cherry-picked these two commits into master to fix the serialization issue: commit 0dce8d2c2ab273c488d708fb3e66dbb9c4298a79 Author: Jürgen Hunold commit 7d33e519b3daa01e9bb4a5545d5d084c45875e4f Author: K. Noel Belcourt MPI tests are clean on master. Graph_parallel is mostly clean, there’s one issue: clang-darwin.compile.c++ ../bin.v2/libs/graph_parallel/test/distributed_csr_algorithm_test-1.test/clang-darwin-4.2.1/debug/distributed_csr_algorithm_test.o In file included from ../libs/graph_parallel/test/distributed_csr_algorithm_test.cpp:25: In file included from ../boost/graph/dijkstra_shortest_paths.hpp:25: ../boost/pending/relaxed_heap.hpp:194:53: error: no viable conversion from returned value of type 'const value_type' (aka 'const boost::optional<unsigned long>') to function return type 'bool' bool contains(const value_type& x) const { return groups[get(id, x)]; } ^~~~~~~~~~~~~~~~~~ which looks like a dependency on an un-merged change from graph develop. I’ll have to track this down. — Noel

On Wednesday, April 27, 2016 09:43 PM, Vladimir Prus wrote:

On 4/27/2016 2:48 PM, Belcourt, Kenneth wrote:

...

...

if you're still around, please commit these patches too.

Sorry about the delay, just pushed this commit to graph master.

commit ed989311185caf8384dd7e42315f58dcd349d3eb Author: K. Noel Belcourt Date: Wed Apr 27 05:42:03 2016 -0600

Fixes to clear graph and graph_parallel for 1.61 release.

Graph, graph_parallel, and MPI all pass on master. Let me know when the super project has updated and I’ll kick off the Sandia testers.

Thanks, the superprorject was updated - please start the tests.

Mine had only been running a short time, I've just restarted them. gcc-5.2 libstdc++ and clang-3.8 with libc++, both with -std=c++14 on Ubuntu x64, if that helps. Ben

On 26 Apr 2016, at 19:47, Rene Rivera wrote:

Thanks for the info.. But given that we don't have *any* test results with MPI passing (i.e. nothing on develop yet).. I'm afraid it's going to stay broken this release.

Is the test matrix actually working? There should be more recent results than April 21… Thomas