Jeff, I don't understand why you ignore all the work that has been done with this ticket and suggest your own metric. Was the information I provided unreliable or untrue? As I said, it took me about 2.5h to implement the entire change on the MSMPI code base; yes there were many internal functions that had const in it, but also many that did not. I don't think that by any measure this is a significant work for any implementer. More than that, this interface change was tested using the ANL test suite and the Intel complete test suite, without a single compile or runtime error over multiple platforms and compilers. Again, this was not a significant work item; and I believe that OpenMPI has a regression suite that crosses platform and compilers which is easy to run (as you described to me many times). With this information that I have already provided before, I don't understand your claims; unless you think that they are biased and unreliable. Hence this ticket completely meets MPI 2.2 requirements in scope and backward compatibility. Thanks, .Erez -----Original Message----- From: mpi-22-bounces_at_[hidden] [mailto:mpi-22-bounces_at_[hidden]] On Behalf Of Jeff Squyres Sent: Thursday, March 19, 2009 5:20 AM To: Bronis R. de Supinski; MPI 2.2 Subject: Re: [Mpi-22] Ticket #46: Add const Keywordto the Cbindings-implementation On Mar 19, 2009, at 12:03 AM, Bronis R. de Supinski wrote:
I have been quiet on this debate but I am to the point that I feel a need to speak up. I think the "significant changes" reason is a canard (I think Brian and Jeff believe it but it is still a red herring for the most part). The changes to support it are not significant. You can implement it by casting it away early.
The changes *are* significant. I count 90 top-level MPI API functions that are affected by this proposal. The bar for 2.2 is "trivial" implementation efforts, no? This is not trivial. The MPICH diff was ~10,000 lines. Apparently, they chose to go above and beyond the requirement and propagate const to lower layers (vs. casting it away immediately), but still -- if a 2.2 change can inspire a 10,000 line diff, that just seems like it doesn't meet the spirit of the "trivial" implementation requirement. Indeed, in doing the "simple" cast-it-away-immediately approach implementation, editing and testing each of the 90 functions will require a good amount of effort. Sure, the first-wave addition of "const" across all of the affected functions is probably relatively easy -- one code monkey and several hours. But how long will it take you to find the one place where you put "const" in the wrong location? How long will it take you to write new tests to verify the const-ness in all the right places? To be clear: it's a "not significant" change to a code monkey. But try to tell your QA guys that this is not significant -- they'll freak out. Hence, if you take the overall scope of both the change and the additional testing to validate this change, this is a large scale implementation effort. I just don't see what the rush is to get this into 2.2. I think Brian makes several good arguments, one of which is: those who want const can put it in today. It hypothetically shouldn't break any existing user codes (this is the code monkey in me talking, not the QA rep), and those implementors who want it for stronger contracts can have it. -- Jeff Squyres Cisco Systems _______________________________________________ mpi-22 mailing list mpi-22_at_[hidden] http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22