From: Kirk, B. (JSC-EG311) <ben...@na...> - 2014-01-13 15:50:25
|
OK, this could kick off a lot of discussion, but here goes… I'd like to polish a release this week if possible. Roy'd previously mentioned calling it 1.0, but I'd like to go with v0.9.3 because 1) I'm not aware of anything drastically different vs 0.9.2, but correct me if I'm wrong; 2) In any case I'd like to wire brush the code and remove all the APIs that have been deprecated for ages; 3) I'd like to remove the default comm_world business for 1.0. So v0.9.3 could be imminent with then 1.0 a API cleanup follow-on. But what about C++11? I could see 1.0 as a 'maintenance stream' where we back port important bug fixes but otherwise leave it alone. New development could occur on a master requiring C++11, unless there is a consensus otherwise. It's 2014 already, and a good quorum of C++11 features are implemented in pretty much all relevant compilers. Specifically for the MOOSE guys, what's the oldest compiler you are compelled to support? -Ben |
From: Roy S. <roy...@ic...> - 2014-01-13 16:29:18
|
On Mon, 13 Jan 2014, Kirk, Benjamin (JSC-EG311) wrote: > I'd like to polish a release this week if possible. Roy'd previously mentioned calling it 1.0, but I'd like to go with v0.9.3 because > 1) I'm not aware of anything drastically different vs 0.9.2, but correct me if I'm wrong; > 2) In any case I'd like to wire brush the code and remove all the APIs that have been deprecated for ages; > 3) I'd like to remove the default comm_world business for 1.0. > > So v0.9.3 could be imminent with then 1.0 a API cleanup follow-on. This all sounds great. Just to be clear, we're talking 0.9.3 this week, then 1.0-rc1 ASAP after we go through and shred deprecated stuff? My "warnings fixes" branch might be worth merging into the latter too. > But what about C++11? I could see 1.0 as a 'maintenance stream' > where we back port important bug fixes but otherwise leave it alone. We've started doing something like this already, no? Each release tends to have one or two "whoops" entries in the major.minor.subminor.whoops numbering conventions. Or are you thinking of keeping 1.0 alive well after the next official 1.x release? I guess that might not be much more work? Instead of backporting major bug fixes to the previous stable release, we'd backport to both the previous stable release and the 1.0.x branch? But right now we never backport minor bug fixes, for bugs of the kind that nobody would be likely to trigger in the few months before the next official release. If we have a bugfixes-only branch then we no longer have that leeway. > New development could occur on a master requiring C++11, unless > there is a consensus otherwise. It's 2014 already, and a good > quorum of C++11 features are implemented in pretty much all relevant > compilers. Gah. I can't believe *I'm* objecting (my current app development is using C++1y features, which like C++11 features are awesome), but AFAIK full C++11 support is *still* limited to g++ and clang++. I'm not sure I want to deal with the hassles of trying to remember what's in C++11 versus what's in Lowest-Common-Denominator-Compiler. https://wiki.apache.org/stdcxx/C%2B%2B0xCompilerSupport http://cpprocks.com/c11-compiler-support-shootout-visual-studio-gcc-clang-intel/ http://software.intel.com/en-us/articles/c0x-features-supported-by-intel-c-compiler I can already see a feature I'd like to use that didn't make it into icpc 13, and three features that aren't even in icpc 14. I could probably be talked into us supporting the intersection of "stuff in C++11" and "stuff in a single broken compiler, X", where X is something I can get auto-testing in buildbot, preferably icpc 11.1, 12.1, or 13.1. But then everyone with older pgc++ or other "not quite C++11 compatible" compilers will be gambling. --- Roy |
From: Derek G. <fri...@gm...> - 2014-01-13 16:35:06
|
Absolutely 100% against C++11 Portability is one of the main areas where we are well beyond our competition. I would say that nearly half of the cluster installations we do are using compilers that are at least 4 to 5 years old. We can't afford to tell everyone "you need to upgrade your compiler" as many of these people are locked into some ancient Redhat and changing that is nontrivial. C++11 is not going going to be viable for a few more years. I wish it were not the the case... we talk about how we would love to use some of those features all the time. But... it just can't happen yet. Everything else sounds good to me. It will force me to get off my butt and finally stop using comm_world ;-) Also, another suggestion: MOOSE is going open source soon (really!) and it's going up on GitHub as well. Is now the time to start looking into the development model/process for libMesh (and MOOSE). ie codifying a set of branches (like devel/stable/master) and putting together a plan for testing everything, etc? We talked about this a while ago and we all decided to wait and see how things were working on GitHub before making any decisions... and I think that time might be upon us. Derek On Mon, Jan 13, 2014 at 8:50 AM, Kirk, Benjamin (JSC-EG311) < ben...@na...> wrote: > OK, this could kick off a lot of discussion, but here goes… > > I'd like to polish a release this week if possible. Roy'd previously > mentioned calling it 1.0, but I'd like to go with v0.9.3 because > 1) I'm not aware of anything drastically different vs 0.9.2, but correct > me if I'm wrong; > 2) In any case I'd like to wire brush the code and remove all the APIs > that have been deprecated for ages; > 3) I'd like to remove the default comm_world business for 1.0. > > So v0.9.3 could be imminent with then 1.0 a API cleanup follow-on. > > But what about C++11? I could see 1.0 as a 'maintenance stream' where we > back port important bug fixes but otherwise leave it alone. New > development could occur on a master requiring C++11, unless there is a > consensus otherwise. It's 2014 already, and a good quorum of C++11 > features are implemented in pretty much all relevant compilers. > > Specifically for the MOOSE guys, what's the oldest compiler you are > compelled to support? > > -Ben > > > > ------------------------------------------------------------------------------ > CenturyLink Cloud: The Leader in Enterprise Cloud Services. > Learn Why More Businesses Are Choosing CenturyLink Cloud For > Critical Workloads, Development Environments & Everything In Between. > Get a Quote or Start a Free Trial Today. > > http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk > _______________________________________________ > Libmesh-devel mailing list > Lib...@li... > https://lists.sourceforge.net/lists/listinfo/libmesh-devel > |
From: Roy S. <roy...@ic...> - 2014-01-13 16:44:42
|
On Mon, 13 Jan 2014, Derek Gaston wrote: > Portability is one of the main areas where we are well beyond our competition. I would say that nearly half of the cluster installations we do > are using compilers that are at least 4 to 5 years old. We can't afford to tell everyone "you need to upgrade your compiler" as many of these > people are locked into some ancient Redhat and changing that is nontrivial. Anyone stuck in this situation should know that installing and using a new gcc is easier than it used to be... assuming you have a gigabyte or more to devote to it. Since that isn't always a safe assumption, this is a pretty good argument for sticking with C++03 for a while. > Also, another suggestion: MOOSE is going open source soon (really!) > and it's going up on GitHub as well. Is now the time to start > looking into the development model/process for libMesh (and MOOSE). > ie codifying a set of branches (like devel/stable/master) and > putting together a plan for testing everything, etc? Definitely time to start brainstorming, at least. --- Roy |
From: Derek G. <fri...@gm...> - 2014-01-13 16:50:49
|
On Mon, Jan 13, 2014 at 9:44 AM, Roy Stogner <roy...@ic...>wrote: > Anyone stuck in this situation should know that installing and using a > new gcc is easier than it used to be... assuming you have a gigabyte > or more to devote to it. Since that isn't always a safe assumption, > this is a pretty good argument for sticking with C++03 for a while. I agree. The problem is that many of these systems don't have any proper admin. They are "deparment clusters" where one department at the university had some extra funds and bought a few hundred cores worth of a cluster. They plugged it in and the way it is is the way it is... meaning that they don't have anyone actively working on the cluster at all. We've even gone in and set up "modules" and installed newer compilers, etc in some of these cases. But we can't be the sysadmins for the world... ;-) Definitely time to start brainstorming, at least. > Should we do a conference call to talk about this? We have some ideas about what we're going to do with the development model for MOOSE once it's open source... could be good to chat about the possibilities with libMesh. Also, if you are interested in what we currently do with MOOSE we have an open paper on that here: http://figshare.com/articles/Continuous_Integration_for_Concurrent_Computational_Framework_and_Application_Development/790755 Derek |
From: John P. <jwp...@gm...> - 2014-01-13 17:09:50
|
On Mon, Jan 13, 2014 at 9:29 AM, Roy Stogner <roy...@ic...>wrote: > > On Mon, 13 Jan 2014, Kirk, Benjamin (JSC-EG311) wrote: > > > I'd like to polish a release this week if possible. Roy'd previously > mentioned calling it 1.0, but I'd like to go with v0.9.3 because > > 1) I'm not aware of anything drastically different vs 0.9.2, but correct > me if I'm wrong; > > 2) In any case I'd like to wire brush the code and remove all the APIs > that have been deprecated for ages; > > 3) I'd like to remove the default comm_world business for 1.0. > > > > So v0.9.3 could be imminent with then 1.0 a API cleanup follow-on. > > This all sounds great. Just to be clear, we're talking 0.9.3 this > week, then 1.0-rc1 ASAP after we go through and shred deprecated > stuff? My "warnings fixes" branch might be worth merging into the > latter too. > > > But what about C++11? I could see 1.0 as a 'maintenance stream' > > where we back port important bug fixes but otherwise leave it alone. > > Gah. I can't believe *I'm* objecting (my current app development is > using C++1y features, which like C++11 features are awesome), but > AFAIK full C++11 support is *still* limited to g++ and clang++. I'm > not sure I want to deal with the hassles of trying to remember what's > in C++11 versus what's in Lowest-Common-Denominator-Compiler. > > https://wiki.apache.org/stdcxx/C%2B%2B0xCompilerSupport > > http://cpprocks.com/c11-compiler-support-shootout-visual-studio-gcc-clang-intel/ > > http://software.intel.com/en-us/articles/c0x-features-supported-by-intel-c-compiler > > I can already see a feature I'd like to use that didn't make it into > icpc 13, and three features that aren't even in icpc 14. > > I could probably be talked into us supporting the intersection of > "stuff in C++11" and "stuff in a single broken compiler, X", where X > is something I can get auto-testing in buildbot, preferably icpc 11.1, > 12.1, or 13.1. But then everyone with older pgc++ or other "not quite > C++11 compatible" compilers will be gambling. > Is there anything in C++11 that can be treated analogously to the "LIBMESH_BEST_UNORDERED_MAP" business we've got now? That's actually been pretty useful in the past. Off the top of my head, the C++11 features I'd really like to use (auto, range-based for loop syntax, lambdas) don't really lend themselves to preprocessor detection/macros like this. But what about easing in to the C++11 world with the new static_assert? We can use configure to see if the compiler supports it, and then have a libmesh_static_assert that either uses it or falls back on libmesh_assert as the case may be. At the very least, this would force us to start a c++11.m4 file of some kind to test for specific features, which I don't think we have at the moment... -- John |
From: Derek G. <fri...@gm...> - 2014-01-13 17:17:29
|
On Mon, Jan 13, 2014 at 10:09 AM, John Peterson <jwp...@gm...>wrote: > But what about easing in to the C++11 world with the new static_assert? > We can use configure to see if the compiler supports it, and then have a > libmesh_static_assert that either uses it or falls back on libmesh_assert > as the case may be. > I like this idea - I already have a use-case for a static_assert in the restart system... Derek |
From: Kirk, B. (JSC-EG311) <ben...@na...> - 2014-01-13 17:17:35
|
> On Jan 13, 2014, at 12:09 PM, "John Peterson" <jwp...@gm...> wrote: > > Off the top of my head, the C++11 features I'd really like to use (auto, range-based for loop syntax, lambdas) don't really lend themselves to preprocessor detection/macros like this. If the consensus is C++11 isn't there yet for the moose portability needs, that's fine for now... I expect we'll revisit this discussion annually until the answer changes. auto is one of the things I'd like most, I think it'll give us some more flexibility when refactoring return types, not to mention dealing with the compile-time configurable type sizes. But we can wait a little longer... |
From: Roy S. <roy...@ic...> - 2014-01-13 17:35:48
|
On Mon, 13 Jan 2014, Kirk, Benjamin (JSC-EG311) wrote: > auto is one of the things I'd like most, I think it'll give us some > more flexibility when refactoring return types, not to mention > dealing with the compile-time configurable type sizes. But we can > wait a little longer... FYI, using auto as a function return type remains a pain in the neck until C++1Y. About half of the hassle in the macros here: https://github.com/libantioch/antioch/blob/master/src/utilities/include/antioch/metaprogramming_decl.h is C++03 fallback, but the other half is the annoying C++11 trailing return type requirement. --- Roy |
From: Roy S. <roy...@ic...> - 2014-01-13 17:30:32
|
On Mon, 13 Jan 2014, John Peterson wrote: > Is there anything in C++11 that can be treated analogously to the > "LIBMESH_BEST_UNORDERED_MAP" business we've got now? That's > actually been pretty useful in the past. Very good point. LIBMESH_BEST_UNORDERED_MAP *is* a C++11 feature, isn't it? Even though we do have a bunch of fallbacks to TR1 and GNU implementations. > Off the top of my head, the C++11 features I'd really like to use > (auto, range-based for loop syntax, lambdas) don't really lend > themselves to preprocessor detection/macros like this. Nope. > But what about easing in to the C++11 world with the new > static_assert? We can use configure to see if the compiler supports > it, and then have a libmesh_static_assert that either uses it or > falls back on libmesh_assert as the case may be. Actually, it's easy to implement a limited static_assert in C++03; we'd just want to do what we did with AutoPtr so we'd get better error messages when the standard implementation is available. Hmmm... there's basically three kinds of C++11 features we can use with old compilers: Reimplementable-if-not-found features: hash tables (done!) static_assert is_foo type traits tuples (within limitations) shared_ptr unique_ptr Ignorable-via-preprocessor-if-not-found features: constexpr final override rvalue reference argument function overloads explicit keyword on conversion operators Fallback-if-not-found features: strongly typed enumerations multithreading deleted member functions > At the very least, this would force us to start a c++11.m4 file of > some kind to test for specific features, which I don't think we have > at the moment... I've got a catch-all we can use; we'll probably want to have feature-by-feature tests, though. --- Roy |
From: Jed B. <jed...@mc...> - 2014-01-14 20:20:17
|
Roy Stogner <roy...@ic...> writes: > Anyone stuck in this situation should know that installing and using a > new gcc is easier than it used to be Note that you might also have to rebuild the entire software stack due to ABI incompatibilities, e.g., http://gcc.gnu.org/wiki/Cxx11AbiCompatibility |
From: Roy S. <roy...@ic...> - 2014-01-14 20:27:39
|
On Mon, 13 Jan 2014, Jed Brown wrote: > Note that you might also have to rebuild the entire software stack due > to ABI incompatibilities, e.g., > > http://gcc.gnu.org/wiki/Cxx11AbiCompatibility Ouch! Thanks for the information! "entire software stack" in this context seems to mean "most software using STL and/or std::complex"? So e.g. PETSc would be safe, Trilinos a problem? --- Roy |
From: Jed B. <je...@je...> - 2014-01-15 04:48:40
|
[My lab email was just moved to Exchange and I don't have enough fingers to count the number of ways in which they violate RFC-2822 in the simple process of forwarding a message.] Roy Stogner <roy...@ic...> writes: > On Mon, 13 Jan 2014, Jed Brown wrote: > >> Note that you might also have to rebuild the entire software stack due >> to ABI incompatibilities, e.g., >> >> http://gcc.gnu.org/wiki/Cxx11AbiCompatibility > > Ouch! Thanks for the information! > > "entire software stack" in this context seems to mean "most software > using STL and/or std::complex"? So e.g. PETSc would be safe, Trilinos > a problem? Any C++ component that uses any of the features in the incompatibility list. Some C++ libraries don't use these features, but that's not very comforting or reliable to audit quickly so the safe thing is to rebuild every C++ package in your stack. |
From: Roy S. <roy...@ic...> - 2014-01-16 15:07:56
|
On Mon, 13 Jan 2014, Roy Stogner wrote: > Hmmm... there's basically three kinds of C++11 features we can use > with old compilers: > > Reimplementable-if-not-found features: You know, there's a subset of this that's probably important enough to be worth its own mention: Available-in-boost-if-not-found features. And IIRC we've already got a decent set of boost headers in contrib/. One thing that concerns me there, though: parts of boost can be a bit of a stress-test for compilers. "Correct C++03 compilation even with the craziest template voodoo" is a much lower hurdle than "Correct C++11 compilation", but I still don't think we're going to be able to guarantee safety for everybody using old compilers unless we've got those compilers in CI testing. And honestly, we ought to be auto-testing a few old compilers anyway regardless of whether we plan to stress them or not. Derek, any chance you could get me worst-case version numbers from your users? I'd like to get at least a "gcc-3.ancient" and "intel ancient.1" test runs added to Buildbot right away, and it would be good if my definitions of "ancient" matched with theirs. Thanks, --- Roy |
From: Kirk, B. (JSC-EG311) <ben...@na...> - 2014-01-16 15:12:20
|
I cover back to gcc-4.1.2 (centos5) and intel-11.1. I think I've got a compat-gcc from the 3x series installed I can toss into the mix, if it is important… -Ben On Jan 16, 2014, at 10:07 AM, Roy Stogner <roy...@ic...> wrote: > > And honestly, we ought to be auto-testing a few old compilers anyway > regardless of whether we plan to stress them or not. Derek, any > chance you could get me worst-case version numbers from your users? > I'd like to get at least a "gcc-3.ancient" and "intel ancient.1" test > runs added to Buildbot right away, and it would be good if my > definitions of "ancient" matched with theirs. |
From: Kirk, B. (JSC-EG311) <ben...@na...> - 2014-01-22 18:30:54
|
All, please have a look at the NEWS file and update with anything I missed. Otherwise, I am ready to tag v0.9.3. -Ben |
From: John P. <jwp...@gm...> - 2014-01-22 21:12:01
|
On Wed, Jan 22, 2014 at 11:30 AM, Kirk, Benjamin (JSC-EG311) < ben...@na...> wrote: > All, please have a look at the NEWS file and update with anything I > missed. Otherwise, I am ready to tag v0.9.3. > Looks good to me. I just pushed a patch updating the copyright notice to 2014 (we skipped 2013) if you want to tag that one instead. -- John |
From: Roy S. <roy...@ic...> - 2014-01-22 21:20:40
|
On Wed, 22 Jan 2014, Kirk, Benjamin (JSC-EG311) wrote: > All, please have a look at the NEWS file and update with anything I > missed. Otherwise, I am ready to tag v0.9.3. "Preliminary checkpoint/restart capability"? There's got to be a better way to phrase that. To read that you'd think we'd just barely managed to start implementing EquationSystems::read()/write(). Everything else I can think of I've added to NEWS. We might want to tag v0.9.3-rc1 before tagging a final 0.9.3? --- Roy |
From: Kirk, B. (JSC-EG311) <ben...@na...> - 2014-01-22 22:46:57
|
v0.9.3-rc1 is tagged, master's version is now at 1.0.0-pre and is open for business for Roy's aforementioned cleanup… Gotta run but will send an email tonight or tomorrow announcing availability. -Ben On Jan 22, 2014, at 3:20 PM, Roy Stogner <roy...@ic...> wrote: > > On Wed, 22 Jan 2014, Kirk, Benjamin (JSC-EG311) wrote: > >> All, please have a look at the NEWS file and update with anything I >> missed. Otherwise, I am ready to tag v0.9.3. > > "Preliminary checkpoint/restart capability"? There's got to be a > better way to phrase that. To read that you'd think we'd just barely > managed to start implementing EquationSystems::read()/write(). > > Everything else I can think of I've added to NEWS. > > We might want to tag v0.9.3-rc1 before tagging a final 0.9.3? > --- > Roy |
From: Kirk, B. (JSC-EG311) <ben...@na...> - 2014-01-23 16:49:31
|
On Jan 13, 2014, at 9:50 AM, "Kirk, Benjamin (JSC-EG311)" <ben...@na...> wrote: > I'd like to polish a release this week if possible. Roy'd previously mentioned calling it 1.0, but I'd like to go with v0.9.3 because > 1) I'm not aware of anything drastically different vs 0.9.2, but correct me if I'm wrong; > 2) In any case I'd like to wire brush the code and remove all the APIs that have been deprecated for ages; > 3) I'd like to remove the default comm_world business for 1.0. > > So v0.9.3 could be imminent with then 1.0 a API cleanup follow-on. Unless anyone screams, I'll be changing the default com_world to off later today. -Ben |