add system module

[scivision]

There are a number of capabilities it would be useful to bring from
cstdlib and STL. This is an initial demonstration, replacing
the non-cross-compiler sleep() with a standard implementation that
works across compilers and operating systems, with millisecond integer
input.
For example, Intel compilers can hang at runtime if call sleep() is used without use ifport. This PR technique doesn't suffer from that issue across operating systems and compilers.

There are a number of other useful functions that can be implemented like this, including resolving absolute filenames and expanding ~ to user home path

Adding CI for Windows brought an interesting corner case to light--runtime segfaults on Windows. I don't see these on my Windows Gfortran PC. This is a common type of corner case, tricky/shaky tests using uncommon features where it isn't feasible to whitelist/blacklist systems. A future PR would do a "check_fortran_source_run()" on a snippet of code to ensure the program can run instead of nuisance failure.

[certik]

Thanks @scivision for pushing this. Can you create another PR where you get the Windows build working? I am working on reviewing #51 now, let's get that one in first.

I like what you are trying to do, and let's get it polished an in.

[scivision]

Yes basically the CMake needs #51 to get working where I could put the necessary Windows stuff if. For these Windows tests, it will require CMake >= 3.14 to do the workaround. I added the feature to CMake 3.14 that makes it possible.

[certik]

@scivision in that case we can depend on CMake 3.14, which I know @zbeekman would be very happy about. :)

[zbeekman]

@scivision in that case we can depend on CMake 3.14, which I know @zbeekman would be very happy about. :)

I told you there be bugs... all's well that ends well.

[certik]

I would strongly suggest to split the unrelated and approved parts of this PR into separate PRs, so that we can merge them:

• The Windows CI tests
• The CMake changes
• The action argument

The actual system module will require some discussion about the API, before we can merge.

[milancurcic]

I agree with @certik to use smaller and more focused PRs. We can narrow down the workflow details together in #5.

Reviewed here only the system sleep additions. I think they're in scope for stdlib and useful. We can continue discussing and working out the details here, but for any additions to the API, please open an issue and discuss there before moving forward to a PR.

[zbeekman]

I would strongly suggest to split the unrelated and approved parts of this PR into separate PRs, so that we can merge them:

I'll have a go at this in a moment.

[certik]

@scivision most of your other unrelated improvements in this PR have been merged into master. Do you want to submit a clean PR with just the system module?

[certik]

That looks good to me.

[certik]

Overall it looks good. I left some minor comments.

[certik]

@scivision I would like to merge your system module, but when you bundle unrelated CI changes, I don't want to just merge it, because some people might disagree with the CI changes, or want to further discuss them.

Do you think it would be please possible to not bundle unrelated changes in a single PR?

Let's split this PR, so that we can merge the system module, which I think is a great start and exactly as you say, it would allow us to use this approach for other things.

[certik]

As the PR stands right now, I think I am ok with merging it. It shows how to use system API from Fortran, and we can use it for all the other things that we want to do for the os module.

@zbeekman, @milancurcic if you could both also review it before we merge, that would be great.

[zbeekman]

I'd love to see module and program scopes indendented, and single new-lines at EOF, but these are nits and will be irrelevant if/when auto-formatting is implemented. Otherwise, looks good to me.

[certik]

Let's not worry about formatting too much in individual PRs --- rather let's figure out how to do this automatically for all source files.

[certik]

@zbeekman thanks for the review!

@milancurcic can you please review this also?

For new functionality, I want several independent reviews, to prevent putting things in that might not be well designed or too bloated.

[certik]

@milancurcic can you please review this also?

@scivision sorry for the delay.

[milancurcic]

Great! Thank you @scivision, and sorry for the delay with me reviewing this. I missed the notifications.

[urbanjost]

Are we discussing something like an interface to C system routines like often proposed for POSIX interfaces? I use routines like that a lot but cooked my own (not sure how many platforms they would work on, but worked on all the ones I needed) in
M_system. A lot of compilers supported some variant of a "POSIX" interface, but in different ways, which made it highly non-portable. Never quite sure why this did not become part of the standard, especially when "POSIX" was a hot topic. The only one I remember doing a full PXF interface was Cray.

PS: FUNIX shows a lot of simple examples that use the interface. Shows how just the addition of a few things like those being proposed in stdlib make Fortran just as good if not better than most languages for creating basic utilities.

[nncarlson]

The NAG compiler comes with a collection of intrinsic f90_unix_* modules that implement a bunch of POSIX stuff. They should be examples to consider if we wanted to head in that direction with stdlib. The documentation for them is here.

[urbanjost]

Almost the same list as I have; which is a good sign it can be done relatively generically. Cray, Intel, and gfortran all have a lot of the same functionality as extensions, but all as proprietary extensions so not very portable. Probably others too. None are OOPs, which is interesting.