Currently I'm learning Fortran. I came across procedures
submodule (points) points_a
contains
module procedure point_dist
distance = sqrt((a%x - b%x)**2 + (a%y - b%y)**2)
end procedure point_dist
end submodule points_a
I am not sure if I can use an import statement inside the module procedure block?
Can anyone share an example program?
When it comes to the IMPORT statement, you have to ask yourself a question: am I using Fortran 2008 or Fortran 2018? Fortran 2018 significantly expanded this statement.
In Fortran 2008 the IMPORT statement makes available within an interface body entities that are defined outside that interface body (from the host scoping unit). In the question example there is no interface body and so a Fortran 2008 IMPORT statement is not allowed.
The Fortran 2008 form of the IMPORT statement is the form most commonly supported by compilers and tools.
Fortran 2018 allows the IMPORT statement to more fully control host association. We have the statements which look like
import
import host_entity
which are the same as in Fortran 2008. But we also have
import, only : host_entity
import, none
import, all
With these statements, we say what entities are host associated within the scoping block. import, only : ... gives a list of those host entities which are available. import, none says no entities from the host are accessible through host association (but may be by other means); import, all which makes all host entities accessible through host association (and these cannot be "shadowed" locally).
The Fortran 2018 IMPORT statement can be used in any scoping unit which has a host scoping unit. (This includes module procedures within a submodule, as in the question.)
At the moment, you are likely to see your compiler/tool telling you that IMPORT can appear only in interface bodies. Again, this is down to language level support.
Related
Coq is using a module system similar to OCaml. In OCaml, we can apply a function like Module_A.Module_B.Func and use Module_A.Module_B. to find the path to Func.
However, I cannot do similar things in Coq. For instance, if I just run Print Coq.Arith.Minus.minus_n_O. Coq reports Coq.Arith.Minus.minus_n_O is not a defined object.
I must first load the library and then can print the object. In the following case, it is successful.
From Coq Require Export Arith.Minus.
Print Coq.Arith.Minus.minus_n_O.
Is there a way to run Print Coq.Arith.Minus.minus_n_O without loading the library just as applying a function in OCaml?
In Coq there is a distinction between requiring and importing a module. Require is the keyword that lets you load the library while Import lets you drop the prefix. Export M does Import M but also says that when the current module is itself imported, then M will be imported too.
I would say what you want is
From Coq Require Arith.Minus.
Print Coq.Arith.Minus.minus_n_O.
without the Export.
To compare with ocaml, Import is like open and Require is just implicit in ocaml: a module is imported when it is used basically.
You can find more in the documentation of Import, Export and Require. Also in general to find more about commands, just look up the command index.
I have a rather large codebase, that I want to start porting to C++20-modules. The layout is (roughly) like this:
SDK/System > Engine > Editor
In the order of they reference each other (editor uses engine, etc...).
My main interest would be, to first port SDK, and then Engine to modules. Editor is the least important in that regard. However, from my first attempts and research, you would have to start bottom-up, since if "SDK" is modularized, if "Editor" still uses header-includes, it wouldn't be able to use the modules.
Is this correct? If so, is there any way around it? I have seen some attempts by using #ifdefs to have both modules and header based approaches, but this would remove much of the benefit from using modules in the first place. Or do I really have to port all the consumer-code before I can start porting the shared libraries?
A file that is not a module unit can import module units just fine. You can even #include a header which has import directives in it (not that this is a good idea). And module units can #include headers just fine, so long as you do it in the global module fragment, before the main module declaration.
What you can't do is create a module unit and expose its interface to some other file via a header that does not import that module unit. Once something is in a module, it can only be accessed via import.
Before installing the package, I read the code and I got a question.
There is double dot in the code when the code calls a module, the module is tools.
What is the double dot in python?
The code wrote from ..tools import *.
You can find it here, https://github.com/synergetics/spectrum/blob/master/src/conventional/cum2x.py
The code is computing the bispectrum.
And do you know the other code analysing a wave interaction for python such as HOSA in MATLAB?
In python, The . is just accessing an attribute. The attribute could be a class, an instance, a method/function, etc and The .. is just specify an relative address in Linux environment. It means go to ../tools folder and import everything inside it.
I have a question about generating code coverage in Go(lang) projects.I have this simple structure:
ROOT/
config/
handlers/
lib/
models/
router/
main.go
config contains configuration in JSON and one simple config.go that reads and parses JSON file and fills the Config struct which is used then when initializing DB connection. handlers contains controllers (i.e. handlers of respective METHOD+URL described in router/routes.go). lib contains some DB, request responder and logger logic. models contains structs and their funcs to be mapped from-to JSON and DB. Finally router contains the router and routes definition.
Basically just by testing one single handler I ensure that my config, logger, db, responder, router and corresponding model are invoked (and tested somehow as well).
Now if this would be a PHP or Java or I don't know what else language, having and running that single handler test would create a code coverage also for all other invoked parts of code even if they are in different folders (i.e. packages here). Unfortunately, this is not the case in Go.
And there is very little code in most of my lib files having just one method (like InitDB() or ReadConfig() or NewRouter() or Logger()) so to be able to have code coverage for them I have to create stupid tests in these packages as well while they were already invoked and tested by testing the main URLs handling packages.
Is there any way how to get code coverage from packages also for included other packages within one project?
You can import your packages within a single test and write tests for them based on how they'll be used within your application. For example, you can have one test, main_test.go which imports all the other packages, and then you write tests for the methods in the imported packages.
Like this (in main_test.go):
package main
import (
"testing"
"lib"
"models"
"handlers"
// etc
)
// testing code here
However, in my personal opinion, it might be better to make sure that each package does what it should and that only. The best way to do that, is by testing the individual package itself, with its own test suite.
While developing and translating an application, it might be nice if gettext will use the catalogs found in the local po/ dir so it wouldn't be necessary to call make install each time.
Is there a way to do it?
One of the problems is the naming convention: gettext looks for the catalog files in an hierarchy that looks like /usr/share/locale/LL/LC_MESSAGES/package.mo (where LL is two-letter language code), while usually in the development tree the binary catalogs reside in po/LL.gmo.
it might be nice if gettext will use the catalogs found in the local po/ dir so it wouldn't be necessary to call make install each time....Is there a way to do it?
If I am understanding your idea correctly, it sounds like gettext is able to do just that (i.e. change the translation path variable) if you follow the prescribed methods to set it up...
Translations should be stored in a path having a fixed structure.
First of all, we’ll have a root folder named to your taste (for
example “languages”). Inside it, we have to create a folder for every
targeted language whose name must comply to the ISO 3166 standard. So,
valid names for an Italian translation can be “it_IT” (Italian of
Italy), “it_CH” (Italian of Switzerland), “en_US” (English of USA),
and so on. Within the folder having the language code, we must have a
folder named “LC_MESSAGES” where, finally, we’ll store the translation
files.
From Here (there is a script example included in this link showing one method to perform this task)
Change "languages" in description above to "po", and that may do what you want?