Progname from cl

[zbeekman]

Changed the default program name to be whatever the user invoked it as. I would like to change this to strip off the leading directories, and this may only work on unix-like systems… I don’t know if you’re OK with that or not.

For example, if I build a program without passing the -o flag to gfortran and then run it like ./a.out, progname will default to ./a.out. I think this is a good change since it will be a better guess of what the program name is even if it’s not explicitly set in the source code, AND, strange things won’t happen like setting the program name to ‘foo’ in the source but then compiling it named as ‘baz’. Ideally I would like the default to remove any path specification as well… a.out instead of ./a.out etc. but I don’t have time to do this now, and am not sure how to treat windows…

Also fixed a small issue with optional disable_hv argument. As it was it’s presence would cause the behavior to be set as disable_hv=.true. even if the user passed disable_hv=.false.

[zbeekman]

strange… the documentation travis job failed… I think it needs to be setup so that PRs don’t try to update the documentation… PRs don’t have access to the same secure data since I could just write a PR that sends me your credentials if I wanted to…

[szaghi]

PRs don’t have access to the same secure data since I could just write a PR that sends me your credentials if I wanted to…

What do you mean?

[zbeekman]

What do you mean?

Travis-ci sets up a different environment for pull requests. When a PR is tested there is no access to encrypted/private data. See here for a discussion of why this is needed from a security perspective. Because of this, the documentation deployment job will always fail when testing a PR since the PR doesn’t have access to your github credentials.

You should test for PRs before trying to deploy documentation or do anything requiring sensitive data. I can submit a PR for the .travis.yml file to do this for you, if you like.

[szaghi]

You should test for PRs before trying to deploy documentation or do anything requiring sensitive data. I can submit a PR for the .travis.yml file to do this for you, if you like.

I like, you are great, but do not wast your time if you have more important things to do.

[zbeekman]

Hi Stefano please don't merge this PR yet. I've taken a look at your Travis CI setup and think I may be able to make some improvements, however my last commit will break your Travis setup and I need to fix it. I should be able to fix this and simplify/improve the CI setup for FLAP tomorrow morning. For example, I don't think it makes sense to run a separate Travis job to deploy the documentation; documentation should only be deployed if the tests succeed. Furthermore, building FLAP, the documentation, and running the tests is pretty quick; waiting in the queue (twice!) usually takes much longer. By eliminating the second job the results should return faster.

[szaghi]

Hi @zbeekman , thank you very much for your help. Today I am not at office (this is the birthday of Rome), thus I cannot see your improvements.

See you tomorrow.

[zbeekman]

No rush at all, enjoy your holiday! :tada:

[szaghi]

@zbeekman

What happen to your default progname change? I merged the small docs simplification but the default value of progname is still program. Do you have come back to the original?

[zbeekman]

@szaghi hmmm, are you sure? Did you pull down the latest changes to your local repository? The code that handles the logic is here and looks like it got merged into the master branch. It’s possible that on some systems get_command_argument(0,…,status=stat) will fail and return with a non-zero stat. In those cases, I revert back to using 'program' as the default. Maybe I should print a warning when that happens too?

[zbeekman]

I also tested on the intel compilers in the event that you were using that instead of gfortran (I’ve only tested with 5.1) and there are bigger issues with the intel compiler: #44

[szaghi]

@zbeekman ok, maybe I have done some mistakes during my local merging after the remote merge. Tomorrow I will fix my local repo.

I have an off topic (not so much) question. How do you update your local repo with respect a remote one in the case you have modified both with different changes? For example let us consider this case: at some time both local and remote repo are sinked; then I make a commit locally and in the meanwile the remote merges a PR. How can I pull remote updates preserving the local ones? Today, I have cloned the remote after the PR mergjng and then I do a manual diff... that is evidently the worst error prone approach...but I am a POOF-MAN (poor fortran man) :-)

[zbeekman]

The short answer is that most of the time I much prefer to rebase rather than merge. Rebasing helps to linearize the history, BUT you must be VERY careful that you don't re-write history that you've shared with others. To help with this, I rarely work directly with the master branch once a code is established; instead I create "feature" branches. This is a nice habit to get into, whether merging or rebasing. I hack away on those feature branches. If a small bug fix or PR needs to be made on the master branch, I'll merge the PR into master, then pull the changes to the master branch to the local repository's master branch. Then, if I haven't pushed my feature branch to a remote repository, or even if I have but I am sure no one else is using that branch, I'll rebase my feature branch onto the master branch, if it applies cleanly. (If it doesn't apply cleanly then sometimes I'll try to interactively rebase each commit onto the master branch.) If I am pushing the branch to a remote repo, then, to update it after the rebase, you'll need to add --force to git push. (Please make sure you push to the correct remote branch and that no one else is using your feature branch.) I can make an example walk through later if you want.

[szaghi]

@zbeekman thank you very much! If you can post an example it is very appreciated. You are right, using a testing branch is a good habit (that I used only for medium-size project like OFF, but not for small like FLAP... and I am wrong!).

Thanks!