diff --git a/_posts/2022-06-09-Fortran-Newsletter-June-2022.md b/_posts/2022-06-09-Fortran-Newsletter-June-2022.md
new file mode 100644
index 000000000..9abaa7fbb
--- /dev/null
+++ b/_posts/2022-06-09-Fortran-Newsletter-June-2022.md
@@ -0,0 +1,506 @@
+---
+layout: post
+date: 2022-06-09
+title: "Fortran newsletter: June 2022"
+category: newsletter
+author: Milan Curcic, Alexis Perry-Holby, Ondřej Čertík, Henil Panchal
+---
+
+Welcome to the June 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
+
+Here's what's new in the fortran-lang.org repo:
+
+* [#401](https://github.com/fortran-lang/fortran-lang.org/pull/401):
+ Newsletter May 2022
+* [#403](https://github.com/fortran-lang/fortran-lang.org/pull/403):
+ Add SeisSol to package index
+
+Work in progress:
+
+* [#397](https://github.com/fortran-lang/fortran-lang.org/pull/397) (WIP):
+ Add NUFFT to package index
+* [#396](https://github.com/fortran-lang/fortran-lang.org/pull/396) (WIP):
+ Add OpenFFT to package index
+* [#395](https://github.com/fortran-lang/fortran-lang.org/pull/395) (WIP):
+ Add 2DECOMP&FFT to package index
+* [#394](https://github.com/fortran-lang/fortran-lang.org/pull/394) (WIP):
+ Add SLICOT to package index
+* [#393](https://github.com/fortran-lang/fortran-lang.org/pull/393) (WIP):
+ Add FATODE to package index
+* [#347](https://github.com/fortran-lang/fortran-lang.org/pull/347) (WIP):
+ Fortran Intrinsics
+
+[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/HEAD/CONTRIBUTING.md)
+for how to get started.
+
+## Fortran Standard Library
+
+Here's what's new in stdlib:
+
+* [#656](https://github.com/fortran-lang/stdlib/pull/656):
+ Add hint for building error with make
+* [#655](https://github.com/fortran-lang/stdlib/pull/655):
+ fixed 32-bit integer overflow in stdlib_io_npy
+* [#657](https://github.com/fortran-lang/stdlib/pull/657):
+ Remove support for manual make builds
+
+Work in progress:
+
+* [#660](https://github.com/fortran-lang/stdlib/pull/660) (WIP):
+ Fix erroneous gaussian quadrature points in gauss_legendre
+* [#659](https://github.com/fortran-lang/stdlib/pull/659) (WIP):
+ Readme update
+* [#652](https://github.com/fortran-lang/stdlib/pull/652) (WIP):
+ Feature: loadtxt skiprows and max_rows
+* [#625](https://github.com/fortran-lang/stdlib/pull/625) (WIP):
+ Gamma special function
+* [#611](https://github.com/fortran-lang/stdlib/pull/611) (WIP):
+ Hash maps
+* [#604](https://github.com/fortran-lang/stdlib/pull/604) (WIP):
+ Add get_argument, get_variable and set_variable
+* [#580](https://github.com/fortran-lang/stdlib/pull/580) (WIP):
+ Add terminal and color escape sequences
+* [#552](https://github.com/fortran-lang/stdlib/pull/552) (WIP):
+ fixed bug in stringlist
+* [#536](https://github.com/fortran-lang/stdlib/pull/536) (WIP):
+ Fix conversion warnings
+* [#520](https://github.com/fortran-lang/stdlib/pull/520) (WIP):
+ [stdlib_io] add `disp`(display variable values formatted).
+* [#517](https://github.com/fortran-lang/stdlib/pull/517) (WIP):
+ adding SPEC_TEMPLATE.md #504
+* [#514](https://github.com/fortran-lang/stdlib/pull/514) (WIP):
+ pop, drop & get with basic range feature for stringlist
+* [#491](https://github.com/fortran-lang/stdlib/pull/491) (WIP):
+ Stdlib linked list
+* [#473](https://github.com/fortran-lang/stdlib/pull/473) (WIP):
+ Error stop improvements
+* [#363](https://github.com/fortran-lang/stdlib/pull/363) (WIP):
+ Sorting string's characters according to their ASCII values
+* [#286](https://github.com/fortran-lang/stdlib/pull/286) (WIP):
+ Probability Distribution and Statistical Functions -- Beta Distribution Module
+* [#278](https://github.com/fortran-lang/stdlib/pull/278) (WIP):
+ Probability Distribution and Statistical Functions -- Gamma Distribution Module
+* [#189](https://github.com/fortran-lang/stdlib/pull/189) (WIP):
+ Initial implementation of COO / CSR sparse format
+
+
+
+Please help improve stdlib by testing and [reviewing pull requests](https://github.com/fortran-lang/stdlib/issues?q=is%3Apr+is%3Aopen+label%3A%22reviewers+needed%22)!
+
+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:
+
+* [#692](https://github.com/fortran-lang/fpm/pull/692):
+ Fix for non-portable GFortran `-J` flag in install script
+* [#693](https://github.com/fortran-lang/fpm/pull/693):
+ Fix show-model option
+
+Work in progress:
+
+* [#701](https://github.com/fortran-lang/fpm/pull/701) (WIP):
+ Some cleanups and minor fixes
+* [#686](https://github.com/fortran-lang/fpm/pull/686) (WIP):
+ fix: remove extra space from help-test cmd
+* [#685](https://github.com/fortran-lang/fpm/pull/685) (WIP):
+ fix: function for getting executable path
+* [#653](https://github.com/fortran-lang/fpm/pull/653) (WIP):
+ Enable profiles in toml
+* [#608](https://github.com/fortran-lang/fpm/pull/608) (WIP):
+ --env switch lets you specify the prefix of the compiler-related environment variables
+* [#539](https://github.com/fortran-lang/fpm/pull/539) (WIP):
+ Add parent packages into dependency tree
+* [#498](https://github.com/fortran-lang/fpm/pull/498) (WIP):
+ Compiler flags profiles
+
+`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://fpm.fortran-lang.org/en/tutorial)
+to learn how to build your package with fpm, and the [manifest reference](https://fpm.fortran-lang.org/en/spec/manifest.html)
+to learn what are all the things that you can specify in the fpm.toml file.
+
+* Browse existing *fpm* packages on the [fortran-lang website](https://fortran-lang.org/packages/fpm)
+* 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
+
+### Flang
+
+* FIR
+ * Initial lowering of the Fortran Do loop
+ * Lower Unstructured do loops
+* Driver
+ * Define the default frontend driver triple
+ * Add support for consuming LLVM IR/BC files
+ * Add support for -save-temps
+ * Switch to the MLIR coding style in the driver
+ * Fix driver method names overridden by the plugins
+ * Support parsing response files
+ * Make driver accept -module-dir
+ * Add support for generating executables on MacOSX/Darwin
+* OpenMP
+ * Add lowering stubs for OpenMP/OpenACC declarative constructs
+ * Added tests for taskwait and taskyield translation
+ * Restrict types for omp.parallel args
+ * Add omp.cancel and omp.cancellationpoint.
+ * Initial lowering of the OpenMP worksharing loop
+ * Lowering for task construct
+ * Support lowering to MLIR for ordered clause
+ * Support for Collapse
+ * Upstream the lowering of the parallel do combined construct
+ * Fix the types of worksharing-loop variables
+ * Change the OpenMP atomic read/write test cases
+* Runtime
+ * Correct emission & reading of unterminated final records
+ * Support B/O/Z editing of CHARACTER
+ * Use 1-based dim in transformational runtime error msg
+ * Change "unsupported" messages in the runtime to "not yet implemented"
+ * Fix input of NAN(...) on non-fast path
+ * Don't pad CHARACTER input at end of record unless PAD='YES'
+ * Enforce restrictions on unlimited format repetition
+ * (G0) for CHARACTER means (A), not (A0)
+ * BACKSPACE after non-advancing I/O
+ * Use proper prototypes in Fortran_main. NFCI
+ * Clean up asynchronous I/O APIs
+ * INQUIRE(UNIT=666,NUMBER=n) must set n=666
+ * Handle BACKSPACE after reading past EOF
+* Fix MAXLOC/MINLOC when MASK is scalar .FALSE.
+* Fix UBOUND() constant folding for parentheses expr
+* Support FINDLOC/MAXLOC/MINLOC with scalar mask
+* Handle common block with different sizes in same file
+* Add one semantic check for implicit interface
+* Fix semantics check for RETURN statement
+* Fix ICE for passing a label for non alternate return arguments
+* Add ExternalNameConversionPass to pass pipeline
+* Fix AllocaOp/AllocMemOp type conversion
+* Support external procedure passed as actual argument with implicit character type
+* Fix internal error with DATA-statement style initializers
+* Upstream support for POINTER assignment in FORALL
+* Enforce a program not including more than one main program
+* Retain binding label of entry subprograms
+* Fold intrinsic inquiry functions SAME_TYPE_AS() and EXTENDS_TYPE_OF()
+* Fold intrinsic functions SPACING() and RRSPACING()
+* Operands of SIGN() need not have same kind
+* Correct folding of SPREAD() for higher ranks
+* Refine handling of short character actual arguments
+* Ensure that structure constructors fold parameter references
+* Correct actual/dummy procedure compatibility for ALLOCATABLE/POINTER functions
+* Allow PDTs with LEN parameters in REDUCE()
+* Allow NULL() actual argument for optional dummy procedure
+* Allow implicit declaration of DATA objects in inner procedures
+* Refine error checking in specification expressions
+* Reverse a reversed type compatibility check
+* Accept POINTER followed by INTERFACE
+* Allow ENTRY function result symbol usage before the ENTRY
+* Fold real-valued DIM(), MODULO() and MOD()
+* Enforce limit on rank + corank
+* Allow local variables and function result inquiries in specification expressions
+* Change "bad kind" messages in the runtime to "not yet implemented"
+* Fold complex component references
+* Fix check for assumed-size arguments to SHAPE() & al.
+* Fix a performance problem with lowering of forall loops and creating too many temporaries
+* Warn for the limit on name length
+* Install Fortran_main library
+* test conforming & non-conforming lcobound
+* Fix use-associated false-positive error
+* Fix character length calculation for Unicode component
+* Allow global scope names that clash with intrinsic modules
+* Ignore BIND(C) binding name conflicts of inner procedures
+* Allow more forward references to ENTRY names
+* Extension: Accept Hollerith actual arguments as if they were BOZ
+* Alternate entry points with unused arguments
+* Fix crash in semantics after PDT instantiation
+
+
+### LFortran
+
+* Gagandeep Singh (106):
+ - Factored out visit_Declaration to visit_DeclarationUtil in CommonVisitor
+ - Added test for kwargs in class procedure
+ - Added support for kwargs in class procedures
+ - Updated reference tests
+ - Added support for i32 and i64 in repeat
+ - Added mergechar in merge interface
+ - Added is_iostat_eor
+ - Removed compulsory evaluation of ishft
+ - Updated reference tests
+ - Use intrinsic type checking in assignment only when operator overloading fails
+ - Perform casting in Compare only when overloaded is not available
+ - Set dest_type and source_type even though casting doesn't happen
+ - Use kind_value to generate type in ArraySize
+ - Added test for verifying SemanticError in case of non-constant kind input
+ - Updated reference tests
+ - Add AssociateBlock and Block in serialization.cpp
+ - Include associate_06 in the integration_tests/CMakeLists.txt
+ - Take into account output kind in LLVM's ArraySize visitor
+ - Added test for different output kinds in ArraySize
+ - Updated reference tests
+ - Import procedures for overloaded operators as well
+ - Fixed tests for compiling correctly with gfortran
+ - Mangle name before importing procedures under generic procs
+ - Merged master into sprint_6
+ - Avoid manual imports while using overloaded symbols
+ - Remove symbol from to_be_imported_later
+ - Added support for keyword arguments in generic procedures and fix total arguments
+ - Added test for generic procedures with keyword arguments
+ - Updated reference tests
+ - Added intrinsics: congjz, dotproduct and updated: merge
+ - Added matmul, transpose as ASR nodes
+ - Added tests for matmul and transpose
+ - Updated reference tests
+ - Added merge, dotproduct procedures for complex type
+ - Updated reference tests
+ - Add support for source kwarg in allocate
+ - Updated test for verifying source argument
+ - Updated reference tests
+ - Registered shiftr, shiftl, adjustr, lgt, llt, lge, lle, count in comptime_eval.h
+ - Added shiftl, shiftr and count
+ - Added more implementations for abs, mod
+ - Added adjustr, lgt, llt, lle, lge for string type
+ - Updated reference tests
+ - Registered ieee_is_nan in comptime_eval.h
+ - Added support for pack intrinsic
+ - Added support for transfer intrinsic
+ - Use modern Fortran syntax for array constants
+ - Updated reference tests
+ - ArrayTransfer -> Transfer rename
+ - Added generation code for expression replacer
+ - Added ReplaceArgVisitor and generalised handle_return_type
+ - Added tests for verifying arg replacer in return types
+ - Updated reference tests
+ - Added cmplx via ComplexConstructor node
+ - Updated reference tests
+ - Import via use inside Function
+ - Added support for matching Derived/ClassType
+ - Added support for falling back to intrinsic
+ - Added to test verify importing procedures inside function
+ - Updated reference tests
+ - Added support for passing kind parameter to floor intrinsic
+ - 1. Use CPtr for variables declared with type(c_ptr) 2. Set Module_t.m_intrinsic in set_intrinsic 3. Add CPtr in extract_dimensions_from_ttype
+ - Updated reference tests
+ - Added LLVM support for CLoc, CPtr
+ - Updated reference tests
+ - Added integration test for c_f_pointer
+ - Added support for c_f_pointer
+ - Updated reference tests
+ - Added error checking for presence of shape argument in c_f_pointer call
+ - Fixed ArrayConstant type and raise error is shape is not rank 1
+ - Updated reference tests
+ - Implemented c_f_pointer for non-array variables
+ - Updated reference tests
+ - Added test with pointer array variables
+ - Shifted type generation to a function in LLVM backend
+ - Corrected llvm::Type* for array pointer variables
+ - Updated reference tests
+ - 1. Fixed ArrayBound for array pointers 2. Shifted argument type generation to a function and use recursion for Pointer
+ - Added support for printing Pointer type
+ - 1. Added AssociateBlock symbol in PassVisitor 2. Fixed get_bound to return ArrayBound instead of a function call
+ - Use element type in ArrayRef instead of pointer
+ - Syntax improvement
+ - Updated reference tests
+ - Removed warnings
+ - Adjust ArrayBound for ArrayConstant
+ - Corrected arrays_13 by making iv, rv as target
+ - Stronger verification checks for CFPointer creation
+ - Support for array inputs in CFPointer
+ - Improved bindc2 for array inputs in c_f_pointer
+ - 1. Fixed ArraySize for array pointer variables in LLVM backend. 2. Improved CFPointer in LLVM backend to not interfere with already stored array in array pointer variables 3. Improved bindc2.f90 and made it robust to cover more cases. 4. Updated reference tests
+ - Fixed unused variable warnings in llvm_utils.cpp
+ - Use abstract methods in CFPointer for accessing array descriptor data
+ - Added test for ArrayRef in c_loc
+ - Minor update in bindc2 and bindc3
+ - Fixed Complex case in duplicate type and intialise type at declaration
+ - Added support ArrayRef in CLoc in LLVM backend
+ - Updated reference tests
+ - 1. Added support for CPtr in arguments and fixed llvm::Type for intent(out) for CPtr 2. Added support for constant arrays as shape in c_f_pointer
+ - Updated bindc4 for verifying constant arrays in c_f_pointer
+ - Updated reference tests
+
+* Naman Gera (1):
+ - Update the C runtime library
+
+* Ondřej Čertík (136):
+ - AST->ASR: Remove current_body
+ - Fix a bug in a test
+ - Update tests
+ - bind(c): Add tests for i64, f32, f64
+ - Update modules_18b.f90 to compile
+ - Add tests for the other types
+ - Comment out a non-working case
+ - Update tests
+ - bind(c): Fix call_fortran_i64
+ - Update tests
+ - bind(c): Add a test for i32 by value
+ - LLVM: implement value arguments in bind(c) procs
+ - Update tests
+ - Make modules_18b.f90 compile
+ - bind(c): test i64, f32, f64 by value
+ - Update modules_18b to compile
+ - Update tests
+ - ASR: Bring updates from LPython
+ - Update tests
+ - ASR: Updates from LPython
+ - Update the rest of the code to compile
+ - Update tests
+ - C++ backend: implement ComplexConstructor
+ - Add the simplest test for submodules
+ - Add Logical to nested_vars
+ - Workaround a cmake bug
+ - Add a test for bind(c) with pointers
+ - Rework the AST->ASR handling of floor()
+ - Implement is_intrinsic_symbol()
+ - Refactor floor() into lfortran_intrinsic_math3
+ - Update tests
+ - Add a test case for imported derived type
+ - Add value to all expr nodes except Constant
+ - Update tests
+ - Implement expr_type() using ExprTypeVisitor
+ - Implement expr_value() using ExprValueVisitor
+ - iso_c_binding: add the c_loc() function
+ - Allow derived types as return values
+ - ASR: Represent c_loc()
+ - Add ASR test for c_loc()
+ - Update tests
+ - ASR: Add string conversion for derived type
+ - Add a CPtr() type
+ - Make c_loc() return CPtr
+ - LLVM: handle CPtr in convert_args()
+ - LLVM: Comment out visit_CFPointer (WIP)
+ - CI: pin mkdocs-material and mkdocs versions
+ - Fix spelling
+ - Update tests
+ - Shorten the help for --show-wat to fit 80 columns
+ - Git ignore wasm_visitor.h
+ - Move emit_wat out of LLVM ifdef
+ - Generate wasm_visitor.h in ci/build.xsh
+ - Enable WAT tests in run_tests.py
+ - Add a test for WASM
+ - Update reference tests
+ - Implement FortranEvaluator::get_wasm()
+ - Use asr_to_wasm_bytes_stream() in asr_to_wasm
+ - WASM: Add 64 bit BinOp operations
+ - WASM: handle i64 arguments
+ - WASM: Add a test for i64
+ - Move the wasm_instructions_visitor.py to libasr
+ - Update ASR from LPython
+ - Update tests
+ - Bring more ASR improvements from LPython
+ - Bring in name mangling
+ - Update tests
+ - Add a test for passing through pointers via C
+ - LLVM: implement debug ASR printing
+ - LLVM: Use `deftype` to implement interfaces
+ - LLVM: Pass type(c_ptr) by value properly
+ - Pass "n" by reference for now
+ - Pass arguments by value for bind(c)
+ - Only do the load if it is a pointer
+ - LLVM: Use an ASR condition instead of LLVM one
+ - lfortran_intrinsic_string: depend iso_fortran_env
+ - Enable bindc_01 LLVM test
+ - Add a test for pointer argument
+ - Add suffixes 1/2
+ - Add a callback2b test
+ - Add a test for callback1b()
+ - Get value to reference argument working
+ - Port ASR improvements from LPython
+ - Update the rest of the code to compile
+ - Update tests
+ - ASR sync with LPython
+
+* Tapasweni Pathak (9):
+ - Add markdown sample for intrinsic:math:asin
+ - Add doxygen docstring in lfortran intrinsic runtime asin
+ - Add comments for interface asin
+ - Add doxygen comment for lfortran_sasin_api
+ - Enhance presentation of information
+ - use retval for return values variable
+ - delete fortran doxygen comments docs
+ - mkdocs: LFortran Intrinsics: asin
+ - add: mkdocs: code syntax highlighting
+
+* Ubaid (24):
+ - Improve ceiling() test case
+ - Update reference tests
+ - Specifying constants as double precision
+ - Update error condition check as suggested
+ - Update reference tests
+ - Code formatting
+ - Add and improve namespace ending comments
+ - Add wasm_instructions list
+ - Comment out few instructions that have temporary variables
+ - Add wasm_instructions_visitor script
+ - Add namespace related info and pass code as function parameter in wasm_insts_visitor script
+ - Add command in build0.sh to generate wasm_visitor.h
+ - Add utility struct and functions defined in wasm_utils
+ - Add wasm_to_wat converter
+ - Include wasm_to_wat and wasm_utils in CMakeLists.txt
+ - Define vector.resize()
+ - Add --show-wat flag and emit_wat() function
+ - Declare and define get_wat() in fortran_evaluator
+ - Declare and define asr_to_wasm_bytes_stream() which stores wasm binary to memory
+ - Fix warning by adding U and add comment
+ - Fix missing parameters bug
+ - Switch off WAT_DEBUG macro
+ - Remove debugging cout statements
+ - Move load_file() to top
+
+We are looking for new contributors. Please do not hesitate to contact us if you are interested. We will help you get up to speed.
+
+## Events
+
+* The Fortran-lang Google Summer of Code 2022 program began on May 23.
+ We welcome five contributors: Arteev Raina, Ashirwad Mishra,
+ Henil Shalin Panchal, Mohd Ubaid Shaikh, and Oshanath Rajawasam.
+ They will be working on exciting projects from fpm and the Fortran
+ website to improving the LFortran compiler.
+ Read more about their projects [here](https://summerofcode.withgoogle.com/programs/2022/organizations/fortran-lang).
+* We had our 26th Fortran Monthly call on May 16.
+ Watch the recording below:
+
+
+Join and follow the [Fortran 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/stdlib-cmake-example](https://github.com/fortran-lang/stdlib-cmake-example)
+* [fortran-lang/fpm](https://github.com/fortran-lang/fpm)
+* [fortran-lang/fpm-registry](https://github.com/fortran-lang/fpm-registry)
+* [fortran-lang/fpm-docs](https://github.com/fortran-lang/fpm-docs)
+* [fortran-lang/setup-fpm](https://github.com/fortran-lang/setup-fpm)
+* [fortran-lang/fpm-haskell](https://github.com/fortran-lang/fpm-haskell)
+* [fortran-lang/fortran-lang.org](https://github.com/fortran-lang/fortran-lang.org)
+* [fortran-lang/benchmarks](https://github.com/fortran-lang/benchmarks)
+* [fortran-lang/fortran-forum-article-template](https://github.com/fortran-lang/fortran-forum-article-template)
+* [fortran-lang/fftpack](https://github.com/fortran-lang/fftpack)
+* [fortran-lang/minpack](https://github.com/fortran-lang/minpack)
+* [fortran-lang/test-drive](https://github.com/fortran-lang/test-drive)
+* [fortran-lang/vscode-fortran-support](https://github.com/fortran-lang/vscode-fortran-support)
+* [j3-fortran/fortran\_proposals](https://github.com/j3-fortran/fortran_proposals)
+
+
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 54cd3a295..bd95ce779 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,6 +1,161 @@
{
"name": "fortran-lang/fortran-lang.org",
"issues": [
+ {
+ "number": 405,
+ "user": "henilp105",
+ "date": "2022-05-28 05:00:04+00:00",
+ "title": "Sphinx learn section ",
+ "text": "None",
+ "is_open": false,
+ "labels": [],
+ "comments": [
+ {
+ "user": "henilp105",
+ "date": "2022-05-28 05:00:42+00:00",
+ "text": "#build_preview"
+ },
+ {
+ "user": "github-actions[bot]",
+ "date": "2022-05-28 05:02:10+00:00",
+ "text": "This PR has been built with Jekyll and can be previewed at: https://fortran-lang.org/pr/405/"
+ },
+ {
+ "user": "henilp105",
+ "date": "2022-05-28 05:04:19+00:00",
+ "text": "#delete_preview"
+ },
+ {
+ "user": "github-actions[bot]",
+ "date": "2022-05-28 05:04:39+00:00",
+ "text": "The preview build for this PR has now been deleted."
+ }
+ ]
+ },
+ {
+ "number": 404,
+ "user": "gnikit",
+ "date": "2022-05-09 17:49:56+00:00",
+ "title": "Verifying VS Code Publisher",
+ "text": "Our VS Code Publisher is register as the Fortran Lang organisation and points to the official webpage https://fortran-lang.org. Microsoft allows for Organisations to verify their publisher IDs by proving they own the domain they list see: https://code.visualstudio.com/api/working-with-extensions/publishing-extension#verify-a-publisher\nI think it would make use look substantially more official if we verified the publisher ID.\nThese are the steps that need to be made in order to verify (copy-pasted from the manager portal of the publisher ID. @awvwgk can also view them if he logs in here and goes to Verified domain)\n\nCreate a TXT record in your DNS configuration for the following hostname:_visual-studio-marketplace-fortran-lang.fortran-lang.org\nUse this code as the value for the TXT ! redacted !\nWait until your DNS configuration changes. This could take up to 72 hours.\n\nI have redacted the value of the txt file in 2. in case this information is not set through a PR on GitHub but through some private backend. If that is the case, I can send the value privately or Sebastian can get it directly.",
+ "is_open": false,
+ "labels": [],
+ "comments": [
+ {
+ "user": "milancurcic",
+ "date": "2022-05-09 18:25:25+00:00",
+ "text": "Thanks @gnikit, the TXT record is now live."
+ },
+ {
+ "user": "gnikit",
+ "date": "2022-05-09 18:26:57+00:00",
+ "text": "Awesome, thanks a lot @awvwgk @milancurcic !"
+ }
+ ]
+ },
+ {
+ "number": 403,
+ "user": "ashirrwad",
+ "date": "2022-05-06 17:04:42+00:00",
+ "title": "Add SeisSol to package index",
+ "text": "Added the SeisSol package listed on Issue: #232 to the package index.",
+ "is_open": false,
+ "labels": [],
+ "comments": [
+ {
+ "user": "certik",
+ "date": "2022-05-06 17:20:41+00:00",
+ "text": "I also thought this is a C++ project with legacy Fortran, but it seems it has physics stuff in Fortran and it is still developed in Fortran (see e.g. SeisSol/SeisSol#536), so I would say this package fits into our index.\n(If it was just Fortran wrappers, then I would say we should have a category for Fortran wrappers to other packages.)"
+ },
+ {
+ "user": "ivan-pi",
+ "date": "2022-05-06 20:42:04+00:00",
+ "text": "For the record, the developers have told me they would like to remove Fortran soon. See also the comment here: #232 (comment). If you look closer, they already have an issue to migrate the physics stuff from Fortran to C++: SeisSol/SeisSol#538."
+ },
+ {
+ "user": "ashirrwad",
+ "date": "2022-05-07 09:12:00+00:00",
+ "text": "As the package was still a part of checklist on #232 and the library and its documentation showed references to Fortran usability I figured it was still up for addition. While I did stick to the guide the criterias for package addition are a bit ambiguous to me as I am new to the language. If the package doesn't meet the requirements I will add a PR to revert these changes as needed."
+ }
+ ]
+ },
+ {
+ "number": 402,
+ "user": "ivan-pi",
+ "date": "2022-05-04 19:55:58+00:00",
+ "title": "Debunking Fortran Myths",
+ "text": "There are several webpages, blogs, and articles, which try to debunk Fortran myths. I think having a QA section to help resolve misconceptions at Fortran-lang could be valuable.\nHere are a few links:\n\nMyths | FortranWiki\nDebunking the myths about Fortran | ACM Fortran Forum (a PDF is available here)\nFortran Myths & Disinformation Wanted | comp.lang.fortran\nWhy do people think Fortran programs are hard to read? | Quora\nWhy do people think Fortran is so bad? | Quora\nWill Julia replace Fortran for high performance computing? | Quora\nIs Fortran still used in 2021? | Quora\nTHE MYTHS OF FORTRAN |\u00a0The Craft of Coding (Michael Wirth has several very lucid essays about Fortran)\nFortran is still a thing | Words and Buttons Online\nDEFY, DEmystify Fortran mYths |\u00a0Szaghi\nIn Numerical Computing with Modern Fortran, pg. 58, Hanson & Hopkins write,\n\n... we attempt to convince the reader that Fortran recursion is an important and efficient programming technique. We will dispel some myths ...\n\n\nWhy Fortran? | NCAR |\u00a0DART \nFortran: Tales of the Living Dead? | The Delocalized Physicist\nWHO SAID FORTRAN IS DEAD? | Hackaday\n2.0.7 Dinosaurs | This Developer's Life\nThe Joy of Fortran | OCEANOGRAPHER'S CHOICE\n\nRoughly, I see two categories of misconceptions,\n\nthose affecting programmers with little or no prior knowledge/awareness of Fortran\nthose affecting Fortran programmers, who may only be familiar with a fraction of the standard\n\nI was thinking about this topic while watching a lecture by Dan Saks on \"Talking to C Programmers about C++\". Here's a quote he refers to on several occasions:\n\n\u201cIf you\u2019re arguing, you\u2019re losing.\u201d \u2014 Mike Thomas\n\nSome parts of the lecture are summarised here.\nPerhaps by linking such an article in replies on HackerNews, Stack OverFlow, Quora, etc., we could slowly turn the tide against misinformation surrounding Fortran.",
+ "is_open": true,
+ "labels": [],
+ "comments": [
+ {
+ "user": "ivan-pi",
+ "date": "2022-05-04 22:57:51+00:00",
+ "text": "The various journals from ACM have many good articles on the reasons behind Fortran:\n\nHow Not to Write FORTRAN in Any Language | acmqueue\nThe Ideal HPC Programming Language: Maybe it's Fortran. Or maybe it just doesn't matter. | acmqueue\n\nWe undertook such an exercise to get a feel for what an \"ideal\" programming language for HPC applications might look like. ... Almost immediately, we were struck by what we were seeing. ... surprisingly, the \"ideal\" programming language was basically Fortran.\n\n\nHas Fortran a future? | ACM Fortran Forum\nWhy Fortran? |\u00a0ACM Fortran Forum\nWhither Fortran? | ACM Fortran Forum\nFortran Matters | SD Times\n\nThe Fortran articles in CiSE also give many good reasons for Fortran:\n\nWhy Fortran?\nThe State of Fortran \ud83d\ude80\n\nPerhaps we could even share some of the opinions from famous (computer) scientists:\n\nFortran is harder to compete with. It has a dedicated following who [...] care little for programming languages or the finer points of computer science. They simply want to get their work done. \u2014 Bjarne Stroustrup\n\nbut I'm afraid this may backfire at some point."
+ }
+ ]
+ },
+ {
+ "number": 401,
+ "user": "milancurcic",
+ "date": "2022-04-30 20:14:34+00:00",
+ "title": "Newsletter May 2022",
+ "text": "Here's the newsletter draft:\n\n Draft text\n GitHub stats data\n Flang updates by @AlexisPerry\n LFortran updates by @certik @czgdp1807 or @HaoZeke\n\nLet's plan to merge by Friday, May 6.\nThank you!",
+ "is_open": false,
+ "labels": [],
+ "comments": [
+ {
+ "user": "AlexisPerry",
+ "date": "2022-05-04 16:28:33+00:00",
+ "text": "Please see milancurcic#7 for Flang updates. Thanks!"
+ },
+ {
+ "user": "gnikit",
+ "date": "2022-05-04 22:49:03+00:00",
+ "text": "@milancurcic would you like me to write a short announcement in May's newsletter for Modern Fortran migrating to fortran-lang?"
+ },
+ {
+ "user": "milancurcic",
+ "date": "2022-05-04 22:55:53+00:00",
+ "text": "@gnikit yes, please! I forgot about that. I think best to add it as a bullet point under events. Feel free to commit directly to this PR branch and add your name to the authors list. Thank you!"
+ },
+ {
+ "user": "gnikit",
+ "date": "2022-05-05 06:48:16+00:00",
+ "text": "Done, I was unable to push to your branch so I opened a separate PR. I hope that's okay. see milancurcic#8"
+ },
+ {
+ "user": "certik",
+ "date": "2022-05-05 13:45:50+00:00",
+ "text": "@czgdp1807, @HaoZeke is one of you able to put in LFortran updates?"
+ },
+ {
+ "user": "czgdp1807",
+ "date": "2022-05-05 13:46:36+00:00",
+ "text": "I can do it tonight (my time) i.e., in 3 - 4 hours. @HaoZeke Feel free to go ahead if you can do it before that."
+ },
+ {
+ "user": "certik",
+ "date": "2022-05-05 13:47:55+00:00",
+ "text": "Thanks @czgdp1807, I really appreciate it!"
+ },
+ {
+ "user": "czgdp1807",
+ "date": "2022-05-05 14:51:15+00:00",
+ "text": "I have started working on it."
+ },
+ {
+ "user": "czgdp1807",
+ "date": "2022-05-05 15:05:54+00:00",
+ "text": "Done. See the LFortran updates in milancurcic#9"
+ },
+ {
+ "user": "milancurcic",
+ "date": "2022-05-05 15:09:38+00:00",
+ "text": "Thanks all! We have all the updates now. Let's merge later today if there are no objections."
+ }
+ ]
+ },
{
"number": 400,
"user": "p-costa",
@@ -5030,6 +5185,21 @@
"user": "gklimowicz",
"date": "2022-04-27 17:02:41+00:00",
"text": "Out of curiosity, is anyone creating a Git project with as many of these projects as possible as submodules? I will find myself in need of as large a corpus of Fortran codes as I can lay my hands on, and these are all silos of grain for my mill."
+ },
+ {
+ "user": "ivan-pi",
+ "date": "2022-05-06 20:48:43+00:00",
+ "text": "Hi @gklimowicz, I'm not aware of any of us within Fortran-Lang having done something like that. Is it compiler testing you have in mind?\nPerhaps worth asking @jeffhammond. He was recently searching for Fortran codes on Twitter."
+ },
+ {
+ "user": "jeffhammond",
+ "date": "2022-05-07 07:43:30+00:00",
+ "text": "https://github.com/Beliavsky/Fortran-code-on-GitHub was useful to me. I wrote a script to clone every repo it references. Was about 25MLOC I think.\nI recommend Dalton (GitLab) and NWChem (GitHub) for Fortran testing. Those are both huge codes. Mostly legacy stuff."
+ },
+ {
+ "user": "gklimowicz",
+ "date": "2022-05-07 17:43:05+00:00",
+ "text": "@jeffhammond @Beliavsky @ivan-pi Thanks, Jeff and Ivan. I will dig into our chess-playing friend's repo and see if there is anything I've come across to suggest add to it.\nI'm planning to work on something of an over-extended Fortran semantic analyzer, so Dalton and NWChem are good, too.\nKeep those cards and letters coming. :-)"
}
]
},
diff --git a/community/github_stats_data/data-fortran-lang-fpm.json b/community/github_stats_data/data-fortran-lang-fpm.json
index 2fa2cda98..26d54a7e0 100644
--- a/community/github_stats_data/data-fortran-lang-fpm.json
+++ b/community/github_stats_data/data-fortran-lang-fpm.json
@@ -1,15 +1,109 @@
{
"name": "fortran-lang/fpm",
"issues": [
+ {
+ "number": 702,
+ "user": "awvwgk",
+ "date": "2022-06-03 11:09:24+00:00",
+ "title": "Bump version to 0.6.0",
+ "text": "Feel free to merge and release following the guide at https://github.com/fortran-lang/fpm/wiki/Release-Process\nTest release at https://github.com/awvwgk/fortran-package-manager/releases/tag/v0.6.0\nCloses #679",
+ "is_open": true,
+ "labels": [],
+ "comments": []
+ },
+ {
+ "number": 701,
+ "user": "zoziha",
+ "date": "2022-05-27 19:13:24+00:00",
+ "title": "Some cleanups and minor fixes",
+ "text": "Description\nWhile using fpm and reading the fpm source code, I have found some small areas for improvement, as they tend to be small and have little impact on the overall functionality of fpm, and it doesn't seem worth it to list them as a single PR.\nUpdates\nThe work this PR does:\n\nDelete the unused fnv_1a reference;\nUpdate number_of_rows, remove unnecessary character reading;\nUpdate mkdir and os_delete_dir, the output format of which is somewhat complicated, and the current modification is unified with the following style:\n\n \n \n fpm/src/fpm_filesystem.F90\n \n \n Line 906\n in\n aec789f\n \n \n \n \n\n \n \n if(echo_local) print *, '+ ', cmd \n \n \n \n\n\nLogical operators using ==, /=, etc. are more intuitive and modern than .eq., .ne.;\nThe display of compilation percentage output style has been corrected;\n\n[ 24%]Compiling ... # Original\n[ 24%] Compiling ... # Now\n\nIn the new_test test, the wildcard command line used in CMD shell on Windows did not actually take effect, which was corrected;\n\n\ud83d\udce2 PS. I made a single commit record for each fix, it would be simple enough to review them in turn.",
+ "is_open": true,
+ "labels": [],
+ "comments": [
+ {
+ "user": "zoziha",
+ "date": "2022-05-28 11:47:12+00:00",
+ "text": "Thanks for reviewing, @LKedward .\n\n\nAre you able to fix this line in new-test as well: \n \n \n fpm/test/new_test/new_test.f90\n \n \n Line 156\n in\n cd8b5cc\n \n \n \n \n\n \n \n rm_command = 'rmdir ' // dirs_to_be_removed // ' /s /q' \n \n \n \n\n\n\n\nSorry I didn't see this line of code before, I'll update my commit to fix it.\n\n\nIn backend_output, perhaps we should just declare overall_progress with length 7 and remove the (:7) indexing?\n\n\nNice suggestion ~"
+ }
+ ]
+ },
+ {
+ "number": 700,
+ "user": "rouson",
+ "date": "2022-05-23 04:59:59+00:00",
+ "title": "Option to ignore subdirectories and/or files",
+ "text": "Description\nWhen adding fpm to a project that already has one or more non-fpm build system(s) (e.g., ones based on make or cmake), not being able to tell fpm to ignore certain subdirectories and/or files means the involved files must be moved out of the locations where fpm attempts to build every file found. Any such directory/file moves are likely to necessitate changes to the other build system(s). Also, there's the social issue associated with having to ask for what sometimes feels like a big change to a project.\nPossible Solution\nAdd a feature that gives users the ability to specify in the manifest that a certain subdirectory or file should be ignored. Being able to insert something like the following in a fpm.toml file might suffice:\n[ignore]\nsrc/ignore-me\n\nAdditional Information\nNo response",
+ "is_open": true,
+ "labels": [
+ "enhancement"
+ ],
+ "comments": []
+ },
+ {
+ "number": 698,
+ "user": "wyphan",
+ "date": "2022-05-18 15:51:58+00:00",
+ "title": "fpm build failure with NAG 7.0",
+ "text": "Description\nContinuing the discussion in #690 about building fpm with NAG Fortran.\nBuilding fpm with NAG Fortran 7.0 currently gives an internal compiler error (ICE).\nPanic: fpm.F90: High word of Uindex must be zero\nInternal Error -- please report this bug\nAbort\nSee https://gist.github.com/wyphan/03b095763e25f5639db21c01e0d7cc3b for the full build log.\nExpected Behaviour\nfpm can be built with NAG nagfor.\nThis is important because NAG is arguably the most standard-conforming Fortran compiler out there.\nVersion of fpm\nLatest develop at time of writing aec789f\nPlatform and Architecture\nLinux x86_64 (CentOS 7)\nAdditional Information\nI'm not too familiar yet with the NAG compiler. I intend to submit the bug report to NAG, but will need extensive help to pinpoint where the ICE comes from, so I can make a reproducer code.",
+ "is_open": true,
+ "labels": [
+ "bug"
+ ],
+ "comments": [
+ {
+ "user": "awvwgk",
+ "date": "2022-05-18 16:50:27+00:00",
+ "text": "Panic: fpm.F90: High word of Uindex must be zero\nInternal Error -- please report this bug\n\nPlease follow the suggestion in the compiler output and report this as a bug to NAG. They are taking compiler bugs very serious will most likely come back to you with a new release including a fix quickly."
+ },
+ {
+ "user": "wyphan",
+ "date": "2022-05-18 16:51:42+00:00",
+ "text": "Can someone who has access to version 7.1 try to reproduce this issue? So I don't waste time performing bug isolation on a bug that is already fixed \ud83d\ude02"
+ },
+ {
+ "user": "awvwgk",
+ "date": "2022-05-18 16:58:32+00:00",
+ "text": "NAG 7.1 does fail at fpm_command_line.f90 with\nWarning: ./src/fpm_command_line.f90, line 607: Unused local variable FLAGS\nWarning: ./src/fpm_command_line.f90, line 1298: FNV_1A explicitly imported into FPM_COMMAND_LINE but not used\nWarning: ./src/fpm_command_line.f90, line 1298: INPUT_UNIT explicitly imported into FPM_COMMAND_LINE (as STDIN) but not used\nWarning: ./src/fpm_command_line.f90, line 1298: LOWER explicitly imported into FPM_COMMAND_LINE but not used\n[NAG Fortran Compiler normal termination, 4 warnings]\n./src/fpm_command_line.f90: In function \u2018fpm_command_line_MP_get_command_line_settings\u2019:\n./src/fpm_command_line.f90:462:39: error: invalid type argument of \u2018->\u2019 (have \u2018struct fpm_command_line_DT_fpm_build_settings\u2019)\n install_settings = fpm_install_settings(&\n ^~\n./src/fpm_command_line.f90:462:39: error: invalid type argument of \u2018->\u2019 (have \u2018struct fpm_command_line_DT_fpm_build_settings\u2019)\n install_settings = fpm_install_settings(&\n ^~\n\nMeaning I didn't reach fpm.F90 so far, the ICE could still be present."
+ },
+ {
+ "user": "wyphan",
+ "date": "2022-05-19 14:46:12+00:00",
+ "text": "IIRC the ICE with 7.0 happens when bootstrapping with the single source file fpm.F90 right after it has been downloaded with curl/wget, not the main program fpm.f90 in the repo at src/fpm.f90."
+ },
+ {
+ "user": "awvwgk",
+ "date": "2022-05-19 19:35:24+00:00",
+ "text": "Same error as shown above using the install script with\nFC=nagfor FFLAGS=\"\" ./install.sh\n\nThe line number is a bit changed but it is the same piece of code\n[NAG Fortran Compiler normal termination, 138 warnings]\nfpm.F90: In function \u2018fpm_command_line_MP_get_command_line_settings\u2019:\nfpm.F90:11526:39: error: invalid type argument of \u2018->\u2019 (have \u2018struct fpm_command_line_DT_fpm_build_settings\u2019)\n install_settings = fpm_install_settings(&\n ^~\nfpm.F90:11526:39: error: invalid type argument of \u2018->\u2019 (have \u2018struct fpm_command_line_DT_fpm_build_settings\u2019)\n install_settings = fpm_install_settings(&\n ^~"
+ }
+ ]
+ },
+ {
+ "number": 697,
+ "user": "wyphan",
+ "date": "2022-05-18 15:44:06+00:00",
+ "title": "Remove warning message when building fpm",
+ "text": "Description\nThis is not a game-breaking bug by any means, but it would be nice if this warning message when building fpm no longer shows up at the link phase.\n/usr/bin/ld: build/gfortran_367ECB55A902040F/fpm/libfpm.a(src_fpm_filesystem.F90.o): in function `__fpm_filesystem_MOD_get_temp_filename':\n/fpm/./src/fpm_filesystem.F90:591: warning: the use of `tempnam' is dangerous, better use `mkstemp'\nExpected Behaviour\nBuilding fpm does not emit any warning messages.\nVersion of fpm\nIt's been there for a while, incuding latest develop (at the time of writing) aec789f\nPlatform and Architecture\nLinux x86_64 (Ubuntu 20.04 LTS)\nAdditional Information\nNo response",
+ "is_open": true,
+ "labels": [
+ "bug"
+ ],
+ "comments": []
+ },
{
"number": 693,
"user": "zoziha",
"date": "2022-04-28 13:06:23+00:00",
"title": "Fix show-model option",
"text": "To close #615 .\nInit the f_source%link_libraries array length as 0.",
- "is_open": true,
+ "is_open": false,
"labels": [],
- "comments": []
+ "comments": [
+ {
+ "user": "zoziha",
+ "date": "2022-05-27 19:18:45+00:00",
+ "text": "This is a relatively small correction, mainly to initialize the length of the allocatable array f_source%link_libraries to prevent access segfaults.\nIf possible, it seems that the PR can pass ~"
+ }
+ ]
},
{
"number": 692,
@@ -17,9 +111,15 @@
"date": "2022-04-23 18:25:02+00:00",
"title": "Fix for non-portable GFortran `-J` flag in install script",
"text": "None",
- "is_open": true,
+ "is_open": false,
"labels": [],
- "comments": []
+ "comments": [
+ {
+ "user": "wyphan",
+ "date": "2022-05-18 14:41:38+00:00",
+ "text": "Can we use cd instead of pushd to avoid the issue with non-bash shells?\n\nI wrote a custom pushd and popd (without the stack) to deal with non-bash shells, and that's the part that I need extra testing...\n\nOr if we want to stay with bash, why not just change the shebang to require a bash?\n\nI honestly prefer portability so fpm can be installed anywhere, even on minimalist distros like Alpine or TinyCore. This would be beneficial for Docker usage."
+ }
+ ]
},
{
"number": 691,
@@ -63,7 +163,7 @@
"date": "2022-04-20 00:24:06+00:00",
"title": "Module output directory flag in bootstrap install script",
"text": "Description\nWhen trying to build fpm with NAG Fortran compiler nagfor 7.0, I discovered that the install script currently hardcodes the GCC flag -J for where to output generated .mod module files.\n\n \n \n fpm/install.sh\n \n \n Line 67\n in\n c841456\n \n \n \n \n\n \n \n $FC $FFLAGS -J $BOOTSTRAP_DIR $BOOTSTRAP_DIR/fpm.F90 -o $BOOTSTRAP_DIR/fpm \n \n \n \n\n\nThis prevents compiling the bootstrap version with compilers other than gfortran.\nNAG nagfor fortunately gives a helpful error message that enabled me to figure this out:\nNAG Fortran Compiler Release 7.0(Yurakucho) Build 7003\nOption error: Unrecognised option -J\nExpected Behaviour\nI think there should be some kind of database in the install script for this particular compile flag.\nThe contents for now will be\n\n\n\nCompiler\nmodule output flag\n\n\n\n\nGCC gfortran\n-J\n\n\nNAG nagfor\n-mdir\n\n\nIntel ifort\n-module\n\n\n\nMore compilers, e.g. NVIDIA nvfortran, Cray ftn, AMD AOCC flang (= \"classic\" flang), Arm armflang, etc. can then be added as they're tested.\nVersion of fpm\n0.5.0\nPlatform and Architecture\nLinux (CentOS 7) x86\nAdditional Information\nI can also test on Windows if needed.",
- "is_open": true,
+ "is_open": false,
"labels": [
"bug"
],
@@ -102,6 +202,21 @@
"user": "wyphan",
"date": "2022-04-23 18:41:49+00:00",
"text": "Btw, building fpm with NAG 7.0 gives an internal compiler error (ICE)!\nSee https://gist.github.com/wyphan/03b095763e25f5639db21c01e0d7cc3b for more details."
+ },
+ {
+ "user": "wyphan",
+ "date": "2022-05-18 15:45:23+00:00",
+ "text": "PR #692 just merged! \ud83c\udf89\nInstead of using pushd and popd, we use plain old cd following @awvwgk 's suggestion.\nBtw, should I create a separate issue for the NAG build failure and close this one?"
+ },
+ {
+ "user": "awvwgk",
+ "date": "2022-05-18 15:46:16+00:00",
+ "text": "Sure do this"
+ },
+ {
+ "user": "wyphan",
+ "date": "2022-05-18 15:52:23+00:00",
+ "text": "Issue #698 opened to continue the discussion there."
}
]
},
@@ -152,7 +267,7 @@
"user": "rouson",
"date": "2022-04-06 22:03:34+00:00",
"title": "Option to output dependency tree",
- "text": "Description\nI assume that fpm constructs some form of dependency dependency tree. It would be nice to have an option that prints the dependency tree for a project. This is especially useful for a developer who encounters a new project that doesn't have such information in the documentation. Specifically, if one is going to contribute to a project, dependency information can be really useful in determining the number of places that could be impacted by changes in one given place.\nPossible Solution\nAdd a --dependency-tree flag that prompts the printing of whatever data structure fpm uses to store this information.\nAdditional Information\nNo response",
+ "text": "Description\nI assume that fpm constructs some form of module dependency tree. It would be nice to have an option that prints the dependency tree for a project. This is especially useful for a developer who encounters a new project that doesn't have such information in the documentation. Specifically, if one is going to contribute to a project, dependency information can be really useful in determining the number of places that could be impacted by changes in one given place.\nPossible Solution\nAdd a --dependency-tree flag that prompts the printing of whatever data structure fpm uses to store this information.\nAdditional Information\nNo response",
"is_open": true,
"labels": [
"enhancement"
@@ -162,6 +277,11 @@
"user": "milancurcic",
"date": "2022-04-07 01:06:31+00:00",
"text": "Similar question in #682."
+ },
+ {
+ "user": "rouson",
+ "date": "2022-05-01 20:13:46+00:00",
+ "text": "@milancurcic I just realized that #682 addresses a different topic but related topic. I'm referring to module dependencies, which might be mostly internal and could exist even in a project with no dependencies on external projects. I've added the word \"module\" in this issue's title and initial comment to make my request more clear. I'm seeking information that's useful for refactoring. Seeing a module dependency tree could be very helpful in determining which modules could be impacted by changes in any given module."
}
]
},
@@ -210,6 +330,11 @@
"user": "awvwgk",
"date": "2022-03-19 08:23:01+00:00",
"text": "No, this is currently not possible. See my answer in #655 for things to consider in case anyone wants to pick this up."
+ },
+ {
+ "user": "wyphan",
+ "date": "2022-05-20 08:05:20+00:00",
+ "text": "Thanks @awvwgk for mentioning this in the Spack issue #79.\nSpack does handle RPATH issues quite nicely for Linux and MacOS: https://spack.readthedocs.io/en/latest/packaging_guide.html#handling-rpaths\nI'm not too familiar with DLLs to comment on how to resolve this for Windows."
}
]
},
@@ -283,13 +408,83 @@
"date": "2022-03-13 18:13:28+00:00",
"title": "Tree shaking for modules",
"text": "Experimental changes to implement limited dependency tree-shaking/pruning just for modules (#635)\n\nSource parsing is updated to detect files that only contain modules (FPM_UNIT_MODULE)\n\nIf a source contains anything outside of a module, then that source cannot be pruned\nPruning is only supported for modules with an end module statement since this is used to detect if anything is outside a module. Modules without an end module statement will always be built and linked.\n\n\nNew prune_build_targets subroutine to perform tree-shaking/pruning of supported modules\n\nSupported modules are pruned by recursively enumerating used module dependencies down from the executables\nIf there are no executables, then module dependencies are enumerated from all sources in the top-level package (so only modules from dependencies are pruned)\nSubmodules are pruned if their parents aren't used anywhere\nSources that are not pure modules (FPM_UNIT_SUBPROGRAM) are never pruned\n\n\n\nPlease test and give feedback; there are possibly more edge cases that I have not considered.\nTODO:\n\n Further testing\n Prune based on root package modules when no executables\n Add --all--no-prune flag to fpm build to skip pruning",
- "is_open": true,
+ "is_open": false,
"labels": [],
"comments": [
{
"user": "milancurcic",
"date": "2022-03-14 01:14:57+00:00",
"text": "This is a very exciting update, thank you for working on it. I will test it this week. For the skip pruning option, I suggest a --no-prune flag as it's more specific, and it may be that --all will be more appropriate for some other feature."
+ },
+ {
+ "user": "milancurcic",
+ "date": "2022-05-08 20:30:43+00:00",
+ "text": "Thanks @awvwgk.\n\nThe initial preparation step for the tree-shaking is quite costly, for a project of mine it took ~1 min before starting the build (8 projects, 135 files, 37k LOC, tblite/tblite).\n\nOn my 2014 low-end laptop it took 26 s, which nevertheless is quite long. Granted, this is a quite large project--wIth dependencies it's over 100K LOC. I believe all dependency source files need to be parsed before the build can begin (correct me if I'm wrong). I think this project is a good test-case to use to get pruning to work the way we want it.\nHow do you suggest improving this? At the very least, we should print a message to the stdout that the pruning in progress may take a while, otherwise the user will think that fpm hung.\nA possibility is to develop a heuristic to automatically disable pruning if the size of the root project (e.g. measured in LOC) is large relative to individual dependencies. This seems quite involved to do well and could perhaps be a future GSoC project.\n\nWorse, the build eventually failed because in jacobwilliams/json-fortran a couple of modules were pruned.\n\nI can reproduce this with a minimal project that doesn't use json-fortran, but lists it as a dependency. With pruning enabled it attempts to build json-fortran (which it shouldn't), but then it either prunes out a module that's needed, or it messes up the build sequence. I can't tell yet which part of the introduced logic causes this behavior. I agree this should be resolved before moving forward."
+ },
+ {
+ "user": "ivan-pi",
+ "date": "2022-05-08 20:54:18+00:00",
+ "text": "Could the long time be explained by the use of a recursive subroutine? Some profiling may explain where the majority of time is spent, and what is the bottleneck."
+ },
+ {
+ "user": "awvwgk",
+ "date": "2022-05-08 20:56:54+00:00",
+ "text": "On my 2014 low-end laptop it took 26 s, which nevertheless is quite long. Granted, this is a quite large project--wIth dependencies it's over 100K LOC. I believe all dependency source files need to be parsed before the build can begin (correct me if I'm wrong). I think this project is a good test-case to use to get pruning to work the way we want it.\n\nCertainly not a large one, maybe medium-sized. Large projects in the Fortran world have several million lines of codes. Another good test project is John's general-purpose-fortran.\nRegarding the bottleneck, I recommend to do some profiling. I doubt the source scanner will be a time consuming step, but I spotted a couple of quadratic scaling search loops when looking through the patch.\nIf it turns out that we cannot reduce the startup time for this feature, we have to defer the time consuming step to runtime and create the build graph dynamically. This strategy is quite successful in meson/CMake generated ninja files, which callback into their parent build system for dynamically determining dependencies, startup time is instantaneous and the dependency resolution never fails."
+ },
+ {
+ "user": "LKedward",
+ "date": "2022-05-09 06:33:01+00:00",
+ "text": "Thanks all for testing and the feedback! I didn't test on a large project so that's been useful; I now realise that I missed a redundancy check from the recursive enumeration of modules, which is probably the cause of the poor scaling, so I'll add that in.\nNot sure what could be causing the other issue, I'll look into that."
+ },
+ {
+ "user": "LKedward",
+ "date": "2022-05-09 10:54:51+00:00",
+ "text": "Adding the missing redundancy check to the recursive exploration has reduced the startup time for large projects. Pruning now adds about 5% to the startup time for tblite compared to the main branch on my machine. Please can you test again for yourselves since I didn't encounter startup times of the same order as you two for tblite (about 10secs on 2014 i7 prior to adding redundancy checks, and now about 2.3secs).\nThe issues with json-fortran were twofold: first, I wasn't enumerating used modules in non-module sources (which can't be pruned) and; the json sources were being misidentified as non-module sources because of preprocessor lines. I've pushed fixes and tests for these as well."
+ },
+ {
+ "user": "milancurcic",
+ "date": "2022-05-10 21:36:10+00:00",
+ "text": "Hmm, with the recent updates, fpm doesn't seem to prune for me. To reproduce:\nfpm new a\ncd a\n\nAdd to fpm.toml:\n[dependencies]\ntblite = { git=\"https://github.com/tblite/tblite\" }\n\nthen run fpm build. I expected fpm to not build tblite and dependencies, but it does.\nIf I run it with fpm build --no-prune, it builds more stuff, which makes me realize that the first run did prune some stuff.\nThen I compared the two and found that with --no-prune, fpm build 253 files, and 81 otherwise.\nMy question is, if I don't use a dependency at all in my programs and modules, but it's listed in fpm.toml as a dependency, is fpm with pruning expected to build some of that dependency? I didn't think so, but maybe I'm wrong."
+ },
+ {
+ "user": "LKedward",
+ "date": "2022-05-11 15:57:57+00:00",
+ "text": "Thanks for checking @milancurcic - I can confirm that this is expected behavior because dftd4 (a dependency of tblite) contains a non-module source file compat.f90 which is classified as such since it contains a subroutine defined outside of a module: generate_wsc. Based on the information that fpm has, we cannot prune this file nor any of the modules it uses, hence the parts that got built in your test.\n\nMy question is, if I don't use a dependency at all in my programs and modules, but it's listed in fpm.toml as a dependency, is fpm with pruning expected to build some of that dependency?\n\nSo to answer your question directly: yes, if you don't use a dependency via a use statement then that dependency shouldn't be built, except for source files that contain functions/subroutines defined outside of a module and c source files (which we cannot currently prune based on the information that fpm has)."
+ },
+ {
+ "user": "milancurcic",
+ "date": "2022-05-11 16:01:53+00:00",
+ "text": "@LKedward Ah! I forgot about that. All clear. I will continue testing with a few packages of varying sizes."
+ },
+ {
+ "user": "awvwgk",
+ "date": "2022-05-11 16:31:40+00:00",
+ "text": "Thanks for the fix, I can depend on json-fortran again \ud83c\udf89.\nAnother edge case for the pruning, this time a smaller project (~95k LOC in 205 files in 5 projects, s-dftd3), well not really smaller. I'm currently not enabling tests for the C-API because we haven't released an fpm version supporting it yet, but if you try to build the C-API tester it will fail due to the bind(c) API export getting pruned without any Fortran users.\nApply this patch on top of the current head:\ndiff --git a/fpm.toml b/fpm.toml\nindex 249d6db..265eeff 100644\n--- a/fpm.toml\n+++ b/fpm.toml\n@@ -24,3 +24,8 @@ dependencies.toml-f.git = \"https://github.com/toml-f/toml-f\"\n [[test]]\n name = \"tester\"\n source-dir = \"test/unit\"\n+\n+[[test]]\n+name = \"api-tester\"\n+source-dir = \"test/api\"\n+main = \"api-test.c\"\nTry to run a fresh build for the tests\n\u276f ../fortran-package-manager/_pull/676/bin/fpm test api-tester\n...\napi-tester failed.\n[ 97%]Compiling...\n/usr/bin/ld: build/gfortran_EA1B3FB6891FF6E5/s-dftd3/test_api_api-test.c.o: in function `show_error':\n/home/awvwgk/projects/src/git/s-dftd3/test/api/api-test.c:27: undefined reference to `dftd3_get_error'\n...\n/usr/bin/ld: /home/awvwgk/projects/src/git/s-dftd3/test/api/api-test.c:178: undefined reference to `dftd3_delete_error'\ncollect2: error: ld returned 1 exit status\n Compilation failed for object \" api-tester \"\nstopping due to failed compilation\nSTOP 1\n\nSame holds for most of the projects I'm developing, they have an api.f90 file somewhere defining a C-API via bind(c) which is than consumed at least in a unit test, but usually by actual C or Python side users. You can find a similar setup in minpack as well, which is even smaller for testing this behavior."
+ },
+ {
+ "user": "LKedward",
+ "date": "2022-05-12 09:02:52+00:00",
+ "text": "Thanks @awvwgk - yes this is another scenario I missed. I think it shouldn't be too difficult to detect bind(c) subroutines, just need to take care to distinguish from bind(c) interfaces.\n\nAside: It seems a shame for a package to effectively loose pruning support because it provides a C API; some possible solutions to this could be to provide the C API as a separate package or to have the C API as optional feature (#609)."
+ },
+ {
+ "user": "awvwgk",
+ "date": "2022-05-12 20:38:56+00:00",
+ "text": "Aside: It seems a shame for a package to effectively loose pruning support because it provides a C API; some possible solutions to this could be to provide the C API as a separate package or to have the C API as optional feature (#609).\n\nSplitting of bindings into separate projects means they will eventually become stale and out-of-sync, this is not an option for long-term maintainability.\nHaving the possibility to mark part of the code as optional features would be a solution. For the other build systems in my projects (CMake and meson) the C API is indeed optional and usually disabled when the project is included as subproject and statically linked to avoid symbols leaking from shared libraries declared in the superproject."
+ },
+ {
+ "user": "awvwgk",
+ "date": "2022-06-03 11:17:09+00:00",
+ "text": "Startup times look okay now\n\u276f fpm run --runner time -- build -C ../mctc-tools/tblite\nProject is up to date\nfpm: Entering directory '/home/awvwgk/projects/src/git/mctc-tools/tblite'\nProject is up to date\nfpm: Leaving directory '/home/awvwgk/projects/src/git/mctc-tools/tblite'\n\nreal\t0m0.790s\nuser\t0m0.739s\nsys\t0m0.043s\n\u276f time fpm build -C ../mctc-tools/tblite\nfpm: Entering directory '/home/awvwgk/projects/src/git/mctc-tools/tblite'\nProject is up to date\nfpm: Leaving directory '/home/awvwgk/projects/src/git/mctc-tools/tblite'\n\nreal\t0m0.578s\nuser\t0m0.504s\nsys\t0m0.066s"
+ },
+ {
+ "user": "milancurcic",
+ "date": "2022-06-03 11:32:34+00:00",
+ "text": "I haven't played with it further, but given @awvwgk's review I suggest to go ahead and merge."
+ },
+ {
+ "user": "LKedward",
+ "date": "2022-06-03 14:20:22+00:00",
+ "text": "Thanks both for reviewing, I'll now merge."
}
]
},
@@ -345,9 +540,15 @@
"date": "2022-03-09 05:50:08+00:00",
"title": "Add `library-dir` to support `-Lpath`",
"text": "Add library-dir in fpm.toml to support -Lpath;\n Use the compiled minpack as a demo of this new feature;\n Update tests.\n\nDescription\n-Lpath makes it possible to distribute large libraries such as stdlib, OpenBLAS, HDF5, MKL, etc., and to package compiled .mod and .a/.dll/.so/.dll.a files into fpm distribution.",
- "is_open": true,
+ "is_open": false,
"labels": [],
- "comments": []
+ "comments": [
+ {
+ "user": "zoziha",
+ "date": "2022-05-27 19:22:23+00:00",
+ "text": "Rethinking the value of this PR, it seems that this feature does not need to be implemented. :\\\nCurrently, we can mostly set the system or temporary FPM_FFLAGS environment variable to support -Ipath/to/include and -Lpath/to/lib.\nI will close this PR tomorrow."
+ }
+ ]
},
{
"number": 670,
@@ -454,6 +655,16 @@
"user": "urbanjost",
"date": "2022-03-04 18:01:23+00:00",
"text": "All messages that are informative should not appear unless the --verbose|-V switch is present; other possibilities are all messages go to stderr instead of stdout; and/or the user can set a verbosity level including no messages. Having messages like that appear when using --list and --runner broke a lot of my scripts where I just wanted a pathname. Somewhat ironic it appears to have showed up along with the quiet mode for building :>"
+ },
+ {
+ "user": "awvwgk",
+ "date": "2022-05-18 18:55:53+00:00",
+ "text": "It is not uncommon for build systems to report that there is no work to be done\n\u276f make\nmake: Nothing to be done for 'all'.\n\u276f ninja -C _build_gcc11/\nninja: Entering directory `_build_gcc11/'\nninja: no work to do."
+ },
+ {
+ "user": "urbanjost",
+ "date": "2022-05-20 14:51:31+00:00",
+ "text": "And all that I know of write to stderr and/or have a quiet mode; as is the convention on GNU/Linux and Unix. Even grep(1) has a quiet mode!"
}
]
},
@@ -688,6 +899,11 @@
"user": "LKedward",
"date": "2022-02-07 14:48:42+00:00",
"text": "@LKedward about the changes to the manifest being included in the PR. I was thinking that since the profiles are not used yet, then we should not include it so that it does not confuse anybody.\n\nOf course, good point!"
+ },
+ {
+ "user": "milancurcic",
+ "date": "2022-05-07 19:10:19+00:00",
+ "text": "This looks like it could be merged, no?"
}
]
},
@@ -1419,7 +1635,7 @@
"date": "2021-11-21 02:41:53+00:00",
"title": "Trouble with `--show-model`",
"text": "Description\nFound this while I was trying to debug an unrelated issue in fpm itself.\ncd fpm\nfpm build --show-model\nAt line 247 of file ././src/fpm_model.f90\nFortran runtime error: Index '1' of dimension 1 of array 'source%link_libraries' below lower bound of 4\n\nError termination. Backtrace:\n#0 0x7f0a0e0f9332 in ???\n#1 0x7f0a0e0f9df9 in ???\n#2 0x7f0a0e0fa40a in ???\n#3 0x4ad86b in info_srcfile\n at ././src/fpm_model.f90:247\n#4 0x4af2fa in info_package\n at ././src/fpm_model.f90:167\n#5 0x4a363c in info_model\n at ././src/fpm_model.f90:277\n#6 0x4a2db9 in __fpm_model_MOD_show_model\n at ././src/fpm_model.f90:313\n#7 0x40c527 in __fpm_MOD_cmd_build\n at ././src/fpm.f90:285\n#8 0x4027eb in MAIN__\n at app/main.f90:67\n#9 0x402d1b in main\n at app/main.f90:10\n\nExpected Behaviour\nView fpm model.\nVersion of fpm\n9dc068d\nPlatform and Architecture\nLinux x64, Windows x64\nAdditional Information\nNo response",
- "is_open": true,
+ "is_open": false,
"labels": [
"bug"
],
@@ -1675,6 +1891,11 @@
"user": "urbanjost",
"date": "2021-11-29 00:32:42+00:00",
"text": "Haven't carefully read this discussion yet but I\nalways put -L and -l on the right side of my build objects in order as a result of working with single-pass left-to-right loaders; without trouble; but since multiple -flag options are allowed, perhaps a special option like --place [left|right] that would indicate the position to place subsequent options would be a stop-gap? Although nearly a standard, not all compilers necessarily use -L and -l so just looking for those flag names might have issues"
+ },
+ {
+ "user": "awvwgk",
+ "date": "2022-05-26 13:35:26+00:00",
+ "text": "@rouson Would native support for pkg-config in fpm be a solution for your library? I see that there is a generation step paring the GASNet-EX pkg-config file to build the fpm.toml at\nhttps://github.com/BerkeleyLab/caffeine/blob/96ae0a818203ed92017e79bd3debb3b2f6e3c556/install.sh#L297-L303\nWe discussed pkg-config support in #439, but didn't arrive at an agreement whether fpm should support it or no."
}
]
},
@@ -3235,7 +3456,13 @@
"labels": [
"bug"
],
- "comments": []
+ "comments": [
+ {
+ "user": "Carltoffel",
+ "date": "2022-05-13 10:20:22+00:00",
+ "text": "I also ran into this issue. To make some progress on this issue:\n\nThe error comes from here because none of 'library', 'executable', 'test', 'example' is allocated.\nTo be allocated 'executable', 'test' and 'example' needs to contain a 'main.f90' file.\nI tried to change these three lines to be the same as for 'library'/'src' (just check if the directory exists). But then fpm complains that it cannot find, e.g., 'example/main.f90' because it currently needs to set a default app, example, or test."
+ }
+ ]
},
{
"number": 533,
@@ -18120,6 +18347,21 @@
"user": "certik",
"date": "2021-09-06 14:22:44+00:00",
"text": "Note that to fix this issue, I am imagining something like fpm --create-spack-package and it will take the current fpm package in the current directory, and spit out the spack Python file that can be used with Spack to build it."
+ },
+ {
+ "user": "awvwgk",
+ "date": "2022-05-19 06:13:12+00:00",
+ "text": "I think rather than writing a spack package from fpm as first step, we should enable fpm to work as build system for spack by\n\nproviding a way to satisfy fpm dependencies by spack (maybe #439)\ncreate libraries usable by other spack packages (maybe #681)"
+ },
+ {
+ "user": "certik",
+ "date": "2022-05-19 06:32:01+00:00",
+ "text": "@awvwgk I agree, that is higher priority."
+ },
+ {
+ "user": "wyphan",
+ "date": "2022-05-19 14:40:23+00:00",
+ "text": "Like I mentioned on Fortran Discourse forum, I recently patched the fpm package in Spack with spack/spack#30158 and spack/spack#30342 . Would love to see Option 1 happen!"
}
]
},
@@ -19879,6 +20121,11 @@
"user": "ivan-pi",
"date": "2021-12-14 08:27:22+00:00",
"text": "Just ticked off two more packages from @jacobwilliams. Thanks Jacob for your effort."
+ },
+ {
+ "user": "scivision",
+ "date": "2022-05-17 23:06:05+00:00",
+ "text": "h5fortran and nc4fortran now work with FPM thanks to input from @milancurcic"
}
]
},
@@ -20256,8 +20503,8 @@
}
],
"issue_labels": {
- "bug": "Something isn't working",
"enhancement": "New feature or request",
+ "bug": "Something isn't working",
"os-windows": "Issues specific to the MS Windows operating system",
"user experience": "issue regarding issue experience with fpm",
"good first issue": "Good for newcomers",
diff --git a/community/github_stats_data/data-fortran-lang-stdlib.json b/community/github_stats_data/data-fortran-lang-stdlib.json
index 09047b11a..27e90e1e2 100644
--- a/community/github_stats_data/data-fortran-lang-stdlib.json
+++ b/community/github_stats_data/data-fortran-lang-stdlib.json
@@ -1,13 +1,171 @@
{
"name": "fortran-lang/stdlib",
"issues": [
+ {
+ "number": 661,
+ "user": "JonathanKipp",
+ "date": "2022-06-02 07:28:52+00:00",
+ "title": "Tests failing",
+ "text": "Description\ncompiler: any of gcc10,gcc12\nOS: linux-gnu\n\n\n\nuname -a\nLinux iff1426 4.18.0-348.20.1.el8_5.x86_64 #1 SMP Thu Mar 10 20:59:28 UTC 2022 x86_64 x86_64 x86_64 GNU/Linux\n\n\n\nFollowing the instructions from README, I get a lot of failing tests when doing cmake --build build --target test (see attached file).\nI ran the tests and installed succesfully on the same platform with the same compilers before i did a new git pull, but I dont remember if it was another release.\nLastTest.log\nExpected Behaviour\nI expect the tests to run succesfully.\nVersion of stdlib\nany from 8e0d8dd down to fb4ca80\nPlatform and Architecture\nOS: linux-gnu >>>uname -a Linux iff1426 4.18.0-348.20.1.el8_5.x86_64 #1 SMP Thu Mar 10 20:59:28 UTC 2022 x86_64 x86_64 x86_64 GNU/Linux\nAdditional Information\nNo response",
+ "is_open": true,
+ "labels": [
+ "bug"
+ ],
+ "comments": []
+ },
+ {
+ "number": 660,
+ "user": "hsnyder",
+ "date": "2022-05-23 02:05:00+00:00",
+ "title": "Fix erroneous gaussian quadrature points in gauss_legendre",
+ "text": "fixes #619",
+ "is_open": true,
+ "labels": [],
+ "comments": []
+ },
+ {
+ "number": 659,
+ "user": "gareth-nx",
+ "date": "2022-05-21 06:00:37+00:00",
+ "title": "Readme update",
+ "text": "This pull request explains some CMake options that affect stdlib builds.\n\nIt is designed to address these issues in a simple way.\n\nThe first issue is that user-specified compiler optimizations in FFLAGS are overridden by the default the stdlib CMake setup. This means that, in the original README, the use of FFLAGS was not having any effect.\n\nTo fix this, the updated README discusses -DCMAKE_BUILD_TYPE. This can be setup to avoid default optimizations (while retaining flags that are essential to compile stdlib). This allows optimization flags in FFLAGS to be used.\n\nThe second issue is that by default, the user does not see what commands CMake is using to compile the code. This makes it difficult to notice problems like those above.\n\nThe solution is to set -DCMAKE_VERBOSE_MAKEFILE=On, which prints the compiler options.\n\nI am a CMake novice, so it would be good to have this checked by an expert like @awvwgk .",
+ "is_open": true,
+ "labels": [],
+ "comments": []
+ },
+ {
+ "number": 658,
+ "user": "certik",
+ "date": "2022-05-18 22:32:42+00:00",
+ "title": "Should we require a separate fpm package first before standardizing?",
+ "text": "One thing that I am worried is that we are making the same mistake as the standards committee, often standardizing things before we get actual experience with using it. Now with fpm, I wonder if it's time to first require creating an fpm package with the addition, and get people using it, before standardizing it in stdlib?\nTake #580 as an example. It's been open for half a year, but how many people have actually tried it in their projects? I didn't, because it's not that easy to test a PR, you have to clone the repository, checkout the PR, install stdlib by hand, etc. You can't use it via fpm (as far as I know, since fpm requires a special branch, that is not generated from PRs), we could fix that by committing all the fypp generated files into git, then we could update fpm to support depending on PRs. However, even that seems relatively fragile and temporary.\nInstead, if #580 was posted in a standalone git repository as a regular package, then people can immediately use it in their projects using fpm. If it later gets standardized, then it's a simple change of an fpm dependency, and possibly of a use line. And there is no rush with this change either. People could contribute patches to the repository, tests, etc.\nAn example would be the argparse package in the Python standard library, which first lived as a standalone package, well liked, and then later standardized.",
+ "is_open": true,
+ "labels": [
+ "meta"
+ ],
+ "comments": [
+ {
+ "user": "certik",
+ "date": "2022-05-18 22:43:09+00:00",
+ "text": "Note that argparse was the second attempt at argument parsing in Python. The first module was optparse, but it was too limiting, so a lot of people ended up using the argparse separate module instead."
+ },
+ {
+ "user": "14NGiestas",
+ "date": "2022-05-19 00:34:44+00:00",
+ "text": "About not being able to use fpm to test PR, you actually can but it's just undocumented, you just need to run the ci/fpm_deployment.sh it will generate a folder called stdlib-fpm (which will be the content of the homonymous branch).\nIs somewhat annoying though but it's low effort:\n\nYou first need to clone the forked repo (that could take a while in a slow connection)\nThen you git switch (finding the right PR branch can be a minor annoyance)\nAnd finally, you run the ./ci/fpm_deployment.sh to build the folder\ncd stdlib-fpm\nfpm build, fpm test, or whatever\nI usually create an app/main.f90 where I use the implemented stuff to poke around the PR, usually pulling stuff from docs/specs and tests.\n\nI wonder if the CI can create something like a \"release\" when a PR happens (in its fork of course), so you just download the fpm package, unpack it, and test.\nOr maybe just documenting the process above in a PR template (which I'm extrapolating, does it exists?)"
+ },
+ {
+ "user": "urbanjost",
+ "date": "2022-05-19 02:53:23+00:00",
+ "text": "I totally support some kind of fpm-based development of stdlib features,\nand have suggested people actually try the available date-time packages,\nANSI color packages, .... and from that make suggestions on what should\nbe adapted in stdlib.\nI was hoping something like a central wiki for functions such as these\nwould be part of the stdlib development, where people could add their\npackages for consideration for a certain functionality, and that people\ncould try them and make suggestions based on this for what the stdlib\nimplementation should be, and/or that a clear favorite would emerge from\nthe candidates.\nThat is exactly what I tried to create for this very topic with\nM_escape and subsequently\nM_attr. Didn't seem to get\nmuch traction.\nPerhaps something like a sponsored set of moderated categories based off\nthe Fortran-lang pages would work instead? Discussions could proceed\nusing current methods, but the Fortran-lang pages would keep a simple\ndigest of the materials, like a list of the candidates and a list of\nthe desired functionality? Not sure if moderators are available for\nsuch an approach. Somewhat like a competitive Rosetta Code? It\ncould start with a description of a general functionality, and peoples\nideas about approaches\n...\nFor this topic, maybe the model suggestions would have looked like\n\nbasic terminal control sequence constants\na functional model\nusing an XML-like syntax for attributes like color\nextending type(string) to have attributes and adding a DT for printing it\nwriting latex/html/pdf (see asa2pdf in GPF)\nA preprocessor for an extended Fortran Format to be proposed as a Fortran\nfeature (ie. write(*,\"C.1.4.U,A,C)\")'error' would use the C descriptor to add\nforeground color 1, background color 4, and underlining, and \"C\" would reset).\na new full-blown Fortran object-oriented ncurses-like library\nan ISO_C_BINDING interface to termlib/terminfo functionality in existing C\nlibraries\na proposal for attributes like color to be added to the common extensions\nfor supportng ASA output, combined with a proposal for the support to become\npart of the standard\netc ...\n\nand functionality could be listed and voted on by people actually indicating\nwhat they would use or how critical a functionality would be, like\n\nfull color support versus eight basic colors\nstring positioning\noop design versus functional\nwould overloading of operators be a plus or minus?\nability to turn on and off\netc ...\n\npeople could then submit their fpm packages for consideration and discussion?\nSo basically, I think fpm is a near-perfect tool for creating various\nprototypes for stdlib functionality, but by itself has not become a path for\nsuch.\nWhat is missing that this is not the case? Would a \"request for papers\"\napproach work, with a wiki used for listing desired features, describing\ncurrent roadblocks, and listing current related packages work?\nIs there some model other languages use that would be useful?"
+ },
+ {
+ "user": "awvwgk",
+ "date": "2022-05-19 06:23:48+00:00",
+ "text": "It's been open for half a year, but how many people have actually tried it in their projects?\n\nUnfortunately, this is currently the default for most PRs at stdlib taking several weeks to months until they get reviewer attention and not a criteria to judge a PR.\nRegarding fpm packages for PRs, I'm happy to support this idea and have done so in the past, especially for strings. From my experience with those was not a big difference in review time nor adaption so far whether the project existed as an fpm package before.\nOn the other hand, creating, maintaining and establishing an fpm package is a lot of hard work, especially maintaining the CI testing, automated documentation and maybe the fypp processing puts a huge demand on the contributors. At least for me pushing a project on GitHub means a significant time commitment for maintenance, working with reviewers on a PR of course requires also effort, however this is usually only coding rather than building reliable and long-lived software infrastructure.\nSo while I'm in principle in favor of this idea, I worry it might hamper the pace of developing stdlib even further."
+ },
+ {
+ "user": "milancurcic",
+ "date": "2022-05-19 15:22:01+00:00",
+ "text": "I overall share @awvwgk's opinion. It seems a good idea at a surface, but I don't think it would help in practice.\n\nOne thing that I am worried is that we are making the same mistake as the standards committee, often standardizing things before we get actual experience with using it.\n\nI think this is an incorrect premise to start with. The problem with the Fortran standard and the committee is that there are features that are insufficiently tested and/or well-thought-through, and the committee requires backward compatibility in most cases (understandably so).\nThis is not the case with stdlib. As we discussed many times before, we have an experimental level and stable tiers of features. Anything in experimental (currently everything) is subject to change. Features in stable are really what's comparable to standardized language features.\n\nTake #580 as an example. It's been open for half a year, but how many people have actually tried it in their projects? I didn't, because it's not that easy to test a PR, you have to clone the repository, checkout the PR, install stdlib by hand, etc. You can't use it via fpm\n\nFor example, I at least play a little bit for any feature PR that I review, unless I indicate in the review that I didn't try it but seems reasonable. In my view, it's really when features are committed in experimental that the real playing and testing begins, not the PR stage. I think we should be fast and loose with feature PRs to experimental (Is it in scope? Yes. Does it seem useful? Yes. Is something obviously incorrect about it? No. OK, let's merge it.), and only very conservative at the stage when we consider features for the stable tier. Those will obviously need to show a track record of use in other packages.\nSo, if I'd recommend any change, it's for people to review, merge sooner, don't wait for approval from many people, and iterate in short cycles. If we realize later that an API or an implementation should be improved, we can do it."
+ },
+ {
+ "user": "certik",
+ "date": "2022-05-19 15:47:47+00:00",
+ "text": "Yes, it's all about reducing the burden on both stdlib maintainers, and stdlib users and reviewers (often times but not always the same people).\nI can see only two ways forward:\n\nThe fpm approach I posted above\nMerge PRs relatively quickly to experimental, and use stdlib itself as the test project for people to use.\n\nRight now we do not do either, and that is what I object against. I am fine with either one approach, and Milan is right that we have discussed initially to use experimental precisely as a test project to make it easy for people to try out and use, and we reserve full right to completely change the API or even remove the functionality.\nSo let's get back to our original plan, and merge much quicker to stdlib.\nThe other part of the problem is that stdlib seems to be missing a single person who would be in charge of this, and ensure PRs get reviewed in a timely manner and merged and actively pushing after the goal/vision of stdlib. I can't be that person, as I am already that person for LFortran. Is there anybody who would be interested for this role? @awvwgk, @milancurcic, @14NGiestas, @urbanjost and others?"
+ },
+ {
+ "user": "milancurcic",
+ "date": "2022-05-19 15:52:37+00:00",
+ "text": "I'm at capacity and do my best. Yes, ideally there should be a single person that's consistently on top of it, but it may be difficult to find. Until we do, perhaps we just need to broaden the team of \"partial maintainers\"."
+ },
+ {
+ "user": "milancurcic",
+ "date": "2022-05-19 15:57:28+00:00",
+ "text": "Currently, stdlib PRs require approval from 2 maintainers (members with write access) for it to be merged. This number of 2 was arbitrary when I set it a long time ago. And nowadays we often get approval from reviewers without write-access, which doesn't count toward the required approval quota.\nShould we lower this requirement to 1 approval, with the hope of PRs getting merged faster?"
+ },
+ {
+ "user": "certik",
+ "date": "2022-05-19 15:59:14+00:00",
+ "text": "Yes, a single person in charge is the best. Until we can find such a person, then let's do a collection of people as partial maintainers (as we do now) and let's do our best not to delay things with \"indecision\". (I realize my objections partly caused the delay, but until we have a single person to push for this, please don't get discouraged if I am critical. Merging faster is a higher priority for me than my milder objections, which I still think was important to write.)"
+ },
+ {
+ "user": "jvdp1",
+ "date": "2022-05-19 17:44:52+00:00",
+ "text": "The main issues for stdlib is the lack of reviewers. I try to review most of them, but I am currently lacking time, and the PR are usually quite large.\nMy main concern is that if we merge quickly feature PRs after a \"light\" review, these feature PRs that might be half backed and full of (hidden) issues, will remain as they are in stdlib, because users will used them without reporting issues or providing improvements, or will not use them at all. Why would reviewers appear after the PR are merged, while they are lacking when the PR are opened?\nCurrently I already integrated a few features (e.g. logger, some stat functions, sorting procedures) in my main projects, and use daily almost all features through fpm. I was quite involved in reviewing the logger and sorting procedures, and if they would have been merged in their first submission, I can affirm that I would not use them today because they did not fit my needs in their original proposition, AND I would not try to improve them (or submit issues/PR).\nTherefore, while slow, I prefer to have well though and backed features, even in the experimental space.\nLowering the number of approvals for merging could be also a problem. For example, there is currently a PR with one approval, but the specs and the tests do not fully agree with the stdlib requests/defaults. Merging it as is would result in a feature with not-conforming/\"poor\" specs and tests, which might result in bad reputation for stdlib.\nNote that I am not believing in having a new feature has a separate project. It is already the case for the stdlib_os project, and little tests and improvements have been observed.\nFinally, I believe that the best thing would be to have fpm that can build stdlib from scratch, without the need of the deployement script for fpm. If it would be the case, anyone could build stdlib from any branch of any fork and review and test it appropriately. This would help me a lot when reviewing PRs."
+ },
+ {
+ "user": "ivan-pi",
+ "date": "2022-05-19 18:19:00+00:00",
+ "text": "Personally I think 2 approvals is not the problematic point, but indeed finding the time for reviews, or ideally new reviewers. Maybe once a PR reaches a certain level of maturity, submitting a description and demonstration to Discourse could raise more interest.t\nI'm hesitant to make submitting a fpm package a requirement. It could be a recommendation, and I know @awvwgk has done this many times (also in issues), but it requires a lot of effort, and I fear would raise the bar too high for new contributors."
+ },
+ {
+ "user": "certik",
+ "date": "2022-05-19 19:17:28+00:00",
+ "text": "@jvdp1 I share your concerns, and that's why I opened up this issue. I think you are saying not to merge too quickly to the experimental part of stdlib. You are also saying not to use separate fpm projects.\nAs such, the third way forward that I think you are suggesting is to make it so that fpm can easily build any branch / PR right away (whether by committing the fypp generated codes into git or by teaching fpm about fypp so it can automatically run it). Then we can keep the PRs open for longer."
+ },
+ {
+ "user": "awvwgk",
+ "date": "2022-05-19 20:02:33+00:00",
+ "text": "There is fortran-lang/fpm#78 open since a while, it will take a reasonable effort to integrate the preprocessing stage in the current target generation structure. It's a small to medium-sized project and will require some time commitment mind you, but the fpm maintainers are of course around to provide pointers if needed.\nIf anyone here feels deeply about building stdlib with fpm without running the deploy script locally first, this is the right place to put in some energy and effort."
+ },
+ {
+ "user": "jvdp1",
+ "date": "2022-05-19 20:51:13+00:00",
+ "text": "Then we can keep the PRs open for longer.\n\n@certik You summarized nicely my message. Thank you. However, I hope that compiling any branch with fpm would result in merging faster the PRs, as the users could test quicker the proposed features in their projects."
+ },
+ {
+ "user": "14NGiestas",
+ "date": "2022-05-19 22:54:21+00:00",
+ "text": "The other part of the problem is that stdlib seems to be missing a single person who would be in charge of this, and ensure PRs get reviewed in a timely manner and merged and actively pushing after the goal/vision of stdlib. I can't be that person, as I am already that person for LFortran. Is there anybody who would be interested for this role? @awvwgk, @milancurcic, @14NGiestas, @urbanjost and others?\n\nI'll keep trying to push some PRs/issues forward since I have time to spare now (but I don't know how long I can consistently do it or even if it's ok - please let me know).\n\nThe main issues for stdlib is the lack of reviewers. I try to review most of them, but I am currently lacking time, and the PR are usually quite large.\n\nI'm not sure if it's the case, but one thing that may help is to ask (encourage) everyone to do some light reviews even if you are not 100% familiar with the PR topic, the more people looking at the code the better (especially in huge PRs).\nI don't think anyone should be an expert to catch odd stuff in other people's code and with the help of the PR contributor, we can figure out what is going on. This way we can avoid waiting too much for someone to feel comfortable / find time to extensively review a PR and even relieve the burden on both sides (reviewers and contributor)."
+ }
+ ]
+ },
+ {
+ "number": 657,
+ "user": "milancurcic",
+ "date": "2022-05-07 19:01:29+00:00",
+ "title": "Remove support for manual make builds",
+ "text": "This PR removes the manual Makefiles from directories, CI, and instructions docs (README and WORKFLOW). Its purpose is to remove the burden from PR contributors and stdlib maintainers when adding features to stdlib. The obvious downside is that people wouldn't be able to build stdlib with Make anymore.\nEven if there is wide approval, I'd like this PR to stay open a while (at least a few weeks) to provide an opportunity for people to voice objections.\nI think I removed all Make instances (files and instructions), but it's possible that I missed something.\nBecause this is a such a high-impact and project-wide change that affects users, I request review from many people. While I am in favor of this change, I am not sure that it's the best thing to do.\nDiscussion and poll on Discourse: https://fortran-lang.discourse.group/t/how-do-you-intend-to-build-the-fortran-stdlib/1862\nCloses #526.",
+ "is_open": false,
+ "labels": [
+ "build: make"
+ ],
+ "comments": [
+ {
+ "user": "Carltoffel",
+ "date": "2022-05-07 19:26:12+00:00",
+ "text": "If we agree to remove the make builds, this PR would be a good opportunity to move the fpm section in README.md to the top. There was a discussion on that, but I forgot where."
+ },
+ {
+ "user": "milancurcic",
+ "date": "2022-05-07 19:29:08+00:00",
+ "text": "@Carltoffel I agree but suggest to do it in a separate PR to make this easier to review."
+ },
+ {
+ "user": "milancurcic",
+ "date": "2022-05-19 15:53:43+00:00",
+ "text": "If there are no objects, I will apply the outstanding fixes and merge on Monday, May 23."
+ },
+ {
+ "user": "milancurcic",
+ "date": "2022-05-19 16:30:17+00:00",
+ "text": "@certik, great, thanks for the encouragement. Will merge now."
+ },
+ {
+ "user": "ivan-pi",
+ "date": "2022-06-03 06:34:01+00:00",
+ "text": "Just wanted to mention this discussion from Reference-LAPACK/lapack#488. They have similar problems as we had, keeping two build systems functioning and up to date. For the time being they are keeping both CMake and Make, but there seems to be a slight preference for using CMake."
+ }
+ ]
+ },
{
"number": 656,
"user": "Carltoffel",
"date": "2022-04-29 15:53:36+00:00",
"title": "Add hint for building error with make",
"text": "",
- "is_open": true,
+ "is_open": false,
"labels": [
"documentation",
"build: make"
@@ -26,7 +184,7 @@
"date": "2022-04-24 15:28:19+00:00",
"title": "fixed 32-bit integer overflow in stdlib_io_npy",
"text": "32-bit integer overflows in stdlib_io_npy_save.fypp and stdlib_io_npy_load.fypp are fixed from 2**32 to 2**24, to become the power of base-number (256) at the 4th digit a base-256 number.\nTo improve readability and understandability, the powers of base-number are refactored from 2**8, 2**16, 2**24 to 256**1, 256**2, 256**3, respectively.\nThe tasks done are summarized as follows:\n\nfixed and refactored stdlib_io_npy_save.fypp\nfixed and refactored stdlib_io_npy_load.fypp\nbuilt with gfortran 10.3, ifort 2021.1, and nagfor 7.1 on Windows 10 with cmake 3.20.3\nexecuted cmake --build build --target test to run the test npy and confirmed it passed\n\ncloses #647\nNote that config/DefaultFlags.cmake is locally changed to specify compiler flags for nagfor as follows:\nelseif(CMAKE_Fortran_COMPILER_ID MATCHES \"NAG\")\n set(\n CMAKE_Fortran_FLAGS_INIT\n \"-fpp\"\n \"-f2018\"\n \"-ieee=full\"\n )\n set(\n CMAKE_Fortran_FLAGS_RELEASE_INIT\n )\n set(\n CMAKE_Fortran_FLAGS_DEBUG_INIT\n \"-g\"\n \"-nan\"\n )",
- "is_open": true,
+ "is_open": false,
"labels": [
"bug",
"reviewers needed",
@@ -125,6 +283,36 @@
"user": "14NGiestas",
"date": "2022-04-28 20:25:03+00:00",
"text": "@14NGiestas then the suggestion with cutting of skiprows_ should be fine for this pull request, since it doesn't introduce any new error behavior. If everybody is fine with it, I would commit my suggestion for this.\n\nYep, at first glance your suggestion is ok (just make sure it is mentioned in the docs and examples)\nIf I recall correctly returning a zero-sized array is a behavior used in stdlib_math linspace and logspace."
+ },
+ {
+ "user": "14NGiestas",
+ "date": "2022-05-05 12:06:59+00:00",
+ "text": "I believe the specs should also be updated at specs/stdlib_io"
+ },
+ {
+ "user": "MuellerSeb",
+ "date": "2022-05-05 13:59:47+00:00",
+ "text": "I believe the specs should also be updated at specs/stdlib_io\n\nOh. Why are there two files for the same docs?!"
+ },
+ {
+ "user": "14NGiestas",
+ "date": "2022-05-05 15:26:20+00:00",
+ "text": "@MuellerSeb the stdlib project has this little quirk where it mediates, in a manner, future standardized Fortran features.\n\nThe specification is a document that describes the API and the functionality, so that anyone can use it to create an implementation from scratch without looking at stdlib. The stdlib library then provides the reference implementation.\n\nIt will end up being the \"same\" but it serves a different purpose. This PR is a kinda undefined behavior AFAIK (since it updates a spec) and maybe we should discuss more. I'm reviewing in a good faith that is useful to have such options available but the workflow doesn't seem to be ready for this specific situation."
+ },
+ {
+ "user": "jvdp1",
+ "date": "2022-05-08 19:25:17+00:00",
+ "text": "It will end up being the \"same\" but it serves a different purpose. This PR is a kinda undefined behavior AFAIK (since it updates a spec) and maybe we should discuss more. I'm reviewing in a good faith that is useful to have such options available but the workflow doesn't seem to be ready for this specific situation.\n\nI would say that it is labelled as experimental. So changing the API is ok at this stage, especially that it is also backward-compatible."
+ },
+ {
+ "user": "MuellerSeb",
+ "date": "2022-05-09 08:31:55+00:00",
+ "text": "@jvdp1 another option for negative values for max_rows could be to to interpret them as wrap-around values. Meaning, -1 will be the full file, -2 will leave out the last line and so on. We would just need to find a solution for too large negative numbers. It should again be cut-off at 0 read lines."
+ },
+ {
+ "user": "jvdp1",
+ "date": "2022-05-09 10:20:37+00:00",
+ "text": "@jvdp1 another option for negative values for max_rows could be to to interpret them as wrap-around values. Meaning, -1 will be the full file, -2 will leave out the last line and so on. We would just need to find a solution for to big negative numbers. It should again be cut-off at 0 read lines.\n\nIn this case, I would suggest to define a parameter integer, e.g., read_all, which would be available to the user, and then to add a procedure for checking the provided value, e.g.\nselect case(max_rows_)\n case( 0 )\n ....\n case( : -1 )\n .... = real_all\n case default\n ....\nend select\nA parameter integer would provide the flexibility for the API (as the user doesn't need to rely on a specific number)"
}
]
},
@@ -204,7 +392,7 @@
"date": "2022-04-07 08:13:47+00:00",
"title": "Wrong Compiler Selected When Building With Make",
"text": "This line\n\n \n \n stdlib/Makefile.manual\n \n \n Line 3\n in\n 9f1aa24\n \n \n \n \n\n \n \n FC ?= gfortran \n \n \n \n\n\nshould set FC to gfortran, if no other compiler is defined. But on some (don't know on how many) systems FC is preset to f77. Since I don't have f77 (and I doubt it would be able to compile stdlib) the build process fails.\nIs there anything we can do about this issue? Maybe check the value of FC if it is set to such a default value and print a error/warning message?\nThe current warning is a little bit misleading:\nf77: No such file or directory\nTestet on:\nArch Linux, GNU Make 4.3 built for x86_64-pc-linux-gnu\nFedora 35, GNU Make 4.3 built for x86_64-redhat-linux-gnu",
- "is_open": true,
+ "is_open": false,
"labels": [
"build: make"
],
@@ -218,6 +406,11 @@
"user": "Carltoffel",
"date": "2022-04-19 13:39:39+00:00",
"text": "In my shell FC is not set, too. Where else could f77 come from? If it would select f95 it would work, but this doesn't happen."
+ },
+ {
+ "user": "ivan-pi",
+ "date": "2022-05-19 18:22:24+00:00",
+ "text": "Closing due to #657 (Remove support for manual make builds)."
}
]
},
@@ -227,7 +420,7 @@
"date": "2022-04-06 10:33:39+00:00",
"title": "32bit integer overflow in stdlib_io_npy_save.fypp and load.fypp",
"text": "When compiling stdlib using NAG Fortran compiler 7.0 for Windows on Windows 10, it terminates compiling with the error \"Integer (KIND=3) overflow\" (KIND=3 corresponds to int32 in NAG Fortran).\nErrors are detected in to_bytes_i4 in stdlib_io_npy_save.fypp and in get_descriptor in stdlib_io_npy_load.fypp .\nIn the procedures, the integer literal 2**32 is used in expressions as below:\n\n \n \n stdlib/src/stdlib_io_npy_save.fypp\n \n \n Lines 63 to 66\n in\n 8eaa778\n \n \n \n \n\n \n \n str = achar(mod(val, 2**8)) // & \n \n\n \n \n & achar(mod(val, 2**16) / 2**8) // & \n \n\n \n \n & achar(mod(val, 2**32) / 2**16) // & \n \n\n \n \n & achar(val / 2**32) \n \n \n \n\n\n\n \n \n stdlib/src/stdlib_io_npy_load.fypp\n \n \n Lines 135 to 143\n in\n 8eaa778\n \n \n \n \n\n \n \n if (major > 1) then \n \n\n \n \n header_len = ichar(buf(1)) & \n \n\n \n \n & + ichar(buf(2)) * 2**8 & \n \n\n \n \n & + ichar(buf(3)) * 2**16 & \n \n\n \n \n & + ichar(buf(4)) * 2**32 \n \n\n \n \n else \n \n\n \n \n header_len = ichar(buf(1)) & \n \n\n \n \n & + ichar(buf(2)) * 2**8 \n \n\n \n \n end if \n \n \n \n\n\nI guess that 2**24 is probably correct instead of 2**32.\nI have understood that to_bytes_i4 converts an integer to a byte string by converting a 32 bit decimal integer to a base-256 number and then to four ASCII characters.\nIn this case, the power of base number (=256) at each position are (256**0, 256**1, 256**2, 256**3), corresponding to (2**0, 2**8, 2**16, 2**24).\nThis consideration does not cover negative integers, but if my understanding is correct, the concerning expressions can be modified as follows:\n str = achar(mod(val, 256**1)) // &\n & achar(mod(val, 256**2) / 256**1) // &\n & achar(mod(val, 256**3) / 256**2) // &\n & achar(val / 256**3)\nand\n if (major > 1) then\n header_len = ichar(buf(1)) &\n & + ichar(buf(2)) * 256**1 &\n & + ichar(buf(3)) * 256**2 &\n & + ichar(buf(4)) * 256**3\n else\n header_len = ichar(buf(1)) &\n & + ichar(buf(2)) * 256**1\n end if\nIf using 2**32 is a trick to handle negative integers, I need another solution to compile stdlib using NAG Fortran compiler.",
- "is_open": true,
+ "is_open": false,
"labels": [
"bug"
],
@@ -534,6 +727,16 @@
"user": "awvwgk",
"date": "2022-03-26 09:16:20+00:00",
"text": "I pushed a fix for keeping the -fno-range-check option to #642, which already fixes another CMake issue."
+ },
+ {
+ "user": "14NGiestas",
+ "date": "2022-05-05 17:26:21+00:00",
+ "text": "@awvwgk @Beliavsky was this issue solved by #642? Should it be closed?"
+ },
+ {
+ "user": "awvwgk",
+ "date": "2022-05-05 17:30:11+00:00",
+ "text": "This is only fixed for the CMake build, it is still an issue for fpm."
}
]
},
@@ -543,7 +746,7 @@
"date": "2022-03-04 14:53:44+00:00",
"title": "Makefile.manual not working on Windows",
"text": "c:\\fortran\\public_domain\\github\\stdlib>make -f Makefile.manual ADD_FYPPFLAGS=-DMAXRANK=4\nmake -f Makefile.manual --directory=src\nmake[1]: Entering directory 'c:/fortran/public_domain/github/stdlib/src'\nf77 -Wall -Wextra -Wimplicit-interface -fPIC -g -fcheck=all -fno-range-check -c stdlib_kinds.f90\nprocess_begin: CreateProcess(NULL, f77 -Wall -Wextra -Wimplicit-interface -fPIC -g -fcheck=all -fno-range-check -c stdlib_kinds.f90, ...) failed.\nmake (e=2): The system cannot find the file specified.\nmake[1]: *** [Makefile.manual:89: stdlib_kinds.o] Error 2\nmake[1]: Leaving directory 'c:/fortran/public_domain/github/stdlib/src'\nmake: *** [Makefile.manual:23: all] Error 2\n\nfor an earlier version of stdlib, it compiles at least some codes and does not try to use \"f77\":\nc:\\fortran\\public_domain\\github\\stdlib_20210916>make -f Makefile.manual ADD_FYPPFLAGS=-DMAXRANK=4\nmake -f Makefile.manual --directory=src\nmake[1]: Entering directory 'c:/fortran/public_domain/github/stdlib_20210916/src'\ngfortran -Wall -Wextra -Wimplicit-interface -fPIC -g -fcheck=all -c stdlib_kinds.f90\ngfortran -Wall -Wextra -Wimplicit-interface -fPIC -g -fcheck=all -c stdlib_optval.f90\ngfortran -Wall -Wextra -Wimplicit-interface -fPIC -g -fcheck=all -c stdlib_error.f90\ngfortran -Wall -Wextra -Wimplicit-interface -fPIC -g -fcheck=all -c f18estop.f90\ngfortran -Wall -Wextra -Wimplicit-interface -fPIC -g -fcheck=all -c stdlib_specialfunctions.f90\ngfortran -Wall -Wextra -Wimplicit-interface -fPIC -g -fcheck=all -c stdlib_specialfunctions_legendre.f90\ngfortran -Wall -Wextra -Wimplicit-interface -fPIC -g -fcheck=all -c stdlib_ascii.f90\ngfortran -Wall -Wextra -Wimplicit-interface -fPIC -g -fcheck=all -c stdlib_io.f90\ngfortran -Wall -Wextra -Wimplicit-interface -fPIC -g -fcheck=all -c stdlib_logger.f90\ngfortran -Wall -Wextra -Wimplicit-interface -fPIC -g -fcheck=all -c stdlib_quadrature.f90\ngfortran -Wall -Wextra -Wimplicit-interface -fPIC -g -fcheck=all -c stdlib_quadrature_gauss.f90\ngfortran -Wall -Wextra -Wimplicit-interface -fPIC -g -fcheck=all -c stdlib_string_type.f90\ngfortran -Wall -Wextra -Wimplicit-interface -fPIC -g -fcheck=all -c stdlib_strings.f90\ngfortran -Wall -Wextra -Wimplicit-interface -fPIC -g -fcheck=all -c stdlib_math.f90\ngfortran -Wall -Wextra -Wimplicit-interface -fPIC -g -fcheck=all -c stdlib_stringlist_type.f90\nstdlib_stringlist_type.f90:152:4:\n\n 152 | pure function new_stringlist()\n | 1\nWarning: Return value of function 'new_stringlist' at (1) not set [-Wreturn-type]\ngfortran -Wall -Wextra -Wimplicit-interface -fPIC -g -fcheck=all -c stdlib_bitsets.f90\nstdlib_bitsets.f90:33:37:\n\n 33 | overflow_bits = 2_bits_kind**30/5 ! bits_kind == int32\n | 1\nWarning: Integer division truncated to constant '214748364' at (1) [-Winteger-division]\ngfortran -Wall -Wextra -Wimplicit-interface -fPIC -g -fcheck=all -c stdlib_bitsets_64.f90\nstdlib_bitsets_64.f90:436:26:\n\n 436 | self % num_bits = bits\n | 1\nWarning: Possible change of value in conversion from INTEGER(8) to INTEGER(4) at (1) [-Wconversion]\ngfortran -Wall -Wextra -Wimplicit-interface -fPIC -g -fcheck=all -c stdlib_bitsets_large.f90\ngfortran -Wall -Wextra -Wimplicit-interface -fPIC -g -fcheck=all -c stdlib_linalg.f90\ngfortran -Wall -Wextra -Wimplicit-interface -fPIC -g -fcheck=all -c stdlib_linalg_diag.f90\ngfortran -Wall -Wextra -Wimplicit-interface -fPIC -g -fcheck=all -c stdlib_linalg_outer_product.f90\ngfortran -Wall -Wextra -Wimplicit-interface -fPIC -g -fcheck=all -c stdlib_math_arange.f90\nstdlib_math_arange.f90:61:43:\n\n 61 | step_ = sign(merge(step_, 1.0_qp, step_ /= 0.0_qp), end_ - start_)\n | 1\nWarning: Inequality comparison for REAL(16) at (1) [-Wcompare-reals]\nstdlib_math_arange.f90:40:43:\n\n 40 | step_ = sign(merge(step_, 1.0_dp, step_ /= 0.0_dp), end_ - start_)\n | 1\nWarning: Inequality comparison for REAL(8) at (1) [-Wcompare-reals]\nstdlib_math_arange.f90:19:43:\n\n 19 | step_ = sign(merge(step_, 1.0_sp, step_ /= 0.0_sp), end_ - start_)\n | 1\nWarning: Inequality comparison for REAL(4) at (1) [-Wcompare-reals]\ngfortran -Wall -Wextra -Wimplicit-interface -fPIC -g -fcheck=all -c stdlib_quadrature_trapz.f90\ngfortran -Wall -Wextra -Wimplicit-interface -fPIC -g -fcheck=all -c stdlib_quadrature_simps.f90\ngfortran -Wall -Wextra -Wimplicit-interface -fPIC -g -fcheck=all -c stdlib_sorting.f90\ngfortran -Wall -Wextra -Wimplicit-interface -fPIC -g -fcheck=all -c stdlib_sorting_ord_sort.f90\nstdlib_sorting_ord_sort.f90:6035:47:\n\n 6035 | character(len=:), allocatable :: buf(:)\n | ^\nWarning: '.buf' may be used uninitialized [-Wmaybe-uninitialized]\nstdlib_sorting_ord_sort.f90:6074:33:\n\n 6074 | end function calc_min_run\n | ^\nnote: '.buf' was declared here\nstdlib_sorting_ord_sort.f90:2965:47:\n\n 2965 | character(len=:), allocatable :: buf(:)\n | ^\nWarning: '.buf' may be used uninitialized [-Wmaybe-uninitialized]\nstdlib_sorting_ord_sort.f90:3004:33:\n\n 3004 | end function calc_min_run\n | ^\nnote: '.buf' was declared here\ngfortran -Wall -Wextra -Wimplicit-interface -fPIC -g -fcheck=all -c stdlib_sorting_sort.f90\ngfortran -Wall -Wextra -Wimplicit-interface -fPIC -g -fcheck=all -c stdlib_sorting_sort_index.f90\nstdlib_sorting_sort_index.f90:3411:47:\n\n 3411 | character(len=:), allocatable :: buf(:)\n | ^\nWarning: '.buf' may be used uninitialized [-Wmaybe-uninitialized]\nstdlib_sorting_sort_index.f90:3483:33:\n\n 3483 | end function calc_min_run\n | ^\nnote: '.buf' was declared here\ngfortran -Wall -Wextra -Wimplicit-interface -fPIC -g -fcheck=all -c stdlib_stats.f90\ngfortran -Wall -Wextra -Wimplicit-interface -fPIC -g -fcheck=all -c stdlib_stats_corr.f90\nstdlib_stats_corr.f90:3:19:\n\n 3 | use, intrinsic:: ieee_arithmetic, only: ieee_value, ieee_quiet_nan\n | 1\nFatal Error: Cannot find an intrinsic module named 'ieee_arithmetic' at (1)\ncompilation terminated.\nmake[1]: *** [Makefile.manual:69: stdlib_stats_corr.o] Error 1\nmake[1]: Leaving directory 'c:/fortran/public_domain/github/stdlib_20210916/src'\nmake: *** [Makefile.manual:14: all] Error 2\n\n\nShifting to WSL2,\n/mnt/c/fortran/public_domain/github/stdlib$ make -f Makefile.manual ADD_FYPPFLAGS=-DMAXRANK=4\nworks",
- "is_open": true,
+ "is_open": false,
"labels": [
"bug",
"build: make",
@@ -559,6 +762,11 @@
"user": "Beliavsky",
"date": "2022-03-04 19:19:57+00:00",
"text": "On Windows,\nc:\\fortran\\public_domain\\github\\stdlib>gfortran --version\nGNU Fortran (GCC) 12.0.1 20220213 (experimental)\n\non WSL2,\ngfortran --version\nGNU Fortran (Ubuntu 9.3.0-17ubuntu1~20.04) 9.3.0\n\nThe Windows gfortran is a later version than the WSL2 gfortran."
+ },
+ {
+ "user": "ivan-pi",
+ "date": "2022-05-19 18:23:08+00:00",
+ "text": "Closing due to #657 (Remove support for manual make builds)."
}
]
},
@@ -874,7 +1082,8 @@
"text": "Description\nUnless I missed something, there should not be x(1) = interval(1) and x(size(x)) = interval(2) in gauss_legendre subroutines, this would only be relevant for gauss_legendre_lobatto.\nExpected Behaviour\ngauss_legendre(x, w, interval=[-1._dp, 1._dp] should give same result as without interval optional.\nVersion of stdlib\n0.1.0\nPlatform and Architecture\nLinux\nAdditional Information\nNo response",
"is_open": true,
"labels": [
- "bug"
+ "bug",
+ "easy"
],
"comments": [
{
@@ -891,6 +1100,11 @@
"user": "jvdp1",
"date": "2022-04-23 19:48:39+00:00",
"text": "mjben is correct, this is an error. Feel free to fix it if either of you want to, otherwise I will can do so over the weekend.\n\nHas this bug been fixed?"
+ },
+ {
+ "user": "hsnyder",
+ "date": "2022-05-23 02:05:43+00:00",
+ "text": "@mjben @ivan-pi @jvdp1 I've opened a pull request to fix this issue. Sorry for the delay!"
}
]
},
@@ -988,6 +1202,11 @@
"user": "trippalamb",
"date": "2022-04-07 18:06:41+00:00",
"text": "I like the idea of something like this, but having implemented something nearly identical in my code before, I tend to get a significant performance hit with the interface operators for stuff like matrix multiplication."
+ },
+ {
+ "user": "14NGiestas",
+ "date": "2022-05-05 14:33:58+00:00",
+ "text": "@trippalamb you get a performance hit compared to what? Is it using matmul(transpose(A),A) or something else? I don't believe the compiler gets smart enough to optimize it directly, at least in my humble tests.\nI don't see an issue with having a few syntactic sugars like this if the performance hit is just comparable to using the default functions but shorter (In heavy lifting codes you should be using BLAS anyway).\nWhat could be done is implement an entire derived type for matrices, having a few fields (like: is_transposed, is_conjugated), and when the DT is doing an operation like a multiplication will check such fields and call an optimized subroutine. There will be a small overhead compared to what is the best but the syntax will be (arguably) friendly and shorter.\nBut this can get really tiresome with current Fortran capabilities, for instance, accessing data would be a little annoying since we can't overload (:,:) [I don't know the implications], we could do some atrocities like implementing an overload to operator(//) where rhs is the DT and the lhs is a \"slice\" \ud83d\ude09, like this M//[1, 2], and some stuff to help to define ranges... Oh well! Anyway, I should stop here."
}
]
},
@@ -1292,6 +1511,21 @@
"user": "wclodius2",
"date": "2022-04-24 21:25:51+00:00",
"text": "set is a subroutine rather than a function because the map argument is intent(inout). It is intent(inout) because set modifies a small part of the hashmap structure, rather than duplicating almost the whole structure as a new object.\nget is a subroutine rather than a function because it has the optional exists error flag as an intent(inout) argument. A function with an intent(out) argument has undefined behavior."
+ },
+ {
+ "user": "wclodius2",
+ "date": "2022-05-05 23:47:31+00:00",
+ "text": "@14NGiestas I don't know what you mean by unguarded stops. The three examples you give are all guarded by if statements."
+ },
+ {
+ "user": "14NGiestas",
+ "date": "2022-05-06 00:10:56+00:00",
+ "text": "@wclodius2 I just want to make clear that such stop statements won't get the user by surprise in the sense that they can't recover from it by simply passing a status.\nI will play a little more to see if I can break it :)"
+ },
+ {
+ "user": "wclodius2",
+ "date": "2022-05-16 17:30:59+00:00",
+ "text": "@14NGiestas git shows that I still have one change request from you that I have not addressed. Do you know which one that is?"
}
]
},
@@ -2285,6 +2519,51 @@
"user": "awvwgk",
"date": "2022-04-11 15:59:39+00:00",
"text": "Didn't have time to look into this PR for a while now.\nWorking with color support for a bit I was somewhat unhappy with the API defined here for my projects, as I usually need a more high-level interface to turn off the color printout. The overall structure defined here might be just right to build such a low level interface.\nI'm fine with finishing this PR and merging it as is, still there is some way to go."
+ },
+ {
+ "user": "awvwgk",
+ "date": "2022-05-12 21:32:04+00:00",
+ "text": "I just revisited the API for color escape sequences for a different project and came up with a more robust scheme in tblite/tblite#37. The implementation in question can be found at terminal.f90, if anyone is interested, feel free to use the linked file under MIT license for stdlib.\nThe linked PR shows beside the escape code implementation, an integration all the way up to the callback logger in the Python API which should allow to see colorful output when driving the Fortran library from Python in a cell of a notebook.\nColorful Python/Fortran interop"
+ },
+ {
+ "user": "awvwgk",
+ "date": "2022-05-16 12:51:27+00:00",
+ "text": "I removed the true color support because I didn't use it for my applications so far. Regarding the naming of the type, I'm open for suggestions, the currently chosen in this PR might not be the best choice."
+ },
+ {
+ "user": "certik",
+ "date": "2022-05-18 22:38:31+00:00",
+ "text": "I reread my comments, I still agree with them. Essentially:\n\nI am not a big fan of overloading operators and derived types, it feels like an API that one has to learn, but others like it, so it's fine with me.\nWindows require initialization, but that is out of scope for colors\nIt's hard for me to decide if we should just merge it? I feel it's important to move stdlib forward, even if we don't have perfect agreement, and then iterate on it, rather than stall the development trying to find the perfect solution, however I am also worried about stdlib having half-baked solutions that don't end up being used by users much. Related: should this be an fpm package first to get some real usage by people first?\n\nThe last point is the most important, so I opened up a meta issue #658 to discuss it more."
+ },
+ {
+ "user": "awvwgk",
+ "date": "2022-05-19 08:48:04+00:00",
+ "text": "Fpm project is up at https://github.com/awvwgk/fortty"
+ },
+ {
+ "user": "milancurcic",
+ "date": "2022-05-19 15:05:57+00:00",
+ "text": "It seems like we have a few approvals and no objects, so let's give it a few more days and merge on Monday, May 23, if there are no objections.\nThanks Sebastian and all reviewers!"
+ },
+ {
+ "user": "certik",
+ "date": "2022-05-19 15:52:52+00:00",
+ "text": "As discussed in #658, it seems we all agree to go with the route of \"merge much quicker to experimental, and reserve the right to completely change or even remove later\". So I am fine to merge this as is and go from there. And for other PRs, let's do this in a matter of days or weeks, not months.\n(And my objections above were not meant to derail the merging of this. In light of the above, it now seems to me it is much more important to merge quickly and iterate, rather than wait.)"
+ },
+ {
+ "user": "jvdp1",
+ "date": "2022-05-19 17:53:49+00:00",
+ "text": "As discussed in #658, it seems we all agree to go with the route of \"merge much quicker to experimental, and reserve the right to completely change or even remove later\".\n\nI don't think that we all agree on that. However, as I mentioned it in this comment, I think this PR could be merged as is, such that people can try it through fpm."
+ },
+ {
+ "user": "awvwgk",
+ "date": "2022-05-19 19:48:15+00:00",
+ "text": "The only thing a little off is that the derived type is called ansi_color but it represents not only a color but an entire ansi_style or ansi_escape.\n\nJust rebased and renamed the derived type to ansi_code to better reflect that it can contain a style while keeping the name short (and avoiding British / American English variants)."
+ },
+ {
+ "user": "ivan-pi",
+ "date": "2022-05-19 21:19:57+00:00",
+ "text": "ansi_code is very reasonable given that \"ANSI code\" redirects to ANSI Escape Codes on Wikipedia."
}
]
},
@@ -2342,11 +2621,12 @@
"number": 577,
"user": "iajzenszmi",
"date": "2021-11-25 04:36:53+00:00",
- "title": "Various compilation warnings. eg \"n may be used unitialized in this function\". The code should be edited so that zero warnings are produced. with the -Wall flag on.",
- "text": "Description\nWarning: \u2018n\u2019 may be used uninitialized in this function [-Wmaybe-uninitialized]\n/home/ian/fortran-stdlib/src/stdlib_stats_var.f90:4258:0:\n\n 4258 | real(sp) :: n\n | \nWarning: \u2018n\u2019 may be used uninitialized in this function [-Wmaybe-uninitialized]\n/home/ian/fortran-stdlib/src/stdlib_stats_var.f90:4099:0:\n\n 4099 | real(qp) :: n\n | \nWarning: \u2018n\u2019 may be used uninitialized in this function [-Wmaybe-uninitialized]\n/home/ian/fortran-stdlib/src/stdlib_stats_var.f90:3940:0:\n\n 3940 | real(xdp) :: n\n | \nWarning: \u2018n\u2019 may be used uninitialized in this function [-Wmaybe-uninitialized]\n/home/ian/fortran-stdlib/src/stdlib_stats_var.f90:3781:0:\n\n 3781 | real(dp) :: n\n | \nWarning: \u2018n\u2019 may be used uninitialized in this function [-Wmaybe-uninitialized]\n/home/ian/fortran-stdlib/src/stdlib_stats_var.f90:3622:0:\n\n 3622 | real(sp) :: n\n | \nWarning: \u2018n\u2019 may be used uninitialized in this function [-Wmaybe-uninitialized]\n/home/ian/fortran-stdlib/src/stdlib_stats_var.f90:2815:0:\n\n 2815 | real(dp) :: n\n | \nWarning: \u2018n\u2019 may be used uninitialized in this function [-Wmaybe-uninitialized]\n/home/ian/fortran-stdlib/src/stdlib_stats_var.f90:2772:0:\n\n\nhttps://scholar.google.com.au/scholar?hl=en&as_sdt=0%2C5&q=the+cost+of+ignoring++fortran+compilation+warnings+eg+unitialized+variables&btnG=\nKN King, AJ Offutt - Software: Practice and Experience, 1991 - Wiley Online Library\n\u2026 The predicate analysis operators represent errors that programmers make inside \u2026 variable\nshould get a value before execution begins; output (OUT) indicates that the variable\u2026 mutation\noperators can replace initialized variables with uninitialized variables or change valid array \u2026\n\u2026 \u2019s compiler warnings and static analysis tools flag only a small subset of these uninitialized\n\u2026 for example, by existing compiler functionality for local variables in Fortran), but in particular,\n\u2026 For example, virtual function calls may be made using uninitialized local variables which are \u2026\nSave Cite Cited by 29 Related articles All 7 versions\n[PDF] psu.edu\nA fortran language system for mutation\u2010based software testing\nKN King, AJ Offutt - Software: Practice and Experience, 1991 - Wiley Online Library\n\u2026 The predicate analysis operators represent errors that programmers make inside \u2026 variable\nshould get a value before execution begins; output (OUT) indicates that the variable\u2026 mutation\noperators can replace initialized variables with uninitialized variables or change valid array \u2026\nSave\nCite Cited by 523 Related articles All 11 versions\nExperience with Fortran verifier\nR Conradi - European Software Engineering Conference, 1987 - Springer\n\u2026 those for global variables with cost O(NCalls*(NCallLoops+2) \u2026 The ROUTVER errors refer\nto NIP-variables, and the SYSTVER errors to IP-variables. Calls to intrinsic \u2026 Anyhow, there\nis a staggering amount of uninitialized NIP-variables, although the current LIVE analysis is \u2026\nSave\nCite Cited by 4 Related articles All 5 versions\nTypestate: A programming language concept for enhancing software reliability\nRE Strom, S Yemini - IEEE Transactions on Software \u2026, 1986 - ieeexplore.ieee.org\n\u2026 type errors, in a theoretical treatment one can \"define away\" the errors by means of language\nextensions, eg, by adding uninitialized values \u2026 Whenever it is possible to resolve aliasing\nstatically, as in languages which do not support pointer variables (eg, Fortran or Algol 60), or in \u2026\nSave Cite Cited by 688 Related articles All 9 versions\nExpected Behaviour\nA make run in which Warning messages are absent when running -Wall.\nVersion of stdlib\nFork 88\nPlatform and Architecture\nLinux ubuntu\nAdditional Information\nhttps://dl.acm.org/doi/abs/10.1145/763984.763986",
+ "title": "Spurious warnings in gfortran",
+ "text": "Description\nVarious compilation warnings. eg \"n may be used unitialized in this function\".\nThe code should be edited so that zero warnings are produced. with the -Wall flag on.\nWarning: \u2018n\u2019 may be used uninitialized in this function [-Wmaybe-uninitialized]\n/home/ian/fortran-stdlib/src/stdlib_stats_var.f90:4258:0:\n\n 4258 | real(sp) :: n\n | \nWarning: \u2018n\u2019 may be used uninitialized in this function [-Wmaybe-uninitialized]\n/home/ian/fortran-stdlib/src/stdlib_stats_var.f90:4099:0:\n\n 4099 | real(qp) :: n\n | \nWarning: \u2018n\u2019 may be used uninitialized in this function [-Wmaybe-uninitialized]\n/home/ian/fortran-stdlib/src/stdlib_stats_var.f90:3940:0:\n\n 3940 | real(xdp) :: n\n | \nWarning: \u2018n\u2019 may be used uninitialized in this function [-Wmaybe-uninitialized]\n/home/ian/fortran-stdlib/src/stdlib_stats_var.f90:3781:0:\n\n 3781 | real(dp) :: n\n | \nWarning: \u2018n\u2019 may be used uninitialized in this function [-Wmaybe-uninitialized]\n/home/ian/fortran-stdlib/src/stdlib_stats_var.f90:3622:0:\n\n 3622 | real(sp) :: n\n | \nWarning: \u2018n\u2019 may be used uninitialized in this function [-Wmaybe-uninitialized]\n/home/ian/fortran-stdlib/src/stdlib_stats_var.f90:2815:0:\n\n 2815 | real(dp) :: n\n | \nWarning: \u2018n\u2019 may be used uninitialized in this function [-Wmaybe-uninitialized]\n/home/ian/fortran-stdlib/src/stdlib_stats_var.f90:2772:0:\n\nExpected Behaviour\nA make run in which Warning messages are absent when running -Wall.\nVersion of stdlib\nFork 88\nPlatform and Architecture\nLinux ubuntu\nAdditional Information\nhttps://dl.acm.org/doi/abs/10.1145/763984.763986",
"is_open": true,
"labels": [
- "bug"
+ "bug",
+ "wontfix"
],
"comments": [
{
@@ -2363,6 +2643,11 @@
"user": "iajzenszmi",
"date": "2021-11-29 05:06:49+00:00",
"text": "Spurious gfortran warnings reported to bugzilla.\nttps://\nwww.google.com/search?client=ms-google-coop&q=gfortran+spurious+warnings&cx=008043952663535741821:9whwb87ip5a\n\nDid you mean: gfortran suppress warnings\n\n70312 \u2013 Spurious -Wsurprising warnings for final subroutines\nhttps://gcc.gnu.org \u203a bugzilla \u203a show_bug\n19 Mar 2016 \u2014 -Wsurprising issues spurious warnings about final procedures.\nmodule foo_type type foo contains final :: foo_delete end type contains ...\nYou visited this page on 29/11/21.\n\n\n 59107 \u2013 [8/9/10/11 Regression] Spurious \"Type specified for ...\n https://gcc.gnu.org \u203a bugzilla \u203a show_bug\n\n11 May 2020 \u2014 ... Apr 23 10:33:14 2020 +0100 Fortran : Spurious warning\nmessage with -Wsurprising PR59107 This change is from a patch developed for\ngcc-5.\n\n[5/6 Regression] Spurious warning on derived type initialization\nhttps://gcc.gnu.org \u203a bugzilla \u203a show_bug\n29 Sept 2019 \u2014 Bug 60500 - [5/6 Regression] Spurious warning on derived\ntype ... compiler version: GNU Fortran (Ubuntu 4.8.1-2ubuntu1~12.04) 4.8.1\nNotes: ...\n\nUsing the GNU Compiler Collection - GCC, the GNU Compiler ...\nhttps://gcc.gnu.org \u203a onlinedocs \u203a gcc-7.2.0 \u203a gcc.ps.gz\nPS\nSee Section \u201cStandards\u201d in The GNU Fortran Compiler, for details of\nstandards ... Some spurious warnings can be avoided if you declare all the\nfunctions you.\n\u2026\nOn Mon, Nov 29, 2021 at 2:25 AM Jeremie Vandenplas ***@***.***> wrote:\n The file stdlib_stats_var.f90 generated for fpm` can be found here\n \n .\n\n These are indeed spurious warnings (at least the last time I checked).\n\n \u2014\n You are receiving this because you authored the thread.\n Reply to this email directly, view it on GitHub\n <#577 (comment)>,\n or unsubscribe\n \n ."
+ },
+ {
+ "user": "14NGiestas",
+ "date": "2022-05-05 20:57:44+00:00",
+ "text": "Such spurious warnings are an old bug in gfortran and they are not related to stdlib. This issue seems to come back and forth due to its nature. The most recent bugs I could track are:\n\nBug 77504 - [9/10/11/12/13 Regression] \"is used uninitialized\" with allocatable string and array constructors\n\n\nBug 56670 - Allocatable-length character var causes bogus warning with -Wuninitialized\n\nIt can't be fixed here (Only a patch to GCC could), so I guess this is a \"won't fix\".\nI'm editing the title so this issue gets shorter and clearer.\nI'll keep this open in case someone is interested in proposing a workaround."
}
]
},
@@ -3988,11 +4273,17 @@
"date": "2021-09-19 17:16:31+00:00",
"title": "Manual makefile does not clean fypp generated test files",
"text": "The test_median is currently using fypp to generate the actual test file:\n\n \n \n stdlib/src/tests/stats/Makefile.manual\n \n \n Lines 1 to 7\n in\n 8bfcdf9\n \n \n \n \n\n \n \n SRCFYPP =\\ \n \n\n \n \n test_median.fypp \n \n\n \n \n \n \n\n \n \n SRCGEN = $(SRCFYPP:.fypp=.f90) \n \n\n \n \n \n \n\n \n \n $(SRCGEN): %.f90: %.fypp common.fypp \n \n\n \n \n \tfypp $(FYPPFLAGS) $< $@ \n \n \n \n\n\nSince the include makefile for generating the tests is not aware of the fypp usage the clean command is not working correctly. Running the manual makefile will leave a stale build artifact in the source tree which can be picked when doing a local fpm export using the ci/fpm-deployment.sh script or by the CMake build files.",
- "is_open": true,
+ "is_open": false,
"labels": [
"build: make"
],
- "comments": []
+ "comments": [
+ {
+ "user": "ivan-pi",
+ "date": "2022-05-19 18:23:33+00:00",
+ "text": "Closing due to #657 (Remove support for manual make builds)."
+ }
+ ]
},
{
"number": 532,
@@ -4277,7 +4568,7 @@
"date": "2021-09-17 13:56:57+00:00",
"title": "Should we continue maintaining the manual Makefiles?",
"text": "With stdlib now being also an fpm package, as well as CMake support, should we continue maintaining the manual Makefiles?\nI argued for manual Makefiles early on (before fpm) due to the possible absence of CMake or a sufficient version of CMake on many systems. However, the cost of maintaining manual Makefiles is quite high relative to the fpm or CMake build. For example, adding a new module and tests requires editing multiple Makefiles in the source tree. And it gets messier when trying to merge some older PRs, as the manual Makefiles would often be in conflict with the target branch.\nWe could run a poll on Discourse and see what users there think. I think this may be a good time to remove manual Makefile support. What do you think?",
- "is_open": true,
+ "is_open": false,
"labels": [
"question",
"build: make"
@@ -4302,6 +4593,11 @@
"user": "certik",
"date": "2021-09-17 15:12:57+00:00",
"text": "Now when fpm supports stdlib, I am fine dropping them.\nI don't have time right now, but I really want to provide cmake and make backends for fpm. That way we only have to make sure things build using fpm in stdlib, and fpm takes care of cmake and make and we can also add meson, etc."
+ },
+ {
+ "user": "14NGiestas",
+ "date": "2022-05-06 04:09:09+00:00",
+ "text": "Keeping a makefile for a project like this is kinda annoying because of the non-trivial dependencies and it tends to get outdated. I usually don't like cmake much because I always forget the -DMAXRANK... thing... err... well I forgot again but it works well enough and isn't so complicated adding new files to it.\nAlso with fpm I just run the ./ci/fpm_deployment.sh, cd stdlib-fpm, and I can review a patch easily, build it, create a quick app/main.f90 to play around."
}
]
},
@@ -4817,6 +5113,7 @@
"text": "Loadtxt reads an array, which will typically represent data. Often a data file will have have column labels on the first line. I suggest adding an optional nskip_lines argument so that loadtxt can handle such a file by calling it with nskip_lines = 1. One could also add an optional col_labels(:) character array argument, such that\nsize(col_labels) == size(d,2). Adding these features would allow loadtxt to handle a wider range of data files that people have and give it some of the functionality of read.table() in R. The functions to read data frames in R and Python pandas allow columns to be of different types, which I do not expect loadtxt to handle.\nTo speed up a program during development one may read only a subset of the data. To accommodate this optional arguments max_rows and max_col could be added. Read.table() in R has an nrows argument, the maximum number of rows to read in.",
"is_open": true,
"labels": [
+ "in progress",
"API",
"topic: IO"
],
@@ -4992,6 +5289,11 @@
"user": "Beliavsky",
"date": "2021-09-07 03:06:37+00:00",
"text": "Will savebin write the size (not the dimensions) of the array before writing the array? If not, how will the user provide an allocated array with the proper size to loadbin? One way is to get the file size with inquire(file=data_file,size=file_size) and infer the number of elements."
+ },
+ {
+ "user": "14NGiestas",
+ "date": "2022-05-05 18:48:45+00:00",
+ "text": "Hi @Beliavsky, since #581 we have routines to read and write uncompressed npy files which are basically a self-described binary that can be used for data portability as you suggested. The savebin(array) should not write anything else besides the data being dumped, and the loadbin(array, ...) should receive enough arguments to interpret the binary.\nThis has some other applications and is related to #621.\nIt would be awesome to have a binary stream-like thingy like python's bytes (immutable), bytearray (mutable), and the struct."
}
]
},
@@ -6489,6 +6791,16 @@
"user": "adenchfi",
"date": "2022-02-09 20:58:23+00:00",
"text": "Oh, thanks! I should have tested first, I took the docs too literally."
+ },
+ {
+ "user": "ivan-pi",
+ "date": "2022-05-04 11:33:33+00:00",
+ "text": "While scrolling through the ARCHER2 super-computing service documentation I learned there is BSD-licensed library for MATLAB MAT files called matio. It also has a Fortran interface (help wanted tbeu/matio#51), however it is doesn't appear to use the standard Fortran/C interoperability.\nAs @awvwgk has remarked above, supporting MATLAB binary files would require a zlib interface and potentially also HDF5, both of which are available as C libraries. It looks more straightforward to just have a thin Fortran wrapper of a C/C++ implementation, than to write an interface/implementation for zlib (and HDF5) first."
+ },
+ {
+ "user": "ivan-pi",
+ "date": "2022-05-04 12:38:04+00:00",
+ "text": "How do we want to handle the npz format? It is a zip archive with npy files. Probably, we have to develop a general interface for interacting with compressed archives first.\n\nIn case of the compressed npz files created with numpy.savez_compressed, the NumPy documentation states zipfile.ZIP_DEFLATED is used which requires zlib behind the scenes.\nIrrespective of how we manage to do the zipping/compression (either in C or Fortran), with respect to the zipped format a big question is how to replace positional and keyword arguments in Fortran, without getting overwhelmed by the combinatorial explosion of type/kind/rank + number of saved arrays."
}
]
},
@@ -6611,7 +6923,7 @@
"date": "2021-08-04 00:52:02+00:00",
"title": "More matrix property checks",
"text": "Description\n\n\nI'd been tossing around this proposal for a while, but was spurred into action by @zoziha's recent issue which proposed is_square and is_symmetric checks.\nThis proposal suggests built-in matrix property checks for common properties like triangularity, hermiticity, etc. These kinds of checks are not difficult to write inline with a main program, but having them as a one line call with an obvious name would make any calling code shorter and more readable, and I believe such checks are common enough to warrant inclusion in the standard library.\nIn addition to first two proposed by zoziha, I am proposing a few extras. Below is my full list for now, but additions are welcome:\n\nis_square\nis_symmetric\nis_skew_symmetric\nis_triangular (upper, lower, diagonal (upper and lower), and false none results)\nis_hermitian\nis_hessenberg (upper, lower, tridiagonal (upper and lower), and false/none results)\netc.\n\nPrior Art\n\n\nNumpy does not appear to have an is_symmetric or any other of the proposed checks (after light digging)\nMatLab has an issymmetric that uses an option to also work as a skew symmetric test, it takes a matrix and returns a bool\nJulia has issym (here and see links for other is* tests), isdiag, istriu, istril, ishermitian, all of which take a matrix and return a bool\n\nAPI Discussion\nis_square, is_symmetric, is_skew_symmetric, and is_hermitian will probably be four separate tests that all take a matrix and return a bool*\n*The one exception I might suggest is perhaps is_square having a form like is_square(A,n) that also sets n=dim(A). Personally I have found this extremely useful when checking inputs to my own liinear algebra routines for methods or decompositions in which only square matrices are permitted. I believe this form of is_square could be snuck into the interface.\nThe case of triangular and Hessenberg tests will perhaps require a bit more discussion. We could only provide the \"exact\" tests for upper and lower (and possibly diag like Julia) and let the user construct the logic \"on their side\", in which case our tests would take a matrix and return a bool. Alternatively, our functions could take a matrix and return a letter for one of the four possibilities. For triangularity, I imagine the outputs being something like 'u': upper, 'l': lower, 'd': diag, 'n': not triangular. Alternatively we could use 'b': both which would generalize for both triangular and Hessenberg but rely on the user to understand what it implies (for example 'b' for Hessenberg implies tridiagonal). I'm partial to the string returns, but I recognize that returning a character/string may not be the expected output of a function called is_*.\nFor all these checks, I think the key will be to find a solution that doesn't require too many unique stdlib functions for a user to remember, doesn't require the caller to do much of the work/logic/thinking on their side, while being easy and obvious in style/format/usage.\nOnce we decide on the API, I'm happy to implement these checks myself or split them among whoever is interested.",
- "is_open": true,
+ "is_open": false,
"labels": [
"topic: mathematics",
"idea"
@@ -6661,6 +6973,11 @@
"user": "ghbrown",
"date": "2021-08-19 04:05:56+00:00",
"text": "Based on the entries listed in your link, I'm not so sure that the matrix is_* functions would fit in with other \"logic functions\", even though they obviously return truthy values. The problem of where to put these is made more difficult since Numpy doesn't have the matrix checks built in (that I could find).\nEither place is fine with me, though, and moving it over should be pretty simple if we decide where to put after implementation. I should be able to start my PR this weekend with couple checks implemented. I'll put them in stdlib_linalg.f90 for now, since that makes the most sense to me. Glad you implemented the close functions, they'll be good to have."
+ },
+ {
+ "user": "ghbrown",
+ "date": "2022-05-04 16:29:13+00:00",
+ "text": "My PR was merged quite a while ago, so I'm closing the issue to remove clutter. Feel free to reopen if needed."
}
]
},
@@ -10313,7 +10630,7 @@
"date": "2021-04-18 13:41:22+00:00",
"title": "Compilation problems using CMake and ifort (IFORT) 18.0.3 20180410",
"text": "My version of ifort\nifort (IFORT) 18.0.3 20180410\nCopyright (C) 1985-2018 Intel Corporation. All rights reserved.\nis having trouble compiling stdlib when invoked using make. In particular while compiling stdlib_quadrature_simps.f90 I am getting multiple messages of the form\n ...stdlib_quadrature_simps.f90(50): error #6284: There is no matching specific function for this generic function reference. [SIMPS]\n integral = simps38(y(1:4), dx) + simps(y(4:6), dx)\n ------------------------------------------------------^\n\nFWIW I get no messages when compiling with gfortran 10.2.",
- "is_open": true,
+ "is_open": false,
"labels": [
"duplicate",
"build: cmake",
@@ -10339,6 +10656,11 @@
"user": "wclodius2",
"date": "2021-04-18 18:10:36+00:00",
"text": "Thanks"
+ },
+ {
+ "user": "14NGiestas",
+ "date": "2022-05-05 21:50:40+00:00",
+ "text": "Closing in favor of #299"
}
]
},
@@ -10874,7 +11196,7 @@
"date": "2021-04-08 02:26:46+00:00",
"title": "Median",
"text": "I suggest that the descriptive statistics section include the median. Alan Miller's median.f90 could be used. Arguably any library that has a function for the mean should also have one for the median, since the latter is a more robust measure of central tendency (although less efficient than the arithmetic mean for Gaussian data).",
- "is_open": true,
+ "is_open": false,
"labels": [
"topic: mathematics"
],
@@ -10883,6 +11205,11 @@
"user": "jvdp1",
"date": "2021-04-08 19:02:58+00:00",
"text": "Thank you for opening this thread. I agree with you that stdlib should include a function for the median (but also for the quartiles,..). However, such functions need sorting algorithms. This might be solved in a near-future with #98. I think it is better to rely on a module that provide general algorithms, instead of implementing its own algorithm as in Alan Miller 's code.\nThis issue is also related to #113 in which such a function was already proposed."
+ },
+ {
+ "user": "14NGiestas",
+ "date": "2022-05-05 18:01:24+00:00",
+ "text": "Closing this issue since it was addressed by #426, stdlib has median since v0.1.0"
}
]
},
@@ -11030,12 +11357,18 @@
"date": "2021-03-30 18:32:36+00:00",
"title": "Problems using Makefile.manual on OS X V11.2.3 \"BigSur\"",
"text": "I am testing out some possible additions to stdlib. During initial development CMake has worked well in compiling the source code. I would now like to appropriately modify Makefile.manual so that it can also be used to compile the files. I am getting a load time error for gfortran 10.2.0: \"ld: library not found for -lSystem\". Is there some obvious change I can do so that Makefile.manual will work? I assume I need to modify the library search path.",
- "is_open": true,
+ "is_open": false,
"labels": [
"build: make",
"platform: MacOS"
],
- "comments": []
+ "comments": [
+ {
+ "user": "ivan-pi",
+ "date": "2022-05-19 18:25:00+00:00",
+ "text": "Closing due to #657 (Remove support for manual make builds)."
+ }
+ ]
},
{
"number": 370,
@@ -11724,6 +12057,7 @@
"text": "Idea:\n\nhttps://twitter.com/arclight/status/1371676228856463364\n\nPreliminary repository:\n\nhttps://twitter.com/arclight/status/1371913313211273216\nhttps://gitlab.com/apthorpe/stdlib-codata/-/blob/1c541b3a71556fd89cc6a9f03d401c757d182ceb/src/STDLIB_CODATA_2018.f90\n\nPrior art:\n\nScipy: https://docs.scipy.org/doc/scipy/reference/constants.html\nfundamental_constants: https://github.com/vmagnin/fundamental_constants\nQCElemental: https://github.com/MolSSI/QCElemental/blob/master/qcelemental/physical_constants/context.py",
"is_open": true,
"labels": [
+ "duplicate",
"topic: utilities"
],
"comments": [
@@ -11731,6 +12065,21 @@
"user": "awvwgk",
"date": "2021-03-16 23:38:09+00:00",
"text": "Related discourse thread: https://fortran-lang.discourse.group/t/physical-constants/822"
+ },
+ {
+ "user": "14NGiestas",
+ "date": "2022-05-05 23:34:37+00:00",
+ "text": "Sounds like a duplicate of #99, doesn't it? It's about physical \"constants\" and all but I think this discussion should be kept there."
+ },
+ {
+ "user": "certik",
+ "date": "2022-05-19 19:49:13+00:00",
+ "text": "I view #99 as a limited to mathematical constants like pi, e and such. The CODATA are physical constants, so I think it might be slightly different."
+ },
+ {
+ "user": "14NGiestas",
+ "date": "2022-05-19 20:24:17+00:00",
+ "text": "Scipy put math and physical constants in the same bag under scipy.constants that's why I bring that (not that we should follow scipy in every possible way but this seems to share the same design issues)."
}
]
},
@@ -11838,7 +12187,18 @@
"labels": [
"topic: utilities"
],
- "comments": []
+ "comments": [
+ {
+ "user": "14NGiestas",
+ "date": "2022-05-05 16:16:17+00:00",
+ "text": "here's some context/rant, IDK, maybe it is worth your time:\nI have a failed experiment where I tried to automatically fetch and build using a CI the unicode name list, the idea didn't work because it generates some ridiculously long names like ARABIC_LIGATURE_LAM_WITH_ALEF_WITH_HAMZA_BELOW_ISOLATED_FORM (even in CamelCase or compiler flags) and without them, the file compilation is killed or takes an eternity either way. So I stopped when I figured that I would need to create a hash_map/database structure \ud83d\ude09\n\nI wonder if there is some standard C source for such information.\nHere are some pointers:\nhttps://www.unicode.org/reports/tr21/tr21-3.html\nhttps://www.unicode.org/reports/index.html"
+ },
+ {
+ "user": "wclodius2",
+ "date": "2022-05-06 00:46:24+00:00",
+ "text": "FWIW my attempt at creating processing for Unicode used one-d arrays. It makes use of the old saw, \"there is nothing that can's be fixed by an additional level of indirection\". One was an array of a derived type that includes the defined non-Unihan data. This has I believe just over 100,000 elements for the latest data base. Another was an array of 17*2**16 int32 integers that for the corresponding Unicode code point either is an index to the corresponding element of the first array, or the value 0 if the code point does not have any non-Unihan data defined. The code point names were stored in a single long character string, and the derived type included indices to the starting and stopping character of its corresponding name. Most of the other attributes of the code points were represented by derived types whose only component was an eight bit integer, that served as an enumeration of the property values. This kept the storage required for the first array down to a few tens(?) of Megabytes."
+ }
+ ]
},
{
"number": 343,
@@ -13894,6 +14254,11 @@
"user": "ivan-pi",
"date": "2021-10-18 19:55:05+00:00",
"text": "I found an old thread from @certik, which discusses how to implement the incomplete gamma function:\n\nFast and accurate double precision implementation of incomplete gamma function: https://scicomp.stackexchange.com/questions/3341/fast-and-accurate-double-precision-implementation-of-incomplete-gamma-function\n\nThe function is covered by Chapter 8 in DLMF."
+ },
+ {
+ "user": "14NGiestas",
+ "date": "2022-05-06 03:35:45+00:00",
+ "text": "I'm just moving and linking the old thread mentioned (#102) here, where it looks the discussion got further.\n\nThere are lots of implementations online.\nAs an example, here are the special functions that I needed in my projects over the past 10 years:\nhttps://github.com/certik/fortran-utils/blob/b43bd24cd421509a5bc6d3b9c3eeae8ce856ed88/src/special.f90\nhttps://github.com/certik/hfsolver/blob/b4c50c1979fb7e468b1852b144ba756f5a51788d/src/special_functions.f90\nBeing able to standardize on the API for all or most of them would be a huge deal. Other languages:\nSciPy\nhttps://docs.scipy.org/doc/scipy/reference/special.html\nMatlab\nhttps://www.mathworks.com/help/matlab/special-functions-1.html\nJulia\nSeparate package: SpecialFunctions.jl"
}
]
},
@@ -15758,6 +16123,7 @@
"text": "I now find myself with some free time that I would like to put in to extending the STDLIB. I have some preliminary work on three topics that might be useful to users of STDLIB: error codes, hash tables/unordered maps, and the unicode database. I would appreciate some guidance as to which topic people would find most useful and whether the interest in any topic is high enough to justify inclusion in STDLIB.\nFor error codes the idea is to standardize how the stdlib identifies and distinguises error conditions. I have a list of 100+ error code names, each with unique integer values. The names currently follow a pattern language in which a suffix is used to indicate the general source of the error: _failure, in which the outside world is not as expected, _error, in which the programmer likely made a mistake, and _fault, in which the processor is likely at fault. This pattern language makes the names a little unwieldy so I am considering dropping it. I have also defined a subroutine that takes an error code as an argument and stops processing with an error stop with an error code dependent string as the stop code. The resulting codes could be made part of stdlib_error.f90 and the subroutine part of an overloaded error_stop. FWIW this approach was inspired by a [posting by Richard A. O'Keefe in the Erlang mail list] (http://erlang.org/pipermail/erlang-questions/2015-March/083608.html).\nThe hash tables/unordered maps are composed of two or three modules: a module of hash functions, a module of hash tables using key/value pairs to implement an unordered map, and perhaps a module of hash tables using keys to implement an unordered set. The hash functions would have to be non-cryptographic to be legal in the US. Ideally there should be several different functions so the function can be changed in the event of excessive collisions. My idea is to use 64 bit hashes as reasonable for large data sets, though I can be persuaded to use 32 bit hashes. I have tentatively identified the Fowler-Noll-Voh (FNV) hash, the Murmur hash, and the Spooky hash as 64 bit public domain hash functions of interest. If anyone believes that any of these hashes are cryptographic let me know, or if you know of \"better\" hash functions. The hashes will be a transliteration to signed arithmetic assuming two's complement arithmetic and overflow detection can be turned off. The hash table will store the key and the value as (transferred) eight bit integer arrays. The tables can come in two implementations: chaining and open tables. They will use power of two table sizes, which assumes that the hash functions do an excellent job of randomizing bits.\nThe Unicode consortium maintains a database of character properties for the UCS character set. This database is the basis of the Python module unicodedata. This database is necessary for assigning code points to categories (e.g., number, letter, and punctuation), converting strings to one of the four normalization forms, and case folding. I consider this data necessary for the implementation of a UCS based varying string module. The initial implementation would be a module with procedures that use 32 bit integer scalars and arrays to represent UCS code points and strings. Several of the Unicode categories (\"Bidi\", \"General Category\", \"Decomposition\", and \"Numerical\") would be represented by enumerations in category specific types whose only components are eight bit integers. The text files in the UCD and Unihan directories that make up the database take up about 70.5 MBytes, so supporting this database requires a very significant download. The rank one arrays implementing this database take up a comparable amount of runtime storage.",
"is_open": true,
"labels": [
+ "in progress",
"topic: utilities"
],
"comments": [
@@ -16267,7 +16633,7 @@
"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?",
- "is_open": true,
+ "is_open": false,
"labels": [
"topic: IO"
],
@@ -16296,6 +16662,16 @@
"user": "wclodius2",
"date": "2020-12-04 23:15:30+00:00",
"text": "Great!"
+ },
+ {
+ "user": "14NGiestas",
+ "date": "2022-05-05 16:24:45+00:00",
+ "text": "This issue was solved 9 Dec 2020 by #261 and probably can be closed."
+ },
+ {
+ "user": "14NGiestas",
+ "date": "2022-05-05 17:22:53+00:00",
+ "text": "I'm closing this issue since it was solved and merged in #261 ."
}
]
},
@@ -17297,6 +17673,7 @@
"text": "Besides common descriptive statistics, we need standard modules for various continuous statistical distribution (e.g., gamma distribution) and discrete distribution (e.g., bernoulli distribution). These statistical distributions will be very useful to various computer simulation techniques.\nEven though these functions are available in Scipy package for python, I think it is worthwhile to have in stdlib with pure Fortran. There are plenty of source codes on the net, we just need to convert them.",
"is_open": true,
"labels": [
+ "in progress",
"topic: mathematics",
"idea"
],
@@ -18129,7 +18506,7 @@
"date": "2020-08-07 22:56:33+00:00",
"title": "Develop an API for a STDLIB logging system",
"text": "It is common for a library of code to have the equivalent of one or more error logging modules. SLATEC has its XERROR codes, Futility has its ExceptionHandler.f90 and FileTypeLog.f90, and FLIBS has its reporting, m_logger, m_multilog, and m_exception modules. I propose that STDLIB have its own logger module that I propose naming STDLIB_LOGGER. I propose that the logger have options to:\n\nbe able to send the same text to multiple logical units;\nbe able to configure which units receive the text;\nby default have one of those units be one of OUTPUT_UNIT or ERROR_UNIT;\nprecede messages by a blank line;\nprecede messages by a time stamp of the form yyyy-mm-dd hh:mm:ss.sss;\nprecede a message with module and procedure names;\nfollow a message with the STAT and ERRMSG of the statement that prompted the log message;\nfollow a message with the IOSTAT and IOMSG of the I/O statement that prompted the log message;\nlabel a message with one of 'INFORMATION: ', 'WARNING: ', or 'ERROR: ';\nindent subsequent lines of the messages; and\nformat the text to fit within a maximum column width.\n\nThe maximum number of logical units to be supported at one time is a minimum of two: one of either OUTPUT_UNIT or ERROR_UNIT and an additional formatted file, but by using an array of logical units it should be possible to support more, such as the five supported by SLATEC's XERROR. While the initial implementation will use Fortran's standard file interface through logical units, I hope to hide enough of the details that wrappers to the logical units can be deployed if desired. The above proposal prompts the following questions:\n\nIs the general outline of the proposal a good one?\nIs STDLIB ready for such a proposal at this time?\nWhich should be the default logical unit for the logger: OUTPUT_UNIT or ERROR_UNIT?\nShould you be able to output to both OUTPUT_UNIT and ERROR_UNIT at the same time?\nHow many output units should be supported at one time?\nShould output of the labels be determined by the name of the procedure, e.g., LOG_ERROR, LOG_WARNING, and LOG_INFO, or by a flag?\nAre there any other questions I am missing?",
- "is_open": true,
+ "is_open": false,
"labels": [
"implementation",
"topic: IO"
@@ -18219,6 +18596,11 @@
"user": "w6ws",
"date": "2021-05-07 18:08:49+00:00",
"text": "Should also note that in ESMF, we wanted to distinguish between our library 'return codes' (rc=) and Fortran-specific iostat/stat status returns. So the different entry points into the Log class reflected that as well."
+ },
+ {
+ "user": "14NGiestas",
+ "date": "2022-05-05 16:30:52+00:00",
+ "text": "This issue was addressed in stdlib_logger a while ago so it's API discussion can be safely closed (I can't find the exact PR)."
}
]
},
@@ -18735,7 +19117,7 @@
"date": "2020-07-18 02:36:09+00:00",
"title": "API for a bitset data type ",
"text": "Both C++ and Java define a bitset type, so I propose that the standard\nlibrary also have a module implementing a bitset type. My first draft\nfor a public API for that module is as follows.\nThe module name is STDLIB_BITSETS.\nThe module exports one constant, BITS_KIND, to be used as a KIND\nvalue in addressing bits in the bitset. This will initially be\nINT32.\nThe module exports one derived type, BITSETS, with a plural name so\nthat users can name their scalar realizations as BITSET. The type\nwill contain two private components: BITS a scalar integer of kind\nBITS_KIND giving the number of bits in a bitset entity, and a rank\none allocatable integer array BLOCK of private kind BLOCK_KIND,\nthat will be INT32, to be used in holding the bit values. The type\nhas an ASSIGNMENT(=) operation defined.\nBITSETS will have the following procedures: ALL, AND, AND_NOT,\nANY_BIT, BIT_COUNT, BITS, CLEAR, EOR, EQUIV, EXTRACT,\nFLIP, INIT, INPUT, MAX_SET_BIT, NONE, OR, OUTPUT,\nPRINT_BITSET, READ_BITSET, SET, TEST, and VALUE. Some of\nthese procedures will be overloaded:\ninterface clear\n module procedure clear_bit, clear_range\nend interface clear\n\ninterface flip\n module procedure flip_bit, flip_range\nend interface flip\n\ninterface init\n module procedure init_copy, init_zero\nend interface init\n\ninterface set\n module procedure set_bit, set_range\nend interface set\n\ninterface print_bitset\n module procedure print_bitset_string, print_bitset_unit\nend interface print_bitset\n\ninterface read_bitset\n module procedure read_bitset_string, read_bitset_unit\nend interface read_bitset\n\nThe API for the individual procedures is listed below. The following\naspects of the API may be controversial:\n\n\nHow the range is defined for CLEAR_RANGE, FLIP_RANGE, and\nSET_RANGE. I have roughly followed Java's bitset here.\n\n\nThat the first argument is modified in AND, AND_NOT, EOR, and\nOR. That is how it is done in the Java bitset, but I can see\nhaving a function that returns the result rather than a subroutine\nthat modifies the first argument.\n\n\nThat the I/O procedures INPUT, OUTPUT, PRINT_BITSET, and\nREAD_BITSET have STATUS flags.\n\n\nThat the procedures often ignore user specification of positions\noutside the range 0 to BITS-1. An alternative is to make the\nprocedures impure and invoking ERROR STOP. Another option is to\nadd a STATUS argument, but I am reluctant to do that for a simple\nuser error.\n\n\nThe names of some of the procedures could be more similar to the\nnames of Fortran's bit intrinsics.\n\n\nsubroutine init_copy(set, aset, bits)\n: Creates the bitset SET, of size BITS if present, otherwise of the\nsize of ASET. All bits in the range of ASET are copied from ASET. If\nBITS is present and larger than the size of ASET then all additional\nbits are zero.\nsubroutine init_zero(set, bits)\n: Creates the bitset, SET, of size BITS, with all bits initialized to\nzero. BITS must be non-negative.\nelemental function all_bits( set )\n: Returns .TRUE. if all bits in SET are 1, .FALSE. otherwise.\nelemental subroutine and(set1, set2)\n: Sets the bits in SET1 to the bitwise AND of the original bits in\nSET1 and SET2. If SET1 has fewer bits than SET2 then the\nadditional bits in SET2 are ignored. If SET1 has more bits than\nSET2, then the absent SET2 bits are treated as if present with\nzero value.\nelemental subroutine and_not(set1, set2)\n: Sets the bits in SET1 to the bitwise and of the original bits in\nSET1 with the bitwise negation of SET2. If SET1 has fewer bits\nthan SET2 then the additional bits in SET2 are ignored. If SET1\nhas more bits, then the absent SET2 bits are treated as if present\nwith zero value.\nelemental function any_bit(set)\n: Returns .TRUE. if any bit in SET is 1, .FALSE. otherwise\nelemental function bit_count(set)\n: Returns the number of non-zero bits in SET.\nelemental function bits(set)\n: Returns the number of bit positions in SET.\nelemental subroutine clear_bit(set, pos)\n: Sets to zero the POS position in SET. If POS is less than zero\nor greater than BITS(SET)-1 it is ignored.\npure subroutine clear_range(set, start_pos, stop_pos)\n: Sets to zero all bits from the START_POS to STOP_POS positions in\nSET. If STOP_POS < START_POS then no bits are modified. Positions\noutside the range 0 to BITS(SET)-1 are ignored.\nelemental subroutine eor(set1, set2)\n: Sets the bits in SET1 to the bitwise EOR of the original bits in\nSET1 and SET2. If SET1 has fewer bits than SET2 then the\nadditional bits in SET2 are ignored. If SET1 has more bits than\nSET2, then the absent SET2 bits are treated as if present with\nzero value.\nelemental function equiv(set1, set2)\n: Returns .TRUE. if all bits in SET1 and SET2 have the same\nvalue, .FALSE. otherwise. If the sets differ in size a value true\nwill be returned if and only if the sets are equivalent in the\noverlapping range, and all bits outside the overlapping range are\nzero.\npure function extract(set, start_pos, stop_pos)\n: Creates a new bitset from a range, START_POS to STOP_POS, in\nbitset SET.\nelemental subroutine flip_bit(set, pos)\n: Flips the value at the POS position in SET, provided the\nposition is valid. If POS is less than 0 or greater than\nBITS(SET)-1, then no value is changed.\npure subroutine flip_range(set, start_pos, stop_pos)\n: Flips all valid bits from the START_POS to STOP_POS positions in\nSET. If STOP_POS < START_POS no bits are flipped. Positions less\nthan 0 or greater than BITS(SET)-1 are ignored.\nsubroutine input(unit, set, status)\n: Reads the components of the bitset, SET, from the logical unit,\nUNIT, assuming that the components were written using OUTPUT.\nelemental function max_set_bit( set )\n: Returns the maximum position with a set bit. If no bit is set\nreturns -1.\nelemental function none(set)\n: Returns .TRUE. if none of the bits in SET have the value 1.\nelemental subroutine or(set1, set2)\n: Sets the bits in SET1 to the bitwise OR of the original bits in\nSET1 and SET2. If SET1 has fewer bits than SET2 then the\nadditional bits in SET2 are ignored. If SET1 has more bits than\nSET2, then the absent SET2 bits are treated as if present with\nzero value.\nsubroutine output(unit, set, status)\n: Writes the components of the bitset, SET, to the logical unit,\nUNIT, in a unformatted sequence compatible with INPUT.\nsubroutine print_bitset_string(string, set)\n: Writes a BITSETS literal to the allocatable default character\nSTRING, representing the individual bit values in the bitsets,\nSET.\nsubroutine print_bitset_unit(unit, set, status, advance)\n: Writes a bitsets literal to the logical unit, UNIT, representing\nthe individual bit values in the bitsets, SET. If STATUS is not\npresent and an error occurs then processing stops with an error\nmessage. If STATUS is present then it has the error code SUCCESS\nif no error occurs, has the value ALLOC_FAULT if failure is due to\nthe allocation of a temporary and, has the value WRITE_FAULT if an\nerror occurs in the write to the unit. By default or if ADVANCE is\npresent with the value 'YES', advancing output is used. If ADVANCE\nis present with the value 'NO', then the current record is not\nadvanced by the write.\nsubroutine read_bitset_string(string, set, status)\n: Uses the bitsets literal in the default character STRING, to\ndefine the bitset, SET. The literal may be preceded by an an\narbitrary sequence of blank characters. If STATUS is not present\nthen an error results in the sending an error message to ERROR_UNIT\nand the termination of the program. If STATUS is present then it has\nthe error code SUCCESS if no error occurs, the value\nINVALID_STRING if the sequence of characters after an initial\nsequence of blanks is not a BITSETS literal, the value\nINVALID_ARRAY_SIZE if the literal's bit size is too large to be\nrepresented by the bit size integer kind, the value ALLOC_FAULT if\nallocation of SET failed for the specified BITSIZE, or\nINVALID_INTEGER if the HEX literal constant is too large to be\nrepresented by a bit size binary integer. If STATUS is present with\nthe value SUCCESS then SET is defined, otherwise it is not\ndefined.\nsubroutine read_bitset_unit(unit, set, status)\n: Uses the bitsets literal at the current position in the formatted\nfile with logical unit, UNIT, to define the bitset, SET. The\nliteral may be preceded by an an arbitrary sequence of blank\ncharacters. If STATUS is not present then an error results in the\nsending an error message to ERROR_UNIT and the termination of the\nprogram. If STATUS is present then it has the error code SUCCESS\nif no error occurs, the value INVALID_STRING if the sequence of\ncharacters after an initial sequence of blanks is not a BITSETS\nliteral, the value INVALID_ARRAY_SIZE if the literal's bitsize is\ntoo large to be represented by the bitsize integer kind, the value\nALLOC_FAULT if allocation of SET failed for the specified bitsize,\nor INVALID_INTEGER if the HEX literal constant is too large to be\nrepresented by a bitsize binary integer. If STATUS is present with\nthe value SUCCESS then SET is defined, otherwise it is not\ndefined.\nelemental subroutine set_bit(set, pos)\n: Sets the value at the POS position in SET, provided the position\nis valid. If the position is less than 0 or greater than BITS(SET)-1\nthen SET is unchanged.\npure subroutine set_range(set, start_pos, stop_pos)\n: Sets all valid bits to 1 from the START_POS to the STOP_POS\npositions in SET. If STOP_POS < START_POS no bits are\nchanged. Positions outside the range 0 to BITS(SET)-1 are ignored.\nelemental function test(set, pos)\n: Returns .TRUE. if the POS position is set, .FALSE.\notherwise. If POS is negative or greater than BITS(SET) - 1 the\nresult is .FALSE..\nelemental function value(set, pos)\n: Returns 1 if the POS position is set, 0 otherwise. If POS is\nnegative or greater than BITS(SET) - 1 the result is 0.",
- "is_open": true,
+ "is_open": false,
"labels": [
"implementation"
],
@@ -19059,6 +19441,16 @@
"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."
+ },
+ {
+ "user": "14NGiestas",
+ "date": "2022-05-05 15:31:56+00:00",
+ "text": "The bitsets module was merged a while ago in #239 I believe the corresponding API discussion can be closed."
+ },
+ {
+ "user": "milancurcic",
+ "date": "2022-05-05 15:38:21+00:00",
+ "text": "Agreed, thanks @14NGiestas."
}
]
},
@@ -20757,7 +21149,7 @@
"date": "2020-05-17 18:50:22+00:00",
"title": "Logger",
"text": "Will a logger be a part of stdlib? For my projects I've written this logger\nhttps://gist.github.com/mobius-eng/16d2a309f80eeee25547d6725334a1a1\nIt is intended to be used through macros: if the logging level is set to\n#define LOGERROR\n\nthis statement will produce no code\n _DEBUG_('TIMESTEP: Calling STEPLSODA')\n\nI would like to contribute it to stdlib if there is a scope for it.",
- "is_open": true,
+ "is_open": false,
"labels": [
"topic: utilities",
"implementation"
@@ -20847,6 +21239,16 @@
"user": "arjenmarkus",
"date": "2020-09-08 06:39:26+00:00",
"text": "For colours you could also consider a library as Foul -\nhttp://foul.sourceforge.net/. Although, its license is set as GPLv3, which\nmight conflict with the purposes of the standard library.\n\n\n\nOp ma 7 sep. 2020 om 20:19 schreef Ian Giestas Pauli <\nnotifications@github.com>:\n\u2026\n Interesting... there is a GNU extension and a intel compiler support to\n this function already:\n\n - GNU isatty \n - Intel isatty\n \n Unfortunately is not a standard, but it would fix this issue.\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 <#193 (comment)>,\n or unsubscribe\n \n ."
+ },
+ {
+ "user": "14NGiestas",
+ "date": "2022-05-05 16:29:19+00:00",
+ "text": "This issue was addressed in stdlib_logger a while ago (and already got several bugfixes, can't find the exact PRs) and I think this one can be closed too."
+ },
+ {
+ "user": "14NGiestas",
+ "date": "2022-05-05 17:19:43+00:00",
+ "text": "I'm closing this old issue since stdlib has stdlib_logger since v0.1.0."
}
]
},
@@ -23320,7 +23722,7 @@
"date": "2020-02-01 00:16:36+00:00",
"title": "Pseudorandom number generator",
"text": "EDIT: An updated proposal is available below.\nThere are a few suggestions to have pseudorandom number generators (PRNGs) in the library, e.g., #1 (comment) and #104 (comment). Focusing on the uniform floating-point PRNG [0.0, 1.0), we have already had the intrinsic subroutine, random_number. The first question is whether we should have custom PRNGs of the uniform distribution. Or, we should concentrate on derived PRNGs like non-uniform distributions or integer PRNGs. I think it is still worth developing custom PRNGs because of better flexibility and performance.\nWith the custom PRNGs, we have many more questions.\n\nShould we have various generators (e.g., integer numbers) in addition to a floating-point PRNG [0.0, 1.0)?\nShould it support different algorithms of PRNG, or can we provide a single algorithm?\n\nIf true: Should it optionally call the intrinsic subroutine?\nIf true: Should the seed (state) be global, private, or both?\n\nIf global, Should it be thread-safe?\n\n\n\n\n\nThe decision defines a design of API. A possible API is the same as the intrinsic subroutines. The subroutine name in the below example is just a placeholder.\n! just arbitrary precision here\ntype(random_number_generator) :: rng\nreal(dp) :: harvest\ninteger :: seed(2)\n\n! for local state as derived type\nseed = [1,2]\ncall pseudorandom_seed(rng,put=seed)\ncall pseudorandom_number(rng,harvest)\n\n! for global state as saved seed\ncall pseudorandom_seed(put=seed)\ncall pseudorandom_number(harvest)\nPlease tell me what you think about it.\n\nR: https://www.rdocumentation.org/packages/base/versions/3.6.2/topics/Random\nPython: https://docs.python.org/3/library/random.html\nNumPy: https://docs.scipy.org/doc/numpy-1.15.0/reference/routines.random.html\nMatlab: https://www.mathworks.com/help/matlab/random-number-generation.html\nOctave: https://octave.org/doc/v4.0.3/Special-Utility-Matrices.html#Special-Utility-Matrices\nJulia: https://docs.julialang.org/en/v1/stdlib/Random/\nC++: https://en.cppreference.com/w/cpp/numeric/random\nRust: https://rust-num.github.io/num/rand/index.html#thread-local-rng\nGo: https://golang.org/pkg/math/rand/\nNAG: https://www.nag.co.uk/numeric/fl/nagdoc_fl24/html/g05/g05conts.html\nMKL: https://software.intel.com/en-us/mkl-developer-reference-fortran-random-number-generators\nIMSL: https://docs.roguewave.com/imsl/fortran/6.0/stat/default.htm?turl=rnun.htm\nGSL: https://www.gnu.org/software/gsl/doc/html/rng.html",
- "is_open": true,
+ "is_open": false,
"labels": [
"topic: algorithms"
],
@@ -23429,6 +23831,11 @@
"user": "Beliavsky",
"date": "2021-11-04 23:46:56+00:00",
"text": "TensorFlow has both impure and \"stateless\" RNG, for example tf.random.stateless_uniform"
+ },
+ {
+ "user": "14NGiestas",
+ "date": "2022-05-06 03:26:57+00:00",
+ "text": "I'm closing this issue since Probability Distribution and Statistical Functions -- PRNG Module #271 was merged in 6 Feb 2021 so it's likely to be resolved (it isn't tagged in any release version nor mentioned but it was probably in 0.2.0)."
}
]
},
@@ -25381,6 +25788,26 @@
"user": "Carltoffel",
"date": "2022-04-27 07:57:48+00:00",
"text": "I will try to collect some more errors, update my comment and then report them."
+ },
+ {
+ "user": "Carltoffel",
+ "date": "2022-05-05 12:54:34+00:00",
+ "text": "I've posted my problems in the nvidia forum:\nhttps://forums.developer.nvidia.com/t/building-fortran-standard-library-stdlib-fails/213461\nIt's currently hidden, because I used two links in one post, which has triggered the spam filter. \ud83d\ude44"
+ },
+ {
+ "user": "mcolg",
+ "date": "2022-05-05 17:59:47+00:00",
+ "text": "FYI, I'm looking into these issue now and have mails out to engineering about items #1 and #3. I'll post an update on our forums once I can give complete answers.\nFor #1, the initial issue does look more to be a parse error with the variable name beginning with \"module_\" but I don't think it's still quite right even if the variable name is changed. It only works when using literal strings or if the variable name's has the same or more number of characters as the string that's being printed. Again, waiting on feedback from engineering.\nFor #2, I reported the issue (TPR #31784)\nFor #3, Still looking into it.\nFor #4, these are known. I'll push on engineering to see if we can get them added.\nTo respond to scivision's earlier comment, yes, much of our effort is focused on F18 development and our current plan is to move nvfortran to use the F18 code base. No idea on when that will be, but hopefully sometime in the next few years if all goes well.\nFor the missing F2008/F2018 features in nvfortran/\"classic\" flang, we'll still add them depending on the feature, difficulty to implement, and if there's enough demand. We're just not proactively adding them. Reporting on our forums which features you're looking for helps with gauging demand. Big items, like co-arrays, will need to wait for F18."
+ },
+ {
+ "user": "milancurcic",
+ "date": "2022-05-05 18:20:26+00:00",
+ "text": "For #3, Still looking into it.\n\nThanks @mcolg! I recently hit 3. with nvfortran trying to build neural-fortran and found this thread:\nhttps://forums.developer.nvidia.com/t/nvfortran-f-0000-internal-compiler-error-interf-new-symbol-symbol-not-found/185901\nIt looks like you filed it as TPR #30461 (thank you!)"
+ },
+ {
+ "user": "mcolg",
+ "date": "2022-05-05 19:09:18+00:00",
+ "text": "It looks like TPR #30461 should be fixed in our upcoming 22.5 release. I just tested it, and it no longer fails.\n% nvfortran test.F90 -c -V22.3\nNVFORTRAN-F-0000-Internal compiler error. interf:new_symbol, symbol not found 625 (test.F90: 87)\nNVFORTRAN/x86-64 Linux 22.3-0: compilation aborted\n% nvfortran test.F90 -c -V22.5\n%\n\nMy usual caveat is that I'm testing with a pre-released version still under going testing. While unlikely, there have been cases when a fix causes other issues so is pulled at the last minute. Hence, I can't guarantee the fix will be in final 22.5, it's just likely to be.\nHopefully, this fixes your item as well."
}
]
},
@@ -25454,6 +25881,11 @@
"user": "Beliavsky",
"date": "2021-10-19 19:35:14+00:00",
"text": "type :: datetime\n integer :: year = 1\n integer :: month = 1\n integer :: day = 1\n integer :: hour = 0\n integer :: minute = 0\n integer :: second = 0\n integer :: millisecond = 0\nend type datetime\n\nOften I want to work with just dates. Should a date type with just year, month, day components also be part of stdlib?"
+ },
+ {
+ "user": "ivan-pi",
+ "date": "2022-05-23 10:35:49+00:00",
+ "text": "The QSAS Time Format Conversion Library which is part of PLPlot Enhancement Libraries uses a combination of an integer and a double to represent times with an accuracy of 0.01 ns."
}
]
},
@@ -25559,11 +25991,17 @@
"date": "2020-01-08 20:00:21+00:00",
"title": "Implement special functions",
"text": "There are lots of implementations online.\nAs an example, here are the special functions that I needed in my projects over the past 10 years:\nhttps://github.com/certik/fortran-utils/blob/b43bd24cd421509a5bc6d3b9c3eeae8ce856ed88/src/special.f90\nhttps://github.com/certik/hfsolver/blob/b4c50c1979fb7e468b1852b144ba756f5a51788d/src/special_functions.f90\nBeing able to standardize on the API for all or most of them would be a huge deal. Other languages:\nSciPy\nhttps://docs.scipy.org/doc/scipy/reference/special.html\nMatlab\nhttps://www.mathworks.com/help/matlab/special-functions-1.html\nJulia\nSeparate package: SpecialFunctions.jl",
- "is_open": true,
+ "is_open": false,
"labels": [
"topic: mathematics"
],
- "comments": []
+ "comments": [
+ {
+ "user": "14NGiestas",
+ "date": "2022-05-06 03:35:51+00:00",
+ "text": "Closing it in favor of #305"
+ }
+ ]
},
{
"number": 101,
@@ -28104,6 +28542,11 @@
"user": "KoldMen",
"date": "2022-04-24 03:38:22+00:00",
"text": "I have been programming in Fortran since 1981. So I guess I know a thing or two about Fortran. I do a lot of high performance computing. I use Fortran for computations and write my GUI in VB, C#, Java, and had used Pascal and QBasic in their hey days for the front end.\nI use a lot of graphs and data structures in these languages. Lists are the more commonly used than arrays. One can keep adding to a list without predefining its length. This is important for system programmers. I have never missed lists in my computational engines, except when trying to use stacks. I have my own implementation of a stack where I create a new array and copy the old one when the stack size increases beyond the allocated size. I know all about inefficiency. But then try replacing a stack with an array in any algorithm.\nShould Fortran have lists, the answer is YES. Should it be super efficient ? The answer is NO.\nAllow the end users like me make the choice. Not all programmers would be writing weather forecasting routines. Those who write will never use a list.\nList is a basic feature of modern languages. If you don't want to implement, then you are essentially limiting Fortran to a special use, namely Computations. I am okay with this. But then don't cry that the new generation is not using Fortran.\nAdd modern features like lists or die.\nThe whole arguments above seem to miss the point that we stopped teaching Fortran formally in my University and elsewhere more than 20 years ago. We teach Python to freshmen, and they love it. An avid programmer friend from NIST advised me to shift to Python since Python has so many libraries. And here you are, arguing about implementing a simple list. So funny.\nAnyway, thanks for trying to build the stdlib, even if it is 30 years too late."
+ },
+ {
+ "user": "certik",
+ "date": "2022-05-05 01:25:19+00:00",
+ "text": "@KoldMen I agree with your post. One nuance is that above we are arguing about the API of a list data structure in stdlib built using Fortran. Notice that in Python the list is part of the language itself, it is not implemented in Python. In LFortran we have actually recently added List as a first class feature into the intermediate representation, and it will get very efficient implementation in the backends. We have not exposed it in the frontend (syntax) yet, but one option is to simply recognize a list from stdlib, and transform it into the List node in the intermediate representation (instead of using the Fortran implementation from stdlib), and thus it would get excellent performance with LFortran. Other compiles could either do the same, or they could just use the actual implementation from stdlib (slower, but it would work).\nWe also have dictionaries, tuples and sets in LFortran. So once stdlib has an implementation of those, we can hook them in in the frontend."
}
]
},
@@ -29834,6 +30277,7 @@
"is_open": true,
"labels": [
"good first issue",
+ "in progress",
"topic: utilities",
"easy"
],
@@ -33551,9 +33995,10 @@
}
],
"issue_labels": {
- "documentation": "Improvements or additions to documentation",
- "build: make": "Issue with stdlib's manual makefile build",
"bug": "Something isn't working",
+ "meta": "Related to this repository",
+ "build: make": "Issue with stdlib's manual makefile build",
+ "documentation": "Improvements or additions to documentation",
"reviewers needed": "This patch requires extra eyes",
"topic: IO": "Common input/output related features",
"build: cmake": "Issue with stdlib's CMake build files",
@@ -33562,14 +34007,14 @@
"idea": "Proposition of an idea and opening an issue to discuss it",
"build: fpm": "Issue with stdlib's automatic exported fpm build",
"platform: Windows": "Build issues specific to the Windows platform",
- "meta": "Related to this repository",
"topic: strings": "String processing",
+ "easy": "Difficulty level is easy and good for starting into this project",
"topic: container": "(Abstract) data structures and containers",
"topic: utilities": "containers, strings, files, OS/environment integration, unit testing, assertions, logging, ...",
"API": "Discussion on a specific API for a proposal (exploratory)",
"topic: mathematics": "linear algebra, sparse matrices, special functions, FFT, random numbers, statistics, ...",
"good first issue": "Good for newcomers",
- "easy": "Difficulty level is easy and good for starting into this project",
+ "wontfix": "This will not be worked on",
"topic: algorithms": "searching and sorting, merging, ...",
"enhancement": "New feature or request",
"refactoring": "Internal change for better maintainablility",
@@ -33579,10 +34024,10 @@
"topic: statistics": "Statistical functions",
"automation": "Related to the workflows and automatic tests running here",
"waiting for OP": "This patch requires action from the OP",
+ "in progress": "This proposal is being worked on",
"implementation": "Implementation in experimental and submission of a PR",
"specification": "Discussion and iteration over the API",
"topic: datetime": "Specific for date and time data",
- "wontfix": "This will not be worked on",
"compiler: ifort": "Specific to Intel Fortran compilers",
"topic: interface": "Interfacing with other libraries or languages",
"topic: plotting": "Creating plots and representations of data",
@@ -33592,7 +34037,6 @@
"platform: Linux (32 bit)": "Specific to Linux 32 bit",
"compiler: nagfor": "Specific to NAG Fortran compiler",
"compiler: nvfortran": "Specific to NVHPC compilers",
- "compiler: flang": "Specific to classic flang compiler",
- "in progress": "This proposal is being worked on"
+ "compiler: flang": "Specific to classic flang compiler"
}
}
\ No newline at end of file
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 4407cfbb0..98086a7a3 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,249 @@
{
"name": "j3-fortran/fortran_proposals",
"issues": [
+ {
+ "number": 263,
+ "user": "8bitmachine",
+ "date": "2022-05-22 15:19:07+00:00",
+ "title": "Upper/Lower case variable names",
+ "text": "Currently Fortran ignores case for variable names. Originally using capitals, editors currently use, almost exclusively, lower case as typed and which many seem to prefer.\nHowever, I would propose to allow upper and lower case to be used distinctly. This would require a new directive element such as\nCASE SENSITIVE\nwhich if absent allows the compiler to continue to ignore case.\nas I would find it convenient to be able to use both in variable names.\nIt will mean having to pay attention when used, such as m and M, when for example nested loops or indirect references may need several integers such as i,j,k,m,n; while real variables could use M,N etc.\nThis should not preclude the use of engineering notation like k or K (which would also be useful) if these are attached to real numbers as that should be implicit in the context.",
+ "is_open": true,
+ "labels": [],
+ "comments": [
+ {
+ "user": "wyphan",
+ "date": "2022-05-22 15:25:38+00:00",
+ "text": "This is gonna be interesting if implemented. IMHO it's definitely gonna break backwards compatibility. Unless you have a really strong reason why Fortran should treat VAR, var, Var, or vAr (pun intended) differently, other than making it behave more like C/C++, Python, and all the other programming languages that are case-sensitive.\nAlso, I would suggest something other than CASE for the keyword since that's already in use for SELECT CASE and will trip not only lexers, but also syntax highlighting!"
+ },
+ {
+ "user": "certik",
+ "date": "2022-05-22 15:32:35+00:00",
+ "text": "@8bitmachine do you want to be using k and K for two different variables?\nIf you just want this feature to make the compiler enforce case sensitivity, that could already be implemented in compilers without changing the standard: the compiler could warn you if you use a variable name in a case insensitive manner."
+ },
+ {
+ "user": "8bitmachine",
+ "date": "2022-05-22 18:45:48+00:00",
+ "text": "@certik\nYes, that is the idea. I like minimal typing and often use M for a matrix (real) and want to then use m as an index if needed, for example, especially if references are indirect (as in mapping a physical grid to a matrix location).\nOr I may want k for an index and K for Boltzmann's constant. So yes, and it will make Fortran more C-like.\nReading data using engineering notation is not a problem if using ASCII as k and K are identifiable.\nWhile I'm at it, has anyone suggested making pi (=3.14159265358979323 etc) a standard variable?"
+ },
+ {
+ "user": "8bitmachine",
+ "date": "2022-05-23 10:09:38+00:00",
+ "text": "@certik - Another point is that if a compiler does the job without changing the standard then that means portability is at risk.\nI don't think this should be a compiler function. Unless Fortran demands compilers meet a standard critierion for this."
+ },
+ {
+ "user": "certik",
+ "date": "2022-05-23 11:46:41+00:00",
+ "text": "Above I suggested it could be a compiler function only to warn about inconsistent case. Since you want to allow making k and K to be two different variables, that would have to be a change in the standard."
+ }
+ ]
+ },
+ {
+ "number": 262,
+ "user": "ZedThree",
+ "date": "2022-05-13 14:14:13+00:00",
+ "title": "Scoped enums",
+ "text": "This paper recommends that the new typed enumerators have values scoped to the type, and not to the enclosing scope.\n\nThe authors strongly believe that the current proposal for typed\nenumerators, as described in J3/21-120 and subsequent revisions, be\namended so that enumerator names are class two names. That is,\nenumerator names must be local to each enumeration type and not in\nthe surrounding scope. Some suggestions for syntax are made.",
+ "is_open": true,
+ "labels": [],
+ "comments": [
+ {
+ "user": "certik",
+ "date": "2022-05-13 14:25:20+00:00",
+ "text": "@ZedThree thanks a lot for writing this up! I will read it carefully soon and provide feedback.\nLet's iterate on this. Everybody, go ahead and provide feedback as well please."
+ },
+ {
+ "user": "klausler",
+ "date": "2022-05-13 16:56:50+00:00",
+ "text": "I completely agree that the current 202X typed enumerators are ridiculous and should be deleted or replaced. Thank you for writing this up. There is zero chance that J3 will fix this, but maybe we implementers can agree on a better common solution.\nThree suggestions:\n(1) The syntax \"T%E\" is ambiguous at parsing time with a component reference. Consider another symbol, please. \"T:E\" would work. So would \"T_E\" if you want really easy implementation.\n(2) The class-1 scoping of the current 202X misfeature could be retained with a keyword, like \"ENUM, OPEN\" or something.\n(3) We have to also have optional value initializers for interoperability.\nIf an unambiguous syntax is used for literal constant enumerators, all of this would be trivial to implement in f18. A syntax that's ambiguous with component references could be made to work -- misparses one way or the other would have to be detected and repaired once the symbol table is in hand, as I have to do for statement function definitions vs array element assignments, function calls vs array references, array slices vs substrings, &c. &c. -- but would be a harder sell to me if anybody wanted a demonstrable prototype in short order."
+ },
+ {
+ "user": "ZedThree",
+ "date": "2022-05-13 17:13:53+00:00",
+ "text": "@klausler Thanks for your comments, it's good to hear from an implementer!\n(1) The appeal of % is that (to me at least) it feels quite intuitive what it means, but if it's impediment to implementation, that's certainly a strike against it. : feels quite overloaded already, maybe ::? Or even the ugly %%? Early revisions suggested enum_name(value_name) as a way to resolve conflicts. Could that be made to work?\nDo you think if this had a straw poll for syntax, it would help?\n(2) Indeed, or perhaps import which is already used for similar purposes in interfaces. I'm not proposing that feature here though, as I thought this might stand a better chance by keeping the scope (ha) limited.\n(3) I'm not sure what you mean -- could you elaborate?"
+ },
+ {
+ "user": "certik",
+ "date": "2022-05-13 17:36:43+00:00",
+ "text": "(1) The syntax of accessing the enumerators T%E should be designed to be consistent with the potential namespaces for modules proposal (#1), which have a similar issue: some_module%some_function(). As well as if Fortran was to get namespaces (#87), they should use a consistent syntax. As an example, C++ uses . for \"derived types\", but :: for namespaces and enumerations (in C++ it seems the enumerators are both global as well as accessible locally using :: for enum, but only locally for enum class). So if we go with T:E, then also some_module:some_function() should work. What about T::E, some_module::some_function()?"
+ },
+ {
+ "user": "plevold",
+ "date": "2022-05-14 17:20:57+00:00",
+ "text": "I think T::E makes the most sense both for namespaces and for enums (and nopass procedures for that matter). This is common in multiple similar programming languages. Insisting on that Fortran syntax should be \"unique\" only makes it confusing for newcomers. As a comparison, Rust is considered to be \"the C++ replacement\" and has adopted much of its syntax like :: for namspaces and <> for generics.\n@ZedThree It might be worth pointing out in the paper that with the current Fortran standard it's trivial to implement a strongly typed and properly namespaced enum. I've often done it in my code like the example below. It should be easy to reduce the amount of boilerplate code with e.g. fypp or maybe even compiler preprocessors as well. This begs the question if an arguably worse implementation is even needed in the standard.\nmodule animal_mod\n implicit none\n\n private\n public animal_t, animals\n\n type :: animal_t\n private\n integer :: id\n contains\n generic :: operator(==) => equals\n generic :: operator(/=) => not_equals\n\n procedure, private :: equals, not_equals\n end type\n\n type :: animals_t\n type(animal_t) :: dog = animal_t(1)\n type(animal_t) :: cat = animal_t(2)\n type(animal_t) :: bird = animal_t(3)\n type(animal_t) :: fox = animal_t(4)\n end type\n\n type(animals_t), parameter :: animals = animals_t()\n\ncontains\n\n logical elemental function equals(a,b)\n class(animal_t), intent(in) :: a\n type(animal_t), intent(in) :: b\n equals = a%id == b%id\n end function equals\n\n\n logical elemental function not_equals(a,b)\n class(animal_t), intent(in) :: a\n type(animal_t), intent(in) :: b\n not_equals = .not. a == b\n end function not_equals\n\nend module\n\nprogram main\n use animal_mod, only: animal_t, animals\n implicit none\n\n write(*,*) what_says(animals%dog)\n write(*,*) what_says(animals%cat)\n write(*,*) what_says(animals%bird)\n write(*,*) what_says(animals%fox)\n\ncontains\n\n pure function what_says(animal) result(sound)\n type(animal_t), intent(in) :: animal\n character(len=:), allocatable :: sound\n\n if (animal == animals%dog) then\n sound = 'woof'\n else if (animal == animals%cat) then\n sound = 'meow'\n else if (animal == animals%bird) then\n sound = 'tweet'\n else\n sound = '???'\n end if\n end function\n\nend program\nProgram output:\n woof\n meow\n tweet\n ???"
+ },
+ {
+ "user": "FortranFan",
+ "date": "2022-05-14 23:24:33+00:00",
+ "text": "it's trivial to implement a strongly typed and properly namespaced enum. I've often done it in my code like the example below. It should be easy to reduce the amount of boilerplate code with e.g. fypp or maybe even compiler preprocessors as well. This begs the question if an arguably worse implementation is even needed in the standard.\n\nAn important need with proper enums is use with SELECT CASE constructs that no \"roll your own\" types permit."
+ },
+ {
+ "user": "FortranFan",
+ "date": "2022-05-14 23:42:06+00:00",
+ "text": "Let's iterate on this. Everybody, go ahead and provide feedback as well please.\n\nHonestly, @certik , at this stage the \"ball\" is in WG5's side of the \"court\". The current design was passed by J3 with no objections by any of the voting members. You can now be completely certain J3's position will be \"There will be no further action on these suggestions at this time.\"\nThe only viable option is to submit a request with WG5 to withdraw the enumeration type feature from Fortran 202X. A good design can then be considered as a fresh slate toward Fortran 202Y."
+ },
+ {
+ "user": "FortranFan",
+ "date": "2022-05-14 23:57:05+00:00",
+ "text": "This paper recommends that the new typed enumerators have values scoped to the type, and not to the enclosing scope.\n..\n\n@ZedThree , there are few use cases which are supported by the 'enumeration type` as currently included in draft Fortran 202X.\nIn my opinion, to pick one missing use case that is of interest to the authors and proposing something to get that addressed is just not right. I can't give a big enough down vote on this, it is thumbing its nose at all the other use cases."
+ },
+ {
+ "user": "certik",
+ "date": "2022-05-15 01:57:06+00:00",
+ "text": "@FortranFan, can you formulate what you propose should be done? Do you like the enumerations as proposed in 2X more than this proposal?"
+ },
+ {
+ "user": "FortranFan",
+ "date": "2022-05-15 01:58:26+00:00",
+ "text": "@FortranFan, can you formulate what you propose should be done?\n\nSubmit a request with WG5 to withdraw the enumeration type feature from Fortran 202X."
+ },
+ {
+ "user": "klausler",
+ "date": "2022-05-15 23:41:52+00:00",
+ "text": "Is there any essential difference between this specific proposal -- putting enumerators into a scope and requiring some kind of syntax that names the scope and the enumerator wherever an enumerator appears -- and using distinct prefixes on the enumerators? It seems to me that we're just saving some typing here."
+ },
+ {
+ "user": "certik",
+ "date": "2022-05-16 03:01:09+00:00",
+ "text": "If you use distinct/unique prefixes (and are willing to accept this downside) then I think there is no difference."
+ },
+ {
+ "user": "ZedThree",
+ "date": "2022-05-16 08:16:23+00:00",
+ "text": "@FortranFan :\n\n@ZedThree , there are few use cases which are supported by the 'enumeration type` as currently included in draft Fortran 202X.\nIn my opinion, to pick one missing use case that is of interest to the authors and proposing something to get that addressed is just not right. I can't give a big enough down vote on this, it is thumbing its nose at all the other use cases.\n\nI disagree, the existing proposal supports most use cases even if it is missing several features that would support more use cases, the main two being the ability to specify the underlying type, and values for individual enumerators. Both of these could be added in F202Y without breaking code that uses the current spec, and could be vendor extensions until then. I certainly disagree that this is \"thumbing its nose at other use cases\" -- this proposal is about enhancing all use cases, and not about any particular use case.\nThe existing spec certainly has its flaws and the final form seems to have ignored a couple of decades of language research and innovation, but I don't think it is so flawed that it should be completely thrown out.\n@klausler :\n\nIs there any essential difference between this specific proposal -- putting enumerators into a scope and requiring some kind of syntax that names the scope and the enumerator wherever an enumerator appears -- and using distinct prefixes on the enumerators? It seems to me that we're just saving some typing here.\n\nIt's not just about saving typing, although that is part of it, it's about building in best coding practice. Rather than having to teach new developers \"you should always add a unique prefix to enum names, because sometimes it's important, and if you don't you might have to rename each individual enumerator when you use them\", we can just teach them how to use them and that's enough.\nMore concretely, here's an example:\n! Existing spec using renaming:\nuse colour_mod, only: colour_t, colour_red => red, colour_green => green, colour_blue => blue\nuse alert_mod, only: alert_t, alert_red => red, alert_amber => amber, alert_green => green\n! or with prefixes:\nuse colour_mod, only: colour_t, colour_red, colour_green, colour_blue\nuse alert_mod, only: alert_t, alert_red, alert_amber, alert_green\n\n! This proposal:\nuse colour_mod, only: colour_t\nuse alert_mod, only: alert_t"
+ },
+ {
+ "user": "plevold",
+ "date": "2022-05-16 13:49:55+00:00",
+ "text": "An important need with proper enums is use with SELECT CASE constructs that no \"roll your own\" types permit.\n\n@FortranFan that's true, but with the proposed select case statement my understanding is that you will only save a few keystrokes. Sure, the code\nif (animal == dog) then\n sound = 'woof'\nelse if (animal == cat) then\n sound = 'meow'\nelse if (animal == bird) then\n sound = 'tweet'\nelse\n sound = '???'\nend if\ncould be rewritten to\nselect case(animal)\ncase (dog)\n sound = 'woof'\ncase (cat)\n sound = 'meow'\ncase (bird)\n sound = 'tweet'\ncase default\n sound = '???'\nend select\nThat should give you 114 non-whitespace characters instead of 123 and maybe somewhat better readability. The behavior is exactly the same though.\nOn the other hand, if the Fortran compiler would require that the select case statement was exhaustive, either by including all enum variants or by having a case default statement then there would be an actual advantage of using select case over if-s.\n\nIs there any essential difference between this specific proposal -- putting enumerators into a scope and requiring some kind of syntax that names the scope and the enumerator wherever an enumerator appears -- and using distinct prefixes on the enumerators? It seems to me that we're just saving some typing here.\n\n@klausler in addition to the example by @ZedThree another advantage of using scope instead of a prefix is that (a future) Fortran standard could allow the scope to be omitted in case (...)-statements since the enum type is already known from the select case (var) line. For example,\nselect case(animal)\ncase (animal_t::dog)\n sound = 'woof'\ncase (animal_t::cat)\n sound = 'meow'\ncase (animal_t::bird)\n sound = 'tweet'\ncase default\n sound = '???'\nend select\ncould be simplified to\nselect case(animal)\ncase (dog)\n sound = 'woof'\ncase (cat)\n sound = 'meow'\ncase (bird)\n sound = 'tweet'\ncase default\n sound = '???'\nend select\nstill without the risk of naming collisions. This is for example allowed in Java switch-statements."
+ },
+ {
+ "user": "klausler",
+ "date": "2022-05-16 15:39:49+00:00",
+ "text": "If you're just saving typing, it's not worth the effort and drama. Add int values and I/O and you'd have something.\nSELECT CASE is O(1) or O(log2(N)). An IF cascade is O(N). More important, a SELECT CASE with no default can be checked at compilation time for missing values."
+ },
+ {
+ "user": "plevold",
+ "date": "2022-05-16 15:58:39+00:00",
+ "text": "@klausler good point about the performance differences. So with the current proposal one would have to choose between performance (with enumeration type) or maintainability (with a custom implementation). In my experience, maintainability trumps performance in large software projects unless the penalty is absolutely prohibiting.\n\nMore important, a SELECT CASE with no default can be checked at compilation time for missing values.\n\nAbsolutely agree. My understanding is that with the current 202X proposal compilers are not required to give an error on missing values, but maybe I've misread something?"
+ },
+ {
+ "user": "ZedThree",
+ "date": "2022-05-16 16:23:06+00:00",
+ "text": "As far as I can see it, these are the missing features that one would want from an enum in a modern language:\n\nproper scope\nexhaustive select case\ncustom values\ncustom underlying type\nproper I/O using the enumerator name (reflection)*\n\nOf these, I think the first two cannot be implemented in a future standard without breaking backwards-compatibility, while the other three can. Are there others? I'm ignoring proper sum/algebraic types here, because I think they would only be usable with proper generic typing support.\nSeveral people that have knowledge of how the committee works have said this proposal doesn't stand any chance of getting accepted. Is \"kill/delay typed enumerations\" more likely to get accepted instead?\n21-110 is the paper that stripped down the much nicer 19-216. Does anybody have any insight into what the committee thought was too complicated about 19-216?\n\n* Weirdly, the current spec has some degree of reflection with next()/previous() and enum_type(1)/huge(enum_type), not seen in many other languages"
+ },
+ {
+ "user": "klausler",
+ "date": "2022-05-16 16:29:06+00:00",
+ "text": "Of these, I think the first two cannot be implemented in a future standard without breaking backwards-compatibility, while the other three can. Are there others? I'm ignoring proper sum/algebraic types here, because I think they would only be usable with proper generic typing support.\n\nProper sum types as in ML/O'Caml/Haskell would want their constructors (including nullary ones) to be available in the declaration scope anyway.\n\nSeveral people that have knowledge of how the committee works have said this proposal doesn't stand any chance of getting accepted. Is \"kill/delay typed enumerations\" more likely to get accepted instead?\n\nNo. There's huge overlap between WG5 and J3. J3 asking WG5 for permission to defer the feature involves the same group of people taking off their J3 hats, donning their WG5 hats, and saying \"no\" to themselves."
+ },
+ {
+ "user": "ZedThree",
+ "date": "2022-05-16 16:36:32+00:00",
+ "text": "No. There's huge overlap between WG5 and J3. J3 asking WG5 for permission to defer the feature involves the same group of people taking off their J3 hats, donning their WG5 hats, and saying \"no\" to themselves\n\nI'm sorry, I am entirely ignorant of the structure here. There's no chance of changing J3's mind on this then either?"
+ },
+ {
+ "user": "certik",
+ "date": "2022-05-16 16:56:23+00:00",
+ "text": "@ZedThree there is always a chance. That's why I asked you to write this up. Even if they say no, we can require the committee to provide a response why the paper was not accepted. Furthermore, it provides guidance to compiler developers to implement as extensions.\nThere is committee politics and how it operates, but I urge all participants here to stay away from that, as it is not productive (or move it to a separate \"meta\" issue). In this issue, let's focus on having free discussion about what makes sense to do for enumerations.\nPeter K. has good points about it being \"not worth doing\", as it is \"just syntax\". But, isn't most of Fortran \"just nice syntax'? It absolutely is, and that is why I like it. And I think having modern enumerations in the language should be the goal, and we should not be discouraged. Peter H.'s arguments thus resonate with me. Finally, I think @FortranFan's main argument is that this proposal doesn't go far enough, and thus is not worth it, but I think it's a step in the right direction and most importantly: it allows to add the other things in backwards compatible manner. If this proposal is not accepted, and the current F2023 enumerations go in, then I think we can't change the scope without breaking backwards compatibility."
+ },
+ {
+ "user": "klausler",
+ "date": "2022-05-16 16:58:50+00:00",
+ "text": "No. There's huge overlap between WG5 and J3. J3 asking WG5 for permission to defer the feature involves the same group of people taking off their J3 hats, donning their WG5 hats, and saying \"no\" to themselves\n\nI'm sorry, I am entirely ignorant of the structure here. There's no chance of changing J3's mind on this then either?\n\nWG5 is the ISO (international) standard committee for Fortran. J3 is the old name for the American standard committee for Fortran. WG5 comes up with lists of work items for each new standard, and asks J3 to define them; J3 writes draft international standards, gives them to WG5, and they get approved as ISO standards. J3 also takes care of corrections and interpretation requests.\nOne problem with this arrangement is that it has no feedback loop that includes implementation experience or even broad review before WG5 hands ideas off to J3, and in the 3+ decades since the structure was established, there's a sad history of not-completely-thought-through changes being set permanently into the language. That's why we have PDTs still not being implemented widely enough to be portable after 20 years; a DO CONCURRENT construct that is serial; and soon, rank-agnostic array indexing. And we don't have simple things like pointers to immutable data. It is a mess."
+ },
+ {
+ "user": "plevold",
+ "date": "2022-05-16 17:49:29+00:00",
+ "text": "I'm ignoring proper sum/algebraic types here, because I think they would only be usable with proper generic typing support.\n\nI think proper sum types has a lot use cases without proper generic types (and even more with it). How JSON values are parsed in Rust is a good practical example: When reading data at a given path, e.g. root[\"foo\"][\"bar\"] you get back a Value enum:\npub enum Value {\n Null,\n Bool(bool),\n Number(Number),\n String(String),\n Array(Vec),\n Object(Map),\n}\nWhile the data of the Array and Object variants use generics this enum doesn't. If Fortran enumration types had support for different types it would be possible to implement this kind of interface in Fortran as well without any additional language features.\nFor reference, the alternative \"object oriented\" approach (one that is possible to implement in Fortran today) would be to use an abstract base class:\ntype, abstract :: json_value_t\nend type\n\ntype, extends(json_value_t) :: json_bool_t\n logical :: value\nend type\n\ntype, extends(json_value_t) :: json_number_t\n real(dp) :: value\nend type\nAnd so on. This approach is (of course) very verbose and does not provide much type safety: While you could select type on a class(json_value_t) variable there's no way of knowing that you've covered all possible variations since inheritance is not an finite set . Even a type outside this hypothetical JSON parsing library could extend json_value_t."
+ }
+ ]
+ },
+ {
+ "number": 261,
+ "user": "thomas-robinson",
+ "date": "2022-05-13 12:30:43+00:00",
+ "title": "BIND (python)",
+ "text": "Binding routines in C is great. I would like to see more languages that could use the BIND specifier.\nfunction pyfunction (args) result (res) BIND(python, name=\"pyfunction\")\nWith an increasing number of machine learning algorithms being written in python, utilizing python is going to be important to HPC applications that are written in Fortran in the future.",
+ "is_open": true,
+ "labels": [],
+ "comments": [
+ {
+ "user": "wyphan",
+ "date": "2022-05-13 13:20:00+00:00",
+ "text": "This is a brilliant idea, since it removes an intermediary C layer (Cython\nor Numba) and lets Python interface directly to Fortran.\n\nIMHO Fortran has to be the secret sauce to NumPy being fast even though\nPython is an interpreted language, because AFAIK NumPy leverages either MKL\nor OpenBLAS to do the heavy lifting.\n\nSummoning @pearu (Quansight) here.\n\u2026\nOn Fri, May 13, 2022, 08:31 Tom Robinson ***@***.***> wrote:\n Binding routines in C is great. I would like to see more languages that\n could use the BIND specifier.\n\n function pyfunction (args) result (res) BIND(python, name=\"pyfunction\")\n\n With an increasing number of machine learning algorithms being written in\n python, utilizing python is going to be important to HPC applications that\n are written in Fortran in the future.\n\n \u2014\n Reply to this email directly, view it on GitHub\n <#261>, or\n unsubscribe\n \n .\n You are receiving this because you are subscribed to this thread.Message\n ID: ***@***.***>"
+ },
+ {
+ "user": "certik",
+ "date": "2022-05-13 22:21:19+00:00",
+ "text": "Great idea. Note that there are two directions:\n\nCalling Python from Fortran: https://gitlab.com/lfortran/lfortran/-/issues/44\nCalling Fortran from Python: https://gitlab.com/lfortran/lfortran/-/issues/133\n\nSee the above two issues for examples of syntax. For calling Python from Fortran (the first issue), I had in mind some syntax of the kind:\nuse, external(python) :: numpy, only: sin\nprint *, sin(5)\nBut using your proposal, it could also be just:\ninterface\n function sin(x) result(r) bind(python, name=\"numpy.sin\")\n real, intent(in) :: x\n real :: r\n end function\nend interface\nprint *, sin(5.0)\nAnd one would declare it by hand to work for arrays (of all dimensions) as well. One can then create numpy.f90 Fortran module which would have all these declarations (and possibly making the function sin generic over all scalars and arrays), so that it is easy to use."
+ },
+ {
+ "user": "h-vetinari",
+ "date": "2022-05-15 17:21:49+00:00",
+ "text": "This is a brilliant idea, since it removes an intermediary C layer (Cython or Numba) and lets Python interface directly to Fortran. IMHO Fortran has to be the secret sauce to NumPy being fast even though Python is an interpreted language, because AFAIK NumPy leverages either MKL or OpenBLAS to do the heavy lifting.\n\nIndeed both numpy and scipy rely on BLAS/LAPACK; both tend to use openblas by default, but are fully functional with MKL (in fact, it's the default in conda-forge on windows) as well as the netlib/blis flavours. The use of BLAS/LAPACK is indeed a key pillar of the performance and will not change.\nAdditionally, scipy has a non-trivial amount of native fortran code (and a lot of historical packaging/distribution complications stem from that; see also the entire f2py effort), though nowadays the native fortran tends to get slowly replaced by C/C++ code (often through cython/pythran transpilation) not least due to a shortage of reviewer's expertise (resp. availability of the few that do know).\n\nSummoning @pearu (Quansight) here.\n\nSince Pearu can be hard to reach, adding some more numpy/scipy maintainers for visibility: @rgommers @seberg @tylerjereddy"
+ },
+ {
+ "user": "ivan-pi",
+ "date": "2022-05-15 21:53:33+00:00",
+ "text": "I'm interested how this would work from the perspective of the Fortran processor (jargon for Fortran compiler). From the perspective of Fortran calling Python would a Fortran processor embed Python (either CPython, PyPy, or perhaps HPy)? This would mean inserting calls to Py_Initialize() and Py_FinalizeEx() and handling all the data-conversion using functions from Python's C API when needed. Or would it use a static Python compiler such as Cython, Nuitka, LPython, and others?\nWould interoperability be limited to numeric scalars, and strings, NumPy arrays covering compatible NumPy data types or more ambitiously, would it also cover Python sequence types including lists and tuples, and mapping types such as dictionaries, etc.?\nCould decorators be used on the Python side to expose functions and classes for use in Fortran (i.e. generate the Fortran module, interfaces, and wrapper code automatically)? What about Python type annotations; could these be used for static typing?\nFor Python calling Fortran on the other hand, bind(Python) would effectively be like a \"standardized\" form of the F2PY tool and language extensions?\nIt might also be wise to follow the development of the Python array API standard, and see how it can work with Fortran interoperability."
+ },
+ {
+ "user": "certik",
+ "date": "2022-05-15 22:51:39+00:00",
+ "text": "@ivan-pi excellent questions. For LFortran I want to pursue what I always wanted as a user, that is, \"all the way\". So all Fortran features would be wrapped, and all (or almost all) Python features would be usable. And yes, all the things you mentioned have to be resolved, and there is more than one way to resolve them.\nBut for a standard, I would start at the lowest denominator, that is, just annotating Fortran functions (to be called from Python) and Fortran interfaces (for Python functions to be called from Fortran). The standard would not specify how the compiler should actually implement it, it would only standardize the syntax and how it should behave in Fortran from the user's perspective. However, even this minimal approach has challenges: what features to allow, so initially integers/floats and arrays. But if arrays, are we going to interoperate with NumPy only, or other packages too? Etc.\nA feature like this should require a prior compiler implementation and experience to make sure we like all the details before standardizing."
+ },
+ {
+ "user": "HaoZeke",
+ "date": "2022-05-16 11:37:34+00:00",
+ "text": "Thanks for bringing this up! @pearu and I had a short chat about this. I'm going to summarize some of the discussion (any mistakes / omissions are mine).\nFrom a technical / standards perspective I'm not sure this proposal would hold a lot of water.\n\nFor an interpreted language, calling a compiled language will always have to be embedding not inter-op.\n\nAt best what can be done is that a compiled Fortran code can be linked to Python (or imported as a shared library)\n\n\nSimilar considerations exist from the other side, even if the standard requires (for example) that Fortran supports an intrinsic for starting up a co-processor (Python) the problem would be defining what would happen for say, co-arrays\nThe data structures themselves are implementation specific in Python and have no high level inter-op with Fortran (e.g. dictionaries)\n\nThis is assuming that some other structures like arrays are considered to be handled by the buffer protocol\n\n\nThe language standard would require many changes for the Python interpreters as well (e.g. what about the GC?)\n\nAs far as the Fortran language is concerned, Python is essentially a high level C library currently, and given the differences in language design (interpreted / compiled) this seems to be the only feasible way forward.\nA better candidate might be bind(cpp) which would also allow the language to grow very rapidly.\nI personally do not believe it is healthy for the language standard to special case interacting with a sub-project like Cython or the other statically compiled variants of Python, since they implement a subset of Python; though in theory one might propose bind(cython) as an approach.\nSimilarly, typing in Python is 100% optional, so for the same reason it would be difficult to describe a language binding which requires it.\nNote that none of these concerns are valid for user-binding generation codes (f2py, f90wrap, fmodpy, lfortran etc.), which have the happy circumstance of being able to define their own scope to be more narrow than the language specification.\nAlso, as @certik pointed out, we should have working implementations and experience. By that measure, this might be a bit premature. There are many approaches gaining traction jointly and converging towards a consolidated image of what Python looks like when interoperated with Fortran. Some are:\n\nThe bind(c) variants (e.g. fmodpy, f90wrap)\n\nf2py also has a developmental interest in special casing for bind(c)\n\n\nThe wrappers generated in Fortran approach (and pointers for users) (e.g. f2py)\nThe cython binding generation of LFortran\nThe LPython approach to compiling Python down to a common subset (shared with Fortran)\n\nThese are just some off the top of my head, and apologies to any projects I missed. Once these user-land approaches have stabilized (and efforts are ongoing to keep communication open so there's no fragmentation of the ecosystem), then and only then would it make sense to have the standards committee consider such a proposal.\nApart from ease of user-experience, at this moment I do not think there are any intrinsic functions or compatibility requests / helpers (e.g. those found in iso_c_binding) which would be required (and are not covered by existing stipulations).\n(not including features requested for other purposes which would help this, like generics support)"
+ },
+ {
+ "user": "certik",
+ "date": "2022-05-16 11:48:27+00:00",
+ "text": "I agree with @HaoZeke. In addition however I will also say that as a user, I think I would want this. Even more, as a user, I just want to use any Python library and I don't even want to write the wrappers and everything should just work. And from Python I just want to import any Fortran library and everything should just work."
+ },
+ {
+ "user": "jeffhammond",
+ "date": "2022-05-20 11:08:18+00:00",
+ "text": "The reason Fortran can interoperate with C is that C is unique in having a well-defined ABI. Python doesn't even require types, so it can't begin to have an ABI, so the task proposed here is impossible. The only reasonable way to interoperate Python and Fortran is to use the C interoperability capability of both."
+ },
+ {
+ "user": "ivan-pi",
+ "date": "2022-05-20 13:25:12+00:00",
+ "text": "Python (or specifically CPython) does have a stable C ABI: https://docs.python.org/3/c-api/stable.html#stable-application-binary-interface\nOf course it's not an ISO standard like C and Fortran, but many of us do not care in practice."
+ },
+ {
+ "user": "klausler",
+ "date": "2022-05-20 14:41:37+00:00",
+ "text": "The reason Fortran can interoperate with C is that C is unique in having a well-defined ABI. Python doesn't even require types, so it can't begin to have an ABI, so the task proposed here is impossible. The only reasonable way to interoperate Python and Fortran is to use the C interoperability capability of both.\n\nI think that the point of having Python <-> Fortran interoperability is to automate and hide the use of the C ABI so that it's not a big deal to haul data between the languages or to invoke procedures, especially Python calling Fortran."
+ },
+ {
+ "user": "thomas-robinson",
+ "date": "2022-05-20 14:56:37+00:00",
+ "text": "If C is interoperable with python, and C is interoperable with Fortran, then there should be some way to eliminate the C middle man. As a user, it would provide a lot of convenience and allow for easy usage of python that is being used for accelerated computing."
+ },
+ {
+ "user": "jeffhammond",
+ "date": "2022-05-22 19:58:53+00:00",
+ "text": "I'd like to see a proper implementation of this in one of the major Fortran compilers and a report on the implementation difficulty before considering this."
+ },
+ {
+ "user": "FortranFan",
+ "date": "2022-05-22 23:14:34+00:00",
+ "text": "a proper implementation of this in one of the major Fortran compilers\n\nWhat is a \"major Fortran compiler\"? It's a rhetorical question! The very notion of it sounds rather discriminatory and unconvincing."
+ },
+ {
+ "user": "HaoZeke",
+ "date": "2022-05-22 23:31:33+00:00",
+ "text": "a proper implementation of this in one of the major Fortran compilers\n\nWhat is a \"major Fortran compiler\"? It's a rhetorical question! The very notion of it sounds rather discriminatory and unconvincing.\n\nPerhaps lets leave this as something to be revisited when there is a complete set of bindings of enough language features in any user-land library or compiler."
+ },
+ {
+ "user": "HaoZeke",
+ "date": "2022-05-22 23:33:20+00:00",
+ "text": "If C is interoperable with python, and C is interoperable with Fortran, then there should be some way to eliminate the C middle man. As a user, it would provide a lot of convenience and allow for easy usage of python that is being used for accelerated computing.\n\nThe problem is that this is not exactly true. Not all of Python is compatible with Fortran in a transparent way.\nAlso, C is not completely interoperable with Fortran, and the primary argument is still that from a language perspective, unless we would like to make statements about the GC and other interpreted features, binding Python-C should be left to user-code.\nCurrently some common features can be emulated / bound, and perhaps many more can be, but to say that there is immediately a way to embed an interpreted language with a compiled one because they have bindings to a common language might be premature."
+ }
+ ]
+ },
{
"number": 260,
"user": "klausler",
@@ -93,6 +336,26 @@
"user": "womenflyplanes",
"date": "2022-04-25 14:14:22+00:00",
"text": "Bye the way, how long has fortran had multidimensional arrays?\nLW\n\u2026\nOn Mon, 25 Apr 2022, Lenore Mullin wrote:\n Exactly!\n\n On Mon, Apr 25, 2022 at 8:40 AM Luther Woodrum ***@***.***> wrote:\n That's very funny.\n I was the one who first implemented mulidimensionaional arrays\n of more than two. All the ones before that were only for\n matrices, two dimensions.\n\n I implemented 7 dimensions.\n\n LW\n\n On Sun, 24 Apr 2022, Lenore Mullin wrote:\n\n > Ken never had indexing either. Luther was the first to\n introduce any kind of\n > indexing in APL.BTW, he also has mucho patents on his sorting\n algorithms.\n >\n > On Sun, Apr 24, 2022 at 1:37 PM Lenore Mullin\n ***@***.***>\n > wrote:\n >\u00a0 \u00a0 \u00a0 \u00a0That\u2019s because it was Luther\u2019s idea not Kens.\n > That\u2019s why it\u2019s not in kens book .\n >\n >\n > On Sun, Apr 24, 2022 at 1:21 PM Walter Spector\n > ***@***.***> wrote:\n >\n >\u00a0 \u00a0 \u00a0 \u00a0LOL!\u00a0 Yes, I learned a bit about APL back in college (on\n a\n >\u00a0 \u00a0 \u00a0 \u00a0DECsystem-10).\u00a0 My copy of the classic Sandra Pakin\n >\u00a0 \u00a0 \u00a0 \u00a0APL/360 manual from those days uses the terms \"grade up\"\n >\u00a0 \u00a0 \u00a0 \u00a0and \"grade down\" for the respective operators.\u00a0 So I\n >\u00a0 \u00a0 \u00a0 \u00a0thought it was fun that the HPF group used the same for\n >\u00a0 \u00a0 \u00a0 \u00a0their functions.\u00a0 It is also interesting that HPF 1 only\n >\u00a0 \u00a0 \u00a0 \u00a0had the grade functions.\u00a0 HPF 2.0 added the sort\n >\u00a0 \u00a0 \u00a0 \u00a0functions.\n >\u00a0 \u00a0 \u00a0 \u00a0\u00a0\n >\u00a0 \u00a0 \u00a0 \u00a0I also have a copy of Ken Iversons \"A Programming\n >\u00a0 \u00a0 \u00a0 \u00a0Language\".\u00a0 It has quite a lot of prose on ranking and\n >\u00a0 \u00a0 \u00a0 \u00a0sorting, but doesn't specifically use those terms.\n >\u00a0 \u00a0 \u00a0 \u00a0\u00a0\n >\u00a0 \u00a0 \u00a0 \u00a0Walter\n >\u00a0 \u00a0 \u00a0 \u00a0\u00a0\n >\u00a0 \u00a0 \u00a0 \u00a0-----Original Message-----\n >\u00a0 \u00a0 \u00a0 \u00a0From: j3-fortran/fortran_proposals\n >\u00a0 \u00a0 \u00a0 \u00a0Sent: Apr 24, 2022 10:00 AM\n >\u00a0 \u00a0 \u00a0 \u00a0To: j3-fortran/fortran_proposals\n >\u00a0 \u00a0 \u00a0 \u00a0Cc: Walter Spector , Author\n >\u00a0 \u00a0 \u00a0 \u00a0Subject: Re: [j3-fortran/fortran_proposals] Add simple\n >\u00a0 \u00a0 \u00a0 \u00a0sorting intrinsics (Issue #258)\n >\u00a0 \u00a0 \u00a0 \u00a0\u00a0\n >\u00a0 \u00a0 \u00a0 \u00a0\u00a0\n >\u00a0 \u00a0 \u00a0 \u00a0Mathematical definitions are in my dissertation. If\n you\u2019d\n >\u00a0 \u00a0 \u00a0 \u00a0like to speak to the original designer and implementor\n >\u00a0 \u00a0 \u00a0 \u00a0grade up and down in APL It is Luther Woodrum and he can\n >\u00a0 \u00a0 \u00a0 \u00a0be reached at\n >\u00a0 \u00a0 \u00a0 \u00a0***@***.*** ***@***.***)\n >\u00a0 \u00a0 \u00a0 \u00a0\u2014\n >\u00a0 \u00a0 \u00a0 \u00a0Reply to this email directly, view it onGitHub(#258 (comment)\n ent-11\n >\u00a0 \u00a0 \u00a0 \u00a007878967), orunsubscribe(https://github.com/notifications/unsubscribe-auth/ABCNQO35Q4BDQ\n OVONHV2BV3V\n >\u00a0 \u00a0 \u00a0 \u00a0GV44TANCNFSM5UGOXWPQ).\n >\u00a0 \u00a0 \u00a0 \u00a0You are receiving this because you authored the\n >\u00a0 \u00a0 \u00a0 \u00a0thread.Message ID:\n >\n >\u00a0 \u00a0 \u00a0 \u00a0\u00a0\n >\n >\u00a0 \u00a0 \u00a0 \u00a0\u2014\n >\u00a0 \u00a0 \u00a0 \u00a0Reply to this email directly, view it on GitHub, or\n >\u00a0 \u00a0 \u00a0 \u00a0unsubscribe.\n >\u00a0 \u00a0 \u00a0 \u00a0You are receiving this becauseyoucommented.[ABVSNFEJ7TVCTOPYCEAQSIDVGV7LFA5CNFSM5UGOXWP2YY3PNVWWK3TUL52HS\n 4DF\n >\u00a0 \u00a0 \u00a0 \u00a0VREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOIIEPFVA.gif]\n >\u00a0 \u00a0 \u00a0 \u00a0Message ID:\n >\u00a0 \u00a0 \u00a0\n ***@***.***>\n >\n > --\n > \"Great spirits have always encountered violent opposition from\n > mediocre minds\" - Albert Einstein\n >\n >\n >\n > --\n > \"Great spirits have always encountered violent opposition from\n mediocre\n > minds\" - Albert Einstein\n >\n >\n\n --\n \"Great spirits have always encountered violent opposition from mediocre\n minds\" - Albert Einstein"
+ },
+ {
+ "user": "certik",
+ "date": "2022-05-08 00:49:27+00:00",
+ "text": "This seems a duplicate of #101.\nUpdate: the #101 is not a duplicate, but a similar proposal. See the clarification below."
+ },
+ {
+ "user": "w6ws",
+ "date": "2022-05-08 04:17:21+00:00",
+ "text": "-----Original Message-----\nFrom: j3-fortran/fortran_proposals\nSent: May 7, 2022 5:49 PM\nTo: j3-fortran/fortran_proposals\nCc: Walter Spector , Author\nSubject: Re: [j3-fortran/fortran_proposals] Add simple sorting intrinsics (Issue #258)\n\u00a0\n\u00a0\nThis seems a duplicate of #101 (#101).\n\n\u00a0\nYes and no.\u00a0 The stdlib procedures ORD_SORT, SORT_INDEX, and SORT, implemented in #101 are a great start.\u00a0 But as mentioned, my proposal is a little different.\u00a0 In particular:\n\u00a0\n1.) Functional form.\u00a0 This would allow use in expressions rather than subroutine calls.\u00a0 It also avoids the need to allocate and make a copy of the input array in the case where the original unsorted input data needs to be maintained as is.\n\u00a0\n2.) Explicit GRADE functions - SORT_INDEX does an in-place sort of its input argument and also returns the index array.\u00a0 Again very often reordering the input array is not wanted.\u00a0 Just the indices for use in later permutations.\u00a0 (For example, obtaining the index array for keys in arrays of derived types.)\u00a0 And again functional form would allow use in expressions.\n\u00a0\n3.) Encoding the sort order in the entry point name.\u00a0 This eliminates run-time checking of required order.\u00a0 While it is a cheap test, in practice in my 40+ years of programming, one tends to know which direction is desired at compile time.\u00a0 Though in the case of GRADE functions, there should probably be an optional argument to maintain stability or not.\n\u00a0\nAdditionally thread #101 has some later messages about search procedures such as binary search.\u00a0 Over the\u00a0 years I've encountered numerous examples of Fortran applications with homegrown binary search procedures.\u00a0 However they are easy enough to write that I don't have strong feelings about including them or not.\u00a0 In any event, they sound be under a different proposal thread.\n\u00a0\nIf I should add these comments to #101 instead, then that would be fine.\n\u00a0\nWalter"
+ },
+ {
+ "user": "certik",
+ "date": "2022-05-08 04:26:29+00:00",
+ "text": "@w6ws, let's keep this issue here, separate from #101. I can see that they are similar, but distinct proposals, so let's keep both issues open. I wasn't sure if you were aware of the work at #101, but it's now clarified."
+ },
+ {
+ "user": "gklimowicz",
+ "date": "2022-05-09 21:03:59+00:00",
+ "text": "Bye the way, how long has fortran had multidimensional arrays? LW\n\nSince Fortran I in 1956, if you mean 1, 2, or 3-dimensional arrays. I believe that was the case for Fortan II and Fortran 66.\nFortran 77 upped the limit to 7 dimensions, which appears to be the limit in Fortran 90, 95, and 2003.\nFortran 2008 increased the limit to 15 dimensions, but as the sum of dimensions and co-dimensions of an array (or coarray)."
}
]
},
@@ -102,7 +365,7 @@
"date": "2022-04-21 01:49:36+00:00",
"title": "Allow more readable integer assignment in the namelist input",
"text": "I have been using namelist input files extensively in my codes. While they are very useful, one weak point is that integer assignment allows only this kind of \"raw\" notation\n...\npar%nsteps = 1000000\npar%nsteps2 = 100000\npar%nsteps3 = 10000000\n...\n\n(here, par is some parameter object). Very often, the number of steps like above is rather large, which is often not very readable. I tried using the usual notation like\n...\npar%nsteps = 10**6\npar%nsteps2 = 10**5\npar%nsteps3 = 10**7\n...\n\nbut it interferes with the special meaning of * in the namelist and results in a runtime error. So I wish some other syntax would be available, e.g.,\n...\npar%nsteps = 1_000_000\npar%nsteps2 = 100_000\npar%nsteps3 = 10_000_000\n...\n\nor\n...\npar%nsteps = 10^6\npar%nsteps2 = 10^5\npar%nsteps3 = 10^7\n...\n\nIf the symbols like * or ^ are not acceptable, some kind of \"math\" string (e.g. m\"...\") may be useful for internal conversion (from math strings to integer in this case).\n...\npar%nsteps = m\" 10**6 \"\npar%nsteps2 = m\" 10**5 \"\npar%nsteps3 = m\" 10**7 \"\n...\n\nApart from the specific syntax, I hope I can also write nsteps = 2 * 10^7 rather than nsteps = 20000000, because I need to count the number of zeros every time with mouse cursor.\n(Edit) Because the math evaluation like sqrt() seems like too far as a request, I deleted it from the original post. My intention is not a \"general\" expression evaluator, but just the above kind of large integers (at the moment).",
- "is_open": true,
+ "is_open": false,
"labels": [
"Clause 8"
],
@@ -437,6 +700,26 @@
"user": "klausler",
"date": "2022-03-07 17:16:13+00:00",
"text": "These new versions of the constraints would be easy to check, and I haven't been able to come up with a failure mode that they might enable. SGTM."
+ },
+ {
+ "user": "everythingfunctional",
+ "date": "2022-05-17 20:01:43+00:00",
+ "text": "I've come up with an example program that violates the current constraints, but does not violate my proposed new constraints.\nprogram\nimplicit none\n\ntype, abstract :: parent\nend type\n\ntype, extends(parent) :: child\n character(len=:), allocatable :: message\nend type\n\ntype :: wrapper\n class(parent), allocatable :: item\nend type\n\ntype(wrapper) :: coarray[*]\n\nif (this_image() == 1) then\n coarray%item = child(\"Hello, World!\")\nend if\nsync all\nif (this_image() /= 1) then\n coarray%item = coarray[1]%item\nend\nselect type (the_item => coarray%item)\ntype is (child)\n print *, the_item%message\nend select"
+ },
+ {
+ "user": "klausler",
+ "date": "2022-05-17 20:21:56+00:00",
+ "text": "I concur that this example violates the named constraints in a way that makes them seem surprising.\nHowever, there is a possible implementation motivation for those constraints that has occurred to me: a polymorphic component that is not deallocated/disassociated will need some means to identify its dynamic type, and that's typically implemented by means of a pointer to some kind of compiler-created type description record (which also holds the information necessary for I/O, overrideable TBP bindings, finalization, &c.). A type description record pointer from one image would have to be usable (or identical) to its analog on the local image in order to serve as the RHS of an allocating LHS (as above), to work with SELECT TYPE and SAME_TYPE_AS, and handle I/O. This is an implementation requirement that comes for free in some coarray implementation models -- MPI ranks all running the same executable, for example -- but might require pointer mapping or be simply impossible in some other coarray implementation models.\nSo I encourage you to bring the possible relaxation of these constraints up for discussion, but be advised, it may not be the no-brainer that we (or at least I) though it would be."
+ },
+ {
+ "user": "FortranFan",
+ "date": "2022-05-17 20:34:39+00:00",
+ "text": "@everythingfunctional wrote May 17, 2022 4:01 PM EDT:\n\nI've come up with an example program that violates the current constraints\n\nWhat do the current compiler implementations detect and report with this program?\nHere I mean besides the first line itself where program-name is missing, or line 19 with the typo where end if was intended, and so forth."
+ },
+ {
+ "user": "everythingfunctional",
+ "date": "2022-05-17 21:52:53+00:00",
+ "text": "coarray[1]%item violates C918. I'll fix the example and report the messages issued by the various compilers I have access to."
}
]
},
@@ -1518,7 +1801,7 @@
"date": "2021-07-30 22:54:00+00:00",
"title": "Eliminate implicit mapping",
"text": "Issue #90 proposes to eliminate implicit typing in Fortran. There is strong resistance to this, there being a major concern that to \"eliminate implicit typing\", if pursued with any seriousness, will require a deletion of the IMPLICIT statement from the language. There is great worry some existing code would break as a result.\nCan the Fortran community then coalesce to a somewhat simpler proposal, to eliminate implicit mapping instead?\nThe main aspect of such a proposal is to primarily change one sentence in the section on IMPLICIT statement to introduce the following:\n\"If a mapping is not specified for a letter, the default for a program unit or an interface body shall be NULL, and the default for a BLOCK construct, internal subprogram, or module subprogram is the mapping in the host scoping unit\"\nNote the current Fortran standard (document 18-007r1) instead states in section 8.7 IMPLICIT STATEMENT page 114, paragraph 3, lines 32-34, \"If a mapping is not specified for a letter, the default for a program unit or an interface body is default integer if the letter is I, J, ..., or N and default real otherwise, and the default for a BLOCK construct, internal subprogram, or module subprogram is the mapping in the host scoping unit.\"\nThis one sentence in the current standard effectively ends up achieving backward compatibility with code written from the days of FORTRAN I where \"ICARUS was an integer unless specified as REAL\", to paraphrase a long-standing joke with FORTRAN!\nBut now almost all the code written from the days of FORTRAN 77 then has tried to avoid the fate of the legend and not drown while trying to only take flight via the explicit use of the IMPLICIT statement, IMPLICIT NONE overwhelmingly but IMPLICIT INTEGER(I-N), xx(A-H, O-Z) {xx = DOUBLE PRECISION, REAL, REAL*8, etc.]. This proposal intends not to affect in any adverse manner any such existing code that makes explicit use of IMPLICIT statements.\nThe intended benefit of this one change is to set in motion finally a positive change where IMPLICIT NONE becomes the default in any and all program units and in all the interface bodies, gone will be the need to ensure the inclusion of implicit none in a list of explicit interfaces:\ninterface\n function foo(..) result(..)\n [import .. ]\n implicit none !<-- Per current standard, forget this and face peril\n ..\n end function\n function bar(..) result(..)\n [import .. ]\n implicit none !<-- Per current standard, forget this and face peril\n ..\n end function\n subroutine foobar(..)\n [import .. ]\n implicit none !<-- Per current standard, forget this and face peril\n ..\n end subroutine\nend interface\nAlmost every processor tries to offer a compiler option to enforce the gist of this proposal, with fpm and LFortran considering making this even the default. Why not standardize all such good intent?\nWhat say you all, can you support this for Fortran 202Y? Please keep in mind even with 202Y, it may be year 2040 by the time this can become practicable. Is it not time now to start giving this a serious consideration?",
- "is_open": true,
+ "is_open": false,
"labels": [
"Clause 8"
],
@@ -1537,6 +1820,31 @@
"user": "jacobwilliams",
"date": "2021-09-20 16:56:17+00:00",
"text": "Ah, I see what you are saying now (based on your comments here. What you are calling \"implicit mapping\" here, I was calling \"implicit typing\" in #90. I never proposed getting rid of the implicit statements (I don't think that's a good idea and will never happen anyway). So, this is the same thing I was proposing."
+ },
+ {
+ "user": "p-pap",
+ "date": "2022-05-25 15:23:41+00:00",
+ "text": "implicit none should be the default for any code written in Fortran 90 or later. This is not the case and that only causes trouble. How often you forgot to type implicit none then spent time trying to figure out what's wrong with your code, just because you mistyped a variable somewhere - but the compiler happily accepts it, just because you forgot the goddamn implicit none in the beginning? It happened more than once to me, and the workaround to prevent it from happening again is to enable extra compiler warnings, so that the compiler will at least complain about such a mistyped variable. The worst bug is the one you assume it can't ever happen."
+ },
+ {
+ "user": "Carltoffel",
+ "date": "2022-05-26 07:26:22+00:00",
+ "text": "My idea to solve this:\n\nin fixed form code\n\nbusiness as usual\n\n\nin free form code\n\nusing any implicit statement results in a warning (this warning should show up at any warning level)\nthe compiler accepts no implicit typing (unless explicitly enabled) and raises an error, if a variable without type declaration occurs"
+ },
+ {
+ "user": "klausler",
+ "date": "2022-05-30 19:35:03+00:00",
+ "text": "I don't understand how these proposals differ -- both just make IMPLICIT NONE the default, yes?\nI doubt that could possibly gain approval for Fortran 202Y for 3<=Y<\u221e, but one thing that could find support: in MODULE FUNCTION and MODULE SUBROUTINE interface blocks in (sub)modules, automatically inherit the implicit mappings or IMPLICIT NONE from the (sub)module. There is little-to-no legacy to worry about with separate module procedure interfaces and I don't ever see anybody remembering to put any kind of IMPLICIT statement in them."
+ },
+ {
+ "user": "jacobwilliams",
+ "date": "2022-05-30 20:58:48+00:00",
+ "text": "Yes, frankly, I think this is the same as #90. We don't need two of them. We should discuss it there."
+ },
+ {
+ "user": "FortranFan",
+ "date": "2022-05-30 22:59:33+00:00",
+ "text": "@jacobwilliams , with issue #90 with \"eliminate implicit typing\", it was entirely unspecific as to what was implied, perhaps removal of IMPLICIT statement altogether even? I explained this previously to you upthread:\n#218 (comment)\nYou effectively had a \"one-liner\" initially that was provocative and which was not received well.\nGiven above, ideally you would have closed issue #90 so the discussion can move to the specific suggestions in this thread. But you insist otherwise, so I will close this thread."
}
]
},
@@ -2114,7 +2422,13 @@
"labels": [
"Clause 8"
],
- "comments": []
+ "comments": [
+ {
+ "user": "septcolor",
+ "date": "2022-05-09 17:00:24+00:00",
+ "text": "I would also like to have some more \"direct\" method for holding or representing an array of pointers and an array of polymorphic variables (rather than wrapping them in a different derived type for every such case). To do so, in addition to literals like above, I wonder it may be useful to consider a builtin container type like\nlist(real) :: xs !! a list of primitive values\nlist(real, pointer) :: ps !! a list of pointers\nlist(foo_t, allocatable) :: foos !! a list of allocatable class variables\n\nthat supports\nxs% append( y )\nps% reserve( 10 )\nps( 5 ) => q\nfoos% reserve( 10 )\nallocate( foo_child_t :: foos( 5 ) )\n\n(just a rough sketch but close to what I would like to have). Here I think having the attributes like \"pointer\" or \"allocatable\" to be part of list is crucial (apart from specific syntax), such that one can distinguish whether the components have such attribute when passed to different routines. I am still not sure whether this kind thing can play well with generics, but I guess it is at least closer to what std::vector in C++ is doing. Also, I think that the very reason for \"why Fortran is considered weak for unstructured data\" (discussed in some forum thread) is deeply related to this inconvenience / awkwardness of handling such \"non-rectangular\" data."
+ }
+ ]
},
{
"number": 196,
@@ -6019,6 +6333,11 @@
"user": "certik",
"date": "2021-10-27 14:17:22+00:00",
"text": "Also proposed at https://fortran-lang.discourse.group/t/make-line-continuation-operator-optional/2176."
+ },
+ {
+ "user": "8bitmachine",
+ "date": "2022-05-22 14:36:17+00:00",
+ "text": "I would certainly like to have implicit line continuation. The & & thing is quite clunky."
}
]
},
@@ -6915,6 +7234,16 @@
"user": "veryreverie",
"date": "2021-05-31 08:53:16+00:00",
"text": "I think that there are two independent proposals here, which I would separate as:\n\nFunction objects, i.e. types which overload the () operator, probably using operator(()) syntax. Ideally these objects would also be useable in procedure(func) contexts.\nOverloadable array slice syntax. i.e. allowing user-defined procedures to take a:b:c slices as arguments. This could possibly be done by definining an intrinsic type slice with components %first, %last and %stride\n\nI think both proposals would make the language more intuitive, but I think the two should be evaluated separately, on their own merits. If both were implemented, I see no reason to limit the slice syntax to only be useable with the function object syntax."
+ },
+ {
+ "user": "perazz",
+ "date": "2022-06-03 16:44:41+00:00",
+ "text": "I'm bringing back this discussion following what's been under discussion here.\nI think having an accessor operator would be a very useful way to enable derived types/classes to be treated like arrays.\nThe points for having it should be that all functions operating on arrays should also have validity on derived types with the accessor operator.\nHere's one simple example I have in mind:\ntype :: symmetric_matrix\n integer, len :: n\n real :: data((n**2+n)/2)\n\n contains\n\n ! This should be pure and elemental OR pointer\n procedure, private, pass(this) :: sym_access\n \n ! The accessor needs something to define its dimensions\n generic :: accessor(:,:) => sym_access\n\nend type symmetric_matrix\n\ncontains\n\n! Point to symmetric data\nelemental integer function sym_ptr(this,i,j) result(ptr)\n class(symmetric_matrix), intent(in) :: this\n integer, intent(in) :: i,j\n\n integer :: row,col,ptr\n\n row = merge(i,j,i>=j)\n col = merge(j,i,i>=j)\n\n ! Get pointer to data\n ptr = this%n*(col-1)-((col-1)*(col-2))/2 + (row-col+1)\n\nend function sym_ptr\n\nelemental real function sym_access(this,i,j) result(aij)\n class(symmetric_matrix), intent(in) :: this\n integer, intent(in) :: i,j\n\n integer :: ptr\n\n ptr = sym_ptr(this,i,j)\n aij = this%data(ptr) \nend function sym_access\n\n! pointer version\nfunction sym_access(this,i,j) result(aij)\n class(symmetric_matrix), intent(in) :: this\n integer, intent(in) :: i,j\n real, pointer :: aij\n integer :: ptr\n\n if (i>=1 .and. j>=1) then \n ptr = sym_ptr(this,i,j)\n aij => this%data(ptr) \n else\n nullify(aij)\n endif\nend function sym_access\n\n\nI haven't thought about all the implications on sliced array indexing/ stride/etc. but if there's an elemental way to compute that, maybe it's straightforward.\nActually, a compiler may like more the pointer version for its' ability to return null and hence catch out-of-bounds access, or maybe not.\nMy two cents,\nFederico"
+ },
+ {
+ "user": "perazz",
+ "date": "2022-06-03 16:47:24+00:00",
+ "text": "On the usage standpoint, imagine all array-based syntax to be enabled by that, like:\nforall(i=1:N,j=1:N,j<=i) sym_mat(i,j) = blabla\n! array-like dimensions to work on are specified by the accessor interface\nsum(sym_mat,2)\nsum(sym_mat,1)\n\netc."
}
]
},
@@ -9074,6 +9403,86 @@
"user": "certik",
"date": "2021-01-12 20:33:31+00:00",
"text": "Thanks @elecprog for writing down the assumptions that you used. Under your assumptions I think your proposal could work.\nThe issue that we have is that we can't get a community agreement on the assumptions. I have seen opposition to the assumption 2., and consequently also 1. I personally agree with 2. (i.e., implicit by default being more evil), but some others disagreed (older code not compiling being more evil: Fortran historically tries very hard to compile older code, so I understand this position)."
+ },
+ {
+ "user": "jacobwilliams",
+ "date": "2022-05-25 15:03:12+00:00",
+ "text": "FYI:\n\nHow to solve the same numerical Problem in 7 different Programming Languages\nsubsequent discussion on fortran-lang Discourse"
+ },
+ {
+ "user": "jacobwilliams",
+ "date": "2022-05-30 20:57:56+00:00",
+ "text": "I think we spook people when we talk about tools and code changes. The proposal should be this and only this:\n\nThe feature in Fortran that automatically sets the type of undeclared I-N variables to integer and other variables to real is deleted.\nNo other language changes related to this are done. implicit none is still valid, implicit double precision (a-h,o-z), etc. are all still valid. implicit none becomes redundant, but that's OK (just like recursive was made redundant in a recent standard, but is still valid)\nCode that has undeclared variables (or variables not covered by an implicit statement) is now a syntax error.\nBUT, the compiler vendors are expected to provide a command line argument (e.g., -f-allow-implicit-typing that reenables it, so undeclared variables will work the same way they always have for those users not able or willing to modify their code.\n\nThat's it. Very simple and doesn't change the behavior of any code. All the maintainers of a legacy code has to do is add a single command-line argument to their build system. They don't have to change a single line of code if they don't want to.\nBut, the important part is that new codes no longer have to type \"implicit none\" everywhere. We get that automatically. Implicit typing no longer has to be explained on page 1 of the Fortran Getting Started manual, it's moved into the appendix, and new users who want to write modern code never have to worry about it or even know it ever existed. An entire class of bugs that have plagued Fortran programmers for decades will disappear forever. We can finally move on."
+ },
+ {
+ "user": "klausler",
+ "date": "2022-05-31 01:15:49+00:00",
+ "text": "J3 will sometimes change the semantics of newer conforming code, but it is very unlikely that they would change the semantics of a large proportion of older code so as to require a new compiler option to make existing (c)makefiles and source code continue to work.\nI suggest that we define a new distinct Modern Fortran source file name suffix that would imply free source form and a few modest incompatible semantic changes: default IMPLICIT NONE(TYPE,EXTERNAL) and corrected DO CONCURRENT semantic guarantees are obvious possibilities. (I have a list, but the specific details don't matter as much as the general idea.) Get a few compilers to recognize the new suffix -- I think that it would not be a hard sell, at least for me -- and you'll have what you want without affecting any older codes.\n(Addendum: This could of course also be done with a compiler directive !dir$ modern but that kind of defeats the purpose of making things less mysterious for newcomers. And my list includes: enable cpp-like preprocessing, disable deprecated features, disallow non-module subprograms, and give up on things like LEN parameters to PDTs that are still not widely avaiable.)"
+ },
+ {
+ "user": "milancurcic",
+ "date": "2022-05-31 15:11:36+00:00",
+ "text": "@jacobwilliams here are my suggestions:\n\nRemove the last bullet (expect compiler arguments), it's a non-starter for a proposal to J3.\nThe first 3 bullets are redundant statements. Distill into the simplest and clearest message possible. Perhaps this is something along the lines of \"Implicit typing must be enabled with the implicit statement\", or similar. I'm not proficient enough yet with standardese to express it more appropriately.\nResearch what edits to the standard would need to be made to implement this; this is not required at this stage (idea pitch), but it would be helpful to demonstrate that this would be indeed a small change to the standard from an editorial point of view.\nWrite the proposal; research past successful proposals to get an idea for the style, structure, and contents. Include a thorough list of concrete downsides and upsides to this change. I suggest not writing in absolutes like \"nobody's code will break\" or \"everybody wants this\" if you want it taken seriously.\nSubmit a proposal as a PR in this repo. This will serve as the first filter before it's uploaded to J3. The sooner the better.\nFind a J3 member to champion your proposal.\nJoin J3.\n\nI think the proposal may have a slightly better chance if it proposes for marking default implicit typing as obsolescent rather than deleted. Traditionally features have been sunset gradually (obsolescent first, delete second), but there have been discussions about changing this process and deleting features on a shorter fuse."
+ },
+ {
+ "user": "FortranFan",
+ "date": "2022-06-01 01:19:12+00:00",
+ "text": "@milancurcic wrote May 31, 2022 11:11 AM EDT:\n\n3. Research what edits to the standard would need to be made to implement this; this is not required at this stage (idea pitch), but it would be helpful to demonstrate that this would be indeed a small change to the standard from an editorial point of view.\n\nI have done the \"research\" and as I pointed in issue #218 my observation is only one sentence needs to be modified in the standard (18-007r1 document as proxy) which is in section 8.7 IMPLICIT STATEMENT page 114, paragraph 3, lines 32-34.\nIn order to achieve the desired change, the relevant sentence can be changed to something along the lines of:\n\"If a mapping is not specified for a letter, the default for a program unit or an interface body shall be NULL, and the default for a BLOCK construct, internal subprogram, or module subprogram is the mapping in the host scoping unit\"\nReaders can peruse 18-007r1 document or issue #218 for what the standard states currently."
+ },
+ {
+ "user": "FortranFan",
+ "date": "2022-06-01 02:09:05+00:00",
+ "text": "my observation is only sentence needs to be modified in the standard\n\n@jacobwilliams , I hope you will be leading this based on your prior comment and your insistence on closing issue #218 even though so many things are on the wrong track here in this thread, starting with your poorly worded title itself.\nIt should be obvious to any reader the root matter is mostly non-technical, it is a vision thingy really for Fortran to head in the direction of explicit declarations. All indications are most on the committee do not align with any such vision, or any vision period. Most voting members would rather live with the status quo for eternity. There is a monumental hurdle to be overcome here.\nSo I hope you will follow all the right steps from this point forward - which are all administrative \"process\" and the \"right manners\" based as laid out by @milancurcic - in order to try to bring about the right influence on the committee(s).\nPerhaps you want to watch this video first and do as indicated to avoid the \"no soup for you\" fate."
+ },
+ {
+ "user": "certik",
+ "date": "2022-06-01 02:30:05+00:00",
+ "text": "Everybody, let's be nice to each other. We are all in the same boat. As I mentioned at the Discourse thread, LFortran already \"eliminated implicit typing\" by default, and I encourage other compilers to follow suit.\nRegarding the standard, @jacobwilliams, do you want to take a lead on this?"
+ },
+ {
+ "user": "klausler",
+ "date": "2022-06-01 17:30:56+00:00",
+ "text": "Has there been a WG5 or J3 proposal paper in the past to make implicit none(type) the default? The archive isn't very searchable and it only goes back to 2006, so maybe I've missed a paper on this topic."
+ },
+ {
+ "user": "gklimowicz",
+ "date": "2022-06-02 15:28:31+00:00",
+ "text": "Since implicit none was introduced in Fortran 1990, I suspect that any papers that reference making it a default only exist in hard-copy form. Here's what I can see in my offline archive of all the digital papers I have laid my hands on. There are 442 references to the phrase, but most are in program examples.\nPaper 03-153.txt, around line 78:\nj. WG5 was undecided whether the default implicit rules in a\nsubmodule should be those of its parent or implicit none and\nencourages J3 to consider this further.\n\nA vote on submodules and implicit none was recorded in 03-210.txt, near line 206:\nThe default implicit rules for a submodule are those of \nits Parent, Implicit none, usual Default rules\nor Undecided? P I D U\n 4 5 0 3\n\nWe should probably ask Peter's question in comp.lang.fortran."
+ },
+ {
+ "user": "certik",
+ "date": "2022-06-02 16:02:58+00:00",
+ "text": "Thanks @gklimowicz ! So that is interesting: nobody voted for the \"usual Default rules\". Most people voted for \"Implicit none\" to be the default.\nAlso: there where only 12 people voting. There are already 10 participants who commented in this issue, and 23 (!) who upvoted the issue. So to me it means that there is clear interest in revisiting this."
+ },
+ {
+ "user": "klausler",
+ "date": "2022-06-02 16:58:51+00:00",
+ "text": "Inventing the implicit typing behavior for a new feature like submodules wouldn't affect any existing code, of course. But it's odd, given this vote, that submodules (and more important, separate module procedure interfaces) ended up with the same old rules by the time they were published in F'2008.\nI look forward to seeing what happens when a proposal that would require source changes to legacy codes is put forward. Is somebody going to write this up as an official paper?"
+ },
+ {
+ "user": "FortranFan",
+ "date": "2022-06-02 20:50:03+00:00",
+ "text": "Is somebody going to write this up as an official paper?\n\nBased on the thumbs up voting trail upthread, I expect @jacobwilliams and the nice folks will write up the \"official\" paper."
+ },
+ {
+ "user": "FortranFan",
+ "date": "2022-06-02 20:59:49+00:00",
+ "text": "any papers that reference making it a default\n\nI hope any such papers and prior votes are only of historic interest.\nAny proposals, if present at all to make implicit none the default, clearly got voted down ultimately and that's why the standard is the way it is now with implicit mapping rules pervasive across all the program units.\nI will hope past performance of the committee(s) is not indicative of future results."
+ },
+ {
+ "user": "klausler",
+ "date": "2022-06-02 21:16:01+00:00",
+ "text": "any papers that reference making it a default\n\nI hope any such papers and prior votes are only of historic interest.\nAny proposals, if present at all to make implicit none the default, clearly got voted down ultimately and that's why the standard is the way it is now with implicit mapping rules pervasive across all the program units.\nI will hope past performance of the committee(s) is not indicative of future results.\n\nWill you champion this paper at J3, if it is written?"
+ },
+ {
+ "user": "FortranFan",
+ "date": "2022-06-03 01:21:34+00:00",
+ "text": "any papers that reference making it a default\n\nI hope any such papers and prior votes are only of historic interest.\nAny proposals, if present at all to make implicit none the default, clearly got voted down ultimately and that's why the standard is the way it is now with implicit mapping rules pervasive across all the program units.\nI will hope past performance of the committee(s) is not indicative of future results.\n\nWill you champion this paper at J3, if it is written?\n\n@klausler , sincere apologies if the question was not addressed to me - I have presumed as such because my comments got quoted.\nMy response will be as follows: assuming the paper is a single topic one and it focuses on doing away with the implicit mapping along the lines of a possible one-sentence change (see above), meaning a minimally complicated brief paper honed in to make implicit none the default, I will be more than eager to lend it my fullest support in any way possible including all J3 discussions where I might be able to contribute and particularly with any straw votes. And if I were a full voting member, I would have been more than eager to champion it also, alas I am not. My gut feel though is getting a commercial vendor or two who are full voting members to champion a paper can prove to be a far positive influence."
+ },
+ {
+ "user": "klausler",
+ "date": "2022-06-03 17:06:00+00:00",
+ "text": "any papers that reference making it a default\n\nI hope any such papers and prior votes are only of historic interest.\nAny proposals, if present at all to make implicit none the default, clearly got voted down ultimately and that's why the standard is the way it is now with implicit mapping rules pervasive across all the program units.\nI will hope past performance of the committee(s) is not indicative of future results.\n\nWill you champion this paper at J3, if it is written?\n\n@klausler , sincere apologies if the question was not addressed to me - I have presumed as such because my comments got quoted.\nMy response will be as follows: assuming the paper is a single topic one and it focuses on doing away with the implicit mapping along the lines of a possible one-sentence change (see above), I will be more than eager to lend it my fullest support in any J3 discussion where I can contribute and particularly with any straw votes. And if I were a full voting member, I would have more than eager to champion it also, alas I am not. My gut feel though is getting a commercial vendor or two who are full voting members to champion a paper can prove to be a far positive influence.\n\nYou should write the paper, then, to ensure that it matches your concept of the change."
}
]
},
@@ -10226,6 +10635,96 @@
"user": "certik",
"date": "2019-11-11 21:14:30+00:00",
"text": "@FortranFan thank you, I think it looks great!"
+ },
+ {
+ "user": "8bitmachine",
+ "date": "2022-05-22 15:04:08+00:00",
+ "text": "I have also made a request which is based on a similar concept that numbers declared with REAL(8) for example are exactly that. The issue is that if a number is not specified to be \"doubnle precision\" then at least one compilier will only assign 4-byte precision even though a number is declared 8 bytyes.\nFor example:\nREAL(8) :: x=3.\nPRINT*,'x=',x\nmay print out\n3.00000001254321\nor some such.\nThis is only fixable (in my compiler) if the statement\nREAL(8) :: x=3.0d0 is used.\nNot even REAL(8) :: x=3.0E0 worked.\nSo my request is that variables declared as REAL(8) (or other) are recognised as 8 byte precision and not left to a compiler preference.\nFollowing on from this, the \"D\" designator is past its due date and should be obsoleted.\nFurthermore, requring the decimal point to indicate a real number is also past due.\nUnless this is already implemented, I would like to see\nREAL(8) ::one=1\nbe sufficient to specify the variable one as 1.0000000000000 etc and not have to type the decimal pont - in otherwords, because the variable is declared real, it should implcitly understand that without a decimal point."
+ },
+ {
+ "user": "certik",
+ "date": "2022-05-22 15:34:46+00:00",
+ "text": "My understanding is that REAL(8) :: x=3 is declaring an integer 3 (exact) and then implicitly casting it to a kind=8 floating point number. So it should print exactly 3.0000000000000000 (or similar)."
+ },
+ {
+ "user": "8bitmachine",
+ "date": "2022-05-22 17:49:15+00:00",
+ "text": "You are right, but my concern is that something like\nREAL(8)::x=4.1\ndoes not default to 8 byte precision (at least not with the compiler I am using, but it can be forced by setting promote REAL(4) to REAL (8).\nMy point is that in order to drop the D descriptor Fortran should require all initialisations to implicitly set the target accuracy.\nWhat happens currently is that REAL(8) :: x=4.1 assigns an 8 byte space but only specifies 4 bytes of precision, leaving the LSB's undefined (random numbers)."
+ },
+ {
+ "user": "certik",
+ "date": "2022-05-22 18:06:22+00:00",
+ "text": "Yes, that is a common problem, and discussed in quite a few issues here and at Fortran discourse. If you read through the prior discussion, there are quite a few arguments why it might be difficult to fix this. So in order for any such proposal to succeed, you have to address the prior points."
+ },
+ {
+ "user": "klausler",
+ "date": "2022-05-22 23:37:38+00:00",
+ "text": "You are right, but my concern is that something like REAL(8)::x=4.1 does not default to 8 byte precision (at least not with the compiler I am using, but it can be forced by setting promote REAL(4) to REAL (8). My point is that in order to drop the D descriptor Fortran should require all initialisations to implicitly set the target accuracy. What happens currently is that REAL(8) :: x=4.1 assigns an 8 byte space but only specifies 4 bytes of precision, leaving the LSB's undefined (random numbers).\n\nAll bits are completely well defined, just not to what you think they should be. Come on."
+ },
+ {
+ "user": "8bitmachine",
+ "date": "2022-05-23 09:35:51+00:00",
+ "text": "@klausler - What was the point of your comment?\nFortran as a language has strict rules. But if users want to bring it up to date and elminate some of the more outdated quirks things like D descriptor then surely defining constants properly is mandatory? And making number implementation compatible with future capabilities at the same time. It won't be long before REAL(16) is needed if not already by some programmers.\nEven a floating point chip designed decades ago did a better job (and that tended to work with 96 bit precision).\n@certik - do you have a link to where the previous points have been raised?"
+ },
+ {
+ "user": "certik",
+ "date": "2022-05-23 14:02:02+00:00",
+ "text": "I think Peter's point was that the current standard defines exactly what happens and it has its logic and motivation and it is (relatively) consistent. I agree.\nBut in my experience this is a point of confusion to almost every single new person to Fortran. I'll find the links to prior discussions later today."
+ },
+ {
+ "user": "klausler",
+ "date": "2022-05-23 14:55:25+00:00",
+ "text": "My point is that claiming that the lower order bits of the result of a 32-bit to 64-bit floating-point conversion are undefined random garbage is complete nonsense.\nIf you don't like D numbers, use a modern suffix."
+ },
+ {
+ "user": "8bitmachine",
+ "date": "2022-05-23 15:38:58+00:00",
+ "text": "@klausler - Well, filling in with zeros to extend the data is one approach, but do you agree that the bits ought to have been extended to ensure that the number is consistent with the specified one when converted back from binary to decimal?\nI was somewhat glib, technically corrected. But the digits may as well have been random for the effect they have as to avoid this some additional work is needed (like using D, still).\nI am not sure what the motivation was but no doubt Fortran developers will know.\nI'm not that new to Fortran BTW, but I do have some wishes for future releases."
+ },
+ {
+ "user": "wyphan",
+ "date": "2022-05-23 15:53:48+00:00",
+ "text": "@8bitmachine I think what @klausler meant is the representation of a number as sign, mantissa, and exponent bits in the floating-point representation as dictated by IEEE 754 standard. If you know the nuances of the mantissa bits, I think you should arrive at the conclusion that it is impossible to have a one-to-one mapping between binary and decimal for floating-point numbers. I suggest you grab a copy of the latest Fortran standard interpretation document J3/18-007r1 and look into the following:\n\nsection 7.4.3 on \"Numeric intrinsic types\"\nsection 16.9.160 on the definition of the \"REAL()\" intrinsic function\nsection 17 \"Exceptions and IEEE Arithmetic\"."
+ },
+ {
+ "user": "klausler",
+ "date": "2022-05-23 16:12:20+00:00",
+ "text": "@klausler - Well, filling in with zeros to extend the data is one approach, but do you agree that the bits ought to have been extended to ensure that the number is consistent with the specified one when converted back from binary to decimal?\n\nEvery binary number with a finite number of digits can be represented by a decimal number with a finite number of digits, but the converse is not true."
+ },
+ {
+ "user": "8bitmachine",
+ "date": "2022-05-23 16:20:46+00:00",
+ "text": "I do know that decimal numbers and binary numbers do not have exact equvialents, of course.\nMy point is that, and I do not seem to be the only person, I would much prefer that when a compiler sees\nreal(8)::x=4.1, to continue with my earlier example, it translates and stores the number as\n4010666666666666 rather than 4010666660000000 (both hexadecimal).\nRather than having to use a suffix, although that would appear to be the current BKM."
+ },
+ {
+ "user": "8bitmachine",
+ "date": "2022-05-24 14:30:02+00:00",
+ "text": "I would also add that it seems to me that selected_real_kind has not actually helped.\nMost computer systems these days implement the IEEE number formats in full. Therefore, unlike earlier times, 32, 64 and extended precisions are well established and should be the primary defaults. Fortran should in my view recognise that.\nIf particular programs need greater resolution than offered by real(8) or real(16) then perhaps the argument needs to be as to what the next resolution standard should be. selected_real_kind does not really assure of a particular resolution only a minimum which might be met.\nHaving to specify a real with a suffix seems to be as an imposition similar to requiring the D descriptor.\nNo doubt Fortran community will tell me \"selected_real_kind\" is a step forward. As a long time user of Fortran, I'm asking for a simpler option, not a more complicated one."
+ },
+ {
+ "user": "wyphan",
+ "date": "2022-05-24 14:34:27+00:00",
+ "text": "There are already `real32` and `real64` kinds defined in `ISO_FORTRAN_ENV`,\nisn't that enough?\n\u2026\nOn Tue, May 24, 2022, 10:30 8bitmachine ***@***.***> wrote:\n I would also add that it seems to me that selected_real_kind has not\n actually helped.\n Most computer systems these days implement the IEEE number formats in\n full. Therefore, unlike earlier times, 32, 64 and extended precisions are\n well established and should be the primary defaults. Fortran should in my\n view recognise that.\n If particular programs need greater resolution than offered by real(8) or\n real(16) then perhaps the argument needs to be as to what the next\n resolution standard should be. selected_real_kind does not really assure of\n a particular resolution only a minimum which might be met.\n Having to specify a real with a suffix seems to be as an imposition\n similar to requiring the D descriptor.\n No doubt Fortran community will tell me \"selected_real_kind\" is a step\n forward. As a long time user of Fortran, I'm asking for a simpler option,\n not a more complicated one.\n\n \u2014\n Reply to this email directly, view it on GitHub\n <#78 (comment)>,\n or unsubscribe\n \n .\n You are receiving this because you commented.Message ID:\n ***@***.***>"
+ },
+ {
+ "user": "klausler",
+ "date": "2022-05-24 15:25:07+00:00",
+ "text": "The problem here is that you're trying to change part of the language that is not context-sensitive into something that is. The type of a numeric literal (in Fortran and every other programming language that I know!) is self evident from the characters that constitute that literal. 3.14 is default REAL in Fortran in every context, and double in C/C++ in every context.\nSo you want to change that. Fine. What you need to do next is (1) figure out a way to not invalidate hundreds of millions of lines of existing code by changing the interpretation of their numeric literals and (2) figure out a way of defining, in a very precise and airtight way, how the context would affect the interpretation of numeric literals.\nLast, you may not like SELECTED_REAL_KIND or the real kind parameters in the intrinsic modules, but you're going to have to use those kind names even if you somehow come up with useful semantics for the REAL(KIND=k) type-declaration-stmt. REAL(8) should be universally portable, but it isn't, thanks to one vendor."
+ },
+ {
+ "user": "8bitmachine",
+ "date": "2022-05-24 19:56:08+00:00",
+ "text": "@wyphan\nIndeed, that sort of adds to my point that while selected_real_kind appears to offer a great flexibility in practice almost all, at least all the programs I have seen in industrial use, have used real(8) which I assume is the same as real64 ISO_FORTRAN_ENV which I would use if my compiler had it. I've never needed greater than that either, so real(4) and real(8) should have been sufficient. It also means I question the development of selected-real_kind if it was not going to offer guaranteed formats, as many of the possible real/exponent combinations won't be available or used. Must have seemed a good idea at the time.\n@klausler, yes it may be that REAL(8) and REAL(4) would indeed set the context. I'm sure that is not beyond the capabilities of Fortran programmers. It is difficult to see, though, how extending a real(4) to a real(8) by zeroing the additional bits was a better solution as the context has changed for those variables defined as real(8). Presumably, like myself, programmers wishing to use 8 byte precision were expecting the context to change.\nI guess I'll define real(r8) as a selected real kind (15,307) and have done with it. Does not alter my wish for a simpler system.\nTherefore, if programmers are using some form of selected_real_kind definition a new term would only apply to"
+ },
+ {
+ "user": "w6ws",
+ "date": "2022-05-24 23:37:13+00:00",
+ "text": "There are at least two compilers I know of that, by default, use kind=1 for single precision and kind=2 for double precision.\u00a0 They are the NAG Fortran compiler and the Silverfrost FTN95 compiler.\u00a0 There may be others.\u00a0 But these are two I can know of off the top of my head.\u00a0 In both cases, compiler options can be used to change the defaults to byte-oriented kinds.\n\u00a0\nAs previously mentioned, the real solution is use kind=real32 and kind=real64 from ISO_FORTRAN_ENV.\u00a0 For constants, you could write for example:\n\u00a0\n\u00a0 use iso_fortran_env\n\u00a0 ...\n\u00a0 real(real64), parameter :: pi = 3.141592654_real64\u00a0 ! Poor approximation\n\u00a0\nOr if you've been defining your own 'r4' and 'r8' kinds:\n\u00a0\n\u00a0 use iso_fortran_env\n\u00a0 ...\n\u00a0 integer, parameter :: r4 = real32, r8 = real64\n\u00a0 ...\n\u00a0 real(r8), parameter :: pi = 3.141592654_r8\u00a0 ! Poor approximation\n\u00a0\nWhich compiler are you using that doesn't support ISO_FORTRAN_ENV?\n\u00a0\nWalter\n\u00a0\n-----Original Message-----\nFrom: j3-fortran/fortran_proposals\nSent: May 24, 2022 12:56 PM\nTo: j3-fortran/fortran_proposals\nCc: Subscribed\nSubject: Re: [j3-fortran/fortran_proposals] Default KINDs for constants and intrinsics (#78)\n\u00a0\n\u00a0\n@wyphan (https://github.com/wyphan)\nIndeed, that sort of adds to my point that while selected_real_kind appears to offer a great flexibility in practice almost all, at least all the programs I have seen in industrial use, have used real(8) which I assume is the same as real64 ISO_FORTRAN_ENV which I would use if my compiler had it. I've never needed greater than that either, so real(4) and real(8) should have been sufficient. It also means I question the development of selected-real_kind if it was not going to offer guaranteed formats, as many of the possible real/exponent combinations won't be available or used. Must have seemed a good idea at the time.\n@klausler (https://github.com/klausler), yes it may be that REAL(8) and REAL(4) would indeed set the context. I'm sure that is not beyond the capabilities of Fortran programmers. It is difficult to see, though, how extending a real(4) to a real(8) by zeroing the additional bits was a better solution as the context has changed for those variables defined as real(8). Presumably, like myself, programmers wishing to use 8 byte precision were expecting the context to change.\nI guess I'll define real(r8) as a selected real kind (15,307) and have done with it. Does not alter my wish for a simpler system.\nTherefore, if programmers are using some form of selected_real_kind definition a new term would only apply to\n\u2014\nReply to this email directly, view it on GitHub (#78 (comment)), or unsubscribe (https://github.com/notifications/unsubscribe-auth/ABCNQOY6TVWJ4RSC7XR26H3VLUX6HANCNFSM4JLXUJZA).\nYou are receiving this because you are subscribed to this thread.Message ID:\n\n\u00a0"
+ },
+ {
+ "user": "FortranFan",
+ "date": "2022-05-25 15:29:09+00:00",
+ "text": "What you need to do next is (1) figure out a way to not invalidate hundreds of millions of lines of existing code by changing the interpretation of their numeric literals and (2) figure out a way of defining, in a very precise and airtight way, how the context would affect the interpretation of numeric literals.\n\n@8bitmachine , why not upvote the original post? It addresses the challenges thrown here by @klausler. Should there be any gaps or limitations or wrinkles with the proposal in the original post, the standard committee should and can step up to iron them out, if they can be influenced to again take up a solution to the situation. Note the proposal in the original post nearly had made its way into Fortran 2008 but was only deferred due to non-technical aspects.\nConsider the following program:\n double precision :: x = 0.1\n print \"(b0)\", x\nend\nMost processors based on the current standard will yield the following output:\n11111110111001100110011001100110100000000000000000000000000000\n\nPer your posts here and as mentioned by @certik re: many Fortranners, the above output is a bit (pun intended) confusing and can even lead to errors with unsuspecting users.\nWith the proposal in the original post, the following modification will likely give many users the output they expect and also want with a possible conforming processor in the future:\n default real (kind=kind(1D0)) !<-- pseudo syntax\n double precision :: x = 0.1\n print \"(b0)\", x\nend\n11111110111001100110011001100110011001100110011001100110011010"
}
]
},
@@ -11716,7 +12215,7 @@
{
"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."
+ "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.\nEdit: updated link"
},
{
"user": "FortranFan",
@@ -11727,6 +12226,61 @@
"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."
+ },
+ {
+ "user": "wyphan",
+ "date": "2022-05-23 16:00:11+00:00",
+ "text": "Hi @klausler , now that my Google Summer of Code project proposal for DO CONCURRENT support in GFortran has been accepted, I'd like to set up a meeting to discuss about this. (I wish GitHub has a messaging feature...)\nIf you happen to be at the Fortran Discourse forums, please send me a PM with your NVIDIA email address so I can send you a calendar invite to the meeting I'm in the process of setting up with Jeff Larkin, G\u00fcray \u00d6zen, and the folks at Predictive Science who published arXiv:2110.10151 about the DO CONCURRENT implementation in NVIDIA nvfortran. Otherwise you can reach me at wileam [at] phan [dot] codes.\nOf course, anyone in this thread who is interested is welcome too."
+ },
+ {
+ "user": "klausler",
+ "date": "2022-05-24 23:56:28+00:00",
+ "text": "I have reviewed the document for LLVM Fortran that describes the problems with DO CONCURRENT in the standard language, and unfortunately nothing has changed on the language standards front since I wrote it in 2020. In particular, nothing has been done to fix DO CONCURRENT in the draft Fortran 202X standards (apart maybe from SIMPLE procedures). Perhaps somebody on WG5/J3 may take it up for Fortran 202Y but that is of course a long ways out."
+ },
+ {
+ "user": "certik",
+ "date": "2022-05-25 00:02:58+00:00",
+ "text": "Perhaps somebody on WG5/J3 may take it up for Fortran 202Y but that is of course a long ways out.\n\n@klausler you have the most knowledge on this particular issue (since you wrote the Flang document!). Do you think you could please submit proposals for 2Y to fix this? I'll help champion it and advocate for it, but it would take me much longer to write up than it would take for you, since you have thought about all the details here and what needs to be done."
+ },
+ {
+ "user": "klausler",
+ "date": "2022-05-25 00:56:59+00:00",
+ "text": "My 2019 paper, which was ignored by J3, remains my favored solution; recycle it if you like. It would be nice if the semantics of locality specifiers with regard to pointers and ASSOCIATE/SELECT TYPE names would also be clarified, too, as being invalid for LOCAL()."
+ },
+ {
+ "user": "rouson",
+ "date": "2022-05-25 01:42:07+00:00",
+ "text": "A J3 mailing list discussion of this topic spanned 44 emails over 11 days in July 2020. I wrote email 42 attempting to crystallize the discussion into a practice that I could teach. My takeaway: it suffices for every do concurrent construct to include a default(none) statement obligating the programmer to declare every variable accessed inside the construct as shared, local, or local_init. Email 43 essentially concurred and compared default(none) to implicit none so I think of default(none) as just good code hygiene and consider the issue settled for my purposes. I would be satisfied with a compiler that parallelizes, vectorizes, or offloads do concurrent only when default(none) is present. I therefore don't consider do concurrent broken any more than I would consider all of Fortran broken because programmers are free to not use implicit none.\nIf someone submits a Fortran 202Y proposal related to this issue, I suggest that it either involve backward-compatible changes to do concurrent or that a new feature be proposed that is syntactically similar to do concurrent but with semantics amenable to parallelization. The new feature could be do parallel and could resemble do concurrent but with different constraints."
+ },
+ {
+ "user": "rouson",
+ "date": "2022-05-25 01:51:26+00:00",
+ "text": "@klausler could you share with us what course of action NVIDIA chose for offloading do concurrent? If, for example, the compiler allows me pass a flag that toggles offloading off and on at compile time, I would be happy. I would always include default(none), which at least would force me to think through locality so that I have a good understanding of whether it's safe to offload."
+ },
+ {
+ "user": "klausler",
+ "date": "2022-05-25 02:02:03+00:00",
+ "text": "The three problems with DO CONCURRENT (...) DEFAULT(NONE) are that (1) you have to name every data item in every loop in a locality clause, (2) the F'2018 locality clauses only allow simple names and (3) the semantics of pointers in locality clauses are not defined.\nA better (but not best) suggestion was to use DEFAULT(SHARED) but the problem with that is that it doesn't exist.\nSo I still recommend that the default implicit localization rule be changed (perhaps by syntax) to pertain only to names that could appear in an explicit LOCAL() clause. The fact that it was defined so that it applies to array elements and components is accidental; if fixed, it would work the way everybody assumes that it already does."
+ },
+ {
+ "user": "rouson",
+ "date": "2022-05-25 03:14:22+00:00",
+ "text": "The three problems with DO CONCURRENT (...) DEFAULT(NONE) are that (1) you have to name every data item in every loop in a locality clause, (2) the F'2018 locality clauses only allow simple names and (3) the semantics of pointers in locality clauses are not defined.\n\nThis is helpful. I hope the NVIDIA representative(s) on J3 can champion your suggestions. I'd like to see these issues addressed but I would be a poor champion because I have little personal use for most of the features that break do concurrent. It seems that the problematic features mostly involve pointers (which I rarely use), indirect addressing (which I seldom use), or module variables (which I mostly avoid) so I wouldn't have many useful insights in any of the discussions that arise around a new proposal.\n\nA better (but not best) suggestion was to use DEFAULT(SHARED) but the problem with that is that it doesn't exist.\n\nA J3 member in the aforementioned mailing list discussion stated that default(shared) was considered by the committee and that it was decided that default(none) would be less error-prone. A reference was made to the complexities of OpenMP's default(shared). I don't know enough to have an opinion. I just want to say that the suggestion was considered and another path taken for reasons that were provided.\n\nSo I still recommend that the default implicit localization rule be changed (perhaps by syntax) to pertain only to names that could appear in an explicit LOCAL() clause. The fact that it was defined so that it applies to array elements and components is accidental; if fixed, it would work the way everybody assumes that it already does.\n\nMaybe but I think the committee gives more weight to what the committee intended than to what users might incorrectly assume. I think the unstated goal is to make the standard clear, consistent, and useful. If it's unclear, add a note. If it's inconsistent, fix it. If it's clear and consistent but not useful, replace the feature much like do concurrent effectively replaces forall, but don't break existing code that relies upon the feature as long as that code has an unambiguous interpretation that is consistent with what those who wrote the standard intended. This is just my observation of how the committee operates and I'm ok with it. It's why I usually recommend that people attend several meetings before making a proposal. It can take some time to read the room and understand the dynamics and the implicit aims."
+ },
+ {
+ "user": "klausler",
+ "date": "2022-05-25 15:37:23+00:00",
+ "text": "Maybe but I think the committee gives more weight to what the committee intended than to what users might incorrectly assume. I think the unstated goal is to make the standard clear, consistent, and useful. If it's unclear, add a note. If it's inconsistent, fix it. If it's clear and consistent but not useful, replace the feature much like do concurrent effectively replaces forall, but don't break existing code that relies upon the feature as long as that code has an unambiguous interpretation that is consistent with what those who wrote the standard intended. This is just my observation of how the committee operates and I'm ok with it. It's why I usually recommend that people attend several meetings before making a proposal. It can take some time to read the room and understand the dynamics and the implicit aims.\n\nThere's good precedent in a similar case of J3 doing the right thing to preserve the intent of a feature. PURE procedures have restrictions that prevent them from causing side effects. A hole was discovered by which one could sneak modification of a global variable into a PURE subprogram -- declare a derived type with an initialized pointer component outside the procedure, then within, declare a variable of that type, and then use its default initialized pointer component to write to the global variable.\nThe response, admirably, was to plug the hole. The change might invalidate existing code, but it was the right thing to do.\nDO CONCURRENT's problems are similar. The definition of the default localization rule makes it possible to write a loop whose iterations cannot execute concurrently, even though all of the many documented restrictions in the standard are satisfied. That's the hole in the spec. Worse, a compiler can't always detect at compilation time whether the hole is being exploited, and may have to conservatively assume that it is. The hole is easy to plug. And like the hole in PURE procedures, it should be plugged."
+ },
+ {
+ "user": "wyphan",
+ "date": "2022-05-25 15:51:21+00:00",
+ "text": "@klausler This is exactly why I want to start discussion. I plan to push for DEFAULT as a GNU extension and implement it accordingly during the GSoC. I'm inviting you, @jefflarkin, and @grypp from NVIDIA, Ron Caplan and Miko Stulajter from @predsci because they published arXiv:2110.10151 as the first real-world use case for DO CONCURRENT, as well as my GSoC mentors Tobias Burnus and @tschwinge from GCC/Siemens. And as I indicated before, other interested folks in this thread are welcome too. Tentatively it will be held between June 6-10, which is the week after ISC '22. Hopefully, upon successful implementation as a GNU extension, the standards committee will consider to include it in Fortran 202Y.\nEdit: after a careful re-read of R1130 in J3/18-007r1 section 11.1.7.2, turns out DEFAULT(NONE) is included in Fortran 2018, but not DEFAULT(SHARED) or any other DEFAULT arguments."
+ },
+ {
+ "user": "wyphan",
+ "date": "2022-05-25 15:53:19+00:00",
+ "text": "Btw, the first thread from the discussion over the J3 mailing list that @rouson mentioned can be accessed here: https://mailman.j3-fortran.org/pipermail/j3/2020-July/012229.html"
}
]
},
@@ -13966,6 +14520,131 @@
"user": "vansnyder",
"date": "2020-05-09 20:02:21+00:00",
"text": "I proposed parameterized modules in 2004. The paper was 04-383r1. It's similar in spirit to Arjen's proposal, but uses the MODULE and USE statements. It provides what Magne Haveraaen asked for in Tokyo.\n04-383r1.pdf"
+ },
+ {
+ "user": "urbanjost",
+ "date": "2022-05-08 16:53:04+00:00",
+ "text": "For reference, I have been experimenting with templating using simple\nstring substitution in a Fortran preprocessor, and was considering\nrefactoring it to allow something like the following...\nThe vast majority of times I use templating it is for a generic interface.\nEssentially, a \"module procedure\" declaration could \"call\" a generic\nprocedure from the interface block with a list of tokens.\nIt would not by itself handle when conditionals are required but I\nalready had fpp(1)-like conditional directives. Even without that, a\nsubset of problems that would lend themselves to conditional processing\ncould just be handled with more complex strings (like making a token\nwith values like 'character(len=:,kind=default)' and 'type(mytype)'\ninstead of simple words).\nSupporting this only in a module would allow for the strings to be\nspecified in other places, like a PUBLIC directive instead of only\nallowing it in an interface block, but then name mangling would be harder\nto automate, but maybe something like\npublic pubname=>name(tokens ...)\nwould work as well.\ninterface swap\n module procedure swap('REAL','REAL32')\n module procedure swap(type='REAL',kind='REAL64')\n module procedure swap('INTEGER','INT8')\n module procedure swap('INTEGER','INT16')\n module procedure swap('INTEGER','INT32')\n module procedure swap('INTEGER','INT64')\n module procedure swap(type='logical',)\nend interface\n\ncontains\n\n! adding the TOKENS field indicates this procedure is\n! only to be processed if referenced from an interface\n! definition. Having a default specified by NAME='string'\n! would be not just convenient, but document what strings \n! are expected and allow for them to be called by name.\n\nelemental subroutine swap(x,y) TOKENS(TYPE='integer',KIND='int32') \n\n!@(#) M_sort::d_swap(3fp): swap two double variables\n\ninteger, parameter :: wp={KIND}\n{TYPE}(kind={KIND}), intent(inout) :: x,y\n{TYPE}(kind={KIND}) :: temp\n{TYPE}(kind={KIND}) :: unused\n temp = x; x = y; y = temp\n\n ! note an issue with using _wp here :\n unused=10_wp \n unused=10.0_wp \n\nend subroutine swap\nIf you allowed arrays to create permutations something like\n module procedure swap('INTEGER',['INT8','INT32','INT16','INT64'])\nwould be nice, and some way to conditionally build only if a {type,kind}\nis supported, so if a compiler does not support REAL128 it could be\nskipped, or all supported kinds could be detected and used.\nSo that got me re-reading some of the links regarding templating.\nI was surprised how similiar some of the proposals were in many ways,\nand how far they dated back at first, except for syntax details; but\nthe real question to me then became whether the Fortran language itself\nshould have templating syntax or if Fortran needs a Standard-specified\npre-processor (anyway) and that templating should be included there\ninstead of in the language.\nI am wondering what the benefits are to placing templating straight into\nthe language versus Fortran developing a standard pre-processor that would\ninclude templating?\nFor example, perhaps templating might occur at run-time, or only include\nrequired instances of the routine versus a preprocessor generating a\npre-defined set? Is this seen as something that will basically be handled\nby pre-processing the code by the compiler, or something accessible at\nload/link or run time?"
+ },
+ {
+ "user": "vansnyder",
+ "date": "2022-05-08 19:39:34+00:00",
+ "text": "On Sun, 2022-05-08 at 09:53 -0700, urbanjost wrote:\n I am wondering what the benefits are to placing templating straight\n into\n the language versus Fortran developing a standard pre-processor that\n would\n include templating?\nThis was Part 3 of the Fortran standard, which essentially nobody used,\nand has been withdrawn.\n\nIt was also briefly part of the 2008 draft -- a subclause about a\nbuilt-in macro system -- which was also withdrawn.\n\nThe advantage of parameterized modules or templates is that the\nprocessor understands them. One of the goals of the current design\neffort is that there will be no syntax or semantic errors within an\ninstantiated paramaterized module or template if there are no syntax or\nsemantic errors in the parameterized module or template. This is\nenforced with adequate declarations of the parameters and their\nrelationships, checked by the processor before instantiation, which is\nnot possible with a string-substitution, token-substitution, or macro\nsystem."
+ },
+ {
+ "user": "urbanjost",
+ "date": "2022-05-09 02:52:30+00:00",
+ "text": "Thanks. Not totally convinced a standardized preprocessor could not be tightly bound with the processor and provide the same checks, but then it essentially might as well be part of the language, I suppose. Thanks for the clear explanation. Indeed, I can use a preprocessor on a non-Fortran program and certainly generate incorrect code with the preprocessor being completely unaware of that; but it also allows applying information conditionally using information the templating proposals do not include, such as conditional coding depending on system or processor type, and so on. So the need for a preprocessor is reduced but not eliminated. For templating alone that is a big advantage though. Since I use preprocessing for other reasons (generating documentation, conditional code selection, recording date and time of compilation, .... it seemed like \"well, let it do templating too, and keep the core language simpler\"; but your explanation drives home a major advantage for the current approaches. Thanks again, I really enjoyed that explanation."
+ },
+ {
+ "user": "klausler",
+ "date": "2022-05-09 15:10:06+00:00",
+ "text": "One of the goals of the current design effort is that there will be no syntax or semantic errors within an instantiated paramaterized module or template if there are no syntax or semantic errors in the parameterized module or template. This is enforced with adequate declarations of the parameters and their relationships, checked by the processor before instantiation, which is not possible with a string-substitution, token-substitution, or macro system.\n\nIf this is a goal, it is not possible to completely achieve it. Not all errors stem from interactions between actual parameters to instantiations of parameterized entities. I appreciate a desire to have better error messages than those that even good C++ compliers emit for errors in the semantics of template instantiations, but to insist that all errors can and will be detected and diagnosed prior to instantiation is not a feasible design goal."
+ },
+ {
+ "user": "certik",
+ "date": "2022-05-09 15:18:14+00:00",
+ "text": "but to insist that all errors can and will be detected and diagnosed prior to instantiation is not a feasible design goal.\n\nI can clarify the goals: the generics subgroup is currently going with templates with \"restrictions\" (called \"strong concepts\" in the C++ world). To understand the details what it means, you can read our comparison document here:\n\nhttps://github.com/j3-fortran/generics/blob/52a9152da03b044a109aea1f9c08b3118f5db384/theory/comparison/comparison.md\n\nIt explains exactly in what sense errors will be caught and when. In short, you can indeed catch all errors before instantiating, but obviously you can only do it at the instantiation site when you know the user types, and you check them against the \"restrictions / strong concepts\", and if they pass, then you can instantiate without errors. See the document above for the details, and the kinds of error messages you can expect (showing actual error messages in Rust, Haskell for strong concepts and C++ for weak concepts). Indeed, C++ cannot catch all errors prior to instantiation (it only supports \"weak concepts\"), but Haskell, Rust and Go catch all errors prior to instantiation (\"strong concepts\"), and that is the goal for Fortran also."
+ },
+ {
+ "user": "klausler",
+ "date": "2022-05-09 15:44:12+00:00",
+ "text": "Yes, thanks, I know about concepts, and have read the design.\nHaskell doesn't really have concepts -- its typeclass constraints are really not the same thing. Standard ML's functors and signatures are a much closer match to the idea.\nFortran mandates that a compiler enforce hundreds of constraints at compilation time. I guarantee you that I can write a test program that violates at least one of them in an instantiation without violating any concept on a template parameter."
+ },
+ {
+ "user": "certik",
+ "date": "2022-05-09 16:58:24+00:00",
+ "text": "@klausler I think you are onto something. What you are saying is that if you write a templated function that has an argument a of type T, which is a template with restrictions (concepts), then you use a inside the function in various constructs that the compiler is required to check, then it will be very hard or impossible to design the restrictions parts in such a way to catch all these \"checks\" without an instantiation?\nOk, here is an example:\nmodule swap_m\n implicit none\n private\n public :: swap_t\n\n template swap_t(T)\n private\n public :: swap\n\n type :: T\n end type\n\n interface swap\n module procedure swap_\n end interface\n contains\n subroutine swap_(x, y)\n type(T), intent(inout) :: x\n type(T) :: tmp\n\n tmp = x\n x = y\n y = tmp\n end subroutine\n end template\nend module\n\nHere the template T doesn't have any restrictions, in other words, you can't do much with it. The templated function swap assigns it (swaps it). Possibly the assignment operation should be specified in the restrictions for T. Can you show me an example of some more complicated function that uses T, that violates at least one of the Fortran constraints in an instantiation (without violating the \"concept/requirement\")?"
+ },
+ {
+ "user": "klausler",
+ "date": "2022-05-09 17:27:08+00:00",
+ "text": "Sure. Write a template subprogram that abstracts the kind of a REAL argument. In the subprogram, use the kind to deduce the next kind of REAL with higher precision -- e.g., given default real, determine double precision -- and declare a local variable with that kind. You won't be able to instantiate this subprogram for the kind of REAL with the most precision available in the implementation, only for those with less than the maximum. Perhaps you can devise a way for the programmer to encode a restriction on the kind of the template REAL kind, but detecting a failure to impose such a restriction would require instantiation."
+ },
+ {
+ "user": "certik",
+ "date": "2022-05-09 17:35:53+00:00",
+ "text": "So something like this:\nsubroutine bad_swap(x, y)\ntype(T), intent(inout) :: x\ntype(T) :: tmp\nreal(kind(x)+4) :: r\n...\ntmp = x\nx = y\ny = tmp\nend subroutine\nThe natural way in my mind how to make this work is that the compiler when compiling bad_swap to some intermediate representation would figure out the restriction on kind(x)+4 being a valid real kind (say either 4 or 8), and then it would require the user to specify this restriction (somehow) in the restriction for the template T. Whether this can be done in all cases I don't know, but these are the kinds of things the generics subgroup is trying to figure out."
+ },
+ {
+ "user": "wyphan",
+ "date": "2022-05-09 17:39:33+00:00",
+ "text": "I'm not sure whether `kind(x)+4` would be portable across all compilers.\nIIRC the last time I used Silverfrost FTN95 on Windows they use 1 and 2 for\nsingle and double precision, instead of the more common 4 and 8.\n\u2026\nOn Mon, May 9, 2022, 13:36 Ond\u0159ej \u010cert\u00edk ***@***.***> wrote:\n So something like this:\n\n subroutine bad_swap(x, y)\n type(T), intent(inout) :: x\n type(T) :: tmpreal(kind(x)+4) :: r\n ...\n tmp = x\n x = y\n y = tmpend subroutine\n\n The natural way in my mind how to make this work is that the compiler when\n compiling bad_swap to some intermediate representation would figure out\n the restriction on kind(x)+4 being a valid real kind (say either 4 or 8),\n and then it would require the user to specify this restriction (somehow) in\n the restriction for the template T. Whether this can be done in all cases\n I don't know, but these are the kinds of things the generics subgroup is\n trying to figure out.\n\n \u2014\n Reply to this email directly, view it on GitHub\n <#29 (comment)>,\n or unsubscribe\n \n .\n You are receiving this because you are subscribed to this thread.Message\n ID: ***@***.***>"
+ },
+ {
+ "user": "klausler",
+ "date": "2022-05-09 18:15:56+00:00",
+ "text": "Obviously that's unportable as written, but the issue remains even when the code is written in a portable manner -- say selected_real_kind(p=precision(x)+1).\nAnd don't focus on patching a single hole. The general problem is that the hundreds of compile-time constraints cannot all be checked without actually instantiating a templatized subprogram (or better, module, but those are infuriatingly excluded).\nI think this would become more obvious if J3 were to require a demonstrable prototype implementation before standardizing the feature."
+ },
+ {
+ "user": "certik",
+ "date": "2022-05-09 18:51:39+00:00",
+ "text": "The general problem is that the hundreds of compile-time constraints cannot all be checked without actually instantiating a templatized subprogram.\n\nI don't know if this is true. If it is true however, then we cannot do \"strong concepts\", we can only do \"weak concepts\", almost for the same reason C++ is doing \"weak concepts\". That would be quite a big change in direction, so we should have a solid answer to this.\nDo you have another example of such constraints that would be hard to check without instantiating? Why can Rust and Go do it, but not Fortran? (Or Haskell, although you said it's slightly different there --- I don't know Haskell much).\nIt seems there are constraints on kind, type and rank to consider. You are right that there are hundreds of potential compile-time constraints that the compiler must check. It seems to me the compiler would simply check every statement/expression/declaration in a templatized function against the restrictions/concepts.\n\nI think this would become more obvious if J3 were to require a demonstrable prototype implementation before standardizing the feature.\n\nYes! It should be an absolute requirement for all features. @everythingfunctional and I sat down two months ago in Santa Fe and started working on a prototype in LFortran (https://gitlab.com/lfortran/lfortran/-/merge_requests/1664), but I need to focus on compiling actual projects with LFortran before I can spend more time on this. However, you might be further along with Flang, so you should consider if you can create a prototype."
+ },
+ {
+ "user": "klausler",
+ "date": "2022-05-09 19:32:57+00:00",
+ "text": "Prototyping J3's designs is J3's job, not mine.\nConstraints that are obvious concerns for a \"no need to instantiate\" design include C712, C714, C715, C718, C732-C734, C736, C737, C740, C748, C758, C764, C784, C785, C788, C791, C792, C798, C799, C7103, C7111, and that's just from a quick pass over subclause 7. Also, detecting ambiguous generic interfaces in templatized subprograms (or derived types in them) can't be done until the interfaces that depend on template arguments are instantiated."
+ },
+ {
+ "user": "everythingfunctional",
+ "date": "2022-05-09 20:18:55+00:00",
+ "text": "Prototyping J3's designs is J3's job, not mine.\n\nNot that I disagree, but which compiler should they use for prototyping? And should they really be expected to do it without help from someone on that compiler's development team?\n\nIf this is a goal, it is not possible to completely achieve it.\n\nObviously the design of a single language feature can't prevent all possible bugs, but I think we can catch a lot of them. Catching any at time of processing a template is better than waiting till instantiation (IMO). No reason to suggest that if we can't be perfect there's no reason to do it at all.\nAnd not that there's no use for trying to do something like this, but I think it might be better to not allow at first, until we can be more deliberate about it. For example, I think the template you'd want is something like the following\ntemplate foo(k)\n integer :: k\n require valid_but_not_largest_real_kind(k) ! We haven't even discussed this yet for value parameters\ncontains\n function bar(x) result(y)\n real(kind=k), intent(in) :: x\n real(kind=k) :: y\n\n integer, parameter :: wp = selected_real_kind(p=precision(x)+1)\n real(kind=wp) :: tmp\n ! now we can do the math with higher precision\n end function\nend template\nWe haven't thought about how we could specify restrictions on the values of template parameters, but I think before we allow their use in a context where that value matters to whether the code will even compile, we should think about that."
+ },
+ {
+ "user": "vansnyder",
+ "date": "2022-05-09 22:00:40+00:00",
+ "text": "On Mon, 2022-05-09 at 08:18 -0700, Ond\u0159ej \u010cert\u00edk wrote:\n > but to insist that all errors can and will be detected and\n > diagnosed prior to instantiation is not a feasible design goal.\n I can clarify the goals: the generics subgroup is currently going\n with templates with \"restrictions\" (called \"strong concepts\" in the\n C++ world). To understand the details what it means, you can read our\n comparison document here:\n * https://github.com/j3-\n fortran/generics/blob/52a9152da03b044a109aea1f9c08b3118f5db384/theor\n y/comparison/comparison.md\n It explains exactly in what sense errors will be caught and when. In\n short, you can indeed catch all errors before instantiating, but\n obviously you can only do it at the instantiation site when you know\n the user types, and you check them against the \"restrictions / strong\n concepts\", and if they pass, then you can instantiate without errors.\n See the document above for the details, and the kinds of error\n messages you can expect (showing actual error messages in Rust,\n Haskell for strong concepts and C++ for weak concepts).\nThe important thing is that there will be no mysterious errors\nannounced WITHIN an instance when it is instantiated, if the template\nis syntactically and semantically correct.\n\u2026\n \u2014\n Reply to this email directly, view it on GitHub, or unsubscribe.\n You are receiving this because you commented.Message ID: "
+ },
+ {
+ "user": "certik",
+ "date": "2022-05-09 22:13:05+00:00",
+ "text": "Constraints that are obvious concerns for a \"no need to instantiate\" design include C712, C714, C715, C718, C732-C734, C736, C737, C740, C748, C758, C764, C784, C785, C788, C791, C792, C798, C799, C7103, C7111\n\nYes, all these would have to be checked.\n\nPrototyping J3's designs is J3's job, not mine.\n\nWe are all volunteers on J3. If you wanted to help us out, I would really appreciate it. :)"
+ },
+ {
+ "user": "klausler",
+ "date": "2022-05-09 22:29:07+00:00",
+ "text": "Constraints that are obvious concerns for a \"no need to instantiate\" design include C712, C714, C715, C718, C732-C734, C736, C737, C740, C748, C758, C764, C784, C785, C788, C791, C792, C798, C799, C7103, C7111\n\nYes, all these would have to be checked.\n\nAnd each of them is a constraint for which I could write a template example that can't be checked prior to instantiation against a specific set of template arguments.\n\n\nPrototyping J3's designs is J3's job, not mine.\n\nWe are all volunteers on J3. If you wanted to help us out, I would really appreciate it. :)\n\nI did try with DO CONCURRENT and was met with nothing but denial that there's even a problem. No thanks."
+ },
+ {
+ "user": "wyphan",
+ "date": "2022-05-09 22:47:47+00:00",
+ "text": "I did try with DO CONCURRENT\n\nNot trying to hijack this thread, but I submitted a GSoC proposal for DO CONCURRENT offloading in GFortran so am genuinely curious. Is it this one? #62"
+ },
+ {
+ "user": "klausler",
+ "date": "2022-05-09 22:54:31+00:00",
+ "text": "I did try with DO CONCURRENT\n\nNot trying to hijack this thread, but I submitted a GSoC proposal for DO CONCURRENT offloading in GFortran so am genuinely curious. Is it this one? #62\n\nYes. DO CONCURRENT admits non-parallelizable usage that can't be detected at compilation time, and there's no standard way to promise to the compiler than a given DO CONCURRENT construct is free of such usage."
+ },
+ {
+ "user": "certik",
+ "date": "2022-05-10 01:03:37+00:00",
+ "text": "Yes. DO CONCURRENT admits non-parallelizable usage that can't be detected at compilation time, and there's no standard way to promise to the compiler than a given DO CONCURRENT construct is free of such usage.\n\nI think that definitely would be a problem problem. I think the way forward is to implement an extension (say in Flang) that allows the user to promise to the compiler that a given construct is parallelizable, and then when we submit a paper with a prototype, I think we have a good chance to fix this."
+ },
+ {
+ "user": "klausler",
+ "date": "2022-05-10 21:06:59+00:00",
+ "text": "Here are a couple examples of templatized Fortran that I believe demonstrate violations that would require instantiation to detect. These are obviously not tested and the syntax is almost certainly incorrect.\n template tmplt(ty)\n type :: ty; end type\n contains\n subroutine subr(x)\n type(ty), intent(in) :: x\n generic :: gen => inner1, inner2\n call gen(x) ! ambiguous if instantiated with ty = real\n contains\n subroutine inner1(x)\n type(ty), intent(in) :: x\n end subroutine\n subroutine inner2(x)\n real, intent(in) :: x\n end subroutine\n end subroutine\n end template\n\n template tmplt(ty)\n type :: ty; end type\n contains\n subroutine sub(x)\n type, extends(ty) :: ext ! error if ty is not a derived type\n real :: comp ! error if ty already has a component named \"comp\"\n end type\n type(ty) :: v\n v = ty() ! error if ty has type parameters or components without defaults\n end subroutine\n end template"
+ },
+ {
+ "user": "everythingfunctional",
+ "date": "2022-05-10 22:02:21+00:00",
+ "text": "template tmplt(ty)\n type :: ty; end type\n contains\n subroutine sub(x)\n type, extends(ty) :: ext ! error if ty is not a derived type\n real :: comp ! error if ty already has a component named \"comp\"\n end type\n type(ty) :: v\n v = ty() ! error if ty has type parameters or components without defaults\n end subroutine\n end template\n\n\nI believe we have, or intend to, prohibit extending from template type parameters, at least for now. Also, we don't assume the accessibility of an intrinsic structure, let alone user defined, constructor for a template type parameter, so that usage isn't allowed either.\nThe other example is something I'm not sure we've considered very strongly yet. We may desire preventing use of template type parameters as arguments in generic interfaces with multiple actual procedures. Not quite sure if that has all the right implications. This is something worth thinking about."
+ },
+ {
+ "user": "vansnyder",
+ "date": "2022-05-10 22:02:53+00:00",
+ "text": "On Tue, 2022-05-10 at 14:07 -0700, Peter Klausler wrote:\n Here are a couple examples of templatized Fortran that I believe\n demonstrate violations that would require instantiation to detect.\n These are obviously not tested and the syntax is almost certainly\n incorrect.\nEven if the goal of preventing any constraint violations in an instance\nof a template cannot be achieved, eliminating the vast majority of\npossible situations using a parameterized module or template system is\nbetter than catching none using a string-substitution preprocessor or a\nbuilt-in token-substitution macro system.\n\u2026\n template tmplt(ty)\n type :: ty; end type\n contains\n subroutine subr(x)\n type(ty), intent(in) :: x\n generic :: gen => inner1, inner2\n call gen(x) ! ambiguous if instantiated with ty = real\n contains\n subroutine inner1(x)\n type(ty), intent(in) :: x\n end subroutine\n subroutine inner2(x)\n real, intent(in) :: x\n end subroutine\n end subroutine\n end template\n template tmplt(ty)\n type :: ty; end type\n contains\n subroutine sub(x)\n type, extends(ty) :: ext ! error if ty is not a derived type\n real :: comp ! error if ty already has a component named \"comp\"\n end type\n type(ty) :: v\n v = ty() ! error if ty has type parameters or components without defaults\n end subroutine\n end template\n \u2014\n Reply to this email directly, view it on GitHub, or unsubscribe.\n You are receiving this because you commented.Message ID: "
+ },
+ {
+ "user": "certik",
+ "date": "2022-05-10 22:02:59+00:00",
+ "text": "Thanks Peter!\nThe first one is similar to a template specialization. I can see multiple ways forward:\n\nDo not allow generic procedures if one of the arguments is a template; and possibly create some new separate syntax for template specialization\nIf the template ty = real, use the inner2 function, as in a template specialization\n\nIn the second example, the way I understand it, it would not compile, with an error message that you are using extends(ty) on a type ty that does not allow that. It is not written in the requirements part. To fix it, you have to \"allow\" such operations explicitly, something like this:\n template tmplt(ty)\n type :: ty; end type\n allow_extend(ty)\n type_params_and_components_have_defaults(ty)\n contains\n subroutine sub(x)\n type, extends(ty) :: ext ! allowed in the requirements section\n real :: comp ! -- multiple options here, see below\n end type\n type(ty) :: v\n v = ty() ! now works, as it is allowed in the requirements section\n end subroutine\n end template\nThe type :: ty; end type requirements says that there is a generic type ty, but you can't do much with it. You have to explicitly allow all operations that you want to do with it. I showed above how it could be done for the main two operations. Regarding the comp component, I know there was some discussion about components of templates and I can't remember right now if they decided to allow them or not. If it is not allowed, then you simply get a compiler error above. If it is allowed, then one approach is that you need to specify them in the parent template:\ntype :: ty\n real :: comp2\nend type\n\nThat is the one and only component that is allowed (in the user type that will get passed in at call site), and it must be called comp2. Then in the extended type ext you know that comp2 is in the parent class and that comp is not there and thus you can declare it.\nMy understanding of the general approach is that initially you get compiler error for most of the usages above (and indeed you can always determine ahead of time if a given user type can be instantiated or not). Then we can add more ways to specify \"requirements\", and then you can use the template in more cases, such as your examples above, while keeping the property that if the user type satisfies the requirements, then it can always be instantiated."
+ },
+ {
+ "user": "klausler",
+ "date": "2022-05-11 01:08:50+00:00",
+ "text": "Even if the goal of preventing any constraint violations in an instance of a template cannot be achieved, eliminating the vast majority of possible situations using a parameterized module or template system is better than catching none using a string-substitution preprocessor or a built-in token-substitution macro system.\n\nIt's a shame about the parameterized modules not being followed up on, though. Even if modules were parameterizable only by other modules (not types or anything else), you'd have an effective and highly composable solution, and the implementation would be easy to prototype and demonstrate."
}
]
},
@@ -15330,6 +16009,11 @@
"user": "aradi",
"date": "2021-11-26 07:10:08+00:00",
"text": "@sblionel Thanks for the feedback. It is promising, that at least there seems to be consensus, that this should be considered in some form. \ud83d\ude04"
+ },
+ {
+ "user": "klausler",
+ "date": "2022-05-18 19:38:31+00:00",
+ "text": "For maximum safety and for best alias analysis, I believe now that additional attributes should be available for both data pointers and for data targets.\nAt present, a data pointer can be associated with any compatibly-typed object on the same image with the TARGET attribute. I suggest that:\n\nThere be a means to restrict an associated data pointer's pointed-to object from appearing in a definition context. Call this a read-only pointer here. This is basically what we've been discussing so far, but not limited to a dummy argument.\nThere be a means to restrict a TARGET object so that only a read-only pointer may be associated with it. Call this a read-only TARGET.\nThere be a means to further restrict a read-only pointer to be associated only with read-only targets. Call this a safe read-only pointer.\n\nThe distinction between an \"unsafe\" read-only pointer and a safe read-only pointer is that alias analysis must assume that the pointed-to object of an \"unsafe\" read-only pointer might be modified by way of a non-read-only pointer. But a safe read-only pointer's pointed-to object cannot be modified by way of a non-read-only pointer. It is nearly as \"optimizable\" as an INTENT(IN) dummy argument.\nA read-only pointer (safe or not) would be allowed to be associated with non-local data in a PURE procedure, including the case of default pointer component initialization.\n real :: x, y, p, q, s\n target :: x\n target, readonly :: y\n pointer :: p\n pointer, readonly :: q\n pointer, readonly, safe :: s\n\n p => x ! ok\n p => y ! BAD\n p => q ! BAD\n p => s ! BAD\n q => x ! ok\n q => y ! ok\n q => p ! ok\n q => s | ok\n s => x ! BAD\n s => y ! ok\n s => p ! BAD\n s => q ! BAD\n x = 1. ! ok\n y = 1. ! ok\n p = 1. ! ok\n q = 1. ! BAD\n s = 1. ! BAD\n\nIn short, a \"safe\" read-only pointer is an alias only for objects that are read-only targets. An \"unsafe\" read-only pointer can be associated with any target."
}
]
},
@@ -15578,6 +16262,11 @@
"user": "klausler",
"date": "2019-11-05 00:49:23+00:00",
"text": "I'm not sure that Fortran needs an unsigned type so much as it actually needs some unsigned operations and relations. Be wary of simply copying-and-pasting C's unsigned types into Fortran, for they are full of pitfalls that shouldn't be perpetuated, mostly around their interactions with signed types and conversions."
+ },
+ {
+ "user": "8bitmachine",
+ "date": "2022-05-22 14:41:42+00:00",
+ "text": "I too would like unsigned integers. Mainly because of bitmap, image data, and other binary coding or data.\nI do not see that this should be a problem as it would be a new data type (not an operation, we do need a type) that existing programs would continue to default to signed integers.\nMy work around for simplicity (not elegance) is to use 16 bit integers and save the data as is in 8 bits when needed. I find that more convenient than having to check 8 bits all the time if only unsigned is needed."
}
]
},
@@ -16078,6 +16767,11 @@
"user": "FortranFan",
"date": "2020-10-03 03:25:31+00:00",
"text": "@wclodius2 wrote Oct. 1, 2020\n\nThere seems to have been a consensus that there should be a poll/vote on the preferred syntax. As there has been a significant pause in postings on this issue, I think it is an appropriate to summarize our current syntactic options to prompt more suggestions for options. There are four orthogonal choices in the syntax:\nWhat word to use as the keyword\n..\n\nIf there are folks who aren't enthused by any of the keywords thus far, here's another one that can perhaps considered for the poll? PREFIX:\nuse, prefix(ut) :: utils, only : savetxt\n..\ncall utXsavetxt(..)"
+ },
+ {
+ "user": "aradi",
+ "date": "2022-05-09 08:01:39+00:00",
+ "text": "I think, the idea with prefix is a really nice one. But, maybe prefixed (as adjective) is more aligned with what we have already, e.g.\nuse, intrinsic, prefixed :: iso_fortran_env ! if entire module name is used as prefix\nuse, intrinsic, prefixed(ife) :: iso_fortran_env ! if specified prefix is used"
}
]
}