 Okay, so hi again. Thank you for attending this last presentation of the day. So in case you were not at the previous presentation, I'm Pierre-Marie and I work at Haydecaux. And so this presentation will be about small library to read thermal files. So what is thermal exactly? Let's first describe what it's not. So it's a format, it's a text format to record data basically. It's generic, just like XML, JSON, and EML, which I will compare it to. So in XML, everybody knows XML. It's a format that is more or less easily written and written by humans, more or less because it's a bit verbose. And one of its defaults is that it's expensive to process. It's a complex format and writing a XML parser is a big job and it's very hard to get it right, not only to write the parser, but then to write something that uses a parser because of the format complexity, such as the namespace feature validation is cumbersome because basically between tags you have text and well when it spaces it's fine, it's just notation, but when you have extra text, is it valid or not? You have to, it's complicated to check that an XML document actually conforms to some given format. There are tools to do that, but they are even more complex. So well, XML is something that is good for some purposes, but it has these defaults. So another widely known format is JSON. JSON is also very easy to read and write for humans. It's very easy to parse for machines. There is a specification for that, but it has again some shortcomings, such as well, this document is invalid because you're not allowed to have a comma at this place and if you have some experience writing this kind of document, you know that having this comma is handy because you don't have, when you add a new entry, you don't have to add it there anyway, it's handy. JSON does not allow strict JSON because some implementations can be more permissive. There's no provision to write comments. I'm sure there are other problems. So, and there are several known gotchas, so you may know that JSON comes from JavaScript and in JavaScript you can't. The spec does not make a difference between integers and floats, so basically everything is a float. And so when you're writing numbers in JSON, you don't know what's the precision that the implementation will use to represent your numbers, so you're not sure that your numbers will be preserved basically. It's a big issue. Another widely known format is GML. So it looks actually, it's a superset of JSON, so every JSON document is a valid GML document. It's easy enough to write, but actually the format is very complex and adds a lot of subtleties, so it's not very, depending on who you ask, it's not very, it's not a format that you can write things in and be confident in how it will be interpreted from the first look. And yes, you have several annoying gotchas. You don't, strings are not, there's no need for quotes, so generally you write strings without quotes until the string you want to write is some magic keywords such as a new, which will not be a string, it's gonna be interpreted as a new value. So it's not very nice. So after this quick tour of readily known text formats and their defaults, their issues, there is Tamil. So it's a file format, you have an example here. It's a file format that looks a lot like any files, the older format that was mainly used on Windows and some configuration, mainly in configuration files. So Tamil has been created specifically for this use case. It's easy to read and I mean it has obvious semantics. So here you have a mapping title is an entry that is, it has a value that is a string here. You have first-class dates, dates is a native type to this format. It's mainly oriented as a mapping between keys that are strings and values that can be anything. Other mappings, arrays and numbers and so on. You have Booleans. Anyway, the format has a specification. It's not formal, but it's very precise. And so it's quite easy to know if, to read the spec and to actually know how to pass and the right documents. And yeah, so it has a lot of good properties that make it a good candidate to write, to use Tamil as a file for your software configuration and sometimes just to record data. So that was for the Tamil language. I didn't invent it. So this is the Canyonical home for the project. What I did on the other hand is oh yes, sorry. So I told you it's used for configuration files. So in the real world, most of the Tamil uses I could find were package managers. So the main one is I think is Cargo, the Rust package manager. And other package managers for other languages also use this Tamil. And as you probably saw earlier today, Alaya uses the Tamil format as well. And so Aida Tamil, it's an Aida library. It's very simple one to read, I mean to pass and to create Tamil documents from scratch. So I've written it actually for Alaya because we were looking for a file format that could be easy to write, to read and write for humans and machines for to describe packages. So this library has two very simple jobs. First, take a stream of bytes and parse it and convert it to in-memory data structures containers. And the other job is to turn this in-memory, this containers back into a Tamil document. So there are two parts in the library to fulfill those jobs. First, you have the definition of the data structures, the containers, and so programs to actually do the parsing and the dumps. And the project is on GitHub. So if you want to have a look, this is the projects home. So, and this is where, oh yeah, okay. Oh, it's good, but the big deal. So the first part is the data structures, the containers. It's very simple. You have two types, so Tamil value and any value type. So Tamil value is what could be any value in a Tamil document, could be a table, a mapping between key and values, could be an integer, a string, or any other data type allowed by the Tamil format. And you have this enumerated type that describes what's behind a Tamil value. So is it a table, an array, a string, a date, an integer, a Boolean, could be anything. And you have this function kind that takes an existing value and returns what is behind this value. All right, so you have naturally functions to create values. So if you want to create a Tamil value that is a Boolean, you call the create Boolean function that takes the actual value you want to store inside a Tamil document. You have the same for integer, tables, and so on. And also functions to add an entry in a mapping, all sorts of operations you would like to do with the containers. So that was to create values and you have the corresponding other operations to actually read the values behind the Tamil document. So here the asBoolean function takes a value and assuming that this value holds a Tamil Boolean, it retains the corresponding A-Boolean. Otherwise? Or it's a precondition, so otherwise, you have an assertion error. Yes, as I said earlier in the slides, it's a NAIDA 2012 library, so we can use preconditions there to actually be specific about what are the requirements for each function. So it should be quite natural. Well, this library does not do anything complex, so it's supposed to be very easy to use. Yes? Because that would, yes, well, it's a personal opinion, but I have the feeling that having multiple constructors, the only way as a human to understand which, so you're talking about overloads, having multiple functions, having the same. Don't we return the same type anyway? Sorry? Don't we return the same type anyway? They do return the same type, but they. You can't do all of them. I can because they are part, yes. But when you have the thing is that when you have, because of the shape of this, wait, let me. You get the both of the best of both worlds, to place your function create integer. Yes? The function creates, and the parameter is called crop integer. Yes, well. They would name parameter association. Actually, that works for the atomic data types. That doesn't work for arrays and tables because you have constructors that just create empty containers. So for tables and arrays, that doesn't work. Indeed, it could work for the atoms. So Booleans, strings, integers, dates, and so on. But as a feeling that if you do that, if you rely too much on overloading, the code ends up less readable because as a reader you have to, I mean, if you have create integer and provided directly an integral literal, it's quite obvious what it's doing. But if you have, is factually, instead of 42 here, you have other calls, other functions, other something, anything more complex, your brain has to work a little bit more to know what it's doing, actually. But that's right. And then you have to rely on actually coding practices to make the thing the less, the more understandable possible. Yes. Anyway, so this is what the, using the API looks like to build values. So it's quite straightforward. Here we create an integer, a string, and then an empty table, and then we fill the table with the values that we just created before. And so if you're familiar with JSON, by when the execution reaches the command, you have in T a document that is equivalent to this JSON document. And here you have a small example of what converting terminal values back to a native Ada values looks like. So that was it. With that, you can create terminal documents programmatically without passing any terminal. But then, so, so yes. First, still in the terminal package, the main package that define containers and so on, you have two functions to actually convert a string to a terminal value and the other way. So, well, it's not directly returning a terminal value because when there is a passing error, you want to actually return an error. I decided not to use an exception because of various practical considerations such as the Ada standard does not guarantee that the message that you associate to an exception will be preserved. I mean, you don't have any guarantees regarding the length. So for error messages, it's not great. And also, anyway. Also in the read results also contains the source location of the error. I mean, it could be in text, but I prefer to keep it as numbers. Anyway, so that's quite straightforward to use. There is another package that actually allows you to do this the same, but instead of dealing with terminal documents strings in memory, it goes to the file system. And finally, if your terminal documents, you don't want to read it from memory or from a file. For instance, if you want to get it from the network or from a compressed file, well, there are generic sub-programs that just abstract the stream of primitives to read or write the terminal file to and from an abstract stream. And that's it. So again, here is the project home. So this library is already available in Alaya. Fortunately, because Alaya requires it. So it would be a shame if it wasn't for you to stop there. There is only one release. It's a very young project. And as far as I'm aware, the only serious use of this library is Alaya, the Alaya project. But still, the first release is, I mean, the API probably won't move much except if I rename constructors, but that's another debate. And so you're welcome to have a look and if you want contribute. Thank you. And if you have questions, I will be... Just a remark, there is another benefit of terminal that you didn't mention is that you have no closing bracket. Now it's very important because if you want to accumulate results in a file, you cannot do that in Yemo because when you've closed the bracket, there is nothing you can do after that. Take a tool like an example in a control, which, by the way, can have its output in terminal format. Then you can run it several times and accumulate the results in the same file. Yes, the text concatenation also works from a valid document concatenation. Yes, absolutely. And that's something you cannot do with Yemo. Yes, that's right. Well, that works for the maps. Actually, it depends. I mean, it works for the top-level document, for the top-level mapping, but you can actually have nested, you have a syntax to create nested tables, but all that doesn't matter. Another thing I didn't mention about this format is that it's specified, actually, it's not a text format, it's a binary format, in the sense that it specifies that all documents must be, must use UTF-8. So you don't have to worry about encodings when you use this library, more or less. Because when you provide it a string, it's assuming that it's a valid UTF-8 string. Other questions? Yes? Are you also the author of Knack called Jason or did you just take some inspirations from it? I took some inspiration from it. Actually, I'm one of the current maintainers of Knack called Jason. Yeah, I think the API, some parts of the API were easy to use. Yes, yes. I didn't, yes. Actually, the parts where, when you pass, it doesn't raise an exception, but returns a structured error, first class value error. It's the part I contributed to Knack called Jason. So. Okay, thank you. Thank you very much. Thank you.