Menu
▾
▴
pfunit-developers — For anyone developing pFUnit
You can subscribe to this list here.
| 2014 |
Jan
(7) |
Feb
(3) |
Mar
(2) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2016 |
Jan
(2) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Tom C. <Tho...@na...> - 2016-01-04 15:04:51
|
Hello Pål, You are most welcome, and thank you for the contribution. I probably cannot look at this until the weekend, but I suspect your changes will be most appreciated. I’ve been using CMake+pFUnit in a number of projects in the last year. Happy New Year, - Tom > On Jan 4, 2016, at 9:47 AM, Pål Levold <Pal...@ma...> wrote: > > Dear all pFUnit developers, > > Thank you for making pFUnit publicly available! Over the past year we have been using pFUnit to write tests for development in our Fortran code base here at MARINTEK and the experience has been very good. This has enabled us to do changes to old Fortran code that otherwise had not been possible. > > We've made some changes to the pFUnit code which we'd be happy to contribute back into pFUnit if you're interested? We're pushing our changes to a public repository located here: https://bitbucket.org/marintek/pfunit/src/?at=marintek > > The changes are mainly made in order to integrate unit tests into our CMake build system in an easy way. I can go into further details if you're interested. > > > Best regards, > Pål Levold > Master of Science - Mooring and Positioning > > MARINTEK (Norsk Marinteknisk Forskningsinstitutt AS) > Address: POB 4125 Valentinlyst, NO-7450 Trondheim, Norway > Mobile: +47 99 03 68 78 > Web: www.marintek.sintef.no > > > ------------------------------------------------------------------------------ > _______________________________________________ > Pfunit-developers mailing list > Pfu...@li... > https://lists.sourceforge.net/lists/listinfo/pfunit-developers Thomas Clune, Ph. D. <Tho...@na...> Software Infrastructure Team Lead Global Modeling and Assimilation Office, Code 610.1 NASA GSFC MS 610.1 B33-C128 Greenbelt, MD 20771 301-286-4635 |
|
From: Pål L. <Pal...@ma...> - 2016-01-04 14:47:42
|
Dear all pFUnit developers, Thank you for making pFUnit publicly available! Over the past year we have been using pFUnit to write tests for development in our Fortran code base here at MARINTEK and the experience has been very good. This has enabled us to do changes to old Fortran code that otherwise had not been possible. We've made some changes to the pFUnit code which we'd be happy to contribute back into pFUnit if you're interested? We're pushing our changes to a public repository located here: https://bitbucket.org/marintek/pfunit/src/?at=marintek The changes are mainly made in order to integrate unit tests into our CMake build system in an easy way. I can go into further details if you're interested. Best regards, Pål Levold Master of Science - Mooring and Positioning MARINTEK (Norsk Marinteknisk Forskningsinstitutt AS) Address: POB 4125 Valentinlyst, NO-7450 Trondheim, Norway Mobile: +47 99 03 68 78 Web: www.marintek.sintef.no |
|
From: Tom C. <Tho...@na...> - 2014-03-03 20:51:18
|
Ben, Thanks for the update. I would have thought that the Mock files were part of 2.1 and would thus be causing you problems regardless of my 3.0 changes. Either way, since they provide no useful functionality at this time, I'm happy to add an ifdef to the CMake/Make to skip those files (and their tests) for gfortran 4.7. We'll need some sort of CPP token for the bundling layers that USE these modules as well. For the internal compiler error, I'm not surprised. pFUnit appears to put a fair bit of stress on the OO features of the various compilers. As a result I spent considerable time upgrading to the latest compiler from each vendor and getting things to go a bit further. As you've pointed out, I'll have to be much more conservative as we go forward so as not to lose the user base that I've now accumulated. My thinking at the time was that unit-testing would be most useful to people doing new things and thus would be able to use the latest compilers. One thing you might try, but I have no idea if it will work. That is to compile the tests with a more recent gfortran, but your application with 4.7.3. If the two versions are binary compatible, you might get the best of both worlds at the cost of a bit of complexity in your build environment. Let me know if you would like us to add a deactivation switch for the Mock modules. Cheers, - Tom On Mar 3, 2014, at 3:27 PM, Benjamin Andre <ba...@lb...> wrote: > Hi Tom, > > I started working on porting the release-3.0 branch to gfortran 4.7.3, > but ran into a couple of problems that seemed like they would be > nontrivial to work around. Before I got to the issue with returning > TestResult form TestRunner, I ran into an internal compiler error in > TestCase that did not seem like the problem you described. There is > also a problem in MockCall where unlimited polymorphism is not > implemented in gfortran 4.7.3. > > I decided to bring the prototype based on pfunit 2.1 into our system > and get people writing tests then decide if we want to try patching to > the 3.0 release or just wait until we stop supporting gfortran 4.7. If > someone else is interest in gfortran 4.7 support I'd be happy to point > them to a branch and split the work with them. > > Ben > > > > > > On Fri, Feb 28, 2014 at 6:24 AM, Tom Clune <Tho...@na...> wrote: >> Hello Ben, >> >> I'm just checking in to see if you've attempted this port yet and could use >> any assistance? >> >> Cheers, >> >> - Tom >> >> >> >> On Feb 6, 2014, at 9:00 PM, Tom Clune <Tho...@na...> wrote: >> >> Hi Ben, >> >> Hope you don't mind that I'm moving this back to the pfunit-developers list. >> >> On Feb 6, 2014, at 7:38 PM, Benjamin Andre <ba...@lb...> wrote: >> >> Hi Tom, >> >> After some prototyping and discussion we've decided to move forward with >> using pFUnit in PFLOTRAN (subsurface flow and reactive transport that scales >> from laptops to HPC). Supporting gfortran 4.7.3 is going to be a requirement >> for a while. Do you think the pFUnit community is interested in maintaing >> that support with us (accepting patches)? I'm trying to plan out a strategy >> forward, pfunit-2.1 vs 3.0, how much work to put into compiler kludges, etc. >> >> >> Quite likely the difficulty in putting in the gfortran patch into 4.7 is >> easy. The guy that found the fix was able to apply it in the dev and 4.8 >> branch with little difficulty. (Finding the problem was the hard part.) >> However, my understanding of the policy is that there will never be another >> 4.7.x. There will be a 4.8.3 that has the patch, but not even another >> 4.8.2, even though that would be trivial to create. >> I should also add that I'm not 100% certain there are not other shortcomings >> with the 4.7.x releases, though most probably will have simple #ifdef >> kludges that could be included. >> >> I can certainly point you to the changes in pfunit 3.0 that trigger the >> problem in 4.8, but ... What those changes revealed is that the code was >> epsilon close to triggering the bug all along. Otherwise I would simply >> have backed off that one rather minor change. The desire was to have the >> code return a non-zero status as a unix process when any of the tests >> failed. Right now, the provided driver returns a status of 0 regardless of >> how many tests failed. Only really matters when you want to embed the >> execution of the tests within higher level scripts for regression testing, >> but surely I'm not the only one that wants to do that? >> >> Even if we pull out that one relatively minor improvement, there is no >> guarantee that other changes since then have not also triggered the bug. >> They called it a "heisenbug", and it certainly was. My guess is that the >> probability of such a bad outcome is rather low given that pfunit was >> working fine for ~ 1 year in more-or-less the same state. But you should at >> least be aware of that risk. >> >> To undo the critical feature: >> >> In the TestRunner classes, the run() method was previously a subroutine. >> It is now a function that returns an internally generated TestResult object. >> You should change it back, and just have the TestResult object be a local >> variable in the concrete implementations. You'll see when you get in there >> that this will be nontrivial to ifdef. But to maintain on a separate >> branch ought to be simple. Some work is continuing with RobustRunner, but >> any conflicts won't involve the external interface and should be easily >> resolved. >> ./tests/selfTests.F90 and ./include/driver.F90 should be modified to treat >> the above run() method as a subroutine instead of as a function. the >> variable "success" should just be set to true. (The report still indicates >> when tests have failed. The only impact is the "success" return value for >> the unix process.) >> >> >> That should be it. I guess in the parlance of branch management this >> qualifies as a "hot fix" branch. Though that name implies that the changes >> will get merged back into the main development. If you can get it >> working, I'll put it into a hotfix-3.0-gfortran-4.7 branch and activate >> regression tests with gfortran 4.7.3 under linux for it. I'll then >> endeavor to push changes to 3.0 into that branch as well. >> >> Is there any obvious time when your project can move on to gfortran 4.8.3, >> presuming that it becomes available in the near future? It would be nice to >> freeze that version if/when we look at releasing 3.1. >> >> Cheers, >> >> - Tom >> >> >> >> >> >> >> >> >> Thanks for all the work you've put into pFUnit and making it framework >> available, >> >> Ben >> >> >> 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 |
|
From: Benjamin A. <ba...@lb...> - 2014-03-03 20:27:52
|
Hi Tom, I started working on porting the release-3.0 branch to gfortran 4.7.3, but ran into a couple of problems that seemed like they would be nontrivial to work around. Before I got to the issue with returning TestResult form TestRunner, I ran into an internal compiler error in TestCase that did not seem like the problem you described. There is also a problem in MockCall where unlimited polymorphism is not implemented in gfortran 4.7.3. I decided to bring the prototype based on pfunit 2.1 into our system and get people writing tests then decide if we want to try patching to the 3.0 release or just wait until we stop supporting gfortran 4.7. If someone else is interest in gfortran 4.7 support I'd be happy to point them to a branch and split the work with them. Ben On Fri, Feb 28, 2014 at 6:24 AM, Tom Clune <Tho...@na...> wrote: > Hello Ben, > > I'm just checking in to see if you've attempted this port yet and could use > any assistance? > > Cheers, > > - Tom > > > > On Feb 6, 2014, at 9:00 PM, Tom Clune <Tho...@na...> wrote: > > Hi Ben, > > Hope you don't mind that I'm moving this back to the pfunit-developers list. > > On Feb 6, 2014, at 7:38 PM, Benjamin Andre <ba...@lb...> wrote: > > Hi Tom, > > After some prototyping and discussion we've decided to move forward with > using pFUnit in PFLOTRAN (subsurface flow and reactive transport that scales > from laptops to HPC). Supporting gfortran 4.7.3 is going to be a requirement > for a while. Do you think the pFUnit community is interested in maintaing > that support with us (accepting patches)? I'm trying to plan out a strategy > forward, pfunit-2.1 vs 3.0, how much work to put into compiler kludges, etc. > > > Quite likely the difficulty in putting in the gfortran patch into 4.7 is > easy. The guy that found the fix was able to apply it in the dev and 4.8 > branch with little difficulty. (Finding the problem was the hard part.) > However, my understanding of the policy is that there will never be another > 4.7.x. There will be a 4.8.3 that has the patch, but not even another > 4.8.2, even though that would be trivial to create. > I should also add that I'm not 100% certain there are not other shortcomings > with the 4.7.x releases, though most probably will have simple #ifdef > kludges that could be included. > > I can certainly point you to the changes in pfunit 3.0 that trigger the > problem in 4.8, but ... What those changes revealed is that the code was > epsilon close to triggering the bug all along. Otherwise I would simply > have backed off that one rather minor change. The desire was to have the > code return a non-zero status as a unix process when any of the tests > failed. Right now, the provided driver returns a status of 0 regardless of > how many tests failed. Only really matters when you want to embed the > execution of the tests within higher level scripts for regression testing, > but surely I'm not the only one that wants to do that? > > Even if we pull out that one relatively minor improvement, there is no > guarantee that other changes since then have not also triggered the bug. > They called it a "heisenbug", and it certainly was. My guess is that the > probability of such a bad outcome is rather low given that pfunit was > working fine for ~ 1 year in more-or-less the same state. But you should at > least be aware of that risk. > > To undo the critical feature: > > In the TestRunner classes, the run() method was previously a subroutine. > It is now a function that returns an internally generated TestResult object. > You should change it back, and just have the TestResult object be a local > variable in the concrete implementations. You'll see when you get in there > that this will be nontrivial to ifdef. But to maintain on a separate > branch ought to be simple. Some work is continuing with RobustRunner, but > any conflicts won't involve the external interface and should be easily > resolved. > ./tests/selfTests.F90 and ./include/driver.F90 should be modified to treat > the above run() method as a subroutine instead of as a function. the > variable "success" should just be set to true. (The report still indicates > when tests have failed. The only impact is the "success" return value for > the unix process.) > > > That should be it. I guess in the parlance of branch management this > qualifies as a "hot fix" branch. Though that name implies that the changes > will get merged back into the main development. If you can get it > working, I'll put it into a hotfix-3.0-gfortran-4.7 branch and activate > regression tests with gfortran 4.7.3 under linux for it. I'll then > endeavor to push changes to 3.0 into that branch as well. > > Is there any obvious time when your project can move on to gfortran 4.8.3, > presuming that it becomes available in the near future? It would be nice to > freeze that version if/when we look at releasing 3.1. > > Cheers, > > - Tom > > > > > > > > > Thanks for all the work you've put into pFUnit and making it framework > available, > > Ben > > > 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 > > > > > |
|
From: Tom C. <Tho...@na...> - 2014-02-28 14:24:29
|
Hello Ben, I'm just checking in to see if you've attempted this port yet and could use any assistance? Cheers, - Tom On Feb 6, 2014, at 9:00 PM, Tom Clune <Tho...@na...> wrote: > Hi Ben, > > Hope you don't mind that I'm moving this back to the pfunit-developers list. > > On Feb 6, 2014, at 7:38 PM, Benjamin Andre <ba...@lb...> wrote: > >> Hi Tom, >> >> After some prototyping and discussion we've decided to move forward with using pFUnit in PFLOTRAN (subsurface flow and reactive transport that scales from laptops to HPC). Supporting gfortran 4.7.3 is going to be a requirement for a while. Do you think the pFUnit community is interested in maintaing that support with us (accepting patches)? I'm trying to plan out a strategy forward, pfunit-2.1 vs 3.0, how much work to put into compiler kludges, etc. > > Quite likely the difficulty in putting in the gfortran patch into 4.7 is easy. The guy that found the fix was able to apply it in the dev and 4.8 branch with little difficulty. (Finding the problem was the hard part.) However, my understanding of the policy is that there will never be another 4.7.x. There will be a 4.8.3 that has the patch, but not even another 4.8.2, even though that would be trivial to create. > I should also add that I'm not 100% certain there are not other shortcomings with the 4.7.x releases, though most probably will have simple #ifdef kludges that could be included. > > I can certainly point you to the changes in pfunit 3.0 that trigger the problem in 4.8, but … What those changes revealed is that the code was epsilon close to triggering the bug all along. Otherwise I would simply have backed off that one rather minor change. The desire was to have the code return a non-zero status as a unix process when any of the tests failed. Right now, the provided driver returns a status of 0 regardless of how many tests failed. Only really matters when you want to embed the execution of the tests within higher level scripts for regression testing, but surely I'm not the only one that wants to do that? > > Even if we pull out that one relatively minor improvement, there is no guarantee that other changes since then have not also triggered the bug. They called it a "heisenbug", and it certainly was. My guess is that the probability of such a bad outcome is rather low given that pfunit was working fine for ~ 1 year in more-or-less the same state. But you should at least be aware of that risk. > > To undo the critical feature: > > In the TestRunner classes, the run() method was previously a subroutine. It is now a function that returns an internally generated TestResult object. You should change it back, and just have the TestResult object be a local variable in the concrete implementations. You'll see when you get in there that this will be nontrivial to ifdef. But to maintain on a separate branch ought to be simple. Some work is continuing with RobustRunner, but any conflicts won't involve the external interface and should be easily resolved. > ./tests/selfTests.F90 and ./include/driver.F90 should be modified to treat the above run() method as a subroutine instead of as a function. the variable "success" should just be set to true. (The report still indicates when tests have failed. The only impact is the "success" return value for the unix process.) > > That should be it. I guess in the parlance of branch management this qualifies as a "hot fix" branch. Though that name implies that the changes will get merged back into the main development. If you can get it working, I'll put it into a hotfix-3.0-gfortran-4.7 branch and activate regression tests with gfortran 4.7.3 under linux for it. I'll then endeavor to push changes to 3.0 into that branch as well. > > Is there any obvious time when your project can move on to gfortran 4.8.3, presuming that it becomes available in the near future? It would be nice to freeze that version if/when we look at releasing 3.1. > > Cheers, > > - Tom > > > > > > > >> >> Thanks for all the work you've put into pFUnit and making it framework available, >> >> Ben > > 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 |
|
From: Tom C. <Tho...@na...> - 2014-02-07 02:00:22
|
Hi Ben, Hope you don't mind that I'm moving this back to the pfunit-developers list. On Feb 6, 2014, at 7:38 PM, Benjamin Andre <ba...@lb...> wrote: > Hi Tom, > > After some prototyping and discussion we've decided to move forward with using pFUnit in PFLOTRAN (subsurface flow and reactive transport that scales from laptops to HPC). Supporting gfortran 4.7.3 is going to be a requirement for a while. Do you think the pFUnit community is interested in maintaing that support with us (accepting patches)? I'm trying to plan out a strategy forward, pfunit-2.1 vs 3.0, how much work to put into compiler kludges, etc. Quite likely the difficulty in putting in the gfortran patch into 4.7 is easy. The guy that found the fix was able to apply it in the dev and 4.8 branch with little difficulty. (Finding the problem was the hard part.) However, my understanding of the policy is that there will never be another 4.7.x. There will be a 4.8.3 that has the patch, but not even another 4.8.2, even though that would be trivial to create. I should also add that I'm not 100% certain there are not other shortcomings with the 4.7.x releases, though most probably will have simple #ifdef kludges that could be included. I can certainly point you to the changes in pfunit 3.0 that trigger the problem in 4.8, but … What those changes revealed is that the code was epsilon close to triggering the bug all along. Otherwise I would simply have backed off that one rather minor change. The desire was to have the code return a non-zero status as a unix process when any of the tests failed. Right now, the provided driver returns a status of 0 regardless of how many tests failed. Only really matters when you want to embed the execution of the tests within higher level scripts for regression testing, but surely I'm not the only one that wants to do that? Even if we pull out that one relatively minor improvement, there is no guarantee that other changes since then have not also triggered the bug. They called it a "heisenbug", and it certainly was. My guess is that the probability of such a bad outcome is rather low given that pfunit was working fine for ~ 1 year in more-or-less the same state. But you should at least be aware of that risk. To undo the critical feature: In the TestRunner classes, the run() method was previously a subroutine. It is now a function that returns an internally generated TestResult object. You should change it back, and just have the TestResult object be a local variable in the concrete implementations. You'll see when you get in there that this will be nontrivial to ifdef. But to maintain on a separate branch ought to be simple. Some work is continuing with RobustRunner, but any conflicts won't involve the external interface and should be easily resolved. ./tests/selfTests.F90 and ./include/driver.F90 should be modified to treat the above run() method as a subroutine instead of as a function. the variable "success" should just be set to true. (The report still indicates when tests have failed. The only impact is the "success" return value for the unix process.) That should be it. I guess in the parlance of branch management this qualifies as a "hot fix" branch. Though that name implies that the changes will get merged back into the main development. If you can get it working, I'll put it into a hotfix-3.0-gfortran-4.7 branch and activate regression tests with gfortran 4.7.3 under linux for it. I'll then endeavor to push changes to 3.0 into that branch as well. Is there any obvious time when your project can move on to gfortran 4.8.3, presuming that it becomes available in the near future? It would be nice to freeze that version if/when we look at releasing 3.1. Cheers, - Tom > > Thanks for all the work you've put into pFUnit and making it framework available, > > Ben 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 |
|
From: Tom C. <Tho...@na...> - 2014-02-03 18:37:25
|
Hello Matthew, We're going to work on integrating your changes this week. We did already run our regression suite against what you pushed. Mostly this revealed unimportant issues that should go away when we merge. However gfortran 4.9.0 on x86 failed to build. We're investigating manually, but thought I'd mention it in case you know of something unusual in your environment. Cheers, - Tom On Jan 30, 2014, at 9:06 AM, "Hambley, Matthew" <mat...@me...> wrote: > We hope to use pFUnit on IBM POWER7 machines so I have been porting > it to them. I have had some difficulty with the make files > apparently being over reliant on GNU tools but that was an easy > fix. More challenging have been some of the assumptions built in to > the Unix process handling areas of the program. > > I tried to remove Linuxisms but found the whole thing to be somewhat > fragile and liable to breakage. I believe this comes from two issues. > The first is the approach taken where the program shells out to > command line tools rather than using the Unix libraries directly. > > The other is that standard Unix libraries are designed around common > C calling conventions which do not play so well with Fortran calling > conventions. For instance it is not uncommon for these standard Unix > libraries to use a global "errno" variable to return information. > Unfortunately this variable is not always a variable. It may be a > pre-processor macro. This makes it challenging to access through > Fortran's interoperability layer. > > My solution is to introduce a layer, written in C, which adapts the > library calls to a more Fortran friendly interface. Originally this > was just going to be an adapting shim but I have ended up with > something a little thicker which also takes care of some of the > logic surrounding processes. > > You can view this work at > <https://sourceforge.net/u/matthewhambley/pfunit/ci/cshim/tree/>. > > I have this compiled and working for both serial and MPI cases on > x86 using Intel and GNU Fortrans. The XLF/AIX version is > afflicted by a race condition which means it only works sometimes. > I am still to hunt the problem down. > > Now that I better understand how processes are used by pFUnit I > am beginning to wonder if there is a better way to structure this > area of the code. I need to think more about this but I have a > suspicion it will involve running the watchdog loop in the master > process. > > -- > Matthew Hambley > Scientific Software Engineer > The Hadley Centre, The Met Office, UK > > ------------------------------------------------------------------------------ > WatchGuard Dimension instantly turns raw network data into actionable > security intelligence. It gives you real-time visual feedback on key > security issues and trends. Skip the complicated setup - simply import > a virtual appliance and go from zero to informed in seconds. > http://pubads.g.doubleclick.net/gampad/clk?id=123612991&iu=/4140/ostg.clktrk > _______________________________________________ > Pfunit-developers mailing list > Pfu...@li... > https://lists.sourceforge.net/lists/listinfo/pfunit-developers 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 |
|
From: Benjamin A. <ba...@lb...> - 2014-01-30 19:46:32
|
I support having a formal workflow/branch policy. I don't have a preference, but found this discussion interesting: http://www.mail-archive.com/fe...@li.../msg01396.html I suspect that the petsc model is more in line with your intent for the integration branch...? Ben On Wed, Jan 29, 2014 at 6:53 PM, Tom Clune <Tho...@na...> wrote: > Upon prompting by one of the hopeful users of pFUnit, I'm shifting my > somewhat adhoc approach to branching and versioning of pFUnit to a hopefully > more standard and user-friendly approach. > > Branching policy will attempt to follow the recipe provided here: > > http://nvie.com/posts/a-successful-git-branching-model > > The main point is that the master branch will be used exclusively for stable > releases. I will create a new development branch for routine development > using continuous integration. The newly created integration branch will > go away, though I would like to implement a better mechanism to test changes > more thoroughly prior to pushing to the development branch. (IT security > can make some seemingly simple things such a chore.) > > Then, with regard to numbering revisions, I will endeavor to follow the > Semantic Versioning Specification: > > http://semver.org/ > > What I've done until now is actually not too different, but my understanding > was at best blurry. Short summary is that revisions are of the form x.y.z. > z is incremented for backwards compatible bug fixes. y is incremented for > backward compatible enhancements, and x is incremented when backward > compatibility cannot be maintained. > > With that in mind, by recent 2.1.0 branch (which should have been a tag) > will be the last release before 3.0 which introduced new interfaces for the > parser. I've already pushed those changes to the integration branch and > hopefully tomorrow will create a development branch and a 3.0 release branch > so that interested users can start playing. After we've gained some > experience and believe these to be stable, I will formally release 3.0. > Saying this out loud primarily for my own benefit. > > Also, it may be useful to start thinking about a management structure - > change review board and all that. (I abhor "process", so I hope to make > whatever of this we need as lightweight as possible.) > > Questions/concerns/objections? Speak quickly. > > Cheers, > > - Tom > > > > > 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 > > > > > > > ------------------------------------------------------------------------------ > WatchGuard Dimension instantly turns raw network data into actionable > security intelligence. It gives you real-time visual feedback on key > security issues and trends. Skip the complicated setup - simply import > a virtual appliance and go from zero to informed in seconds. > http://pubads.g.doubleclick.net/gampad/clk?id=123612991&iu=/4140/ostg.clktrk > _______________________________________________ > Pfunit-developers mailing list > Pfu...@li... > https://lists.sourceforge.net/lists/listinfo/pfunit-developers > |
|
From: Tom C. <Tho...@na...> - 2014-01-30 16:13:35
|
On Jan 30, 2014, at 9:06 AM, "Hambley, Matthew" <mat...@me...> wrote: > We hope to use pFUnit on IBM POWER7 machines so I have been porting > it to them. I have had some difficulty with the make files > apparently being over reliant on GNU tools but that was an easy > fix. Matthew - probably too late now, but one might have hoped that CMake would be a preferred solution. I'm only maintaing the original build mechanism to help entice new users. (One less thing that needs to be installed.) > More challenging have been some of the assumptions built in to > the Unix process handling areas of the program. > > I tried to remove Linuxisms but found the whole thing to be somewhat > fragile and liable to breakage. I believe this comes from two issues. > The first is the approach taken where the program shells out to > command line tools rather than using the Unix libraries directly. > > The other is that standard Unix libraries are designed around common > C calling conventions which do not play so well with Fortran calling > conventions. For instance it is not uncommon for these standard Unix > libraries to use a global "errno" variable to return information. > Unfortunately this variable is not always a variable. It may be a > pre-processor macro. This makes it challenging to access through > Fortran's interoperability layer. > > My solution is to introduce a layer, written in C, which adapts the > library calls to a more Fortran friendly interface. Originally this > was just going to be an adapting shim but I have ended up with > something a little thicker which also takes care of some of the > logic surrounding processes. > > You can view this work at > <https://sourceforge.net/u/matthewhambley/pfunit/ci/cshim/tree/>. > > I have this compiled and working for both serial and MPI cases on > x86 using Intel and GNU Fortrans. The XLF/AIX version is > afflicted by a race condition which means it only works sometimes. > I am still to hunt the problem down. I've never had to investigate, but I've seen robust fail on real applications in other environments as well. I do hope to spend more time on it at some point. > > Now that I better understand how processes are used by pFUnit I > am beginning to wonder if there is a better way to structure this > area of the code. I need to think more about this but I have a > suspicion it will involve running the watchdog loop in the master > process. I look forward to seeing your solution. - Tom > > -- > Matthew Hambley > Scientific Software Engineer > The Hadley Centre, The Met Office, UK > > ------------------------------------------------------------------------------ > WatchGuard Dimension instantly turns raw network data into actionable > security intelligence. It gives you real-time visual feedback on key > security issues and trends. Skip the complicated setup - simply import > a virtual appliance and go from zero to informed in seconds. > http://pubads.g.doubleclick.net/gampad/clk?id=123612991&iu=/4140/ostg.clktrk > _______________________________________________ > Pfunit-developers mailing list > Pfu...@li... > https://lists.sourceforge.net/lists/listinfo/pfunit-developers 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 |
|
From: Hambley, M. <mat...@me...> - 2014-01-30 14:07:22
|
We hope to use pFUnit on IBM POWER7 machines so I have been porting it to them. I have had some difficulty with the make files apparently being over reliant on GNU tools but that was an easy fix. More challenging have been some of the assumptions built in to the Unix process handling areas of the program. I tried to remove Linuxisms but found the whole thing to be somewhat fragile and liable to breakage. I believe this comes from two issues. The first is the approach taken where the program shells out to command line tools rather than using the Unix libraries directly. The other is that standard Unix libraries are designed around common C calling conventions which do not play so well with Fortran calling conventions. For instance it is not uncommon for these standard Unix libraries to use a global "errno" variable to return information. Unfortunately this variable is not always a variable. It may be a pre-processor macro. This makes it challenging to access through Fortran's interoperability layer. My solution is to introduce a layer, written in C, which adapts the library calls to a more Fortran friendly interface. Originally this was just going to be an adapting shim but I have ended up with something a little thicker which also takes care of some of the logic surrounding processes. You can view this work at <https://sourceforge.net/u/matthewhambley/pfunit/ci/cshim/tree/>. I have this compiled and working for both serial and MPI cases on x86 using Intel and GNU Fortrans. The XLF/AIX version is afflicted by a race condition which means it only works sometimes. I am still to hunt the problem down. Now that I better understand how processes are used by pFUnit I am beginning to wonder if there is a better way to structure this area of the code. I need to think more about this but I have a suspicion it will involve running the watchdog loop in the master process. -- Matthew Hambley Scientific Software Engineer The Hadley Centre, The Met Office, UK |
|
From: Tom C. <Tho...@na...> - 2014-01-30 02:53:21
|
Upon prompting by one of the hopeful users of pFUnit, I'm shifting my somewhat adhoc approach to branching and versioning of pFUnit to a hopefully more standard and user-friendly approach. Branching policy will attempt to follow the recipe provided here: http://nvie.com/posts/a-successful-git-branching-model The main point is that the master branch will be used exclusively for stable releases. I will create a new development branch for routine development using continuous integration. The newly created integration branch will go away, though I would like to implement a better mechanism to test changes more thoroughly prior to pushing to the development branch. (IT security can make some seemingly simple things such a chore.) Then, with regard to numbering revisions, I will endeavor to follow the Semantic Versioning Specification: http://semver.org/ What I've done until now is actually not too different, but my understanding was at best blurry. Short summary is that revisions are of the form x.y.z. z is incremented for backwards compatible bug fixes. y is incremented for backward compatible enhancements, and x is incremented when backward compatibility cannot be maintained. With that in mind, by recent 2.1.0 branch (which should have been a tag) will be the last release before 3.0 which introduced new interfaces for the parser. I've already pushed those changes to the integration branch and hopefully tomorrow will create a development branch and a 3.0 release branch so that interested users can start playing. After we've gained some experience and believe these to be stable, I will formally release 3.0. Saying this out loud primarily for my own benefit. Also, it may be useful to start thinking about a management structure - change review board and all that. (I abhor "process", so I hope to make whatever of this we need as lightweight as possible.) Questions/concerns/objections? Speak quickly. Cheers, - Tom 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 |
|
From: Benjamin A. <ba...@lb...> - 2014-01-29 04:04:11
|
I've patched the pfunit_2.1.0 branch to compile and pass the self test suite in serial mode under gfortran 4.7. Can you look at the changes and let me know if this is something you'd be willing to accept back upstream. I'm open to refactoring the patch before submitting a pull request if you have any changes. You can see the patch or clone the repo at: http://sourceforge.net/u/bjalbl/pfunit-gfortran47/ci/a357687aaefb7ff0415774b2c6b68a148d4b2ae8/ Thanks, Ben Summary of the changes: * pFUnit_compiler_kludges.H90 - new file, contains macros needed to identify specific compiler versions and define any compiler specific macros. * numerous files: use #ifdef GFORTRAN_4_7 to work around compiler issues related to allocatable character arrays such as: "Error: Deferred-length character component 'getname' at (1) is not yet supported" * TestSuite.F90 : a problem where an associate block wasn't working correctly and returned a null pointer, causing a segfault. I ifdef'd this, but the associate block isn't actually needed and could be removed entirely. * Commented out building MockCall.F90 and MockRepository.F90 and the corresponding use/ADD statements in selfTests.F90 - They do not appear to be used anywhere outside their own self-tests and I don't know how to work around the compiler errors: gfortran-mp-4.7 -c -g -O0 -fbacktrace -fbounds-check -fcheck=mem -DSTRINGIFY_SIMPLE -I../include -DGNU -DDarwin -I${HOME}/pfunit/include -DGNU -o MockCall.o MockCall.F90 MockC polymorphism all.F90:34.14: class(*), pointer :: argument 1 Fatal Error: Unlimited at (1) not yet supported * Test Results - serial passes with gfortran 4.7 and 4.8. Those are the only compilers I have access too. $ make FC=gfortran-mp-4.7 DEBUG=YES; ./tests/tests.x GNUmakefile:226: Compilation configuration is as follows: GNUmakefile:227: UNAME: Darwin GNUmakefile:228: ARCH: i386 GNUmakefile:229: F90 vendor: GNU GNUmakefile:230: F90 command: gfortran GNUmakefile:231: F90 has cpp: YES GNUmakefile:232: USE MPI: NO GNUmakefile:233: ABI: 32 GNUmakefile:234: File extensions: GNUmakefile:235: OBJ_EXT .o GNUmakefile:236: LIB_EXT .a GNUmakefile:237: EXE_EXT .x make -C pfunit/source all make[1]: Nothing to be done for `all'. make -C pfunit/tests all make[1]: Nothing to be done for `all'. ........................................................................................................................................ Time: 0.003 seconds OK (136 tests) $ make FC=gfortran-mp-4.8 DEBUG=YES; ./tests/tests.x GNUmakefile:226: Compilation configuration is as follows: GNUmakefile:227: UNAME: Darwin GNUmakefile:228: ARCH: i386 GNUmakefile:229: F90 vendor: GNU GNUmakefile:230: F90 command: gfortran GNUmakefile:231: F90 has cpp: YES GNUmakefile:232: USE MPI: NO GNUmakefile:233: ABI: 32 GNUmakefile:234: File extensions: GNUmakefile:235: OBJ_EXT .o GNUmakefile:236: LIB_EXT .a GNUmakefile:237: EXE_EXT .x make -C pfunit/source all make[1]: Nothing to be done for `all'. make -C pfunit/tests all make[1]: Nothing to be done for `all'. ........................................................................................................................................ Time: 0.004 seconds OK (136 tests) |
|
From: Hambley, M. <mat...@me...> - 2014-01-27 10:07:19
|
Rather than overload the mailing list with honking great attachments I've created a page on the wiki to hold design documents. I've also uploaded a corrected version of my class diagram: <https://sourceforge.net/p/pfunit/wiki/Design/> -- Matthew Hambley Scientific Software Engineer The Hadley Centre, The Met Office, UK |
|
From: Hambley, M. <mat...@me...> - 2014-01-24 10:01:55
|
To inaugurate the new developers mailing list I present the UML class diagram I have been building. This is an updated version of the one I sent to Tom by privmail. I apologise for the size of the attachment. I have been using Enterprise Architect to draw the diagram but I appreciate that not everyone has access to that. So PDF it is until we can agree on a better option. EA can export XMI if that will help people. -- Matthew Hambley Scientific Software Engineer The Hadley Centre, The Met Office, UK |
