Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Feedback] The inconsistency of stdlib internal modules about access keyword of opening files: stdlib_io/open, stdlib_logger #465

Open
zoziha opened this issue Jul 15, 2021 · 4 comments
Labels
bug Something isn't working specification Discussion and iteration over the API topic: IO Common input/output related features

Comments

@zoziha
Copy link
Contributor

zoziha commented Jul 15, 2021

Describe the issue

I tried to use the stdlib_logger module, and used the open function in stdlib_io, and found that there was an adaptability problem. The root cause was that stdlib_logger required to open the log file as access=sequential, while the stdlib_io:open function defaulted to open the file as access=stream , I was wondering if this is a problem and how to solve this problem?

program test_io_logger

    use stdlib_logger, only: global_logger
    use stdlib_io, only: open
    implicit none
    integer :: log_unit

    log_unit = open("log.txt","w+")
    call global_logger%add_log_unit(log_unit)
        !! ERROR STOP unit in stdlib_logger % set_log_unit is not "sequential".

end program test_io_logger

Links

@zoziha zoziha added the bug Something isn't working label Jul 15, 2021
@zoziha
Copy link
Contributor Author

zoziha commented Jul 15, 2021

Maybe I think open as a more basic function, can you consider leaving a loose possibility for access in open function? access can be included by the mode argument, and access=stream can be used by default.

character(*), intent(in), optional :: mode

@ivan-pi
Copy link
Member

ivan-pi commented Jul 15, 2021

Thanks @zoziha for bringing this inconsistency up.

I believe that @jvdp1 as author of the stdlib_io and reviewer of the logger module is the best person to comment on this issue.

@ivan-pi ivan-pi added the specification Discussion and iteration over the API label Jul 15, 2021
@jvdp1
Copy link
Member

jvdp1 commented Jul 15, 2021

Thank you for reporting this incompatibilit. Please see the PR #71 and its code that introduced open() in stdlib. With this code, the access was sequential. In #71 there was already a lot of discussions about this.
The specs of open() specify that all files are streamed files.

I don't recall when the change of access was implemented. However, using mode argument is a good idea IMO to deal with that. Do you have any suggestions?

Another possibiliy would change the logger to accept streamed files, if possible (@wclodius2).

@zoziha zoziha changed the title [Feedback] The inconsistency of stdlib internal modules about access keyword of opening files: stdlib_io_open, stdlib_logger [Feedback] The inconsistency of stdlib internal modules about access keyword of opening files: stdlib_io/open, stdlib_logger Aug 20, 2021
@zoziha
Copy link
Contributor Author

zoziha commented Sep 9, 2021

select case (mode_(4:4))
    case('u'); access_ = 'sequential'
    case('d'); access_ = 'direct'
    case('s'); access_ = 'stream'
end select

I tried to parse the access into mode of the open function, and the default mode is now rts. I submitted my branch here.
I refer to the open function of python: open
image
Among them, python abandoned u (universal) mode, which is sequential access in fortran.
But I think three types of access (sequential, direct, stream) are supported in the fortran syntax, so keeping stream as the default and adding support for sequential and direct is currently acceptable.

@awvwgk awvwgk added the topic: IO Common input/output related features label Sep 18, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working specification Discussion and iteration over the API topic: IO Common input/output related features
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants