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

This new status update attempt to summarize my professional activity for February. I tried to make it shorter but failed.

On the teaching front, I further adapted my teachings 90 minutes-long sessions (instead of 120mn last year) by removing many useless details of my lectures (in French).

This year, I introduced OO modeling through the classical Class Responsibility Collaborator methodology, and we rewrote with Killian the exercise explaining the kind of objects in memory (static, dynamic, automatic and temporary objects). This is now the third year I teach the C++ class, and I have the feeling to really deepen my understanding. My thinking about Hare pays off here, even if I'm not sure that I like C++ at the end of the day. I mean, I never really loved this language, but I now clearly see the cost of its complexity.

I managed to attend to several lectures given by Simon about compilation, and I'm behind wrt the associated project even if I spent several afternoons on this. Too bad I could not attend all practical sessions to get at full speed, but my agenda didn't allow. The project is in Java, another language that I used to really like. Now, I'm really uncomfortable with the fact that you don't see from the code whether a variable is an object on the heap passed by reference, or a scalar on the stack passed by value. The code looks easy, but there is too much you need to know to fully understand its semantic.

Jade Garcia Bourée did everything for our pedagogical module as a TA, and I did not even review the contributions that my students did to the CS unplugged activities this year. Within the Facto ANR project, we worked on a new unplugged activity explaining CSMA algorithms with (real) walkie-talkie. We'll post it online when it's ready, but it looks rather appealing already.

On the administrative front, I mentored the 18 first-year students to help them find an internship topic somewhere in France for this summer. None of them will do this internship with me, so I have the feeling that I did it right, serving the students before my own interest. It would have been great if one of them decided to study my topics, but it did not happen this year, and that's OK.

On the SimGrid front, we spent 2 days in Grenoble with Mathieu to visit my friends in the Polaris team. Our first topic was about exploring the state space of classical parallel and distributed applications, statistics and random walks. This team counts great experts of the theoretical characterization of practical P&D applications, a perfect match for Mathieu's PhD topic on guided model-checking for asynchronous distributed applications.

We also discussed with several faculty members in Grenoble teaching MPI and multi-threaded programming. We presented our tools and proposed to assist their students with these tools during the classes. This should give us some interesting feedback, and many new bugs to detect and dissect in the experimental section of our upcoming papers. We need that because the rest of the month on that front was mostly about finding bugs in SimGrid while searching for bugs in existing programs. The remaining bugs are subtle and vicious: they wrongly cut branches in the exploration, hindering the soundness of the exploration. We don't find bugs in the analyzed programs, but we don't know whether it's because the code is genuinely correct or whether it's because of a missed branch. Meh.

Personally, I was marginally more productive on SimGrid this month. I wrote a small patch allowing to continue the exploration after the first deadlock. The first use is to find the shortest possible counterexample even if it's not the first encountered one, but Mathieu will also use it to do some statistics about the kind of branches that lead to deadlocks.

I fixed the bug I introduced in December while refactoring the timeout detectors in SimGrid for consistency. This lays at the very core of the framework, and the previous code was really intricate. My change broke an obscure test in SMPI wrt communication cancelation. This code is so frightening, with many long-range interactions between seemingly unrelated modules, that it took me 2 months to dare debugging it. The fix was actually trivial. During the refactoring process, I intentionally introduced a failure in a seemingly redundant code branch to simplify its removal in a subsequent round of refactoring. However, instead of triggering an immediate failure using the DIE_IMPOSSIBLE macro, I inadvertently raised an exception using the THROW_IMPOSSIBLE macro. Unfortunately, this exception was caught in another part of that code, hindering the proper detection that this code branch was actually useful. I'm ashamed that it took 2 months for such a simple fix, but hopefully this will restart my efforts to complete the implementation of sthread, a model-checker of pthread programs using SimGrid.

I did not implement the idea where we fork the application while exploring a branch in order to quickly backtrack it without having to replay the trace prefix again and again. This would be very handy for Mathieu's quest for a wild bug (a bug that we did not artificially add to the code), but I was too afraid to dig into that quite complex system-level code. The last bug I should be fixing is about inter-netzone routing. This one is maybe less complex than the other ones, but I don't like the routing code in SimGrid, for historical reason. The first version of that code was written by an intern. It was so buggy that we spent months to fix it afterward. Now, my skin starts to crawl each time I have to work with this code. Anyway. I should be simgriding, for sure.

On the SmolPhone front, the first good news is that the project proposal we wrote with Simon got accepted. Inria already said that they cannot fund it as much as requested, but they will help us for sure. It was quite expected unfortunately since the French government keeps cutting the funding of every public institution (the worst budget cut for french research in 15 years was voted 3 days ago), but being supported is already good news. Maybe we should hire an external service provider to make it cheaper, but this kind of contract is always very complex to settle given the differences between public administrations and private companies. I hope that we won't have to go that way. Even buying elements for our prototyping work is so difficult that we often buy the small pieces with our own funds. I bought a screen and a bunch of BlackBerry keyboards while Simon paid for the first prototype of PCB (that is still to be soldered). To solve this, we discussed with a colleague at ENSSAT, an engineering school with a large electronics department. He will propose to his students to work on a prototype of the SmolPhone hardware. This is a great news, as it could help us to break that lock preventing the project to really take off. I wish we get a first working prototype before the end of 2024.

Concerning the software side, Aloïs did great this month, even if his cat broke the only PiZ that we had (Joseph's personal one). He is using is laptop as an applicative processor for the experiments for the time being. Since the PiZ and the 2040 are supposed to be interconnected in USB anyway, this setting remains somewhat realistic. It's still a pity because we cannot measure the consumption as we intended to, but Aloïs is not blocked. He built a demo where the 2040 request the applicative processor to render a GPS tile from the OpenStreetMap data, and get the image back on the 2040. Since we also don't have a keyboard (the ones we bought are not soldered yet) nor a GPS chip (we didn't even choose one yet), he will now work on displaying the rendered tile on the screen. He will also do some more lit review until the new PiZ arrives and until the keyboard is soldered. That's very good, I think we will submit a paper somewhere before the summer. BTW, I got my fourth rejection in a row. I should probably submit fewer papers and work them more carefully.

Concerning the cloud side of the SmolPhone, we brainstormed with Anne-Cécile and Olivier Barais (a researcher in software engineering in our lab) about the rendering of HTML in constrained context. I discovered Carbonyl, a modification of the Chrome engine that can render in the terminal in ascii art. It is impressive, but that's not the path I'd like to take as it brings the whole complexity of Chrome with it. Gigabytes of source code just for the rendering of information does not sound really lowtech. Another interesting but off-topic project is Servo, an ultra-modern rendering engine that sounds exactly as complex as Chrome. Being written in Rust instead of C++ does not solve my problem wrt the complexity. Instead, we will try to propose an internship to Olivier's student on a subset of HTML+CSS+javascript that would be sufficient to cover useful webpages (such as transportation networks or Wikipedia) while being small enough to be easily rendered. I should be writing the internship proposal.

Finally, I did a presentation on the SmolPhone while in Grenoble. It gives more background and motivation that the previous presentation in Toronto, along with the current technical state. In the presentation aftermath, Frédéric Wagner (a researcher of the Polaris team) demoed his GPS navigation code which runs on a Bangle2 watch. This is really impressive, given that it runs on a very small microcontroller (4mA consumption at 100% is 25 times less than the RP2040 that we envision for the SmolPhone and that I found really tiny already). It has 256kb of RAM, and Fred still manages to load the whole path of his bike ride to navigate the map in full network autonomy for several hours. Pretty amazing. It makes me more confident in the fact that this whole SmolPhone story is actually doable, somehow

On the Hare front, I spent a lot of time further discovering the language. I really like the philosophy of minimalism and maximal efficiency with no bloat, but at the same time, the language drives me nuts. It's not mature enough to envision its use in the SmolPhone so far, so I still have to think in Rust for our developments for now, unfortunately. I'm also completely convinced by some choices of the Hare community. Please take the following elements with a pince of salt. I'm new to the language and may miss some parts yet.

• The answer to encapsulation seems suboptimal: "simply omit the documentation of private fields, and people will not use them". I think it's a pity to rely on such a muddy rule where things could be enforced automatically at no cost with only some support from the language.
• To me, the modules are also missing a way to differentiate between public imports (imports that should be passed over to the users of this module) and private modules (the ones that are only used in the implementation and should be hidden), but that will probably be solved at some point.
• I would also like to have the dotted notation to call obj.do_thing(a, b) instead of class_do_thing(&obj, a, b). I'm not sure that this will ever occur in Hare, but that's probably something I could live with.

• Finally, I am uncomfortable with the fact that there are no generics. I fully understand their thinking that they don't quite fit into the language, and that monomorphisation leads to bloated binaries and large compilation time. But despite what Drew says, I agree with Ayende Rahien that optimizing the containers lead to better and faster software. When we started the rewrite of SimGrid from C to C++ 10 years ago, we were a bit concerned about performance because our code was highly optimized, but we wanted to make the code easier to work with for newcomers, free from our private habits and custom constructs. Now that this rewrite is done, the benchmarks shown below say that the C++ version (v4) is much faster and consumes less memory than its C counterpart (v3). It may be easy to write a hash table for a simple example, and I wrote one too, but writing highly optimized data structures is much more demanding, even justifying researches to push optimization to its limits.

  

  The language is still young, so things will probably evolve. After all, Go added generics after a while (and benefited from a performance boost). Maybe approaches for generics without monomorphisation could be investigated, such as parametric polymorphism used in Haskell, or maybe even unconventional ones. Or maybe simplicity is preferable to efficiency, as said by Florence Maranchini, Ville-Matias Heikkilä or Devine Lu Linvega. After all, the performance of SimGrid v3 was never seen as a problem, to the contrary actually. I don't know. I just don't know. I will live without generics for now.

• The ecosystem is technically unsettling, and I discover that I never really contributed to someone's else project. Maintaining feature branches is not trivial, and the fact that Hare uses a mail-centric workflow while emails usually only bring me spam and broken work injunctions hinders my work in this community. But I'll get used to it eventually. At least, this workflow is consistent with the quest for less bloat in our tooling. Webapps are harmful like the sugars of fast foods.

I still see Hare as a very promising initiative, and a refreshing environment in our bloated world. The main issue right now lays in the tooling, so I implemented a debug malloc that can keep track of the leaked blocks and of double-free errors. This could be improved further by preventing use-after-free errors, but this would require to store the metadata away from the blocks (as done in dmalloc), but I didn't feel like implementing a skip list to that extend, as in dmalloc. My patches are currently reviewed for integration, but they already allowed me to find and fix about 100 memleaks in the tests of the Hare standard library. I did not find anything useful so far, only little mistakes in the test codes.

One interesting aspect of Hare is that the authors claim that they want to implement some sort of borrow checking in their language at some point. David Baelde (a colleague of mine) and Paul Adam (his student) work on a borrow checker for a toy language, mostly to understand this mechanism. They were happy to use Hare when I proposed. This is great, as the needed syntax and semantic remain rather hazy so far. Their work could help formalize things before an implementation by the Hare community.

This, along with the compiler passes class I'm taking this semester, has sparked my interest in type checking. There are some patches in the Hare community to which I would like to contribute next if possible. I am also curious about why the big ideas making Ada a language of choice for secure codes did not make their way to the new C competitor such as Hare, but also Odin, Zig or C3.

On the other fronts of frugal computing, I discovered sxmo this month, a frugal environment for mobile computing that aims at empowering advanced users with highly scriptable interfaces. That resonates with my goals of lowtech computing, and I definitely need to investigate it further. I already found mepo, a highly hackable OSM viewer (written in Zig and hosted on SourceHut). Aloïs uses it in his demo: the scripting interface allows the 2040 to efficiently drive mepo running on the applicative processor. More on this next month, hopefully.

On the other open-source fronts, I uploaded the latest version of the ns-3 package to Debian. This code is crazy: I need 15 Gb of disk and over two hours to build the package on my fast machine. That's quite a lot of code. SimGrid is only one tenth of that size, and it contains a model checker and a complete implementation of MPI. I'm unsure of why there is so much code in ns-3, but anyway.

I also improved the config file parser in po4a. Last month, I wrote a function to split the command line correctly with quotes and escaped spaces, but simple and double quotes could not be nested. Of course, at least one package (apt) was nesting quotes and broke with the new version. The new version correctly deals with simple and double quotes (possibly nested) and with escaped spaces, but I found it surprisingly hard to write. I could not find any working code on Stack Overflow, so I ended up posting my own version there. My first real post on SO.

I launched the process of a new po4a release asking translators to update their work during a string freeze, just to receive a new bug report. The version released last month also breaks debhelper, which had a very inventive configuration file. Because of some Perl magic behavior, this misconfiguration used to work before the introduction of PerlIO in po4a but it is not the case anymore. I fixed the new issue, and launched yet another string freeze for an upcoming release. I must say that I like this little project very much. It's of managable complexity, enjoys a real community of users and contributors. The only issue is that it's written in Perl, a language full of ancient magic.

On the reporting front, I must say that this idea of writing one status report per month may be potentially harmful and leading to workoolism, just like the GitHub streak. I'm uncertain, but it's possible that this has led me to become overly involved in my professional activities. What I do know is that I don't typically work this much, but I'm unsure whether it's due to the reporting activity ("I must have more content by the end of the month"), or because these projects are new and exciting to me. If this effect gets confirmed, I'll probably stop have to these reports to preserve my sleeping time. I confess that I'm very sensitive to such effects. My GitHub streak had a really great effect on the SimGrid project, along with a rather bad effect on my well-being back then. On the other end, I love this situation where the SmolPhone makes me speak with nice colleagues of various topics to try to gather the forces of many people on a nice tiny project. Will see how it turns out.