[1.61.0] Master branch is closed
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. Thanks, The Release Managers
Le 20/04/2016 21:17, Vladimir Prus a écrit :
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? Best, Vicente The commits are the following: Commits on Apr 21, 2016 1. fix hiden rename <https://github.com/boostorg/thread/commit/587ad425489ebac3d68a2ba64a8c201a9aa886ab> viboes <https://github.com/boostorg/thread/commits/develop?author=viboes> committed 12 minutes ago 1. Commits on Apr 20, 2016 1. Merge branch 'develop' of github.com:boostorg/thread into develop <https://github.com/boostorg/thread/commit/ef401d81dba8c23f8cc8d7ab61a57ef2ba865d59> viboes <https://github.com/boostorg/thread/commits/develop?author=viboes> committed 23 minutes ago viboes <https://github.com/boostorg/thread/commits/develop?author=viboes> committed 42 minutes ago viboes <https://github.com/boostorg/thread/commits/develop?author=viboes> committed an hour ago viboes <https://github.com/boostorg/thread/commits/develop?author=viboes> committed an hour ago akrzemi1 <https://github.com/boostorg/thread/commits/develop?author=akrzemi1> committed 15 hours ago 10. Commits on Apr 18, 2016 1. fix crash in regression tests because of tls <https://github.com/boostorg/thread/commit/db5898ba46d308eb35b56b756ec2a9a7c77b15df> Philippe Daouadi committed 3 days ago 1. Commits on Apr 17, 2016 1. Merge branch 'develop' of github.com:boostorg/thread into develop <https://github.com/boostorg/thread/commit/c7a5122fd3333800fd33f3407f6868a79694407d> viboes <https://github.com/boostorg/thread/commits/develop?author=viboes> committed 3 days ago viboes <https://github.com/boostorg/thread/commits/develop?author=viboes> committed 3 days ago 3. Commits on Apr 16, 2016 1. fix leak in tls <https://github.com/boostorg/thread/commit/e29a4129e85f7f7c9bdb50ce314c4acb511985f5> Philippe Daouadi committed 5 days ago # # fix memory leak. <https://github.com/boostorg/thread/commit/57f34e1ea4572a5033baa61802a4783c48951eba> viboes <https://github.com/boostorg/thread/commits/develop?author=viboes> committed 30 minutes ago # # fix memory leak. <https://github.com/boostorg/thread/commit/daae305bf77a84cb7446096ae31d61084362fe49> viboes <https://github.com/boostorg/thread/commits/develop?author=viboes> committed 32 minutes ago # # call interrupt only if joinable. <https://github.com/boostorg/thread/commit/55a1325f303957d5637819432a40a70bfbd66e0e> viboes <https://github.com/boostorg/thread/commits/develop?author=viboes> committed 32 minutes ago # # Describe what happens on thread::interrupt with a non-a-thread. <https://github.com/boostorg/thread/commit/46f0be2dce1ea847d1664d078dfdb2e4cdd0002d> viboes <https://github.com/boostorg/thread/commits/develop?author=viboes> committed 33 minutes ago # # Merge pull request <https://github.com/boostorg/thread/commit/98dbc9da413d5b30cfb041338492da53f527c6e1> #81 <https://github.com/boostorg/thread/pull/81> from blastrock/develop <https://github.com/boostorg/thread/commit/98dbc9da413d5b30cfb041338492da53f527c6e1> # # Merge pull request <https://github.com/boostorg/thread/commit/640e1acb9836b2e0b74695b3b5baa527698a9b2d> #78 <https://github.com/boostorg/thread/pull/78> from brycelelbach/patch-1 <https://github.com/boostorg/thread/commit/640e1acb9836b2e0b74695b3b5baa527698a9b2d> # # Merge pull request <https://github.com/boostorg/thread/commit/7f2535015d9eca75115821ba0f8c8c74d30701b1> #82 <https://github.com/boostorg/thread/pull/82> from akrzemi1/patch-1 <https://github.com/boostorg/thread/commit/7f2535015d9eca75115821ba0f8c8c74d30701b1> # # fix scoped_thread move assignement description. <https://github.com/boostorg/thread/commit/aab2891cdbc3c19ef492f16a7c473a4ccc488bff> viboes <https://github.com/boostorg/thread/commits/develop?author=viboes> committed an hour ago # # docs: thread_interruption never calls terminate() <https://github.com/boostorg/thread/commit/8bbe005bbc2f2a72443a8b5f031a1fcf1145f36c> # # Merge pull request <https://github.com/boostorg/thread/commit/b932b8c015bb9398f071a399a33a639d5061ca90> #80 <https://github.com/boostorg/thread/pull/80> from blastrock/develop <https://github.com/boostorg/thread/commit/b932b8c015bb9398f071a399a33a639d5061ca90> # # call on_desctruction on scoped_thread move assignment. <https://github.com/boostorg/thread/commit/411798367b075a0e993010252eec81b846e011ef> viboes <https://github.com/boostorg/thread/commits/develop?author=viboes> committed 3 days ago
On 4/21/2016 1:24 AM, Vicente J. Botet Escriba wrote:
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.
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 08:39, Vladimir Prus a écrit :
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. Vicente
On 4/21/2016 8:17 PM, Vicente J. Botet Escriba wrote:
I don't think that fixing a typo is a necessary patch at this point.
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.
* call interrupt only if joinable. (optimization cosmetic) https://github.com/boostorg/thread/commit/55a1325f303957d5637819432a40a70bfb...
If it is cosmetic, can it wait for next release?
* 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? Thanks, -- Vladimir Prus http://vladimirprus.com
Le 23/04/2016 21:44, Vladimir Prus a écrit :
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 :
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:06, Vicente J. Botet Escriba a écrit :
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; } Vicente
Le 24/04/2016 00:11, Vicente J. Botet Escriba a écrit :
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
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, -- Vladimir Prus http://vladimirprus.com
On 4/20/16 12:17 PM, Vladimir Prus wrote:
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. Robert Ramey
On Fri, Apr 22, 2016 at 10:11 AM, Robert Ramey <ramey@rrsd.com> wrote:
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
On 4/22/16 8:31 AM, Rene Rivera wrote:
it is the very latest one on the develop branch = 3eb2bda
If it's small enough we likely would say yes..
It's basically a change in one function. It is the only change.
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. Robert Ramey
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.
On 4/22/16 11:11 AM, John Maddock wrote:
I'm aware of this. But it seems specific to msvc 10 which I don't have. I presume that this will require some workaround for some problem in the msvc 10 standard library implementation. I consider it low priority.
On the test matrix, the serialization library fails with all compilers on the mingw platform. I've asked about this on the build list a couple of times and gotten no response. It's low priority.
I could not get my cygwin system to build and test the serialization library. This particular error might be addressed by this pending high priority fix.
+ lots more, all with the same failure as: http://www.boost.org/development/tests/develop/developer/output/timber-cygwi...
same as above.
Intel 16 win:
Almost everything fails with linker errors.
Hmm - the current develop test matrix only shows a couple of errors. All are linker errors apparently related to one function which is only used in a couple of cases. Again - low priority. I have this one fix. It means that all xml output has an invalid ending tag on all tests/platforms etc. I consider this as super high priority as anyone who were to use the library would be generating invalid xml files and sometimes storing them indefinitely. I'd rather not imagine what the repercussions of this might be. I'd rather not. The other issues are corner cases on specific configurations. I always have this. I strive to diminish them every release. In this round, I made the tests for output of non-ascii characters more stringent and implemented limited visibilty for gcc/clang compilers. This generated a large number of new test failures. This not an indicator of declining quality or regressions, but rather a side effect of insisting on a higher quality product. I recognize that I can't make a perfect product. I strive to make each version better than the previous one. In any case, given that I haven't received any new information, I'll merge the change from develop into master.
Let me know if there's anything I can do.
I appreciate your help.
HTH, John.
Robert Ramey
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. — Noel
On 4/23/16 12:02 PM, Belcourt, Kenneth wrote:
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
Guilty.
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.
I'll take a look at this when we get 1.61 out the door
Thanks, ping me if I can help test or make changes.
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.
Sounds good. Noel
Am Saturday 23 April 2016, 23:29:34 schrieb Belcourt, Kenneth:
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 4/25/2016 12:27 AM, Belcourt, Kenneth wrote:
No promises, but please post when tests do cycle. Also, I left inline comment on commit on GitHub, could you take a look? -- Vladimir Prus http://vladimirprus.com
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? -- Vladimir Prus http://vladimirprus.com
On Mon, Apr 25, 2016 at 2:05 PM, Belcourt, Kenneth <kbelco@sandia.gov> wrote:
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? -- -- 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/16 9:49 AM, Belcourt, Kenneth wrote:
Yep, right you are. All of Boost.MPI depends on Boost.Serialization, that’s not ideal.
Thinking about it that doesn't surprise me. But I wonder if it's necessary that MPI depends on array_wrapper? It seems to me that it would only depend upon it if one is transmitting an array. and of course it doesn't help the the serialization library is a little ambiguous regarding what its type requirements are. Robert Ramey
On Tue, Apr 26, 2016 at 3:36 AM, alainm <alain.miniussi@oca.eu> 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. -- -- 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:
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 Tue, Apr 26, 2016 at 2:14 PM, Vladimir Prus <vladimir.prus@gmail.com> wrote:
Graph is mostly OK. Graph Parallel looks entirely broken also. -- -- Rene Rivera -- Grafik - Don't Assume Anything -- Robot Dreams - http://robot-dreams.net -- rrivera/acm.org (msn) - grafikrobot/aim,yahoo,skype,efnet,gmail
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 4/26/2016 10:24 PM, Belcourt, Kenneth wrote:
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. graph_parallel/example breakage should not hold the release, I think. -- Vladimir Prus http://vladimirprus.com
Just cherry-picked these two commits into master to fix the serialization issue: commit 0dce8d2c2ab273c488d708fb3e66dbb9c4298a79 Author: Jürgen Hunold <jhunold@gmx.eu> commit 7d33e519b3daa01e9bb4a5545d5d084c45875e4f Author: K. Noel Belcourt <kbelco@sandia.gov> 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
There’s a small change to graph develop: include/boost/pending/relaxed_heap.hpp, that fixes the graph and graph_parallel results on master, here’s the diff (haven’t found a commit to cherry-pick yet). diff --git a/include/boost/pending/relaxed_heap.hpp b/include/boost/pending/relaxed_heap.hpp index 13f7af4..8be4484 100644 --- a/include/boost/pending/relaxed_heap.hpp +++ b/include/boost/pending/relaxed_heap.hpp @@ -191,7 +191,9 @@ public: return !smallest_value || (smallest_value->kind == largest_key); } - bool contains(const value_type& x) const { return groups[get(id, x)]; } + bool contains(const value_type& x) const { + return static_cast<bool>(groups[get(id, x)]); + } Okay to apply this change to master, we should be all green for graph, graph_parallel, and MPI on master? — Noel
and this change to graph/develop to fix one last issue. s988329:graph kbelco$ git diff diff --git a/include/boost/graph/adjacency_matrix.hpp b/include/boost/graph/adjacency_matrix.hpp index b1078d9..ade7351 100644 --- a/include/boost/graph/adjacency_matrix.hpp +++ b/include/boost/graph/adjacency_matrix.hpp @@ -443,7 +443,7 @@ namespace boost { // graph type. Instead, use directedS, which also provides the // functionality required for a Bidirectional Graph (in_edges, // in_degree, etc.). - BOOST_STATIC_ASSERT(type_traits::ice_not<(is_same<Directed, bidirectionalS>::value)>::value); + BOOST_STATIC_ASSERT(!(is_same<Directed, bidirectionalS>::value)); typedef typename mpl::if_<is_directed, bidirectional_tag, undirected_tag>::type These tests all pass on master with the above changes: graph/test # test-suite graph graph_parallel/test # test-suite graph/parallel mpi/test # test-suite mpi Also with the above fixes, the graph_parallel/example issue is now a linker error due to a missing dependency on Boost.MPI. I can supply the user with a local patch to get them going. — Noel
On 4/26/2016 11:59 PM, Belcourt, Kenneth wrote:
Noel, if you're still around, please commit these patches too. -- Vladimir Prus http://vladimirprus.com
Sorry about the delay, just pushed this commit to graph master. commit ed989311185caf8384dd7e42315f58dcd349d3eb Author: K. Noel Belcourt <kbelco@sandia.gov> 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.
On 4/27/2016 2:48 PM, Belcourt, Kenneth wrote:
Thanks, the superprorject was updated - please start the tests. -- Vladimir Prus http://vladimirprus.com
On Wednesday, April 27, 2016 09:43 PM, Vladimir Prus wrote:
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 4/23/2016 8:39 PM, Robert Ramey wrote:
Robert, you commit on master includes this: diff --git a/test/test_z.cpp b/test/test_z.cpp index 2a3e56f..bd8aa34 100644 --- a/test/test_z.cpp +++ b/test/test_z.cpp @@ -1,4 +1,4 @@ -#if 1 +#if 0 /////////1/////////2/////////3/////////4/////////5/////////6/////////7/////////8 // test_optional.cpp @@ -63,7 +63,7 @@ int test_main( int /* argc */, char* /* argv */[] ) // EOF -#else +#elseif 0 I don't believe '#elseif' is a valid preprocessor directive. Should it be '#elif? Was this change actually meant to be merged to master? This test file is not built by test Jamfile. -- Vladimir Prus http://vladimirprus.com
participants (11)
-
alainm -
Belcourt, Kenneth -
Ben Pope -
John Maddock -
Jürgen Hunold -
Peter Dimov -
Rene Rivera -
Robert Ramey -
Thomas Trummer -
Vicente J. Botet Escriba -
Vladimir Prus