On 8 Jul 2015, at 20:10, Comer Duncan <[email protected]> wrote:
> Erik, > > I agree that the Carruth (sorry for misspelling his name in my previous > post!) talk is a good intro to what's currently possible. He is a bit quick > but covers many interesting an relevant topics for a developer in the > trenches. If clang-format gets adopted by the ET team, then I would > recommend a document to lead new users who want to use it through some > Cactus-related examples. > > I also wonder about the following: if users do use Kranc as a thorn > construction tool (as I hope becomes a popular choice (although I am at the > beginning of learning to use it!)), when Kranc does its thing maybe have > clang-format used as a backend so that when users use the Kranc route the > resulting code had had the benefit of passing through clang-format. That > would seem to help guarantee any new thorns would not have a need to be > filtered until the user makes changes to the *.cc files in the thorn. Of > course one would want to make sure that the backend clang-formatted files > result in executables that are at least as fast as not using clang-format. Hi Comer, Yes, it would be good if the code generated by Kranc adhered to some formatting guideline. However, I want to stress that the intention when developing a thorn using Kranc is that the generated code should be treated as if it were an object file or executable; it is definitely not recommended (apart for debugging) to edit the generated code. This would prevent you from editing the original Kranc script and regenerating the code without losing your source code edits. Generating a thorn with Kranc is not a one-off operation; you expect to do it repeatedly. It shouldn't even be necessary to read the code; think of Kranc as a compiler. Now, of course, compilers have bugs, and Kranc undergoes much less testing and review than GCC or the Intel compiler, so looking at the code generated by Kranc is not a bad idea from time to time. Having said that, people do often want to add features to their thorns which are not supported by Kranc itself, and if you aren't supposed to edit the generated code, this is difficult. Modifying Kranc to support the feature is one option, but it might not always be appropriate. I have added a feature to Kranc which allows you to "merge" a directory containing modifications with the generated thorn. Files which already exist are appended to, and new files are added. This allows you to keep a directory of "modifications" to the generated thorn separately, and these are applied every time the thorn is regenerated. I haven't tried it, but this should allow you to define additional source files (assuming that these can be added to make.code.defn by appending only), add schedule, interface and param CCL items, etc. You can also add documentation and test cases this way. On the other hand, Cactus is supposed to be used as a modular system, and if the new feature could be added in a separate thorn, then it might be usable with other thorns as well, so if possible, this is probably what you want to do. -- Ian Hinder http://members.aei.mpg.de/ianhin
_______________________________________________ Users mailing list [email protected] http://lists.einsteintoolkit.org/mailman/listinfo/users
