Menu
▾
▴
Re: [Pfunit-support] gfortran-4.7.x support
|
From: Tom C. <Tho...@na...> - 2014-01-31 02:47:23
|
Hello Ben, On Jan 30, 2014, at 2:25 PM, Benjamin Andre <ba...@lb...> wrote: > Hi Tom, > > It wasn't clear that CI was being used and one of your statements > confused me. It would be great if you can get the CI results made > public, but I understand institutional limits. Maybe just describe the > current infrastructure someplace (tested platforms and compilers) even > if the current pass/fail info isn't available? buildbot has the option > to send an email when results come in. Maybe that is another option > with your current system. Our in-house script is already sending an email. It will be a simple matter of adding you to that mailing list. I suppose I should move from an in-house list to a formal mailing list on sourceforge. Until then, please confirm whether you would like to be added to that list. I believe the current documentation does specify somewhere which systems are supported. In theory that description is 1-to-1 with our testing, but I suspect it is inaccurate with regard to the few configurations to which we don't have direct access. (Windows, IBM). > > I'm sure different developers have different preferences, but my > thoughts are on development procedures: > > For scientific reproducibility, all* software used in a computation > should be explicitly versioned (changeset hash or x.y.z version). Just > saying we used the head of some branch that was updated around some > day isn't good enough. I completely agree. But to be devils advocate, I would not expect pFUnit to be used in any scientific results. In theory, the applications that I build do not have any pFUnit in them. The tests are entirely separate. In practice, there are a few places where I test the error checking on inputs and such in the app that do result in a small amount of pfunit calls to throw(), but I surround those with #ifdef. (Most of the groups that I support don't even want to know that I'm using unit testing, and certainly don't want to have an extra dependency on my library in their builds.) > > *Obviously you have to draw the line somewhere, but I think TPL's used > by the main application are a good compromise. Completely agree. Regardless of my caveats above, we should soon have the framework in the situation that you want. In the mean time, I'm happy to tag any specific version in some ad hoc manner to give you what you need right now. > > Unit testing libraries are low level infrastructure that most people > trust to work correctly to report results. I expect most pFUnit users > (and all new users) should be using a stable release version for > production use. They then contribute to development or switch to a dev > branch when they have a feature request or bug fix. In the long run, I agree. For the present, you're actually the first user to raise this concern. Granted we're talking about single-digits for the number of real users, and those are mostly contributing extensions too. But your concerns are well timed. It is definitely time to improve our game. > > I would only use semantic versioning for "releases". Use separate > development and release branches. You can do what ever you want on the > public development branch, but when you want to "release" a new > version use semver rules. Dev's still get quick TDD/CI development. > Users get stability. OK - I think we're on the same page. The master will be in a less-than-ideal state from this perspective for the time being. Hopefully the 3.0 release will be ready within a few weeks. Cheers, - Tom > > Ben > > > On Wed, Jan 29, 2014 at 5:34 AM, Tom Clune <Tho...@na...> wrote: >> Ben, >> >> On Jan 28, 2014, at 11:29 PM, Benjamin Andre <ba...@lb...> wrote: >> >> Hi Tom, >> >> I've started a new thread to discuss my gfortran4.7 patch on the pfunit-dev >> list. >> >> Just a couple of follow up comments: >> >> * Asking users to install compilers is a major hassle, especially on >> institutional clusters running an older OS. Requiring the latest dev version >> of a compiler not only requires user to install the compiler but also >> rebuild all their third party libraries. For a low level library like >> pFUnit, supporting the widest reasonable range of compilers may be the best >> approach to building a user community. >> >> >> I understand, but it is also the case that the design of pFUnit (2.x) is >> predicated upon use of F2003 OO capabilities. Earlier compilers were >> incomplete/buggy. When I encounter issues, I generally try to find a >> workaround that will still allow older compilers to work, but in the case of >> gfortran it was a very serious bug that for which none of the experts I >> consulted could suggest a robust workaround. (Small changes could make the >> problem go away, but it would come back with a change as simple as >> commenting out a PRIVATE statement in a derived type. >> >> My compromise was to create a branch that still at least worked (with the >> latent bug possibly to be exposed by any further changes on that branch). I >> believe that getting 4.7 to work on that branch will be relatively easy, and >> will even do it for you if need be. Unfortunately I've got a packed >> schedule of visitors this week and just won't have time until the weekend. >> >> Even more critical, but not likely to happen soon would be a PGI port. >> There are so many compiler issues that are encountered that do not have >> obvious workarounds that I've made relatively little progress. But multiple >> users would really like that port. sigh. >> >> >> * We've found continuous integration systems like buildbot >> <http://buildbot.net/> to be critical to supporting multiple >> builds/compliers/platforms with minimal pain. It takes a bit of an initial >> investment, but is worth it. Just like testing :-). >> >> >> Er, we use continuous integration. For the most part, we are using >> something built in house. Been trying to move to Hudson/Jenkins but NASA >> IT security has defeated some aspects (e.g. making the results more >> visible). I certainly am in discussions with users that have access to a >> wider variety of compilers (e.g. Cray and IBM) so that we can include those >> as well. >> >> One of the nice things about GIT is that we can actually do multi-phase >> continuous integration. E.g. I have hudson running on my laptop checking 3 >> vendors with each commit. Then when I push, our cluster pulls an update >> and runs against multiple _versions_ of those same compilers. (Separate >> set for the 2.1 branch than for the master.) >> >> Then, this weekend I switched to having an integration branch for the main >> integration. This should decrease the frequency at which the master branch >> itself is temporarily broken from a push. (Had not been an issue for most >> of pFUnit history, but the introduction of CMake caused some instability for >> a bit.) >> >> I'll look again at buildbot in the hopes that it would make it easier to >> incorporate tests by external users on IBM/Cray etc. >> >> >> * "Semantic Versioning <http://semver.org/>" might be helpful in keeping >> track of your releases. >> >> >> Yes - I've been sloppy here, and would like to improve going forward. >> Physicist playing SE. >> >> Questions/comments on semantic versioning: I'm not certain I understand >> the value of the "patch" attribute in the context of continuous integration >> and agressive use of TDD. Users should be able to get the head of >> development and experience no issues. All bugs that have appeared on the >> master branch have had a lifetime usually measured in minutes or hours. (A >> couple made it over a weekend, but the integration branch mentioned above >> should eliminate even that situation.) >> >> Technically I could argue I have followed semantic versioning for the >> major/minor attributes. 2.1.0 was backward compatible. Mostly it was >> drawing a line in the sand pointing out that new work would break that >> backward compatibility. My read of the document you cited would imply >> that virtually every push I make would force an increment to the minor >> attribute. Seems at odds with the lightweight process that has been >> working until now though. I've been using numbers only when they will >> matter to the user. >> >> So, if I understand the desire correctly, the master branch should now be >> considered to be 3.0 beta. I'm a bit reluctant to call the push I'll be >> making sometime this week "3.0" because (a) the changes are actually not all >> that substantial although certainly not backward compatible (at the request >> of the users!) and (b) they are preliminary which means that I expect >> further minor changes to the interface in short order. I.e. I can be >> convinced to call it 3.0, but do I really then need to have 4.0 the >> following week just to tweak those interfaces after the users play with >> them? Should I expect users to checkout a branch instead even though I'm >> using continuous integration? I'm certainly interested in being educated >> in best practices here. >> >> Cheers, >> >> - Tom >> >> >> >> >> Ben >> >> >> On Jan 24, 2014, at 5:48 AM, Tom Clune <Tho...@na...> wrote: >> >> Hello Ben, >> >> It should certainly be feasible to patch this for you - esp. if you are >> willing to do the leg work. Note that the development branch does not even >> support 4.8.x any more due to a terrible (as in hard to pin down) bug >> uncovered over the holidays. Eventually 4.8.3 should be supported by the >> development when it comes out, and in the mean time we are forced to use the >> unreleased 4.9.0. >> >> If you do want to do this, I suggest you start with the pfunit_2.1.0 branch, >> or else you will find yourself encountering the bug I described above. >> We'll put the patch as tag pfunit_2.1.1. (I should not have but the final >> ".0" in the branch name. Not a real SE ...) >> >> You should note though, that the downside is that I'm about to introduce a >> major change in the pFUnitParser that significantly simplifies tests that >> involve user-defined subclasses of TestCase. By using the 2.1.0 branch you >> will miss out on that and may need to modify your tests when you eventually >> upgrade. Generally this will involve deleting unnecessary things, but with >> a large number of tests it can be a bit tedious. >> >> Also, not sure it is relevant here or not, but we have found that the tar >> release of GCC 4.8.1 had the same exact problem you are reporting, but that >> the build from SVN for 4.8.1 did not. So it is possible that you could >> rebuild 4.7.x from SVN and have a similar fix. Not sure it is worth the >> effort to discover the answer though. >> >> Cheers, >> >> - Tom >> >> >> >> On Jan 24, 2014, at 1:35 AM, Benjamin Andre <ba...@lb...> wrote: >> >> I've been working on bringing pFUnit into our project but hit a snag. We >> still support gfortran 4.7.x (and will probably continue as long as it is >> the "oldest maintained release" of gcc, http://gcc.gnu.org/). I've run into >> the "Deferred-length character component" bug: >> >> SurrogateTestCase.F90:54.57: >> >> class (SurrogateTestCase), intent(inout) :: this >> 1 >> Error: Deferred-length character component 'getname' at (1) is not yet >> supported >> >> mentioned on the pfunit-support mailing list: >> >> https://sourceforge.net/p/pfunit/mailman/message/31184942/ >> >> Only supporting unit testing on gfortran-4.8 is possible but suboptimal. Is >> supporting gfortran-4.7.x in the pfunit-2.1 branch feasible? I'm willing to >> work on it and submit patches, but I don't want to start down a never ending >> path of kludges to get it to work. >> >> Thanks, >> >> 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 >> _______________________________________________ >> Pfunit-support mailing list >> Pfu...@li... >> https://lists.sourceforge.net/lists/listinfo/pfunit-support >> >> >> Thomas Clune, Ph. D. <Tho...@na...> >> Chief, Software Systems Support Office Code 610.3 >> NASA GSFC 301-286-4635 >> MS 610.8 B33-C128 <http://ssso.gsfc.nasa.gov> >> Greenbelt, MD 20771 >> >> >> >> >> >> >> >> Thomas Clune, Ph. D. <Tho...@na...> >> Chief, Software Systems Support Office Code 610.3 >> NASA GSFC 301-286-4635 >> MS 610.8 B33-C128 <http://ssso.gsfc.nasa.gov> >> Greenbelt, MD 20771 >> >> >> >> Thomas Clune, Ph. D. <Tho...@na...> Chief, Software Systems Support Office Code 610.3 NASA GSFC 301-286-4635 MS 610.8 B33-C128 <http://ssso.gsfc.nasa.gov> Greenbelt, MD 20771 |