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

Design of FoOtS #1

Open
paul-martin3 opened this issue Nov 20, 2015 · 2 comments
Open

Design of FoOtS #1

paul-martin3 opened this issue Nov 20, 2015 · 2 comments

Comments

@paul-martin3
Copy link

Dear Mr. Zaghi,

I discovered with great interest your project "FoOtS" on GitHub :
https://github.com/Fortran-FOSS-Programmers/FoOtS
Thank you for your work on this project and on your other Open Source Projects.

I am not currently able to contribute to your project, but please find below some remarks whose intention is to be helpful.

  1. How does your project compare with the modFileSys project ?
    https://bitbucket.org/dftbplus/modfilesys
    https://aradi.bitbucket.org/modfilesys/

  2. Will your project be usable under Windows ?
    For a sample, in Fortran, see for example :
    https://groups.google.com/forum/#!msg/comp.lang.fortran/bU02_Q3ZB7s/Xy8F0U5mvckJ

  3. Will your project will portable on 32-bits and 64-bits operating systems ?
    Under POSIX, the members of the "dirent" structure seemingly differ depending on whether the system is 32 or 64 bits. See for example :
    https://gcc.gnu.org/ml/fortran/2007-08/msg00167.html
    https://gcc.gnu.org/ml/fortran/2007-08/msg00175.html

    On Windows, STDCALL calling convention should be required 32-bits version.

  4. Most importantly : instead of defining your own Fortran interface (e.g. the names of procedures), did you consider the possibility to mold your interface on one of the existing libraries ?

    My preference would go to the Boost Filesystem Library project :
    http://www.boost.org/doc/libs/1_33_1/libs/filesystem/doc/design.htm
    http://www.boost.org/doc/libs/1_33_1/libs/filesystem/doc/index.htm
    http://www.boost.org/doc/libs/1_33_1/libs/filesystem/doc/portability_guide.htm

    Another possibility could be the Fortran POSIX interface :
    http://standards.ieee.org/findstds/standard/1003.9-1992.html
    IEEE 1003.9-1992 was withdrawn, but some compilers (for example ifort) include access to POSIX functions :
    https://software.intel.com/en-us/node/580295
    See also the NAG compiler :
    http://www.nag.co.uk/nagware/np/r60_doc/f90_unix_dir.html
    http://www.nag.co.uk/nagware/np/r60_doc/f90_unix_dirent.html

    Another interface (POSIX and Windows) is defined by the functions group "Files Utilities" from the glib library :
    https://developer.gnome.org/glib/stable/glib-File-Utilities.html
    These functions handle file names with any Unicode characters in them on Windows without having to use ifdefs and the wide character API in the application code.

Yours faithfully,

Paul Martin

@szaghi
Copy link
Member

szaghi commented Nov 20, 2015

Dear Paul,

Firstly I would like to thank you for this great contribution, it is very welcome!

I am going to try to replay to your questions, but I doubt I will success...

Some preliminaries:

  • This project has started from a suggestion of mine, but the project itself cannot be considered mine: it is a collaborative effort of our group; we are Fortraners enthusiast of Fortran and we like to share our work with the FOSS community (for ethic and efficiency reasons); we are a very open group and we will be very happy if you like to join us; to be more clear, we consider a valuable help also the contributions like the one you have just done here, so we consider our members not only who directly writes Fortran codes, but also who contributes with great ideas like yours;
  • this project is not yet started: I decided to favorite FOODIE before all others, so FoOts is currently just an idea, all design specifications must still be done.

Now I am trying to replay to your questions:

How does your project compare with the modFileSys project ?

I do not know this project. I will study it soon. At a first view it seems very good, thus maybe FoOts will never born... I do not like to reinvent the wheel :-) Thank you very much to focus us to it!

Will your project be usable under Windows ?

My effort will be devoted to only GNU Linux, but I hope that other members will test FoOts on other architectures.

Will your project will portable on 32-bits and 64-bits operating systems ?

I am confident to support both. If FoOts will born it will be based on a robust/diffused/mature C back-end, meaning that the underling C library should be very portable. Fortran has a lot of wonderful compilers able to port codes on a wide OS jungle (32bits, 64bits, RISC, CISC, ARM...) so when (if) we chose the C library we should take into account its portability.

Most importantly : instead of defining your own Fortran interface (e.g. the names of procedures), did you consider the possibility to mold your interface on one of the existing libraries ?

The FoOts API is far from being defined... I have no idea of which approach we would like to take. Surely, if the APIs you highlighted (I know something about boost) are good for us we will be happy to adopt them. However, Fortran poor people often think differently from C/C++ rich ones, so I will not surprised nor irritated if we finally design a different (more Fortranish) API.

Please, continue to support us with such a great contribution, it is very appreciated!

Stefano

P.S. I am going to study modFileSys, maybe FoOts will die before it will born.

@szaghi
Copy link
Member

szaghi commented Nov 20, 2015

@paul-martin3

Under POSIX, the members of the "dirent" structure seemingly differ depending on whether the system is 32 or 64 bits.

I have quickly read the thread you mentioned. Is this portability issue strictly related to the libc, or is it commonly diffused to other C libraries (boost and others)?

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