Other reports for 2024: January, February, (March), April.

This new status update attempts to summarize my professional activity for March. It was a very active month on SimGrid and also quite a bit on teaching, but I did not completely give up on the SmolPhone. My other projects went under the radar for this month.

On the teaching front, I got further in OOP in C++. I introduced the concepts of encapsulation and inheritance, then we took a look at the implementation of C++ in terms of memory layout and name mangling to explain the difference between trivial and non-trivial objects when it comes to overriding, overloading and overwriting. I wrote a new homework on the expression problem, and reworked the existing homeworks. The next lectures are about smart pointers and functional programming in C++. I'm quite glad of this class: I seem to really understand this language now, and even manage to explain its intricate behavior to the students. I think that I'm now ready to move to the next level, and teach Rust on top of it next year.

I was also more active than previously on the pedagogical module this month. I reviewed and integrated the first students' contributions to the unplugged activities. As usual, these contributions are very good. Altogether, the activities described in this repository constitute a solid material, and I should clean things up to make it easier to find the activity you are looking for.

I attended some more lectures given by Simon on compilation, but since I gave up on the associated project, I'm not really into it. We discussed a bit of the possibility to rebuild that project on top of the homework I wrote on the expression problem. There is maybe something to do here, but I don't know when we will find the time.

On the administrative front, I was involved in discussions about the future of the local master curriculum on CS research, but I find this topic a bit too depressive to discuss it here. Things are not going in the right direction, IMHO.

This month, I was really active on the SimGrid front, much more than January and February. I implemented a feature where the verified application is forked regularly to allow fast rollbacks from an intermediate state. That's fast and allows much faster explorations of the state space. If you don't fork only one tenth or one thousandth of the states, the memory usage remains under a few gigabits, so that's excellent news. I hope that it will enable the discovery of a previously unknown bug with this tool, aka The Wild Bug that we are hunting since over a decade now.

I restored the ability to verify Python scripts. Our Python bindings mandate the threaded context factory, because we didn't manage to get our optimized context factory working with the Python Gran Interpreter Lock. But POSIX mandates that when a multithreaded application forks, only the calling thread is copied in the child process, which makes it impossible to mix system forks and the SimGrid threaded context factory. This broke not only the feature described in previous paragraph, but every verification of Python scripts, since the application is forked right after the initialization in any case, to not reinitialize the application when rollbacking to another state. As a response, I added an option to the model checker to not use any fork. Instead, the python interpreter is restarted from scratch each time we need to rollback the application. That's really slow and gory, but at least it seems to work. It will probably break if an application behavior's depends on the memory layout (for example because it sorts elements according to their address in memory), because the memory layout is computed randomly upon application start (that's because of the ASLR). So, if the actions of your Python application depend on the order of elements in memory, the verification in SimGrid may well fail in awful ways. But that's not something we have seen so far, so I hope that it's ok to assume that this will not happen.

I implemented condition variables in MC and in sthread, so we are now able to verify the POSIX programs using that mechanism. MC required the asynchronous version of this mechanism to preserve the transition persistency, which was not trivial given the complexity of the condvar semantic. Mathieu implemented the corresponding independence theorems. I'm almost done implementing the iprobe semantic in the model checker, enabling the verification of MPI programs containing calls to MPI_Iprobe, i.e. the most interesting ones when you search for bugs.

We received the first codes from our colleagues teaching MPI in Grenoble and started exploring then in the hope to find our first natural, non-synthetic bug, but we found nothing so far. I keep faith!

I fixed a nasty bug where the canceled activities were not cleaned ASAP but only upon actors' termination. I lost half a day to enable the execution of crazy simulations, canceling activities like hell. I must say that I'm not 100% convinced that it was the best possible use of my time, but it's fixed now. The good news is that teaching C++ now give me a sufficient understanding of that language to address such bugs. Plus, maintaining software involves such commitment to the source code, there is no way around it.

A bunch of new bugs were reported by the users, but I did not dig into it yet unfortunately. It's really difficult to get motivated to fix subtle bugs in an advanced piece of code like SimGrid that is not widely used. It's something that I feel necessary (for the users) and useless (in general) at the same time. I'll try to fix them faster than they get reported, let's see how it goes.

On the publication side of SimGrid, Henri and Fred resubmitted a new version of our journal paper on SimGrid4. The first attempt was returned as a "major revision". As usual, we cursed the reviewers when we got their comments, but after implementing their suggestions, we must agree that the paper is now better than our first submission. I hope that this version actually gets accepted, as I wait for this moment to reuse some part of the article text in the documentation before actually releasing SimGrid 4.0.

On another aspect of SimGrid, we finally managed to publish a first paper on the TANSIV project. This project is about interconnecting VMs through a network simulator to enable the study of unmodified applications. The ultimate goal is to enable the study of malwares that would use the network to detect the analysis sandbox and evade it. We work on this project with Mathieu and Louis since maybe 5 years, and Léo is in its second year of PhD on that topic, so I'm very glad that this paper got accepted. It's mostly on the security aspects for now (how to ensure that you really are seamless to avoid the detection by the malware) while I'm personally more interested in the performance aspects (how to ensure that you really return realistic results). Yes, even if TANSIV encompasses both aspects in the same technical framework, the security and performance aspects of this work are not perfectly aligned, because malwares don't really know about what the performance they would get in reality, but they can easily detect performance glitches and irregularities.

On the SmolPhone front, things progressed smoothly even if I was not personally involved in the technical implementation of anything. We wrote one internship topic on the design of a first hardware prototype. It's tuned for the M1 students from the ENSSAT school, but everyone is welcome to apply of course. We wrote another internship topic on the remote rendering of HTML pages mechanism that the SmolPhone will need to display HTML5 pages using a dedicated cloud service. We do not have any applications for these internships yet, but it's a bit too early to get pessimistic.

On the software side, Aloïs got the first measurement we need, and we submitted an abstract to the poster track of the ICT4S conference. I think that pieces will fit together for a nice submission.

On the funding side of the SmolPhone, we had a first meeting with Inria officials about our "action exploratoire", but I'm late doing the actual paperwork to launch the process. I'm quite confident that it will get fully accepted, and that it will take the whole project from a nifty side project of a bunch of friends to a full speed research project. At least, I hope so.

I did not do anything on the Hare front nor on other frugal computing projects this month.

On the other open-source fronts, I released a new version of po4a, only to get a bunch of new bugs to fix. Maintaining an obscure software that is actually used by only a few dozen of people in the world is not really rewarding. Cinderella was dreaming for her prince, I'm quite dreaming for my co-maintainers (in both SimGrid and po4a, actually). I definitely understand how things like the xz backdoor could happen.

I uploaded a new version of Zeal to Debian to avoid a FTBFS due to the upcoming upload of Qt 6.2.2. That was quite easy for me, as I only had to cherry-pick a commit from upstream.

I integrated the NMU of several of my packages due to the 64 bits time_t transition. That too was easy, as I just had to integrate in my git repository the patches I got in the Debian bug tracker. I'm glad to see that Debian is dealing with such issues, doing its share of the work in the FOSS world. But at the same time, it's always a pity to see that the Debian workflow is so different from the git workflow. Since a git repository containing Debian packages usually relies on 3 branches (one for the upstream source, one for the Debian changes and one for the pristine archives), it's rather difficult to do a pull request on such a repository, making it difficult to interact between Debian maintainers on a git forge such as GitLab. That being said, it's not worse than the usual Hare workflow: you exchange patches per email, and people merge them manually in git.

By the end of the month, new upstream releases of quilt and widelands were announced, but I didn't update the corresponding packages yet. Quilt is quite an impressive piece of software: its breakages are very intrusive on Debian as it's used by maintainers to modify the Debian-specific changes of each package. Quilt is not used during the build of individual packages (dpkg uses the quilt files directly), but preventing Debian maintainers from working is already shameful enough to justify that my package often lags several versions behind the upstream version, and that my list of patches that I should review and submit upstream is getting rather long. Quilt is co-maintained in Debian, but I always feel I should do something instead of relying on my colleagues. Widelands is much simpler to package, but it requires a large amount of disk space, and I messed up the partitions on my new laptop. 30G for / and the rest for /home is not a good idea. I need to resize it all, but that's not a trivial task. I'd first need to update my backups.

On the reporting front, things really improved as you can see. Compared to last month, I'm more focused on fewer fronts. And I do not take this reporting thing as seriously as I did. The price for this is that I'm late by at least one week for this report, but that's not a big deal. I already started accumulating facts for my next reporting, but who cares if this reporting is a bit late? If you do, thanks a lot. I'm sorry for the delay and I'll see you next month