Winter is coming... #46
Conversation
The API should be complete although primitive. No documentation yet.
Removed a few "unsigned int" comparuson warnings with g++ Splitted bug test_main function
Conflicts: src/communicator.cpp
doc: Fix typos
Fix: adapt to renaming of serialization::array_wrapper Tested that both graph_parallel and MPI work fine with El Capitan and clang, thanks for the patch!
Newer MPI uses MPI_Comm_set_errhandler and MPI_Comm_get_attr.
Added test case to send recv a vector of udt with an overload of get_mpi_datatype. Added test to Jamfile for nightly testing.
Add remark in Jamfile that test case requires -std=c++11.
|
@aminiussi, I think you are one of Boost.MPI maintainers, aren't you? If you feel #47 and #46 are ready for master, you could merge them yourself. IMO, merging the fixes from develop and #47 is better than doing nothing since Boost.MPI is completely broken in 1.64 and will be still as broken in 1.65. |
|
Yes, I saw a few months ago I was in that list. But being both the submitter/reviewer/executioner of those pull requests makes me uncomfortable. If I did, it would be in opposition with the current cherry pick release model (which I do not approve, but still) without having heard of the exacts problems/platforms mentioned by @Belcourt. |
|
Well, at least merging #47 to develop would be desirable so that it gets tested and fixes a few test failures. Regarding community opinion I think it's best to write a message to the Boost developers mailing list. Personally, as I mentioned, I think the changes make the library "better" (at least, it compiles) and therefore should be merged before the 1.65 release. Regarding Sandia, I think @Belcourt manages these testers. You can also request test logs through the dev ML. |
Fix mpi-python component compilation.
Add const conversion to accomodate open MPI 1.6
|
Is there any plan to merge this PR? Right now I have to patch boost mpi to be able to use it with nvcc (this has been fixed a year ago in this branch) |
|
On a related note, has anyone any news from Noel Belcourt ?
Otherwise I'm afraid I'll have to merge it on my own.
Cheers
…On 13/02/2018 14:34, Bruno Turcksin wrote:
Is there any plan to merge this PR? Right now I have to patch boost
mpi to be able to use it with nvcc (this has been fixed a year ago in
this branch)
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#46 (comment)>, or
mute the thread
<https://github.com/notifications/unsubscribe-auth/AAhsjNs3FdSNarok6UiAlJDEFCHejjyhks5tUY9VgaJpZM4MJ8VO>.
|
|
@aminiussi would you please make sure 90e84fe makes it into 1.67.0? |
|
If this is a breaking change, then it really should be merged today, if not then there's a week left. If that isn't possible, let us (the release managers) know. |
|
The idea would be to merge long due develop on master.
So it's big, but has been tested as devlop for a long time. Is that ok ?
I'm relaunching my linux tests
Thk
…On 20/02/2018 19:41, Daniel James wrote:
If this is a breaking change, then it really should be merged today,
if not then there's a week left. If that isn't possible, let us (the
release managers) know.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#46 (comment)>, or
mute the thread
<https://github.com/notifications/unsubscribe-auth/AAhsjGNd6GYMjAbhxbUMRCaWsceaOxgsks5tWxHJgaJpZM4MJ8VO>.
|
|
I'm not keen on massive merges, but if it's unavoidable then I think the important thing is to try to get people to test the beta. |
|
IMHO, it's been tested in develop for ages. It doesn't matter how big it is, we should accept develop as the "best" Boost.MPI version there is and just merge it. Otherwise, if develop is considered broken somehow then let's revert it to master state. |
|
I don't think the length of time they've been tested for makes much of a difference, as it's always the same tests. I think there were problems with pointer containers in the last release, which was a merge of old develop changes. |
|
Folks, I’m completely unable to help with MPI, can someone else (Alain) please help out with this? Sorry about the delay.
Noel Belcourt
On Feb 20, 2018, at 11:25 AM, Damien L-G <notifications@github.com<mailto:notifications@github.com>> wrote:
@aminiussi<https://github.com/aminiussi> would you please make sure 90e84fe<90e84fe> makes it into 1.67.0?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub<#46 (comment)>, or mute the thread<https://github.com/notifications/unsubscribe-auth/AA65bebPup_r9xdkzfhMVp5M3w1XOpuDks5tWw40gaJpZM4MJ8VO>.
|
|
On 20/02/2018 23:12, Daniel James wrote:
I don't think the length of time they've been tested for makes much of
a difference, as it's always the same tests. I think there were
problems with pointer containers in the last release, which was a
merge of old develop changes.
Didn't saw these, if anyone has a pointer to the problem, that would be
welcomed, if only to add a test ?
The mains issues usually comes from source incompatibilities between mpi
and serialize (mpi uses the internals of serialize, which is something
to fix, so some source change in serialize impact mpi in a difficult to
predict way (since both libs have two branches, and boost distribution
on the test platform can trigger/mask issues)).
So yes, the huge merge is a problem, but nobody knows how to split that
huge merge into small one without doing more harm than good.
So if develop appears not to be good enough, I think we might as well
reset it to master and forget about the last years development. But if
we can cover enough platform, I think it's worth give it a try.
The reason why we're in this situation is described in this #46 issue.
Cheers
… —
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#46 (comment)>, or
mute the thread
<https://github.com/notifications/unsubscribe-auth/AAhsjAmm1gwkX7vgxdSyiLhsmB-t7PIbks5tW0MwgaJpZM4MJ8VO>.
|
|
Sorry, pointer containers is another library, not your problem. I was just using it to illustrate a point. I'm afraid it's up to you whether or not develop is good enough. But don't be over-cautious, it looks like people want these improvements. We understand that you're in a difficult position and appreciate your work. I hope I wasn't discouraging. |
|
Discouraging ?
I do Fortran with astronomers on a weekly basis....
;-)
…On 20/02/2018 23:51, Daniel James wrote:
Sorry, pointer containers is another library, not your problem. I was
just using it to illustrate a point.
I'm afraid it's up to you whether or not develop is good enough. But
don't be over-cautious, it looks like people want these improvements.
We understand that you're in a difficult position and appreciate your
work. I hope I wasn't discouraging.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#46 (comment)>, or
mute the thread
<https://github.com/notifications/unsubscribe-auth/AAhsjI8GPBeO5WroKyk3jcI66ZF0C4DDks5tW0xdgaJpZM4MJ8VO>.
|
Even if so, I assume those problems were localized and sorted out. Which ultimately resulted in a better code rather than stagnation. |
|
Does anyone has the possibility to give it a try on windows platforms ?
I tested intel 17.0.4 with intel's MPI in the plain, C++11, C++14
flavour and gcc 4.8.5.
The configuration is everything on master except mpi which is develop.
I'll have a look on the regression web pages to check if they're not
tooo out of date.
thk
… —
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#46 (comment)>, or
mute the thread
<https://github.com/notifications/unsubscribe-auth/AAhsjGtRNJFFp6N2H_N-3RklYy_wc0NZks5tW1sLgaJpZM4MJ8VO>.
|
|
Ok, so we have the test on the boost web site and my local linux tests
and they look ok.
I'm pushing the merge.
…On 21/02/2018 00:53, Andrey Semashev wrote:
I think there were problems with pointer containers in the last
release, which was a merge of old develop changes.
Even if so, I assume those problems were localized and sorted out.
Which ultimately resulted in a better code rather than stagnation.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#46 (comment)>, or
mute the thread
<https://github.com/notifications/unsubscribe-auth/AAhsjGtRNJFFp6N2H_N-3RklYy_wc0NZks5tW1sLgaJpZM4MJ8VO>.
|
Right now, develop passes all its testing with both develop and master branch of serialization.
Having both is a security I think.
They pass on g++5.2.0 OpenMpi on ubuntu and Intel 15.0.3 (based on g++4.4.7 lib, pretty antique, which is reassuring for compatibility) default mode and intel MPI on CentOS
I think we should check both default compile option and explicit C++11 activation.
I can try intel 17 on CentOS7.
@Belcourt I think you have access to other platforms, I'm afraid I do not have access to MS environment.