Fortran Monthly Call: August 2021

Thanks, @jeremie.vandenplas. I won’t be able to join this meeting, nor provide the Zoom meeting room. Anyone else has a premium Zoom account to use? Otherwise, I found Google Meet to be a high-quality and free alternative, and has the features we use (screen sharing and recording).

I have a zoom account we could use for this purpose.

Here is the meeting information:

Topic: Fortran Monthly Call: August 2021
Time: Aug 17, 2021 05:00 PM Universal Time UTC

Join Zoom Meeting: Launch Meeting - Zoom

Meeting ID: 934 0502 4705
Passcode: 758228
One tap mobile
+493056795800,93405024705#,*758228# Germany
+496938079883,93405024705#,*758228# Germany

Dial by your location
+49 30 5679 5800 Germany
+49 69 3807 9883 Germany
+49 69 3807 9884 Germany
+49 695 050 2596 Germany
+49 69 7104 9922 Germany
Meeting ID: 934 0502 4705
Passcode: 758228
Find your local number: Zoom International Dial-in Numbers - Zoom

Join by SIP
93405024705@131.220.109.56

Join by H.323
131.220.109.56
Meeting ID: 934 0502 4705
Passcode: 758228

I suggest to discuss:

  • teams for fpm, stdlib, lfortran, etc.
  • Process to suggest and discuss features for 202Y.
3 Likes

Great @awvwgk. Thank you for the Zoom link.

Here is the current agenda:

1) Teams for fpm, stdlib, lfortran, etc. (@certik)
2) Process to suggest and discuss features for 202Y (@certik)

Don’t hesitate to submit other items to the agenda!

I already opened threads for fpm and stdlib, where we can collect some ideas to refine further tomorrow at the call and continue the discussion afterwards:

How about the open position at the ACM Fortran Forum?

Fine for me :wink:
Here are more details.

Here is the updated agenda:

1) Teams for fpm, stdlib, lfortran, twitter (social media team), etc. (@certik)
2) Process to suggest and discuss features for 202Y (@certik)
3) Open position at the ACM Fortran Forum (@arjen)

Details for the position at the ACM Fortran Forum see details here

@awvwgk @certik Unfortunately I will not be able to join the meeting due to a last minute personal obligation. Could one of you lead the meeting, please?

Yes, I’ll lead the meeting.

1 Like

I would like to also discuss:

Quick summary from my notes

Maintainer teams

  • teams for fpm and stdlib in discussion, call for maintainers open
  • LFortran team will be organized by Ondrej
  • social media team (twitter, …)
  • webpage should get a team as well

Overview page for compilers

  • create overview page for all fpm packages with supported compilers

Fortran 202Y

  • community driven discussion
  • create extensive list of features
  • open poll for broad feedback
  • select features and work on proposals
  • be ready to submit once committee opens for new standard

Fortran 202X

Maintaining project under fortran-lang

  • generally agreed on
4 Likes

Regarding the 202Y standard, I think generics are the top priority. It is related to the development of the underlying libraries (one of the cornerstones of the Fortran ecosystem), including stdlib and fftpack.
After all, using fypp is a stopgap measure because of lacking generics, native support for generics is what I look forward to most for Fortran! :yum:
(see j3-fortran/generics (github.com))

1 Like

Recording is up now:

I dropped the recording here for the moment: sciebo

Yes, generics are part of 202Y, even WG5 agrees to that.

How would generics help with fftpack though? Note that currently the fypp like usage is not part of the generics effort, but I would like to change that. So it is important to be specific when it comes to generics.

I assume what you are looking forward is to “generate” functions for any kind (single/double precision) and possibly also any type (integer, real), and also any rank (1D, 2D, 3D, …, arrays). Is that correct?

Yes, I hope that many implementations, such as the function sin, can be applied to arbitrary kind and type with only one template. It seems that kind(precision) is more important to me, after all, real(4/8/10/16) has four kinds of precisions, writing four copies of the sin function does not seem to conform to common sense. (or something like Function kind specified by optional input · Issue #91 · j3-fortran/fortran_proposals (github.com))

Isn’t this generic content?

About any rank, we have elemental label and will have dimension(..).:heart:

1 Like

Or this: Allow an intent(out) arg

Yes it is in my mind, and I would even say this is the most important case. But the existing generic subgroup (I am part of it) has these use cases: generics/Generics_Use_Cases.txt at main · j3-fortran/generics · GitHub, and I need to make sure it prioritizes the above use case more.

1 Like

Note that there are (somewhat cumbersome) techniques to achieve support for multiple kinds with just one source version. If you want more variations, like various ranks, then either elemental routines will help or you need preprocessing like with fypp. But there is no need perse to keep multiple copies around merely for the sake of various kinds.