You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In some cases (e.g., from WebAssembly), to generate some code with the view of compiling it on the fly is next to impossible at this stage (at least, using LLVM+Clang; see opencor/libopencor#223). For this reason, it would be nice to have a way to interpret a model. This could (greatly) take advantage of what has been done for the Generator, especially when it comes to which equation should be evaluated and when.
Technically speaking, the interpreter should probably not be part of libCellML but rather libOpenCOR. However, to have it in libOpenCOR would require duplicating most of the current Generator code, which would be a very bad idea. So, so far, the plan has been to refactor the Generator code so that it can not only generate C and Python code, but also generate the structure needed to interpret a model.
The text was updated successfully, but these errors were encountered:
In some cases (e.g., from WebAssembly), to generate some code with the view of compiling it on the fly is next to impossible at this stage (at least, using LLVM+Clang; see opencor/libopencor#223). For this reason, it would be nice to have a way to interpret a model. This could (greatly) take advantage of what has been done for the
Generator
, especially when it comes to which equation should be evaluated and when.Technically speaking, the interpreter should probably not be part of libCellML but rather libOpenCOR. However, to have it in libOpenCOR would require duplicating most of the current
Generator
code, which would be a very bad idea. So, so far, the plan has been to refactor theGenerator
code so that it can not only generate C and Python code, but also generate the structure needed to interpret a model.The text was updated successfully, but these errors were encountered: