{"action":"created","issue":{"url":"https://api.github.com/repos/swig/swig/issues/1195","repository_url":"https://api.github.com/repos/swig/swig","labels_url":"https://api.github.com/repos/swig/swig/issues/1195/labels{/name}","comments_url":"https://api.github.com/repos/swig/swig/issues/1195/comments","events_url":"https://api.github.com/repos/swig/swig/issues/1195/events","html_url":"https://github.com/swig/swig/pull/1195","id":296601166,"number":1195,"title":"Fortran-2003 target language","user":{"login":"sethrj","id":741229,"avatar_url":"https://avatars3.githubusercontent.com/u/741229?v=4","gravatar_id":"","url":"https://api.github.com/users/sethrj","html_url":"https://github.com/sethrj","followers_url":"https://api.github.com/users/sethrj/followers","following_url":"https://api.github.com/users/sethrj/following{/other_user}","gists_url":"https://api.github.com/users/sethrj/gists{/gist_id}","starred_url":"https://api.github.com/users/sethrj/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/sethrj/subscriptions","organizations_url":"https://api.github.com/users/sethrj/orgs","repos_url":"https://api.github.com/users/sethrj/repos","events_url":"https://api.github.com/users/sethrj/events{/privacy}","received_events_url":"https://api.github.com/users/sethrj/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"assignees":[],"milestone":null,"comments":17,"created_at":"2018-02-13T03:20:56Z","updated_at":"2018-03-20T20:00:13Z","closed_at":null,"author_association":"NONE","pull_request":{"url":"https://api.github.com/repos/swig/swig/pulls/1195","html_url":"https://github.com/swig/swig/pull/1195","diff_url":"https://github.com/swig/swig/pull/1195.diff","patch_url":"https://github.com/swig/swig/pull/1195.patch"},"body":"This branch is WIP because there are a few procedural issues that need to be addressed before it's merged.\r\n1. I tend to have a very atomic commit style, so there are a *lot* of commits on this branch. Should I squash all of the changes that create the new module source file and library files, and keep separate any commits that modify the rest of the source code?\r\n2. The style in `Module/fortran.cxx` is in my work group's preferred style, with much more whitespace, comments, and documentation than is present in the rest of SWIG. Should I run it through clang-format to convert it to K&R style like the manual suggests, or can it stay independent if I'm the primary maintainer?\r\n3. Rather than hand-code the documentation in HTML, I've written it in gfm-style markdown and used [Pandoc](http://pandoc.org) to build an HTML file from it. The existing python chapter tools are very rigid in how they combine the data (it looks like they're archaic python too, almost 20 years old!) so I was hoping to work with you to update the scripts and/or the documentation itself. In this MR the Fortran chapter works as a stand-alone document but its (pandoc-generated) table of contents is not pulled into the global table of contents.\r\n\r\nThe rest of the \"new module requirements\" are satisfied I believe:\r\n- Most of the C++ test cases work: 412 create valid C++ and Fortran code; 38 create valid C++ and invalid Fortran. The invalid ones are added to the `FAILING_CPP_TESTS` macro variable.\r\n- I have a manual chapter about the new fortran capabilities.\r\n- I have several examples of C and C++ wrapping, including the required \"simple\" and \"class\" tests.\r\n- I am definitely committed to maintaining this module; its development has been as part of a [software technology plan to provide Fortran interfaces to a numerical solver library](https://www.ecpannualmeeting.com/assets/program_assets/ecp_fortran_trilinos.html) as part of the U.S. Department of Energy's [Exascale Computing Project](https://www.exascaleproject.org/focus_area/software/)\r\n\r\nI've been pleased with the responsiveness of the SWIG lead maintainer @wsfulton and look forward to working with you to integrating this new capability."},"comment":{"url":"https://api.github.com/repos/swig/swig/issues/comments/374736565","html_url":"https://github.com/swig/swig/pull/1195#issuecomment-374736565","issue_url":"https://api.github.com/repos/swig/swig/issues/1195","id":374736565,"user":{"login":"wsfulton","id":2878511,"avatar_url":"https://avatars0.githubusercontent.com/u/2878511?v=4","gravatar_id":"","url":"https://api.github.com/users/wsfulton","html_url":"https://github.com/wsfulton","followers_url":"https://api.github.com/users/wsfulton/followers","following_url":"https://api.github.com/users/wsfulton/following{/other_user}","gists_url":"https://api.github.com/users/wsfulton/gists{/gist_id}","starred_url":"https://api.github.com/users/wsfulton/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/wsfulton/subscriptions","organizations_url":"https://api.github.com/users/wsfulton/orgs","repos_url":"https://api.github.com/users/wsfulton/repos","events_url":"https://api.github.com/users/wsfulton/events{/privacy}","received_events_url":"https://api.github.com/users/wsfulton/received_events","type":"User","site_admin":false},"created_at":"2018-03-20T20:00:13Z","updated_at":"2018-03-20T20:00:13Z","author_association":"OWNER","body":"Mingw on Appveyor is passing now.\r\n\r\nReview 4:\r\n1. 04d7970 This change affects kwargs in a few SWIG directives: %fragment, %rename,  %typemap, %extend, %include, %module as far as I can see. I've made a note of it here for when we create the CHANGES file additions for this merge. I think this is all okay, but could do with better documentation in the main ones (just %feature and %typemap should suffice). There is a subtle difference to the SWIG directives using {} as in the attributes there is an implicit 'noblock=1' which swallows the {} braces. That seems okay though to me.\r\n3. 85c171d Interesting. This has an uncovered a general bug I'd say. The `__dummy__` names should not be renamed under any circumstances as this is a reserved SWIG identifier (C allows a double underscore prefix to be reserved by the implementation and SWIG takes advantage of this for it's implementation). Fortran renaming can then use a simpler matching pattern with a fix for this. Could you do the fix and adjust the Fortran renaming pattern (probably \"strip:\")?\r\n5. 44b28a9 Okay, let's revisit when this is all on master.\r\n6. 7aff1ef While you may prefer this naming pattern someone else may prefer it the other way. I'd like to have a consistent default in SWIG including Fortran. For most languages this is an implementation detail as proxy classes provide the member name exactly as it is in C/C++. I'm still getting to grips with your Fortran wrappers, but if I look at the class example, the `x` member is accessed using `set_x`, but this is the member accessor which calls `set_Shape_x`. Using `set_x` is Fortran specific, but what is wrong with the implementation detail function which ought to be `Shape_x_set` ? So change the generated code from:\r\n```fortran\r\n  procedure :: set_x => set_Shape_x\r\n```\r\nto\r\n```fortran\r\n  procedure :: set_x => Shape_x_set\r\n```\r\nThis then conforms and a user targeting multiple languages could add member variables use %extend without having to do something different for Fortran. But I think you are then concerned about global variable wrappers which are done via function calls? Maybe we just need to make the %extend work consistently across languages and allow your preferred style for get_ set_ functions."}}
{"actor":{"display_login":"wsfulton"}}