dune-common issueshttps://gitlab.dune-project.org/core/dune-common/-/issues2024-01-17T07:45:27Zhttps://gitlab.dune-project.org/core/dune-common/-/issues/320dunecontrol fails when a branch with name 'dune.module' is created.2024-01-17T07:45:27ZRobert Kdunecontrol fails when a branch with name 'dune.module' is created.This is probably the best bug I have seem in my entire time with DUNE.
See mailing list discussion: https://lists.dune-project.org/pipermail/dune-devel/2022-October/002961.htmlThis is probably the best bug I have seem in my entire time with DUNE.
See mailing list discussion: https://lists.dune-project.org/pipermail/dune-devel/2022-October/002961.htmlhttps://gitlab.dune-project.org/core/dune-common/-/issues/319How skip kwallet/gpg/pinetry dialogs when building DUNE (with python)2022-12-07T15:24:27ZMarkus BlattHow skip kwallet/gpg/pinetry dialogs when building DUNE (with python)I was getting already really nervous about pinetry dialogs asking for the passphrase of my GPG key popping up from time to time. Slowly I realized that this happens when I run CMake in Dune. I think this might be pypi or whatever we are ...I was getting already really nervous about pinetry dialogs asking for the passphrase of my GPG key popping up from time to time. Slowly I realized that this happens when I run CMake in Dune. I think this might be pypi or whatever we are using. Not sure why exactly. It is a bit annoying.
Is there any way to prevent this dialog?
I also wonder what happens when I log into my machine remotely while there is an Y/Wayland-session running. I assume that the dialog will pop on the graphical console and CMake/pypi will wait for input.https://gitlab.dune-project.org/core/dune-common/-/issues/318python -m fix-dunepy not working with new Makefile approach2023-02-10T15:06:33ZAndreas Dednerpython -m fix-dunepy not working with new Makefile approachOne can use `python -m dune fix-dunepy force` as before but the other inconsistency tests only make sense for the old cmake setup. Need to check if the inconsistencies that came up with the old setup are still an issue with the new setup...One can use `python -m dune fix-dunepy force` as before but the other inconsistency tests only make sense for the old cmake setup. Need to check if the inconsistencies that came up with the old setup are still an issue with the new setup, i.e., what can break by a ctrl-c at the wrong time?https://gitlab.dune-project.org/core/dune-common/-/issues/317Callable in algorithm.run2022-10-10T17:27:19ZRobert KCallable in algorithm.runCurrently it's only possible to receive `std::function<void(...)>` in an algorithm from the Python side since pybind11::function can only be cast into that. This is when the argument passed to algorithm.run has not cppType.
Setting the ...Currently it's only possible to receive `std::function<void(...)>` in an algorithm from the Python side since pybind11::function can only be cast into that. This is when the argument passed to algorithm.run has not cppType.
Setting the cppType by hand to, e.g. `std::function<bool(...)>` is a working fix.https://gitlab.dune-project.org/core/dune-common/-/issues/316Some methods in Communication<T> are unnecessarily mutable2023-03-14T14:12:07ZSantiago Ospina De Los Ríossospinar@gmail.comSome methods in Communication<T> are unnecessarily mutableSome methods like `send` and `recv` in the dummy `Communication<T>` are mutable while their counterpart in `Communication<MPI_Comm>` are const. Although copying the object is not a problem, I don't see the reason why these have to be mut...Some methods like `send` and `recv` in the dummy `Communication<T>` are mutable while their counterpart in `Communication<MPI_Comm>` are const. Although copying the object is not a problem, I don't see the reason why these have to be mutable.https://gitlab.dune-project.org/core/dune-common/-/issues/315race condition in dune-2.8 python builder2022-10-10T07:54:46ZChristian Engwerrace condition in dune-2.8 python builderI tried using dune python on an NFS share. After code generation we try to build the file, but sometimes cmake didn't yet realize that `CMakeLists.txt` has changed (as the changes are not yet fully synced).
What helped in my case was to...I tried using dune python on an NFS share. After code generation we try to build the file, but sometimes cmake didn't yet realize that `CMakeLists.txt` has changed (as the changes are not yet fully synced).
What helped in my case was to add an `os.sync()` at the the beginning of the `compile()` function.
I didn't check yet, how the situation is on the development branch.https://gitlab.dune-project.org/core/dune-common/-/issues/314Python buildir check returns wrong error code2023-02-10T15:06:34ZSantiago Ospina De Los Ríossospinar@gmail.comPython buildir check returns wrong error codeThe following discussion from !1162 should be addressed:
- [ ] @andreas.dedner started a [discussion](https://gitlab.dune-project.org/core/dune-common/-/merge_requests/1162#note_117407): (+4 comments)
> I think this needs to be 77...The following discussion from !1162 should be addressed:
- [ ] @andreas.dedner started a [discussion](https://gitlab.dune-project.org/core/dune-common/-/merge_requests/1162#note_117407): (+4 comments)
> I think this needs to be 77 so that the test is marked as skipped.
The script [`run-in-dune-env.sh`](https://gitlab.dune-project.org/core/dune-common/-/blob/5dcb1e2b96d99e758ad06894218b8ba786725e15/cmake/scripts/run-in-dune-env.sh.in) returns an error code with value 77. This value is chosen so that dune tests are marked as skipped when the python configuration failed. Otherwise, the value is arbitrary. Now, with !1148 merged, we can address this situation at configuration time directly and conditionally add tests to the test suite.
Related to #289.https://gitlab.dune-project.org/core/dune-common/-/issues/313Python virtual environment depends on dune-common python package2023-03-01T11:23:17ZSantiago Ospina De Los Ríossospinar@gmail.comPython virtual environment depends on dune-common python packageCurrently, the [`run-in-dune-env.sh`](https://gitlab.dune-project.org/core/dune-common/-/blob/5dcb1e2b96d99e758ad06894218b8ba786725e15/cmake/scripts/run-in-dune-env.sh.in) script uses the dune-common python module to check for something ...Currently, the [`run-in-dune-env.sh`](https://gitlab.dune-project.org/core/dune-common/-/blob/5dcb1e2b96d99e758ad06894218b8ba786725e15/cmake/scripts/run-in-dune-env.sh.in) script uses the dune-common python module to check for something on the build dirs (I don't know what). This is problematic because the venv may be used in downstream modules without necessarily assuming that dune-common python package is installed (e.g. `dune-testtools`, `dune-codegen`).
A simple fix is to conditionally check if the python package is available:
```bash
# check if dune-common is installed
if python -m dune --help &> /dev/null; then
# test if build directory matches installed dune python packages
python -m dune checkbuilddirs @PROJECT_NAME@ @CMAKE_BINARY_DIR@
RESULT=$?
if [ $RESULT -ne 0 ] ; then
echo "Dune python package could not check build directories"
exit $RESULT
fi
fi
# execute the command
"$@"
```
But perhaps someone with more insight of `checkbuilddirs` can give a more appropriate solution.Samuel Burbullasamuel.burbulla@mathematik.uni-stuttgart.deSamuel Burbullasamuel.burbulla@mathematik.uni-stuttgart.dehttps://gitlab.dune-project.org/core/dune-common/-/issues/312debugallocator.hh: `operator new` not well-behaved; causes test failures with...2022-07-19T20:36:20ZAnsgar Burchardtansgar.burchardt@tu-dresden.dedebugallocator.hh: `operator new` not well-behaved; causes test failures with LTO[dune-common 2.8.0 fails to build in Debian with link-time optimization enabled](https://bugs.debian.org/1015392) due to failures in testdebugallocator.
A backtrace from gdb shows:
```
Program received signal SIGFPE, Arithmetic exceptio...[dune-common 2.8.0 fails to build in Debian with link-time optimization enabled](https://bugs.debian.org/1015392) due to failures in testdebugallocator.
A backtrace from gdb shows:
```
Program received signal SIGFPE, Arithmetic exception.
0x0000555555556cf1 in Dune::DebugMemory::AllocationManager::allocate<char> (this=<optimized out>, n=<optimized out>) at ./dune/common/debugallocator.hh:124
124 ai.page_ptr = mmap(NULL, ai.pages * page_size,
(gdb) bt
#0 0x0000555555556cf1 in Dune::DebugMemory::AllocationManager::allocate<char> (this=<optimized out>,
n=<optimized out>) at ./dune/common/debugallocator.hh:124
#1 operator new (size=size@entry=64) at ./dune/common/debugallocator.hh:322
#2 0x00007ffff7fb0e82 in __gnu_cxx::new_allocator<unsigned long>::allocate (this=<optimized out>,
__n=8) at /usr/include/c++/11/ext/new_allocator.h:127
#3 std::allocator_traits<std::allocator<bool*> >::allocate (__n=8, __a=<synthetic pointer>...)
at /usr/include/c++/11/bits/alloc_traits.h:464
#4 std::_Deque_base<bool, std::allocator<bool> >::_M_allocate_map (__n=8,
this=0x7ffff7fc36f8 <Dune::dvverb+24>) at /usr/include/c++/11/bits/stl_deque.h:576
#5 std::_Deque_base<bool, std::allocator<bool> >::_M_initialize_map (__num_elements=0,
this=0x7ffff7fc36f8 <Dune::dvverb+24>) at /usr/include/c++/11/bits/stl_deque.h:625
#6 std::_Deque_base<bool, std::allocator<bool> >::_Deque_base (this=0x7ffff7fc36f8 <Dune::dvverb+24>)
at /usr/include/c++/11/bits/stl_deque.h:439
#7 std::deque<bool, std::allocator<bool> >::deque (this=0x7ffff7fc36f8 <Dune::dvverb+24>)
at /usr/include/c++/11/bits/stl_deque.h:834
#8 std::stack<bool, std::deque<bool, std::allocator<bool> > >::stack<std::deque<bool, std::allocator<bool> >, void> (this=<optimized out>, this=<optimized out>) at /usr/include/c++/11/bits/stl_stack.h:163
#9 0x00007ffff7fb0f42 in _sub_I_65535_0.0 ()
from /build/dune-common-GdfBws/dune-common-2.8.0/build/lib/libdunecommon.so.2.8.0
#10 0x00007ffff7fdc0ce in ?? () from /lib64/ld-linux-x86-64.so.2
#11 0x00007ffff7fdc1b0 in ?? () from /lib64/ld-linux-x86-64.so.2
#12 0x00007ffff7fcd08a in ?? () from /lib64/ld-linux-x86-64.so.2
#13 0x0000000000000001 in ?? ()
#14 0x00007fffffffeccd in ?? ()
#15 0x0000000000000000 in ?? ()
```
This is during the construction of global objects, in particular some member of `Dune::dvverb`.
It calls the custom `operator new` from "debugallocator.hh".
The relevant instruction is:
```
=> 0x0000555555556cf1 <+81>: div %r12
```
which should come from this division:
```
ai.pages = (ai.capacity) / page_size + 2;
```
`page_size` is still 0 as the global variables from the "debugallocator.cc" translation unit have not been initialized when the "Dune::dvverb" object gets constructed.
Note that the order in which global variables in different translation units are initialized is undefined according to the C++ standard, but the code currently requires a specific order (`page_size` must be initialized before anything uses the `operator new`).https://gitlab.dune-project.org/core/dune-common/-/issues/311python packaging fails with strange errors if dependencies are not available ...2023-04-09T14:10:39ZChristian Engwerpython packaging fails with strange errors if dependencies are not available in the pipy repositoryI tried building locally a python package for dnue-uggrid.
The current build infrastructure tries to install the dependencies. The problem is now that `dune-uggrid` is version 2.9 and requires `dune-common` version 2.9. My initial idea ...I tried building locally a python package for dnue-uggrid.
The current build infrastructure tries to install the dependencies. The problem is now that `dune-uggrid` is version 2.9 and requires `dune-common` version 2.9. My initial idea was to install `dune-common` 2.9 into my local venv using `pip install ./dune-common` which worked perfectly:
```
> pip list
Package Version
------------------ ---------------
certifi 2022.6.15
charset-normalizer 2.0.12
cmake 3.22.5
distro 1.7.0
dune-common 2.9.dev20220622
idna 3.3
Jinja2 3.1.2
MarkupSafe 2.1.1
mpi4py 3.1.3
ninja 1.10.2.3
numpy 1.22.4
packaging 21.3
pip 22.1.1
portalocker 2.4.0
pyparsing 3.0.9
requests 2.28.0
scikit-build 0.15.0
setuptools 59.6.0
urllib3 1.26.9
wheel 0.37.1
```
... but still `pip install ./dune-uggrid` tries to install `dune-common` and finds only the 2.8 wheel:
```
> pip -v install dnue-uggrid/
Using pip 22.1.1 from /home/christi/Uni/Dune/foobar/lib/python3.10/site-packages/pip (python 3.10)
Processing ./uggrid
Running command pip subprocess to install build dependencies
Collecting cmake>=3.13
Using cached cmake-3.22.5-py2.py3-none-manylinux_2_17_x86_64.manylinux2014_x86_64.whl (22.5 MB)
Collecting dune-common
Using cached dune_common-2.8.0.post2-cp310-cp310-linux_x86_64.whl
Collecting ninja
Using cached ninja-1.10.2.3-py2.py3-none-manylinux_2_5_x86_64.manylinux1_x86_64.whl (108 kB)
Collecting pip
Using cached pip-22.1.2-py3-none-any.whl (2.1 MB)
Collecting requests
Using cached requests-2.28.0-py3-none-any.whl (62 kB)
Collecting scikit-build
Using cached scikit_build-0.15.0-py2.py3-none-any.whl (77 kB)
Collecting setuptools
Using cached setuptools-62.6.0-py3-none-any.whl (1.2 MB)
Collecting wheel
Using cached wheel-0.37.1-py2.py3-none-any.whl (35 kB)
Collecting portalocker
Using cached portalocker-2.4.0-py2.py3-none-any.whl (16 kB)
Collecting mpi4py
Using cached mpi4py-3.1.3-cp310-cp310-linux_x86_64.whl
Collecting numpy
Using cached numpy-1.22.4-cp310-cp310-manylinux_2_17_x86_64.manylinux2014_x86_64.whl (16.8 MB)
Collecting urllib3<1.27,>=1.21.1
Using cached urllib3-1.26.9-py2.py3-none-any.whl (138 kB)
Collecting idna<4,>=2.5
Using cached idna-3.3-py3-none-any.whl (61 kB)
Collecting charset-normalizer~=2.0.0
Using cached charset_normalizer-2.0.12-py3-none-any.whl (39 kB)
Collecting certifi>=2017.4.17
Using cached certifi-2022.6.15-py3-none-any.whl (160 kB)
Collecting packaging
Using cached packaging-21.3-py3-none-any.whl (40 kB)
Collecting distro
Using cached distro-1.7.0-py3-none-any.whl (20 kB)
Collecting pyparsing!=3.0.5,>=2.0.2
Using cached pyparsing-3.0.9-py3-none-any.whl (98 kB)
Installing collected packages: ninja, cmake, wheel, urllib3, setuptools, pyparsing, portalocker, pip, numpy, mpi4py, idna, distro, charset-normalizer, certifi, requests, packaging, dune-common, scikit-build
```
The build will then later fail with a `cmake` error, as it only find `dune-common` version 2.8 and not version 2.9.
If this intended behaviour? Or how should I properly handle this local install?https://gitlab.dune-project.org/core/dune-common/-/issues/310dune_python_install_package can only install packages without setup.py2022-07-18T16:01:41ZSantiago Ospina De Los Ríossospinar@gmail.comdune_python_install_package can only install packages without setup.pyBefore the python overhaul, the `dune_python_install_package` was intended to install complete python packages other than dune. This is not possible anymore. The reasons and possible solutions are:
1. Python projects are expected to hav...Before the python overhaul, the `dune_python_install_package` was intended to install complete python packages other than dune. This is not possible anymore. The reasons and possible solutions are:
1. Python projects are expected to have a `setup.py.in` file or a generic one will be provided. This does not hold for well-formed python projects because they have other own `setup.py` and the CMake generated `setup.py` is not appropriate. https://gitlab.dune-project.org/core/dune-common/-/commit/f954a5a114a1f26bb0101dca7458b710c4df138f#ebdde4c20e47e807f1a7a7b0067708d96786d8ef is offending commit where the path to the python project is unconditionally set to the binary directory instead of the source directory. A solution is to set the `PYINST_FULLPATH` to the binary directory only if no `setup.py` is provided.
2. The `pip install` is called with a `--no-index` argument. While this is fine for dune projects, this is not ideal for generic project installations where the `setup.py` states dependencies expected to be fulfilled by `pip`. A solution for this would be to have an opt-in option to have index (e.g. `USE_INDEX`).https://gitlab.dune-project.org/core/dune-common/-/issues/309PoolAllocator is not an allocator2022-06-08T11:25:15ZCarsten Gräsergraeser@math.fau.dePoolAllocator is not an allocatorThe `PoolAllocator` class does not satisfy the allocator requirements of the standard. More specifically the requirements for `A` to be an allocator include:
Assume that `B` is obtained by rebinding `A` to another type and than `a` is a...The `PoolAllocator` class does not satisfy the allocator requirements of the standard. More specifically the requirements for `A` to be an allocator include:
Assume that `B` is obtained by rebinding `A` to another type and than `a` is an object of type `A`. Then after constructing a `B` using `B b(a);` it must hold that `A(b) == a` and `B(a) == b`. This equality constraint especially implies that you can deallocate memory allocated by another instance that compares equal. Hence all allocators obtained in this way from a single allocator essentially must have shared state.
In contrast, different `PoolAllocator` objects will never compare equal, because each one manages its own pool and they never share state. Additionally to not meeting the requirements this also prohibits many use cases. E.g. `std::allocate_shared` (creation of `shared_ptr` with allocator) will always use a copy of the provided allocator. Thus using a `PoolAllocator` many times in `std::allocate_shared` will contstruct a new internal pool for any allocation.https://gitlab.dune-project.org/core/dune-common/-/issues/308MPICommunicator does not allow for size adjustment in async communication2022-06-02T12:55:03ZChristian EngwerMPICommunicator does not allow for size adjustment in async communication`MPICommunicator::rrecv` allows to pass a buffer with insufficient size. It first uses `MPI_Mprobe` and `MPI_Get_count` to extract the size info from the message, then resizes the buffer and at last it actually performs the `MPI_Recv`.
...`MPICommunicator::rrecv` allows to pass a buffer with insufficient size. It first uses `MPI_Mprobe` and `MPI_Get_count` to extract the size info from the message, then resizes the buffer and at last it actually performs the `MPI_Recv`.
It would be very helpful to have a similar feature to `irecv`.
The approach would roughly look as follows:
- use `MPI_Iprobe` to check for the message in an async fashion
- return a corresponding future
- after `future.ready()` is true the data can be received, e.g. in `future.get()` or any other polling call
- with the `MPI_Iprobe`/`MPI_Get_count` results we resize the buffer and perform a sync `MPI_Recv`.https://gitlab.dune-project.org/core/dune-common/-/issues/307dune_require_cxx_standard does not require anything2023-03-26T18:20:04ZTimo Kochdune_require_cxx_standard does not require anything`dune_require_cxx_standard(MODULE "mymodule" VERSION 140)` runs through without error. In the case the required standard is higher than the highest available standard nothing is checked or set.
Expected: Fatal error saying that the comp...`dune_require_cxx_standard(MODULE "mymodule" VERSION 140)` runs through without error. In the case the required standard is higher than the highest available standard nothing is checked or set.
Expected: Fatal error saying that the compiler doesn't support the required standard.https://gitlab.dune-project.org/core/dune-common/-/issues/306configure looks for Metis but build doesn't use it2022-05-31T06:32:28ZYuri Vicconfigure looks for Metis but build doesn't use it```
-- Found METIS: /usr/local/lib/libmetis.so (found version "5.1")
```
Version: 2.8.0```
-- Found METIS: /usr/local/lib/libmetis.so (found version "5.1")
```
Version: 2.8.0https://gitlab.dune-project.org/core/dune-common/-/issues/305[python][bug] Deadlock in cmakebuilder2022-04-25T08:52:36ZTimo Koch[python][bug] Deadlock in cmakebuilderCommit d3e697332dcc80fd1535c694466eda7649bb93d7 introduces a bug in the cmake builder.
`Popen.wait` deadlocks if the command produces enough output to fill the buffer. The docs clearly warns about this https://docs.python.org/3/library/s...Commit d3e697332dcc80fd1535c694466eda7649bb93d7 introduces a bug in the cmake builder.
`Popen.wait` deadlocks if the command produces enough output to fill the buffer. The docs clearly warns about this https://docs.python.org/3/library/subprocess.html#subprocess.Popen.wait. `communicate` has to be called.Timo KochTimo Kochhttps://gitlab.dune-project.org/core/dune-common/-/issues/304Messed up python compile output after !11152022-04-25T08:51:45ZTimo KochMessed up python compile output after !1115Commit eebb02805eaca397c54a82bf54789ffaf62c921e messed up the Python log output. The message differentiating between different compilation modes (`PrintCompiling`, no idea why the variable name is uppercase.., e.g. here https://gitlab.du...Commit eebb02805eaca397c54a82bf54789ffaf62c921e messed up the Python log output. The message differentiating between different compilation modes (`PrintCompiling`, no idea why the variable name is uppercase.., e.g. here https://gitlab.dune-project.org/core/dune-common/-/blob/master/python/dune/generator/cmakebuilder.py#L275) is lost because the local variable has no effect when it's in a separate function.Timo KochTimo Kochhttps://gitlab.dune-project.org/core/dune-common/-/issues/303[python] pybind11 name of FieldVector does not contain the field type2022-05-06T16:25:19ZChristian Engwer[python] pybind11 name of FieldVector does not contain the field typeThe field type changes the type of the FieldVector, but registerFieldVector only considers the dimension and does not adhere the field type.
This breaks any code using `field_type != double`.The field type changes the type of the FieldVector, but registerFieldVector only considers the dimension and does not adhere the field type.
This breaks any code using `field_type != double`.https://gitlab.dune-project.org/core/dune-common/-/issues/302Python and MPI does not work anymore.2022-04-08T12:12:17ZRobert KPython and MPI does not work anymore.Somewhere between commit 240bccb5ad830f791d38bea43fad285aa1b4ae76 (works fine) and commit 73ec17e1f45a376f7e026d9ce6b2d404531f83b6 (does not work) the ability to run DUNE Python scripts with MPI broke.
With the current master I get:
Wit...Somewhere between commit 240bccb5ad830f791d38bea43fad285aa1b4ae76 (works fine) and commit 73ec17e1f45a376f7e026d9ce6b2d404531f83b6 (does not work) the ability to run DUNE Python scripts with MPI broke.
With the current master I get:
With the current master I get
```
Traceback (most recent call last):
File "/home/robertk/work/Dune/stable/cfd-playground/examples/euler/euler.py", line 67, in <module>
gridView = view( grid( Model.domain, dimgrid=dim ) ) in
File "/home/robertk/work/Dune/stable/dune-grid/build-cmake/python/dune/grid/_grids.py", line 195, in yaspGrid
gridView = view( grid( Model.domain, dimgrid=dim ) )
File "/home/robertk/work/Dune/stable/dune-grid/build-cmake/python/dune/grid/_grids.py", line 195, in yaspGrid
constructor = equidistantOffsetCoordinates(
File "/home/robertk/work/Dune/stable/dune-grid/build-cmake/python/dune/grid/_grids.py", line 122, in equidistantOffsetCoordinates
constructor = equidistantOffsetCoordinates( on
File "/home/robertk/work/Dune/stable/dune-grid/build-cmake/python/dune/grid/_grids.py", line 122, in equ.tidistantOffsetCoordinates
mod = moduleYaspCoordinates(dim) on
File "/home/robertk/work/Dune/stable/dune-grid/build-cmake/python/dune/grid/_grids.py", line 116, in mod.tuleYaspCoordinates
mod = moduleYaspCoordinates(dim)
File "/home/robertk/work/Dune/stable/dune-grid/build-cmake/python/dune/grid/_grids.py", line 116, in moduleYaspCoordinates ul
module = builder.load(moduleName, source, "yasp coordinates dim={dim}".format(dim = dim)) # , self.typeName[0], extraCMake) eN
File "/home/robertk/work/Dune/stable/dune-common/build-cmake/python/dune/generator/cmakebuilder.py", line 276, in load e
module = builder.load(moduleName, source, "yasp coordinates dim={dim}".format(dim = dim)) # , self.typeName[0], extraCMake)
File "/home/robertk/work/Dune/stable/dune-common/build-cmake/python/dune/generator/cmakebuilder.py", line e 276, in load
self.initialize()
File "/home/robertk/work/Dune/stable/dune-common/build-cmake/python/dune/generator/cmakebuilder.py", linine 191, in initialize
removeGenerated(['30'], date=True, verbose=False)
File "/home/robertk/work/Dune/stable/dune-common/build-cmake/python/dune/generator/remove.py", line 82, e in removeGenerated
self.initialize()
File "/home/robertk/work/Dune/stable/dune-common/build-cmake/python/dune/generator/cmakebuilder.py", line 191, in initialize
for line in fileinput.input( os.path.join(generated_dir, 'CMakeLists.txt'), inplace = True): in
File "/usr/lib/python3.9/fileinput.py", line 249, in __next__
removeGenerated(['30'], date=True, verbose=False)
File "/home/robertk/work/Dune/stable/dune-common/build-cmake/python/dune/generator/remove.py", line 82, in removeGenerated
for line in fileinput.input( os.path.join(generated_dir, 'CMakeLists.txt'), inplace = True):
File "/usr/lib/python3.9/fileinput.py", line 249, in __next__
line = self._readline()
File "/usr/lib/python3.9/fileinput.py", line 343, in _readline
line = self._readline() on
File "/usr/lib/python3.9/fileinput.py", line 343, in _readline .t
os.rename(self._filename, self._backupfilename)
FileNotFoundError: [Errno 2] No such file or directory: '/home/robertk/work/Dune/stable/cache/dune-py/pythonon/dune/generated/CMakeLists.txt' -> '/home/robertk/work/Dune/stable/cache/dune-py/python/dune/generated/C.tMakeLists.txt.bak'
os.rename(self._filename, self._backupfilename)
FileNotFoundError: [Errno 2] No such file or directory: '/home/robertk/work/Dune/stable/cache/dune-py/python/dune/generated/CMakeLists.txt' -> '/home/robertk/work/Dune/stable/cache/dune-py/python/dune/generated/CulMakeLists.txt.bak'
```https://gitlab.dune-project.org/core/dune-common/-/issues/301How call GenerateTypeName for `Foo<Signature>`2022-04-01T13:37:37ZChristian EngwerHow call GenerateTypeName for `Foo<Signature>`When defining function bindings, it is not so uncommon, that the first template argument is a signature, e.g.
`double(Dune::FieldVector<double,2>)`.
I couldn't figure out how to specify such a type for the python type registry.
If I c...When defining function bindings, it is not so uncommon, that the first template argument is a signature, e.g.
`double(Dune::FieldVector<double,2>)`.
I couldn't figure out how to specify such a type for the python type registry.
If I call
```
GenerateTypeName("Foo", "double(Dune::FieldVector<double,2>)")
```
it interprets the second string as a member name and tries to register `Foo::double(Dune::FieldVector<double,2>)`.
If I try something like
```
GenerateTypeName("Foo", MetaType<double(Dune::FieldVector<double,2>)>)
```
it fails, because the signature is nothing we could register as a complete type, or could and should we?