 Hello, good morning again. Now, yes, I am for myself, Pablo Besone. I am with Carolina Hernandez, and we are going to present Bustrapping Minimal Reflective Language Kernels. That basically is something that we use for Faro itself, but we want to be able to use for other tools. I am with Carolina Hernandez. She's a PhD student. She's working a lot in the Bustrapping of Kernels using Faro and the tools and the problems that we have on them. So, the question should be, I will do a little introduction of the problem that we have, and she will provide the solutions to them. Well, this is my, I am myself. I am a Faro engineer. I work in the Faro Consortium. I basically, my job is trying to take the innovative ideas and the nice things done by researchers and try to do it then for real with an industrial quality on some time of trying to do it for real. So, what are crafted kernel languages? Well, basically, the idea that we have is that we want to produce as many languages as we need. We want to produce as many runtimes as we need. We need to produce, to have the ability to produce languages and runtimes for small domains or languages and runtime for specific domains. And we want to have a given language that give us support for implementing our problem. But also, it gives us all the tools that we need, but not much more because we want to have small languages. Why? Basically, this is used for IoT, for all the resources constrained devices that we can have. But also, it can be useful when we are paying by resources. For example, if we are using cloud computing or if we are using virtualization, we want to improve the usage of resources. So, we only want to pay what we are really using. But, as this is a piece of software, we have to generate it from the source code. We have to compile it. We have to deploy it. If it has some kind of problem, we want to debug it. And we want to update it. So, if we take our system, so big system, and we start reducing it, and we remove, for example, the debugging capabilities, how we debug it? So, we will have to have shipping in the small runtime, all the debugging capabilities. Or if we want to update it, well, we have to also keep the updated. So, we want to try to see what are the tools required to minimize this overhead, and still be able to debug the system, update them dynamically, and develop them in a nice reproducible way. So, our proposed approach is use a high level bootstrap where we have a language that uses a lot of reflection where we can define in our small language, in our small runtime, a lot of the operations, a lot of the required reflective operations to do these modifications. We want to generate them, this small language and kernels, by doing a bootstrap. This is normal. We want to start from the source code only. But we want to do it in an environment and set of tools that allows us to debug it, to update, and to deploy this working in a high level. We don't want to be crafting the language kernel really by hand because it takes a lot of work. Actually, we are using a bootstrapping process for Faro itself. But the problem with that is that this bootstrapping process is very complicated. We need to master a lot of things to know before I be able to touch it without crashing. Or you start touching and run the full bootstrap, it fails. Touch again, it fails. And it takes a lot of time. So we want to have really good tools that use the reflective features, uses the ability to interpret the language and to simulate it, and give us better bootstrapping tools. So this is in part some development to improve our life like developers of Faro to bootstrap new versions of Faro, but also it can be extended to bootstrap smaller kernels and smaller applications. So basically, the context that we have now in Faro is that we have a language definition or a runtime definition that is basically a source code, a small talk source code that we execute. This small talk source code is run inside a pre-existent Faro that we will generate a new image executing the code and the bootstrap step by step. This problem is that touching the modify in this source code requires a lot of knowledge or a lot of patience because it is a lot of trial and error. Once the full Faro image generates a small image of the kernel, it can be executed itself independently in its own virtual machine. However, I will pass now to Carolina. This can always fail. Or most of the time, this fail. That is the problem. OK. So as Pablo was saying, yes, the bootstrap process is complicated. And the thing is that it requires a lot of expertise to debug it and to basically modify the language definition. So the problem specifically is that inside the language definition, if we have unintended errors, which we will call defects, they will generate failures during the bootstrap process or during the execution of the kernel after it was deployed. So yeah. It can happen that some defects prevent the kernel from generating. And that's fine. We can know ahead of time. But the problem is some kinds of defects they will manifest only after. So we will generate a buggy kernel, which will fail here. And the problem is that in here, sometimes we are running this small kernel in a resource constraint device, which, given the fact that the kernel is small, we don't have debugging support. We don't have, sometimes, the layer of communication to debug remotely. So this is the challenge. OK. What do you want? What do we want? We want to open the bootstrap process to the community. And we want to allow to anyone to be able to modify the current bootstrap process of Fado or to use the same set of tools for creating their own small languages. So since fixing errors is a complex task, we intend to provide high level tools, which will allow us to create, maybe from zero if you want, or modify an existing language definition, just the source code, and after to debug the full process. OK. So among the tools that we are providing, we have a code editor, which is used to modify the source code of the language. And this code editor provides the same features that the code editor in Fado provides currently. We can browse code, navigate. We can perform refactoring, et cetera. And this is something that we didn't have before, because usually the vision of the code was made by hand in a plain text file. So this is to start with. The next thing that we are providing is debugging support. OK. So we provide a custom debugger, which allows us to debug the bootstrap process, but also the application that will run inside the generated kernel. OK. So this debugger will allow us to debug the application before the deploying. So we managed to do this by providing a simulated environment in which the application will run, and we will be able to debug it. This debugger also provides high-level tools for dealing with low-level features regarding the interaction that the kernel will have with the virtual machine. But yeah, it's OK. We also provide a set of inspectors to be able to inspect the kernel while it is being generated and each one of the objects or of the elements that we are installing inside of it. So as an example in here, for example, we are seeing an array of important objects which are instances inside the kernel. And we can see, for example, the main process that we are installing. We can inspect it. And since Faro is fully reflective, et cetera, we can provide through Faro capabilities the ability to see what is inside the kernel in a high-level way. We also are providing visual analysis of the language definition which are available even before the generating process. So this way you can see, for example, the hierarchy for classes, the inheritance hierarchy for classes. We can see the number of methods per class. It's just a set of visual tools which will give you a general view of how your kernel will look like and what it does contain. So it is important to notice that this is not only constrained to the generation of new languages, but it is also useful for developing the application which will be installed inside the kernel. So to provide the support, we don't need to modify nothing, because the same tool set which we are using to debug the bootstrap allows us to debug the application that we run after. Yeah, that's it. Thank you for your attention. And I'm open to questions. The target. OK, for the case of a small language, you could, for example, develop a language that is specifically, that is the smallest language that you need to run a specific application, for example, in an Arduino. I don't know. You want an application that, I don't know, needs to check a sensor every, I don't know, one second. So you don't need big part of the library that we are providing right now in Faro. You don't need it, because it's very simple. So that way you can get rid of most of the features that comes by default in a minimal kernel. And you can obtain a kernel which will weight, I don't know, 50 kilobytes, maybe less. So we have a minimal kernel definition, which is what it is required by the virtual machine to run an image. So that is provided since the beginning. Given that, on top of that, you can start adding things and you can make it as minimal as you want. Yeah. Yes? You are not sorry? We are, I'm not sure if I understood the question, but we are aiming to run always in the same virtual machine. Our small kernels are running always in the same virtual machine, which runs Faro now. This is like the Alcancer. Yeah, the scope of this project. We have parallel projects which are working on minimizing the virtual machine we're working with. But for now, we are fixing the virtual machine. This is the virtual machine that you have. And yeah, it's a bytecode interpreter virtual machine. And so we are generating these kernels, which are compatible with this virtual machine. Just to add, the virtual machine that we have now, we have basically running for 32 and 64-bits PCs and 32-bits ARM architectures. This is a sheet-based or sheet-improved bytecode machine. And we are working to generate alternative to this. For example, directly generating the machine code from the bytecode during the execution. But all these solutions of directly generating machine code, it will require some work or some research to keep all the dynamic features of Faro just generating code. But as Carolina says, this is a part of the story. We are also working in improving the VM. And the part that we are now is in the tooling of the VM because also we want to democratize the access to the VM. So it makes it easy to do new improvements and it does not need to be an expert to do it. It's we're writing in a slang that is a kind of distribution of small talk. And then that is compiling to C. It's a subset. It's a similar solution that, for example, our Python, where we have a small subset of Faro that can be directly compiled or can be transpiled to C. And we are using that to generate the lowest level. Then on top of that, you have your small talk of Faro and you can do all the reflective and dynamic stuff usually. We have tried. We still, as we assembly is lacking garbage collection or a nicer memory model that allows us to have actually an arbitrary memory model. We are a little limited, but it can run. But there is also a transpilation to directly to share a script that works better even than the version of WebAssembly. We are still kind of limited by the limitations of WebAssembly until the next release. Thank you. Thank you.