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

Installation instructions #1

Open
awvwgk opened this issue Apr 16, 2023 · 2 comments
Open

Installation instructions #1

awvwgk opened this issue Apr 16, 2023 · 2 comments

Comments

@awvwgk
Copy link
Contributor

awvwgk commented Apr 16, 2023

Thanks for sharing this project. Is there a preferred way to use this module in other Fortran projects (other than copying the whole file)?

I'm maintaining some docs on how to create adapters between existing datetime implementation and serialization formats (TOML) in toml-f/toml-f#101, if there is interest I can add this implementation there as well. To make a useful recipe I try to closely follow the preferred installation instructions of the respective implementation.

@patti-favaron
Copy link
Owner

Thanks Sebastian!

Surely, the possibility to use the 'datetime' in a wider context is decidedly attractive, and my answer is a resounding "yes"!

As you can see from my own code I'm not a computer scientist, and rather a Fortran end user (if you want, you could figure me as a sort-of university professor not far from retirement ;) - that's not my exact qualification, but a close approximation). So, would be glad if you explain me in simple words what you desire, when writing "installation instructions"... :) Actually, 'datetime' is used within a larger project, composed by various sources all compiled together directly with quite a brutal makefile. But packaging as a library would not that a problem for me. Just, I'm extremely unfamiliar with the conventions used today. So please, be a bit patient...

(In "my old times", executables were compiled directly from a lump of all sources involved...)

"And".

I checked your 'toml_datetime' implementation, and wondered whether it could be of some interest whether, instead of quoting the 'datetime' code as it is, it could be productive and interesting to extend the existing 'toml_datetime' with:

  • An improved date and time comparison allowing to check not only whether two time stamps are equal, but also which one is larger.
  • Conversion of 'toml_datetime' values back and forth to some convenient "epoch".

This could make my 'datetime' obsolete, and 'toml_datetime' apt to "my own" use cases. (Besides, a Fortran TOML library is very useful for my work! However, I'm quite egoistical in this regard, and not considering whether the "improvement" I'm imagining really is in your view. :) So, don't hesitate to say me "No!!" in advance.)

If you agree, I could provide some work and send you a pull request with the proposed additions. In these days I'm very busy, but think could find a (non-time-stamped) slice...

Thanks, regards, and serene days to come, never devoid of occasions of marvel!
Patrizia

@awvwgk
Copy link
Contributor Author

awvwgk commented Apr 23, 2023

As you can see from my own code I'm not a computer scientist, and rather a Fortran end user (if you want, you could figure me as a sort-of university professor not far from retirement ;) - that's not my exact qualification, but a close approximation).

Well, I'm not a computer scientist either. Fortunately, that has not stopped anyone yet from being active in the open source Fortran community. Everyone is welcome.

So, would be glad if you explain me in simple words what you desire, when writing "installation instructions"... :) Actually, 'datetime' is used within a larger project, composed by various sources all compiled together directly with quite a brutal makefile. But packaging as a library would not that a problem for me. Just, I'm extremely unfamiliar with the conventions used today. So please, be a bit patient...

I'm looking for information how this project is usually used in larger projects, so this is already helpful. TOML Fortran offers many ways to be used in other projects (via fpm, cmake, or meson) and I want to be closest to how the library is usually used. In this case it seems to be make (not a big fan, but a possibility).

I checked your 'toml_datetime' implementation, and wondered whether it could be of some interest whether, instead of quoting the 'datetime' code as it is, it could be productive and interesting to extend the existing 'toml_datetime' with:

* An improved date and time comparison allowing to check not only whether two time stamps are equal, but also which one is larger.

* Conversion of 'toml_datetime' values back and forth to some convenient "epoch".

This could make my 'datetime' obsolete, and 'toml_datetime' apt to "my own" use cases. (Besides, a Fortran TOML library is very useful for my work! However, I'm quite egoistical in this regard, and not considering whether the "improvement" I'm imagining really is in your view. :) So, don't hesitate to say me "No!!" in advance.)

I want to keep the datetime implementation in TOML Fortran as lean as possible, such that it only contains the necessary information for storing the datetime. Otherwise there is a risk of creating another imperfect datetime implementation in TOML Fortran and somebody still has to write their own procedures to augment the functionality. So my strategy is to rather provide instructions to connect TOML Fortran with an existing datetime library which can develop functionality as needed for datetime handling independently from the IO library.

One solution could be to agree on a datetime implementation in the standard library.

If you agree, I could provide some work and send you a pull request with the proposed additions. In these days I'm very busy, but think could find a (non-time-stamped) slice...

I proposed a patch in #2.

Thanks, regards, and serene days to come, never devoid of occasions of marvel!

Thanks!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants