-
Notifications
You must be signed in to change notification settings - Fork 116
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
Can we rename nocmodl generated file to .cpp instead of .c? #384
Comments
In principle I have no objection to this. It would be a good idea to test this with all the NEURON ModelDB models (the current nrnverify scripts have not been kept to the point of complete coverage.) |
I agree that switching to C++ has minimal downside and introduces significant new features. That said, is this solving the wrong problem? In my mind, MOD files are for specifying ion channel (etc) kinetics. The ingenious thing about MOD files is that they allow arbitrary code in VERBATIM blocks, but I'd argue that anyone using VERBATIM blocks is working around something that they perceive to be a limitation in NEURON/CoreNEURON. In particular, if VERBATIM blocks are being used to interconnect NEURON with external tools, maybe we should just have a NEURON API for doing that. For NEURON, ctypes and cvode.extra_scatter_gather can probably do most of this as-is and examples might be all that's needed; for CoreNEURON, things are probably trickier. For the adex.mod example, should we think of that as an implicit feature request for NMODL? Shouldn't we view resorting to C as a sign of a limitation in the language? This is slightly complicated by the fact that there are now multiple NMODL compilers. Models that avoid VERBATIM blocks have greater potential for being machine analyzed (in the sense of comparing models and not the model outputs). Perhaps a NEURON board should have an NMODL subcommittee? Or maybe that should be a stand-alone board, now that Arbor and others use NMODL? |
A NEURON API is a necessary addition to the environment. Most of the labor is the documentation. |
CoreNEURON recently underwent a refactoring where all c files were renamed cpp and everything is |
I think @pramodk's arguments make sense and I am in favor of this change. @ramcdougal is right in saying that we're trying to solve the wrong problem. But unfortunately I don't see a way how nmodl can become anytime soon a language powerful enough to encompass all the use-cases we currently need |
I agree with above. I tried to use
Agree as well! (it was wrong example for this feature)
That's good idea! During last hackathon me/Omar were thinking of having a dedicated discussion about NMODL aspects but dropped it because of time constant. For upcoming hackathon, we can include this!
Yes. We already have analysed all VERBATIM blocks from ModelDB (there is Verbatim visitor in NMODL). Lets review those during next hackathon. |
- nrnivmodl accept extra option -cpp by which all mod files are translated to .cpp instead of .c - all files are then compiled with CXX and relevant compiler flags to build special - keep everything backward compatible i.e. if -cpp flag is not provided then keep old behaviour - nocmodl accepts extra comamnd line argument ext=cpp (last argument) by which .mod file is translated to .cpp - nrnivmodl and relevant makefiles are updated to accept -cpp flag fixes #384
- nrnivmodl accept extra option -cpp by which all mod files are translated to .cpp instead of .c - all files are then compiled with CXX and relevant compiler flags to build special - keep everything backward compatible i.e. if -cpp flag is not provided then keep old behaviour - nocmodl accepts extra comamnd line argument ext=cpp (last argument) by which .mod file is translated to .cpp - nrnivmodl and relevant makefiles are updated to accept -cpp flag fixes #384
Answer of this ticket is yes and this is already being addressed in #708. |
I am creating this issue as question (/proposal):
What if we merely rename nocmodl generated file
.cpp
instead of.c
?Would this be a problem?
What will be benefit?
cc : @ohm314 @ramcdougal
The text was updated successfully, but these errors were encountered: