The design of distributed applications in Lingua Franca requires care, particularly if the coordination of the federation is decentralized. The intent of this post is to illustrate and handle the challenges arising from designing distributed applications in Lingua Franca, with the help of two realistic use cases.
Deadlines in Lingua Franca serve three purposes: they specify real-time requirements, guide scheduling, and provide fault handlers to invoke when real-time requirements are not met. But they can be subtle to use, and, do not guide scheduling as much as we would like. This blog outlines the current state of affairs and lays out ongoing work to improve the situation.
A deadline specifies that the physical time at which a reaction starts minus the logical time of that reaction (a time difference called the lag) should not exceed some threshold. If it does, then the deadline violation handler is invoked rather than the regular reaction.
Deadlines expose a number of scheduling subtleties because unrelated reactions can cause a deadline violation. Moreover, many users wonder why the deadline refers to the physical time at which a reaction starts rather than the time at which it ends. Here, we explain some of the subtleties.
Programming languages like Python, Rust, or JavaScript are popular not only because of particular language features, but also thanks to the quality of the tools and packages they offer access to. A good and mature ecosystem includes features such as developer support, mainly through IDEs or LSPs. Lingua Franca already shines in this area with its VSCode integration that offers functionality like code highlighting, error handling, build support, and diagram synthesis. Another important aspect of a modern language's ecosystem concerns package management. Although it is possible to import reactors from files in the local file system, support for packaging in Lingua Franca is still in its infancy.
We have a new website! Most importantly, this website is the home of our documentation.
After careful consideration, we realized that our original website had become overly intricate to maintain due to its numerous customizations and dependencies. Writing comprehensive documentation is already a challenging and time-consuming task, and we were keen on avoiding additional complexity that could hinder our progress. Additionally, we had a wishlist of new features, including the ability to version our documentation, incorporate a blog page, and provide support for MDX. In pursuit of solutions, we explored various options.