From A.S.Dedner at warwick.ac.uk Wed May 5 13:37:00 2021 From: A.S.Dedner at warwick.ac.uk (Dedner, Andreas) Date: Wed, 5 May 2021 11:37:00 +0000 Subject: [Dune-devel] Python/Build system meeting: Input wanted In-Reply-To: References: Message-ID: Dear developers. This is a follow up from an email from Dominic (on 05/02). Following the discussion, we had on the Python bindings and the build internal virtual environment, Dominic started work on making the changes along the lines of what we discussed. Over the last week I've made some changes to get packaging and some other thngs up and running again based on these changes. The main merge request https://gitlab.dune-project.org/core/dune-common/-/merge_requests/960 contains hopefully useful information on the changes and some of the consequences. I would suggest having a discussion on the changes there. There other core modules (and some others) have companion MRs (still marked WIP). Best Andreas PS: At the time we asked everyone interested to summarize their use cases for combining Dune and Python. I just went through that list again and think everything is addressed: Adrian: can use pip install (and even combine with own source module) Babara: will now get an internal dune-env installed which she might not want Can disable by disabling the cmake lookup of Python but that is perhaps not obvious to her - perhaps give her an easy flag to set? Clara: should be mostly fine - differences are documented. But I guess there are different viewpoints on this Dominic: should be happy since internal venv is now on by default Andreas: works fine for me Linus: Can't say for sure but hope he's happy? Robert: A bit like Babara, i.e., might get an internal venv he doesn't use Oliver: Embedded is still a bit of an issue which is mostly a venv problem 1. An external venv is used: then everything should be fine 2. the internal venv is used: make tests will be fine but calling a C++ code directly will fail since the venv interpreter is not used and the dune packages are not found. Needs to run build-dir/run-in-env ./test This is an issue with venv/embedded that has been discussed on the venv mailing lists but never fixed Christian: These issues are a bit separate from these changes and need to be discussed separately, I think. Some of the things mentioned should work already I believe. At least I hope that current changes don't make things worse. ________________________________ From: Dune-devel on behalf of Dominic Kempf Sent: 05 February 2021 16:15 To: dune-devel at lists.dune-project.org Subject: [Dune-devel] Python/Build system meeting: Input wanted Dear developers, we had a small meeting today that emerged from recent discussions on Gitlab issues + MRs to get an overview of the Python landscape in Dune. Participants were Andreas, Robert, Simon, Carsten, Samuel and myself. I think we made some progress, but we want to build on everybody's feedback to continue. We would like to collect a list of use cases formulated as fictional or non-fictional user profiles. Just add yours to the list: https://cryptpad.fr/pad/#/2/pad/edit/Cdg8eTGASWgdQetoM06emmp7/ This list will serve as the basis of discussion to converge to a technical solution that accommodates the needs of as many users as possible and allows a consensus to enable the Python bindings feature by default in the future. Best, Dominic -------------- next part -------------- An HTML attachment was scrubbed... URL: From simon.praetorius at tu-dresden.de Sun May 16 19:27:20 2021 From: simon.praetorius at tu-dresden.de (Simon Praetorius) Date: Sun, 16 May 2021 19:27:20 +0200 Subject: [Dune-devel] cmake and buildsystem documentation Message-ID: <46a1108d-b569-0e53-8cd6-2f6503fb52db@tu-dresden.de> Hi everyone, In the last months me and others have updated several cmake files, e.g., Find.cmake package modules. During this update, I have changed the way cmake code is documented. I followed the recommendation given by cmake developers in https://cmake.org/cmake/help/latest/manual/cmake-developer.7.html#id6 Since cmake 3.x multi-line comments are supported, starting with #[===========================[.rst: ... comments ... #]===========================] This makes long cmake documentation more readable (in my opinion). Additionally, I used code blocks to document cmake functions. Recently, I discovered that this way of documentation is not covered by the way in Dune the documentation is extracted from .cmake files. This is done manually by a python script, since there is no available tool from cmake for this task. Files are parsed and then some special tags are found representing function, variable or parameter documentations. In order to support multi-line comments this extraction needs to be extended. While searching the web for ways how to do this extraction and documentation generation in a more standardized way, e.g., by public available tools, I have found at least the sphinx "domain" extension to represent cmake commands and variables. This is available from https://pypi.org/project/sphinxcontrib-moderncmakedomain/ Thus, we just need to write the documentation in a cmake compatible way, put into an multi-line comment block at the beginning of the file and then run sphinx on the generated .rst files. I have written the corresponding extension in the file `extract_cmake_Data.py` in the MR https://gitlab.dune-project.org/core/dune-common/-/merge_requests/957 (branch feature/separate-cmake-files) In my opinion, the generated documentation looks nice in HTML format and additionally, the documentation inside cmake source files are better readable. What is your opinion on this? Should we support this way of documentation (in addition to the old way)? Best regards, Simon -- Dr. Simon Praetorius Technische Universität Dresden Institute of Scientific Computing phone: +49 351 463-34432 mail: simon.praetorius@tu-dresden.de From A.S.Dedner at warwick.ac.uk Mon May 17 10:11:20 2021 From: A.S.Dedner at warwick.ac.uk (Dedner, Andreas) Date: Mon, 17 May 2021 08:11:20 +0000 Subject: [Dune-devel] cmake and buildsystem documentation In-Reply-To: <46a1108d-b569-0e53-8cd6-2f6503fb52db@tu-dresden.de> References: <46a1108d-b569-0e53-8cd6-2f6503fb52db@tu-dresden.de> Message-ID: Hi Simon. Sounds good to me especially since I don't understand what the drawbacks are (if there are any). Best Andreas ________________________________ From: Dune-devel on behalf of Simon Praetorius Sent: 16 May 2021 18:27 To: dune-devel at lists.dune-project.org Subject: [Dune-devel] cmake and buildsystem documentation Hi everyone, In the last months me and others have updated several cmake files, e.g., Find.cmake package modules. During this update, I have changed the way cmake code is documented. I followed the recommendation given by cmake developers in https://cmake.org/cmake/help/latest/manual/cmake-developer.7.html#id6 Since cmake 3.x multi-line comments are supported, starting with #[===========================[.rst: ... comments ... #]===========================] This makes long cmake documentation more readable (in my opinion). Additionally, I used code blocks to document cmake functions. Recently, I discovered that this way of documentation is not covered by the way in Dune the documentation is extracted from .cmake files. This is done manually by a python script, since there is no available tool from cmake for this task. Files are parsed and then some special tags are found representing function, variable or parameter documentations. In order to support multi-line comments this extraction needs to be extended. While searching the web for ways how to do this extraction and documentation generation in a more standardized way, e.g., by public available tools, I have found at least the sphinx "domain" extension to represent cmake commands and variables. This is available from https://pypi.org/project/sphinxcontrib-moderncmakedomain/ Thus, we just need to write the documentation in a cmake compatible way, put into an multi-line comment block at the beginning of the file and then run sphinx on the generated .rst files. I have written the corresponding extension in the file `extract_cmake_Data.py` in the MR https://gitlab.dune-project.org/core/dune-common/-/merge_requests/957 (branch feature/separate-cmake-files) In my opinion, the generated documentation looks nice in HTML format and additionally, the documentation inside cmake source files are better readable. What is your opinion on this? Should we support this way of documentation (in addition to the old way)? Best regards, Simon -- Dr. Simon Praetorius Technische Universität Dresden Institute of Scientific Computing phone: +49 351 463-34432 mail: simon.praetorius@tu-dresden.de _______________________________________________ Dune-devel mailing list Dune-devel at lists.dune-project.org https://lists.dune-project.org/mailman/listinfo/dune-devel -------------- next part -------------- An HTML attachment was scrubbed... URL: From foss at grueninger.de Wed May 19 21:09:37 2021 From: foss at grueninger.de (=?UTF-8?Q?Christoph_Gr=c3=bcninger?=) Date: Wed, 19 May 2021 21:09:37 +0200 Subject: [Dune-devel] cmake and buildsystem documentation In-Reply-To: <46a1108d-b569-0e53-8cd6-2f6503fb52db@tu-dresden.de> References: <46a1108d-b569-0e53-8cd6-2f6503fb52db@tu-dresden.de> Message-ID: <4ce8a61d-b002-6a62-4911-965411927115@grueninger.de> Hi Simon, I tried to understand the topic. Can help me? 1) https://pypi.org/project/sphinxcontrib-moderncmakedomain/ states: "This is taken directly from the Kitware git repository's Utilities directory." Why should anybody maintain a copy of CMake's utility folder? Is it not possible to use the file from there? 2) Further: "The original sphinxcontrib-cmakedomain has not been touched in quite some and as a result it wildly out of date." How is this repository related? 3) I welcome the general idea for having a nicer looking / better accessible documentation. But can it still be build without the newly introduced external dependency? Bye Christoph From simon.praetorius at tu-dresden.de Wed May 19 21:52:38 2021 From: simon.praetorius at tu-dresden.de (Simon Praetorius) Date: Wed, 19 May 2021 21:52:38 +0200 Subject: [Dune-devel] cmake and buildsystem documentation In-Reply-To: <4ce8a61d-b002-6a62-4911-965411927115@grueninger.de> References: <46a1108d-b569-0e53-8cd6-2f6503fb52db@tu-dresden.de> <4ce8a61d-b002-6a62-4911-965411927115@grueninger.de> Message-ID: <788e6524-f1b7-5f74-67e4-6d0181e75205@tu-dresden.de> I've just started to dive into this. Have not yet understood everything completely: 1.) This python package just provides two files from the cmake repository, that can easily be installed using pip, so if we do not want to get a dependency on the full cmake source package, this would be a minimal solution 2.) `sphinxcontrib-cmakedomain` is just another implementation of a Sphinx extension to understand cmake documentation tokens. It is outdated, though. 3.) I just wanted to find a way to document using the new multi-line comment blocks and to use the standard cmake documentation statements. This way we could import other cmake files and get the documentation included directly. I'm still experimenting, though. Maybe, if the license allows this, we could just include the two python files from cmake directly in our repository. Otherwise, this cmake documentation generation is purely optional and just used to generate online documentation files. It is thus only needed in one of our ci docker images and there we could easily add this additional dependency, since we added multiple other python packages recently as well. I'm not yet sure how everything works. It seems that there is a python script provided as sphinx extension that would allow to parse the cmake files directly. Then we do not need to first extract the documentation manually into an .rst file and then run sphinx on this. If someone is interested to look into this as well, I would appreciate the help. Best, Simon Am 19.05.21 um 21:09 schrieb Christoph Grüninger: > Hi Simon, > I tried to understand the topic. Can help me? > > 1) https://pypi.org/project/sphinxcontrib-moderncmakedomain/ states: > "This is taken directly from the Kitware git repository's Utilities > directory." > Why should anybody maintain a copy of CMake's utility folder? Is it not > possible to use the file from there? > > 2) Further: > "The original sphinxcontrib-cmakedomain has not been touched in quite > some and as a result it wildly out of date." > How is this repository related? > > 3) I welcome the general idea for having a nicer looking / better > accessible documentation. But can it still be build without the newly > introduced external dependency? > > Bye > Christoph > > _______________________________________________ > Dune-devel mailing list > Dune-devel at lists.dune-project.org > https://lists.dune-project.org/mailman/listinfo/dune-devel -- Dr. Simon Praetorius Technische Universität Dresden Institute of Scientific Computing phone: +49 351 463-34432 mail: simon.praetorius at tu-dresden.de web: https://tu-dresden.de/mn/math/wir/das-institut/beschaeftigte/simon-praetorius From A.S.Dedner at warwick.ac.uk Wed May 26 10:46:18 2021 From: A.S.Dedner at warwick.ac.uk (Dedner, Andreas) Date: Wed, 26 May 2021 08:46:18 +0000 Subject: [Dune-devel] Python/Build system meeting: Input wanted In-Reply-To: References: , Message-ID: Hi, I would like to discuss how to proceed with the next release and the new Python bindings. Perhaps we need another developer meeting? I see a few options: (a) We release 2.8 with the current master (I would like to do this really quickly if that is the decision taken). After the release, the new python approach is merged. (b) We merge these branches now. Since this is a more significant change we would then wait for a few month until releasing 2.8, i.e., end of the year. (c) We decide not to merge this at all - or someone suggest some major modifications. In all three cases there is a further question: should the Python bindings be turned on by default? I've already got the first email from Gitlab that in one of the modules the branch can't be merged anymore - with 10 modules with a corresponding MR this could become painful quite soon, so I would appreciate not to have to wait for too long for a decision (or at least to know which parts are contentious). I'm happy to meet up with anyone interested during the next weeks for example - let me know if that would be helpful. Otherwise, discussions on any of the details of the changes should be done in https://gitlab.dune-project.org/core/dune-common/-/merge_requests/960 That MR also contains an explanation of what is done - if something is unclear let me know. Greetings Andreas ________________________________ From: Dedner, Andreas Sent: 05 May 2021 12:37 To: dune-devel at lists.dune-project.org Subject: Re: [Dune-devel] Python/Build system meeting: Input wanted Dear developers. This is a follow up from an email from Dominic (on 05/02). Following the discussion, we had on the Python bindings and the build internal virtual environment, Dominic started work on making the changes along the lines of what we discussed. Over the last week I've made some changes to get packaging and some other thngs up and running again based on these changes. The main merge request https://gitlab.dune-project.org/core/dune-common/-/merge_requests/960 contains hopefully useful information on the changes and some of the consequences. I would suggest having a discussion on the changes there. There other core modules (and some others) have companion MRs (still marked WIP). Best Andreas PS: At the time we asked everyone interested to summarize their use cases for combining Dune and Python. I just went through that list again and think everything is addressed: Adrian: can use pip install (and even combine with own source module) Babara: will now get an internal dune-env installed which she might not want Can disable by disabling the cmake lookup of Python but that is perhaps not obvious to her - perhaps give her an easy flag to set? Clara: should be mostly fine - differences are documented. But I guess there are different viewpoints on this Dominic: should be happy since internal venv is now on by default Andreas: works fine for me Linus: Can't say for sure but hope he's happy? Robert: A bit like Babara, i.e., might get an internal venv he doesn't use Oliver: Embedded is still a bit of an issue which is mostly a venv problem 1. An external venv is used: then everything should be fine 2. the internal venv is used: make tests will be fine but calling a C++ code directly will fail since the venv interpreter is not used and the dune packages are not found. Needs to run build-dir/run-in-env ./test This is an issue with venv/embedded that has been discussed on the venv mailing lists but never fixed Christian: These issues are a bit separate from these changes and need to be discussed separately, I think. Some of the things mentioned should work already I believe. At least I hope that current changes don't make things worse. ________________________________ From: Dune-devel on behalf of Dominic Kempf Sent: 05 February 2021 16:15 To: dune-devel at lists.dune-project.org Subject: [Dune-devel] Python/Build system meeting: Input wanted Dear developers, we had a small meeting today that emerged from recent discussions on Gitlab issues + MRs to get an overview of the Python landscape in Dune. Participants were Andreas, Robert, Simon, Carsten, Samuel and myself. I think we made some progress, but we want to build on everybody's feedback to continue. We would like to collect a list of use cases formulated as fictional or non-fictional user profiles. Just add yours to the list: https://cryptpad.fr/pad/#/2/pad/edit/Cdg8eTGASWgdQetoM06emmp7/ This list will serve as the basis of discussion to converge to a technical solution that accommodates the needs of as many users as possible and allows a consensus to enable the Python bindings feature by default in the future. Best, Dominic -------------- next part -------------- An HTML attachment was scrubbed... URL: From foss at grueninger.de Wed May 26 23:27:56 2021 From: foss at grueninger.de (=?UTF-8?Q?Christoph_Gr=c3=bcninger?=) Date: Wed, 26 May 2021 23:27:56 +0200 Subject: [Dune-devel] Python/Build system meeting: Input wanted In-Reply-To: References: Message-ID: <5326ea03-15ad-e248-48e7-bc521f1fe365@grueninger.de> Hi Andreas, thank you for investing so much time to improve this topic! This applies to Dominic, Samuel, Robert, and however I forgot, too. I'd like to have a) and stick to a disabled Python for Dune 2.8. Right after Dune 2.8, merge 960 and enable the Python bindings by default. This should give us enough time to iron out any rough edges. My rationale: I don't want to delay Dune 2.8 any longer. And we should give it a proper testing by a broad number of users. Currently with the code from Git master thy Python tests are failing when I enable Python. This should not be the case, and is fix with 960, if I remember correctly. Bye Christoph -- Als wär es nix, leb' ich von [IT] und mach' nur, was ich lieb' Lebe wie im Paradies, womit hab' ich das verdient? Die Wahrheit ist: Hab' ich nicht, ich bin nur reicher beschenkt Als jemand in einem armen Land mit dem gleichen Talent [frei nach Tua von Die Orsons - Oioioiropa] From simon.praetorius at tu-dresden.de Thu May 27 11:26:16 2021 From: simon.praetorius at tu-dresden.de (Simon Praetorius) Date: Thu, 27 May 2021 11:26:16 +0200 Subject: [Dune-devel] Python/Build system meeting: Input wanted In-Reply-To: References: Message-ID: <3b6d2d55-9b20-11ca-4cfd-fb44395dd69f@tu-dresden.de> Hi Andreas, I'm also in favor of a). The python bindings are clearly a great thing. In order to thoroughly test it by a large community it needs to be enabled by default. Although it has improved a lot since our last meeting, I expect some corner cases to break. Fixing these will probably take time. Releasing now would allow to have an up-to-date stable release before we introduce these possibly breaking changes. I'm also waiting for a stable release before I start including other changes (cmake related). These are always a bit related to the python bindings because you also need cmake for the setup and you have written several cmake extensions. This needs to be aligned to the other cmake changes. I think merging both things in the same release cycle (step by step) and fixing incompatibilities by these two independent developments would also need time and is better done after a stable 2.8 release. So, in my opinion, we need to start now listing what needs to be done for a release that is independent of the python bindings topic so that we can start the release procedure soon. I think, Christoph has already listed a few topics that needed to be fixed before 2.8, but some/most of these points are already finished. Best wishes, Simon Am 26.05.21 um 10:46 schrieb Dedner, Andreas: > Hi, > I would like to discuss how to proceed with the next release and the > new Python bindings. > Perhaps we need another developer meeting? > > I see a few options: > (a) We release 2.8 with the current master (I would like to do this > really quickly if that is the decision taken). > After the release, the new python approach is merged. > (b) We merge these branches now. Since this is a more significant > change we would then wait for a few month > until releasing 2.8, i.e., end of the year. > (c) We decide not to merge this at all - or someone suggest some major > modifications. > > In all three cases there is a further question: should the Python > bindings be turned on by default? > > I've already got the first email from Gitlab that in one of the > modules the branch can't be merged anymore - with 10 modules with a > corresponding MR this could become painful quite soon, so I would > appreciate not to have to wait for too long for a decision (or at > least to know which parts are contentious). > > I'm happy to meet up with anyone interested during the next weeks for > example - let me know if that would be helpful. Otherwise, discussions > on any of the details of the changes should be done in > https://gitlab.dune-project.org/core/dune-common/-/merge_requests/960 > > That MR also contains an explanation of what is done - if something is > unclear let me know. > > Greetings > Andreas > ------------------------------------------------------------------------ > *From:* Dedner, Andreas > *Sent:* 05 May 2021 12:37 > *To:* dune-devel at lists.dune-project.org > > *Subject:* Re: [Dune-devel] Python/Build system meeting: Input wanted > Dear developers. > > This is a follow up from an email from Dominic (on 05/02). > Following the discussion, we had on the Python bindings and the build > internal virtual environment, > Dominic started work on making the changes along the lines of what we > discussed. > Over the last week I've made some changes to get packaging and some > other thngs up and running again based on these changes. > The main merge request > https://gitlab.dune-project.org/core/dune-common/-/merge_requests/960 > > contains hopefully useful information on the changes and some of the > consequences. > I would suggest having a discussion on the changes there. There other > core modules (and some others) have companion MRs (still marked WIP). > Best > Andreas > > PS: At the time we asked everyone interested to summarize their use > cases for combining Dune and Python. > I just went through that list again and think everything is addressed: > > Adrian: can use pip install (and even combine with own source module) > Babara: will now get an internal dune-env installed which she might > not want > Can disable by disabling the cmake lookup of Python but that is > perhaps not obvious to her - perhaps give her an easy flag to > set? > Clara: should be mostly fine - differences are documented. > But I guess there are different viewpoints on this > Dominic: should be happy since internal venv is now on by default > Andreas: works fine for me > Linus: Can't say for sure but hope he's happy? > Robert: A bit like Babara, i.e., might get an internal venv he > doesn't use > Oliver: Embedded is still a bit of an issue which is mostly a venv > problem > 1. An external venv is used: then everything should be fine > 2. the internal venv is used: make tests will be fine but > calling > a C++ code directly will fail since the venv interpreter > is not > used and the dune packages are not found. Needs to run > build-dir/run-in-env ./test > This is an issue with venv/embedded that has been discussed > on the venv > mailing lists but never fixed > Christian: These issues are a bit separate from these changes and need to > be discussed separately, I think. Some of the things > mentioned should > work already I believe. > At least I hope that current changes don't make things worse. > ------------------------------------------------------------------------ > *From:* Dune-devel on > behalf of Dominic Kempf > *Sent:* 05 February 2021 16:15 > *To:* dune-devel at lists.dune-project.org > > *Subject:* [Dune-devel] Python/Build system meeting: Input wanted > Dear developers, > > we had a small meeting today that emerged from recent discussions on > Gitlab issues + MRs to get an overview of the Python landscape in > Dune. Participants were Andreas, Robert, Simon, Carsten, Samuel and > myself. I think we made some progress, but we want to build on > everybody's feedback to continue. > > We would like to collect a list of use cases formulated as fictional > or non-fictional user profiles. Just add yours to the list: > https://cryptpad.fr/pad/#/2/pad/edit/Cdg8eTGASWgdQetoM06emmp7/ > > This list will serve as the basis of discussion to converge to a > technical solution that accommodates the needs of as many users as > possible and allows a consensus to enable the Python bindings feature > by default in the future. > > Best, > Dominic > > > > _______________________________________________ > Dune-devel mailing list > Dune-devel at lists.dune-project.org > https://lists.dune-project.org/mailman/listinfo/dune-devel -- Dr. Simon Praetorius Technische Universität Dresden Institute of Scientific Computing phone: +49 351 463-34432 mail: simon.praetorius at tu-dresden.de web: https://tu-dresden.de/mn/math/wir/das-institut/beschaeftigte/simon-praetorius -------------- next part -------------- An HTML attachment was scrubbed... URL: From foss at grueninger.de Thu May 27 23:39:07 2021 From: foss at grueninger.de (=?UTF-8?Q?Christoph_Gr=c3=bcninger?=) Date: Thu, 27 May 2021 23:39:07 +0200 Subject: [Dune-devel] cmake and buildsystem documentation In-Reply-To: <788e6524-f1b7-5f74-67e4-6d0181e75205@tu-dresden.de> References: <46a1108d-b569-0e53-8cd6-2f6503fb52db@tu-dresden.de> <4ce8a61d-b002-6a62-4911-965411927115@grueninger.de> <788e6524-f1b7-5f74-67e4-6d0181e75205@tu-dresden.de> Message-ID: <5d15d803-7130-5525-1108-bdede536d1b0@grueninger.de> Hi Simon, thanks for your explanations! > 1.) This python package just provides two files from the cmake > repository, that can easily be installed using pip, so if we do not want > to get a dependency on the full cmake source package, this would be a > minimal solution I missed that, the source files are not part of CMake, they are only available if people checkout CMake sources. This dependency would be bad. Having it installed from pip sounds great for people using it. If the files are not present, the Sphinx output would not work, right? I am unsure whether we can accept that or not. I tend to accept it, it is just a second dependency besides Sphinx to build the CMake documentation. > 3.) I just wanted to find a way to document using the new multi-line > comment blocks and to use the standard cmake documentation statements. It would be create to get these changes upstream into Sphinx. Not sure how likely this would be. > Otherwise, this cmake documentation > generation is purely optional and just used to generate online > documentation files. It is thus only needed in one of our ci docker > images and there we could easily add this additional dependency, since > we added multiple other python packages recently as well. For people writing CMake documentation it is also needed, but this is acceptable to me. > I'm not yet sure how everything works. It seems that there is a python > script provided as sphinx extension that would allow to parse the cmake > files directly. Then we do not need to first extract the documentation > manually into an .rst file and then run sphinx on this. > > If someone is interested to look into this as well, I would appreciate > the help. The code is not obvious, would need more time to read it more thoroughly. Bye Christoph -- Als wär es nix, leb' ich von [IT] und mach' nur, was ich lieb' Lebe wie im Paradies, womit hab' ich das verdient? Die Wahrheit ist: Hab' ich nicht, ich bin nur reicher beschenkt Als jemand in einem armen Land mit dem gleichen Talent [frei nach Tua von Die Orsons - Oioioiropa]