From 44b54386c0ed251528f36f5e84d5583d1a4c256d Mon Sep 17 00:00:00 2001 From: milancurcic Date: Mon, 30 Nov 2020 20:31:33 -0500 Subject: [PATCH 01/15] add December 2020 newsletter draft --- ...-12-01-Fortran-Newsletter-December-2020.md | 146 ++++++++++++++++++ 1 file changed, 146 insertions(+) create mode 100644 _posts/2020-12-01-Fortran-Newsletter-December-2020.md diff --git a/_posts/2020-12-01-Fortran-Newsletter-December-2020.md b/_posts/2020-12-01-Fortran-Newsletter-December-2020.md new file mode 100644 index 000000000..a711ae310 --- /dev/null +++ b/_posts/2020-12-01-Fortran-Newsletter-December-2020.md @@ -0,0 +1,146 @@ +--- +layout: post +title: "Fortran newsletter: December 2020" +category: newsletter +author: Milan Curcic +--- + +Welcome to the December 2020 edition of the monthly Fortran newsletter. +The newsletter comes out at the beginning of every month and details +Fortran news from the previous month. + + + +## fortran-lang.org + +This month we've had a few updates to the website: + +* [#156](https://github.com/fortran-lang/fortran-lang.org/pull/156): +Updates to the mini-book on building Fortran programs, including the addition of +short guides on meson and CMake. +You can read the mini-book [here](https://fortran-lang.org/learn/building_programs). +* [#169](https://github.com/fortran-lang/fortran-lang.org/pull/169): +Add PSBLAS to the package index. + +Ongoing work: + +* [#160](https://github.com/fortran-lang/fortran-lang.org/pull/160) (WIP): +In-depth introduction for Fortran with Make. + +[Let us know](https://github.com/fortran-lang/fortran-lang.org/issues) if you have any suggestions for the website and its content. +We welcome any new contributors to the website and the tutorials page in particular - see the [contributor guide](https://github.com/fortran-lang/fortran-lang.org/blob/master/CONTRIBUTING.md) for how to get started. + +## Fortran Standard Library + +Here's what's new in stdlib: + +* [#239](https://github.com/fortran-lang/stdlib/pull/239): Implementation of bitsets in `stdlib_bitsets`. +* [#243](https://github.com/fortran-lang/stdlib/pull/243), + [#245](https://github.com/fortran-lang/stdlib/pull/245), + [#252](https://github.com/fortran-lang/stdlib/pull/253), + [#255](https://github.com/fortran-lang/stdlib/pull/255): Various improvements to `stdlib_logger`. +* [#245](https://github.com/fortran-lang/stdlib/pull/245), + [#250](https://github.com/fortran-lang/stdlib/pull/250): Minor fixes to the CI. + +Work in progress: + +* (WIP) [#240](https://github.com/fortran-lang/stdlib/pull/240): Implementation of the `stdlib_stats_distribution` module. It provides probability distribution and statistical functions. +* (WIP) [#189](https://github.com/fortran-lang/stdlib/pull/189): Initial implementation of sparse matrices. + +Don't hesitate to test and review these pull requests! + +Otherwise, ongoing discussions continue: +* [#220](https://github.com/fortran-lang/stdlib/issues/220): API for file system operations: directory manipulation +* [#241](https://github.com/fortran-lang/stdlib/issues/241): Include a `split` function (202X feature) + +The candidate for file system operations to be included in stdlib is being developed by +[@MarDiehl](https://github.com/MarDiehl) and [@arjenmarkus](https://github.com/arjenmarkus) +in [this repository](https://github.com/MarDiehl/stdlib_os). +Please try it out and let us know how it works, if there are any issues, or if the API can be improved. + +## Fortran Package Manager + +Here's what's new in fpm: + +* [#259](https://github.com/fortran-lang/fpm/pull/259): Update the instructions for building from source in README.md. +* [#246](https://github.com/fortran-lang/fpm/pull/246): Automated binary releases in CI. +* [#233](https://github.com/fortran-lang/fpm/pull/233): Allow linking with external libraries. +* [#224](https://github.com/fortran-lang/fpm/pull/224): Add a reference document for the package manifest (fpm.toml). +* [#221](https://github.com/fortran-lang/fpm/pull/221), + [#239](https://github.com/fortran-lang/fpm/pull/239): Runner options for test and app executables. +* [#220](https://github.com/fortran-lang/fpm/pull/220): Implement compiler and flags settings in Haskell fpm. +* [#209](https://github.com/fortran-lang/fpm/pull/209): + [#237](https://github.com/fortran-lang/fpm/pull/237): Developer API docs. +* [#216](https://github.com/fortran-lang/fpm/pull/216), + [#225](https://github.com/fortran-lang/fpm/pull/225), + [#226](https://github.com/fortran-lang/fpm/pull/226), + [#229](https://github.com/fortran-lang/fpm/pull/229), + [#236](https://github.com/fortran-lang/fpm/pull/236), + [#240](https://github.com/fortran-lang/fpm/pull/240), + [#247](https://github.com/fortran-lang/fpm/pull/240), Other fixes and improvements. + +Work in progress: + +* [First beta release](https://github.com/fortran-lang/fpm/milestone/1) (WIP): First feature-complete release of the Fortran implementation. +* (WIP) [#230](https://github.com/fortran-lang/fpm/pull/230), + [#261](https://github.com/fortran-lang/fpm/pull/261): Specification of the fpm CLI. +* (WIP) [#232](https://github.com/fortran-lang/fpm/pull/232): Allowing the `extra` section in fpm.toml. +* (WIP) [#248](https://github.com/fortran-lang/fpm/pull/248): Refactor backend for incremental rebuilds. +* (WIP) [#251](https://github.com/fortran-lang/fpm/pull/251): Dependency management. +* (WIP) [#255](https://github.com/fortran-lang/fpm/pull/255): Setting the compiler and specifying test or app target. +* (WIP) [#257](https://github.com/fortran-lang/fpm/pull/257): Implement `fpm install`. +* (WIP) [#260](https://github.com/fortran-lang/fpm/pull/260): Fix CI to test release build. + +fpm is still in early development and we need as much help as we can get. +Here's how you can help today: + +* Use it and let us know what you think! Read the [fpm packaging guide](https://github.com/fortran-lang/fpm/blob/master/PACKAGING.md) to learn how to build your package with fpm, and the [manifest reference](https://github.com/fortran-lang/fpm/blob/master/manifest-reference.md) to learn what are all the things that you can specify in the fpm.toml file. +* Browse the [open issues](https://github.com/fortran-lang/fpm/issues) and see if you can help implement any fixes or features. +* Adapt your Fortran package for fpm and submit it to the [Registry](https://github.com/fortran-lang/fpm-registry). +* Improve the documentation. + +The short-term goal of fpm is to make development and installation of Fortran packages with dependencies easier. +Its long term goal is to build a rich and decentralized ecosystem of Fortran packages and create a healthy +environment in which new open source Fortran projects are created and published with ease. + +## Compilers + +### Classic Flang + +TODO @gklimowicz + +### LLVM Flang + +TODO @gklimowicz + +### LFortran + +What's new in LFortran: + +TODO @certik + +You can follow LFortran on Twitter for latest updates: [@lfortranorg](https://twitter.com/lfortranorg). + +## Events + +* We had our 6th Fortran Monthly call on November 17. +You can watch the recording below: + + + +As usual, subscribe to the [mailing list](https://groups.io/g/fortran-lang) and/or +join the [Discourse](https://fortran-lang.discourse.group) to stay tuned with the future meetings. + +## Contributors + +We thank everybody who contributed to fortran-lang in the past month by +commenting in any of these repositories: + +* [fortran-lang/stdlib](https://github.com/fortran-lang/stdlib) +* [fortran-lang/fpm](https://github.com/fortran-lang/fpm) +* [fortran-lang/fpm-registry](https://github.com/fortran-lang/fpm-registry) +* [fortran-lang/fortran-lang.org](https://github.com/fortran-lang/fortran-lang.org) +* [fortran-lang/benchmarks](https://github.com/fortran-lang/benchmarks) +* [j3-fortran/fortran_proposals](https://github.com/j3-fortran/fortran_proposals) + +
From fc3e50913d4c048677eaed43ff500dba7826f2e8 Mon Sep 17 00:00:00 2001 From: milancurcic Date: Mon, 30 Nov 2020 20:39:20 -0500 Subject: [PATCH 02/15] add news about new J3 chair --- _posts/2020-12-01-Fortran-Newsletter-December-2020.md | 2 ++ 1 file changed, 2 insertions(+) diff --git a/_posts/2020-12-01-Fortran-Newsletter-December-2020.md b/_posts/2020-12-01-Fortran-Newsletter-December-2020.md index a711ae310..3ebbede39 100644 --- a/_posts/2020-12-01-Fortran-Newsletter-December-2020.md +++ b/_posts/2020-12-01-Fortran-Newsletter-December-2020.md @@ -123,6 +123,8 @@ You can follow LFortran on Twitter for latest updates: [@lfortranorg](https://tw ## Events +* Brian Friesen (Lawrence Berkeley National Laboratory) was selected to be the new Chair of PL22.3 (J3, US Standards Committee). +Brian will serve in his first term until November 2023. Congratulations, Brian! * We had our 6th Fortran Monthly call on November 17. You can watch the recording below: From 5282fb10a54c8687434501e21fcf438c578d057b Mon Sep 17 00:00:00 2001 From: milancurcic Date: Mon, 30 Nov 2020 20:44:27 -0500 Subject: [PATCH 03/15] fix punctuation --- _posts/2020-12-01-Fortran-Newsletter-December-2020.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/_posts/2020-12-01-Fortran-Newsletter-December-2020.md b/_posts/2020-12-01-Fortran-Newsletter-December-2020.md index 3ebbede39..f93f146ef 100644 --- a/_posts/2020-12-01-Fortran-Newsletter-December-2020.md +++ b/_posts/2020-12-01-Fortran-Newsletter-December-2020.md @@ -77,7 +77,7 @@ Here's what's new in fpm: [#229](https://github.com/fortran-lang/fpm/pull/229), [#236](https://github.com/fortran-lang/fpm/pull/236), [#240](https://github.com/fortran-lang/fpm/pull/240), - [#247](https://github.com/fortran-lang/fpm/pull/240), Other fixes and improvements. + [#247](https://github.com/fortran-lang/fpm/pull/240): Other fixes and improvements. Work in progress: From 8ee7130aa380828f9e96390fa5d979dd47f22834 Mon Sep 17 00:00:00 2001 From: Milan Curcic Date: Tue, 1 Dec 2020 07:46:21 -0500 Subject: [PATCH 04/15] Update _posts/2020-12-01-Fortran-Newsletter-December-2020.md Co-authored-by: Jeremie Vandenplas --- _posts/2020-12-01-Fortran-Newsletter-December-2020.md | 1 + 1 file changed, 1 insertion(+) diff --git a/_posts/2020-12-01-Fortran-Newsletter-December-2020.md b/_posts/2020-12-01-Fortran-Newsletter-December-2020.md index f93f146ef..810e1873b 100644 --- a/_posts/2020-12-01-Fortran-Newsletter-December-2020.md +++ b/_posts/2020-12-01-Fortran-Newsletter-December-2020.md @@ -52,6 +52,7 @@ Don't hesitate to test and review these pull requests! Otherwise, ongoing discussions continue: * [#220](https://github.com/fortran-lang/stdlib/issues/220): API for file system operations: directory manipulation * [#241](https://github.com/fortran-lang/stdlib/issues/241): Include a `split` function (202X feature) +[#254](https://github.com/fortran-lang/stdlib/issues/254): Proposition to add a logger for debug phases and levels among the different logs. The candidate for file system operations to be included in stdlib is being developed by [@MarDiehl](https://github.com/MarDiehl) and [@arjenmarkus](https://github.com/arjenmarkus) From bb561db76e29e37417b975b4c18957f60d97b6ee Mon Sep 17 00:00:00 2001 From: Laurence Kedward Date: Tue, 1 Dec 2020 14:26:52 +0000 Subject: [PATCH 05/15] Update: github contributor data for newletter. --- .../data-fortran-lang-fortran-lang.org.json | 236 ++- .../data-fortran-lang-fpm.json | 1364 ++++++++++++++++- .../data-fortran-lang-stdlib.json | 675 +++++++- .../data-j3-fortran-fortran_proposals.json | 118 +- 4 files changed, 2381 insertions(+), 12 deletions(-) diff --git a/community/github_stats_data/data-fortran-lang-fortran-lang.org.json b/community/github_stats_data/data-fortran-lang-fortran-lang.org.json index fd0700ac7..035492dd5 100644 --- a/community/github_stats_data/data-fortran-lang-fortran-lang.org.json +++ b/community/github_stats_data/data-fortran-lang-fortran-lang.org.json @@ -1,17 +1,234 @@ { "name": "fortran-lang/fortran-lang.org", "issues": [ + { + "number": 172, + "user": "milancurcic", + "date": "2020-12-01 01:41:36+00:00", + "title": "December 2020 newsletter draft", + "text": "Sorry for the late start on this.\nI populated the PR updates for each project. Please review and edit if needed. I will specifically need help from:\n\n@gklimowicz (Classic and LLVM Flang updates)\n@certik (LFortran updates)\n@LKedward (contributors data update)\n\nAs usual, please add your name to the authors list if you add, edit, or review content.", + "comments": [] + }, + { + "number": 171, + "user": "milancurcic", + "date": "2020-12-01 00:54:57+00:00", + "title": "Add Sebastian to the list of authors in the building-programs mini-book", + "text": "I have merged #156 but only later realized that we didn't add @awvwgk to the list of authors. I did so in this PR. @awvwgk are you okay with this?", + "comments": [] + }, + { + "number": 170, + "user": "ivan-pi", + "date": "2020-11-17 16:45:11+00:00", + "title": "Fix PSBLAS github address mistake", + "text": "Fixes the typo I made.", + "comments": [ + { + "user": "ivan-pi", + "date": "2020-11-17 16:47:19+00:00", + "text": "Since @certik and @LKedward already reviewed the package is suitable and this is only a tiny correction, I will go ahead and merge." + } + ] + }, + { + "number": 169, + "user": "ivan-pi", + "date": "2020-11-17 16:17:58+00:00", + "title": "Add PSBLAS to package index", + "text": "Adds https://github.com/sfilippone/psblas3\nThis is an established library for sparse matrix linear algebra operations. It is described in several publications.\nPerhaps it will be necessary to update the license manually.", + "comments": [ + { + "user": "ivan-pi", + "date": "2020-11-17 16:39:07+00:00", + "text": "Ooops, I mistyped the github name.\nIt should read \"sfilippone/psblas3\"." + } + ] + }, + { + "number": 168, + "user": "milancurcic", + "date": "2020-11-06 15:35:30+00:00", + "title": "Newsletter on the October 2020 J3 meeting", + "text": "There is a thread with a summary from the meeting here.\nLike we did with the February meeting newsletter, it would be useful to make and distribute a post about the progress made in the October meeting.\nIt looks like the GitHub issue thread could be largely adapted into a post. However, it would be helpful and nice to also have a brief discussion on the progress and future outlook, i.e. how did this meeting steer the course toward F202X.\nThe motivation for this is to leverage the fortran-lang reach and audience and promote the Committee's work.\nWhat do you think? @certik @zjibben @sblionel @longb @rouson @gklimowicz @everythingfunctional @FortranFan @tclune @mleair", + "comments": [ + { + "user": "certik", + "date": "2020-11-06 16:54:42+00:00", + "text": "I obviously agree, that is what I have been pushing all along and why Zach and I took our time to write things up.\n\nHowever, I would appreciate more help from the WG5 and J3 leadership. In my opinion it should be the leadership driving this effort (especially the part about future outlook and how the meeting steers towards F202X), and I can of course help, but it shouldn't be me driving this, as I am not in the committee leadership." + }, + { + "user": "sblionel", + "date": "2020-11-06 19:33:48+00:00", + "text": "I'll be glad to do a writeup - probably for my blog as that's where I've written about standards progress before. Let me review the summary thread for ideas." + }, + { + "user": "milancurcic", + "date": "2020-11-06 22:40:43+00:00", + "text": "Thank you @sblionel. Would you agree to co-author your write-up with @certik and @zjibben who already wrote a useful summary, and cross-post the article on both fortran-lang.org and your website?\nI understand if you prefer to write your own thing for your website. In that case, we (others) should still publish one on fortran-lang.org. I think what @certik and @zjibben wrote is a great start. I could help summarize the discussion that followed in that thread." + }, + { + "user": "FortranFan", + "date": "2020-11-07 12:49:17+00:00", + "text": "@milancurcic wrote Nov. 6, 2020, 10:35 AM EST:\n\nThere is a thread with a summary from the meeting here.\nLike we did with the February meeting newsletter, it would be useful to make and distribute a post about the progress made in the October meeting.\nIt looks like the GitHub issue thread could be largely adapted into a post. However, it would be helpful and nice to also have a brief discussion on the progress and future outlook, i.e. how did this meeting steer the course toward F202X.\nThe motivation for this is to leverage the fortran-lang reach and audience and promote the Committee's work.\nWhat do you think? @certik @zjibben @sblionel @longb @rouson @gklimowicz @everythingfunctional @FortranFan @tclune @mleair\n\nAs you all will know, J3 also puts out the meeting minutes which may be useful to reference in the newsletter: https://j3-fortran.org/doc/year/20/minutes222.txt\nGreat job on the newsletter." + }, + { + "user": "sblionel", + "date": "2020-11-08 15:54:48+00:00", + "text": "@milancurcic , I think the idea of separate posts would work better. I can write mine from the WG5 perspective, and others can write one from the user perspective. We should cross-link the posts." + } + ] + }, + { + "number": 167, + "user": "milancurcic", + "date": "2020-11-03 23:47:15+00:00", + "title": "Revert \"Test Twitter, try 2\"", + "text": "Reverts #166", + "comments": [] + }, + { + "number": 166, + "user": "milancurcic", + "date": "2020-11-03 23:41:13+00:00", + "title": "Test Twitter, try 2", + "text": "This time I removed the secrets from the Org and added them to the repo.", + "comments": [ + { + "user": "milancurcic", + "date": "2020-11-03 23:41:36+00:00", + "text": "#tweet This is a test tweet." + }, + { + "user": "github-actions[bot]", + "date": "2020-11-03 23:41:50+00:00", + "text": "[tweet] the following message will be tweeted in @fortranlang after this PR is merged (character count: 21/280):\n\nThis is a test tweet." + }, + { + "user": "milancurcic", + "date": "2020-11-03 23:45:49+00:00", + "text": "@p-costa Same error persists. I will let you figure it out. I will give you permissions to the repo so you can set up the keys. Unfortunately, Twitter doesn't allow team management of the developer account (to get the secrets), but only for reading and posting tweets. I will contact you by email about getting access to the Twitter account." + } + ] + }, + { + "number": 165, + "user": "milancurcic", + "date": "2020-11-03 21:59:33+00:00", + "title": "Revert \"Test Twitter CI\"", + "text": "Reverts #164", + "comments": [] + }, + { + "number": 164, + "user": "milancurcic", + "date": "2020-11-03 21:50:04+00:00", + "title": "Test Twitter CI", + "text": "", + "comments": [ + { + "user": "milancurcic", + "date": "2020-11-03 21:52:58+00:00", + "text": "#tweet This is a test tweet." + }, + { + "user": "github-actions[bot]", + "date": "2020-11-03 21:53:14+00:00", + "text": "[tweet] the following message will be tweeted in @fortranlang after this PR is merged (character count: 21/280):\n\nThis is a test tweet." + }, + { + "user": "milancurcic", + "date": "2020-11-03 22:06:10+00:00", + "text": "@p-costa I double-checked the names of the secrets (look okay to me), and I updated their values. I also double-checked that we have r+w access for the app in the Twitter account. We still get the same error.\nThis confuses me though:\n\nWhat is consumer-key? Is that a different name for one of the secrets or something different?\nDo you see if these are incorrect in any way?\n\nAnd here are the permissions.\n\nWhat do you think?" + }, + { + "user": "milancurcic", + "date": "2020-11-03 22:08:27+00:00", + "text": "I just looked in ethomson/send-tweet-action. Here's the snippet from their README:\nname: Send a Tweet\non: [push]\njobs:\n tweet:\n runs-on: ubuntu-latest\n steps:\n - uses: ethomson/send-tweet-action@v1\n with:\n status: \"Hi, this is a test!\"\n consumer-key: ${{ secrets.TWITTER_CONSUMER_API_KEY }}\n consumer-secret: ${{ secrets.TWITTER_CONSUMER_API_SECRET }}\n access-token: ${{ secrets.TWITTER_ACCESS_TOKEN }}\n access-token-secret: ${{ secrets.TWITTER_ACCESS_TOKEN_SECRET }}\n\nNote the secrets names here. They are different from what twitter-together instructs.\nShould we rename TWITTER_API_KEY to TWITTER_CONSUMER_API_KEY and TWITTER_API_SECRET to TWITTER_CONSUMER_API_SECRET?" + }, + { + "user": "p-costa", + "date": "2020-11-03 22:31:57+00:00", + "text": "Hi Milan,\nIt is no problem that they are different as long as the names in our CI are consistent with those in the github settings:\n status: ${{steps.extract-tweet.outputs.body}}\n consumer-key: ${{secrets.TWITTER_API_KEY}}\n consumer-secret: ${{secrets.TWITTER_API_SECRET_KEY}}\n access-token: ${{secrets.TWITTER_ACCESS_TOKEN}}\n access-token-secret: ${{secrets.TWITTER_ACCESS_TOKEN_SECRET}}\n\nI tested it on my own twitter account. (what matters is they are passed correctly to send-tweet-action). So it all looks good to me... Can it be that the keys are swapped? I can dig further into this sometime tomorrow." + }, + { + "user": "p-costa", + "date": "2020-11-03 22:35:54+00:00", + "text": "Perhaps trying the classical solution removing those secrets and adding them again? It seems that the secrets are not passing correctly to the CI. We get an error from the first secret the CI tries to fetch from the repo. (also generating new keys on the twitter app)" + }, + { + "user": "milancurcic", + "date": "2020-11-03 23:33:30+00:00", + "text": "It's possible that the keys are incorrect but I find it unlikely considering I did it twice. The error message \"consumer-key is required input\" just doesn't make it sound like the key is incorrect, but missing altogether. It's possible that the org secrets are not correctly propagated to the repo secrets, even though they say they are. I will try this next." + } + ] + }, { "number": 163, "user": "milancurcic", "date": "2020-10-31 15:49:01+00:00", - "title": "draft in progress for the November newsletter", + "title": "November newsletter", "text": "I populated the website updates summary.\nHere's what remains:\n\n stdlib updates; @jvdp1 can you tackle this one?\n fpm updates; @awvwgk or @everythingfunctional can you tackle this one?\n update URL of the monthly call video @ivan-pi\n flang updates @gklimowicz\n LFortran updates @certik\n Contributors data @LKedward\n\nAs usual, add your name to the authors list if you add, edit, or review content.\nConsidering that I started this draft very last minute and also that it's the weekend, don't worry about having it ready for November 1, just do it at your convenience.\nThank you all!", "comments": [ { "user": "jvdp1", "date": "2020-10-31 16:10:12+00:00", "text": "I will look at it this evening.\n\nLe sam. 31 oct. 2020 \u00e0 16:49, Milan Curcic a\n\u00e9crit :\n\u2026\n Assigned #163 <#163>\n to @jvdp1 .\n\n \u2014\n You are receiving this because you were assigned.\n Reply to this email directly, view it on GitHub\n <#163 (comment)>,\n or unsubscribe\n \n ." + }, + { + "user": "certik", + "date": "2020-11-02 19:33:16+00:00", + "text": "I am working on the LFortran part, should have it ready later in the afternoon." + }, + { + "user": "milancurcic", + "date": "2020-11-03 14:40:04+00:00", + "text": "Thank you all, I think it's in great shape.\n@LKedward and @p-costa: Do you want to give it a shot with the Tweet? Here's an example for reference: https://twitter.com/fortranlang/status/1312119558543609856" + }, + { + "user": "p-costa", + "date": "2020-11-03 14:43:28+00:00", + "text": "#tweet Fortran monthly newsletter, November 2020 edition:\nhttps://fortran-lang.org/newsletter/2020/11/01/Fortran-Newsletter-November-2020" + }, + { + "user": "github-actions[bot]", + "date": "2020-11-03 14:43:44+00:00", + "text": "[tweet withdrawn]" + }, + { + "user": "p-costa", + "date": "2020-11-03 14:44:38+00:00", + "text": "#tweet Fortran monthly newsletter, November 2020 edition: https://fortran-lang.org/newsletter/2020/11/01/Fortran-Newsletter-November-2020" + }, + { + "user": "github-actions[bot]", + "date": "2020-11-03 14:44:54+00:00", + "text": "[tweet] the following message will be tweeted in @fortranlang after this PR is merged (character count: 130/280):\n\nFortran monthly newsletter, November 2020 edition: https://fortran-lang.org/newsletter/2020/11/01/Fortran-Newsletter-November-2020" + }, + { + "user": "p-costa", + "date": "2020-11-03 14:46:51+00:00", + "text": "(character count is overestimated because of the link)" + }, + { + "user": "certik", + "date": "2020-11-03 15:36:55+00:00", + "text": "Looks great!\n\u2026\nOn Tue, Nov 3, 2020, at 7:47 AM, Pedro Costa wrote:\n\n\n (character count is overestimated because of the link)\n\n \u2014\n You are receiving this because you were assigned.\n Reply to this email directly, view it on GitHub\n <#163 (comment)>, or unsubscribe ." + }, + { + "user": "milancurcic", + "date": "2020-11-03 15:53:48+00:00", + "text": "It looks like the Tweet CI failed. I'll be able to look into it later today." + }, + { + "user": "p-costa", + "date": "2020-11-03 16:02:42+00:00", + "text": "it looks like an issue with the configuration of the access tokens.\nsome possible causes based on my previous tests when developing could be\n\na mismatch in the name of the keys under the repo secrets, which should match the following names:\n\nTWITTER_API_KEY\nTWITTER_API_SECRET_KEY\nTWITTER_ACCESS_TOKEN\nTWITTER_ACCESS_TOKEN_SECRET\n\n\nlack of writing privileges in the twitter app\nof course, some mismatch in the keys when they were copied into the repo" + }, + { + "user": "milancurcic", + "date": "2020-11-03 18:21:37+00:00", + "text": "I will double-check, update if needed, and open a test PR just for the tweet." } ] }, @@ -31,6 +248,11 @@ "user": "milancurcic", "date": "2020-10-31 15:24:46+00:00", "text": "I'm putting together a website PR summary now." + }, + { + "user": "milancurcic", + "date": "2020-11-06 15:23:55+00:00", + "text": "Fixed by #163." } ] }, @@ -158,7 +380,7 @@ "user": "awvwgk", "date": "2020-10-23 16:19:54+00:00", "title": "Update building programs book", - "text": "I think the build-tools section of the building programs minibook is a bit short and the make example contains a few common gotchas, therefore I tried to update it.\nI also started some minimal introductions to meson and CMake to explain the concept of high-level build systems in comparison to make. Since it is an introductory book I didn't went to much into details on using those, as this might be something for an intermediate or advanced guide.\nChanges:\n\nreplace hyphens by endashs\nuse correct external link declaration\nrename the example source file to functions\ncorrect name of the generate module file set to user_functions\nextend the build-tools page with a detailed guide on make\n\nexplain concept of recursively defined variables which is commonly misused in make\n\n\nadd a short guide on meson\nadd a short guide on CMake", + "text": "I think the build-tools section of the building programs minibook is a bit short and the make example contains a few common gotchas, therefore I tried to update it.\nI also started some minimal introductions to meson and CMake to explain the concept of high-level build systems in comparison to make. Since it is an introductory book I didn't went to much into details on using those, as this might be something for an intermediate or advanced guide.\nChanges:\n\nreplace hyphens by endashs emdashs\nuse correct external link declaration\nrename the example source file to functions\ncorrect name of the generate module file set to user_functions\nextend the build-tools page with a detailed guide on make\n\nexplain concept of recursively defined variables which is commonly misused in make\n\n\nadd a short guide on meson\nadd a short guide on CMake", "comments": [ { "user": "certik", @@ -219,6 +441,16 @@ "user": "certik", "date": "2020-10-24 15:08:44+00:00", "text": "Sounds good, I agree with the comments above.\n\u2026\nOn Sat, Oct 24, 2020, at 8:35 AM, Ivan wrote:\n\n\n > As someone who struggled to find adequate online material when learning `make` and other systems for Fortran (I still struggle with `cmake`), I think this is a good addition to this particular minibook. A separate minibook for fpm seems more appropriate - when ready this can then supplant this minibook as the recommended beginners' guide.\n\n I second these thoughts. The available resources on Cmake and make\n targeted at Fortran are scarce. Most of the time I resorted to just\n adapting the makefiles from existing Fortran projects, not knowing what\n exactly are they doing. Having the minibooks in one place will\n hopefully make it easier for beginners to progress from small projects\n to intermediate and large projects where a build system is needed (at\n least until fpm is mature).\n\n \u2014\n You are receiving this because you commented.\n Reply to this email directly, view it on GitHub\n <#156 (comment)>, or unsubscribe ." + }, + { + "user": "awvwgk", + "date": "2020-11-22 09:56:13+00:00", + "text": "This PR has been stale for almost a month now. Is there still interest in this?" + }, + { + "user": "milancurcic", + "date": "2020-12-01 00:45:23+00:00", + "text": "With no objections, I'll go ahead and merge this." } ] }, diff --git a/community/github_stats_data/data-fortran-lang-fpm.json b/community/github_stats_data/data-fortran-lang-fpm.json index 1a0b3d0de..5e93500ce 100644 --- a/community/github_stats_data/data-fortran-lang-fpm.json +++ b/community/github_stats_data/data-fortran-lang-fpm.json @@ -1,12 +1,1148 @@ { "name": "fortran-lang/fpm", "issues": [ + { + "number": 265, + "user": "everythingfunctional", + "date": "2020-12-01 02:39:11+00:00", + "title": "Failure to build jsonff", + "text": "I wanted to see how well the Fortran version was doing (I haven't really used it at all yet). I tried building my jsonff package and got the following error.\n + gfortran -c build/dependencies/iso_varying_string/src/ISO_VARYING_STRING.f90 -Wall -Wextra -Wimplicit-interface -fPIC -fmax-errors=1 -g -fbounds-check -fcheck-array-temporaries -fbacktrace -Jbuild/gfortran_debug/jsonff -o build/gfortran_debug/jsonff/dependencies_iso_varying_string_src_ISO_VARYING_STRING.f90.o\n + gfortran -c build/dependencies/erloff/src/Module_m.f90 -Wall -Wextra -Wimplicit-interface -fPIC -fmax-errors=1 -g -fbounds-check -fcheck-array-temporaries -fbacktrace -Jbuild/gfortran_debug/jsonff -o build/gfortran_debug/jsonff/dependencies_erloff_src_Module_m.f90.o\n + gfortran -c build/dependencies/erloff/src/Procedure_m.f90 -Wall -Wextra -Wimplicit-interface -fPIC -fmax-errors=1 -g -fbounds-check -fcheck-array-temporaries -fbacktrace -Jbuild/gfortran_debug/jsonff -o build/gfortran_debug/jsonff/dependencies_erloff_src_Procedure_m.f90.o\n + gfortran -c build/dependencies/strff/src/strff.f90 -Wall -Wextra -Wimplicit-interface -fPIC -fmax-errors=1 -g -fbounds-check -fcheck-array-temporaries -fbacktrace -Jbuild/gfortran_debug/jsonff -o build/gfortran_debug/jsonff/dependencies_strff_src_strff.f90.o\n + gfortran -c build/dependencies/erloff/src/Call_stack_entry_m.f90 -Wall -Wextra -Wimplicit-interface -fPIC -fmax-errors=1 -g -fbounds-check -fcheck-array-temporaries -fbacktrace -Jbuild/gfortran_debug/jsonff -o build/gfortran_debug/jsonff/dependencies_erloff_src_Call_stack_entry_m.f90.o\n + gfortran -c build/dependencies/erloff/src/Call_stack_m.f90 -Wall -Wextra -Wimplicit-interface -fPIC -fmax-errors=1 -g -fbounds-check -fcheck-array-temporaries -fbacktrace -Jbuild/gfortran_debug/jsonff -o build/gfortran_debug/jsonff/dependencies_erloff_src_Call_stack_m.f90.o\n + gfortran -c build/dependencies/erloff/src/Message_m.f90 -Wall -Wextra -Wimplicit-interface -fPIC -fmax-errors=1 -g -fbounds-check -fcheck-array-temporaries -fbacktrace -Jbuild/gfortran_debug/jsonff -o build/gfortran_debug/jsonff/dependencies_erloff_src_Message_m.f90.o\n + gfortran -c build/dependencies/erloff/src/Error_list_m.f90 -Wall -Wextra -Wimplicit-interface -fPIC -fmax-errors=1 -g -fbounds-check -fcheck-array-temporaries -fbacktrace -Jbuild/gfortran_debug/jsonff -o build/gfortran_debug/jsonff/dependencies_erloff_src_Error_list_m.f90.o\n + gfortran -c build/dependencies/erloff/src/Message_list_m.f90 -Wall -Wextra -Wimplicit-interface -fPIC -fmax-errors=1 -g -fbounds-check -fcheck-array-temporaries -fbacktrace -Jbuild/gfortran_debug/jsonff -o build/gfortran_debug/jsonff/dependencies_erloff_src_Message_list_m.f90.o\n + gfortran -c build/dependencies/erloff/src/erloff.f90 -Wall -Wextra -Wimplicit-interface -fPIC -fmax-errors=1 -g -fbounds-check -fcheck-array-temporaries -fbacktrace -Jbuild/gfortran_debug/jsonff -o build/gfortran_debug/jsonff/dependencies_erloff_src_erloff.f90.o\n + gfortran -c build/dependencies/parff/src/parff.f90 -Wall -Wextra -Wimplicit-interface -fPIC -fmax-errors=1 -g -fbounds-check -fcheck-array-temporaries -fbacktrace -Jbuild/gfortran_debug/jsonff -o build/gfortran_debug/jsonff/dependencies_parff_src_parff.f90.o\n + gfortran -c ./src/jsonff.f90 -Wall -Wextra -Wimplicit-interface -fPIC -fmax-errors=1 -g -fbounds-check -fcheck-array-temporaries -fbacktrace -Jbuild/gfortran_debug/jsonff -o build/gfortran_debug/jsonff/jsonff.f90.o\n./src/jsonff.f90:46:17:\n\n 46 | join, &\n | 1\nError: Symbol 'readfile' referenced at (1) not found in module 'strff'\ncompilation terminated due to -fmax-errors=1.\n Command failed\nERROR STOP \n\nError termination. Backtrace:\n#0 0x101fc4ebd\n#1 0x101fc5b75\n#2 0x101fc6f03\n#3 0x101f109f8\n#4 0x101efd552\n#5 0x101efcc32\n#6 0x101efdffd\n#7 0x101ef8ddd\n#8 0x101f92886\n\nThis error is from MacOS, but a similar one is emitted on Linux. It appears it is fetching the incorrect version of strff. It fetched version 1.0.0, but version 1.2.0 is specified in the fpm.toml. Maybe it's fetching dependencies depth first instead of breadth first?", + "comments": [ + { + "user": "LKedward", + "date": "2020-12-01 08:42:30+00:00", + "text": "Thanks for reporting, yes it's fetching depth first. Since we don't (yet) check for conflicting versions in dependencies, is breadth first the correct/preferred way of fetching?" + } + ] + }, + { + "number": 264, + "user": "everythingfunctional", + "date": "2020-12-01 02:28:47+00:00", + "title": "Failure to build vegetables", + "text": "I wanted to see how well the Fortran version was doing (I haven't really used it at all yet). I tried building my vegetables package and got the following error.\nUnable to find source for module dependency: \"parff\" used by \"app/make_driver_m.f90\"\nERROR STOP 1\n\nError termination. Backtrace:\n#0 0x105acfebd\n#1 0x105ad0b75\n#2 0x105ad1f6e\n#3 0x105a03440\n#4 0x105a9b886\n\nLooks like it just isn't fetching the dependency specified for the executable, as seen in the below fpm.toml file.\nname = \"vegetables\"\nversion = \"6.0.0\"\nlicense = \"MIT\"\nauthor = \"Brad Richardson\"\nmaintainer = \"everythingfunctional@protonmail.com\"\ncopyright = \"2020 Brad Richardson\"\n\n[dependencies]\n iso_varying_string = { git = \"https://gitlab.com/everythingfunctional/iso_varying_string.git\", tag = \"v2.0.0\" }\n strff = { git = \"https://gitlab.com/everythingfunctional/strff.git\", tag = \"v2.0.0\" }\n\n[[executable]]\n name = \"make_vegetable_driver\"\n source-dir = \"app\"\n main = \"main.f90\"\n [executable.dependencies]\n parff = { git = \"https://gitlab.com/everythingfunctional/parff.git\", tag = \"v2.0.0\" }", + "comments": [ + { + "user": "awvwgk", + "date": "2020-12-01 07:07:36+00:00", + "text": "Duplicate of #228" + } + ] + }, + { + "number": 263, + "user": "everythingfunctional", + "date": "2020-12-01 02:24:07+00:00", + "title": "Failure to build iso_varying_string", + "text": "I wanted to see how well the Fortran version was doing (I haven't really used it at all yet). I tried building my iso_varying_string package and got the following error.\n + gfortran build/gfortran_debug/test/unit_test_main.f90.o build/gfortran_debug/test/unit_test_adjustl_test.f90.o build/gfortran_debug/test/unit_test_adjustr_test.f90.o build/gfortran_debug/test/unit_test_assignment_test.f90.o build/gfortran_debug/test/unit_test_char_test.f90.o build/gfortran_debug/test/unit_test_concat_test.f90.o build/gfortran_debug/test/unit_test_equal_test.f90.o build/gfortran_debug/test/unit_test_extract_test.f90.o build/gfortran_debug/test/unit_test_greater_than_equal_test.f90.o build/gfortran_debug/test/unit_test_greater_than_test.f90.o build/gfortran_debug/test/unit_test_iachar_test.f90.o build/gfortran_debug/test/unit_test_ichar_test.f90.o build/gfortran_debug/test/unit_test_index_test.f90.o build/gfortran_debug/test/unit_test_insert_test.f90.o build/gfortran_debug/test/unit_test_len_test.f90.o build/gfortran_debug/test/unit_test_len_trim_test.f90.o build/gfortran_debug/test/unit_test_less_than_equal_test.f90.o build/gfortran_debug/test/unit_test_less_than_test.f90.o build/gfortran_debug/test/unit_test_lge_test.f90.o build/gfortran_debug/test/unit_test_lgt_test.f90.o build/gfortran_debug/test/unit_test_lle_test.f90.o build/gfortran_debug/test/unit_test_llt_test.f90.o build/gfortran_debug/test/unit_test_not_equal_test.f90.o build/gfortran_debug/test/unit_test_remove_test.f90.o build/gfortran_debug/test/unit_test_repeat_test.f90.o build/gfortran_debug/test/unit_test_replace_range_test.f90.o build/gfortran_debug/test/unit_test_replace_start_test.f90.o build/gfortran_debug/test/unit_test_replace_target_test.f90.o build/gfortran_debug/test/unit_test_scan_test.f90.o build/gfortran_debug/test/unit_test_split_character_set_test.f90.o build/gfortran_debug/test/unit_test_split_string_set_test.f90.o build/gfortran_debug/test/unit_test_trim_test.f90.o build/gfortran_debug/test/unit_test_var_str_test.f90.o build/gfortran_debug/test/unit_test_verify_test.f90.o -Wall -Wextra -Wimplicit-interface -fPIC -fmax-errors=1 -g -fbounds-check -fcheck-array-temporaries -fbacktrace -Jbuild/gfortran_debug/iso_varying_string build/gfortran_debug/iso_varying_string/libiso_varying_string.a -o build/gfortran_debug/test/unit_test\nUndefined symbols for architecture x86_64:\n \"___custom_generator_MOD___vtab_3126CD9\", referenced from:\n ___repeat_test_MOD_test_repeat in unit_test_repeat_test.f90.o\n \"___custom_generator_MOD___vtab_custom_generator_Ascii_character_generator_t\", referenced from:\n ___iachar_test_MOD_test_iachar in unit_test_iachar_test.f90.o\n ___ichar_test_MOD_test_ichar in unit_test_ichar_test.f90.o\n \"___custom_generator_MOD___vtab_custom_generator_Ascii_string_pair_generator_t\", referenced from:\n ___concat_test_MOD_test_concat in unit_test_concat_test.f90.o\n ___equal_test_MOD_test_equals in unit_test_equal_test.f90.o\n ___greater_than_equal_test_MOD_test_greater_than_equals in unit_test_greater_than_equal_test.f90.o\n ___greater_than_test_MOD_test_greater_than in unit_test_greater_than_test.f90.o\n ___index_test_MOD_test_index in unit_test_index_test.f90.o\n ___less_than_equal_test_MOD_test_less_than_equals in unit_test_less_than_equal_test.f90.o\n ___less_than_test_MOD_test_less_than in unit_test_less_than_test.f90.o\n ...\n \"___custom_generator_MOD___vtab_custom_generator_Character_input_t\", referenced from:\n ___iachar_test_MOD_check_iachar in unit_test_iachar_test.f90.o\n ___ichar_test_MOD_check_ichar in unit_test_ichar_test.f90.o\n \"___custom_generator_MOD___vtab_custom_generator_String_and_integer_input_t\", referenced from:\n ___repeat_test_MOD_check_repeat in unit_test_repeat_test.f90.o\n \"___custom_generator_MOD___vtab_custom_generator_String_pair_input_t\", referenced from:\n ___concat_test_MOD_check_concat_character_and_string in unit_test_concat_test.f90.o\n ___concat_test_MOD_check_concat_string_and_character in unit_test_concat_test.f90.o\n ___concat_test_MOD_check_concat_strings in unit_test_concat_test.f90.o\n ___equal_test_MOD_check_string_equal_character in unit_test_equal_test.f90.o\n ___equal_test_MOD_check_character_equal_string in unit_test_equal_test.f90.o\n ___equal_test_MOD_check_string_equal_string in unit_test_equal_test.f90.o\n ___greater_than_equal_test_MOD_check_string_greater_than_equal_character in unit_test_greater_than_equal_test.f90.o\n ...\nld: symbol(s) not found for architecture x86_64\ncollect2: error: ld returned 1 exit status\n Command failed\nERROR STOP \n\nError termination. Backtrace:\n#0 0x106e70ebd\n#1 0x106e71b75\n#2 0x106e72f03\n#3 0x106dbb9f8\n#4 0x106da8810\n#5 0x106da90b2\n#6 0x106da7a0f\n#7 0x106e3d894\n\nThis error is from MacOS, but a similar one is emitted on Linux. I suspect an issue with ordering of things in the link command, but I'm not sure.", + "comments": [ + { + "user": "LKedward", + "date": "2020-12-01 08:38:14+00:00", + "text": "Thanks for trying it out @everythingfunctional and reporting these. It appears there's a bug where tests and executables are only linked to non-library modules that they use directly. Non-library modules that are used via other modules are not added to the link list. Since this relates to the refactoring in #248, I will prepare a fix and tests for after that is merged." + } + ] + }, + { + "number": 262, + "user": "everythingfunctional", + "date": "2020-12-01 02:13:48+00:00", + "title": "Add -fcoarray=single to default gfortran flags", + "text": "By adding this flag to the default set, fpm can at least compile code using coarray features by default if not actually run multiple images.", + "comments": [] + }, + { + "number": 261, + "user": "awvwgk", + "date": "2020-11-30 22:18:13+00:00", + "title": "Create a specification of the fpm command line interface (pandoc)", + "text": "Create fpm(1) and the currently available six subcommand manual pages.\nTo check the resulting manual pages on the command line translate them with pandoc:\npandoc -s -t manpage fpm.1.md\nman -l fpm.1\n\n\nPandoc is written is Haskell and requires the usual set of Haskell dependencies, which you should have around anyway to compile Bootstrap fpm with stack.\n\nPlease review this PR while comparing to #230 and consider the following points\n\nsetup/usage of the toolchain\nthe markup language to express the command line documentation\nthe output (both HTML and roff/man page)\nthe preview on GH\n\nCloses #227\nCloses #230", + "comments": [] + }, + { + "number": 260, + "user": "LKedward", + "date": "2020-11-30 15:55:23+00:00", + "title": "Fix CI to test release build", + "text": "Fixes the CI so that it also tests the release build\n\nArguments to the CI scripts are passed on to fpm build, fpm run and fpm test to parameterize the test scripts\n\n\nFixes #254: workaround for compiler bug in Windows release build\n\nUpdate M_CLI2 revision to include upstream fix (urbanjost/M_CLI2#4)\n\n\n\nSee here for a successful workflow with the updated CI. (See here for the same workflow run prior to applying the Windows fixes.)\nSince this PR affects our CI checks and our release binaries, I think it should be prioritised over the several existing PRs, and I would be grateful for reviews.", + "comments": [ + { + "user": "LKedward", + "date": "2020-12-01 13:13:02+00:00", + "text": "Many thanks for the quick reviews all. I'll merge later today with a new release if there are no more comments." + } + ] + }, + { + "number": 259, + "user": "awvwgk", + "date": "2020-11-29 18:09:00+00:00", + "title": "Reorder README to focus on the Fortran fpm version", + "text": "A suggestion to reorder the README to set the focus on fpm itself.\nThe bootstrapping process is described in a collapsed details section.\nRelated #253", + "comments": [ + { + "user": "awvwgk", + "date": "2020-11-30 17:58:19+00:00", + "text": "Introducing the install.sh script significantly reduces the bootstrap instructions, I think we don't have to collapse them anymore because they also serve as reference to compile Fortran fpm with itself." + }, + { + "user": "milancurcic", + "date": "2020-12-01 01:20:53+00:00", + "text": "Thank you!" + } + ] + }, + { + "number": 258, + "user": "awvwgk", + "date": "2020-11-29 14:06:36+00:00", + "title": "Platform specific testing", + "text": "I'm kinda run into this issue when creating unit tests for the fpm-install command. We make a lot of implicit assumptions on the OS which does not allow to test both variants on the same build machine. It would be helpful for unit testing (and caching) to give all filesystem operations an optional input to set the build machine OS. Testing this kind of stuff on the CI is not great.\nAlso this allows to cache the OS identifier minimizes the calls to get_os_type.\nThe alternative would be to always abstract all OS specific testing in a separate library, but this just shifts the problem away to another project.", + "comments": [] + }, + { + "number": 257, + "user": "awvwgk", + "date": "2020-11-29 10:27:46+00:00", + "title": "Implement fpm-install command", + "text": "Noticed I require some working install command, when working on the fpm-dist command. Therefore, I coded up an installer type and implemented the fpm-install command.\n\n allow installing of executables\n optionally install library and modules if specified in manifest\n add install table to manifest reference\n use in CI to install fpm\n add unit tests for new manifest entry\n add unit tests for new installer type\n\nRelated #71\nCommand-line interface:\nNAME\n fpm-install(1) - install fpm projects\n\nSYNOPSIS\n fpm install [--release] [--no-rebuild] [--prefix DIR]\n [--bindir DIR] [--libdir DIR] [--includedir DIR]\n [--verbose]\n\nDESCRIPTION\n Subcommand to install fpm projects.\n\nOPTIONS\n --release selects the optimized build instead of the debug build\n --no-rebuild do not rebuild project before installation\n --prefix DIR path to installation directory (requires write access)\n --bindir DIR subdirectory to place executables in\n --libdir DIR subdirectory to place libraries and archives in\n --includedir DIR subdirectory to place headers and module files in\n --verbose print more information\n\nInstallation configuration:\n[install]\n# whether or not to install library + modules (default: false)\nlibrary = false", + "comments": [ + { + "user": "urbanjost", + "date": "2020-11-30 17:21:10+00:00", + "text": "In the help text I like the new word \"archies\" but I think \"archives\" is probably better (It's old meaning for the ackkk-ackkk sound of anti-aircraft gunnery is pretty much obsolete, so I think it might catch on though) :>" + }, + { + "user": "urbanjost", + "date": "2020-12-01 03:31:17+00:00", + "text": "It would be useful long-term to be able to set access permits, ownership and group but given there is not a platform-independent way to do that with pure Fortran it is problematic, although easy to do on POSIX platforms.\nDo you intend it to be able to create the specified directories if needed or must all target directories pre-exisit?" + }, + { + "user": "urbanjost", + "date": "2020-12-01 03:35:50+00:00", + "text": "Should the default be to not rebuild and a --build switch be available instead of the opposite? I think that would be a more expected behavior. Althought the risk is low I would like to install an executable I have run tests on first, typically." + }, + { + "user": "urbanjost", + "date": "2020-12-01 06:19:17+00:00", + "text": "The help_install should be added to the list of help produced when you ask for the entire manual, and the install subcommand should be added to the list of available subcommands in several places so it shows in the output for list and the list of commands in the fpm_help. So the output from fpm --list|fpm list fpm --help|fpm help and fpm help manual should mention the install command, not just help install. I like the function you added so the strings can be unallocated, but when I called sget() directly like lget() to set the types describing the command types I hit a gfortran bug when I built with optimization where I got segfaults. I have not pulled and built this yet, just looked over the code but might want to try that. That is why I set variables and passed those for the most part when I used sget() (in a few places I was actually testing the string several times and preferred to do that anyway)." + }, + { + "user": "awvwgk", + "date": "2020-12-01 07:15:57+00:00", + "text": "It would be useful long-term to be able to set access permits, ownership and group but given there is not a platform-independent way to do that with pure Fortran it is problematic, although easy to do on POSIX platforms.\n\nI haven't added file permissions yet, because I wasn't sure how to do it on non-POSIX platforms.\n\nDo you intend it to be able to create the specified directories if needed or must all target directories pre-exisit?\n\nActually, missing directories are automatically created.\n\nShould the default be to not rebuild and a --build switch be available instead of the opposite? I think that would be a more expected behavior. Althought the risk is low I would like to install an executable I have run tests on first, typically.\n\nThe CMake install behaviour is exactly this, you have to invoke a separate CMake command to actually build before installing, which I find annoying. In meson install you get automatically a rebuild if required, with an incremental rebuild like in #248 we can always rebuild without much additional cost.\nI'm mainly orienting my strategy on the meson commands because it is in fact my main build system and I think it is well thought out.\n\nThe help_install should be added to the list of help produced when you ask for the entire manual\n\nWill add it there." + } + ] + }, + { + "number": 256, + "user": "awvwgk", + "date": "2020-11-28 10:42:08+00:00", + "title": "Use git plumbing rather than git porcelain commands", + "text": "Working with the current our current git interface I noticed that we are using the porcelain (high-level) interface for git rather than its plumbing (low-level) interface. I think it is worth to switch from the porcelain to the plumbing interface, since the latter is more predictable and less verbose.\nFor example getting the root commit, with the porcelain command git log -n 1 HEAD results in\ncommit 105644ca8bce711b407e1a15f8f456693f60ff43\nMerge: 2612d9a 846d4e5\nAuthor: Laurence Kedward \nDate: Wed Nov 25 16:00:58 2020 +0000\n\n Merge pull request #246 from LKedward/release_builds\n \n CI: upload binaries when a release is published\n\nReading the commit requires to tokenize the first line of the output and the porcelain command output changes depending on the output device.\nUsing the plumbing command git show-ref HEAD --hash instead gives the hash directly:\n105644ca8bce711b407e1a15f8f456693f60ff43\n\nSince we are planning to use libgit2 (see #168) at some point where we would have access to an API of the plumbing commands rather than the porcelain ones, we should adjust this anyway to make this transition as seamless as possible. Unfortunately, the plumbing commands do not support the handy -C directory switching which will make working with them a little more complicated.\nCurrently we use the following three porcelain commands:\n\ngit init\ngit fetch\ngit checkout\n\nJust opening this issue to keep track of it. In case anyone has experience with plumbing command alternatives for the above let me know.", + "comments": [ + { + "user": "everythingfunctional", + "date": "2020-11-28 14:55:28+00:00", + "text": "Good idea. \ud83d\udc4d from me." + } + ] + }, + { + "number": 255, + "user": "urbanjost", + "date": "2020-11-27 13:35:25+00:00", + "title": "The `run`, `test`, and `build` Fortran fpm(1) command has a new switch", + "text": "added new switch called --fc that sets the Fortran compiler name.\n\nThe default compiler name to use is taken from the value of the\nenvironment variable FPM_FC.\nIf not set, the environment variable FC is used.\nIf it is not set the name gfortran is used.\nThe value specified on the command line overrides any default.\n\nFC is apparently a commonly used environment variable for the compiler,\nis short, and allows for specifying compilers for other languages like\nC (ie. -cc gcc) That is part of the reasons to use --fc instead of\n--compiler.\nSince there is a chance the currently set value of FC may be used by\nother applications being used, and to allow for a temporary change of\nthe default the fpm-specific variable FPM_FC is supported in addition\nto FC and has higher precedence.\nHowever, since the Haskell version has a similar switch called\n--compiler that name is an alias for -fc.\nA skeleton was started for standard debug and release builds that allows\nfor compilers other than gfortran. I now have access to ifort\nand nvfortran and it works with at least simple cases for those\ncompilers.\nLooking for someone with access to other compilers to help\nflesh that out.\n--target\nThe list of executables to run with the run and test subcommands\ncan now be prefixed with --target, as with the Haskell version of\nffpm(1).\nSUMMARY\nSo default usage is unchanged from the previous version. By simply setting\nFC or FPM_FC you can use it like the previous version with other compilers for\ndefault debug and release builds.\n wget http://www.urbanjost.altervista.org/REMOVE/ffpm.f90\n\n gfortran ffpm.f90 -o $HOME/.local/bin/ffpm\n\n # get a test package or use your own\n if [ ! -d M_CLI2 ]\n then\n git clone https://github.com/urbanjost/M_CLI2\n fi\n cd M_CLI2\n\n # default build using ifort\n ffpm build --fc ifort\n export FPM_FC=ifort\n ffpm run\n ffpm test", + "comments": [ + { + "user": "urbanjost", + "date": "2020-11-28 01:58:27+00:00", + "text": "After trying it for seveal days while trying to load in as many packages as I could find FC being used, I find it is used heavily, but inconsitently. CMake uses it in an interesting way where the name can be followed by compiler options that are used to set the options for a build, which might be an approach to adapt for custom builds not specified via a config file/TOML file setting. Make of course uses it, and is probably where the \"standard\" use of FC orginated. Several environment modules such as one for nvfortran use it with a full pathname to the executable. This version handles this by using the basename of the first word of FC; but since the usage is common but varies in meaning significantly I think FPM_FC is needed. If not, as in this implementation, as an override of FC then the cleanest single-option solution seems to be FPM_FC and --fc or FPM_COMPILER and --compiler. Possibly a short name for --compiler would also be desireable. Since the name --fc implies some association with the FC environment variable that is not strictly true in the first scenario, I think it comes down to the second choice. Another factor in favor of that is that --compiler is more compatible with h-fpm. So, although not my personal first choice. I think that it will be\n--compiler COMPILER_NAME\nwhere the default compiler name is taken from the environment variable FPM_COMPILER if set, else 'gfortran' is used. I still find the use of an environment variable for establishing a default useful so I do not propose dropping that. Any dissents or alternatives?" + }, + { + "user": "milancurcic", + "date": "2020-11-28 02:06:25+00:00", + "text": "the cleanest single-option solution seems to be FPM_FC and --fc or FPM_COMPILER and --compiler. Possibly a short name for --compiler would also be desireable. Since the name --fc implies some association with the FC environment variable that is not strictly true in the first scenario, I think it comes down to the second choice. Another factor in favor of that is that --compiler is more compatible with h-fpm. So, although not my personal first choice. I think that it will be\n--compiler COMPILER_NAME\nwhere the default compiler name is taken from the environment variable FPM_COMPILER if set, else 'gfortran' is used.\n\nHaving thought some more and read your message, I agree and now prefer FPM_COMPILER for the env var and --compiler for the flag." + }, + { + "user": "awvwgk", + "date": "2020-11-28 09:33:47+00:00", + "text": "CMake uses it in an interesting way where the name can be followed by compiler options that are used to set the options for a build\n\nCMake also supports reading compile flags from FFLAGS.\n\nSeveral environment modules such as one for nvfortran use it with a full pathname to the executable\n\nIn case of conda-build the FC variable is usually set to something like $BUILD_PREFIX/bin/aarch64-conda-linux-gnu-gfortran, which is still gfortran, but has a lot of additional information in the variable name.\n\nhis version handles this by using the basename of the first word of FC; but since the usage is common but varies in meaning significantly I think FPM_FC is needed\n\nUsing the basename of the compiler found in FC could result in using the wrong compiler. Imagine having two versions of gfortran in your path and you select the latter by giving its explicit path. In this case the basename would be gfortran and the compiler found first in the path would be used instead. Most build systems support both absolute paths to the binary and a name that can be found in the PATH variable." + }, + { + "user": "everythingfunctional", + "date": "2020-11-28 14:46:13+00:00", + "text": "I agree with @milancurcic that they should be FPM_COMPILER and --compiler." + }, + { + "user": "urbanjost", + "date": "2020-11-30 00:52:12+00:00", + "text": "PS: Working on a test of the help subcommand but really haven't thought of a satisfying way to say it is good other than size, line count, and a check for a few words. Used the COUNT() intrinsic to count letter frequency which was intereresting but I decided to drop it (but \"fpm help manual\" produced the expected result with ETA being the three most common letters). Any thoughts on a Fortran-only test of the help output? I am trying to avoid using external system commands." + } + ] + }, + { + "number": 254, + "user": "LKedward", + "date": "2020-11-27 11:41:09+00:00", + "title": "Command line bug on Windows", + "text": "Running fpm --version (or fpm --help) on Windows using the latest release build (fpm-v0.1.0-windows-x86_64.exe) produces the following error:\nUNKNOWN LONG KEYWORD: --version\nKEYWORD SHORT PRESENT VALUE\n F [F]\n\nNo such error occurs on Linux. I believe this regression was introduced in #239 where the M_CLI2 revision was updatded.\n@urbanjost, are you able to look into this?", + "comments": [ + { + "user": "LKedward", + "date": "2020-11-27 12:11:55+00:00", + "text": "Okay I've tracked it down to the use of compiler optimisation.\nThe following will work and print help information: fpm run --flag -O0 -- --help, however any non-zero level of optimisation (-O1,-O2,-O3) will fail with the above error message.\n@urbanjost, it looks like the command line interface is possibly relying on some undefined behaviour which is causing issues when compiled with optimisation flags on Windows.\nedit: Tested on Windows 10 with mingw-w64-gcc 8.1.0 where fpm is being bootstrapped with the latest Haskell fpm implementation.\n\nWe should add tests on the release version in our CI." + }, + { + "user": "urbanjost", + "date": "2020-11-27 13:49:05+00:00", + "text": "Have not been able to reproduce it on Red Hat, so will need to install mingw on a MSWindows machine. Hopefully that will be straight\nforward." + }, + { + "user": "urbanjost", + "date": "2020-11-28 20:22:09+00:00", + "text": "Installed three versions of minogw and also tried in Cygwin, and Cygwin with mingw added and just running the M_CLI2 tests themselves independent of ffpm (on ifort, nvfortran, and gfortran)\nand I cannot reproduce the problem just building the fortran part. I will try to set up the machine to have the Haskell setup instead of directly compiling the fortran parts. It did not sound like the problem would require that to duplicate but I have been unable to duplicate it so far." + }, + { + "user": "LKedward", + "date": "2020-11-28 22:59:21+00:00", + "text": "Have you tried the mingw-w64 8.1.0 build available here on plain Windows (same as used in our CI). I'm able to reproduce on a separate Windows machine with this mingw-w64 version using the latest master branch built from scratch.\nc:\\>gcc --version\ngcc (x86_64-win32-seh-rev0, Built by MinGW-W64 project) 8.1.0\n\nAfter building from scratch (delete output folder), with bootstrap fpm I get:\nc:\\msys64\\home\\laure\\git\\fpm3\\fpm>fpm run --release -- --version\nUNKNOWN LONG KEYWORD: --version\nKEYWORD SHORT PRESENT VALUE\n F [F]\n\nAs per my previous comment this appears to be a problem that only occurs with compiler optimization flags hence '--release'." + }, + { + "user": "LKedward", + "date": "2020-11-29 11:56:32+00:00", + "text": "@urbanjost, I believe I've tracked it down to the split(3f) function used both in M_CLI2 and in the fpm_strings module. There appears to be a compiler bug with mingw-w64-gcc 8.1.0 whereby the case (:high) syntax for the select case clause is not correctly implemented.\nI find replacing 'case (:0)' with 'case (0)' fixes the issue:\ndiff --git a/src/M_CLI2.f90 b/src/M_CLI2.f90\nindex 7f95e31..d022a52 100644\n--- a/src/M_CLI2.f90\n+++ b/src/M_CLI2.f90\n@@ -3071,7 +3071,7 @@ integer :: imax ! length of longest toke\n !-----------------------------------------------------------------------------------------------------------------------------------\n select case (ilen)\n !-----------------------------------------------------------------------------------------------------------------------------------\n- case (:0) ! command was totally blank\n+ case (0) ! command was totally blank\n !-----------------------------------------------------------------------------------------------------------------------------------\n case default" + }, + { + "user": "LKedward", + "date": "2020-11-29 12:29:25+00:00", + "text": "I've created a PR at urbanjost/M_CLI2#4. If you are happy with it, after merging I will open a subsequent PR in this repo with an update revision for M_CLI2 and the same fix applied in the fpm_strings module." + }, + { + "user": "urbanjost", + "date": "2020-11-30 01:50:15+00:00", + "text": "Thanks. Had not had time to look at this further till now. Looks like you have a general solution. Looking at it now." + } + ] + }, + { + "number": 253, + "user": "milancurcic", + "date": "2020-11-26 17:48:33+00:00", + "title": "Phase out fpm-bootstrap", + "text": "With #246 merged (great work @LKedward!) a user that arrives to fortran-lang/fpm can easily:\n\nDownload and run a binary for their platform\nDownload and run the same binary to bootstrap fpm from source\n\nfpm thus does not anymore need the Haskell fpm for bootstrapping. However, the README.md still asks the user to install Haskell for building from source. The correct instructions should now be to first download the appropriate fpm binary and then run fpm build in the fpm repo directory.\nI think we should at this point start to de-emphasize the Haskell implementation in this repo as much as possible. It served its purpose superbly (thank you @everythingfunctional!), but it now can confuse newcomers to the project, which is not helpful at best and harmful at worst (I've seen it more than a few times now). With the ever-shorter attention spans, first impressions matter more than ever.\nI propose the following steps to phase out fpm-bootstrap:\n\nUpdate README.md to not require Haskell for building from source.\nMove the fpm project (contents of https://github.com/fortran-lang/fpm/tree/master/fpm) to the top-level.\nMove contents of https://github.com/fortran-lang/fpm/tree/master/bootstrap to a separate repo. I suggest either fpm-haskell or fpm-hs instead of fpm-bootstrap, because using the word \"bootstrap\" here is now misleading. Ditto with the contents of the archive directory (early Rust prototype), though this one I think we should just remove to not confuse anybody. The code will exist in the git history anyway.\n\nOf course, the Haskell fpm should live on if people want to develop or use it.\nWhat do you think?", + "comments": [ + { + "user": "LKedward", + "date": "2020-11-26 17:58:41+00:00", + "text": "I agree; simplifying the process for developers should hopefully increase engagement with the project. I realised during #246 that the Haskell version now needs to move to a separate repo now that we are explicitly versioning the Fortran implementation.\nThere is still the issue of bootstrapping on non x86_64 platforms, but I don't know how common these are for development.\nPresumably we can also delete the 'archive' folder which isn't necessary on git?" + }, + { + "user": "awvwgk", + "date": "2020-11-26 18:00:39+00:00", + "text": "Sounds like a good plan. Splitting projects on GitHub works usually seamlessly. If we want to preserve the git history we can just clone this repository and push it to the new repo and prune the repositories afterwards. Issues relevant for Haskell fpm can be easily moved within repositories of an organisation from my experience, so nothing gets lost in this transition." + }, + { + "user": "awvwgk", + "date": "2020-11-26 18:05:05+00:00", + "text": "There is still the issue of bootstrapping on non x86_64 platforms, but I don't know how common these are for development.\n\nI have some experience compiling and packaging for PowerPC and ARM on conda-forge. For now we don't have to worry, we can either bootstrap a version on PowerPC, ARM, ... later with the Haskell version (if stack is available there and we find a CI provider, drone offers ARM, Travis-CI offers PowerPC and ARM) or just cross-compile using our native x86_64 binary (for OSX ARM which nobody offers on CI yet)." + }, + { + "user": "everythingfunctional", + "date": "2020-11-26 18:11:41+00:00", + "text": "From the time we decided to (re)implement in Fortran, that had basically always been the plan. If we've reached that point (which it seems we have), then I'm in favor of it.\nI will echo @LKedward's concern about other architectures, but my understanding is that bootstrapping for new architectures is usually done via cross-compiler tool chains anyways. So if the Fortran version has sufficient support to allow cross-compiling (or it will be completed very soon), then this isn't really a big issue.\nI intend to continue using the Haskell version as a platform for experimentation. If the fortran-lang project does not wish to continue hosting it, I will be happy to keep it going under my personal account. In either case, I hope it becomes less and less necessary over time.\nI must say, the amount of support and community contributions this project has received over the last 9 months (I can't believe we only started this project 9 months ago!) has been quite exciting and far exceeded even my wildest expectations. I owe a great deal of gratitude to everyone who has contributed." + }, + { + "user": "certik", + "date": "2020-11-27 17:47:40+00:00", + "text": "Thank you Brad, Laurence, Milan, Sebastian and others! Indeed, we are doing really well, I am very happy with the progress so far, and I agree to simply bootstrap using Fortran by default, only keeping the Haskell as a \"backup\", which won't be the default anymore. Also I think we will soon get #123 working, which will allow to bootstrap fpm from Fortran source using cmake on any architecture." + } + ] + }, + { + "number": 252, + "user": "urbanjost", + "date": "2020-11-25 19:28:55+00:00", + "title": "A proposed \"metadata\" command to include metadata from the TOML configuration file in a Fortran-readable format", + "text": "Something I miss using fpm(1) versus my own tools is being able to provide metadata to the Fortran files directly such as the build time, compiler version used (which some compilers can now provide via Fortran intrinsics), the version number and\nsuch. Essentially if there were a command that converted the TOML metadata into PARAMETER statements each time the build command were used you would have much the same functionality available. Packages past and present such as sccs(1) provided some way to do this but (unless I missed it) git(1) does not. I am not suggesting this is high priority for fpm(1) but would like it discussed and added to the list as appropriate. If an INCLUDE file could be generated automatically or via a subcommand it would be much easier to include correct version and license information in programs without having to edit the code files or a manual editing of an include file it is so often easy to overlook changing the build date or version in.", + "comments": [ + { + "user": "awvwgk", + "date": "2020-11-25 19:57:29+00:00", + "text": "Sounds like a good idea, having to maintain redundant information in different places is really error prone. For meson and CMake I use configure_file to insert build system meta data as parameter into Fortran source code. I very much in favour of having a configure_file or similar option for fpm as well." + } + ] + }, + { + "number": 251, + "user": "awvwgk", + "date": "2020-11-24 23:29:15+00:00", + "title": "Dependency management", + "text": "Opening this for discussion and feedback.\nFor a detailed documentation have a look at src/fpm/dependency.f90\n\n implement fpm-update command, will fetch all dependencies when called\n to force an update the --all flag can be used\n fine grain control over which dependencies are fetched is available by invoking with the dependency names\n use TOML data structure as \u201chash table\u201d for dependency management\n dependencies are stored in build/cache.toml, internal file for now, not part of the user API\n retrieve and store checked out revision in cache file\n report unused or orphaned dependencies (don't delete them?)\n find a way to actually test all this without requiring to actually fetch something\n more documentation\n\nRequires #247\nRelated #121", + "comments": [ + { + "user": "LKedward", + "date": "2020-11-26 12:10:19+00:00", + "text": "Thanks @awvwgk, implementation looks nicely done. Apologies I'm not very familiar with cargo and similar programs so I have a few basic questions:\n\ndoes fpm update only update a dependency if the revision hasn't been specified with a commit or a tag in the manifest?\n\nwhen I try fpm update with a dependency with no version information in the manifest, I notice that no git-obj is produced in the dep-lock.toml - shouldn't the latest commit be stored here?\n\n\ncan I use fpm update to update dependencies after I've change the version information in the manifest?\ndoes the existing checkout procedure for dependencies need updating to use information from the lock file if it exists?" + }, + { + "user": "awvwgk", + "date": "2020-11-26 12:33:12+00:00", + "text": "Thanks for testing, I'm still experimenting with a useful lock file format and possible update procedure. Right now the lock file is only descriptive to see how reusing information between two separate runs can work and acts more like a hash table to avoid having several versions of the same dependency around.\nGetting the actual commit after fetching a git dependency is still something to do.\nFinding a good fpm package to test is also quite a challenge, I use jsonff from @everythingfunctional, which has a moderately extensive dependency tree (there the current --all option fails, so I have to redo this part)." + }, + { + "user": "awvwgk", + "date": "2020-11-28 15:16:34+00:00", + "text": "I think I found a stable way to actually handle the dependency update for now. I renamed the dep-lock.toml to cache.toml, since it is currently used as cache rather than an actual lock file.\nThe update command supports three modes now:\n\njust a plain fpm update will update all dependencies of the project\nwith fpm update ... all the provided dependency names are updated based on the information in the cache file\nfpm update --fetch-only will only fetch not already present dependencies, this mode will be used by all other commands interacting with dependencies\n\nThe more difficult part will be the creation of unit tests for this, without actually requiring to fetch some git repositories." + }, + { + "user": "awvwgk", + "date": "2020-11-28 15:20:27+00:00", + "text": "@LKedward I'm not sure if I want to apply the fetch-only mode already for fpm-build since this might collide with #248, but I would definitely implement the same backend in a later PR or after #248 is merged." + }, + { + "user": "everythingfunctional", + "date": "2020-11-28 15:26:46+00:00", + "text": "There are two ways to design such code to make it unit testable. In a functional style, the code returns the commands/actions it would like to be executed, and some other code further up the call chain is responsible for actually executing them. In this way the unit tests can check that the code is returning the correct actions.\nIn an object oriented style, the code makes use of an abstract derived type to execute the necessary commands/actions. In the \"production\" code the caller supplies a version which just executes the actions, but in the test code a version is provided which only records the actions without executing them so that the test can check them." + } + ] + }, + { + "number": 250, + "user": "ivan-pi", + "date": "2020-11-23 10:16:04+00:00", + "title": "Support additional file extensions", + "text": "Once fpm will be out in the wild, we should try to support other Fortran file extensions.\nThis is not so important right now, but I thought I will create an issue since I gathered the information.\nHere is a table of file extensions with default support by different compilers:\n\n\n\nCompiler\nFixed-form\nFixed-form with preprocessor\nFree-form\nFree form with preprocessor\n\n\n\n\ngfortran\n.f, .for, .ftn\n.fpp, .F, .FOR, .FPP, .FTN\n.f90, .f95, .f03, .f08\n.F90, .F95, .F03, .F08\n\n\nifort\n.f, .for, .ftn, .i\n.fpp, .FPP, .F, .FOR, .FTN\n.f90, .i90\n.F90\n\n\nnvfortran\n.f .for .ftn\n.F .FOR .FTN .fpp .FPP\n.f90 .f95 .f03\n.F90 .F95 .F03\n\n\nnagfor\n.f, .for, .ftn\n.f90, .i90\n.f90, .f95\n.ff90, .ff95, .F90, .F95\n\n\nCray\n.f, .for\n.F, .FOR\n.f90, .f95, .f03, .f08, .f18, .ftn\n.F90, .F95, .F03, .F08, .F18, .FTN\n\n\nIBM\n.f, .f77\n.F, .F77\n.f90, .f95, .f03, .f08\n.F90, .F95, .F03, .F08\n\n\ng95\n.f, .for\n.F, .FOR\n.f90, .f95, .f03\n.F90, .F95, .F03\n\n\n\nThe only options that are compatible along the tool-chains listed above are: .f, .F, .f90, .F90.\nThe .ftn extension has a clash between gfortran, ifort, and nagfor which assume fixed-form, and Cray which assumes free-form.\nTo enhance portability between compilers, we should either allow fpm to (copy and) rename the files silently, or have fpm print a message to the user to consider renaming his files.\nBlog posts related to this issue:\n\n\u201cSource Form Just Wants to be Free\u201d by Doctor Fortran\nFortran File Extensions by degenerateconic\n\nEdit: Feel free to add more compilers.", + "comments": [ + { + "user": "ivan-pi", + "date": "2020-11-23 10:29:01+00:00", + "text": "On second thought, most compilers provide flags which allow to select fixed- or free-form format, meaning we could try and implement this without the need to rename files (e.g. if fpm doesn't have write access).\nBut perhaps printing an message to the user would shift the community in the direction of adopting the compatible extensions." + }, + { + "user": "awvwgk", + "date": "2020-11-23 10:44:23+00:00", + "text": "Alternatively, we could decide on a minimal set compatible for all compilers and allow explicit extension / overwriting on per project basis in the package manifest (some projects use .f while being completely free format source)." + }, + { + "user": "ivan-pi", + "date": "2020-11-23 10:53:34+00:00", + "text": "Good point. I recall now the dbcsr uses the .F extension for all their source files which are free-form.\nSo we should agree on some sane default behavior and allow the package developers to use whatever file extensions and source code format they want via the manifest." + }, + { + "user": "ivan-pi", + "date": "2020-11-23 13:25:21+00:00", + "text": "Here is a table of the respective compiler options for controlling input source format and preprocessing:\n\n\n\nCompiler\nFixed-form\nFree-form\nInvoke (C) preprocessor\n\n\n\n\ngfortran\n-ffixed-form\n-ffree-form\n-cpp\n\n\nifort\n-fixed\n-free\n-fpp\n\n\nifort (Windows)\n/fixed\n/free\n/fpp\n\n\nnvfortran\n-Mfixed\n-Mfree\n-Mpreprocess\n\n\nnagfor\n-fixed\n-free\n-fpp\n\n\nCray\n-f fixed\n-f free\n-eP, -eZ\n\n\nIBM\n-qfixed\n-qfree, -k\n-qpreprocess\n\n\ng95\n-ffixed-form\n-ffree-form\n-cpp\n\n\nflang\n-Mfixed\n-Mfreeform\n-Mpreprocess\n\n\n\nFor fixed-form the default line length is 72. For free-form the default line lengths differ between compilers (132, 255, or any).\nThe preprocessors are not fully compatible between compilers." + }, + { + "user": "awvwgk", + "date": "2020-11-23 14:04:07+00:00", + "text": "Added NVHPC/PGI compilers, which additionally support .cuf for CUDA Fortran and .CUF for preprocessed CUDA Fortran." + }, + { + "user": "ivan-pi", + "date": "2020-11-23 14:55:55+00:00", + "text": "In the blog post from Steve, there is a link to a post from Intel: Problem: Fortran source files not compiled when building in Visual Studio, which shows how the source and header file extensions are specified in Visual studio.\nI haven't studied the manifest or TOML syntax closely, but I imagine this would mean introducing something like this:\n[build]\nsource.free = [\".f90\", \".f03\", \".f08\"]\nsource.fixed = [\".f\", \".f77\"]\nfpm would then neglect all files with other extensions. I am not sure if we need to specify any file extensions for include statements, or do we just allow the compiler to search for the files and report any errors?" + }, + { + "user": "awvwgk", + "date": "2020-11-23 15:03:36+00:00", + "text": "I would remove the dot from the extension, but the general syntax looks good to me. We will probably need additional entries for the preprocessed files as well:\n[build.source]\nfree = [\"f90\", \"f03\", \"f08\"]\nfree-preprocess = [\"F90\", \"F03\", \"F08\", \"fypp\"] # or free-pp\nfixed = [\"f\", \"f77\"]\nfixed-preprocess = [\"F\", \"F77\", \"fpp\"] # or fixed-pp" + }, + { + "user": "ivan-pi", + "date": "2020-11-23 16:23:33+00:00", + "text": "I agree that is cleaner.\nWith respect to the preprocesser, I think we might need to distinguish between external preprocessors (like fypp, or preform) and those built into the compiler (C-like macro processors). Interestingly, ifort has the option to specify an alternative preprocessor using the flag -fpp-name=." + }, + { + "user": "awvwgk", + "date": "2020-11-23 16:44:49+00:00", + "text": "The preprocessor and its operation mode (\"built-in\", \"external\") could be selected in a separate entry in the [build] table. In case fpm recognizes the Intel compiler, it could try to apply an external preprocessor using the given flag, but I fear we might need to preprocess separately anyway, in case module names are mangled with preprocessor directives." + }, + { + "user": "urbanjost", + "date": "2020-11-23 18:35:03+00:00", + "text": "Unless the names are treated differently I am a strong advocate for just ..f|.F|.F90|.f90. If specifying a suffix like .f03 meant Fortran was required to strictly apply the standard as specified for that standard version (which is not the case as far as the standard is concerned) I do not like the other extensions. For a package that is intended to be designed for use by others I think I prefer the user being required to do the preprocessing themselves and only present .f|.f90 files to fpm unless fpm bundles a \"standard\" preprocessor(s). For fpm use building a local package I'm not quite as strong an advocate for that." + }, + { + "user": "urbanjost", + "date": "2020-11-23 18:37:28+00:00", + "text": "Sun used to distribute an fpp command that was written in Fortran if I recall. I use my own. 96% of my Fortran files are actually .ff and .FF files that run through a preprocessor but a lot of experience has shown me you only distribute .f90 and .f files unless there is no alternative." + }, + { + "user": "ivan-pi", + "date": "2020-11-24 09:48:30+00:00", + "text": "Unless the names are treated differently I am a strong advocate for just ..f|.F|.F90|.f90. If specifying a suffix like .f03 meant Fortran was required to strictly apply the standard as specified for that standard version (which is not the case as far as the standard is concerned) I do not like the other extensions. For a package that is intended to be designed for use by others I think I prefer the user being required to do the preprocessing themselves and only present .f|.f90 files to fpm unless fpm bundles a \"standard\" preprocessor(s). For fpm use building a local package I'm not quite as strong an advocate for that.\n\nPersonally, I agree with sticking to \".f\" for fixed, and \".f90\" for free form. Definitely, we should not tie the extensions to specific language standard. However, I am afraid that among developers there is not total consensus. As Steve notes in his blog post: \"as far as the standard was concerned, source lines were delivered to the \u201cprocessor\u201d (compiler) by fairies in the night.\", which I believe is still true today. The file extensions are merely a default set by compiler vendors. Misconceptions concerning file extensions and the Fortran language standards pop up routinely on comp.lang.fortran, Stack Exchange, r/Fortran, and now even on our Discourse.\nAdmittedly, when I started to learn Fortran for CFD, I used the \".f95\" extension. At that time I had never heard of Linux before, nor had I used the command line. The lowest entry point I could find was the Silverfrost FTN95 compiler on Windows. The example programs used the \".f95\" extension. In fact, I was not even aware that modern editions of Fortran existed, as all the examples I could find on the internet were procedural style CFD codes in F77 or F90. Only recently (three years ago!), when I got access to the Intel Fortran compiler at my university, I found out I need to use the \".f90\" extensions to have things work automatically. At the same time you have some respectable Fortran codebases (like cp2k), which bypass the default compiler options, and use \".F\" even for free-form.\nSince fpm is supposed to automatically detect Fortran source files, I believe in the future we should also search for other file extensions. If any are found, we have two options:\n\nInform the user that unless specified in the manifest, fpm assumes the source file extensions are \".f\" for fixed-form, and \".f90\" for free-form, and recommend the user to rename his files, or fill out the [build.source] section of the manifest.\nDetect automatically if the sources are free or fixed, and whether they require preprocessing, and deal with it silently by setting all the necessary compiler flags.\n\nPersonally, I am in favor of the first option. As a beginner in Fortran, this would nudge me in the right direction.\nSpeaking of option 2, it seems like a fun project with neural-fortran, the input to the neural network could be the number of ! and C characters, frequency of spaces in the first six positions, frequency of upper and lower case letters, and the frequency of symbols suchs as #, @, and $ normally used by preprocessors." + }, + { + "user": "urbanjost", + "date": "2020-11-25 19:51:14+00:00", + "text": "I like the neural-fortran idea better; but you just reminded me of some elaborate make(1) files I inherited that were all set up for the Intel compiler except these lines that called \"gfortran -fsyntax-only ...\" with the output module files thrown into a scratch directory and then erased and a bunch of other oddities. It took a moment looking at the subsequent lines to see he was compiling the code with syntax checking with gfortran only and forcing -ffixed-form (or whatever the option is) and if it failed the syntax check he was assuming it was free-form. A dangerous game but apparently it worked the way he wanted. We took it out and renamed the files and changed a few other parts that had .ftn and such built into them. Not recommending anyone use that method! He had been moving a large amount of F77 code to free-format and apparently got tired of renaming the files and making related changes, I think. Several compilers allow for directives in the source files to specify fixed versus free format at least down to the level of a single procedure. When changing old large multi-procedure files that is particularly handy (versus splitting them all apart of having to rewrite them all, and so on). If you are grabbing fixed-format codes and merging them into modules that is initially very useful. If would be nice when free-format was introduced if that had been an attribute you could specify at the beginning of a procedure definition, like\nfreeformat elemental pure function MYPROC(...\n\nbut specifying a code syntax attribute and function attributes together would probably not appeal to everyone." + } + ] + }, + { + "number": 249, + "user": "awvwgk", + "date": "2020-11-22 09:01:00+00:00", + "title": "build-script location", + "text": "Currently the build-script can specified in the [library] table with:\nlibrary.build-script = \"build.mk\"\nFor an executable only project, a library table would still be required to select a build script, even if no library sources are actually available.\nAdding the build-script to the [build] table feels more intuitive. Either as build-script or to reduce redundancy, just script:\nbuild.build-script = \"build.mk\"\nbuild.script = \"build.mk\"\nThis might be a breaking change for some projects using this fpm feature.", + "comments": [] + }, + { + "number": 248, + "user": "LKedward", + "date": "2020-11-21 16:33:23+00:00", + "title": "Refactor backend for incremental rebuilds", + "text": "This PR contains the required changes to implement incremental rebuilds (Resolves #212):\n\nMoves enumeration of link objects to occur before the backend is called\nAdds source file hashing to determine whether targets need rebuilding\nSeparates target scheduling from target compilation which:\n\nallows unit-testing of backend sorting and scheduling\noptionally allows parallel builds when compiled with openmp (bootstrap: fpm build --flag -fopenmp --flag -O3)", + "comments": [ + { + "user": "LKedward", + "date": "2020-11-28 16:40:02+00:00", + "text": "Thanks for reviewing; suggestions applied.\n\nI had a few issues when switching branches with git and rebuilding, but those might also result from incompatible module files left in the build directory\n\nI've been having this issue with the bootstrap version but can't find the source of the problem. I haven't (yet) encountered this problem with this Fortran implementation \u2014 I will look into it for a future PR \ud83d\udc4d" + }, + { + "user": "awvwgk", + "date": "2020-11-28 16:52:36+00:00", + "text": "I've been having this issue with the bootstrap version but can't find the source of the problem. I haven't (yet) encountered this problem with this Fortran implementation\n\nMaybe I encountered this while running fpm run -- build, hard to tell exactly which fpm failed, since it was an issue from gfortran complaining about incompatible module files. I cleaned both build directory afterwards (rm -r build/gfortran_*), but we will certainly get the chance to mess the build process up often enough in the future." + } + ] + }, + { + "number": 247, + "user": "awvwgk", + "date": "2020-11-21 12:09:14+00:00", + "title": "Refactoring of manifest types", + "text": "Minor changes for consistency:\n\nmove manifest defaults from fpm to fpm_manifest\nrename all manifest types from *_t to *_config_t, frees names like executable_t or dependency_t.\nnames of instances in package_config_t correspond to table names in manifest", + "comments": [ + { + "user": "LKedward", + "date": "2020-11-25 09:28:51+00:00", + "text": "The only semantic change in this PR is a minor refactoring of the package defaults \u2014 everything else is variable naming so I will merge. Thanks @awvwgk" + } + ] + }, + { + "number": 246, + "user": "LKedward", + "date": "2020-11-19 17:23:44+00:00", + "title": "CI: upload binaries when a release is published", + "text": "This PR updates the CI so that it is additionally triggered when a github release is published to which it will upload binaries (Linux, Mac, Windows) for both versions of fpm as release assets (example here).\nAs discussed at last month's meeting, this simplifies the bootstrapping process (on the supported platforms) and also simplifies using fpm in your own CI.\nAfter running the usual tests, the CI checks that the release tag, of the form vx.y.z, matches that output by fpm --version;\nbinaries are not uploaded if the release tag does not match (example workflow)\nFor the time being, releases can be created by maintainers at their own discretion as features are added and bugs fixed (I'm happy to do this); in the long term, a release process will need to be discussed and documented.\nI intend to create an initial release (v0.1.0) following this PR.\nResolves #218.", + "comments": [ + { + "user": "LKedward", + "date": "2020-11-19 21:40:23+00:00", + "text": "One minor thing: Could we generate some SHA256 hashes for each release artefact?\n\nGood point; yep I'll add them in.\n\nAlso, how are prerelease events handled?\n\nThey should be treated the same as a normal release - I'll check tomorrow.\nThanks @milancurcic, yes I agree about the naming - I'll reorder with the actual version number in and add +x permission.\n\n@everythingfunctional, do you know if compilation of statically-linked binaries is possible with Haskell stack?" + }, + { + "user": "LKedward", + "date": "2020-11-21 10:07:24+00:00", + "text": "Thanks for reviewing; I've updated the file naming convention as suggested and added hashes for checking integrity.\nUnfortunately I can't seem to preserve executable permissions on the Linux/MacOS binaries when added as assets - I think this may be a limitation (or security feature?) of github." + }, + { + "user": "awvwgk", + "date": "2020-11-21 11:10:24+00:00", + "text": "It is probably a security feature. One option to preserve the permissions would be packaging in a tarball/zip archive instead, but this would increase the \u201cinstallation barrier\u201d slightly." + }, + { + "user": "LKedward", + "date": "2020-11-25 09:34:06+00:00", + "text": "If there are no objections or further comments I will merge later today and create an initial release with tag 'v0.1.0'." + }, + { + "user": "LKedward", + "date": "2020-11-25 16:34:57+00:00", + "text": "I've created a tag v0.1.0 and corresponding release, for which the workflow has executed successfully and there are now binaries to download. Since this is the first release, instead of a change-log I have simply summarised the features currently supported in each version." + } + ] + }, + { + "number": 245, + "user": "urbanjost", + "date": "2020-11-19 13:43:25+00:00", + "title": "should run and test default to listing instead of running all cases and have a --all switch?", + "text": "I find a more intuitive behavior for run and test if that if there is just one target it runs it; but if there is more than one it just lists the candidates and that you either have to use a new switch --all to get the current behavior or give a list of targets. Does that seem like a necessary change to anyone else? Adding the switch is not much of a burden and if you have dozens of apps or tests right now the only way to get a nice list is to enter a name that does not exist. Another option might be to have a switch like -toc that lists the candidates in the nice table you get when you enter a bad name.", + "comments": [ + { + "user": "awvwgk", + "date": "2020-11-23 17:02:55+00:00", + "text": "The other way round it makes more sense to me. I would use a --list option to get all possible targets. I think at least for test that should show the integrity of the project I would prefer to run all tests rather than getting a list (and exit status zero).\nConsider a CI setup with fpm, both fpm test and fpm test --all would return a zero exit status, but the former would only work as expected for projects with a single test target. Together with the automatic discovery of test executables this might lead to surprising outcomes.\nBut it can certainly dependent on the design of the project. After I started using fpm more seriously in my projects, I reconsidered some of my project designs for fpm, leading to overall smaller projects with usually a single executable target per project." + } + ] + }, + { + "number": 244, + "user": "urbanjost", + "date": "2020-11-19 03:05:43+00:00", + "title": "Alternate directory specifications", + "text": "There are reasons to be able to specify build directories other than the defaults for building and for searching for dependencies.\nTo reduce duplication and the need to pull dependencies remotely I would suggest that you be able to specify a directory to buil dependencies in via an environment variable, and that you be able to specify a list of directories colon-separated to seach for existing dependencies somewhat like LD_LIBRARY. The ability to specify an alternate build directory that is a full pathname has some security risks if you allow externally created scripts to be used to do the build, but that is a general issue with any blindly trusted script.\nIt would also be useful to add additional directory names in the fpm.toml file to be automatically searched. Personally, in addition to applications and tests I often have demos/examples and program for testing performance. If I decide to place these outside of app/ and /test I then have to list them individually in fpm.toml; but it is very undesirable to have them run if I use \"fpm run\" or \"fpm test\" automatically.\nA third case is for the --flags option. It would be good to be able to specify a directory for a build when using --flags, and that --flags NOT be allowed to build the default and --release builds; and that that directory name (assumed to only be allowed to be a simple name that follows the rules of a Fortran variable name, not a full path name) could then be used with the run and test subcommands to use those executables. So you could do something like fpm build -flag -p -dir profile and then fpm run -dir profile.", + "comments": [ + { + "user": "awvwgk", + "date": "2020-11-19 13:58:20+00:00", + "text": "There are reasons to be able to specify build directories other than the defaults for building and for searching for dependencies.\n\nThis is a known weakness of the packaging model of cargo which partly inspired the current fpm behaviour. Cargo has an option to do exactly this kind of thing, reusing dependencies between projects. From my observation this feature was always heavily discouraged because of potential incompatibilities and security risks.\nSharing dependencies between projects will just cost us a lot of work to implement and a lot of pain to maintain and debug. A more sustainable model would certainly be necessary for this purpose.\nI think the main issue is rooted in the static linking approach fpm (and cargo as well) are using. An easy way to fix it is to compile shared objects and link dynamically. The drawback of this approach is that we have to start caring about ABI compatibility between dependency versions as well.\n\nIt would also be useful to add additional directory names in the fpm.toml file to be automatically searched. Personally, in addition to applications and tests I often have demos/examples and program for testing performance. If I decide to place these outside of app/ and /test I then have to list them individually in fpm.toml; but it is very undesirable to have them run if I use \"fpm run\" or \"fpm test\" automatically.\n\nIt could be worth to add [[example]] or [[benchmark]] to the package specification for this purpose. But maybe it is easier to add this property to the existing [[test]] and [[executable]] tables:\n[[test]]\nbenchmark = true\n\n[[executable]]\nexample = true" + }, + { + "user": "urbanjost", + "date": "2020-11-20 03:14:17+00:00", + "text": "There might be dependencies specific to the benchmarks or examples that makes me lean towards you first syntax. I was picturing being able to add directory names to be automatically built where the names could be an arbitrary user-supplied list but at least personally my use cases are for those two categories. So would the names be configurable or specifically be \"benchmark\" and \"example\"?\nI am actually a fan of static loading for almost all cases except for \"device interface\" libraries like for MPI and X11; so I would live with the status-quo. I was already concerned with some of the issues a shared directory might present but I think most of them are no worse that what you currently get with shared libraries .\nIf a central repository could only be used with commit keys specified (although that sort of impies the use of git(1) versus some other CVS systems), somwhat like the -r parameter often available on loaders I was thinking most of the problems in such a scheme would be avoided and the alternative could be a large number of copies of dependencies that would be burdensome to update. I think there are a lot of pros to such an approach.\nI was looking for something discussing the cargo issues and whether it was a deprecated cargo feature and a quick search did not find anything. Anything you could refer me to? I already knew there were pros and cons but not being a rust/cargo user I think it would be enlighting. The cargo package seems to be a good model from some references I see that seem to mention it as a better model than other languages have." + }, + { + "user": "awvwgk", + "date": "2020-11-20 07:17:53+00:00", + "text": "There is the CARGO_TARGET_DIR environment variable: https://doc.rust-lang.org/cargo/reference/config.html#buildtarget-dir\nIt was suggested recently for usage in the AUR for speeding up packaging, but not well received: https://lists.archlinux.org/pipermail/aur-general/2020-September/035922.html" + }, + { + "user": "urbanjost", + "date": "2020-11-20 14:11:09+00:00", + "text": "My biggest use case would be for QA of a large package used by many other fpm packages, especially if the dependency required special build options different than the other parts of the package. After seeing some of the issues raised I guess just installing the dependencies once verified as \"regular\" libraries outside of fpm and then using them with something like the h-fpm --link option would handle that case, but then the package is not fully contained within fpm. So it depends on how I want packages \"installed\" on a machine and the use of external links instead of package dependencies. Pros and cons on both sides of that for me. So I guess this is too early a consideration and for now it seems far clearer if everything is self-contained in the build/ directory I guess; and there is a work-around in that packages can be extracted from fpm and used like any other library. Picturing a larger project I do not want to have to rebuild something equivalent to X11 Windows or MPI or OpenMP or other large complex libraries for every little program I build that might use them. I could easily picture an fpm packaging of netlib, for example. So I'm convinced this is not something to do now and can be reconsidered if fpm is successful enough that it is an issue later when things like \"installing\" an fpm package become better defined." + }, + { + "user": "awvwgk", + "date": "2020-11-20 14:44:54+00:00", + "text": "I would recommend to look into other build systems.\nWe had gone through a painful porting process for a CMake based project recently, to allow dynamically linking against projects that were previously repackaged and statically linked. The overall process was not pleasant at all and let to a lot of boilerplate CMake code.\nI made better experiences with meson regarding dependencies so far, the meson-wrap tool allows to define subprojects (quite similar in the way fpm handles dependencies right now) as fallbacks if the dependency is not found on the host system. This works nicely for me, since I usually use the fallback for local development and still have the possibility to create separate packages for distribution.\nSuch a dependency / fallback system could be implemented by a local fpm-registry." + } + ] + }, + { + "number": 243, + "user": "urbanjost", + "date": "2020-11-19 02:20:51+00:00", + "title": "Suggest including short arguments for the major long subcommand options [fortran fpm]", + "text": "Currently the syntax of f-fpm subcommands sans --help and\n--version consists of the following:\n build [--release] [--list] [--flag COMPILER_OPTIONS]\n help [NAME(s)]\n new NAME [--lib|--src] [--app] [--test] [--backfill]\n list [--list]\n run [NAME(s)] [--release] [--runner \"CMD\"] [--list] [-- ARGS]\n test [NAME(s)] [--release] [--runner \"CMD\"] [--list] [-- ARGS]\n\nSuggest allowing short names as well as long names at least for\nthe most commonly interactively used options, as in\n build [--release|-r] [--list|-l] [--flag|-f COMPILER_OPTIONS]\n help [NAME(s)]\n new NAME [--lib|-l|--src|-s] [--app|-a] [--test|-t] [--backfill|-b]\n list [--list|-l]\n run [NAME(s)] [--release|-r] [--runner|-c \"CMD\"] [--list|-l] [-- ARGS]\n test [NAME(s)] [--release|-r] [--runner|-c \"CMD\"] [--list|-l] [-- ARGS]\n\nThat is,\n --app, `-a`\n --backfill, `-b`\n --help, `-h`\n --lib, `-l`\n --list, `-l `\n --release, `-r`\n --runner, `-c`\n --src, `-s`\n --test, `-t`\n --version, `-v`\n\nLooking at cargo it allows short names for several options, but not all.\nSome commands like stack appear to only allow a few short options, like\n-j and -v. Some commands like git allow a lot of short options. In git's case it is only\nfor the more common options on each subcommand; but note git(1) has an elaborate aliasing\nscheme that allows users to make aliases; including an internal scripting\nlanguage.", + "comments": [ + { + "user": "awvwgk", + "date": "2020-11-19 13:48:43+00:00", + "text": "Adding short flags should be done sparsely, while it might be convenient we only got a limited amount of them. I would favour a more careful design of the command line arguments in the first place, arguments that are expected to be used frequently should be easier/shorter to type." + } + ] + }, + { + "number": 242, + "user": "urbanjost", + "date": "2020-11-17 00:02:04+00:00", + "title": "OS variable needs unset in CygWin in Fortran fpm", + "text": "Running in a CygWin environment I had to unset the environment variable OS which was set for the MSWIndows applications and inherited by the CygWin application in order for the routine testing for system type to identify the environment as a CygWin/POSIX environment instead of a default MSWindows environment. Looks like the routine automatically assumes if the OS variable is set it is MSWindows. At least need a note to that effect somewhere; but might want to change the test. Specifically for CygWin there are several environment variables and the /usr/bin/cyg* commands that can be tested for without having to call platform-specific C routines if anyone wants a list. The routine identifying the platform is slated for replacement by a stdlib routine I believe, but that might be a ways off.", + "comments": [ + { + "user": "LKedward", + "date": "2020-11-17 13:36:53+00:00", + "text": "The Windows check (using 'OS'):\n\n \n \n fpm/fpm/src/fpm_environment.f90\n \n \n Lines 36 to 39\n in\n c68cf2f\n \n \n \n \n\n \n \n if (rc == 0 .and. length > 0 .and. index(val, 'Windows_NT') > 0) then \n \n\n \n \n r = OS_WINDOWS \n \n\n \n \n return \n \n\n \n \n end if \n \n \n \n\n\noccurs before the cygwin check (using 'OSTYPE'):\n\n \n \n fpm/fpm/src/fpm_environment.f90\n \n \n Lines 64 to 67\n in\n c68cf2f\n \n \n \n \n\n \n \n if (index(val, 'cygwin') > 0) then \n \n\n \n \n r = OS_CYGWIN \n \n\n \n \n return \n \n\n \n \n end if \n \n \n \n\n\nbut since cygwin imports all Windows environment variables, the Windows check will take precedence over the cygwin one and always return OS_WINDOWS.\nA possible fix could be to check the environment variable 'OS' after 'OSTYPE' and not before - what do you think @interkosmos?" + }, + { + "user": "arjenmarkus", + "date": "2020-11-17 13:40:42+00:00", + "text": "I just checked: Cygwin defines OSTYPE (to be \"cygwin\") whereas plain\nWindows does not define it - instead it uses OS. So the logic should take\nthat non-existence into account. But checking OSTYPE first seems a\nreasonable solution.\n\nOp di 17 nov. 2020 om 14:37 schreef Laurence Kedward <\nnotifications@github.com>:\n\u2026\n The Windows check (using 'OS'):\n\n https://github.com/fortran-lang/fpm/blob/c68cf2fbdb40c33636bd50b6a729490ae9d61654/fpm/src/fpm_environment.f90#L36-L39\n\n occurs before the cygwin check (using 'OSTYPE'):\n\n https://github.com/fortran-lang/fpm/blob/c68cf2fbdb40c33636bd50b6a729490ae9d61654/fpm/src/fpm_environment.f90#L64-L67\n\n but since cygwin imports all Windows environment variables\n , the Windows check will\n take precedence over the cygwin one and always return OS_WINDOWS.\n\n A possible fix could be to check the environment variable 'OS' after\n 'OSTYPE' and not before - what do you think @interkosmos\n ?\n\n \u2014\n You are receiving this because you are subscribed to this thread.\n Reply to this email directly, view it on GitHub\n <#242 (comment)>,\n or unsubscribe\n \n ." + }, + { + "user": "arjenmarkus", + "date": "2020-11-17 13:44:23+00:00", + "text": "Hm, MinGW poses another complication: if started as mingw64.exe you have a\nLinux-like environment under Windows that is compatible with plain Windows,\nwhereas msys64.exe takes you closer to Linux. The two environment variables\ndo not allow you to distinguish the two, though I think mingw64.exe is the\npreferred environment\n\nOp di 17 nov. 2020 om 14:40 schreef Arjen Markus :\n\n> The Windows check (using 'OS'):\n>\n> https://github.com/fortran-lang/fpm/blob/c68cf2fbdb40c33636bd50b6a729490ae9d61654/fpm/src/fpm_environment.f90#L36-L39\n>\n> occurs before the cygwin check (using 'OSTYPE'):\n>\n> https://github.com/fortran-lang/fpm/blob/c68cf2fbdb40c33636bd50b6a729490ae9d61654/fpm/src/fpm_environment.f90#L64-L67\n>\n> but since cygwin imports all Windows environment variables\n> , the Windows check\n> will take precedence over the cygwin one and always return OS_WINDOWS.\n>\n> A possible fix could be to check the environment variable 'OS' after\n> 'OSTYPE' and not before - what do you think @interkosmos\n> ?\n>\n> \u2014\n> You are receiving this because you are subscribed to this thread.\n> Reply to this email directly, view it on GitHub\n> <#242 (comment)>,\n> or unsubscribe\n> \n> .\n>" + }, + { + "user": "LKedward", + "date": "2020-11-17 14:00:46+00:00", + "text": "Yes I agree with you @arjenmarkus. To distinguish between the mingw64.exe shell and the msys64.exe shell there should be an 'MSYSTEM' environment variable set to 'MINGW64' and 'MSYS' for the two different shells respectively.\n\nAside: as an example why the two shells should be treated differently, execute_command_line will call the msys bash shell in msys64.exe but call the Windows cmd shell in mingw64.exe. Hence msys should be treated like Linux and mingw64 like Windows." + } + ] + }, + { + "number": 241, + "user": "14NGiestas", + "date": "2020-11-16 22:52:33+00:00", + "title": "Fix docs CI failing #240", + "text": "I didn't found any set-env command in the JamesIves repo (It is all typescript), so maybe bumping the version fixes the issue.\nEDIT: yep that was it.", + "comments": [ + { + "user": "LKedward", + "date": "2020-11-17 08:53:34+00:00", + "text": "This is a small change to fix a problem, so I will merge." + } + ] + }, + { + "number": 240, + "user": "everythingfunctional", + "date": "2020-11-16 18:13:57+00:00", + "title": "Doc Workflow Fails", + "text": "The doc workflow introduced in #237 appears not to be working. @awvwgk , any chance you can take a closer look and find out what went wrong? You can find the workflow that failed here.", + "comments": [ + { + "user": "milancurcic", + "date": "2020-11-16 21:29:28+00:00", + "text": "Same with stdlib API docs." + }, + { + "user": "14NGiestas", + "date": "2020-11-16 22:31:42+00:00", + "text": "The fpm workflow uses this one JamesIves/github-pages-deploy-action, funny thing I have to fix it there." + }, + { + "user": "14NGiestas", + "date": "2020-11-16 23:02:30+00:00", + "text": "I just bumped the version to the latest one and it seemed to work, can someone please verify if it fixes the issue?" + }, + { + "user": "LKedward", + "date": "2020-11-17 09:01:41+00:00", + "text": "Closed with #241" + } + ] + }, + { + "number": 239, + "user": "urbanjost", + "date": "2020-11-15 17:44:48+00:00", + "title": "Add --runner option to Fortran fpm to match Haskell fpm", + "text": "This option already exists in the Haskell version. It helps reduce the need\nfor the user to interact directly with the build/ directory, which ideally\nshould be a black box as far as the user is concerned.\n --runner CMD A command to prefix the program execution paths with.\n For use with utilities like valgrind(1), time(1), and\n other utilities that launch executables; commands that\n inspect the files like ldd(1), file(1), and ls(1); and\n that copy or change the files like strip(1) and install(1).\n\nEXAMPLES\n # install executables in directory (assuming install(1) exists)\n fpm run -c 'install -b -m 0711 -p -t /usr/local/bin'", + "comments": [ + { + "user": "urbanjost", + "date": "2020-11-17 19:40:36+00:00", + "text": "M_CLI2 is basically one call to define command and crack command line and then two different ways to query the option values. It looks different because the names are in the form --LONGNAME:SHORTNAME. Otherwise it is used by essentially typing the command as you would use it except that all values must be specified and that logicals must be given a value of F or T and strings must be double-quoted. The short names are not listed in the documentation yet so if no one wants short names I will remove them; but you should be able to enter:\nfpm new A -la \nfpm run -c 'gdbg'\nfpm -l\nRight now to see them you can use the --usage|-u switch\nfpm new --usage" + }, + { + "user": "LKedward", + "date": "2020-11-18 09:23:43+00:00", + "text": "Thanks for explaining, the command line code is making sense to me now. I don't mind introducing short names, though it might be better to use a separate PR for them so they can be discussed." + }, + { + "user": "urbanjost", + "date": "2020-11-19 01:33:58+00:00", + "text": "Removed short argument names. Will create a new PR for that discussion" + }, + { + "user": "LKedward", + "date": "2020-11-20 08:52:59+00:00", + "text": "Was waiting to see if anyone complained about --runner just providing a simple prefix syntax.\n\nFunnily enough I did require this capability to copy the executable file elsewhere; but because the command is constructed simply as a concatenated shell string, I simply passed the remaining postfix arguments as ARGS after --.\ne.g.\n$ fpm run --runner cp -- /path/to/destination/\nWhile not the intended syntax, I started conceptualising -- as the executable substitution. Though obviously one must be careful which arguments go before and after -- for the intended behaviour." + }, + { + "user": "urbanjost", + "date": "2020-11-20 14:52:17+00:00", + "text": "Huh. \"Every capability becomes a feature whether intended or not\". Clever thought. Did not even occur to me there is already a \"prefix\" filename \"suffix\" syntax there. I was picturing something like fpm run -runner 'cp %FNAME /path/to/destination' of course. Trying to think of any reason not to show your \"feature\" as an example. If --runner is excepted I was thinking it deserves a separate \"help\" page, where the test/run help would say \"see fpm help runner for further information\" and could show using it with gdb, install, some_non-GNU-command, ... . that had me thinking about the pros and cons of the help text being built into the fpm program itself, but I think for now that is OK." + }, + { + "user": "everythingfunctional", + "date": "2020-11-20 15:02:24+00:00", + "text": "@LKedward , that is exactly what I had in mind when I added the --runner option. I'm pretty sure mentioned as much in one of my comments some where. Glad to know I'm not the only one who noticed it. ;)" + } + ] + }, + { + "number": 238, + "user": "urbanjost", + "date": "2020-11-15 16:57:56+00:00", + "title": "Add --runner command to Fortran fpm to match bootstrap fpm", + "text": "Add the --runner switch to the run and test subcommands on f-fpm. This was recently added to the h-fpm command. It allows for more intuitive use of a command prefix than\nfpm run --list|xargs -iXX cmd XX ###INTEROGATE\nparticularly since xargs(1) probably is only available on GNU/Linux, Cygwin, and Unix platforms.\nCommon use cases for fpm run|test --runner \"COMMAND\" include using the following commands:\nCommon GNU/Linux and Unix commands\n\nnm - list symbols from object files\nsize - list section sizes and total size.\nldd - print shared object dependencies\nls - list directory contents\nstat - display file or file system status\nfile - determine file type\n\nPERFORMANCE\n\nvalgrind - a suite of tools for debugging and profiling programs\ntime - time a simple command or give resource usage\ntimeout - run a command with a time limit\n\nCOPY\n\ninstall - copy files and set attributes\ntar - an archiving utility\n\nALTER\n\nrm - remove files or directories\nchmod - change permissions of a file\n\n fpm run -c 'install -b -m 0711 -p -t /usr/local/bin'\n fpm run --runner \"tar cvfz $HOME/bundle.tgz\"\n fpm run --runner ldd\n fpm run --runner strip", + "comments": [ + { + "user": "urbanjost", + "date": "2020-11-15 18:01:12+00:00", + "text": "Added pull request #239 as a proposed implementation. The --runner CMD command is used simply as a prefix. Was considering that if the cmd include the strings %NAME and %BNAME that it would do a substitute for those strings using the name and basename of the name respectively to allow for commands where the filename does not appear at the end, but for consistency unless a strong use case is made for such a feature I chose to just use it as a prefix for consistency between the versions." + } + ] + }, + { + "number": 237, + "user": "awvwgk", + "date": "2020-11-10 21:52:01+00:00", + "title": "Add workflow to build and deploy documentation", + "text": "Adds a workflow to build and deploy the fpm documentation (based on workflow I use in toml-f):\n\nbuild documentation with ford (branch and PR)\ndeploy on master to branch gh-pages branch in same repository\n\nTODO\n\nmight require somebody with owner rights to add API-tokens", + "comments": [ + { + "user": "milancurcic", + "date": "2020-11-11 19:29:26+00:00", + "text": "Great, thank you! Once this is in, where will the docs be available? fortran-lang.github.io/fpm?\nShould we set up a fpm.fortran-lang.org subdomain like we have for stdlib.fortran-lang.org?" + }, + { + "user": "awvwgk", + "date": "2020-11-14 16:48:20+00:00", + "text": "Should now be visible at https://fortran-lang.github.io/fpm, probably needs a bit of more content. Migration to https://fpm.fortran-lang.org is still required." + } + ] + }, + { + "number": 236, + "user": "rouson", + "date": "2020-11-10 04:10:34+00:00", + "title": "fix(install): remove additional bashisms", + "text": "This pull request makes the edits suggested at\nhttps://github.com/fortran-lang/fpm/pull/216#pullrequestreview-518403499", + "comments": [] + }, + { + "number": 235, + "user": "urbanjost", + "date": "2020-11-09 20:41:50+00:00", + "title": "[Fortran fpm] Add support for command-line specification of compiler options", + "text": "The h-fpm version allows compiler options on the command line. I would propose allowing the same capability but using the\nsyntax\nfpm build [NAME(S)] [-release] -- ARGS\nwhere ARGS could be multiple compiler options.\n\nAny feedback on use cases for the feature, and comments on the h-fpm option would be informative as to whether this option should be added or not.\nshould the options replace all the options sans the ones required for the build (ie. -J, -I, ...) or be in addition to the default options?\nI think the documentation should indicate that this potentially breaks a package being self-describing, as it would be problematic to have required options on external dependencies. It would be useful for building a top-level package with different options. Options for profiling come to mind, as well as external system libraries. Other options are being discussed to handle the compile and load options as something provided in the manifest file but there will probably always be a case for supplying various options while developing a package.\nThe h-fpm version hashes the options to create a unique pathname for each combination of switches. That is an option here ; as well as requiring a user-supplied name ;or still being built in the standard location. Not sure what the general sentiment is about that. Using the hash resolves all kinds of collision problems but could be hard to remember and duplicate unless the hash is reversible and tagged with a name for reuse.\nshould the options only apply to an application and not external dependencies and files in src/? Should there be an option to control what it applies to? Would a rebuild of all package components be required?\nshould the syntax be the same in both the f-fpm and h-fpm packages or is it an advantage to allow for two syntaxes (and underlying implementation differences) for exploring more possibilities?", + "comments": [ + { + "user": "everythingfunctional", + "date": "2020-11-09 21:04:41+00:00", + "text": "Just a note, if you tie the build directory to the compiler options, as I've done for h-fpm, then you have to pass the same options to fpm run, or it will (re)build and run a different version.\nI don't know that the CLI for h-fpm and f-fpm must be identical. I think a little bit of experimentation in this area can help us find a more optimal solution. Ideally they should be similar and converge to the same, but don't have to be identical initially." + }, + { + "user": "awvwgk", + "date": "2020-11-12 07:31:39+00:00", + "text": "We were discussing using another command for this over at #220. There is cargo-rustc for Rust, which essentially allows to build using the syntax you proposed. A similar command for fpm could be fpm-compile.\nTo solve the issue with the arguments for the other build modes, fpm-compile could allow to build and run targets just like the fpm-run and fpm-test:\nfpm compile [--run|--test target] [--compiler name] [-- [args]...]\n\nIn contrast fpm-build would require a defined profile in the package manifest." + }, + { + "user": "everythingfunctional", + "date": "2020-11-12 15:19:17+00:00", + "text": "I like it, but it's missing two aspects.\n\nSpecifying the runner (like #221)\nSpecifying the target arguments\n\nFor 1, I would just add the --runner argument. For 2, I think using the [-- [args]] for that, and then adding a --flags argument that takes a string with all the flags might be the better way to go. In fact, I may switch to that for #220 (or a future PR, I haven't decided)." + }, + { + "user": "urbanjost", + "date": "2020-11-19 03:23:02+00:00", + "text": "I have a version ready that currently assumes\n#238 and #243 are implemented. It would be trivial to remove\nthe dependencies but it logically follows #238 and the Haskell\nversion of --flag; and becomes much cleaner if the --dir option\ndiscussed in #244 (but not implemented in my current implementation)\nis accepted.\nThe version I have ready just applies the options to the debug version\nunless --release is specified in which case it applies to the release\nversion. I do not consider that ideal but it is useful and allows for\nbuilds that would otherwise require the support of options in the fpm.toml\nfile or custom build scripts, such as allowing for X11 libraries or other\nexternal libraries.\nLean towards there being two options, one for compiles and one for\nloads but for now matching the current proposal to some extent (but that\nautomatically builds in an alternate directory) seems needed." + }, + { + "user": "urbanjost", + "date": "2020-11-23 09:31:31+00:00", + "text": "lternate compilers. This is an alpha version for furthering discussion\non how to implement these features as discussed here so I do not think\nit is appropriate yet for an actual pull request, but I would like some\ntrials and feedback on the interface. The code itself might need some\nrefactoring depending on how that goes. So, if interested\nThere are three new switches\n --build_name NAME, -B has to be Fortran name\n --compiler COMPILER_NAME, -C has to be Fortran name\n --flags ARGUMENTS, -F\n\nEssentially, if you use --compiler and/or --flags you have to specify a\nbuild name with the --build_name NAME switch.\nThe names release and debug are reserved.\nYou can only specify the custom build flags on the \"build\" subcommand.\nYou then use the --compiler and --build_name on \"run\" and \"test\" to match\nthe build.\nSo this is just a single file you have to build with gfortran:\n # get the single-file build file\n wget http://www.urbanjost.altervista.org/REMOVE/ffpm.f90\n # compile and name \"ffpm\" somewhere in your path\n gfortran ffpm.f90 -o $HOME/.local/bin/ffpm\nget an fpm project. For example\n```bash\ngit clone https://github.com/urbanjost/M_CLI2\n\ncd M_CLI2\n\n# assuming `ffpm` is in your path from above:\n\n# build the package with the name \"ONE\" with the nvfortran compiler:\nffpm build --compiler nvfortran --flags '-Mbackslash' --build_name ONE\n\n# build it again with the ifort compiler:\nffpm build --compiler ifort\n\n# build it again normally\nffpm build\n\n# and again as a release version\nffpm build --release\n\n# build with gfortran but with no user-specified compiler switches\nffpm build --build_name DEFAULT\n# to run that\nffpm run --build_name DEFAULT\n\n# profile with gfortran\nffpm build --build_name PROFILE --flags '-pg'\nffpm run --build_name PROFILE\nffpm run --build_name PROFILE --runner gprof\n\n# build with ifort(1) compiler and profiling options\nffpm build --compiler ifort --build_name PROFILE --flags '-p' # build\nffpm run --compiler ifort --build_name PROFILE # run\nffpm run --compiler ifort --build_name PROFILE --runner gprof # profile\nIdeally I would like to see this functionality available via the TOML file as discussed in other issues but this gives a working model for getting an idea of what some of the issues will be. RIght now for compilers other than gfortran it is assuming the modules are placed in the directory specified via -module DIRNAME which is an issue that needs a more generic solution. Hopefully this will further the discussion a bit more and help lead to a real pull request." + }, + { + "user": "urbanjost", + "date": "2020-11-23 16:17:12+00:00", + "text": "So after trying a lot of variants, I think:\nThere are two special build suffix names (assuming the compiler name is the prefix) that are used as build directories that are reserved. They can only be used if the compiler is supported and take no user-supplied link options. They are only allowed if the compiler is supported. The one is debug, which is the default. The other is release, which is used if you do a --release.\nThere is a compiler switch --compiler whose default is set with the environment variable FPM_COMPILER else it is gfortran.\nIf you supply any user-specified compiler options with --flags you must use the build command to build and you must specify a user-supplied build name via --build_name. You can then use --compiler and --build_name with a matching name on the run and test commands to run executables built with those options. On build options after -- can be options equivalent to --flags or maybe should be \"loader only\" options. If your compiler name is not known and the switch for specifying where output files to be placed is not \"-module $NAME\" then you must supply and environment variable called FPM_BUILD_OUTPUT which has a space placed between it and the build directory name unless it ends in an = in which case the filename is appended directory to it.\nSo current usage would be unchanged.\nsetting FPM_COMPILER to a supported compiler name would work just like the default except put files in build/${COMPILER}_debug/ and _release. Or, on build, run, and test you could add --compiler $FPM_COMPILER. If you want to specify your own compiler switches (assuming internally used option names are \"universal\" like -o, which is generally but not completely true) you can add a -flags option and a build name. This ignores specifying anything in the TOML file which I support. These switches (--compiler --build_name --flags, -- ARGS) and environment variables would be marked as provisional and documented completely only in \"fpm help compiler\" with a prominent note saying they are intended primarily to handle build requirements not yet internalized in fpm and are subject to change. The names are so long I think short names are appropriate, all capitalized to emphasize they are provisional (--compiler,-C; --build_name,-B, --flags,-F). If no strong opinions not to after waiting for this week I will put in a pull request for a prototype that meets that description after a week that should follow PR #239." + }, + { + "user": "awvwgk", + "date": "2020-11-23 16:39:48+00:00", + "text": "There is a compiler switch --compiler whose default is set with the environment variable FPM_COMPILER else it is gfortran.\n\nI would suggest to stay as consistent with other build systems. The established default for the compiler environment variable is FC across several build systems and meta build systems.\n\nIf your compiler name is not known and the switch for specifying where output files to be placed is not \"-module $NAME\" then you must supply and environment variable called FPM_BUILD_OUTPUT which has a space placed between it and the build directory name unless it ends in an = in which case the filename is appended directory to it.\n\nThe environment variable FPM_BUILD_OUTPUT doesn't capture this purpose in my opinion. I have seen get_module_outdir_args in the meson implementation of the Fortran compiler. CMake uses Fortran_MODULE_DIRECTORY to set the directory path in the build file. From the name FPM_BUILD_OUTPUT I wouldn't expect to set the module output directory for the Fortran compiler.\n\nThe names are so long I think short names are appropriate, all capitalized to emphasize they are provisional (--compiler,-C; --build_name,-B, --flags,-F).\n\n-C is expected in many build systems (make, ninja, meson, ...) and other programs as well (git, ...) to switch the directory, I would discourage using this short flag for the compiler. -B is the CMake flag to select the build directory output, so this might work as expected. I wonder if we should prefer underscores or hyphens in flags? Or might there a better synonym for build name we could use here instead?" + }, + { + "user": "urbanjost", + "date": "2020-11-23 17:25:40+00:00", + "text": "For whatever reason the browser is not letting me edit the post. I wanted to update it with some of the changes as a working document. Using FC instead of making up a \"new\" name seems like a particularly good one. Since hyphens are part of the \"space-hyphen value\" of POSIX commands I find the underscore useful for names, and then the names can be used directly in the code as well as hyphen is allowed in Fortran variable names; but that is probably as much personal taste as anything else as that argument has been going on at least as long as which text editor is \"best\" and which programming language is \"best\". When I get to a machine that works I will try to capture this all into a second take. Thanks for the quick response. I strongly want some of this to go into the TOML/configuration files so packages can be shared more readily but there will always be some need for directly specifying the switches and it lets us more experience with the issues of multiple compiler support On that note, I THINK your input on M_CLI2 plus working through several compiler bugs has the latest version of M_CLI2 passing its tests with nvfortran, ifort, and gfortran8.3+. Each compiler has it's pros and cons and bugs/features; but considering all that I think it is quite portable to modern Fortran compilers. It's predecessor was F77 and can on everything from SCOPE 2/UNICOS/SunOS/Solaris/HP-UX/AIX/NetBSD/Linux/Tru64/... so it was interesting that some of the modernizing made that a bit harder than I expected. It got cluttered by making a stand-alone version of; I hope to streamline it and add a bit of OOP to it in the future, but not in a hurry as long as it functions as intended." + }, + { + "user": "urbanjost", + "date": "2020-11-24 15:50:26+00:00", + "text": "Anyone have any favorite compiler options for compilers other than gfortran that would be used as a seed for the default and --release compiler switches?\nAny suggestions for the --build_name key name that seem better or shorter? --tag or --ID perhaps?\nI added a number of other compiler names for testing based on the list in #223 but have no great way of testing the majority of them.\nA lot of the vendors used to support on-line access to test machines (manufactures and compiler vendors) but I do not see any remaining ones. Something for the wish list would be web interfaces for various compilers where you could give the URL of an fpm package and it would do a build of it and show the resulting output. Probably asking to much for more than a build, but just the build would be nice. After all, legend says some unnamed companies have the policy \"It compiled, ship it!\"." + }, + { + "user": "urbanjost", + "date": "2020-11-24 16:38:03+00:00", + "text": "still oscillating on a separate subcommand like compile or custom versus build, test, run allowing customization if a custom build name is provided. A actually like the switches better but the interface is cleaner (as is documentation) if it a separate command. Something in-between where the custom/compile command just does a custom build and the test and run subcommands remain the same except they have a -ID switch added? If the -ID switch is present run and test would not do an automatic build even if the executables are not built. Everyone would have the --compiler switch.\nfpm compile --ID xxxxx --compiler xxxx -flag xxx .[regular_build_options] -- LOADER_OPTIONS\nmaybe no --flag option but options allowed after the compiler name, eg. \"--compiler 'myf90 -traceback -pg' \"\nwhich might be easier for a user to use using environment variables , or if the build,run,test commands could have a tag added to the name which would act like the --ID switch?\nfpm build,mytest=' -pg -O3' ...\nfpm run,mytest ...\nfpm test,mytest ...\nIf ID is not provided" + }, + { + "user": "urbanjost", + "date": "2020-11-25 03:55:56+00:00", + "text": "Provisional Custom Compiles\nSo, after going through the suggestions and some testing with similar h-fpm features this is\nwhat I am proposing. Looking for feedback and whether this is ready to\npropose as a PR (Pull Request).\nAdd compiler switch --fc\nrun, test,build, and a new command called compile have a switch called\n--fc that sets the Fortran compiler name. The default is to use the\nvalue of the environment variable FC. If it is not set the name gfortran\nis used.\nFC is apparently a commonly used environment variable for the compiler, is\nshort, and allows for specifying compilers for other languages like C (ie. -cc gcc)\nThat is part of the reasons to use --fc instead of --compiler.\nnew command \"compile\"\nThe compile command is like the build command except it does not have\nthe --release parameter. In addition it has the new options\n--ID NAME user-supplied name for the custom build. Required\n--flags ARGUMENTS, -F custom compiler flags\n\n-ID switch added to test and run to match name on compile command\nThe ID names release and debug are reserved and cannot be used.\n--ID is also added to run and test. If present on those commands no\nautomatic builds occur and the matching build created with compile is used.\nThe name custom is currently an alias for compile. I prefer custom and\nam looking for feedback on it.\npreliminary support for alternate compilers for testing\nA skeleton was started for standard debug and release builds that allows\nfor compilers other than gfortran. I now have access to ifort\nand nvfortran and it works with at least simple cases for those\ncompilers. Looking for someone with access to other compilers to help\nflesh that out.\nSUMMARY\nSo default usage is unchanged from the previous version. By simply setting FC you can use it like the\nprevious version with other compilers for default builds. Other than the compiler\nswitch which I suspect would be used infrequently versus the FC compiler the\nonly change to test and run is the --ID switch. The ID must be a name\nsuitable as a Fortran variable. It allows for simple custom builds and loads.\nHow does that sound?\nInstructions for testing before PR is submitted\n# single-file program for testing\nwget http://www.urbanjost.altervista.org/REMOVE/ffpm.f90\n# or pull from webpage of same name\n\n# build and call ffpm. Example. Change output name as appropriate to put\n# into your search path\ngfortran ffpm.f90 -o $HOME/.local/bin/ffpm\nsample testing\n# get a test package or use your own\nif [ ! -d M_CLI2 ]\nthen\n git clone https://github.com/urbanjost/M_CLI2\nfi\ncd M_CLI2\n\nset -x\n\n# simple custom build\nffpm compile --fc nvfortran --flags '-Mbackslash' --ID ONE\nffpm run -ID ONE\n\n# default build using ifort\nffpm build --fc ifort\n\n# default build\nffpm build\n# default release build\nffpm build --release\n\n# not sure if this should do a default build or build with gfortran with\n# no other switches\nffpm build --fc gfortran\n# will not allow reserved names debug and reserve even for this case\nffpm compile --fc gfortran --ID debug\n\n# profile with gfortran\nunset FC\nffpm compile --ID PROFILE --flags '-pg'\nffpm run --ID PROFILE\nffpm run --ID PROFILE --runner gprof\n\n# profile with --fc switch and ifort\nffpm compile --fc ifort --ID PROFILE --flags '-p' # build\nffpm run --fc ifort --ID PROFILE # run\nffpm run --fc ifort --ID PROFILE --runner gprof # profile\n\n# profile using FC variable and appropriate flags for that compiler\nexport FC=ifort\nffpm compile --ID PROFILE --flags '-p' # build\nffpm run --ID PROFILE # run\nffpm run --ID PROFILE --runner gprof # profile" + }, + { + "user": "LKedward", + "date": "2020-11-25 11:20:32+00:00", + "text": "Thanks @urbanjost; I've had a quick play around with your proposal demo \u2014 it's exciting to be able to use other compilers with fpm!\nI've been using the --flag feature since it was introduced in bootstrap version and unfortunately I find it very clunky for a number of reasons. Your addition of compile/custom and ID is certainly an improvement on the compile+run workflow, but I still have to specify the flags correctly at the command line every time I run compile (which is often).\nIt's also worth noting that unlike the bootstrap method of hashing compiler flags for the output directory, this approach may end up with unintended effects if the compiler flags change but the ID does not during a partial rebuild (coming in #248).\nOnce flags can be specified in the manifest as different configs, I would be unlikely to use the compile/custom command or --flags flag ever again.\nIn essence, I don't think the command line is the right place for specifying compiler flags because it inevitably puts the burden on the user to manually 'load' and 'store' flags correctly at each invocation \u2014 I'd much rather store various flag combinations digitally in a toml file than in my brain.\n@urbanjost, would you be happy opening separate PRs for the specification of compilers and specification of flags? The former seems ready to go from a specification standpoint, whereas the latter may need more discussion in it's own PR." + }, + { + "user": "urbanjost", + "date": "2020-11-25 14:19:31+00:00", + "text": "I will split them. My own comments in several other discussions is of the same sentiment. The prototype is just to aid the discussion. Everyone is different but I find it useful to actually try something if the discussion is stalled or has hit a roadblock.\nI separated this out as a way to actually test using other compilers and a --flags switch like h-fpm because of some of those reasons. Since a TOML file is not the most intuitive feature I found a prototype useful for exploring other alternatives like a command similiar to \"custom\" that would write a TOML entry; using aliases and environment variables from the shell to create alternatives; whether a single name or ID should imply a compiler ... If the configuration parameters are in a file they tend to be so specific to a compiler that I want something like \"fpm custom profile\" and the name \"profile\" can be used with various compilers.\nAs-is I found\nI was not using the --flags directly but was buiding up a list of aliases such as \"fpm-profile\" that had the flags set for the build; but once you combine that with multiple compilers then it needs to be a script instead of an alias, and so on.\nSo this let me actually test some of those combinations. It also matches the flag of the same name in h-fpm, and so on; but a lack of compiler and load options seemed to be the most commonly mentioned reason people could not use the earlier fpm versions. Thanks for actually trying it. There are pros and cons to any approach that involves supporting multiple compilers.\nSo my sentiment is similar but there is nothing like trying it. I have been finding that with three compilers now available on my machine that I usually use the environment variable FC and start three terminal sessions in screen(1) or tmux(1) with one set up for each compiler and toggle between them. That has made me wonder if the compiler switch should allow multiple names like\n`fpm build -fc \"nvfortran gfortran intel\" . That might seem useful to me because I am testing. In normal use I would guess most people have a specific compiler they primarily work in and they would just set \"FC\". Since other products apparently use FC if that was implemented with a variable I think it would have to be one with a unique name like FPM_FC that would be looked for.\nStill looking for other feedback on --flags including experiences with h-fpm or other source package managers." + }, + { + "user": "urbanjost", + "date": "2020-11-25 17:47:52+00:00", + "text": "On the contrarian side of this; because of the problems with remembering the compiler switches I was considering that the first build of a directory cache some data. A TOML file would see appropriate but at least for the first cut I was just going to use NAMELIST. The first time you built a (compiler-specific) directory it would create a file with the compiler and load flags from the custom command, so that it would actually be more like new in that it would initialize a directory $FC/ID.\nThen build as well as run and test would have the ID switch; and build would not build unless the directory already existed and custom would always do a full build. That way the switches are remembered and are consistent and the previous versions of build, run, and test have nothing added by one switch something like release. Maybe even change the name from --ID to --custom, and the custom commands' first parameter would be the ID name. That would be\nthe next prototype if everyone agrees this one does not cut it." + }, + { + "user": "urbanjost", + "date": "2020-11-25 17:55:11+00:00", + "text": "fpm custom -fc ifort -fflags '-g -C -CB -CU -fpe8 -ftrapuv -fp-model=precise' -ID my_debug\nfpm run -ID my_debug\nfpm build -ID mydebug\nfpm test -ID mydebug\nor fpm build --custom mydebug ...\nAssuming we allow a short name for --ID/--custom and you name with short names this could be\nfpm build -i d" + }, + { + "user": "urbanjost", + "date": "2020-11-25 19:01:32+00:00", + "text": "Currently build and custom do not use the \"unnamed\" fields so The --ID switch would not be required. TO allow the same for f-fpm there would have to be a change to do the same. Currently names following the subcommand are assumed to be targets (the name of the executables. To remove the --ID switch from all commands that would have to be changed so the same as h-fpm where you specify that with --target NAME. It depends on which would be used more commonly. Alternatively there could be runc and testc which would assume the first parameter is the custom build name instead of a target and test and run would be left as-is. With no pre-view or revision of these messages with an old version of firefox these are getting hard to compose. I will clean up the typos when I can access a more up-to-date machine.\nIt would be a non-compatible change to f-fpm to change to --target but would keep f-fpm and h-fpm more aligned; but this is still alpha. I think with these changes the changes would be useful even with the TOML interface for development. For producing a real package I think having the configuration in a shippable format in the TOML file will be the dominant format for build options that are required for a package to be functional (ie. coarray, openMP, external packages like -X11 and netCFD, .ncurses, MPI, ...)." + }, + { + "user": "urbanjost", + "date": "2020-11-25 19:06:15+00:00", + "text": "So then the format could be\nfpm custom myopts --fflags 'compiler args' -- load_args\nfpm run myopts\nfpm run myopts -target demo1 -- options_for_demo1\nBut then to run multiple programs instead of\nfpm test test1 test2 test3\nit would have to be\nfpm run --target 'test1 test2 test3'" + }, + { + "user": "urbanjost", + "date": "2020-11-26 17:14:09+00:00", + "text": "If anyone is interested I renamed the ffpm.f90 file to ffpm-custom.f90 and put ffpm.f90 there, which is a preliminary version that just specifies a compiler. So new, test, build have a --fc COMPILER_NAME switch. If not specified it looks for names specified with environment variable name FPM_FC, then FC.\n\nshould --compiler be an alias for --fc?\nany suggestions for options for particular compilers for a default and release build?\nshould an unknown compiler name be an error or should fpm(1) warn and try with no compiler options?\nallowing more than one compiler name on a single build would require some refactoring. Is that desirable?\nshould the --fc switch name be optional on build? build ifort |build -fc ifort? If so should new and test do the same and have to have application names specified via --target NAME(s) instead of being able to be names specified after the run subcommand?\nother?\n\nAfter some further testing I will start a new issue for just the compiler switch and probably close the one for the custom command unlesss there is interest. If there is interest I will start a new discussion for that. In either case I plan on closing this one. Thoughts and comments welcome. It will probably be a few days so in the meantime if anyone is interested in trying the single-file prototype please do." + } + ] + }, + { + "number": 234, + "user": "urbanjost", + "date": "2020-11-09 20:37:25+00:00", + "title": "Allow compiler options on Fortran \"fpm build -- ARGS\" [Fortran fpm]", + "text": "The h-fpm version allows compiler options on the command line. I would propose allowing the same capability but using the\nsyntax\nfpm build [NAME(S)] [-release] -- ARGS\nwhere ARGS could be multiple compiler options.\n\nAny feedback on use cases for the feature, and comments on the h-fpm option would be informative as to whether this option should be added or not.\nshould the options replace all the options sans the ones required for the build (ie. -J, -I, ...) or be in addition to the default options?\nI think the documentation should indicate that this potentially breaks a package being self-describing, as it would be problematic to have required options on external dependencies. It would be useful for building a top-level package with different options. Options for profiling come to mind, as well as external system libraries. Other options are being discussed to handle the compile and load options as something provided in the manifest file but there will probably always be a case for supplying various options while developing a package.\nThe h-fpm version hashes the options to create a unique pathname for each combination of switches. That is an option as well as requiring a user-supplied name or still being in the standard location. Not sure what the general sentiment is about that. Using the hash resolves all kinds of collision problems but could be hard to remember and duplicate unless the hash is reversable and tagged with a name for reuse.\nshould the options only apply to an application and not external dependencies and files in src/? Should there be an option to control what it applies to? Would a rebuild of all package components be required?\nshould the syntax be the same in both the f-fpm and h-fpm packages or is it an advantage to allow for two syntaxes (and underlying implementation differences) for exploring more possibilities?", + "comments": [] + }, + { + "number": 233, + "user": "awvwgk", + "date": "2020-11-08 12:08:07+00:00", + "title": "Allow linking against external libraries", + "text": "Specification changes\n\nadd specification for build.link entry in manifest reference\nallow both a single string and an array of strings\nencourage use of single external dependency for package\ndon't forbid multiple external dependencies like cargo does\nallow link entry in executable or test scope\n\nFortran fpm changes\n\nimplement manifest type to store link entries\nallow both a single string and an array of strings for link entry (might be a useful feature in toml-f as well)\nrecursively collect libraries from dependencies\nappend link libraries to model%link_flags\nadd an example package using build.link (using BLAS, which is installed on the OSX and Ubuntu image)\nadd an example package using link in executable scope (using gomp)\nuse TOML-Fortran v0.2.1\n\nTODO\n\nimplement feature in Bootstrap fpm (different PR)\n\nExamples\nbuild.link = \"z\" # -lz\nbuild.link = [\"blas\", \"lapack\"] # -lblas -llapack\n[[executable]]\nlink = [\"fftw\"]\nCloses #119\nRelevant for #168", + "comments": [ + { + "user": "awvwgk", + "date": "2020-11-08 15:36:59+00:00", + "text": "I believe Cargo/Rust want to encourage (force?) small single purpose packages to allow a modular setup. While this is in general a good idea also for fpm, this scheme will not work well for some existing library dependencies. One example would be LAPACK, which also requires linking BLAS, or Intel's MKL which requires at least three external libraries to be linked.\nWorking around an artificial constraint of only one external library per project is possible (several dummy projects with just build.link entries), but in my opinion it is unnecessary to impose such a constraint on the user in the first place." + }, + { + "user": "LKedward", + "date": "2020-11-10 14:21:13+00:00", + "text": "A possible cross-platform library for the test case could perhaps be the gcc openmp runtime api, libgomp.\nFor a simple API call without pragmas, linking directly with -lgomp should be okay on all platforms I think:\nprogram test\n implicit none\n\n interface\n integer function omp_get_num_procs()\n end function\n end interface\n\n print *, omp_get_num_procs()\n\nend program test" + }, + { + "user": "everythingfunctional", + "date": "2020-11-10 18:08:36+00:00", + "text": "I think this is a great idea. But I just want to make sure I understand the idea/implementation. As I understand it, you declare that the library needs to be linked to some external library(s), and then this information makes its way through the build process to packages that depend on it, and eventually to building and linking an executable, such that, if you depend on a package that needs linked with some external library, if you have that library installed (and in your LD_LIBRARY_PATH), then things just work. Does that explanation make sense?\nQuestion, do we want to allow specifying the same thing for specific executables and/or tests? That way packages that need an external library for an executable but not for the library can still be used as dependencies without needing the external library installed? Similar to how fpm dependencies can be specified that way?\nThis is obviously a necessity, but it does mean that some point a user may transitively end up depending on a package with one of these dependencies unknowingly and then be surprised and confused when their package won't compile. You end up with more of an implicit dependency on something that fpm can't help you with. Should we provide warnings or notices to users about these dependencies and suggestions to ensure they have them installed? Or should we require or suggest that these dependencies be repeated/explicitly declared if a package needs them, even if only because of some package they depend on?" + }, + { + "user": "awvwgk", + "date": "2020-11-10 18:55:22+00:00", + "text": "A possible cross-platform library for the test case could perhaps be the gcc openmp runtime api, libgomp.\n\n@LKedward I was thinking about using OpenMP, but than again this is a very compiler specific can of worms, I don't want to open yet.\n\nDoes that explanation make sense?\n\n@everythingfunctional You got the right idea. This way the order of the link line is also generated correctly.\n\nQuestion, do we want to allow specifying the same thing for specific executables and/or tests? That way packages that need an external library for an executable but not for the library can still be used as dependencies without needing the external library installed? Similar to how fpm dependencies can be specified that way?\n\nAlso, this is an interesting suggestion, I have to think about this.\nIn case one wants to have link against a library only for a single executable, a workaround using the implemented syntax would be:\n[[executable]]\nname = \"extra-linking\"\ndependencies.link-zlib.path = \"link-zlib\"\nwith link-zlib/fpm.toml as\nname = \"link-zlib\"\nbuild.link = \"z\"\nI'm very much in favour to cut the chase here and allow to directly specify the external library dependency:\n[[executable]]\nname = \"extra-linking\"\nlink = \"z\"\n\nShould we provide warnings or notices to users about these dependencies and suggestions to ensure they have them installed? Or should we require or suggest that these dependencies be repeated/explicitly declared if a package needs them, even if only because of some package they depend on?\n\nI think we should make a difference between external library and external dependencies.\nA build.link = \"blas\" would try to link against whatever provides the libblas.*, providing this package is the users responsibility, fpm should do exactly as asked and try to link against libblas.*, we can't help here, except for reporting a useful error message when we cannot find a libblas.*.\nThe situation is different for dependencies.blas = \"*\". In this case fpm might search for a BLAS provider, like netlib-BLAS, openBLAS, BLIS or MKL. In case of MKL different libraries might have to be linked depending on the threading model.\nI would consider the build.link option as low-level access compared to actually depending on a blas package might be a smart high-level solution provided by fpm.\nThis is certainly not my own idea to separate it like this, meson has a low-level find_library compiler method, which is similar to build.link and a dependency function, which tries to use internal finders, pkg-config or cmake to get the correct libraries and flags.\nThis is an overall difficult scenario for fpm, because it can't control the environment it is running in. In case it fails to build the package, all it can do is provide the best summary of what possibly went wrong and hope the user can take it from there." + }, + { + "user": "awvwgk", + "date": "2020-11-10 20:27:47+00:00", + "text": "Rebased against d569a89 e034ad4." + }, + { + "user": "awvwgk", + "date": "2020-11-13 08:48:05+00:00", + "text": "With three approvals I will merge later today." + } + ] + }, + { + "number": 232, + "user": "awvwgk", + "date": "2020-11-08 10:38:18+00:00", + "title": "Allow extra section in manifest", + "text": "This PR adds an extra section to the package manifest. It is excluded from checks in Fortran fpm.\nThe general idea behind this section is:\n\nallow third party tools to store information in the package manifest\nstage new entries for the fpm registry without requiring a change in the manifest reference", + "comments": [ + { + "user": "milancurcic", + "date": "2020-11-09 22:20:28+00:00", + "text": "allow third party tools to store information in the package manifest\n\nI don't understand this. Can you give a concrete example? Why would other tools want to store info in the manifest? Would these be fpm plugins or something else?" + }, + { + "user": "awvwgk", + "date": "2020-11-09 22:33:23+00:00", + "text": "I have nothing particular in mind yet, but one idea would be to allow tools like FORD/fprettify/... to read from fpm.toml instead of their own input file:\n[extra.ford]\noutput_dir = \"./docs\"\ndocmark = \"<\"\npredocmark = \">\"\n[extra.fprettify]\nindent = 4\nManaging those entries would be the responsibility of the respective tools and fpm just allows for a free space to do so.\nThe advantage of using fpm.toml is that the meta data has to specified only once, it reduces the repetition of project name, layout, descriptions, ... in case it is adapted by a commonly used tool." + }, + { + "user": "milancurcic", + "date": "2020-11-09 22:43:14+00:00", + "text": "Got it. I'm not opposed to it, but also don't see the need until users ask for it.\nIf others like it, I don't mind it going forward. @everythingfunctional @LKedward @urbanjost @certik what do you think?" + }, + { + "user": "everythingfunctional", + "date": "2020-11-09 22:49:21+00:00", + "text": "Once you put it in, you have to support it. Without a specific use case or request for it, I'd be hesitant to put it in. It's an interesting idea, and would encourage tools and users to converge around supporting and using fpm, so I'm not opposed to it. I just don't think it should be done yet. We've got plenty of other things to get done first." + }, + { + "user": "LKedward", + "date": "2020-11-11 09:13:22+00:00", + "text": "I am not opposed to this, I can see it's uses, particularly this:\n\nThe advantage of using fpm.toml is that the meta data has to specified only once, it reduces the repetition of project name, layout, descriptions, ... in case it is adapted by a commonly used tool.\n\nwhich opens the way for others to develop more tooling for the Fortran ecosystem.\n\nOnce you put it in, you have to support it.\n\nRegarding support, I think the point here is that the section is explicitly ignored by fpm, so there is no burden of maintenance for us." + }, + { + "user": "everythingfunctional", + "date": "2020-11-11 15:30:34+00:00", + "text": "Regarding support, I think the point here is that the section is explicitly ignored by fpm, so there is no burden of maintenance for us.\n\nTrue, there is essentially no maintenance cost for us, other than explicitly ignoring it and not being able to use that table for anything in the future. So it could be worth it, but as I said, I think we've got other things to worry about first." + } + ] + }, + { + "number": 231, + "user": "scivision", + "date": "2020-11-07 23:36:15+00:00", + "title": "DOC: pure Fortran fpm build method?", + "text": "Is there / will there be a way to build the pure Fortran + curl fpm itself without needing to install Haskell first? Would this be doable at least via a Makefile or is there generated source for fpm itself?\n(I would like to start using fpm across my Fortran projects as it seems Fortran submodules are/will be soon supported. I couldn't use fpm until Fortran submodules are supported.)", + "comments": [ + { + "user": "certik", + "date": "2020-11-08 02:53:45+00:00", + "text": "Yes, that is planned:\n\n#123\n\n\u2026\nOn Sat, Nov 7, 2020, at 4:36 PM, Michael Hirsch wrote:\n\n\n Is there / will there be a way to build the pure Fortran + curl fpm\n itself without needing to install Haskell first? Would this be doable\n at least via a Makefile or is there generated source for fpm itself?\n\n \u2014\n You are receiving this because you are subscribed to this thread.\n Reply to this email directly, view it on GitHub\n <#231>, or unsubscribe\n ." + }, + { + "user": "awvwgk", + "date": "2020-11-08 10:13:47+00:00", + "text": "Bootstrapping fpm once with the Haskell version is currently required, but the Fortran fpm implementation should be able to bootstrap itself afterwards. We are working towards a first release and a way to provide binaries as a rolling release (#218)." + }, + { + "user": "certik", + "date": "2020-11-08 17:16:07+00:00", + "text": "Yes, if you are ok with using an fpm binary as a starting point, then fpm will be able built itself eventually. The issue #123 is for bootstrapping from source from scratch." + }, + { + "user": "scivision", + "date": "2020-11-08 19:12:50+00:00", + "text": "If I understand correctly the end goal is to have the capability to build fpm from scratch with a Fortran compiler + CMake (among other methods). This would be great." + }, + { + "user": "certik", + "date": "2020-11-08 19:38:31+00:00", + "text": "Yes, correct.\n\u2026\nOn Sun, Nov 8, 2020, at 12:13 PM, Michael Hirsch wrote:\n\n\n If I understand correctly the end goal is to have the capability to\n build fpm from scratch with a Fortran compiler + CMake (among other\n methods). This would be great.\n\n \u2014\n You are receiving this because you commented.\n Reply to this email directly, view it on GitHub\n <#231 (comment)>, or unsubscribe ." + }, + { + "user": "urbanjost", + "date": "2020-11-09 04:25:23+00:00", + "text": "Well, since the Fortran version does not have any C dependencies at this point it will actually build as a single Fortran file.\nLong story short I wanted a version of #229 on a machine that just had a Fortran compiler and that I could build with the\ndebugger so I used an old \"make\" trick:\ncd $(basename $0)\ncat >gfortran <<\\EOF\n#!/bin/bash\n(\nexec 2>&1\n/usr/bin/gfortran \"$@\" 2>&1\n) >/dev/null\nNAME=$(echo $*|xargs -n 1|grep '\\.f90$')\necho ============================================================\necho COMMAND \"$@\"\necho NAME $NAME\ncase \"$NAME\" in\n'');;\ntest/*);;\n*)\necho cat $NAME >> catthem\n;;\nesac\nEOF\n\necho '#!/bin/bash' >catthem\nexport PATH=`pwd`:$PATH\nchmod u+xr gfortran\nrm -rfv build\nfpm build\nmkdir -p _scratch\nbash catthem >_scratch/ffpm.f90\n(\ncd _scratch\ngfortran ffpm.f90 -o ../ffpm\n)\nrm gfortran\nrm catthem\nmv _scratch/ffpm.f90 .\nrm -rf _scratch\nexit\n\nIf you run that with the bootstrap fpm it makes a file called ffpm.f90 that compiles just fine with a simple gfortran compile.'.\nIt lets you try other compilers anduse a debugger on the code and other nice things for now. Would not commit to that being a long-term solution but it has been pretty handy lately. Maybe we could place the file out there as a simple way for some people to test the Alpha version without having to commit to much effort. Compile one file. Try it." + }, + { + "user": "urbanjost", + "date": "2020-11-21 04:24:40+00:00", + "text": "i changed the use statements to all use the module that defines toml_table as the quickest way to get rid of that Intel compiler message and updated M_CLI2 to use standard-conforming use of : and * in that one line. Wondering if anyone can try the single-file bootstrap version with anything other than gfortran 8.3.1-5 on a Red Hat 8.2\nsystem. Particularly interested in gfortran 10 and non-gfortran compiles.\n wget http://www.urbanjost.altervista.org/REMOVE/ffpm.f90 \nand just compile the single file and if it builds the theory is it should be able to bootstrap a pull of the fpm/fpm Fortran directory without having to install anything on a machine except gfortran and git." + }, + { + "user": "awvwgk", + "date": "2020-11-21 08:23:38+00:00", + "text": "@urbanjost I did a bit of testing with all my available compiler toolchains on three different machines (Manjaro, RedHat, OpenSuse).\nGCC works nicely for me, tested 7.5, 8.4, 9.2, 10.1 and 10.2 so far. Intel is the same, compiles with 18.0, 19.0 and 19.1, but the resulting binary might be non-functional.\nPGI doesn't work since toml-f cannot be compiled due to a bug in 20.7 and 20.9 of the NVHPC compilers (see toml-f/toml-f#25). Also M_CLI2 triggers some PGI bugs, see urbanjost/M_CLI2#2.\nNAG fails on a logical formatter in M_CLI2 (see urbanjost/M_CLI2#1), but toml-f seems to be fine." + }, + { + "user": "scivision", + "date": "2020-11-22 02:23:11+00:00", + "text": "I took a try at this. To make fpm build purely from CMake, I would need to add FetchContent (CMake feature) to retrieve and build toml-f and M_CLI2. The goal of this is to partially address #123 by making fpm build from nothing more than CMake and Fortran compiler, without needing bootstrap fpm. Would this be useful?" + }, + { + "user": "awvwgk", + "date": "2020-11-22 08:07:26+00:00", + "text": "@scivision I'm sometimes building fpm with meson myself. So I'm certainly not against adding another build system (cmake/meson/...) to this repository as it makes some tasks way easier.\nFrom #123 I suspect that a fpm dist --cmake command was intended for this purpose to generate a source distribution with additional CMake files. Until we are actually able to do this, another build system might be a suitable choice as well.\nFetchContent seems to be the easiest way to get the dependencies with CMake, I'm using something similar right now for toml-f." + } + ] + }, + { + "number": 230, + "user": "awvwgk", + "date": "2020-11-07 12:50:19+00:00", + "title": "Create a specification of the fpm command line interface (asciidoctor)", + "text": "Create fpm(1) and the currently available six subcommand manual pages.\nTo check the resulting manual pages on the command line translate them with asciidoctor:\nasciidoctor -b manpage fpm.adoc\nman -l fpm.1\n\n\nI guess asciidoc is not that well known by everybody, checkout its homepage and the asciidoctor project for a short overview. It is comparable to reStructuredText as an extendable and standardized markup language for technical writing. There are several large projects using it extensively but it is not as well known as Markdown.\n\nPlease review this PR while comparing to #261 and consider the following points\n\nsetup/usage of the toolchain\nthe markup language to express the command line documentation\nthe output (both HTML and roff/man page)\nthe preview on GH\n\nCloses #227\nCloses #261", + "comments": [ + { + "user": "awvwgk", + "date": "2020-11-30 18:01:31+00:00", + "text": "I have looked for alternatives to write man pages and CLI documentation, but asciidoc seems to be the best solution I could fine so far, therefore I will just open this PR for discussion." + }, + { + "user": "milancurcic", + "date": "2020-11-30 19:13:40+00:00", + "text": "Have you tried converting Markdown to man page format using Pandoc? There's an example here.\nI ask because 1) Markdown is simpler than Asciidoc and we're already writing Markdown for READMEs, and 2) pandoc is a more mature tool than asciidoctor (I think)." + }, + { + "user": "awvwgk", + "date": "2020-11-30 19:19:06+00:00", + "text": "Thanks for the suggestion, I will give it a try and open another PR with markdown files if it works out nicely. Than we can compare and make a choice between the two." + } + ] + }, + { + "number": 229, + "user": "LKedward", + "date": "2020-11-06 11:37:32+00:00", + "title": "Refactor run command", + "text": "This PR simplifies the run command implementation to use information provided by the model%targets structure. This avoids the duplication of code which has caused the run command to construct executable paths differently to the build command; this PR fixes this problem.", + "comments": [ + { + "user": "urbanjost", + "date": "2020-11-07 01:05:03+00:00", + "text": "So far the code looks good and is passing many tests but ran into\na few problems that might be on my side, and I have not gotten\nthrough some more complex builds with C code so I am still testing.\nI am excited on how well it it working on a machine with no bootstrap\nversion installed, just the Fortran version. Basic build, run, and\ntest are working with many fpm(1) packages I have with --release and\n--list.\nI like the change to just show the pathname with --list which I was\ngoing to put a little PR in for. It allows the names to be used with\nexternal filters easily. It works particularly well with the Unix\nxargs(1) command.\nOn a machine with just a single Fortran source built from #pr229\nmany fpm(1) packages are working. The ones that I do not think I\ncan build with this version are ones that require a \"fpm.mk\" or custom\nbuild script.\nSo this is the only issue I have to raise at this point ...\nWhen an executable does not exist there is no message.\n ffpm new A --lib\n cd A\n ffpm run\n ffpm test\nThis is different than the h-fpm version, which produces a warning\nmessage. It is arguable whether it should or should not produce a\nmessage for the case where there is no executable but even when the name\nis incorrect no error or warning is produced. eg:\n ffpm run this_is_a_typo\ndoes not warn that there is no such executable. I think it should produce\na message and perhaps do the equivalent of the --list option to show the\navailable choices. Maybe just the basenames would be preferable in a\nlittle table.\n box_month d2j d2o d2u d2w\n date_to_julian date_to_unix days2sec dow easter\n fmtdate fmtdate_usage guessdate j2d julian_to_date\n mo2d mo2v moon_fullness M_time_oop now\n o2d ordinal_seconds ordinal_to_date phase_of_moon sec2days\n system_sleep u2d unix_to_date v2mo w2d\n runTests \n\nmaybe just a message to say to use the --list option to see available choices when an unknown name is entered?" + }, + { + "user": "urbanjost", + "date": "2020-11-07 17:23:46+00:00", + "text": "A minor inconsistency. The default search includes the current directory\nwhen anything is found, but if you have no app/ directory it tells you there is nothing to build.\nBut if you explicitly tell it to build a program in the current directory\nyou end up getting two executables if you do not use the default name\nfor your executable.\nI like the concept of having a project in a directory with\nnothing but a source file and an fpm.toml file with external dependencies.\nAnd if I add the auto-executables directive I get the intuitive result.\nSo if I have a directory that contains nothing but \"main.f90\" and the\nfollowing manifest file I get the binary that I was trying to produce (so I\nconsider this the \"minimal project\"). I can see use cases for this where\nI have a program that needs nothing else except external directories.\nCASE I\nname = \"test\"\n[build]\nauto-executables = false\n\n[[executable]]\nname=\"testit\"\nsource-dir=\".\"\nmain=\"main.f90\"\nbut if I just have a manifest with a name in it and the same program file\nCASE II\nname = \"test\"\nI get\nNeither library nor executable found, there is nothing to do\nERROR STOP 1\n\nError termination. Backtrace:\n :\n :\n\nSo it acts like the current directory is not automatically searched.\nBut if I change the manifest to\nCASE III\nname = \"test\"\n\n[[executable]]\nname=\"testit\"\nsource-dir=\".\"\nmain=\"main.f90\"\nIt builds two executables, main and testit because the code\nautomatically searches the current directory. So to have the minimal\ntwo-file project just generate a single file I have to turn off\nauto-detection.\nThe documentation for the manifest file says it searches in the\ndefault directories, so one suggestion might be that it not search\nthe current directory.\nAnother approach would be to have it find and build without the\nerror message when it finds a program in the current directory instead\nof saying there are not any.\nI think others might argue it should only allow pathnames below the\ncurrent directory but I actually like being able to make a two-file\nproject where the manifest just lists external dependencies. I think\nthis could be a common use of fpm." + }, + { + "user": "LKedward", + "date": "2020-11-07 17:35:58+00:00", + "text": "@urbanjost, I like the idea of a minimal two file project - it was not a test case I thought of testing before. It looks like there's a bug in the source processing of explicit [[executable]] entries; the current/root directory should not be searched by auto-discovery. Both Case I and case III should work, but not case II. I will look into this. Thanks for bringing it up." + }, + { + "user": "urbanjost", + "date": "2020-11-07 19:14:27+00:00", + "text": "That was fast. Perfect for ffpm run **not_there** when there are valid targets. When there are no valid targets a simple ffpm run produces no message, but for consistency should it say \"no valid targets\" or show the same thing that \"ffpm run empty\" did in the directory with no targets in the following sequence of commands? I am fine with it as-is but I think it would be less confusing if you were working with a package you did not create and/or were new to fpm. Really nice work. Least number of comments I think I have ever had for something with so many arbitrary paths through it in an alpha version; and nothing I spotted by eye in the code to comment on at all.\n#!/bin/bash\n(\nexec 2>&1\n set -x\n ffpm run asdf\n ffpm new A -lib\n cd A\n ffpm run <<<< NO OUTPUT?\n ffpm run empty\n)|tee -a $0\nexit\n################################################################################\n+ ffpm run asdf\nfpm::run specified names \"asdf\" not found.\n\n Available names:\n box_month d2j d2o d2u\n d2w date_to_julian date_to_unix days2sec\n dow easter fmtdate fmtdate_usage\n guessdate j2d julian_to_date mo2d\n mo2v moon_fullness M_time_oop now\n o2d ordinal_seconds ordinal_to_date phase_of_moon\n sec2days system_sleep u2d unix_to_date\n v2mo w2d\nSTOP 1\n+ ffpm new A -lib\n + mkdir -p A\n + cd A\n + mkdir -p A/src\n + git init A\nInitialized empty Git repository in /home/urbanjs/venus/V600/github/M_time/A/.git/\n+ cd A\n+ ffpm run\n+ ffpm run empty\nfpm::run specified names \"empty\" not found.\n\n Available names:\n\nSTOP 1" + }, + { + "user": "urbanjost", + "date": "2020-11-07 20:35:26+00:00", + "text": "This is an edge case but it looks like it would only take a few lines to warn the user something went wrong.\nSince all the applications go into one directory it is relatively easy to create duplicates that collide. So with a manifest\nlike this\nname = \"test\"\n\n[[executable]]\nname=\"testit\"\nsource-dir=\".\"\nmain=\"main.f90\"\n\n[[executable]]\nname=\"testit\"\nsource-dir=\"other\"\nmain=\"main.f90\"\n\n[[executable]]\nname=\"testit\"\nsource-dir=\"other\"\nmain=\"main2.f90\"\nIn a intentionally setup with intentional duplicates both h-fpm and\nf-fpm build all the targets. h-fpm places them in subdirectories\ncorresponding to their original location while f-fpm places them all\nin build/*/app/. h-fpm has no good way to execute them except by the\nbasename that I know of so all the targets exist but it is not without\nissues, but f-fpm overwrites. f-fpm does list them all with\nfpm build --list\nso I think it would be relatively easy to warn when there are duplicate\nbasenames so you know there was an overwrite.\nIn my testcase the filesystem looks like\n./app/main.f90\n./app/main2.f90\n./other/main2.f90\n./other/main.f90\n./other/main3.f90\n\nI agree this an aberrant case but it looks like the warning would be easy\nto produce.\nI much bigger change would be to put the executables into separate directories like h-fpm but unless the run command took subdirectory names that really does not solve the issue; and if the user is warned they can easily (probably) resolve it by giving a unique name to the output executable in the manifest file." + }, + { + "user": "urbanjost", + "date": "2020-11-07 23:18:50+00:00", + "text": "When I took a second look there is a fixed format of 17 characters, which I sometimes\nexceed.\nAvailable names:\ndemo_system_accesdemo_system_chdirdemo_system_chmoddemo_system_chown \ndemo_system_cleardemo_system_closedemo_system_cpu_tdemo_system_errno \ndemo_system_getcwdemo_system_getegdemo_system_getendemo_system_geteu \ndemo_system_getgidemo_system_getgrdemo_system_gethodemo_system_getlo \ndemo_system_getpidemo_system_getppdemo_system_getpwdemo_system_getsi \ndemo_system_getuidemo_system_getumdemo_system_initedemo_system_isblk \ndemo_system_ischrdemo_system_isdirdemo_system_isfifdemo_system_islnk \ndemo_system_isregdemo_system_issoc demo_system_kill demo_system_link \ndemo_system_mkdirdemo_system_mkfifdemo_system_opend demo_system_perm \ndemo_system_perrodemo_system_puten demo_system_randdemo_system_readd \ndemo_system_readedemo_system_realpdemo_system_removdemo_system_renam \ndemo_system_rewindemo_system_rmdirdemo_system_setsidemo_system_setum \ndemo_system_sranddemo_system_unamedemo_system_unlindemo_system_unset \ndemo_system_utime\nSTOP 1diff --git a/fpm/src/fpm.f90 b/fpm/src/fpm.f90I did ask for this :>. \n\nI cleaner way would require two passes to find the longest string I think. Maybe there is a simpler way you see. A kludge that\nmakes sure nothing is truncated without taking a second pass worked. It would not keep columns aligned but it would prevent truncattion:\nindex 31927fc..d852cb6 100644\n--- a/fpm/src/fpm.f90\n+++ b/fpm/src/fpm.f90\n@@ -304,7 +304,7 @@ subroutine cmd_run(settings,test)\n class(fpm_run_settings), intent(in) :: settings\n logical, intent(in) :: test\n \n- integer :: i, j\n+ integer :: i, j, column_width\n logical :: found(size(settings%name))\n type(error_t), allocatable :: error\n type(package_t) :: package\n@@ -382,8 +382,8 @@ subroutine cmd_run(settings,test)\n \n j = 1\n write(stderr,*) 'Available names:'\n+ column_width=17\n do i=1,size(model%targets)\n-\n exe_target => model%targets(i)%ptr\n \n if (exe_target%target_type == FPM_TARGET_EXECUTABLE .and. &\n@@ -394,7 +394,9 @@ subroutine cmd_run(settings,test)\n if (exe_source%unit_scope == &\n merge(FPM_SCOPE_TEST,FPM_SCOPE_APP,test)) then \n \n- write(stderr,'(A17)',advance=(merge(\"yes\",\"no \",modulo(j,4)==0))) basename(exe_target%output_file)\n+ column_width=max(column_width,len(basename(exe_target%output_file))+1)\n+ write(stderr,'(A)',advance=(merge(\"yes\",\"no \",modulo(j,4)==0))) &\n+ & [character(len=column_width) ::basename(exe_target%output_file)]\n \n j = j + 1\nfpm::run specified names \"asdf\" not found.\n\n Available names:\ndemo_system_access demo_system_chdir demo_system_chmod demo_system_chown \ndemo_system_clearenv demo_system_closedir demo_system_cpu_time demo_system_errno \ndemo_system_getcwd demo_system_getegid demo_system_getenv demo_system_geteuid \ndemo_system_getgid demo_system_getgrgid demo_system_gethostname demo_system_getlogin \ndemo_system_getpid demo_system_getppid demo_system_getpwuid demo_system_getsid \ndemo_system_getuid demo_system_getumask demo_system_initenv demo_system_isblk \ndemo_system_ischr demo_system_isdir demo_system_isfifo demo_system_islnk \ndemo_system_isreg demo_system_issock demo_system_kill demo_system_link \ndemo_system_mkdir demo_system_mkfifo demo_system_opendir demo_system_perm \ndemo_system_perror demo_system_putenv demo_system_rand demo_system_readdir \ndemo_system_readenv demo_system_realpath demo_system_remove demo_system_rename \ndemo_system_rewinddir demo_system_rmdir demo_system_setsid demo_system_setumask \ndemo_system_srand demo_system_uname demo_system_unlink demo_system_unsetenv \ndemo_system_utime \nSTOP 1\n\nI was looking for a quick way to find the longest name and did not see it off the bat and thought I would show you this first before looking deeper. Maybe just listing the basenames instead of the table is simpler. I do not know how common having this many applications or tests is. I happen to try to have a demo as part of each manpage; which can add up quickly." + }, + { + "user": "urbanjost", + "date": "2020-11-07 23:32:08+00:00", + "text": "FYI: worked very nicely with a module of mine called M_system that contained a C file that required me to use an fpm..mk file with h-fpm. Refactoring all my fpm packages to work with f-fpm; which is breaking some of them for use with h-fpm. I am putting a note in the README.md files on the github sites to that effect, but a number of them are listed in the fpm registry which causes some confusion. I think I need to add a rev to the FPM registry files to point to the older ones" + }, + { + "user": "urbanjost", + "date": "2020-11-08 22:16:47+00:00", + "text": "All the other tests I have passed other than what I commented on. I am moving a few repositories to use the new fpm but unless I stumble on something all my tests are complete. Seems like a bootstrappable single Fortran file would be due for people to experiment with? They would just need a Fortran compiler and gfortran. build, run, test, new, help all function, the TOML interface and build with a remote dependency works, the auto-discovery makes for some simple manifest files. Some people might be able to give feedback more readily if they just have to pull a file down and compile it with the language they are developing in. Still cannot do custom build scripts, add external libraries, options of OpenMP, OpenACC, MPI, Coarrays, ... but getting pretty useful." + }, + { + "user": "urbanjost", + "date": "2020-11-11 02:04:58+00:00", + "text": "A build of this branch placed into a single file and built with a simple \"gfortran ffpm.f90\" on a machine with git and gfortran but no bootstrap version built and ran all the repositories in the fpm registry except one that got a compiler error (it was gfortran 10.0) that was part of the package and not an fpm issue. I could build run and test (and help and new which were not really being changed) in all those packages.\nThe only problem I had was on a CygWin machine where I had to unset the OS environment variable in order for the code to select OS_TYPE=cygwin instead of MSWindows. I think that is a seperate issue to resolve in a new PR.\nOut of my own fpm packages the only one I cannot build is one that requires the X11 Windows libraries, which was expected as custom build scripts are not supported yet, nor are user-supplied load and compiler switches. Nice job." + }, + { + "user": "urbanjost", + "date": "2020-11-11 02:19:14+00:00", + "text": "PS:\nwget http://www.urbanjost.altervista.org/REMOVE/ffpm.f90 \ngfortran ffpm.f90 -o ffpm\nI am going to leave the file ffpm.f90 available for a week that can be accessed via a browser or something like the wget(1) above. If anyone has access to compilers other than gfortran I am very curious if the file compiles and runs. The fiile is fpm #229." + }, + { + "user": "arjenmarkus", + "date": "2020-11-11 08:58:28+00:00", + "text": "I have used Intel Fortran version 2018 to compile the file. It produced\nquite a few error messages - see the attachment.\n\nTwo of the error messages were easily corrected - stop abs(sig) is not\nallowed - stop comes with a constant only - and the message about\nallocating a zero-length string disappears when you change the asterisk to\na colon. However, the messages about get_value are more demanding. I have\nnot looked at them in any detail :)\n\nOp wo 11 nov. 2020 om 03:19 schreef urbanjost :\n PS:\n\n wget http://www.urbanjost.altervista.org/REMOVE/ffpm.f90\n gfortran ffpm.f90 -o ffpm\n\n I am going to leave the file ffpm.f90 available for a week that can be\n accessed via a browser or something like the *wget(1)* above. If anyone\n has access to compilers other than gfortran I am very curious if the file\n compiles and runs. The fiile is fpm #229\n <#229>.\n\n \u2014\n You are receiving this because you are subscribed to this thread.\n Reply to this email directly, view it on GitHub\n <#229 (comment)>, or\n unsubscribe\n \n .\n\nIntel(R) Visual Fortran Intel(R) 64 Compiler for applications running on Intel(R) 64, Version 18.0.5.274 Build 20180823\nCopyright (C) 1985-2018 Intel Corporation. All rights reserved.\n\nffpm.f90(1836): error #8231: In an ALLOCATE statement the type parameter values in type specification shall be an asterisk if and only if each object being allocated is a dummy argument for which the type parameter is assumed. [STRINGS]\n allocate(character(len=0)::strings(0))\n------------------------------------^\nffpm.f90(1841): error #8231: In an ALLOCATE statement the type parameter values in type specification shall be an asterisk if and only if each object being allocated is a dummy argument for which the type parameter is assumed. [STRINGS]\n allocate(character(len=0)::strings(0))\n---------------------------------^\nffpm.f90(2659): remark #8291: Recommended relationship between field width 'W' and the number of fractional digits 'D' in this edit descriptor is 'W>=D+7'.\n read(nan_string,'(g3.3)')valu\n----------------------------^\nffpm.f90(5230): error #6345: Either a PAUSE, STOP or ERROR STOP statement has an invalid argument. [ABS]\n stop abs(sig)\n-----------^\nffpm.f90(6756): warning #6843: A dummy argument with an explicit INTENT(OUT) declaration is not given an explicit value. [SELF]\nsubroutine new_keyval(self)\n----------------------^\nffpm.f90(10108): error #6285: There is no matching specific subroutine for this generic subroutine call. [GET_VALUE]\n call get_value(table, key, ptr, present(default), stat)\n--------^\nffpm.f90(10146): error #6285: There is no matching specific subroutine for this generic subroutine call. [GET_VALUE]\n call get_value(table, key, ptr, present(default), stat)\n--------^\nffpm.f90(10184): error #6285: There is no matching specific subroutine for this generic subroutine call. [GET_VALUE]\n call get_value(table, key, ptr, present(default), stat)\n--------^\nffpm.f90(10222): error #6285: There is no matching specific subroutine for this generic subroutine call. [GET_VALUE]\n call get_value(table, key, ptr, present(default), stat)\n--------^\nffpm.f90(10260): error #6285: There is no matching specific subroutine for this generic subroutine call. [GET_VALUE]\n call get_value(table, key, ptr, present(default), stat)\n--------^\nffpm.f90(10298): error #6285: There is no matching specific subroutine for this generic subroutine call. [GET_VALUE]\n call get_value(table, key, ptr, present(default), stat)\n--------^\nffpm.f90(10336): error #6285: There is no matching specific subroutine for this generic subroutine call. [GET_VALUE]\n call get_value(table, key, ptr, present(default), stat)\n--------^\nffpm.f90(10374): error #6285: There is no matching specific subroutine for this generic subroutine call. [GET_VALUE]\n call get_value(table, key, ptr, present(default), stat)\n--------^\nffpm.f90(10409): error #6285: There is no matching specific subroutine for this generic subroutine call. [GET_VALUE]\n call get_value(table, key, ptr, .true., stat)\n--------^\nffpm.f90(10439): error #6285: There is no matching specific subroutine for this generic subroutine call. [GET_VALUE]\n call get_value(table, key, ptr, .true., stat)\n--------^\nffpm.f90(10469): error #6285: There is no matching specific subroutine for this generic subroutine call. [GET_VALUE]\n call get_value(table, key, ptr, .true., stat)\n--------^\nffpm.f90(10499): error #6285: There is no matching specific subroutine for this generic subroutine call. [GET_VALUE]\n call get_value(table, key, ptr, .true., stat)\n--------^\nffpm.f90(10529): error #6285: There is no matching specific subroutine for this generic subroutine call. [GET_VALUE]\n call get_value(table, key, ptr, .true., stat)\n--------^\nffpm.f90(10559): error #6285: There is no matching specific subroutine for this generic subroutine call. [GET_VALUE]\n call get_value(table, key, ptr, .true., stat)\n--------^\nffpm.f90(10589): error #6285: There is no matching specific subroutine for this generic subroutine call. [GET_VALUE]\n call get_value(table, key, ptr, .true., stat)\n--------^\nffpm.f90(10619): error #6285: There is no matching specific subroutine for this generic subroutine call. [GET_VALUE]\n call get_value(table, key, ptr, .true., stat)\n--------^\nffpm.f90(10946): error #6285: There is no matching specific subroutine for this generic subroutine call. [GET_VALUE]\n call get_value(array, pos, ptr, stat)\n--------^\nffpm.f90(10974): error #6285: There is no matching specific subroutine for this generic subroutine call. [GET_VALUE]\n call get_value(array, pos, ptr, stat)\n--------^\nffpm.f90(11002): error #6285: There is no matching specific subroutine for this generic subroutine call. [GET_VALUE]\n call get_value(array, pos, ptr, stat)\n--------^\nffpm.f90(11030): error #6285: There is no matching specific subroutine for this generic subroutine call. [GET_VALUE]\n call get_value(array, pos, ptr, stat)\n--------^\nffpm.f90(11058): error #6285: There is no matching specific subroutine for this generic subroutine call. [GET_VALUE]\n call get_value(array, pos, ptr, stat)\n--------^\nffpm.f90(11086): error #6285: There is no matching specific subroutine for this generic subroutine call. [GET_VALUE]\n call get_value(array, pos, ptr, stat)\n--------^\nffpm.f90(11114): error #6285: There is no matching specific subroutine for this generic subroutine call. [GET_VALUE]\n call get_value(array, pos, ptr, stat)\n--------^\nffpm.f90(11142): error #6285: There is no matching specific subroutine for this generic subroutine call. [GET_VALUE]\n call get_value(array, pos, ptr, stat)\n--------^\nffpm.f90(11170): error #6285: There is no matching specific subroutine for this generic subroutine call. [GET_VALUE]\n call get_value(array, pos, ptr, stat)\n--------^\nffpm.f90(11174): error #6285: There is no matching specific subroutine for this generic subroutine call. [ADD_KEYVAL]\n call add_keyval(array, ptr, stat)\n--------------^\nffpm.f90(11204): error #6285: There is no matching specific subroutine for this generic subroutine call. [GET_VALUE]\n call get_value(array, pos, ptr, stat)\n--------^\nffpm.f90(11446): catastrophic error: Too many errors, exiting\ncompilation aborted for ffpm.f90 (code 1)" + }, + { + "user": "urbanjost", + "date": "2020-11-11 13:43:05+00:00", + "text": "Thanks. That is basically all one issue I believe. Interesting differences." + }, + { + "user": "awvwgk", + "date": "2020-11-11 13:49:38+00:00", + "text": "I have used Intel Fortran version 2018 to compile the file. It produced\nquite a few error messages - see the attachment.\n\n@arjenmarkus I'm responsible for parts of those issues with TOML-Fortran (get_value, see toml-f/toml-f#16), but those are now fixed with the v0.2.1 release and will be used in fpm with #233." + }, + { + "user": "milancurcic", + "date": "2020-11-11 19:24:16+00:00", + "text": "I'm responsible for parts of those issues with TOML-Fortran (get_value, see toml-f/toml-f#16), but those are now fixed with the v0.2.1 release and will be used in fpm with #233.\n\n@LKedward @awvwgk Considering this, is there a preferred order to merging? Should this PR wait for #233 or it doesn't matter?" + }, + { + "user": "awvwgk", + "date": "2020-11-11 21:02:11+00:00", + "text": "Doesn't matter too much. In case there is a fix required in this PR as well, updating the TOML-Fortran dependency is just a simple patch version bump:\ndiff --git a/fpm/fpm.toml b/fpm/fpm.toml\nindex fc3a381..404e65c 100644\n--- a/fpm/fpm.toml\n+++ b/fpm/fpm.toml\n@@ -8,7 +8,7 @@ copyright = \"2020 fpm contributors\"\n [dependencies]\n [dependencies.toml-f]\n git = \"https://github.com/toml-f/toml-f\"\n-tag = \"v0.2\"\n+tag = \"v0.2.1\"\n \n [dependencies.M_CLI2]\n git = \"https://github.com/urbanjost/M_CLI2.git\"" + }, + { + "user": "LKedward", + "date": "2020-11-12 08:52:32+00:00", + "text": "The fix isn't required for this PR and I have no preferred order of merging." + }, + { + "user": "milancurcic", + "date": "2020-11-12 19:05:32+00:00", + "text": "Sounds good, I will merge this." + } + ] + }, + { + "number": 228, + "user": "LKedward", + "date": "2020-11-06 08:37:35+00:00", + "title": "Implement [test.dependencies] and [executable.dependencies]", + "text": "Support for this manifest syntax was left out of #193.", + "comments": [] + }, + { + "number": 227, + "user": "awvwgk", + "date": "2020-11-04 21:17:16+00:00", + "title": "Create a specification for the command line interface", + "text": "To make clear what we expect from the command line interface we should create a specification of the current command line interface, similar to the specification for the manifest format. First, it allows to check for consistency for between the bootstrap and the Fortran version and gives a clear reference what to expect from an fpm implementation (of whatever kind). Also, it allows to propose new functionality independently of an implementation.\nGood material might be the dub or cargo reference\n\nhttps://dub.pm/commandline\nhttps://doc.rust-lang.org/cargo/commands/index.html\n\nThe format should probably be man page compatible, preferably markdown, such that we can include it on the online documentation with various tools (FORD, jekyll, ...) and also translate it to roff. I personally prefer asciidoc to write man pages, which is translatable to roff and compatible with jekyll but probably not with FORD.\nAny other opinion or suggestions on this?", + "comments": [ + { + "user": "LKedward", + "date": "2020-11-05 09:37:13+00:00", + "text": "Yes this is definitely needed; we have two slightly divergent CLIs currently. I don't have experience with asciidoc, but I agree that it would be good to have man page compatibility for this. I don't see FORD compatibility as a necessity for this." + }, + { + "user": "urbanjost", + "date": "2020-11-09 01:53:48+00:00", + "text": "I use txt2man(1) markup myself so I have not tried asciidoc although I have heard about it. In my own environment the manpage document is written as text blocks in the Fortran source file and extracted and usuallly also converted to comments or a text variable declaration by a preprocessor which works the way I like (documentation, Fortran source all in one file and automatically converted to roff and then (via man2html or groff) converted to HTML) but I don't expect the rest of the world to do that.\nThat being said, txt2man is widely available, simple, and works reasonably well for basic manpages. I keep meaning to make a Fortran program that is the equivalent but do not.\nThis is particularly apt as I was just going to open an issue and ask if we wanted to add a CLI option to specify custom compiler options like h-fpm recently added; but was thinking the syntax `fpm build -- -arg1 opt1 -arg2 -arg3... would be the easiest to implement and be a little easier to use but would be a different syntax for f-fpm than h-fpm. Wanted feedback on how people felt about it at all and what experiences everyone was having with the h-fpm version but the topics overlap; and at a minimum highlight the question of whether h-fpm and f-fpm need to stay in sync or not." + }, + { + "user": "urbanjost", + "date": "2020-11-09 03:15:28+00:00", + "text": "Note that fpm help manual writes out a file that was essentially written in txt2man markdown. Each help section was designed to be converted to roff via txt2man(1). The roff can then be converted to html, which can display on a github page if you turn on the doc section, or github markup allows you to put HTML into a md file by putting > source/greet_m.f90 \nfpm run\n\nThe last fpm run command will rebuild the library, but not the apps or tests.\nOutput\n\n~$ cd /tmp/\n/tmp$ git clone git@github.com:fortran-lang/fpm.git\nCloning into 'fpm'...\nremote: Enumerating objects: 206, done.\nremote: Counting objects: 100% (206/206), done.\nremote: Compressing objects: 100% (101/101), done.\nremote: Total 2830 (delta 114), reused 178 (delta 100), pack-reused 2624\nReceiving objects: 100% (2830/2830), 568.50 KiB | 1.49 MiB/s, done.\nResolving deltas: 100% (1569/1569), done.\n/tmp$ cd fpm/\n/tmp/fpm$ cd bootstrap/\n/tmp/fpm/bootstrap$ stack install\nDEPRECATED: The package at Repo from https://gitlab.com/everythingfunctional/hedge.git, commit 1c6cba3b5f8e52cf317f2421aaca13a0ddab4e92 in subdir . does not include a cabal file.\nInstead, it includes an hpack package.yaml file for generating a cabal file.\nThis usage is deprecated; please see https://github.com/commercialhaskell/stack/issues/5210.\nSupport for this workflow will be removed in the future.\n\nBuilding all executables for `fpm' once. After a successful build of all of them, only specified executables will be rebuilt.\nfpm> configure (lib + exe)\nConfiguring fpm-0.1.0.0...\nWarning: 'extra-source-files: ../README.md' is a relative path outside of the\nsource tree. This will not work when generating a tarball with 'sdist'.\nWarning: 'extra-source-files: ../ChangeLog.md' is a relative path outside of\nthe source tree. This will not work when generating a tarball with 'sdist'.\nfpm> build (lib + exe)\nPreprocessing library for fpm-0.1.0.0..\nBuilding library for fpm-0.1.0.0..\n[1 of 4] Compiling BuildModel\n[2 of 4] Compiling Build\n[3 of 4] Compiling Fpm\n[4 of 4] Compiling Paths_fpm\nPreprocessing executable 'fpm' for fpm-0.1.0.0..\nBuilding executable 'fpm' for fpm-0.1.0.0..\n[1 of 2] Compiling Main\n[2 of 2] Compiling Paths_fpm\nLinking .stack-work/dist/x86_64-linux/Cabal-2.4.0.1/build/fpm/fpm ...\nfpm> copy/register\nInstalling library in /tmp/fpm/bootstrap/.stack-work/install/x86_64-linux/624da27b4edec5b2a9682661e54b7da94a4de40ca862562a4526c1ddd57e9117/8.6.5/lib/x86_64-linux-ghc-8.6.5/fpm-0.1.0.0-ExRRX9W2aflLvTBBChPpxh\nInstalling executable fpm in /tmp/fpm/bootstrap/.stack-work/install/x86_64-linux/624da27b4edec5b2a9682661e54b7da94a4de40ca862562a4526c1ddd57e9117/8.6.5/bin\nRegistering library for fpm-0.1.0.0..\nCopying from /tmp/fpm/bootstrap/.stack-work/install/x86_64-linux/624da27b4edec5b2a9682661e54b7da94a4de40ca862562a4526c1ddd57e9117/8.6.5/bin/fpm to /home/lk12325/.local/bin/fpm\n\nCopied executables to /home/lk12325/.local/bin:\n- fpm\n\n\n/tmp/fpm$ cd ../example_packages/hello_complex\n/tmp/fpm/example_packages/hello_complex$ fpm run\n# gfortran (for build/gfortran_debug/hello_complex/source_subdir_constants.f90.o build/gfortran_debug/hello_complex/subdir_constants.mod)\n# gfortran (for build/gfortran_debug/hello_complex/source_farewell_m.f90.o build/gfortran_debug/hello_complex/farewell_m.mod)\n# gfortran (for build/gfortran_debug/hello_complex/source_greet_m.f90.o build/gfortran_debug/hello_complex/greet_m.mod)\n# ar (for build/gfortran_debug/hello_complex/libhello_complex.a)\nar: creating build/gfortran_debug/hello_complex/libhello_complex.a\n# gfortran (for build/gfortran_debug/apps/say_hello/apps_say_hello_say_Hello.f90.o)\n# gfortran (for build/gfortran_debug/apps/say_hello/say_Hello)\n# gfortran (for build/gfortran_debug/apps/say_goodbye/apps_say_goodbye_say_goodbye.f90.o)\n# gfortran (for build/gfortran_debug/apps/say_goodbye/say_goodbye)\n# gfortran (for build/gfortran_debug/tests/greet/tests_greet_greet_test.f90.o)\n# gfortran (for build/gfortran_debug/tests/greet/greet_test)\n# gfortran (for build/gfortran_debug/tests/farewell/tests_farewell_farewell_test.f90.o)\n# gfortran (for build/gfortran_debug/tests/farewell/farewell_test)\n Hello, World!\n Goodbye, World!\n/tmp/fpm/example_packages/hello_complex$ echo \"!\" >> source/greet_m.f90 \n/tmp/fpm/example_packages/hello_complex$ fpm run\n# gfortran (for build/gfortran_debug/hello_complex/source_greet_m.f90.o build/gfortran_debug/hello_complex/greet_m.mod)\n Hello, World!\n Goodbye, World!", - "comments": [] + "comments": [ + { + "user": "LKedward", + "date": "2020-11-01 15:08:27+00:00", + "text": "@everythingfunctional, are you able to look into this?" + }, + { + "user": "everythingfunctional", + "date": "2020-11-02 15:30:48+00:00", + "text": "I'm pretty sure I know exactly what happened. Forgot a need archives in the build rules. I'm super busy today, but I should have time tomorrow to fix it." + }, + { + "user": "everythingfunctional", + "date": "2020-11-03 22:57:11+00:00", + "text": "Also note, the build system is comparing file hashes for rebuilds, so adding a comment to the end of the file won't cause the .o or .mod files to be different, stopping the rebuild after that one step." + } + ] }, { "number": 221, "user": "everythingfunctional", "date": "2020-10-28 19:50:37+00:00", - "title": "WIP: Test and executable runner options", + "title": "Test and executable runner options", "text": "Allow a way of specifying a command to be used to run the executable(s) or test(s).\nAn example of where this might be particularly useful (practically necessary) is\nfpm test --runner \"valgrind --leak-check=full --error-exitcode=1\"\n\nto run the tests while looking for memory leaks.", "comments": [ { @@ -59,6 +1231,21 @@ "user": "urbanjost", "date": "2020-10-31 01:41:49+00:00", "text": "I keep running into cases where using xargs(1) makes it easier as not all commands take the filenames at the end.\nSince I do not know of an equivalent command to xargs(1) on non-GNU/Unix platforms (is there one?) I am wondering if something like the mask that you can do with xargs(1) would be useful, where if the --runner command has some special string in it like %FILE that gets replaced with the filename? This option allows for testing things that might become options like installing executables in a specified directory, listing app names when you have multiple ones, thinking about how profiling or debuggers might be incorporated, and so on. Would be useful to do on source files as well as executables. Works well in GNU/Unix \"toolbox\" environment, not sure if it works as well in MSWindows environment.\nfpm run --runner 'ls -l'\n fpm run --runner file\n fpm run --runner time\n fpm run --runner sum\n fpm run --runner 'valgrind --leak-check=full -s'\n# get list of pathnames\n fpm run --runner 'echo'\n# debugger\n fpm run --runner 'gdb'\n# combine echo and xargs\n fpm run --runner 'echo'|xargs -iXX cp XX /tmp/bin/\n# copy with name at end of command (people usually use \"cp FILE DIR/\")\n fpm run --runner 'cp --target-directory=/tmp/bin/ --update'\n# make nice little table of names that can be run or tested\n fpm test --runner echo|xargs -iXX basename XX|xargs -n 5|column -t\n# install binaries in specified directory\nfpm run --runner 'env VERSION_CONTROL=numbered install -D --owner=$LOGNAME --preserve-timestamps --backup --suffix=`date +%Y%M%D` --group=$(id -nG) --mode=0711 --target-directory=/tmp/bin/fpm --verbose --preserve-context'" + }, + { + "user": "everythingfunctional", + "date": "2020-11-02 20:12:08+00:00", + "text": "Yeah, I'm not totally enamored with the verbosity of having to specify every flag with --flag in front of it. I'm not sure exactly what the solution is yet though.\nFor recording compiler version and options, we could just put a log file at the base of the build directory that identifies them. Just printing the exact strings used to generate the hashes would probably be sufficient for most cases.\nfpm run A B C to specify multiple targets never worked, but I could definitely be persuaded to allow for multiple --target." + }, + { + "user": "everythingfunctional", + "date": "2020-11-12 19:00:23+00:00", + "text": "With #220 merged in, this is now ready as well. I don't think I've seen any significant objections, so I'd like to merge it sooner rather than later, but I'll give a day or two for anybody to take another look" + }, + { + "user": "everythingfunctional", + "date": "2020-11-16 17:56:21+00:00", + "text": "Having seen no objections, and indications that the Fortran version will soon have this same functionality, I'm going to go ahead and merge." } ] }, @@ -153,6 +1340,46 @@ "user": "awvwgk", "date": "2020-10-31 11:24:01+00:00", "text": "@everythingfunctional I created #223 to track the available compilers and their different flavours of command line flags." + }, + { + "user": "everythingfunctional", + "date": "2020-11-02 20:21:23+00:00", + "text": "I'm not particularly enamored with it either, since you're correct that it gets quite cumbersome, but I don't know of a much better solution. I don't think we want to specify them in the fpm.toml file until we've developed some compiler agnostic way of doing it, and know exactly how they interact between packages." + }, + { + "user": "ianabc", + "date": "2020-11-07 20:29:06+00:00", + "text": "This is exciting to see, passing multiple --flag options covers my use-case for now (coarrays)." + }, + { + "user": "awvwgk", + "date": "2020-11-09 09:07:32+00:00", + "text": "After looking around a bit I found cargo-rustc, I like the idea of cargo to separate a build and a compile mode, maybe we should copy this approach and implement a separate command (fpm compile?), which allows this for fpm, but leave the build command deterministic by only using arguments from the package manifest (see #112)." + }, + { + "user": "everythingfunctional", + "date": "2020-11-09 21:09:06+00:00", + "text": "@awvwgk , that's an interesting idea. However, we would need additional options to run and test to allow specifying that they run the version(s) built with such a command." + }, + { + "user": "everythingfunctional", + "date": "2020-11-09 23:45:49+00:00", + "text": "I've added the error check suggested regarding the mutually exclusive options, and done some refactoring to make it easier to add support for more compilers. I'll give everybody a few days to take another look, but I think with some support and approval already, this is ready to merge in." + }, + { + "user": "awvwgk", + "date": "2020-11-11 15:45:49+00:00", + "text": "However, we would need additional options to run and test to allow specifying that they run the version(s) built with such a command.\n\ncargo-rustc seems to implement run and test mode inside the rustc subcommand again to keep everything contained.\nAnother option might be to generate a lock file with the used compile flags which is also used for run and test if present, this requires to set the flags only once with build. Once the flags are changed in build the lock file will be updated as well.\nThe file could be something human-readable like TOML:\nfortran-compiler = \"gfortran\"\nfortran-compile-args = [\n \"-O3\",\n# ...\n]\nMaybe the lock file should be placed in the build directory? One should not be able to check it in into the version control system, I think." + }, + { + "user": "everythingfunctional", + "date": "2020-11-11 16:27:02+00:00", + "text": "I think having the compile (or some other name) subcommand reimplement build, test and run allowing flags would be the most self consistent and easiest to explain. I.e.\nfpm [compile [--flag FLAG]] build|run|test ...\n\nI don't like the idea of a lock file, as it introduces implicit, global state and makes it more complicated to explain. I.e.\n...\nfpm run\n...\nfpm run\n\nWithout knowing what the ...'s are, you don't know if the two invocations of fpm run will do the same thing.\nEither way I think it's something that should be explored in a future PR." + }, + { + "user": "everythingfunctional", + "date": "2020-11-12 18:09:06+00:00", + "text": "Without any other significant comments that I think need addressed here, and some requests from some people funding this effort to make it available, I'm going to go ahead and merge this now." } ] }, @@ -199,6 +1426,11 @@ "user": "LKedward", "date": "2020-10-28 10:32:36+00:00", "text": "Hi @rouson, it looks like you are referring to the bootstrap version. This functionality is available in the latest Fortran implementation - this is the version that is currently under continued development." + }, + { + "user": "rouson", + "date": "2020-11-06 03:10:36+00:00", + "text": "@LKedward @everythingfunctional I'm replacing CMake with fpm in the dag project and would like to update the list of prerequisites in our README.md, where it would be nice to write something like \"fpm version x.y.z or later\". Even without the fpm --version functionality mentioned in this issue, it would be great to create and tag releases for downstream documentation purposes." } ] }, @@ -347,6 +1579,36 @@ "user": "awvwgk", "date": "2020-10-17 11:20:25+00:00", "text": "https://github.com/Fortran-FOSS-Programmers/ford seems like the correct upstream for FORD, but the project looks discontinued. If this is the case, we probably have to workaround the bug ourselves or make an attempt to resume the maintenance of FORD." + }, + { + "user": "LKedward", + "date": "2020-11-04 15:09:39+00:00", + "text": "@awvwgk are you able to resolve the conflicts here and perhaps include the new manifest-reference in with the docs. After that I think it's ready to merge." + }, + { + "user": "awvwgk", + "date": "2020-11-04 16:22:54+00:00", + "text": "For reference, about the current status of FORD: Fortran-FOSS-Programmers/ford#317.\nUsing FORD for fpm will currently require some ugly fixes since the TOML array of tables will clash with the cross reference syntax. This might be a blocker for this PR until I figure a good way out to work around this issue. The respective bug is described here: Fortran-FOSS-Programmers/ford#309." + }, + { + "user": "LKedward", + "date": "2020-11-05 09:26:34+00:00", + "text": "This might be a blocker for this PR until I figure a good way out to work around this issue.\n\nIs 8030941 a sufficient workaround to merge this?" + }, + { + "user": "awvwgk", + "date": "2020-11-05 10:26:24+00:00", + "text": "@LKedward Yes, it fixes it by introducing whitespace around the header of the array of tables. It looks ugly in my opinion but is still valid TOML, so if everyone is fine with this solution we can go ahead and merge.\n-[[executable]]\n+[[ executable ]]" + }, + { + "user": "LKedward", + "date": "2020-11-05 11:06:50+00:00", + "text": "Yep, I'm happy with that solution. Having some kind of internal API documentation for developers plus specifications and user documentation on the web is important IMO." + }, + { + "user": "awvwgk", + "date": "2020-11-10 13:14:49+00:00", + "text": "I'll go ahead and merge this PR later today." } ] }, @@ -690,6 +1952,11 @@ "user": "awvwgk", "date": "2020-10-06 11:59:53+00:00", "text": "As a user I could perhaps be slightly annoyed by the manifest being re-formatted (especially for git diffs), but this is only a minor inconvenience.\n\nOne thing that would currently happen in this process is the conversion of all inline tables:\n [dependencies]\n-toml-f = { git = \"https://github.com/toml-f/toml-f\", tag = \"v0.2\" }\n+[dependencies.toml-f]\n+git = \"https://github.com/toml-f/toml-f\"\n+tag = \"v0.2\"\nBut I could adjust this in toml-f if you prefer to keep them (the information is there, but the serializer simply doesn't care).\nOne thing toml-f currently cannot do is preserve dotted keys:\n [dependencies]\n-toml-f.git = \"https://github.com/toml-f/toml-f\"\n+[dependencies.toml-f]\n+git = \"https://github.com/toml-f/toml-f\"\nAlso whitespace and comments are not preserved.\nIn case the package manifest is created with fpm new and managed with fpm add and so on, the diffs would always be minimal." + }, + { + "user": "awvwgk", + "date": "2020-11-30 18:02:19+00:00", + "text": "Closing this for now due to time constraints. I might give it a try at a later point again." } ] }, @@ -1923,6 +3190,31 @@ "user": "LKedward", "date": "2020-09-13 10:19:27+00:00", "text": "I like this idea! I have noticed the same thing while working with fpm, having to switch back and forth between two terminal panes when building. This is also exactly how git(1) works.\n\n... especially since each executable source has to be kept in a seperate directory.\n\nThere is discussion in #164 (Automatically discover tests and executables) to remove this restriction and further simplify user-effort." + }, + { + "user": "urbanjost", + "date": "2020-11-19 02:27:55+00:00", + "text": "This is trivial if CHDIR(3f) is supported. Note that a quick survey of three compilers (GCC/gfortran, Intel, PGI) shows all support a CHDIR(3f) extension; and it is easily supported via ISO_C_BINDING interfaces on POSIX machines. It almost certainly will be part of stdlib at some point. Since it is such a common extension, would greatly simplify implementation of the feature, and currently Fortran fpm is assumed to be being built with gfortran perhaps some of the gfortran POSIX-like extensions (in this case CHDIR(3f)) can be used directly?" + }, + { + "user": "arjenmarkus", + "date": "2020-11-19 07:53:53+00:00", + "text": "@martin Diehl and I are working on that sort of\nroutines, as part of stdlib-os. The complications are the Windows platform\nwhich consists actually of four different environments (plain Windows,\nCygwin, MinGW and MSYS). CHDIR is relatively simple, the main problem is\nunifying the build system (CMake based), such that we do not have to rely\non a preprocessor on the Fortran side. I intend to solve the immediate\nissue we now have today or within the next few days.\n\nOp do 19 nov. 2020 om 03:28 schreef urbanjost :\n\u2026\n This is trivial if CHDIR(3f) is supported. Note that a quick survey of\n three compilers (GCC/gfortran, Intel, PGI) shows all support a CHDIR(3f)\n extension; and it is easily supported via ISO_C_BINDING interfaces on POSIX\n machines. It almost certainly will be part of stdlib at some point. Since\n it is such a common extension, would greatly simplify implementation of the\n feature, and currently Fortran fpm is assumed to be being built with\n gfortran perhaps some of the gfortran POSIX-like extensions (in this case\n CHDIR(3f)) can be used directly?\n\n \u2014\n You are receiving this because you are subscribed to this thread.\n Reply to this email directly, view it on GitHub\n <#172 (comment)>,\n or unsubscribe\n \n ." + }, + { + "user": "MarDiehl", + "date": "2020-11-19 17:38:47+00:00", + "text": "@urbanjost: I agree with @arjenmarkus, relying on certain extensions is not a good long-term strategy. When os/os_path works on Windows (Cygwin, MinGW, and MSYS) and on POSIX (currently tested on Mac OS and Linux), it should be straight forward to include other system routines from C. We (i.e. mainly @arjenmarkus) almost found a suitable setup that works on all OS flavors." + }, + { + "user": "urbanjost", + "date": "2020-11-20 02:17:26+00:00", + "text": "I have a list of methods for handling platform-specific options. One of the easiest that does not require a preprocessor is to use a generic name like my_routine and then have a directory for each platform that has a source for my_routine. Instead of a preprocessor you just select the correct directory to build. If each solution contains very similar code or if there is a strong reason for keeping all the code in a single file a preprocessor can be more appropriate. I generally use POSIX platforms and have found the ISO_C_BINDING interface to work very well on Mac/CygWin/Unix/GNU-Linux; and in a few cases on windows I was able to make C routines that looked like the POSIX routines that called the MSWindows equivalents. I do not know of a public version of a POSIX look-alike for MSWindows like CygWin provides but that would be very useful if it exists.\nSome Fortran extensions are so common they are as standard as the standard implementation is itself; CHDIR seems to fall in or close to that. It would seem like a low maintenance issue to make a wrapper library that had something like STDLIB_CHDIR in it that called the vendor routine if it existed. If it did not call a ISO_C_BINDING to the POSIX routine if the platform is POSIX, and then a custom solution. In general it would seem reasonable to use vendor extensions if they exist behind such a wrapper and leave the maintenance to the compiler supplier." + }, + { + "user": "arjenmarkus", + "date": "2020-11-20 07:12:39+00:00", + "text": "Well, that is the solution we have chosen now: different source code,\nselected per platform, where CMake does the actual selection. So, we are\nworking along the same lines here - the details may differ, but that is all.\n\nOp vr 20 nov. 2020 om 03:17 schreef urbanjost :\n\u2026\n I have a list of methods for handling platform-specific options. One of\n the easiest that does not require a preprocessor is to use a generic name\n like my_routine and then have a directory for each platform that has a\n source for my_routine. Instead of a preprocessor you just select the\n correct directory to build. If each solution contains very similar code or\n if there is a strong reason for keeping all the code in a single file a\n preprocessor can be more appropriate. I generally use POSIX platforms and\n have found the ISO_C_BINDING interface to work very well on\n Mac/CygWin/Unix/GNU-Linux; and in a few cases on windows I was able to make\n C routines that looked like the POSIX routines that called the MSWindows\n equivalents. I do not know of a public version of a POSIX look-alike for\n MSWindows like CygWin provides but that would be very useful if it exists.\n\n Some Fortran extensions are so common they are as standard as the standard\n implementation is itself; CHDIR seems to fall in or close to that. It would\n seem like a low maintenance issue to make a wrapper library that had\n something like STDLIB_CHDIR in it that called the vendor routine if it\n existed. If it did not call a ISO_C_BINDING to the POSIX routine if the\n platform is POSIX, and then a custom solution. In general it would seem\n reasonable to use vendor extensions if they exist behind such a wrapper and\n leave the maintenance to the compiler supplier.\n\n \u2014\n You are receiving this because you were mentioned.\n Reply to this email directly, view it on GitHub\n <#172 (comment)>,\n or unsubscribe\n \n ." } ] }, @@ -3487,6 +4779,11 @@ "user": "awvwgk", "date": "2020-10-31 12:16:41+00:00", "text": "This might be fixed with #213." + }, + { + "user": "everythingfunctional", + "date": "2020-11-02 20:17:19+00:00", + "text": "Correct, the bootstrap version is no longer enforcing any match between module and source file name." } ] }, @@ -3531,6 +4828,11 @@ "user": "awvwgk", "date": "2020-10-31 12:17:27+00:00", "text": "This might be fixed with #213." + }, + { + "user": "everythingfunctional", + "date": "2020-11-02 20:18:31+00:00", + "text": "The bootstrap version is no longer enforcing any match between module and source file name." } ] }, @@ -3615,7 +4917,13 @@ "date": "2020-07-16 20:07:51+00:00", "title": "Allow to generate a standalone tarball with all dependencies", "text": "fpm should have a feature like fpm tarball --include-deps that will create a tarball of the current fpm package together with all dependencies and a build system such as CMake (#69), so that one can unpack this tarball at a machine without internet connection, and build everything from scratch (all the dependencies and the main application).\nThere are many usages of this feature:\n\nan application that must run on an HPC machine without internet connection, and I want to distribute it as a tarball that is built using cmake (a common expectation)\nfpm itself --- we can distribute fpm source code like this, and anybody with cmake can then build it from source (no other dependencies needed)", - "comments": [] + "comments": [ + { + "user": "awvwgk", + "date": "2020-11-22 08:28:51+00:00", + "text": "I was trying to figure out what it takes to implement a command like this, but there are a some things that are unclear. First, I would propose to name the command fpm dist rather than fpm tarball.\nThe second thing that comes to mind is, in case we use fpm dist --cmake and generate a CMake based build system, how do we make CMake fetch the dependencies? FetchContent works fine, but only if the upstream project supports CMake as well.\nOn solution would be to rely on a release artefact created by fpm and uploaded somewhere instead of the default git-archive.\nFinally, how do we handle the case of fpm dist --cmake --include-deps? Of course we can recursively generate the CMake files for all the projects and include them in a tarball, but some dependencies come with their own CMake files, would we overwrite (maybe with a fpm dist --cmake --include-deps --overwrite)?\nAs a note, in case anyone wants to give this a real try. Implementing a fpm dist --meson will probably be way less painful than implementing robust CMake." + } + ] }, { "number": 122, @@ -4108,6 +5416,41 @@ "user": "jerryd", "date": "2020-08-14 16:53:20+00:00", "text": "It seems the simplest way to do this would to have FPM check for an environment variable such as $FFLAGS and just substitute those in or use it to override the default flags. I have not looked at the FPM source code so I 'imagine' this would be straight forward to do" + }, + { + "user": "awvwgk", + "date": "2020-11-08 19:07:08+00:00", + "text": "Cargo uses profiles to define the compilation arguments: https://doc.rust-lang.org/cargo/reference/profiles.html\nWe could use a similar scheme to define arguments in fpm and make it extensible for additional compilation profiles (like coverage).\nJust as an example how the current release build mode could be expressed:\n[profile.release]\nfast-math = true\noptimization = 3\ndebug = false\nstandard = \"2008\"\nlto = false\npic = true\ncompile-args.gnu = [\"-funroll-loops\"] # compiler id required for specifying arguments?\nThe command line could allow a --profile key to reference a defined profile, with debug or development being the default and release being a special profile selected by the --release argument." + }, + { + "user": "urbanjost", + "date": "2020-11-09 01:06:39+00:00", + "text": "Yes. The package ideally has a self-contained definition file so when someone uses it as an external dependency it would build automatically so this seems like a good direction, but harder for Fortran than most other languages to implement.\nUsing switches on the command line is handy for a developer or someone not planning on distributing their package but is problematic otherwise, especially for anything that is intended to be used automatically as an external dependency by others.\nMulti-compiler support becomes difficult unless the keywords are something like a general name like \"coarray\" or \"X11\" and there are built-in defaults for how to implement that for each compiler, which quickly gets to be a maintenance problem past a few basic options. Just wondering if the configuration files should be able to be in separate files so they can be shared and reused easily. I would not say that should be mandatory; but an option.\nSo I am trying to picture when I am using a number of external dependencies and maybe a math library is using coarrays and a graphics package is using X11 libraries and a TUI interface is using ncurses. It seems like external \"system\" load options should be inherited by the apps by default for loading? It gets complicated because there are potentially many compilers with different options. It would be nice if we had a generic load script and compile script for Fortran that was standardized, but right now if I just had something that let me say for \"ifort\" add these load options, and for \"gfortran\", \"f90\", ... add these it would eliminate my need for a fpm.mk file for several packages, which would be nice.\nI could live with the top package having to specify all the options but it would require any external package that depends on \"system\" libraries to always require manual editing of the main project manifest.\nSo I think there are still issues but being able to specify options in the manifest file seems the right direction; and being to distinguish between optional and required options might allow \"required\" options to be inherited by the top package.\nMaybe just like you have to add a line in your manifest for a dependency the dependency might be able to specify options as well?" + }, + { + "user": "LKedward", + "date": "2020-11-09 08:54:42+00:00", + "text": "We could use a similar scheme to define arguments in fpm and make it extensible for additional compilation profiles (like coverage)\n\nYes, this is very much how I envisaged the problem to be solved. This allows us to support multiple compilers and handle flag compatibility between dependencies but without restricting the general user. I think this is the solution we should pursue for managing compilers and flags. Importantly this will allow us to get something general and flexible working; any issues surrounding particular flags and compilers can then be addressed on a case-by-case basis.\n\nIn addition to \"coverage\" the other profile I use often would, perhaps confusingly, be \"profile\" for performance profiling." + }, + { + "user": "awvwgk", + "date": "2020-11-14 15:39:40+00:00", + "text": "An alternative proposal, we already have the build table, so we could put it in here:\n[build.config.release]\noptimization = 3\ndebug = false\n\n[build.config.debug-optimized]\noptimization = 2\ndebug = true\n\n[build.config.debug]\noptimization = 0\ndebug = true\n\n[build.config.coverage]\noptimization = 0\ndebug = true\n\n[build.config.profile]\noptimization = 2\ndebug = false\nThe idea would be to create a table in build containing our compilation profiles. This is the scope I'm envisioning for now:\n\nthe profiles can have any name, fpm allows to select them at runtime\nfpm defines release and debug profiles for GCC (this set can be extended in future)\nany dependency not defining a named profile will inherit the profile from the dependent\ninheritance of profile options is defined on per option basis (optimization is handled different than fast-math, and so forth)\ncompiler-specific options should be discussed separately (see #223)\n\nI'm also looking for a better synonym of profile; config, option or setting would be possible. Any suggestions or preferences?" + }, + { + "user": "ivan-pi", + "date": "2020-11-23 00:05:10+00:00", + "text": "Just as an example how the current release build mode could be expressed:\n[profile.release]\nfast-math = true\noptimization = 3\ndebug = false\nstandard = \"2008\"\nlto = false\npic = true\ncompile-args.gnu = [\"-funroll-loops\"] # compiler id required for specifying arguments?\n\nI am not sure if the language standard makes sense as part of a profile." + }, + { + "user": "awvwgk", + "date": "2020-11-23 07:27:29+00:00", + "text": "I am not sure if the language standard makes sense as part of a profile.\n\nThere should be some way to specify it, in most projects I usually set the standard flag for debug builds and leave it out in the release, but specifying it globally in the [build] table would work as well." + }, + { + "user": "ivan-pi", + "date": "2020-11-27 11:19:02+00:00", + "text": "To aid the discussion I have tried to summarize some of the available optimization flags. Note that the specific optimizations will slightly differ between compilers. As a single example, to optimize for executable size, gfortran has the flag -Os, however the Intel documentation recommends using -O1.\n(perhaps this table can also be moved to a Wiki)\n\n\n\nFlag\ngfortran\nifort\nnagfor\nflang\nCray\nIBM\n\n\n\n\n-O\nequal to -O1\n/\nequal to -O2\nequal to -O2\n\nequal to -O2\n\n\n-O0\nno optimization (default)\nno optimization\nno optimization\ndisable optimization\ndisable optimization\ndisable optimization\n\n\n-O1\noptimize\noptimize for size\nminimal quick optimisation\nbetween -O0 and -O2\nconservative optimization\nno effect, reserved for future use\n\n\n-O2\noptimize even more\nmaximize speed (default)\nnormal optimisation (default)\nmoderate optimization\ndefault optimization\noptimize for performance\n\n\n-O3\noptimize yet more\nsimilar to -O2 with additional floating point optimizations\nfurther optimisation\nfull optimization\naggresive optimisation\nadditional optimization (similar to gfortran -Ofast)\n\n\n-O4\n/\n/\nmaximal optimisation\nreserved for future use\n/\naggresive optimization\n\n\n-O5\n/\n/\n/\n/\n/\nequal to -O4 with additional interprocedure analysis\n\n\n-Ofast\nsimilar to -O3 with unsafe math\n/\n/\nsimilar to -O3 with further math optimizations\n/\n/\n\n\n-fast\n/\nmaximize speed across entire program\n/\n/\n/\n/\n\n\n-Os\noptimize for size\n/\n/\nlike -O2 but reduces code size\n/\n/\n\n\n-Oz\n/\n/\n/\nlike -Os, but reduces code size further\n/\n/\n\n\n-Og\nturns on optimizations which do not interfere with debugging\n/\n/\n/\n/\n/\n\n\n\nSince we are limited by the available compilers for CI, I would suggest to only handle the -O0, -O1, -O2, and -O3 flags for now, which are common for most Fortran compilers." } ] }, @@ -4741,7 +6084,13 @@ "date": "2020-06-08 16:48:21+00:00", "title": "Implement a build script", "text": "I would do exactly what Cargo does: https://doc.rust-lang.org/cargo/reference/build-scripts.html\nOnly I would allow the build script to be any of: any binary, cmake, make, Bash script.\nOtherwise the following I would do exactly the same:\n\n\nInputs: environment variables\n\n\nOutputs: the build script prints to stdout with lines starting with fpm:, everything else is ignored. At the beginning, I would support the following, and we can add more later:\n\nfpm:fc-link-lib=[KIND=]NAME --- Adds a library to link (doc)\nfpm:fc-flags=FLAGS --- Passes certain flags to the compiler (doc).\n\nThat should be enough to get us started. One of the environment variables passed to the build script is which Fortran compiler is being used, so the build script would know what compiler parameters to pass back (for example ifort in general might require different flags than gfortran). In the same way, the flags might depend on the platform (macOS vs Linux vs Windows), so one of the input variables can be what platform we run on.", - "comments": [] + "comments": [ + { + "user": "ivan-pi", + "date": "2020-11-22 05:04:16+00:00", + "text": "I was taking a look at this after some related comments in #118 prompted my interest.\nIn Rust a crate called cc is used to automate the process of building C dependencies. The crate is organized around two structs, Build - used to specify project and compile options, Tool - used to represent the invocation of the C compiler:\npub struct Build {\n include_directories: Vec,\n definitions: Vec<(String, Option)>,\n objects: Vec,\n flags: Vec,\n flags_supported: Vec,\n known_flag_support_status: Arc>>,\n ar_flags: Vec,\n no_default_flags: bool,\n files: Vec,\n cpp: bool,\n cpp_link_stdlib: Option>,\n cpp_set_stdlib: Option,\n cuda: bool,\n target: Option,\n host: Option,\n out_dir: Option,\n opt_level: Option,\n debug: Option,\n force_frame_pointer: Option,\n env: Vec<(OsString, OsString)>,\n compiler: Option,\n archiver: Option,\n cargo_metadata: bool,\n pic: Option,\n use_plt: Option,\n static_crt: Option,\n shared_flag: Option,\n static_flag: Option,\n warnings_into_errors: bool,\n warnings: Option,\n extra_warnings: Option,\n env_cache: Arc>>>,\n apple_sdk_root_cache: Arc>>,\npub struct Tool {\n path: PathBuf,\n cc_wrapper_path: Option,\n cc_wrapper_args: Vec,\n args: Vec,\n env: Vec<(OsString, OsString)>,\n family: ToolFamily,\n cuda: bool,\n removed_args: Vec,\n}\nMost of the fields are self-explanatory. A few ideas that came to my mind upon looking into the Rust code:\n\nFortran has the intrinsic subroutine CALL GET_ENVIRONMENT_VARIABLE(NAME[, VALUE, LENGTH, STATUS, TRIM_NAME) which makes it easy to recover the environment variables.\nFor the same family of compilers, the compile flags for Fortran and C will be the same, meaning that the derived type representing the compiler invocation can be re-used for compiling both Fortran and C source files. (The Rust crate is not limited to C code, it can accept any source code that can be passed to a C or C++ compiler. As such, assembly files with extensions .s (gcc/clang) and .asm (MSVC) can also be compiled.)\nThe cc crate even supports a parallel build feature for C and Rust sources by setting up a job server. Within Fortran we could do something similar using co-arrays or OMP tasks (once dependencies like these are allowed). The feature is enabled conditionally, using the following TOML option:\n\n[build-dependencies]\ncc = { version = \"1.0\", features = [\"parallel\"] }" + } + ] }, { "number": 93, @@ -6022,6 +7371,11 @@ "user": "everythingfunctional", "date": "2020-03-31 13:52:31+00:00", "text": "You're right. I'm just going to leave out the options to specify compiler flags for now. Until we have time to design it properly." + }, + { + "user": "ivan-pi", + "date": "2020-11-23 01:13:31+00:00", + "text": "What I personally understand as a debug build is enabling (some of) the following options:\n\nGenerate debugging information (should be used with a lower optimization level)\n\ngfortran -g (use with -O0 or -Og)\nifort (Linux, macOS): -g[n], -debug\nifort (Windows) /Zi, /Z7\nNAG -g\n\n\nEnable backtrace of runtime errors\n\ngfortran -fbacktrace\nifort -traceback\nNAG -gline\n\n\nRun-time checks\n\ngfortran -fcheck=[all,array-temps,bits,bounds,do,mem,pointer,recursion]\nifort -check=[arg_temp_created,assume,bounds,contiguous,format,output_conversion,pointers,shape,stack,udio_iostat,uninit,all]\nNAG -C, -C=[alias,all,array,bits,calls,dangling,do,intovf,none,present,pointer,recursion,undefined]\n\n\n\nAdditionally, we could set flags related to handling floating-point exceptions as provided here (Intel) and here (gfortran)." } ] }, diff --git a/community/github_stats_data/data-fortran-lang-stdlib.json b/community/github_stats_data/data-fortran-lang-stdlib.json index edca31054..1ef44b768 100644 --- a/community/github_stats_data/data-fortran-lang-stdlib.json +++ b/community/github_stats_data/data-fortran-lang-stdlib.json @@ -1,6 +1,428 @@ { "name": "fortran-lang/stdlib", "issues": [ + { + "number": 255, + "user": "jvdp1", + "date": "2020-11-29 18:07:28+00:00", + "title": "Fix for a small issue in stdlib_logger", + "text": "", + "comments": [ + { + "user": "jvdp1", + "date": "2020-11-29 18:15:16+00:00", + "text": "@wclodius2 @milancurcic\nI discovered a small issue in stdlib_logger. I fixed it, and added some additional tests for covering them." + }, + { + "user": "wclodius2", + "date": "2020-11-29 18:27:55+00:00", + "text": "Great!" + }, + { + "user": "jvdp1", + "date": "2020-11-30 16:48:07+00:00", + "text": "Thank you for your reviews. I'll merge it." + } + ] + }, + { + "number": 254, + "user": "jvdp1", + "date": "2020-11-29 12:10:09+00:00", + "title": "stdlib_logger: proposition to add a logger for debug phases and levels among the different logs", + "text": "I am playing with stdlib_logger and I think it would be nice to have a subroutine for messages that should be printed only during debug phases.\nProposition\nlog_debug - Writes the string message to self % log_units\nSyntax\ncall self % log_debug( message [,module, procedure, stat, errmsg] )\nLog levels\nLog levels are used for filtering the messages based on their level/severity.\nEach subroutine log_error, log_information, log_io_error, log_text_error, log_warning, and the additional log_debug is associated with a level.\nFor example:\n\nlog_debug associated with debug_level\nlog_information associated with information_level\nlog_warning associated with warning_level\nlog_error, log_io_error, log_text_error associated with error_level\n\nwith debug_level < information_level < warning_level < error_level.\nSince log_message is called by all other log subroutines, it is probably best to not assign a level to log_message IMO.\nThe level of the logger should be set with the method configure, e.g. call self %configure( level = information_level), meaning that all calls with a level < information_level would be ignored.\nSuch log level options are avaible in Julia or Python loggers.\n@wclodius2 , @milancurcic , @14NGiestas , @ivan-pi , @certik is that of interests? any thoughs, comments?", + "comments": [ + { + "user": "wclodius2", + "date": "2020-11-29 15:34:55+00:00", + "text": "A few comments. This is really two separate proposals\" adding log_debug and adding level, and I think it would be best addressed by two separate PRs. Levels are also used by FLIBS (m_exception). On the other hand, Futility (exception_handler) has separate flags for each \"level\", so that you can output \"debug\" while not outputting \"information\" or \"warning\". Testing the effects of level will be tricky. How do you verify what is not output? log_text_error is different from the other error levels. It indicates a problem not with the application, but rather with a file being read by the application. I suspect its output should be independent of level. Overall I am in favor of adding log_debug, but worry that adding level will be a bit tricky." + }, + { + "user": "jvdp1", + "date": "2020-11-29 19:22:13+00:00", + "text": "A few comments. This is really two separate proposals\" adding log_debug and adding level, and I think it would be best addressed by two separate PRs.\n\nI agree with you that it should be two separate PR.\nRe: log_debug, its implementation is straighfoward. The main question is about its API. Should it be similar to e.g., log_information,\ncall self % log_debug( message [, module, procedure ] )\nHere is a draft of log_debug.\n\nLevels are also used by FLIBS (m_exception). On the other hand, Futility (exception_handler) has separate flags for each \"level\", so that you can output \"debug\" while not outputting \"information\" or \"warning\".\n\nThe proposed approach in this message is similar to Julia and Python loggers.\nHowever, the approach proposed of Futility (exception_handler) seem to be more flexible, but more difficult to implement and manage (even for the user).\nHere is a draft for a proposition similar to Julia and Python loggers.\nNote that the different default levels could be set by the user too.\n\nTesting the effects of level will be tricky. How do you verify what is not output?\n\nI don't understand that. For example, we could verify that a message is not printed to output_unit. Here is a proposition for testing the different options.\n\nlog_text_error is different from the other error levels. It indicates a problem not with the application, but rather with a file being read by the application. I suspect its output should be independent of level.\n\nRight. Default levels should be discussed first and set accordingly.\n\nOverall I am in favor of adding log_debug, but worry that adding level will be a bit tricky.\n\nI am not sure what is tricky with the option level (at least in the way I imagine it). I might miss something about the 'level' approach." + }, + { + "user": "wclodius2", + "date": "2020-11-30 03:10:37+00:00", + "text": "The draft and the proposition for testing look mostly reasonable. A few comments on it:\n\nThere is one case of \"...be NOT printed.\" that should be \"...NOT be printed.\"\nThe levels have the prefix \"stdlib_\" that I consider wordy and superfluous. I consider the stdlib_ prefix useful for avoiding naming conflicts between modules, but unnecessary for module entities. If you insist on a prefix I would make it \"log_\".\nIn the test code you use more vertical white space than I would now. I would not insert four blank lines to separate constructs. Because others objected to my inserting blank lines into my if ... then ... else ... end if, I no longer do that though you may be doing that to be consistent with my earlier style in the test code.\nThe if ( self % level > stdlib_..._level) return should have a blank between level and )." + } + ] + }, + { + "number": 253, + "user": "jvdp1", + "date": "2020-11-26 20:05:16+00:00", + "title": "Logger: move self%buffer and seld%len_buffer to local variables", + "text": "I was testing a multi-threading (OpenMP) program with global_logger inside an OpenMP loop. I got a segfault because a thread tried to allocate seld % buffer while it was already allocated by another thread.\nAs a solution, I moved the variables self % buffer and self % len_buffer into the subroutines log_messge and log_text_error. I believe that this solution has been already proposed in another discussion (I can't retrieve it).\nNote that this modification solves the problem of segfault, but it does not make the logger thread-safe. AFAIK, to be thread-safe, the logger (or the write statement inside the logger) should be in an OpenMP critical section.", + "comments": [ + { + "user": "jvdp1", + "date": "2020-11-26 20:06:28+00:00", + "text": "@wclodius2 do you see any possible problems I overlook with these modifications?" + }, + { + "user": "wclodius2", + "date": "2020-11-26 20:45:01+00:00", + "text": "Its a lot mom changes, but as they mostly involve removing self % they look straightforward. I don't see any problems. In the code not shown, any problems would probably show up with implicit none so I have strong confidence the code is correct. I suspect it is more robust than my code. Did you check the test cases?" + }, + { + "user": "wclodius2", + "date": "2020-11-26 23:29:31+00:00", + "text": "There are some points of style in the code. A lot of instances of self with intent(inout) should now be intent(in), i.e., in format_output_string and I believe all log_.... In format_output_string the type declaration statements for the dummy arguments should be in the order of the argument list. The document stdlib_logger.md should be revised to eliminate the references to buffer and len_buffer in the discussion of the derived type and the intents for self in the appropriate procedures should be revised." + }, + { + "user": "awvwgk", + "date": "2020-11-26 23:37:02+00:00", + "text": "I was testing a multi-threading (OpenMP) program with global_logger inside an OpenMP loop. I got a segfault because a thread tried to allocate seld % buffer while it was already allocated by another thread.\n\nThis is kind of a pity with OpenMP, a derived type with allocatable members seems to get memcopied if it is set to firstprivate, resulting in private copies for each thread potentially pointing to the same the location. The only safe way I found so far working with a mutable derived type was to have it shared and read-only, while deep-copying it manually to a private instance in the OpenMP region, which is kind of a waste.\nOpenACC has a mechanism to copyin components of derived types explicitly, but I'm not aware of a similar mechanism in OpenMP.\n\nNote that this modification solves the problem of segfault, but it does not make the logger thread-safe. AFAIK, to be thread-safe, the logger (or the write statement inside the logger) should be in an OpenMP critical section.\n\nThe OpenMP critical should probably be provided on the user side of the API to ensure that two independent loggers don't block each other. If stdlib wants to handle the thread-safety itself, than it probably has to create an OpenMP mutex for each unit connected to the logger, but I'm not sure if this can be done with a normal OpenMP critical region (have to read the specs again)." + }, + { + "user": "jvdp1", + "date": "2020-11-27 06:30:43+00:00", + "text": "Thank you for your reviews. Indeed, many intent(inout) should be modified and the specs should be adapted as well. I will do it.\nNow done in:\ncommit\nand\ncommit" + }, + { + "user": "jvdp1", + "date": "2020-11-27 07:52:55+00:00", + "text": "@awvwgk Thank you for your comments.\n\nThis is kind of a pity with OpenMP, a derived type with allocatable members seems to get memcopied if it is set to firstprivate, resulting in private copies for each thread potentially pointing to the same the location. The only safe way I found so far working with a mutable derived type was to have it shared and read-only, while deep-copying it manually to a private instance in the OpenMP region, which is kind of a waste.\n\nI usually avoid to use (first/last)private for large arrays or derived types (too often bitten with stack memory issues, and issues similar to the one you mentioned). I prefer deep-copying and explicit allocation of copies.\nWith the proposed changes (and the logger being unmutable in the OpenMP parallel region), the following OpenMP code should work without issues:\n use stdlib_logger, only: logger_type, global => global_logger, success\n !$ use omp_lib\n implicit none\n integer :: i, ithread, nthreads, stat\n character(len = 30) :: cdummy, cdummy1\n type(logger_type), allocatable :: logger(:)\n\n call global % add_log_file( 'log_file_omp.txt')\n\n nthreads = 1\n !$omp parallel\n !$ nthreads = omp_get_num_threads()\n !$omp end parallel\n\n write(cdummy, '(i0)') nthreads\n\n ithread = 1\n cdummy = 'master'\n !$omp parallel default(none) &\n !$omp shared(global) &\n !$omp private(i, ithread, cdummy, cdummy1)\n !$omp do\n do i = 1, 100 \n !$ ithread = omp_get_thread_num()+1\n !$ write(cdummy, '(i0)') ithread\n write(cdummy1, '(i0)') i\n !$omp critical\n call global % log_message('Thread : ' // trim(cdummy) //&\n ' | i = ' // trim(cdummy1))\n !$omp end critical\n end do\n !$omp end do\n !$omp end parallel\nend program\nThe user could omit the OpenMP critical section but this could lead to overwritting.\nQuestion: should such an example be provide in the specs?\n\nThe OpenMP critical should probably be provided on the user side of the API ...\n\nI agree with this statement. My main reason is that there are several ways for multi-thread programming. Controlling it outside stdlib does not enforce the user to use a specific approach to be thread-safe.\n\n... to ensure that two independent loggers don't blog each other. If stdlib wants to handle the thread-safety itself, than it probably has to create an OpenMP mutex for each unit connected to the logger, but I'm not sure if this can be done with a normal OpenMp critical region (have to read the specs again).\n\nNamed OpenMP critical section could be used (e.g. 1 named critical section per unit connected to the logger). But, as stated earlier, I don't think it should be the way to go." + }, + { + "user": "awvwgk", + "date": "2020-11-27 08:24:40+00:00", + "text": "Named OpenMP critical section could be used (e.g. 1 named critical section per unit connected to the logger). But, as stated earlier, I don't think it should be the way to go.\n\nOpenMP critical (even with named sections) will not work correctly, maybe the hint-expression introduced in OpenMP 4.5 could solve this issue, but I have not tried them yet (some compiler vendors only support OpenMP 3.x yet). You would have to go for managing an array of locks to make this possible." + }, + { + "user": "jvdp1", + "date": "2020-11-27 10:18:25+00:00", + "text": "Named OpenMP critical section could be used (e.g. 1 named critical section per unit connected to the logger). But, as stated earlier, I don't think it should be the way to go.\n\nOpenMP critical (even with named sections) will not work correctly, maybe the hint-expression introduced in OpenMP 4.5 could solve this issue, but I have not tried them yet (some compiler vendors only support OpenMP 3.x yet). You would have to go for managing an array of locks to make this possible.\n\nIndeed, you are right. Thank you for your comment." + }, + { + "user": "jvdp1", + "date": "2020-11-28 12:31:44+00:00", + "text": "With 4 reviewers agreeing with the changes, I will merge this PR. Thank you all for your reviews and comments." + } + ] + }, + { + "number": 252, + "user": "jvdp1", + "date": "2020-11-25 06:59:55+00:00", + "title": "Issue with logger s configuration subroutine", + "text": "@wclodius2\nI found a small issue within stdlib_logger. If the subroutine configuration is called and no units are associated with the logger, self % log_units is not allocated, and leads to a segfault (in debug mode) when the program tries to use it for allocating log_units.\nWith my proposition, log_units will be a zero-sized array in such situations (as it is tested like that in the tests).", + "comments": [ + { + "user": "wclodius2", + "date": "2020-11-25 14:15:59+00:00", + "text": "@jvdp1 the two changes look good to me. Sorry for missing that problem." + }, + { + "user": "wclodius2", + "date": "2020-11-25 14:35:14+00:00", + "text": "It looks to me like your changes are for a PR against the master, and not against logger-safe-async-io. I don't believe I have write access to the master repository so I can't do a merge there. Do you want me to copy the changes to logger-safe-async-io and we just do a merge of that, or did you have other ideas?" + }, + { + "user": "jvdp1", + "date": "2020-11-25 14:40:52+00:00", + "text": "It looks to me like your changes are for a PR against the master, and not against logger-safe-async-io. I don't believe I have write access to the master repository so I can't do a merge there. Do you want me to copy the changes to logger-safe-async-io and we just do a merge of that, or did you have other ideas?\n\nThank you for the approcal.\nSince it is a small change and that it is not related to logger-safe-async-io, I will merge it in master.\nAnyway, I can open a PR to logger-safe-async-io if you want, but I don't think it is needed at this stage." + }, + { + "user": "wclodius2", + "date": "2020-11-25 14:51:02+00:00", + "text": "Will git pull https://github.com/fortran-lang/stdlib merge your changes into my local version of logger-safe-async-io so it can them be pushed?" + }, + { + "user": "jvdp1", + "date": "2020-11-25 17:15:50+00:00", + "text": "Will git pull https://github.com/fortran-lang/stdlib merge your changes into my local version of logger-safe-async-io so it can them be pushed?\n\nIn you local directory, you could do:\ngit checkout logger-safe-async-io\ngit fetch upstream master #assuming upstream points to github.com/fortran-lang/stdlib\ngit merge --no-ff upstream/master\ngit push origin logger-safe-async-io" + }, + { + "user": "wclodius2", + "date": "2020-11-25 19:33:49+00:00", + "text": "git merge --no-ff upstream/master\n\ngives me\nmerge: upstream/stdlib - not something we can merge" + }, + { + "user": "jvdp1", + "date": "2020-11-25 19:43:20+00:00", + "text": "It seems you tried:\n\ngit merge --no-ff upstream/stdlib\n\n\ninstead of\n\n\ngit merge --no-ff upstream/master\n\n\n\n\nLe mer. 25 nov. 2020 \u00e0 20:34, William B. Clodius \na \u00e9crit :\n\u2026\n git merge --no-ff upstream/master\n\n gives me\n\n merge: upstream/stdlib - not something we can merge\n\n \u2014\n You are receiving this because you modified the open/close state.\n Reply to this email directly, view it on GitHub\n <#252 (comment)>,\n or unsubscribe\n \n ." + }, + { + "user": "wclodius2", + "date": "2020-11-25 19:49:30+00:00", + "text": "All of the following gives the same result\nstdlib % git merge --no-ff upstream/master\nmerge: upstream/master - not something we can merge\n\ngit merge --no-ff https://github.com/fortran-lang/stdlib/master\nmerge: https://github.com/fortran-lang/stdlib/master - not something we can merge\n\ngit merge --no-ff https://github.com/fortran-lang/stdlib \nmerge: https://github.com/fortran-lang/stdlib - not something we can merge\n\ngit merge --no-ff github.com/fortran-lang/stdlib/master \nmerge: github.com/fortran-lang/stdlib/master - not something we can merge" + }, + { + "user": "jvdp1", + "date": "2020-11-25 20:04:21+00:00", + "text": "All of the following gives the same result\nstdlib % git merge --no-ff upstream/master\nmerge: upstream/master - not something we can merge\n\ngit merge --no-ff https://github.com/fortran-lang/stdlib/master\nmerge: https://github.com/fortran-lang/stdlib/master - not something we can merge\n\ngit merge --no-ff https://github.com/fortran-lang/stdlib \nmerge: https://github.com/fortran-lang/stdlib - not something we can merge\n\ngit merge --no-ff github.com/fortran-lang/stdlib/master \nmerge: github.com/fortran-lang/stdlib/master - not something we can merge\n\n\nIs upstream associated with www.github.com/fortran-lang/stdlib ? What does git remote -v return?" + }, + { + "user": "wclodius2", + "date": "2020-11-25 20:06:17+00:00", + "text": "git remote -v\norigin\thttps://github.com/fortran-lang/stdlib (fetch)\norigin\thttps://github.com/fortran-lang/stdlib (push)\nwilliam\tgit@github.com:wclodius2/stdlib.git (fetch)\nwilliam\tgit@github.com:wclodius2/stdlib.git (push)" + }, + { + "user": "jvdp1", + "date": "2020-11-25 20:09:35+00:00", + "text": "git remote -v\norigin\thttps://github.com/fortran-lang/stdlib (fetch)\norigin\thttps://github.com/fortran-lang/stdlib (push)\nwilliam\tgit@github.com:wclodius2/stdlib.git (fetch)\nwilliam\tgit@github.com:wclodius2/stdlib.git (push)\n\n\nOk. I understand. Your origin is what I call upstream. The following should work:\ngit checkout logger-safe-async-io\ngit fetch origin master\ngit merge --no-ff origin/master\ngit push william logger-safe-async-io" + }, + { + "user": "wclodius2", + "date": "2020-11-25 20:16:38+00:00", + "text": "Thanks its merged into logger-safe-async-io now." + } + ] + }, + { + "number": 251, + "user": "jvdp1", + "date": "2020-11-24 20:58:30+00:00", + "title": "Update links in stdlib_bitsets to navigate easily from specs to code (and vice versa)", + "text": "The following has been done:\n\n\nSpecs: Correction of some FORD links + typos\n\n\ncode: addition of links to the specs for easier navigation", + "comments": [ + { + "user": "jvdp1", + "date": "2020-11-28 12:30:08+00:00", + "text": "I'll merge this PR. It is mainly addition of link and correction of typos." + } + ] + }, + { + "number": 250, + "user": "14NGiestas", + "date": "2020-11-23 05:22:14+00:00", + "title": "Fixes CI failing on MacOS", + "text": "This fixes the MacOS CI issue, updating the gcc version to the right one.", + "comments": [ + { + "user": "milancurcic", + "date": "2020-11-23 15:50:01+00:00", + "text": "It seems to work, thank a lot! I will merge it." + } + ] + }, + { + "number": 249, + "user": "awvwgk", + "date": "2020-11-22 21:28:58+00:00", + "title": "Support for Intel oneAPI compilers", + "text": "I just tried to setup a CI for the Intel oneAPI compilers for stdlib and noticed that src/tests/io/test_savetxt.f90 is triggering an ICE in ifort (see https://github.com/awvwgk/fortran-stdlib/runs/1439256395) and src/stdlib_ascii.f90 is triggering an ICE in the ifx compiler (see https://github.com/awvwgk/fortran-stdlib/runs/1439276984).\nI have seen there are compile issues with PGI/NVHPC, NAG and flang already for stdlib. Does this mean stdlib currently only supports GCC?", + "comments": [ + { + "user": "ivan-pi", + "date": "2020-11-22 21:41:10+00:00", + "text": "The ifx error is not very informative:\n/home/runner/work/fortran-stdlib/fortran-stdlib/src/stdlib_ascii.f90(73): catastrophic error: **Internal compiler error: internal abort** Please report this error along with the circumstances in which it occurred in a Software Problem Report. Note: File and line given may not be explicit cause of this error." + }, + { + "user": "ivan-pi", + "date": "2020-11-22 21:48:01+00:00", + "text": "The NAG issues were partially related to CMake - #108 - however, I am not sure if it was resolved. Presumably, PGI will also have issues with submodules, error stop, and other F2018 features.\nThe short answer to your question is yes." + }, + { + "user": "awvwgk", + "date": "2020-11-22 21:48:35+00:00", + "text": "I've never seen an informative ICE so far. Unfortunately, I don't have a local Intel oneAPI installation on my machine (yet), so I wasn't able to pin it down to a more specific part in the implementation. At least with Intel Parallel Studio stdlib builds just fine, so this seems to be Intel oneAPI specific." + }, + { + "user": "jvdp1", + "date": "2020-11-22 22:13:06+00:00", + "text": "Does this mean stdlib currently only supports GCC?\n\nI always try to compile stdlib with gfortran (9.3.1) and Intel ifort (19.1.1), and until now, it was always fine. I got some issues with one of the first versions of ifort 2017, but it has been solved with an update of ifort.\n@awvwgk Which version of ifort did you use?\nI didn't test Intel oneAPI yet." + }, + { + "user": "awvwgk", + "date": "2020-11-22 22:17:16+00:00", + "text": "On my local machine, I use Intel Parallel Studio 2020, Update 2 (ifort 19.1.1.217 20200306), which seems to work just fine.\nOn the CI example it should be Intel oneAPI 2021.1 beta10, ifort 20.2.1.20200827, ifx 2019.0.0.20201005 (?)." + }, + { + "user": "milancurcic", + "date": "2020-11-22 23:49:37+00:00", + "text": "On my laptop (Ubuntu 20.04) I have ifort (IFORT) 2021.1 Beta 20200827 (from oneAPI) and it doesn't ICE until compiling the tests:\n/home/milan/Work/fortran/stdlib/src/tests/io/test_savetxt.f90: catastrophic error: **Internal compiler error: segmentation violation signal raised** Please report this error along with the circumstances in which it occurred in a Software Problem Report. Note: File and line given may not be explicit cause of this error." + }, + { + "user": "milancurcic", + "date": "2020-11-22 23:52:54+00:00", + "text": "nvfortran 20.9-0 doesn't implement real128 yet:\n$ FC=nvfortran cmake .. -DCMAKE_MAXIMUM_RANK=4\n-- The Fortran compiler identification is PGI 20.9.0\n-- Check for working Fortran compiler: /opt/nvidia/hpc_sdk/Linux_x86_64/2020/compilers/bin/nvfortran\n-- Check for working Fortran compiler: /opt/nvidia/hpc_sdk/Linux_x86_64/2020/compilers/bin/nvfortran -- works\n-- Detecting Fortran compiler ABI info\n-- Detecting Fortran compiler ABI info - done\n-- Checking whether /opt/nvidia/hpc_sdk/Linux_x86_64/2020/compilers/bin/nvfortran supports Fortran 90\n-- Checking whether /opt/nvidia/hpc_sdk/Linux_x86_64/2020/compilers/bin/nvfortran supports Fortran 90 -- yes\n-- Performing Test f18errorstop\n-- Performing Test f18errorstop - Success\n-- Performing Test f03rank\n-- Performing Test f03rank - Failed\n-- Performing Test f03real128\n-- Performing Test f03real128 - Failed\n-- Configuring done\n-- Generating done\n-- Build files have been written to: /home/milan/Work/fortran/stdlib/build" + } + ] + }, + { + "number": 248, + "user": "milancurcic", + "date": "2020-11-22 18:19:48+00:00", + "title": "Revert \"Bitsets3\" to diagnose CI issues", + "text": "Reverts #239\nThis PR is to diagnose CI issue in #247. It should not be merged.", + "comments": [] + }, + { + "number": 247, + "user": "milancurcic", + "date": "2020-11-22 16:51:20+00:00", + "title": "CI failure for macos-latest, 8", + "text": "CI is failing for macos-latest, 8 as of the last merge into master (#239). See https://github.com/fortran-lang/stdlib/runs/1438725329.\nI have re-run the CI jobs to make sure the same error repeats. The error comes from a symbol missing in one of the shared libraries:\ndyld: lazy symbol binding failed: Symbol not found: ___addtf3\n Referenced from: /Users/runner/work/stdlib/stdlib/build/src/tests/quadrature/test_trapz\n Expected in: /usr/lib/libSystem.B.dylib\n\nThe same error repeats for several other tests that rely on this symbol. Others are okay.\nI have no knowledge of macOS so I'm not sure where to start with this one.", + "comments": [ + { + "user": "certik", + "date": "2020-11-22 17:11:37+00:00", + "text": "Can you try to send a drFt PR reverting the last merge and see if it fixes the CI? It might not even be related to the last merge.\n\u2026\nOn Sun, Nov 22, 2020, at 9:51 AM, Milan Curcic wrote:\n\n\n CI is failing for macos-latest, 8 as of the last merge into master\n (#239 <#239>). See\n https://github.com/fortran-lang/stdlib/runs/1438725329.\n\n I have re-run the CI jobs to make sure the same error repeats. The\n error comes from a symbol missing in one of the shared libraries:\n\n `dyld: lazy symbol binding failed: Symbol not found: ___addtf3\n Referenced from:\n /Users/runner/work/stdlib/stdlib/build/src/tests/quadrature/test_trapz\n Expected in: /usr/lib/libSystem.B.dylib\n `\n The same error repeats for several other tests that rely on this\n symbol. Others are okay.\n\n I have no knowledge of macOS so I'm not sure where to start with this one.\n\n \u2014\n You are receiving this because you are subscribed to this thread.\n Reply to this email directly, view it on GitHub\n <#247>, or unsubscribe\n ." + }, + { + "user": "Romendakil", + "date": "2020-11-22 18:08:06+00:00", + "text": "That symbol should be part of libgcc_s.1.dylib, maybe a problem with the brewed gcc/gfortran-8?" + }, + { + "user": "milancurcic", + "date": "2020-11-22 18:24:33+00:00", + "text": "@certik To confirm, I did what you suggested in #248." + }, + { + "user": "certik", + "date": "2020-11-22 18:30:10+00:00", + "text": "Thanks Milan. It looks like the error is indeed unrelated to the latest merge and rather is caused by some changes in the CI itself as Jurgen pointed out.\n\u2026\nOn Sun, Nov 22, 2020, at 11:24 AM, Milan Curcic wrote:\n\n\n @certik To confirm, I did what you\n suggested in #248 <#248>.\n\n \u2014\n You are receiving this because you were mentioned.\n Reply to this email directly, view it on GitHub\n <#247 (comment)>, or unsubscribe ." + }, + { + "user": "14NGiestas", + "date": "2020-11-23 05:35:14+00:00", + "text": "It was just a matter of updating the links as the warning said in the \"Install Gfortran on MacOS\" task.\nI've fixed in #250\nEDIT: The warning was hidden in the task. Is there a way to make such warnings appear in github's output?" + }, + { + "user": "milancurcic", + "date": "2020-11-23 15:54:15+00:00", + "text": "Fixed by #250." + } + ] + }, + { + "number": 246, + "user": "14NGiestas", + "date": "2020-11-16 22:18:32+00:00", + "title": "Small fix to issue #245", + "text": "It seems the command set-env is deprecated (since it is exploitable), so the Ford CI is failing.\nI believe this small fix solves the issue: GH Workflow environment files", + "comments": [ + { + "user": "milancurcic", + "date": "2020-11-16 22:24:17+00:00", + "text": "Great, thank you! Do you mind also submitting one to fpm, see here?" + }, + { + "user": "14NGiestas", + "date": "2020-11-16 22:25:45+00:00", + "text": "Great, thank you! Do you mind also submitting one to fpm, see here?\n\nGladly :D" + }, + { + "user": "milancurcic", + "date": "2020-11-16 22:26:49+00:00", + "text": "This is a small technical change that seems to fix the problem, so I will go ahead and merge it." + } + ] + }, + { + "number": 245, + "user": "wclodius2", + "date": "2020-11-16 20:45:17+00:00", + "title": "Logger safe async io", + "text": "Changes in four files:\n\ndoc/specs/index.md - added stdlib_logger.html to the index;\ndoc/specs/stdlib_logger.md - described the changes in stdlib_logger.f90;\nsrc/tests/logger/test-stdlib_logger.f90 - added a blank after a comma in the output;\nsrc/stdlib_logger.f90 - numerous changes\n\nthe code handles new_line calls in the message string properly (added by @jvdp1, but undocumented in stdlib_logger.md)\na character string buffer was added to logger_type and alen_buffer integer to track the number of active characters in the buffer;\nthe code replaced multiple calls to write statements with single calls with line breaks generated by inserting new_line in the output string, in order to make the output thread and asynchronous IO safe;\nshortened a number of lines most of them 80+ characters long\nchanged Rrea_only_error to read_only_error", + "comments": [ + { + "user": "milancurcic", + "date": "2020-11-16 22:18:31+00:00", + "text": "@14NGiestas if your fix for docs build works, can you submit it as a separate PR? Then we can merge it and rebase this PR to master so that the docs build." + }, + { + "user": "14NGiestas", + "date": "2020-11-16 22:21:52+00:00", + "text": "@14NGiestas if your fix for docs build works, can you submit it as a separate PR? Then we can merge it and rebase this PR to master so that the docs build.\n\nIt is already a separate PR #246. I'm just waiting the CI to finish." + }, + { + "user": "wclodius2", + "date": "2020-11-18 00:12:06+00:00", + "text": "I have committed and pushed fixes for the unit = -999 and the potentially too short suffix in both log_error and log_io_error." + }, + { + "user": "jvdp1", + "date": "2020-11-22 17:33:51+00:00", + "text": "Do you expect that this is async I/O safe also for SPMD programs using MPI or coarrays? Specifically, in a pattern where multiple processes are logging to the same file, or stdout. Granted, a safer programming pattern in this case would be for each process to write to its own dedicated logger file. Should we make note of this in the docs?\n\nWould an OpenMP do loop with a logger do the trick? I have a similar example in one of my codes, however I put the logger in a critical OMP section with the first implementation." + }, + { + "user": "wclodius2", + "date": "2020-11-22 17:52:26+00:00", + "text": "While a test would be useful I don't know how to write it. Parallel programming was not in demand for my work. In particular, how do we ensure that asynchronous calls aren't accidentally synchronous? Do we want to special case the cmake compiler flags and Makefile.manual flags for stdlib_logger.f90 and test_stdlib_logger.f90?\nA note to the effect of \"While every effort has been made to make the code thread and asynchronous I/O safe, it is always best to have each process write to its own dedicated logger file\" might be useful.\nOn a related note, should I add an asynchronous argument to the subroutine add_log_file?" + }, + { + "user": "jvdp1", + "date": "2020-11-23 19:28:57+00:00", + "text": "While a test would be useful I don't know how to write it. Parallel programming was not in demand for my work. In particular, how do we ensure that asynchronous calls aren't accidentally synchronous? Do we want to special case the cmake compiler flags and Makefile.manual flags for stdlib_logger.f90 and test_stdlib_logger.f90?\n\nCould such a test be satisfying, assuming that most compilers support basic OpenMP directives?\n...\ntype(logger_type) :: logger\ncharacter (len = 30) :: cdumy\n...\n\ncall logger % add_log_file( 'log.txt')\ncall logger % configure(indent = .true., time_stamp = .true.)\n....\n!$omp parallel default(none) shared(logger)\n!$omp do\ndo i = 1, 100\n !$ write(cdummy, '(i0)') omp_get_thread_num()\n !$omp atomic\n call logger % log_message( ' Message from thread '//trim(cdummy) )'\nenddo\n!$omp end do\n!$omp end parallel\n....\nSuch a test would be more about thread then asynchronous safety.\nTo \"mimick\" MPI, an array of loggers could be used, and each thread would used its own logger.\nHowever, what/how should be tested to have a proper test?\n\nA note to the effect of \"While every effort has been made to make the code thread and asynchronous I/O safe, it is always best to have each process write to its own dedicated logger file\" might be useful.\n\nIMO it is a good idea to add it in the specs, especially if we claim it should asynchornous/thread/process-safe.\n\nOn a related note, should I add an asynchronous argument to the subroutine add_log_file?\n\nIt would be good indeed. Probably it is best to do it in another PR independent from this one." + }, + { + "user": "milancurcic", + "date": "2020-11-23 21:20:32+00:00", + "text": "A note to the effect of \"While every effort has been made to make the code thread and asynchronous I/O safe, it is always best to have each process write to its own dedicated logger file\" might be useful.\n\n@wclodius2, I agree. Do you mind adding this note in the spec document where you find it most appropriate?\nI think this will then be good to merge." + }, + { + "user": "wclodius2", + "date": "2020-11-24 01:15:40+00:00", + "text": "I have added the sentence to stdlib_logger.md just before the note at the end of the introduction.\n@jvdp1 I have no experience with Open MP. My gut feeling is that an additional test wouldn't hurt, but it should probably be written by you as a separate PR. Things to think about if you should decide to do it.\n\nIt appears that compiling with gfortran for open MP requires the compiler flag -fopenmp. Would that flag apply to the library as a whole or just the test code?\nDo you envision the code as a separate \"application\" or part of the current test case?\nI find going through a hundred lines of output a bit daunting. Would ten lines be a sufficient test?" + }, + { + "user": "14NGiestas", + "date": "2020-11-24 06:48:53+00:00", + "text": "Does this PR handles access to the buffer from different threads? Because having a buffer string without guarding the critical region does not guarantee one thread will not overwrite the buffer while the other thread was writing. I need to review the code to better understand that, but I belive It's up to the user put the logger call in a guarded region (omp critical, for e.g.)." + }, + { + "user": "jvdp1", + "date": "2020-11-24 07:47:24+00:00", + "text": "@wclodius2 I will propose another test later, when this is merged.\n\nDoes this PR handles access to the buffer from different threads? Because having a buffer string without guarding the critical region does not guarantee one thread will not overwrite the buffer while the other thread was writing. I need to review the code to better understand that, but I belive It's up to the user put the logger call in a guarded region (omp critical, for e.g.).\n\nGood point. No, there is no guarding within stdlib_logger that different threads access to the buffer at the same time (that is why I set it in an atomic section in the example above). We could add orphaned OpenMP directives in stdlib_logger. However, as @14NGiestas , I would think it is up to the user to put the logger call in a guarded region. In that case, a sentence in the specs should be added for multi-thread programs.\nNote that this issue should not apppear in MPI/coarray-type programs." + }, + { + "user": "wclodius2", + "date": "2020-11-24 16:59:31+00:00", + "text": "@14NGiestas FWIW the string buffer is in a logger object, and not a module variable. With a little extra work it could be made a procedure variable." + }, + { + "user": "wclodius2", + "date": "2020-11-24 19:03:24+00:00", + "text": "FWIW with my latest push five of six CI/Builds passed. The one that failed \"CI / Build (macos-latest, 9) (pull_request)\" failed in running test_stdlib_bitset_large with a file read error. It passes that test on my system with gfortran 10.2." + }, + { + "user": "jvdp1", + "date": "2020-11-24 21:09:41+00:00", + "text": "FWIW with my latest push five of six CI/Builds passed. The one that failed \"CI / Build (macos-latest, 9) (pull_request)\" failed in running test_stdlib_bitset_large with a file read error. It passes that test on my system with gfortran 10.2.\n\nI tested it on my computer (Fedora) with gfortran 9.3.1, and there were no issues.\nI rerun the tests, but they still failed." + }, + { + "user": "wclodius2", + "date": "2020-11-24 23:18:22+00:00", + "text": "FWIW the Mac OS run that fails uses gfortran 9.3.0. It fails with an unexpected End-of-File, which I have trouble understanding as I would expect that error to occur only if there were a coding error that affects all runs. A glance at the code in stdlib_bitsets_large.f90 and test_stdlib_bitset_large.f90 doesn't show anything wrong with the pertinent sections of code. Further, CI / Build (ubuntu-latest, 9) also uses gfortran 9.3.0 and passes the tests. Maybe it is a bad disk sector involving the source code. I hate boggles!" + }, + { + "user": "jvdp1", + "date": "2020-11-25 07:20:54+00:00", + "text": "FWIW the Mac OS run that fails uses gfortran 9.3.0. It fails with an unexpected End-of-File, which I have trouble understanding as I would expect that error to occur only if there were a coding error that affects all runs. A glance at the code in stdlib_bitsets_large.f90 and test_stdlib_bitset_large.f90 doesn't show anything wrong with the pertinent sections of code. Further, CI / Build (ubuntu-latest, 9) also uses gfortran 9.3.0 and passes the tests. Maybe it is a bad disk sector involving the source code. I hate boggles!\n\nI tested it again on my computer with different compilers and debug options. It always passed the tests! So no idea..." + } + ] + }, + { + "number": 244, + "user": "wclodius2", + "date": "2020-11-16 13:14:54+00:00", + "title": "Logger2 - Changes mostly to make output thread and Asynchronous iO safe", + "text": "Changed three files:\n\n/src/stdlib_logger.f90\n\nFixed typos: Rrea_only_error to read_only_error, shortened lines to under 80 columns\nMade output thread and asynchronous IO safe by making it a single string formatted using the new_line function\n\n\n/doc/specs/stdlib_logger.md documented the changes in API in stdlib_logger.f90\n/doc/specs/index.md included the logger in the index.", + "comments": [ + { + "user": "jvdp1", + "date": "2020-11-16 16:43:35+00:00", + "text": "Thanks @wclodius2 for this PR. It seems that the branch logger2 is on top of bitset3, which makes things difficult to review. Would it be possible to rebase logger2 on master? @certik @milancurcic any tips on how to this?" + }, + { + "user": "milancurcic", + "date": "2020-11-16 17:34:51+00:00", + "text": "Assuming upstream is https://github.com/fortran-lang/stdlib and origin is git@github.com:wclodius2/stdlib (if using SSH keys auth) or https://github.com/wclodius2/stdlib (if using password auth), then in William's local git repo, I think this is the procedure:\ngit checkout master # go to master branch in the local repo\ngit fetch upstream # fetch updates from the remote repo (fortran-lang/stdlib)\ngit merge upstream/master # merge updates into local master\ngit checkout -b logger-safe-async-io # create and switch to the new branch\n# make changes to the files\ngit add && git commit -m \"commit message\" # for each meaningful unit of change\ngit push origin logger-safe-async-io" + }, + { + "user": "milancurcic", + "date": "2020-11-16 22:19:39+00:00", + "text": "Closing in favor of #245" + } + ] + }, { "number": 243, "user": "jvdp1", @@ -12,6 +434,61 @@ "user": "jvdp1", "date": "2020-10-30 18:08:28+00:00", "text": "I add @wclodius2 as a reviewer" + }, + { + "user": "jvdp1", + "date": "2020-11-01 14:41:45+00:00", + "text": "@jvdp1:\nIt looks like you did some revisions before adding me as a reviewer so I am missing some context. My idea, when I suggested using new_line, was to recursively insert new_line in a single character string at the points where we had breaks in write statements, and use that string for a single write to each file. This would have changed format_output_string from a procedure that performs writes to one that returns output string. You seem to be going for a more incremental approach.\n\nAll changes can be found here.\nI am not sure to understand what was your approach. Sorry.\nMy idea was to lead the logger writes something like:\nERROR: Possibles reasons:\n 1) first reason\n 2) second reason\n\nwith\ncall global%log_error('Possible reasons'//new_line('a')//'1) first reason'//new_line('a')//'2) second reason')\nTherefore, the user puts some formatting in the message.\nWas it your aim too?" + }, + { + "user": "jvdp1", + "date": "2020-11-01 16:24:24+00:00", + "text": "Here is an additional example of what should be nice to achieve:\n\ncode:\n\n call global % log_message(&\n 'Example of an issue: the new_line() is considered as a character:' // &\n new_line('a')// &\n ' -1) first bullet point: this is a long sentence on purpose. It should' // &\n 'be longer than 72 characters;'//new_line('a') // &\n ' -2) second bullet point' ) \n\nHere is the current output (without the proposed changes):\n\n2020-11-01 17:18:03.241: Example of an issue: the new_line() is\n considered as a character:\n -1) first bullet point: this is a long\n sentence on purpose. It should be longer than 72 characters;\n -2)\n second bullet point\n\n\nHere is the output with the proposed changes:\n\n2020-11-01 17:23:07.982: Example of an issue: the new_line() is\n considered as a character:\n -1) first bullet point: this is a long sentence on purpose. It\n should be longer than 72 characters;\n -2) second bullet point" + }, + { + "user": "wclodius2", + "date": "2020-11-01 17:40:02+00:00", + "text": "The output as shown looks very good. My one concern is what might happen if the output unit is asynchronous. In that case the output from different write statements to the same unit might become separated by writes from other parts of the code. This is not a new problem. It was inherent in my original approach. A way around that is to write the output initially to a single string, inserting new_line for the formatting, and then output that string with a single write to each output unit. It becomes a bit tricky with new_line already in the input string, but I think it is doable. Why don't you continue to make the changes you want to get the formatting for your inputs. Then, after you commit your changes to the main branch, I start a new branch to implement the single output string using your mods as a guide for the treatment of new_line in the input string." + }, + { + "user": "jvdp1", + "date": "2020-11-01 19:45:14+00:00", + "text": "My one concern is what might happen if the output unit is asynchronous. In that case the output from different write statements to the same unit might become separated by writes from other parts of the code. This is not a new problem. It was inherent in my original approach. A way around that is to write the output initially to a single string, inserting new_line for the formatting, and then output that string with a single write to each output unit. It becomes a bit tricky with new_line already in the input string, but I think it is doable.\n\nThis issue was indeed present before the proposed changes. Note that the new_line is already provided by the user in the string. Therefore, I guess it could be considered as a character (as any other ones).\n\nWhy don't you continue to make the changes you want to get the formatting for your inputs. Then, after you commit your changes to the main branch, I start a new branch to implement the single output string using your mods as a guide for the treatment of new_line in the input string.\n\nNice proposition. I believe I finished my changes and it is ready for reviewers. I tested them in a real program with several scenarios, and I was satisfied with the output. Hopefully I covered all possible scenarios." + }, + { + "user": "wclodius2", + "date": "2020-11-02 00:34:37+00:00", + "text": "Outside of the two minor comments, the code looks good to me." + }, + { + "user": "jvdp1", + "date": "2020-11-02 15:19:55+00:00", + "text": "Outside of the two minor comments, the code looks good to me.\n\nI will wait that other users review the proposed changes too." + }, + { + "user": "milancurcic", + "date": "2020-11-13 18:00:55+00:00", + "text": "Please merge if/when ready." + }, + { + "user": "jvdp1", + "date": "2020-11-13 19:45:59+00:00", + "text": "Please merge if/when ready.\n\nThanks for the final review. With 3 reviewers, I will now merge it." + }, + { + "user": "jvdp1", + "date": "2020-11-13 20:01:46+00:00", + "text": "I used it mainly in one of our Fortran programs and was in overal pleased by this implementation.\n\nA way around that is to write the output initially to a single string, i\n\n@wclodius2 are you still interested in implementing such a proposition?\nWhile using the logger, I got the following situation:\n...some code...\ncall global%log_message('Initial value is: '//value2char(rdummy)\n...some code...\ncall global%log_message('New value is: '//value2char(rdummy)\n...some code...\nIt would have been nice to have something like:\n...some code...\ncall global%append_to_buffer_message('Initial value is: '//value2char(rdummy))\n...some code...\ncall global%appent_to_buffer_message('New value is: '//value2char(rdummy))\n...some code...\ncall global%log_message() !write he buffer to file unit(s), and initialise the buffer to''\nThis is probably further than your initial thoughs" + }, + { + "user": "wclodius2", + "date": "2020-11-13 20:20:27+00:00", + "text": "Yes it is further than my initial thoughts, which was to make the code thread/asynchronous IO \"safe\". I could do what you want as part of my rewrite, but what you are proposing has some ambiguities. In the appended strings what would you want done with date/time, module/procedure? What should be the formatting of the appended string?" + }, + { + "user": "jvdp1", + "date": "2020-11-14 18:46:16+00:00", + "text": "Yes it is further than my initial thoughts, which was to make the code thread/asynchronous IO \"safe\". I could do what you want as part of my rewrite, but what you are proposing has some ambiguities. In the appended strings what would you want done with date/time, module/procedure? What should be the formatting of the appended string?\n\nI would expect that date/time/module/procedure woud be initialized once when the string is still empty. Additional appended strings would not contain this information. It might be no sense, and could be considered later if others are interested.\nAt this stage, I think it is more important to have a code thread/asynchronous IO safe." } ] }, @@ -50,7 +527,93 @@ "date": "2020-10-27 19:14:26+00:00", "title": "Include a `split` function (202X feature)", "text": "Fortran 202X will include a new intrinsic split function:\nj3-fortran/fortran_proposals#187\nIt was approved, and then the API was changed after approving it. We should implement the latest approved version in stdlib, and play with it and ensure that the API looks good. And if we discover some improvements, we should propose them at the February 2021 Fortran Standards meeting.\nThen once split becomes part of the next Fortran standard, we can have a section in stdlib called \"backwards compatibility\", where we can have a \"reference implementation\" of such new features, so that people can use them right away even if some compiler might not support them yet.", - "comments": [] + "comments": [ + { + "user": "milancurcic", + "date": "2020-11-01 01:44:15+00:00", + "text": "I put an implementation here: https://github.com/milancurcic/fortran202x_split.\nThis is a \"naive\" implementation--I went for what seemed to me as the simplest solution. The split_first_last specific subroutine, which is the second form listed in 20-139, does much of the grunt work. I wrote it in a mostly functional style, so it does some unnecessary copies that we may want to refactor in an imperative style.\nFor tests so far I only used the three examples from 16.9.194 in 20-007. They seem okay. More tests will be needed at the time of PR for stdlib.\nAt this time, I'd like to get feedback on this before I prepare a PR for stdlib." + }, + { + "user": "jvdp1", + "date": "2020-11-06 21:15:11+00:00", + "text": "Thank you for the implementation. I played a bit with it and it looks good to me. The API seemed a bit strange at the start.\nI wonder if the version with pos is not a bit overlapping with the intrinsic function index (note: I understand that this is a implementation of the proposed standard)" + }, + { + "user": "certik", + "date": "2020-11-06 21:48:55+00:00", + "text": "@jvdp1 thanks for the feedback. That is precisely why I suggested we do this, to get more experience about the API and perhaps propose some changes to it before it gets standardized. @jvdp1 how would you change the API to be more natural?" + }, + { + "user": "milancurcic", + "date": "2020-11-07 01:01:33+00:00", + "text": "Here's my impression of the API.\n\nInput dummy argument set is a scalar character string that contains all separators to be used for delimiting tokens. For example, if you pass \";, \" as a value of set, then any of these characters will be used for delimiting. In this current definition, I don't think it's possible to delimit using a multiple-character string, although I can't think of a use case for this. It seems to me that a more intuitive API would be for set to be an array of characters, so:\n\ncharacter, intent(in) :: set(:)\ninstead of\ncharacter(*), intent(in) :: set\nThen you'd pass it as [\";\", \",\", \" \"] instead of \";, \". But this is I think more a matter of style than anything else.\n\nI found the API to be idiomatic Fortran--subroutines with intent(in out) arguments for output--which is not in itself a bad thing and helps minimize unnecessary copies. I only wish there was also a convenience function for when a user only wants the tokens as a result and nothing else, and doesn't mind an extra copy. The interface would look like this:\n\npure function split(string, set) result(tokens)\n character(*), intent(in) :: string\n character(*), intent(in) :: set\n character(:), allocatable :: tokens(:)\nand then you call it like this:\ntokens = split(string, set)\nwhich would allow a more functional style by passing split(string, set) as an argument to other functions.\nSo, to that end, I'd propose that in the stdlib we also include this 4th specific procedure, even if it ends up being non-standard, or an extension. So we'd have a total of 4 forms of split:\n\nsubroutine split(string, set, tokens, separator)\nsubroutine split(string, set, first, last)\nsubroutine split(string, set, pos, back)\nfunction split(string, set)" + }, + { + "user": "ivan-pi", + "date": "2020-11-07 11:45:10+00:00", + "text": "Unfortunately in Fortran you can not force functions and subroutines under the same interface. So the last split has to be named differently." + }, + { + "user": "milancurcic", + "date": "2020-11-07 11:52:39+00:00", + "text": "Yes, I remembered this rule later. If people desire this as a function, maybe string_tokens, or strtok to mirror the C analog." + }, + { + "user": "jvdp1", + "date": "2020-11-08 16:25:39+00:00", + "text": "@jvdp1 thanks for the feedback. That is precisely why I suggested we do this, to get more experience about the API and perhaps propose some changes to it before it gets standardized. @jvdp1 how would you change the API to be more natural?\n\nFirst I expected a function (similar to scan that has a similar interface (scan(string, set [,back [,kind]]). I was thus a bit surprised that it was a subroutine. However it does make sense with the different ouputs.\nSecond, I don't see the value of the return value pos, if you can get separator, or first. (Maybe efficiency?) I must miss something there (note that I didn't read all the discussions about this proposition). Furthermore this version of split is quite similar to the intrinsic function index.\nFinally, I was wondering why last was not optional. Isn't it that last(1:ntokens-1)=fist(2:ntokens)-1 (or somehting like that)? Do I miss something?\nAnyway, this version would be already a great addition in stdlib and later in the Standard." + }, + { + "user": "milancurcic", + "date": "2020-11-09 06:06:36+00:00", + "text": "Yes, pos is useful for efficiency if you're searching for a delimiter at a specific position in the string. Both other forms parse the whole string.\nYou can't predict the values of last based on values of first because if token(n) is an empty string, last(n) is first(n)-1." + }, + { + "user": "certik", + "date": "2020-11-09 06:32:34+00:00", + "text": "We should also do comparisons with Python and other languages, as we usually do for stdlib.\n\u2026\nOn Sun, Nov 8, 2020, at 11:06 PM, Milan Curcic wrote:\n\n\n Yes, `pos` is useful for efficiency if you're searching for a delimiter\n at a specific position in the string. Both other forms parse the whole\n string.\n\n You can't predict the values of `last` based on values of `first`\n because if `token(n)` is an empty string, `last(n)` is `first(n)-1`.\n\n \u2014\n You are receiving this because you authored the thread.\n Reply to this email directly, view it on GitHub\n <#241 (comment)>, or unsubscribe ." + }, + { + "user": "milancurcic", + "date": "2020-11-09 19:48:47+00:00", + "text": "Similar capability in other languages:\n\nC and C++ strtok\nPython split\nJulia split\nMATLAB strsplit\nGo split\nRust split" + }, + { + "user": "milancurcic", + "date": "2020-11-09 19:59:19+00:00", + "text": "The key differences seem to be:\n\nBehavior of the separator. Fortran split works like that of C and C++ strtok (multiple characters in a string are possible separators), whereas in Python, Julia, MATLAB, and Go, the whole delimiter string is used as a single delimiter. Rust's delimiter allows specifying a pattern. For a few of these implementations, delimiter defaults to an empty space if omitted;\nResult value. Fortran split updates the in out argument in-place. strtok returns a pointer to the beginning of the tokens sequence. Others simply return a list or array of strings as function result.\nUnlike others, Fortran split allows returning first and last indices instead of tokens. If this functionality exists in other languages, it's defined in some other function. So, Fortran here packs multiple functionalities under one name, a design that I'm not fond of, but can get used to it." + }, + { + "user": "certik", + "date": "2020-11-10 00:10:49+00:00", + "text": "Thanks @milancurcic, very helpful, exactly what I was looking for. The first example:\nhttps://github.com/milancurcic/fortran202x_split/blob/a49ccf5b0775732cc4d1087c71fd513d4e921a6a/test/main.f90#L13\nI think is natural. That corresponds to the function split_tokens:\nhttps://github.com/milancurcic/fortran202x_split/blob/a49ccf5b0775732cc4d1087c71fd513d4e921a6a/src/fortran202x_split.f90#L14\nSo I think I like the API of split_tokens.\nI am not a fond of bundling the other functionality into the same split overload.\nIn terms of usability, I think the split_tokens will be the most useful and helpful. The other split_first_last and split_pos might not be as useful, it's hard to tell. I would feel much better if they could be used in stdlib in the experimental section first and see." + }, + { + "user": "jvdp1", + "date": "2020-11-10 13:45:07+00:00", + "text": "I am also not fond of the current API, but even like that, it would be a nice addition.\nI would suggest to add the current version in the experimental namespace of stdlib, such that people can test it." + }, + { + "user": "milancurcic", + "date": "2020-11-11 00:20:02+00:00", + "text": "I added the string_tokens function which is a thin wrapper around split_tokens.\nThis allows the user to do:\ntokens = string_tokens(string, set)\nThere is also a simple benchmark program in app/main.f90 to compare the run-time between string_tokens function and the equivalent split_tokens subroutine, given a decent size input string (data included in the repo). On my laptop:\n$ fpm run\n split subroutine, elapsed 0.482727677 seconds\n string_tokens function, elapsed 0.565418363 seconds" + }, + { + "user": "jvdp1", + "date": "2020-11-11 06:21:43+00:00", + "text": "Thank you @milancurcic for the function and the test. Can the difference be explained by calling the subroutine inside the function? Or was the subroutine inlined in the function?" + }, + { + "user": "milancurcic", + "date": "2020-11-11 15:49:39+00:00", + "text": "The subroutine is not inlined:\n pure function string_tokens(string, set) result(tokens)\n !! Splits a string into tokens using characters in set as token delimiters.\n character(*), intent(in) :: string\n character(*), intent(in) :: set\n character(:), allocatable :: tokens(:)\n call split_tokens(string, set, tokens)\n end function string_tokens\nbut it allocates the function result before returning it to the caller. It's this extra allocation that makes the difference.\nThere is probably some minimal overhead with calling the subroutine, but it should be negligible." + }, + { + "user": "jvdp1", + "date": "2020-11-18 06:39:33+00:00", + "text": "A long discussion on the split function was held during the Fortran Monthly call (November 2020) (from5:39)." + } + ] }, { "number": 240, @@ -112,7 +675,7 @@ { "user": "peteroupc", "date": "2020-10-22 04:15:10+00:00", - "text": "Just for your information you should use algorithms avoiding floating-point arithmetic when possible (or at least make such implementations an option). For example, there are algorithms of the exponential distribution that use comparisons only (von Neumann's method, for one) as well as exact samplers of the Binomial distribution (e.g., Farach-Colton and Tsai, \"Exact Sublinear Binomial Sampling\"; the \"Internal DLA\" paper by Bringmann and others). Even the Poisson distribution can be sampled without using the exponential function (e.g. \"On Buffon Machines and Numbers\"). Perhaps the most familiar example of a distribution of this kind is the discrete (and continuous) normal distribution sampler by Karney. See also my section on \"Specific Non-Uniform Distributions\" in \"Randomization and Sampling Methods\".\nIn fact, as the authors of \"Exact Sublinear Binomial Sampling\" found, BTPE can oversample the tail of a binomial distribution (or at least the GNU Scientific Library implementation of BTPE at the time of the paper can)." + "text": "Just for your information you should use algorithms avoiding floating-point arithmetic when possible (or at least make such implementations an option). For example, there are algorithms of the exponential distribution that use comparisons only (von Neumann's method, for one) as well as exact samplers of the Binomial distribution (e.g., Farach-Colton and Tsai, \"Exact Sublinear Binomial Sampling\"; the \"Internal DLA\" paper by Bringmann and others). Even the Poisson distribution can be sampled without using the exponential function (e.g. \"On Buffon Machines and Numbers\"). Perhaps the most familiar example of a distribution of this kind is the discrete (and continuous) normal distribution sampler by Karney. See also my section on \"Specific Non-Uniform Distributions\" in \"Randomization and Sampling Methods\".\nIn fact, as the authors of \"Exact Sublinear Binomial Sampling\" found, BTPE can oversample the tail of a binomial distribution (or at least the GNU Scientific Library implementation of BTPE at the time of the paper can).\nFor a simpler description of the Bringmann algorithm, see my page \"Miscellaneous Observations on Randomization\"." }, { "user": "Jim-215-Fisher", @@ -217,6 +780,31 @@ "user": "wclodius2", "date": "2020-10-21 02:20:49+00:00", "text": "@jvdp1 thanks for the thorough review." + }, + { + "user": "wclodius2", + "date": "2020-11-13 18:52:02+00:00", + "text": "A bit set for each index `bit` in the range `0\u2026bits-1` has a value of 0 or 1. A value of 1 for index `bit` can be considered as including the `bit` value in the subset, i.e., the value `1110` can be considered as defining the subset (1, 2, 3). This was how Wirth defined sets in Pascal.\n\u2026\n On Nov 13, 2020, at 11:42 AM, Milan Curcic ***@***.***> wrote:\n\n\n @milancurcic commented on this pull request.\n\n In doc/specs/stdlib_bitsets.md <#239 (comment)>:\n\n > +equivalently be considered as a sequence of logical values or as a\n +subset of the integers 0 ... `bits-1`. The bits are indexed from 0 to\n or as a subset of the integers 0 ... bits-1.\n\n This confuses me. The equivalent integer values are 0 and 1, not 0 through bits-1, correct?\n\n Do you mean to say something like this?\n\n \"It can equivalently be considered as a sequence of logical values or as a sequence of integers 0 and 1 with indices in the range 0... bits-1?\"\n\n \u2014\n You are receiving this because you were mentioned.\n Reply to this email directly, view it on GitHub <#239 (review)>, or unsubscribe ." + }, + { + "user": "milancurcic", + "date": "2020-11-13 18:59:28+00:00", + "text": "Okay, thanks, I understand now. All good." + }, + { + "user": "milancurcic", + "date": "2020-11-13 19:02:45+00:00", + "text": "Your example \"i.e., the value 1110 can be considered as defining the subset (1, 2, 3)\" was what made it click for me. Do you agree that we include it in the spec? Something like this:\n\"It can equivalently be considered as a sequence of logical values or as a subset of the integers 0 ... bits-1. For example, the value 1110 can be considered as defining the subset of integers [1, 2, 3].\"" + }, + { + "user": "wclodius2", + "date": "2020-11-13 19:04:57+00:00", + "text": "Sounds good to me." + }, + { + "user": "milancurcic", + "date": "2020-11-22 15:38:48+00:00", + "text": "I will go ahead and merge this considering there aren't any objections. Thank you @wclodius2 and all the reviewers." } ] }, @@ -250,6 +838,11 @@ "user": "jvdp1", "date": "2020-09-29 18:49:30+00:00", "text": "As mentioned in this comment, I copied your branch in my repo, and all actions passed.\nIMO, the best thing to do is to close #236 and open a new and clean PR, as explained in this comment" + }, + { + "user": "wclodius2", + "date": "2020-11-16 21:25:44+00:00", + "text": "I am now getting a similar sounding error, but the detailed error reported by \"View workflow run\" is different\n1\nRun sed -i .bak 's/^[[:blank:]]*graph: *[Tt]rue/graph: false/' \"${FORD_FILE}\"\n19\nError: Unable to process command '::set-env name=MAYBE_SKIP_SEARCH::--no-search' successfully.\n20\nError: The set-env command is disabled. Please upgrade to using Environment Files or opt into unsecure command execution by setting the ACTIONS_ALLOW_UNSECURE_COMMANDS environment variable to true. For more information see: https://github.blog/changelog/2020-10-01-github-actions-deprecating-set-env-and-add-path-commands/\nIt appears that GitHub has deprecated a sed command (set-env) that FORD processing currently uses." } ] }, @@ -293,6 +886,21 @@ "user": "ivan-pi", "date": "2020-09-25 20:02:08+00:00", "text": "Suggestion for further improvement: allow to_lower and to_upper to convert strings of arbitrary length - this seems to me to be the most common usage.\n\nThis has been requested as part of the strings module. I have wondered already if it would be easier to just have a single function with the interface:\npure function upper(str) result(ustr)\ncharacter(len=*), intent(in) :: str\ncharacter(len=len(str)) :: ustr\nend function\nand get rid of the single character case conversions entirely. As you say, the most common usage will be arbitrary length strings, so I am not sure if we need a specialization for single letters. The arbitrary length version can be used on single characters too (hopefully the compilers are capable enough to remove the loop for characters with len=1).\nThe reason I included the case conversions in the first plase was just to cover the same functionality as the header file from C." + }, + { + "user": "milancurcic", + "date": "2020-11-12 20:56:24+00:00", + "text": "@arjenmarkus @ivan-pi @14NGiestas Is this PR good to go or should this comment still be addressed?" + }, + { + "user": "arjenmarkus", + "date": "2020-11-13 14:51:10+00:00", + "text": "Argh, I had intended to rely to these remarks, but never got around to it. I agree: in C the situation is completely different - there are characters and there are arrays of characters. In Fortran we have character strings but not a separate character type. The suggested interface (and almost trivial implementation) looks good to me." + }, + { + "user": "milancurcic", + "date": "2020-11-13 15:07:03+00:00", + "text": "Okay, I will merge this then. The suggested interface can go in as a new PR." } ] }, @@ -1844,6 +2452,11 @@ "user": "wclodius2", "date": "2020-09-30 03:00:46+00:00", "text": "I have created a PR for a branch called bitsets3. The PR had one one that failed on ubuntu, out of six attempts, three on ubuntu and three on macOS.." + }, + { + "user": "wclodius2", + "date": "2020-11-02 03:23:07+00:00", + "text": "At this point @jvdp1 has performed an extensive review of the code, and @14NGiestas has commented on some parts of it It would be useful if someone else also extensively reviewed the code." } ] }, @@ -7403,6 +8016,31 @@ "user": "scivision", "date": "2020-01-14 16:48:13+00:00", "text": "Until PGI 19.4, PGI struggled with Fortran 2003 and 2008 is really buggy if there at all. 19.10 was the first PGI that was usable with Fortran 2008 syntax in my opinion." + }, + { + "user": "awvwgk", + "date": "2020-11-22 22:19:33+00:00", + "text": "I just tested NVHPC 20.9 and it still fails to compile stdlib, with roughly the same errors as already highlighted in this issue." + }, + { + "user": "Romendakil", + "date": "2020-11-22 22:45:01+00:00", + "text": "Our code never worked with NVHPC or its predecessor PGI. There were so many errors already at the level of F2003 code. And it really compiles a factor 3-5 slower than ifort.\n\nI just tested NVHPC 20.9 and it still fails to compile stdlib, with roughly the same errors as already highlighted in this issue." + }, + { + "user": "scivision", + "date": "2020-11-23 18:53:13+00:00", + "text": "Since Intel oneAPI:\n\nhas \"complete\" Fortran 2018 support\nis free to use (not just for education as with prior license)\ngenerally has better performance than PGI/NVHPC for CPU tasks\n\nand since as above PGI/NVHPC still has trouble with Fortran 2003 support, I don't really consider using it in my work. Those who need to use NVHPC for GPU are already stuck with Fortran 95 syntax and stdlib would, in my opinion, become significantly more of a maintenance burden and more heavily reliant on preprocessors." + }, + { + "user": "awvwgk", + "date": "2020-11-23 19:47:38+00:00", + "text": "Those who need to use NVHPC for GPU are already stuck with Fortran 95 syntax and stdlib would, in my opinion, become significantly more of a maintenance burden and more heavily reliant on preprocessors.\n\nSo true... \ud83d\ude22" + }, + { + "user": "scivision", + "date": "2020-11-24 15:46:14+00:00", + "text": "Also, there's the triumvirate of NVHPC, Flang classic, and LLVM/F18 Flang. I am not sure what Nvidia's long term plan is, it could be that they're pouring effort into f18 Flang to then rebase NVHPC on. That would be pretty awesome.\nIn the meantime, there are a significant community of HPC devs who seem to feel that Fortran 95 (or 77) + preprocessing stack is adequate for now, so I can't speak for them. My approach is to simply use the current Fortran standard in my work, and make shims to interface with the older preprocessed Fortran when needed.\nI am almost always able to avoid compiler preprocessors by using CMake or Meson configure_file to avoid duplicated code for select type and select rank. Well, I've just pushed the preprocessing up to the build system, but this helps me avoid compiler quirks as I also have to do this when accommodating Fortran file system operations across operating systems--which is where some of the compiler quirks broke my Fortran preprocessing, but easily worked with configure_file in CMake or Meson." } ] }, @@ -12156,6 +12794,31 @@ "user": "awvwgk", "date": "2020-09-05 08:41:18+00:00", "text": "The of popular Fortran projects in the wiki got quite out of date, in case it should still be maintained, one could automate at least the way meta data is fetched, a hacky example to do so using shields.io is in the details below.\n\n\n\n\nProject\nStars\nContributors\n\n\n\n\nABINIT\n\n\n\n\nADflow\n\n\n\n\naenet\n\n\n\n\narpack-ng\n\n\n\n\nbandup\n\n\n\n\nbspline-fortran\n\n\n\n\nCastro\n\n\n\n\nCFD\n\n\n\n\nCFL3D\n\n\n\n\nclfortran\n\n\n\n\nCompDam\n\n\n\n\ncoretran\n\n\n\n\ncp2k\n\n\n\n\nCTSM\n\n\n\n\ndatetime-fortran\n\n\n\n\nDBCSR\n\n\n\n\nDFTB+\n\n\n\n\nElmerFEM\n\n\n\n\nfdict\n\n\n\n\nfds\n\n\n\n\nFEconv\n\n\n\n\nfgsl\n\n\n\n\nFLAP\n\n\n\n\nFlexi\n\n\n\n\nfluidity\n\n\n\n\nFMS\n\n\n\n\nFOODIE\n\n\n\n\nforpy\n\n\n\n\nfortran2018-examples\n\n\n\n\nFortran-Astrodynamics-Toolkit\n\n\n\n\nfortran-csv-module\n\n\n\n\nfortranlib\n\n\n\n\nfortran-machine\n\n\n\n\nFortranPatterns\n\n\n\n\nfortran-utils\n\n\n\n\nfox\n\n\n\n\nfreeCappuccino\n\n\n\n\nftl\n\n\n\n\nfunctional-fortran\n\n\n\n\nFV3-GFS\n\n\n\n\nGALAHAD\n\n\n\n\nGFR\n\n\n\n\ngtk-fortran\n\n\n\n\nh5fortran\n\n\n\n\nHANDE-QMC\n\n\n\n\nIAMR\n\n\n\n\nICAR\n\n\n\n\njson-fortran\n\n\n\n\nkdtree2\n\n\n\n\nLaGriT\n\n\n\n\nLAPACK\n\n\n\n\nlesgo\n\n\n\n\nMODFLOW6\n\n\n\n\nMOM6\n\n\n\n\nMPAS\n\n\n\n\nNASTRAN-93\n\n\n\n\nNASTRAN-95\n\n\n\n\nNek5000\n\n\n\n\nNetCDF-Fortran\n\n\n\n\nneural-fortran\n\n\n\n\nnode-fortran\n\n\n\n\nnode.fortran\n\n\n\n\nnumerical-methods-fortran\n\n\n\n\nNWChem\n\n\n\n\nOFF\n\n\n\n\nogpf\n\n\n\n\nOpenBLAS\n\n\n\n\nOpenCMISS\n\n\n\n\nOpenCoarrays\n\n\n\n\nOpenSWPC\n\n\n\n\npFUnit\n\n\n\n\nPIC Skeleton Codes\n\n\n\n\nPoisFFT\n\n\n\n\npyplot-fortran\n\n\n\n\nQuantum ESPRESSO\n\n\n\n\nROMS\n\n\n\n\nSciFortran\n\n\n\n\nSHTOOLS\n\n\n\n\nsigma\n\n\n\n\nslsqp\n\n\n\n\nSNAP\n\n\n\n\nspecfem3d\n\n\n\n\nStarlink\n\n\n\n\nstdlib\n\n\n\n\nStringiFor\n\n\n\n\ntcp-client-server\n\n\n\n\nTRACMASS\n\n\n\n\nTruchas\n\n\n\n\ntsunami\n\n\n\n\nVTKFortran\n\n\n\n\nWAVEWATCH III\n\n\n\n\nWPS\n\n\n\n\nwrf_hydro_nwm_public\n\n\n\n\nWRF" + }, + { + "user": "ivan-pi", + "date": "2020-11-05 14:38:30+00:00", + "text": "I found one more large Fortran project: https://github.com/MITgcm/MITgcm (the MIT General Circulation Model, homepage: http://mitgcm.org/)" + }, + { + "user": "ivan-pi", + "date": "2020-11-05 14:39:59+00:00", + "text": "@awvwgk: is it possible to sort the list by the number of stars?" + }, + { + "user": "ivan-pi", + "date": "2020-11-05 14:49:19+00:00", + "text": "These projects are not meant as projects for transition to stdlib, but more as reference projects for us to learn how if Fortran used in real-life applications.\n\nSpeaking of real-life applications, I also found this huge list of programs from the Radiation Safety Information Computational Center: https://rsicc.ornl.gov/Catalog.aspx?c=CCC\nI'm sure there are several other government agencies, where Fortran is(was) the go-to language ;)" + }, + { + "user": "awvwgk", + "date": "2020-11-05 14:49:42+00:00", + "text": "Not without accessing the GH API directly, I'm currently cheating by using shields.io to access to GH API.\nMy suggestion would be to add all the packages from this list to the package index on fortran-lang and than we can figure out how to get this functionality into the package index." + }, + { + "user": "certik", + "date": "2020-11-05 17:09:28+00:00", + "text": "I don't want to maintain the list of projects at the wiki anymore. I want to port all of them to https://fortran-lang.org/packages/ and remove the wiki. We can implement sorting by stars at https://fortran-lang.org/packages/ or any other statistics that we need." } ] }, @@ -12475,7 +13138,13 @@ "date": "2019-12-19 18:17:45+00:00", "title": "Interface to POSIX I/O API", "text": "stdlib may include a module which provides an interface to the POSIX I/O calls in the C standard library. Such a module would support higher level functionality proposed in #14 on Unix-like platforms.\nThis module, or specific components, could be conditionally integrated into stdlib by the build system (CMake, autotools, etc) depending on whether they are available.\nSuch a module could also be extended to include more POSIX calls, e.g. thread support, memory allocation, lower-level system calls. For now, I'd say to keep the scope more narrow in order to keep it achievable.", - "comments": [] + "comments": [ + { + "user": "ivan-pi", + "date": "2020-11-24 14:48:33+00:00", + "text": "I discovered today that the major compiler vendors all provide(d) POSIX interfaces:\n\nIntel Fortran - POSIX* Library Procedures\nNAG - UNIX Process Primitives Module\nIBM - XL Fortran Posix bindings\nOracle - POSIX Library for Sun Fortran Compilers\nCOMPAQ Fortran for Unix and Linux Systems\nAbsoft Support Library\n\nAdditionally, there are several disjoint community efforts:\n\nM_system by @urbanjost\nfortran-posix by @dram\nThe Fortran 90 Posix interface project by Klaus Ramst\u00f6ck\nfortranposix\nAlgorithm 821: A Fortran interface to POSIX threads\nforthreads from @ohm314 (also described in an ACM journal article)\nPSX (from Starlink)\nfsocket\nfortran-server\n\nThe amount of reinvention in the Fortran community is distressing.\nEdit: a F77 interface was proposed by IEEE (see IEEE Standard for Information Technology - POSIX(R) FORTRAN 77 Language Interfaces), but from what I can gather it never gained widespread adoption and was later withdrawn." + } + ] }, { "number": 21, diff --git a/community/github_stats_data/data-j3-fortran-fortran_proposals.json b/community/github_stats_data/data-j3-fortran-fortran_proposals.json index 29c9c3f38..29f329078 100644 --- a/community/github_stats_data/data-j3-fortran-fortran_proposals.json +++ b/community/github_stats_data/data-j3-fortran-fortran_proposals.json @@ -1,6 +1,45 @@ { "name": "j3-fortran/fortran_proposals", "issues": [ + { + "number": 188, + "user": "sblionel", + "date": "2020-11-09 00:39:55+00:00", + "title": "Unions", + "text": "For many years, I have heard complaints from users at the lack of unions in Fortran. DEC added unions as part of its STRUCTURE/RECORD extension in 1985, but J3/WG5 never seriously considered adding unions as far as I know. Some considered unions like EQUIVALENCE, a bad programming practice. In an ideal world, I would agree, but there are just too many places where non-Fortran APIs use unions (Windows API for one) and the lack of a way to represent these in Fortran is considered a defect.\nGiven that a common use of unions is in C-friendly APIs, I want to propose unions in the context of C interoperability. Here is my idea:\n\nSupport the DEC UNION/MAP syntax for interoperable types only\nDisallow types with an \"ultimate component\" of a union from: formatted I/O without DT, default initialization, structure constructors (only those that don't give names for all their components?). Am I missing anything? I thought about intrinsic assignment, but I think this is OK since an interoperable type can't contain a pointer, allocatable or coarray component. Basically, the things that imply a component order would be excluded.\n\nMany compilers already support the DEC syntax, so this would be relatively easy to implement.\nAs a reminder, it would look something like this:\ntype, bind(C) :: union_type\n union\n map \n integer : I\n end map\n map\n real :: R\n end map\n end union\nend type union_type\ntype(union_type) :: UR\n\nOne could then reference UR%I or UR%R which would share the same memory location. The DEC syntax didn't allow naming unions or maps - I am not sure there is a benefit in doing so.", + "comments": [ + { + "user": "certik", + "date": "2020-11-09 01:36:35+00:00", + "text": "Thanks @sblionel for proposing this. That seems reasonable. Without this feature, what is the (current) way of interfacing a union in some C API?" + }, + { + "user": "sblionel", + "date": "2020-11-09 14:28:33+00:00", + "text": "The most straightforward way is to use the extension, if your compiler supports it. Otherwise you have to create separate type definitions for the alternate layouts and use TRANSFER to reinterpret the storage - messy.\nThe text about intrinsic assignment (10.2.1.3p14) will need some additional words on how to handle unions." + }, + { + "user": "FortranFan", + "date": "2020-11-09 23:08:28+00:00", + "text": "Feedback from peers as well as requests by Fortranners on other peer-to-peer sites toward Fortran online do indeed indicate adding the facility toward a union-type in Fortran is a really good idea, some can argue it is long overdue.\nBut all such feedback also indicate a UNION type is a first-class need in Fortran itself, it can be useful in simulations, etc.\nTherefore, the Fortran facility need not be in the context of interoperability with C only. Rather, the facility in Fortran should have additional characteristics when it comes to interoperability with C. One can see that with the CHARACTER type.\nFor example, UNION can perhaps be an attribute of a derived type in Fortran with certain restrictions: its components are all either intrinsic and/or other derived types of UNION types, there are no ALLOCATABLE components, nor are there any type-bound procedures allowed nor generic bindings and so forth similar to those with SEQUENCE types (but without any baggage of the SEQUENCE types for sure). The semantics of a type with a UNION attribute will be such that the STORAGE_SIZE of an object of said type is sufficient to contain the largest of the type components.\nBut that the BIND(C, ..) attribute brings additional semantics into effect toward interoperability with a C companion processor where each component in a union-type needs to be interoperable and the storage aspects then follow those of the companion processor e.g., with respect to any padding considerations.\nRegardless, the DEC Fortran extension that includes MAP sections look not only unnecessary but also not modern for standard Fortran. It will be preferable if the Fortran standard excluded anything with MAP that is currently in DEC Fortran.\nAlso, it should be possible for a derived type to have a component that of a derived type with a UNION attribute regardless of whether the hosting derived type is a UNION type.\nThus a facility can look like so:\ntype, UNION :: some_union_type !<-- see the attribute\n integer :: i\n real :: r\nend type\n\ntype, UNION, BIND(C) :: some_interoperable_union_type\n integer(c_int) :: i\n real(c_float) :: r\nend type\n\ntype, UNION, BIND(C) :: some_other_interoperable_type\n type(some_interoperable_union_type) :: foo\n character(kind=c_char,len=1) :: bar(N) !<-- where N is a named constant, or a constant expression, etc.\nend type" + }, + { + "user": "sblionel", + "date": "2020-11-10 00:43:47+00:00", + "text": "I'm sorry, @FortranFan , but I am having trouble understanding your suggestion. The DEC syntax provides much the same capability as C, allowing unions to be placed inside any type. It is very popular and well-understood. What is the use case of your version?\nI suggested restricting it to interoperable types because that's where the most common use is, and it means you don't have to come up with additional rules for things such as allocatable/pointer/coarray components." + }, + { + "user": "FortranFan", + "date": "2020-11-10 11:44:44+00:00", + "text": "@sblionel wrote Nov. 9, 2020 7:43 PM EST:\n\nI'm sorry, @FortranFan , but I am having trouble understanding your suggestion. The DEC syntax provides much the same capability as C, allowing unions to be placed inside any type. It is very popular and well-understood. What is the use case of your version?\n..\n\nThe use case(s) I am referring to include all the situations in a pure Fortran context, with no involvement of a companion C processor, where Fortranners have a need for a union type.\nThe scenarios I am referring can include something as simple as\n type, union :: foo_t\n double precision :: x\n character(kind=K, len=N) :: s\n end type\nwhere such a type is consumed using a processor with support toward DOUBLE PRECISION that conforms to Fortran standard but whose interoperability with a companion C processor is of no relevance to the program at hand. And the same with the CHARACTER type whose kind K has no relevance to 'C_CHAR' kind and where the program logic can depend on the length 'N' of a scalar component 's'.\nAs I wrote in my earlier post, there is a genuine need for a union type in Fortran which is not restricted in any way by the interoperability considerations with a companion C processor.\nIt's common in simulations (e.g., Physics simulations of particles) to work with \"blobs\" of data where\n\non the computational side of the program, the blob holds pertinent data consisting of Fortran intrinsic types including the floating-point formats that conform to the Fortran standard but not necessarily those of a C processor, and other intrinsic types including INTEGER, CHARACTER, and LOGICAL. But\non the data management side of the simulation program the blob may be an array of some primitive type supported by the Fortran processor and conformant to the Fortran standard e.g., an array of an arbitrary INTEGER or CHARACTER types that conform to Fortran standard but which have no relevance to a companion C processor,\n\nBut I acknowledge also the importance of a union type in the context of interoperation with a companion C processor, a common scenario being one on Windows OS e.g., where a Fortran program needs to work with user input on a console using Microsoft Windows API ReadConsoleInput.\nThat's why I suggest the thought process and vision toward such a feature in Fortran be broader and that the development of any proposal strives to include both of the above needs in order to serve the best interests of Fortran practitioners." + }, + { + "user": "sblionel", + "date": "2020-11-27 22:17:47+00:00", + "text": "Given that EQUIVALENCE has been booted from the language, I'm doubtful that replacing it with a full-throated, distinct union type would get a warm reception. Nothing in my proposal precludes doing that later, but I'm focused on solving a particular problem in a way that I think would be acceptable to the committee - especially as many compilers already support it.\nType-casting is already possible in Fortran, albeit a bit clumsily, with C_LOC and C_F_POINTER. It seems to me that the use cases you mention can be handled by the proposal at hand." + } + ] + }, { "number": 187, "user": "certik", @@ -17,6 +56,16 @@ "user": "milancurcic", "date": "2020-10-28 03:09:24+00:00", "text": "Definition of SPLIT is in 16.9.194 of 20-007." + }, + { + "user": "milancurcic", + "date": "2020-11-01 01:37:50+00:00", + "text": "I put an implementation here: https://github.com/milancurcic/fortran202x_split. I will request feedback in the stdlib issue." + }, + { + "user": "milancurcic", + "date": "2020-11-19 20:18:12+00:00", + "text": "We discussed the split API on a call on Tuesday. You can watch the recording here.\nOn the call we came to an overall tentative agreement that the 3rd form of split may be not appropriate or intuitive to be part of the split functionality. As a reminder, the 3 forms of split, after 20-007 and 20-139 are:\n\nSPLIT (STRING, SET, TOKENS [, SEPARATOR])\nSPLIT (STRING, SET, FIRST, LAST)\nSPLIT (STRING, SET, POS [, BACK])\n\nWhile we found that the first two forms are useful and meaningful for split, we also found that the 3rd form is not appropriate because it doesn't actually do any splitting. Instead, it does \"finding\", which is more akin to the intrinsic index. Bundling the 3rd form of the currently approved split with the other two may thus be confusing to Fortran programmers.\nWe decided to write a proposal against exclude the 3rd form in the split intrinsic for F202X. I have agreed to take a lead on it. I plan to have a PR draft in this repo by early December, so it can be discussed ahead of time both here and on the J3 mailing list and/or forum well ahead of time." } ] }, @@ -399,6 +448,11 @@ "user": "everythingfunctional", "date": "2020-10-08 16:08:44+00:00", "text": "I suggest to have unit tests in the production code and to be able to run unit tests with every standard conforming compiler and without any external tool.\n\nIs the idea then that the tests are run as part of the compilation process, but not included in the resulting executable? Or that the executable is able to \"test itself\" in some secondary mode of operation? I'm not familiar with D, so that example isn't particularly enlightening for me. Is D a compiled or interpreted language? What are the mechanics of running the unit tests?" + }, + { + "user": "Libavius", + "date": "2020-11-19 16:08:43+00:00", + "text": "@zmiimz I agree, that unit testing in the standard (like it exists for Python) would be perfect. Yet, for the time being, I can highly recommend pFUnit.\nPS: Many other modern languages do also not have a built-in unit test capability (e.g. C++)" } ] }, @@ -627,7 +681,12 @@ { "user": "certik", "date": "2020-10-27 19:32:35+00:00", - "text": "It was discussed at the October 2020 Fortran call that another good use case for this feature would be for array initializers. In Python you can do:\n[x+1 for x in range(1,N+1) if x >= 45 else x+5]\nSo in Fortran you could do:\n[ (if (x >= 45) then x+1 else x+5 endif, x = 1, N) ]\nSince conditional expressions are just expressions, this should just work." + "text": "It was discussed at the October 2020 Fortran call that another good use case for this feature would be for array initializers. In Python you can do (I corrected the syntax, thanks to @ivan-pi's comment below):\n[x+1 if x >= 45 else x+5 for x in range(1, N+1)]\nSo in Fortran you could do:\n[ (if (x >= 45) then x+1 else x+5 endif, x = 1, N) ]\nSince conditional expressions are just expressions, this should just work." + }, + { + "user": "ivan-pi", + "date": "2020-11-05 15:58:21+00:00", + "text": "In Python you can do:\n[x+1 for x in range(1,N+1) if x >= 45 else x+5]\n\nThis triggers a SyntaxError in Python. The correct way would be:\n[x + 1 if x > 45 else x+5 for x in range(1,N+1)]\nSo the syntax is\nexpression_if_true if condition else expression_if_false\n\nEdit: following Python if expression syntax, the example from above would be:\nCALL SUB(A, B, C, D IF PRESENT(D) ELSE (EPSILON(X) IF X < 1 ELSE SPACING(X)))\nIt seems fairly nice, you just need to remember the condition is in the middle.\nEdit2: Oops, I just noticed the posts from @14NGiestas above." } ] }, @@ -3047,6 +3106,21 @@ "user": "klausler", "date": "2020-06-04 20:36:16+00:00", "text": "auto is extremely useful in templatized C++ code to avoid having to explicitly write out complicated type expressions (or to avoid using type aliases), yes. And auto is absolutely essential when declaring things whose types are hidden in the compiler (e.g., lambda as local variables for use as internal functions) or polymorphic (e.g., a lambda like [](const auto &x){...} with a hidden template implementation).\nBut sometimes it's great to have around just to save some completely redundant verbiage in C++. const auto *p{std::get_if(&u)}; isn't made any more readable if the auto is replaced with the long type name, I think. And that's why I think it would be useful in Fortran today -- when there's an initializer with an obvious type." + }, + { + "user": "fazedo", + "date": "2020-11-04 15:48:19+00:00", + "text": "auto is very useful in C++, but I see few situations where it will be well employed in Fortran. Let's see some examples in C++:\n\nfor (auto x: some_list) do_stuff(); // Fortran does not have range-based loops.\nauto it = something.begin(); // Fortran does not have support for iterators in a generic programming fashion.\nauto t0 = get_time(); // auto is cool because I don't care about t0 class.\n... some code..\nauto t1 = get_time();\nauto elapsed_time = t1 - t0; // Again I don't care about which class is that.\n// But Fortran does not allow declarations in the middle of the code.\nauto f = [] (double x, int n) -> double {some code}; // Again Fortran...\nint i = 2;\nauto j = i; // Not good practice. \"Explicit is better than implicit.\" - Tim Peters\nauto x = 2.3; // Idem.\nauto x = f(); // Not common to declare variables and define them on the same line.\n\nauto was introduced in C++11 when generic programming was already well settled down, so it found a plethora of good places to be used, while, in Fortran, I don't see it will be really useful.\nI do believe Fortran needs support for generic programming as a scientific computing language, which is supposed to translate algorithms, not just formulas, but for the moment that is not the case." + }, + { + "user": "everythingfunctional", + "date": "2020-11-04 16:09:27+00:00", + "text": "In a sense, Fortran already does have something roughly equivalent to auto.\nassociate(x => some_function()) ! x takes on the type and value of the return from some_function\n ! some code\nend associate" + }, + { + "user": "fazedo", + "date": "2020-11-15 18:23:40+00:00", + "text": "Just in case it helps the discussion, there is an excelent talk by Herb Sutter on CppCon 2014 where he discuss several situations where it is a good practice to employ auto: https://youtu.be/xnqTKD8uD64?t=1703 ." } ] }, @@ -3453,6 +3527,11 @@ "user": "certik", "date": "2020-01-28 20:19:12+00:00", "text": "@difference-scheme just create a PR with the proposal. Once we have the proposals written and we can see the differences between them, if two of them should be merged, then we can do it. Otherwise we'll have several different proposals and we can then discuss the pros and cons of each approach, which will move the discussion forward." + }, + { + "user": "wclodius2", + "date": "2020-11-13 00:09:39+00:00", + "text": "FWIW in the example\nmodule A\nimplicit none\nprivate\npublic :: T\n\n type, requirements :: T\n contains\n generic :: operator(+) => plus\n end type\n\n abstract interface\n function plus(lhs,rhs)\n type(T), intent(in) :: lhs, rhs\n type(T) :: plus\n end function\n end interface\n\nend module A\n\nmodule A2\nuse A, only: T\nimplicit none\nprivate\npublic :: f\n\ncontains\n\n type(T) function f(x)\n type(T), intent(in) :: x\n f = x + 1\n end function\n\nend module A2\nThe interface should be:\n abstract interface\n function plus(lhs,rhs)\n type(T), intent(in) :: lhs\n integer, intent(in) :: rhs\n type(T) :: plus\n end function\n end interface\nThe type probably also needs an assignment interface for the \"strong concepts\" to be enforced, and would benefit from having an example instantiation, so a full example should probably be\nmodule A\nimplicit none\nprivate\npublic :: T\n\n type, requirements :: T\n contains\n generic :: operator(+) => plus\n generic :: assignment(=) => assign\n end type\n\n abstract interface\n function plus(lhs,rhs)\n type(T), intent(in) :: lhs\n integer, intent(in) :: rhs\n type(T) :: plus\n end function plus\n end interface\n\n abstract interface\n function assgn(lhs,rhs)\n type(T), intent(out) :: lhs\n type(T), intent(in) :: rhs\n end function assign\n end interface\n\nend module A\n\nmodule A2\nuse A, only: T\nimplicit none\nprivate\npublic :: f\n\ncontains\n\n type(T) function f(x)\n type(T), intent(in) :: x\n f = x + 1\n end function\n\nend module A2\n\nprogram example\nuse A2\nimplicit none\nreal :: two\ntwo = f(1.0)\nend program example" } ] }, @@ -4106,6 +4185,11 @@ "user": "opeil", "date": "2020-04-14 19:00:13+00:00", "text": "Perhaps, it is too late to discuss this but somehow I have not seen anyone mentioning another important aspect of the compound/augmented assignment: It allows to perform more efficient in-place operations, such as big_array(:, :, :) += big_array2(:, :, :), without the risk of creating temporaries. This makes it more than just a syntactic sugar.\nAnother similar example is that if we have a type like this\ntype :: BigObject\n real(dp) :: values(10000, 10000)\nend type\n\ntype(BigObject) :: a, b\n\nand there is a frequent need to do operations like this -- a % values = a % values + b % values, then a naive overloading of operator (+) would result in an extremely inefficient code. It would be great if one has a possibility to overload something like (+=) [with obvious call semantics] to implement heavy in-place operations." + }, + { + "user": "septcolor", + "date": "2020-11-11 17:50:32+00:00", + "text": "This is another similar request that I have come across on the StackOverflow site recently:\nIncrement value in Fortran?\nhttps://stackoverflow.com/questions/64791017/increment-value-in-fortran?noredirect=1&lq=1" } ] }, @@ -5049,6 +5133,21 @@ "user": "aradi", "date": "2020-01-08 16:23:42+00:00", "text": "Unfortunately, it is not just flattening, but also automatic merging. The assignment\nb = [[-3, 2, 9], [1, 2]]\n\ncurrently works (provided b is a rank-1 array), but it would became a syntactical non-sence if the braces would open/close ranks as they do in Python.\nI agree, that the current syntax is weird and I have no clue, why it was introduced. But I don't think we have any chance to delete it from the language. So, the best compromise IMO is still the assignment of rank-1 arrays to rank-N ones without the need for a reshape, as suggested by @sblionel ." + }, + { + "user": "elecprog", + "date": "2020-11-02 18:04:03+00:00", + "text": "But I don't think we have any chance to delete it from the language.\n\nGiven that I used this rather recently, that chance is indeed rather slim. It's convenient to concatenate arrays, although an intrinsic function would have been the better choice back when that syntax was introduced.\nI'm still keen on doing something similar to Matlab or Julia as in my initial proposal (I'm the original comp.lang.fortran poster), but I haven't yet found a better alternative.\nI'd be weary of introducing anything that doesn't also scale to rank 3 (or higher) arrays, though." + }, + { + "user": "certik", + "date": "2020-11-02 18:36:38+00:00", + "text": "@elecprog thanks for the feedback and for the proposal. I think there is still an opportunity here to do something, but we have to figure out how to do it to satisfy all the requirements/issues stated in this thread." + }, + { + "user": "urbanjost", + "date": "2020-11-03 01:45:11+00:00", + "text": "When I think of all the capabilities available in READ() including list-directed and implied DO constructs if there were some equivalent of a \"here\" document in Fortran it woud allow for inputting small arrays but also text blocks without having to use continuation characters and quotes as well.\ninteger :: a(3,4) <<< read(*,*)(a(i,j),i=1,3,j=1,4)\n 1 2 3 4\n 5 6 7 8\n 9 10 11 12\n>>>\n\ncharacter(len=:),allocatable :: text(:) <<< read(*,'(a)')text\n This is the help text\n for my\n program\n>>>\n\nAlmost no new syntax, useful for small arrays but maybe more so for text; would be really nice to have some kind of block comment too, maybe just\n<<<\n a block of\n text\n>>>" } ] }, @@ -8159,6 +8258,21 @@ "user": "klausler", "date": "2020-09-08 19:22:54+00:00", "text": "After seeing all the discussions around this, I am now under the following impression. The standard chose to use DO CONCURRENT but only specified constraints for (and if we had a time machine should have used) DO UNORDERED. It seems many (if not most) people assumed that the constraints actually were sufficient to allow for parallelism, but it would seem to be highly unlikely the committee would \"break existing code\" by adding constraints to DO CONCURRENT. Thus it seems we will need to introduce (and I would be in favor of) a new keyword to allow a way of specifying constraints sufficient for parallelism, most likely DO PARALLEL.\nOf course, for those of us who considered concurrent and parallel to be synonyms it makes the language a bit more confusing, but is probably the only truly backwards compatible way to get the necessary constraints added. It seems to me quite similar to the way PURE procedures don't have sufficient constraints, hence the proposal to introduce SIMPLE procedures.\n\nSee subclause 4.3.3 in Fortran 2018 for some precedents in which features from earlier standards are disallowed, including some features from DO CONCURRENT. Backward compatibility to mistakes is fixable." + }, + { + "user": "klausler", + "date": "2020-11-18 00:01:41+00:00", + "text": "I've checked in a description of the outstanding problems with DO CONCURRENT in the LLVM documentation. Still not sure what we're going to do in the flang compilers -- there's good arguments for both standard conformance as well as for just doing the right thing." + }, + { + "user": "FortranFan", + "date": "2020-11-18 01:53:55+00:00", + "text": "@klausler wrote Nov. 17, 2020 7:01 PM EST:\n\n.. Still not sure what we're going to do in the flang compilers -- there's good arguments for both standard conformance as well as for just doing the right thing.\n\nc.f. https://mailman.j3-fortran.org/pipermail/j3/2020-July/012244.html where J3 \"effectively\" suggested something which is not yet in the standard.\nSo, is it possible for flang compilers to do both!?\nThat is, first have a standard-conforming implementation of DO CONCURRENT.\nBut then also consider an \"Experimental\" edition of flang compiler(s) that attempts to do the \"right thing\", perhaps via a \"DEFAULT(SHARED)\" or some suitable extension that is Fortrannic and which can then be proposed for Fortran 202Y as further improvement to be incorporated into the standard?" + }, + { + "user": "klausler", + "date": "2020-11-18 02:27:06+00:00", + "text": "@klausler wrote Nov. 17, 2020 7:01 PM EST:\n\n.. Still not sure what we're going to do in the flang compilers -- there's good arguments for both standard conformance as well as for just doing the right thing.\n\nc.f. https://mailman.j3-fortran.org/pipermail/j3/2020-July/012244.html where J3 \"effectively\" suggested something which is not yet in the standard.\nSo, is it possible for flang compilers to do both!?\nThat is, first have a standard-conforming implementation of DO CONCURRENT.\nBut then also consider an \"Experimental\" edition of flang compiler(s) that attempts to do the \"right thing\", perhaps via a \"DEFAULT(SHARED)\" or some suitable extension that is Fortrannic and which can then be proposed for Fortran 202Y as further improvement to be incorporated into the standard?\n\nAnything is possible, but these are all just second-best alternatives to J3 just fixing the problems." } ] }, @@ -9659,7 +9773,7 @@ { "user": "milancurcic", "date": "2019-10-23 16:59:46+00:00", - "text": "Implicit save behavior is relevant only in procedures.\nHowever, now I realize that in the context of default value for derived type components, which I've been happily using for years, the type constructor uses the same style as proposed in #22. For example:\ntype my_type\n integer :: i = 1 \nend type my_type\n\ntype(my_type) :: t1 = my_type() ! this works, t1 % i is 1\ntype(my_type) :: t2 = my_type(3) ! this works also, t2 % i is 3\nSo, the proposal #22 (sorry to hijack the thread :)) is consistent with the current syntax for default values of derived type components, except there we need an extra attribute (default) to work around the implicit save behavior.\nI like this proposal also. It could be merged with #22, or have two separate smaller proposals. We should make whatever is easier to digest by the committee." + "text": "Implicit save behavior is relevant only in procedures.\nHowever, now I realize that in the context of default value for derived type components, which I've been happily using for years, the type constructor uses the same style as proposed in #22. For example:\ntype my_type\n integer :: i = 1 \nend type my_type\n\ntype(my_type) :: t1 = my_type() ! this works, t1 % i is 1\ntype(my_type) :: t2 = my_type(3) ! this works also, t2 % i is 3\n\nSo, the proposal #22 (sorry to hijack the thread :)) is consistent with the current syntax for default values of derived type components, except there we need an extra attribute (default) to work around the implicit save behavior.\nI like this proposal also. It could be merged with #22, or have two separate smaller proposals. We should make whatever is easier to digest by the committee." }, { "user": "jacobwilliams", From 470d08e123a00ccf6c519460846cdaf3cc72db0c Mon Sep 17 00:00:00 2001 From: milancurcic Date: Tue, 1 Dec 2020 10:16:57 -0500 Subject: [PATCH 06/15] formatting fix --- _posts/2020-12-01-Fortran-Newsletter-December-2020.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/_posts/2020-12-01-Fortran-Newsletter-December-2020.md b/_posts/2020-12-01-Fortran-Newsletter-December-2020.md index 810e1873b..47a3b92b4 100644 --- a/_posts/2020-12-01-Fortran-Newsletter-December-2020.md +++ b/_posts/2020-12-01-Fortran-Newsletter-December-2020.md @@ -52,7 +52,7 @@ Don't hesitate to test and review these pull requests! Otherwise, ongoing discussions continue: * [#220](https://github.com/fortran-lang/stdlib/issues/220): API for file system operations: directory manipulation * [#241](https://github.com/fortran-lang/stdlib/issues/241): Include a `split` function (202X feature) -[#254](https://github.com/fortran-lang/stdlib/issues/254): Proposition to add a logger for debug phases and levels among the different logs. +* [#254](https://github.com/fortran-lang/stdlib/issues/254): Proposition to add a logger for debug phases and levels among the different logs. The candidate for file system operations to be included in stdlib is being developed by [@MarDiehl](https://github.com/MarDiehl) and [@arjenmarkus](https://github.com/arjenmarkus) From f788a3b8fc7e5f4a2490a84f5e36ca3391a0b2bf Mon Sep 17 00:00:00 2001 From: milancurcic Date: Tue, 1 Dec 2020 10:17:42 -0500 Subject: [PATCH 07/15] add Jeremie and Laurence to authors --- _posts/2020-12-01-Fortran-Newsletter-December-2020.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/_posts/2020-12-01-Fortran-Newsletter-December-2020.md b/_posts/2020-12-01-Fortran-Newsletter-December-2020.md index 47a3b92b4..1378b953d 100644 --- a/_posts/2020-12-01-Fortran-Newsletter-December-2020.md +++ b/_posts/2020-12-01-Fortran-Newsletter-December-2020.md @@ -2,7 +2,7 @@ layout: post title: "Fortran newsletter: December 2020" category: newsletter -author: Milan Curcic +author: Milan Curcic, Jérémie Vandenplas, Laurence Kedward --- Welcome to the December 2020 edition of the monthly Fortran newsletter. From 39754cd9a2bd6189643202c987e385d6b1011b4f Mon Sep 17 00:00:00 2001 From: milancurcic Date: Sun, 6 Dec 2020 10:57:47 -0500 Subject: [PATCH 08/15] contributions from Gary; Flang call dates yet to be corrected --- ...-12-01-Fortran-Newsletter-December-2020.md | 48 +++++++++++++++++-- 1 file changed, 45 insertions(+), 3 deletions(-) diff --git a/_posts/2020-12-01-Fortran-Newsletter-December-2020.md b/_posts/2020-12-01-Fortran-Newsletter-December-2020.md index 1378b953d..70ee1d116 100644 --- a/_posts/2020-12-01-Fortran-Newsletter-December-2020.md +++ b/_posts/2020-12-01-Fortran-Newsletter-December-2020.md @@ -2,7 +2,7 @@ layout: post title: "Fortran newsletter: December 2020" category: newsletter -author: Milan Curcic, Jérémie Vandenplas, Laurence Kedward +author: Milan Curcic, Jérémie Vandenplas, Laurence Kedward, Gary Klimowicz --- Welcome to the December 2020 edition of the monthly Fortran newsletter. @@ -108,11 +108,53 @@ environment in which new open source Fortran projects are created and published ### Classic Flang -TODO @gklimowicz +We continue to evaluate and merge pull requests into Classic Flang. Recently merged pull requests into Classic Flang include: +* [PR#883: Flang generated executable does not show result variable of function](https://github.com/flang-compiler/flang/pull/883) +* [PR#933: Updating X-flag entries for internal command line option "-x 49"](https://github.com/flang-compiler/flang/pull/933) +* [PR#939: Publish Arm's internal documentation](https://github.com/flang-compiler/flang/pull/939) +* [PR#941: [DebugInfo] Internal subprogram variable is not accessible for printing in gdb](https://github.com/flang-compiler/flang/pull/941) +* [PR#942: Implement UNROLL(n) directive](https://github.com/flang-compiler/flang/pull/942) +* [PR#943: Enable github Actions for push to master and pull requests to master](https://github.com/flang-compiler/flang/pull/943) +* [PR#945: libpgmath: Stop using pgstdinit.h](https://github.com/flang-compiler/flang/pull/945) +* [PR#946: Call check_member() for PD_is_contiguous](https://github.com/flang-compiler/flang/pull/946) +* [PR#951: Fix for ICE in atomic instruction generation](https://github.com/flang-compiler/flang/pull/951) + +Pull requests merged into the supporting projects: +* [classic flang LLVM monorepo PR#5: [Driver] Reduce downstream delta](https://github.com/flang-compiler/classic-flang-llvm-project/pull/5) +* [classic flang LLVM monorepo PR#6: Removing a few CI pipelines](https://github.com/flang-compiler/classic-flang-llvm-project/pull/6) +* [classic flang LLVM monorepo PR#7: Github Actions added to pre-compile artifacts for flang](https://github.com/flang-compiler/classic-flang-llvm-project/pull/7) +* [llvm mirror PR#87: Enable github actions for llvm](https://github.com/flang-compiler/llvm/pull/87) +* [flang-driver PR#94: Enable github actions](https://github.com/flang-compiler/flang-driver/pull/94) + +The Classic Flang biweekly call has been set up to discuss issues and plans +for the next pull requests to be validated and merged. Our next calls are Wednesday, November 16 and 30, 8:00 AM Pacific time. The notes from previous calls, upcoming agenda and a link to join the call can be found +[here](https://docs.google.com/document/d/1-OuiKx4d7O6eLEJDBDKSRnSiUO2rgRR-c2Ga4AkrzOI). ### LLVM Flang -TODO @gklimowicz +Work continues on LLVM Flang, concentrating on semantics, lowering and runtime. Significant contributions are being made for OpenMP and OpenACC support. + +In conjunction with the MLIR-based code from the _fir-dev_ fork (the Fortran IR used for lowering), Flang can compile and run most F77 programs, including the Fortran Compiler Validation Suite (FCVS). + +Pat McCormick is (still) working on an RFC for the merge of the lowering code +in the fir-dev fork into LLVM master. (This was interrupted by Supercomputing 2020 and other ECP duties.) The goal is to expedite this in a way that is acceptable to the Flang community, so we can do further work in the single master branch. + +Recent updates include: +* Johannes Doerfert has created a web page at https://flang.llvm.org; you can find call and Slack logistics there +* Nichols Romero has an llvm-dev RFC for adding Fortran tests to the llvm-tests project: http://lists.llvm.org/pipermail/llvm-dev/2020-November/146873.html +* Andzrej Warzynski has a flang-dev RFC regarding flang option names: http://lists.llvm.org/pipermail/flang-dev/2020-November/000588.html +* Andzrej Warzynski has a cfe-dev RFC regarding refactoring clang to help flang driver become independent of clang: http://lists.llvm.org/pipermail/cfe-dev/2020-November/067263.html +* Changed representation of CHARACTER data in type system to make more consistent with other types (for arrays) +* Changed COMPLEX expression representation to provide better handling in lowering +* More improvements for supporting Fortran 77 programs +* Implemented runtime support for basic ALLOCATE/DEALLOCATE and further work +* Continued implementation of table-driven runtime for derived types; posted documentation +* Continued implementation of array expression lowering +* Improved error checks on forward references +* More updates to flang driver (option handling; -E can now be used to invoke just the Flang preprocessor) +* OpenACC semantic checks for modifiers on enter/exit data, set directives +* OpenACC lowering (enter/exit data, update, init, shutdown, wait directives) +* OpenMP structure checker updates; semantic checks for copyin clause; schedule class ### LFortran From d0cf6ab2d744a102903ffab9eeb9e22baa8bc016 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Ond=C5=99ej=20=C4=8Cert=C3=ADk?= Date: Sun, 6 Dec 2020 17:47:49 -0700 Subject: [PATCH 09/15] Update _posts/2020-12-01-Fortran-Newsletter-December-2020.md --- _posts/2020-12-01-Fortran-Newsletter-December-2020.md | 7 ------- 1 file changed, 7 deletions(-) diff --git a/_posts/2020-12-01-Fortran-Newsletter-December-2020.md b/_posts/2020-12-01-Fortran-Newsletter-December-2020.md index 70ee1d116..ff392b9d7 100644 --- a/_posts/2020-12-01-Fortran-Newsletter-December-2020.md +++ b/_posts/2020-12-01-Fortran-Newsletter-December-2020.md @@ -156,13 +156,6 @@ Recent updates include: * OpenACC lowering (enter/exit data, update, init, shutdown, wait directives) * OpenMP structure checker updates; semantic checks for copyin clause; schedule class -### LFortran - -What's new in LFortran: - -TODO @certik - -You can follow LFortran on Twitter for latest updates: [@lfortranorg](https://twitter.com/lfortranorg). ## Events From 69eacb54cb3675c03466c44cf879b715144452ba Mon Sep 17 00:00:00 2001 From: Milan Curcic Date: Mon, 7 Dec 2020 10:18:54 -0500 Subject: [PATCH 10/15] Update _posts/2020-12-01-Fortran-Newsletter-December-2020.md MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Co-authored-by: Ondřej Čertík --- _posts/2020-12-01-Fortran-Newsletter-December-2020.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/_posts/2020-12-01-Fortran-Newsletter-December-2020.md b/_posts/2020-12-01-Fortran-Newsletter-December-2020.md index ff392b9d7..af9c074c2 100644 --- a/_posts/2020-12-01-Fortran-Newsletter-December-2020.md +++ b/_posts/2020-12-01-Fortran-Newsletter-December-2020.md @@ -32,7 +32,7 @@ We welcome any new contributors to the website and the tutorials page in particu ## Fortran Standard Library -Here's what's new in stdlib: +Here's what's new in `stdlib`: * [#239](https://github.com/fortran-lang/stdlib/pull/239): Implementation of bitsets in `stdlib_bitsets`. * [#243](https://github.com/fortran-lang/stdlib/pull/243), From 70103f3d709bde7140e6f6ec36d111cccecf4a06 Mon Sep 17 00:00:00 2001 From: Milan Curcic Date: Mon, 7 Dec 2020 10:19:08 -0500 Subject: [PATCH 11/15] Update _posts/2020-12-01-Fortran-Newsletter-December-2020.md MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Co-authored-by: Ondřej Čertík --- _posts/2020-12-01-Fortran-Newsletter-December-2020.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/_posts/2020-12-01-Fortran-Newsletter-December-2020.md b/_posts/2020-12-01-Fortran-Newsletter-December-2020.md index af9c074c2..5085ecec4 100644 --- a/_posts/2020-12-01-Fortran-Newsletter-December-2020.md +++ b/_posts/2020-12-01-Fortran-Newsletter-December-2020.md @@ -17,7 +17,7 @@ This month we've had a few updates to the website: * [#156](https://github.com/fortran-lang/fortran-lang.org/pull/156): Updates to the mini-book on building Fortran programs, including the addition of -short guides on meson and CMake. +short guides on Meson and CMake. You can read the mini-book [here](https://fortran-lang.org/learn/building_programs). * [#169](https://github.com/fortran-lang/fortran-lang.org/pull/169): Add PSBLAS to the package index. From 3373836cdfa54dfb0316e9e0c89c99ed9de93909 Mon Sep 17 00:00:00 2001 From: Milan Curcic Date: Mon, 7 Dec 2020 10:19:37 -0500 Subject: [PATCH 12/15] Update _posts/2020-12-01-Fortran-Newsletter-December-2020.md MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Co-authored-by: Ondřej Čertík --- _posts/2020-12-01-Fortran-Newsletter-December-2020.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/_posts/2020-12-01-Fortran-Newsletter-December-2020.md b/_posts/2020-12-01-Fortran-Newsletter-December-2020.md index 5085ecec4..1700e13af 100644 --- a/_posts/2020-12-01-Fortran-Newsletter-December-2020.md +++ b/_posts/2020-12-01-Fortran-Newsletter-December-2020.md @@ -61,7 +61,7 @@ Please try it out and let us know how it works, if there are any issues, or if t ## Fortran Package Manager -Here's what's new in fpm: +Here's what's new in `fpm`: * [#259](https://github.com/fortran-lang/fpm/pull/259): Update the instructions for building from source in README.md. * [#246](https://github.com/fortran-lang/fpm/pull/246): Automated binary releases in CI. From c48ce2eed8e715d243f324eebb53be71f1e0d26e Mon Sep 17 00:00:00 2001 From: Milan Curcic Date: Mon, 7 Dec 2020 10:19:46 -0500 Subject: [PATCH 13/15] Update _posts/2020-12-01-Fortran-Newsletter-December-2020.md MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Co-authored-by: Ondřej Čertík --- _posts/2020-12-01-Fortran-Newsletter-December-2020.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/_posts/2020-12-01-Fortran-Newsletter-December-2020.md b/_posts/2020-12-01-Fortran-Newsletter-December-2020.md index 1700e13af..fe01dfe59 100644 --- a/_posts/2020-12-01-Fortran-Newsletter-December-2020.md +++ b/_posts/2020-12-01-Fortran-Newsletter-December-2020.md @@ -92,7 +92,7 @@ Work in progress: * (WIP) [#257](https://github.com/fortran-lang/fpm/pull/257): Implement `fpm install`. * (WIP) [#260](https://github.com/fortran-lang/fpm/pull/260): Fix CI to test release build. -fpm is still in early development and we need as much help as we can get. +`fpm` is still in early development and we need as much help as we can get. Here's how you can help today: * Use it and let us know what you think! Read the [fpm packaging guide](https://github.com/fortran-lang/fpm/blob/master/PACKAGING.md) to learn how to build your package with fpm, and the [manifest reference](https://github.com/fortran-lang/fpm/blob/master/manifest-reference.md) to learn what are all the things that you can specify in the fpm.toml file. From 87550692419b95d4f171460a2bbc59e3aef0c7d4 Mon Sep 17 00:00:00 2001 From: Milan Curcic Date: Mon, 7 Dec 2020 10:22:04 -0500 Subject: [PATCH 14/15] fix Flang call dates after Gary's feedback --- _posts/2020-12-01-Fortran-Newsletter-December-2020.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/_posts/2020-12-01-Fortran-Newsletter-December-2020.md b/_posts/2020-12-01-Fortran-Newsletter-December-2020.md index fe01dfe59..a4038bb1e 100644 --- a/_posts/2020-12-01-Fortran-Newsletter-December-2020.md +++ b/_posts/2020-12-01-Fortran-Newsletter-December-2020.md @@ -127,7 +127,7 @@ Pull requests merged into the supporting projects: * [flang-driver PR#94: Enable github actions](https://github.com/flang-compiler/flang-driver/pull/94) The Classic Flang biweekly call has been set up to discuss issues and plans -for the next pull requests to be validated and merged. Our next calls are Wednesday, November 16 and 30, 8:00 AM Pacific time. The notes from previous calls, upcoming agenda and a link to join the call can be found +for the next pull requests to be validated and merged. Our next calls are Wednesday, December 16 and 30, 8:00 AM Pacific time. The notes from previous calls, upcoming agenda and a link to join the call can be found [here](https://docs.google.com/document/d/1-OuiKx4d7O6eLEJDBDKSRnSiUO2rgRR-c2Ga4AkrzOI). ### LLVM Flang From 1f25a17e525c08e7b72e94dc0337cdf3c9ca2d05 Mon Sep 17 00:00:00 2001 From: Milan Curcic Date: Mon, 7 Dec 2020 10:22:30 -0500 Subject: [PATCH 15/15] add Ondrej to authors list --- _posts/2020-12-01-Fortran-Newsletter-December-2020.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/_posts/2020-12-01-Fortran-Newsletter-December-2020.md b/_posts/2020-12-01-Fortran-Newsletter-December-2020.md index a4038bb1e..6b862c2d4 100644 --- a/_posts/2020-12-01-Fortran-Newsletter-December-2020.md +++ b/_posts/2020-12-01-Fortran-Newsletter-December-2020.md @@ -2,7 +2,7 @@ layout: post title: "Fortran newsletter: December 2020" category: newsletter -author: Milan Curcic, Jérémie Vandenplas, Laurence Kedward, Gary Klimowicz +author: Milan Curcic, Jérémie Vandenplas, Laurence Kedward, Gary Klimowicz, Ondřej Čertík --- Welcome to the December 2020 edition of the monthly Fortran newsletter.