Re: Portable bitwise operations library (was Re: Portability Considerations)

[Benjamin Kowarsch]

I am sorry but as a user of a library, I want my convenience to rank above the developer's preferences and convenience. As a user, I want to see the interfaces without any clutter. Thus I want those interfaces in one place without anything else being visible to me. And if I need to dig any deeper into it, looking at how it is implemented, then I want to see the implementations without any clutter as well, thus again in one place without anything else being visible. I do not care whether the developer of the library finds this representation practical or palatable to themselves. It is most practical for the library user. And thus, I simply demand it that way. Besides, even as a developer, I am also a user of the library, and using the library is the ultimate reason why I develop it. And thus, my requirements as a user have priority over my considerations as a developer.

regards

benjamin

On Sun, 24 Mar 2024 at 16:08, Fischlin Andreas <andreas.fischlin@env.ethz.ch> wrote:

Hi all,

We (Wirth & colleagues) never separated those files as they always differ in the extensions, .DEF, .MOD, .SBM, .OBM, .RFM (e.g. as produced by the MacMETH compiler https://sysecol.ethz.ch/ramses/ramses-software-layers/macmeth-m2.html) and in principle a module is a unit for which files belong together, isn’t it? ;-)

We used folders to separate the various libraries. E.g. ‘DMLibDev' for the "Dialog Machine" (DM https://sysecol.ethz.ch/ramses/ramses-software-layers/dialog-machine-dm.html). The latter was subdivided into two layers, i.e. subfolder ‘Base' for the modules used by the DM itself and that contained platform dependent code) and the subfolder ‘High' for the higher layer, i.e. all modules that were available and visible to the user of the DM. 

https://www.sysecol2.ethz.ch/RAMSES/Objects/RMSModsByLayer.html gives an overview over all RAMSES modules.

Complex libraries such as the ‘ScienceLib' (Science Library, https://www.sysecol2.ethz.ch/SimSoftware/RAMSES/ScienceLib.html) we used further subdivisions according to functional units. E.g. the subfolder ‘LgMatrices' https://www.sysecol2.ethz.ch/RAMSES/Objects/SciLib/LgMatrices.html#LgMatrices within ‘SciLibDev' holds all modules belonging to the functional unit “LgMatrices” (Long Matrices) or subfolder ‘SunPath’ (solar paths calculations) or 'MapViewer’ (GIS like functions, https://www.sysecol2.ethz.ch/RAMSES/Objects/SciLib/MapViewer.html#MapViewer). 

Within any such folders we always had further subfolders such as ‘Tests' and ‘DevAux’. ‘Tests’ contains all test program modules with any required input data and expected test results. ‘DevAux' contains all make lists/scripts and other project specific informations of interest to the developer.

Andreas

ETH Zurich

Prof. em. Dr. Andreas Fischlin

Systems Ecology - Institute of Biogeochemistry and Pollutant Dynamics

CHN E 24

Universitaetstrasse 16

8092 Zurich

SWITZERLAND

andreas.fischlin@env.ethz.ch

www.sysecol.ethz.ch/people/andreas.fischlin.html

+41 44 633-6090 phone

+41 79 595-4050 mobile

             Make it as simple as possible, but distrust it!

________________________________________________________________________

On 23 Mar 2024, at 00:11, Benjamin Kowarsch <trijezdci@gmail.com> wrote:

Actually, I use "imp" for the subdirs that contain the .mod files, not "mod".

On Sat, 23 Mar 2024 at 08:08, Benjamin Kowarsch <trijezdci@gmail.com> wrote:

On Sat, 23 Mar 2024 at 07:40, Gaius Mulley wrote:

john o goyo writes:

> [~/opt/Alice]=> gcc-git -c -fiso -I. CardBitOps.mod
> <built-in>: error: the file containing the definition module cannot be found
>
> Gaius, any insight here?

yes gm2 is trying to create a definition module symbol and cannot find
the CardBitOps.def file, and uses the builtin location (previously it
would give a misleading error message location in the implementation
module source file).  Perhaps the error message could be improved
though?

 I also separate .def and .mod files in my projects.

However, I put the interfaces in the top levels of each source tree directory and the implementations in their respective imp subdirectories

/src

   /... any library subdirs ...

   /mod

      foo.mod

      bar.mod

   foo.def

   bar.def

The reason why I believe that the interfaces belong in to the top level is that source code should always be presented for the ease of use and convenience of the reader, not for the convenience of the author. For the user/reader, the most important part of a library are the interfaces. They may never even look at the implementations, but they will need the interfaces.

Therefore, if the two are separated to reduce clutter which also makes the library easier to use for readers, then the interfaces should go in to the top level, and the implementations into a subdirectory.

Perhaps, GM2 could accommodate this kind of source tree structure with a simple compiler switch.

regards

benjamin