Re: [Boost-users] [EXTERNAL] Re: [MPI] missing symbols using serialization's static library design
"Barrett, Brian W" <bwbarre@sandia.gov> wrote in message news:<69A29AB53D57F54D81061A9E4E45B8FD239CC111@EXMB01.srn.sandia.gov>...
On 10/17/12 1:00 PM, "Robert Ramey" <ramey@rrsd.com> wrote:
Barrett, Brian W wrote:
Unfortunately, I'm barely competent in using Boost.MPI and Boost.Serialization. I'm definitely not in a position to be able to apply a patch.
What I'm getting from your responses and the general silence elsewhere is that the right answer is to deal with the incompatibilities between versions of Boost and explicitly instantiate all the internal MPI archivers and hope for the best. It's a little painful, but I think we can do that.
Well, your organization could contract with me to address this for you. I've done special work for several companies which use the serialization library. This work has been contributed to boost and become part of the distributed package. So a) The organization gets what it needs for a reasonable cost. b) Any generally useful enhancements get included in the library So it helps everyone all around. Thanks in advance for considering this. Robert Ramey
Thanks,
Brian
-- Brian W. Barrett Scalable System Software Group Sandia National Laboratories
On Thu, Oct 18, 2012 at 10:33 AM, Robert Ramey <ramey@rrsd.com> wrote:
"Barrett, Brian W" <bwbarre@sandia.gov> wrote in message news:<69A29AB53D57F54D81061A9E4E45B8FD239CC111@EXMB01.srn.sandia.gov>...
On 10/17/12 1:00 PM, "Robert Ramey" <ramey@rrsd.com> wrote:
Barrett, Brian W wrote:
Unfortunately, I'm barely competent in using Boost.MPI and Boost.Serialization. I'm definitely not in a position to be able to apply a patch.
What I'm getting from your responses and the general silence elsewhere is that the right answer is to deal with the incompatibilities between versions of Boost and explicitly instantiate all the internal MPI archivers and hope for the best. It's a little painful, but I think we can do that.
Well, your organization could contract with me to address this for you.
I've done special work for several companies which use the serialization library. This work has been contributed to boost and become part of the distributed package. So
a) The organization gets what it needs for a reasonable cost. b) Any generally useful enhancements get included in the library
So it helps everyone all around.
Thanks in advance for considering this.
I'm not at all versed (let alone well-versed) in either Boost.Serialization nor Boost.MPI, so I am not sure what Brian's issue exactly is, but I'm curious, Robert, if you acknowledge this as an issue? It seems strange to require a user to fiddle with stuff in the detail namespace of a library. Also, and I mean this with the best of intentions, but your (Robert's) response here could be construed as...unhelpful, and I'm taking specific aim at the parting sarcasm. If you don't have the time and/or resources to address this or some other issue, I think stating so is sufficient. - Jeff
Jeffrey Lee Hellrung, Jr. wrote:
On Thu, Oct 18, 2012 at 10:33 AM, Robert Ramey <ramey@rrsd.com> wrote:
"Barrett, Brian W" <bwbarre@sandia.gov> wrote in message news:<69A29AB53D57F54D81061A9E4E45B8FD239CC111@EXMB01.srn.sandia.gov>...
On 10/17/12 1:00 PM, "Robert Ramey" <ramey@rrsd.com> wrote:
Barrett, Brian W wrote:
Unfortunately, I'm barely competent in using Boost.MPI and Boost.Serialization. I'm definitely not in a position to be able to apply a patch.
What I'm getting from your responses and the general silence elsewhere is that the right answer is to deal with the incompatibilities between versions of Boost and explicitly instantiate all the internal MPI archivers and hope for the best. It's a little painful, but I think we can do that.
Well, your organization could contract with me to address this for you.
I've done special work for several companies which use the serialization library. This work has been contributed to boost and become part of the distributed package. So
a) The organization gets what it needs for a reasonable cost. b) Any generally useful enhancements get included in the library
So it helps everyone all around.
Thanks in advance for considering this.
I'm not at all versed (let alone well-versed) in either Boost.Serialization nor Boost.MPI, so I am not sure what Brian's issue exactly is, but I'm curious, Robert, if you acknowledge this as an issue? It seems strange to require a user to fiddle with stuff in the detail namespace of a library.
I don't doubt it's an issue. Note that I didn't write the MPI serilializat and in fact have never even glanced at it.
Also, and I mean this with the best of intentions, but your (Robert's) response here could be construed as...unhelpful, and I'm taking specific aim at the parting sarcasm. If you don't have the time and/or resources to address this or some other issue, I think stating so is sufficient.
This is a an email blunder on my part. I meant to send this as a private message but I guess I pressed the wrong button. There was / is no sarcasm intended. This is a serious proposal.. For several companies, I have made special enhancements to the serialization library. Most of these ended up as part of the library. One case in particular was work on the portable_binary?iarchive. This addresses the question: Organization X makes use of a library - in this case - the serialization library. Experience is just great - except for one thing. Maybe it needs an enhancement, or some other platform or whatever. I, nor anyone else, can justify investing the effort for this one user who expressed and interest. So Organization X has a few options. a) write their own library This is very expensive and will delay any project. b) use another library This will cost time adjust to another library - and there is the risk that a simlar situation pops up again c) pay one of their own programmers to extend/modify the library and keep it as their specialized copy Not cheap. And now they've added on a maintainence burden in that future enhancements to the Boost version are not available to them with investing more resources. d) pay someone to make the changes and get them accepted as enhancements into the Boost version. Still not cheap - and an extra hassle to try to get into boost so that some else is responsable for maintaining it. e) pay me to do the work - it IS the way I make a living - and get everything they need for the minimum investment AND make a contribution to Boost by doing so. It's win-win-win. Of course anyone else is free to make the same offer. Personally I think it would be a great thing if certain organizations were to "sponsor" maintainence of certain libraries in which they have an interest in. This would help address the issue of "orphan libraries" which we are currently suffering from. So, to re-iterate, I might be willing to plead guilty to past episodes of sarcasm and/or perhaps other contencious or vexatious behavior, But I'm going to plead innocent on this one. Robert Ramey
On Fri, Oct 19, 2012 at 12:00 AM, Robert Ramey <ramey@rrsd.com> wrote:
Jeffrey Lee Hellrung, Jr. wrote:
On Thu, Oct 18, 2012 at 10:33 AM, Robert Ramey <ramey@rrsd.com> wrote:
"Barrett, Brian W" <bwbarre@sandia.gov> wrote in message news:<69A29AB53D57F54D81061A9E4E45B8FD239CC111@EXMB01.srn.sandia.gov>...
On 10/17/12 1:00 PM, "Robert Ramey" <ramey@rrsd.com> wrote:
Barrett, Brian W wrote:
Unfortunately, I'm barely competent in using Boost.MPI and Boost.Serialization. I'm definitely not in a position to be able to apply a patch.
What I'm getting from your responses and the general silence elsewhere is that the right answer is to deal with the incompatibilities between versions of Boost and explicitly instantiate all the internal MPI archivers and hope for the best. It's a little painful, but I think we can do that.
Well, your organization could contract with me to address this for you.
I've done special work for several companies which use the serialization library. This work has been contributed to boost and become part of the distributed package. So
a) The organization gets what it needs for a reasonable cost. b) Any generally useful enhancements get included in the library
So it helps everyone all around.
Thanks in advance for considering this.
I'm not at all versed (let alone well-versed) in either Boost.Serialization nor Boost.MPI, so I am not sure what Brian's issue exactly is, but I'm curious, Robert, if you acknowledge this as an issue? It seems strange to require a user to fiddle with stuff in the detail namespace of a library.
I don't doubt it's an issue. Note that I didn't write the MPI serilializat and in fact have never even glanced at it.
Ah, okay. Fair enough. And I suppose to don't really have any Boost.MPI experts/maintainers lurking...? Brian, it sounds like at a minimum you should file a trac ticket against Boost.MPI (if one does not already exist), so at least the issue is recorded.
Also, and I mean this with the best of intentions, but your
(Robert's) response here could be construed as...unhelpful, and I'm taking specific aim at the parting sarcasm. If you don't have the time and/or resources to address this or some other issue, I think stating so is sufficient.
This is a an email blunder on my part. I meant to send this as a private message but I guess I pressed the wrong button. There was / is no sarcasm intended. This is a serious proposal.. For several companies, I have made special enhancements to the serialization library. Most of these ended up as part of the library. One case in particular was work on the portable_binary?iarchive.
[...] This is fine, and it's occasionally difficult to evaluate tone in an email. That's all. - Jeff
On 10/19/12 6:50 AM, "Jeffrey Lee Hellrung, Jr." <jeffrey.hellrung@gmail.com> wrote:
I'm not at all versed (let alone well-versed) in either Boost.Serialization nor Boost.MPI, so I am not sure what Brian's issue exactly is, but I'm curious, Robert, if you acknowledge this as an issue? It seems strange to require a user to fiddle with stuff in the detail namespace of a library.
I don't doubt it's an issue. Note that I didn't write the MPI serilializat and in fact have never even glanced at it.
Ah, okay. Fair enough. And I suppose to don't really have any Boost.MPI experts/maintainers lurking...?
Brian, it sounds like at a minimum you should file a trac ticket against Boost.MPI (if one does not already exist), so at least the issue is recorded.
I filed a bug; hopefully someone will eventually have some time to look at it. On the other hand, if no one is actively working on Boost.MPI, it's more likely that using interfaces in the detail namespace won't cause problems with future compatibility :). Brian
participants (1)
-
Barrett, Brian W -
Jeffrey Lee Hellrung, Jr. -
Robert Ramey