Open pramodk opened 4 months ago
We should change default log level from info to warning IMO. When we have tens of MOD files, having those info level logs are not helpful
Agreed.
When multiple MOD files are translated and compiled, it's difficult to understand error log belongs to which MOD file.
I think this is because the AST is not aware of which file it came from (which is good for separation of concerns, not so good for debugging), so I'm not sure what the proper fix for this would be.
Do we abort the NMODL translation when incompatibility visitor detect errors? If it's not the case then it should. In most of the cases user shouldn't end-up seeing compilation errors like the below
It turns out these two are related: NMODL actually does abort by default (i.e. returns a status code of 1), it's just that /gpfs/bbp.cscs.ch/ssd/apps/bsd/2024-02-01/stage_applications/install_oneapi-2023.2.0-skylake/neuron-9.0.a15-ugsan4/share/coreneuron/nrnivmodl_core_makefile
passes the following to NMODL:
nmodl_arguments_c=host --c passes --inline codegen --force
Due to --force
in the above, NMODL happily exits with a 0 status code, thereby creating a CPP file which cannot be compiled, thereby causes the 2 issues. After some digging around, I think removing this line from the Spack recipe here should fix it:
https://github.com/BlueBrain/spack/blob/549a3bfebb3f9f66baea47ea22793801660810c4/bluebrain/repo-patches/packages/neuron/package.py#L87
I think this is because the AST is not aware of which file it came from (which is good for separation of concerns, not so good for debugging), so I'm not sure what the proper fix for this would be.
I should look into the code but when we launch nmodl foo.mod
, nmodl offer could print foo.mod
also in all log messages and hence it would be easy to identify? Is that a possibility?
After some digging around, I think removing this line from the Spack recipe here should fix it:
--force
was definitely added in old
days to have forced behavior. I don't remember if that is needed in 2024. So certainly something should be checked!
Maybe slightly off topic. The line numbers should be reviewed, since they might refer to a line number in the MOD file or they might refer to a line number of some intermediate file.
Overview
As part of this ticket I would like to implement some QoL improvements when using NMODL.
Example
Let's take an example of MOD files directory from BB5:
When I compile that with
nrnivmodl-core
, I see the following:Issues
info
towarning
IMO. When we have tens of MOD files, having thoseinfo
level logs are not helpful:I don't know which MOD file this refers to. Having mod file name in this log would be nice.
i.e. I am not sure if this is because we didn't abort right after incompatibility error detected or there is some other reason.