Week one
Hi everyone,
with a little delay, here it is: my first “post of the week” after the opening of this blog! :-) I’m going to talk a little about the community bonding period and the progresses on my project.
The community bonding period
As you may know if you are familiar with the GSoC, we are now in the period called “Community bonding”. According to Google, it’s a “vital part of the GSoC experience and is intented to get students ready to start contributing to their organization full time in May”. To put it in a nutshell it consists in taking part in the mailing lists, setting up its development environment, participating in code reviews, reporting bugs, reading documentation, etc.
Therefore, I’m taking this “Community bonding” very seriously, especially since it is a good occasion to prepare myself for the coding period, in order to be more efficient. After reading all the recent emails in the mailing lists, I chose to review a document, wrote by one of the main developers and entitled “How to get started with DUNE”. It’s actually more easier than doing some code reviews on a code base I don’t know (and where I have absolutely no detailed overview) and it’s very useful to dive myself into the project. Actually, this work has even occupied me several hours and continues to do so. I had some troubles with the building system, found a bug and patched it (even if there was already a merge request on the GitLab patching it but it’s another story :-°), had a big problem when my / was full because of the software I installed (so I have had the good idea to break my filesystem with resize2fs after GParted didn’t want to start its GUI on my virtual machine due to some bad video settings), re-installed all my virtual machine and re-set up my development environment and finally took a day to compile paraview (2% of the total compilation taking 1 hour with one core of my i5). To be honest, I didn’t expect the review to be so rich in events!
About the Python bindings for the DUNE grid interface
In parallel, I communicated with one of my mentors to precise my future work on the bindings. And it’s very interesting because I didn’t expect that providing Python bindings for a C++ sofware would be not so easy, when I first considered the project. In fact, I had that prejudice about language binding, which I thought to be a simple translation from one language to another (a kind of a non-automated copy/paste).
In reality, I realized with my junior jobs that providing bindings for a software is far more complex than that. Indeed, it’s like designing a facade pattern: you have to design an API for a set of users who use an other language and thus, you have to respect the “philosophy” of that language while making at the same time the sofware easier to use. Finally, it requires a good overview of the base code and it means thinking about the “concepts” introduced in the software rather than the class implemented.
Moreover, since DUNE is written in C++, it uses a lot of compile-time techniques to ensure efficiency. Techniques like template programming, inlining, use of constexpr, etc. And Python being a dynamic language, it thus requires a lot of thinking about how adapting DUNE concepts - implemented using compile-time techniques - to be used in Python, in a dynamic environment. For example, I talked a little about that with one of my mentor who highlighted the fact that some classes are templates parametrized by some static code provided by the user himself. He told me he was investigating a database approach where each static code provided by the user would have its import information for generating the shared libraries (= the python bindings) on demand. This is just an example of how the things can get tricky!
Finally, there is also the question of providing bindings that are maintainable and easily extensible. Indeed, we took the approach of using boost::python. What if we want to change that in the future, using pybind11 instead for example? Thus, it would be nice to have some concepts for exporting classes that would ensure the same approach for exporting classes is always used and that would facilitate switching to a different exporting mechanism. I started to investigate on this yesterday. Since boost::python is a complete header library, using (template) metaprogramming, I chose to begin by reading some documents about metaprogramming (especially the dedicated chapter of “The C++ Programming Language” book). I not already came up with some solutions for the problem but I hope I will in the following days and it surely something I will talk about on this blog!
What next?
This concludes my “post of the week”, I’m going to continue investigating metaprogramming to see how to wrap boost::python and also continue my review of “How to get started with DUNE”, I keep you in touch!