 So I'm going to make this really quick. It's about the sound working. It's about VTY and control tests. So we have these programs with VTY interfaces, and it's really important to test that certain VTY commands work or that when we configure something and write the config back to file that we don't forget things or write it in the wrong syntax. And also we want to, of course, test control command interactions. And every time I wrote these tests, I was a bit annoyed by this stuff. The way it's written is like Python code, where you have programs called in a way with config files and stuff hardcoded. And then you send commands by issuing Python code. And then the short summary is it takes a long time to figure out what to do. You call a command, and then you assert that something is in there. And for example here, we expect that the answer is command incomplete. And for me, it was a very inefficient way of writing this. And what I did was I would open a town at VTY and start typing the commands I would like to test. And then I sat there and I wished, couldn't I just take this screenshot and use it as a test? And it turns out it's quite possible. For example, this is the Osmo BSC VTY test. I took this one because it's still a work in progress. And because these take very long, I recently started, I'm unfinished, but I started to change it. Let me just quickly find the regression here. And reading what was on the screen there. So here I started to write a test that does the same things. So I closed the other one, right? So for example, here it just tests the VTY tree. It goes into the configure node and tests that there's a node below that and what the prompt is. And this is the format. Don't be confused by it. But just ignore the plus in the beginning. So basically there I have a prompt and I issue enable. It just looks just like a VTY transcript, like as you would see it on your screen. The list ABC is just a to do, ignore that. But if I say configure terminal, I get the prompt and I can walk into the nodes and back out of the nodes. Like here you see I go into the network and VTS and I test the exit command going up one level. I test the end command going back to the root level. And everything you see here is verified. The name before the prompt, what the character is, what the node name is here. And of course the replies to commands just interleave. Like it would verify that this is the answer we get. And so here's the reply to a right terminal. I think there's some interleaving work and progress stuff going on here. But I have lots of these tests. For example, yesterday I started on the reselecting the miss feed, the measurement feeds. And just quickly remember, and that's basically this I got working yesterday. It's just going into the network. It's listing all the commands and ignoring an arbitrary amount of lines and just verifies that these two commands exist with this config and ignore the rest. Set some config, read it back. So expect anything, go in the network node, expect anything, and this is what we wrote above. And then basically this is my VTY test. No need to write Python code. And it is just run as part of the test suite automatically as soon as this dot VTY file exists in the test directory. The same goes for control tests. And I think it's fairly obvious. If you want to use it, how it works, you can take some examples. And the stuff below it is the Osmo interact scripts. It's actually our first Python 3 implementation of the VTY interaction stuff in Python. And there's a VTY and a control version. And let me just show the VTY one. And there's also some convenience command here. We produce the VTY reference XML to use in the Osmo GSM in the Osmo GSM manuals. We have PDF files that are auto-generated to specify our VTY interface. And we generate that actually from calling this show online hub command, which generates the XML. And so this is just a shorthand, like if I want to use it, I'll just say x and need to tell it which part. Say it's Osmo BSC. It's part 42, 42. And I could have Osmo BSC running, or I tell it where to run. I actually had this terminal open somewhere, but let me just type it again. Doc, examples, Osmo BSC. Ah, this is the first time. So then it would start the program, run the VTY, and because it's so large, it takes a while and embarks there. You have the XML. You can pipe it to a file directly. And so that's the kind of stuff that helps me do things with Python 3 and just write tests. So I could just tell it on Osmo BSC, type some commands, copy, paste that to a file, replace some stuff. I'm not interested in with dot, dot, dot. There's also actually rig access in there. I'm not going to go into that now. And there you have your VTY or your control test. And that's all I wanted to mention. Right, any questions? I think it's obvious, but the control protocol is pure text as well, right? It's a text, is it? Yeah, it's not. It's slightly different, but it's sort of, for all means and purposes, it works the same. So I mean, we would expect arbitrary bytes sort of. But yeah, I mean, it's basically a text. The control interface is not very strictly defined. It's kind of an open issue to make it stricter. And submitted some patches once. But yeah, it's also a danger of breaking things that we're already working because we weren't checking them properly. Right, that's it for me then.