Live CEOing Ep 792: Language Design in the Wolfram Language [Engine Connectivity Engineering]

Okay. Hi, everyone. We are continuing our Wolfram language design reviews. They're getting intense because we're working on a new version. This is part of our engine connectivity engineering effort. Actually, some of these things aren't for the upcoming version, but we'll talk about them anyway. All right, so first up is Standalone applications.

Yes. So standard applications is Chris Cooley and Todd Gailey. And we have number of updates. And Chris can show one of the new required features, and that is code signing. So, Chris, if you could please talk about the updates here, then.

Sure. So quickly, I just wanted to mention that, you know, there's some kind of a, you know, important underlying pull requests for Salem applications that we're giving. You want to get merged for 14.1, and hopefully our last meeting with the reviewers for those pull requests is on May 1st. So, you know, that things the pull requests are, you know, going forward. And so in the meantime, what we've been working on is a new component called the Standalone Applications SDK. So this is just a static library that we want developers to link against instead of the kernel dynamic library. And the upside of this is it makes compilation easier and it also gives us a place to put some kind of more infrastructure for stalema applications that, you know, when you're making a standalone application, there's various things that you do that it's kind of useful to kind of just have common code for that stuff in that static library. And I can imagine some examples of that.

Let me try a naive question. Okay, so I'm developing some random thing that's going to run on Linux servers. And. Or no, actually, let's say I'm developing an application that's going to run on PC, like computers, you know, PCs and Macs, and I'm using, you know, various kinds of whatever, Visual Studio development environments, et cetera, et cetera, et cetera. And I say I want to call Wolfram language in this place. In my code, I'm going to package up my, you know, my request is going to be done through essentially a library call. Right. But through. Through this Expression API. Is that correct?

Yep, that is correct.

So it'll be a lot of nice functions on my C language side. Or what are the bindings for the Expression API that are the bindings in C? What other bindings are there? Or does that not make sense?

Currently they're all in C. We could at some point have interfaces to the Expression API in other languages. Right now it's just for C. And so for that example of Visual Studio, you would configure your project so that you're linking against this static library.

Okay. So it's just one of the static library is one of the dependencies, and you've got. And then you write Expression API code using definitions from a header file or something. I mean, like, where are the declarations for that? Is that in some header file that's part of the SDK or how does that work?

Yeah, so it's exactly that. It's a header file that's part of the SDK. So there's also an include directory that you would need to configure.

Okay. Okay, so you say hash include. What do you say Hash include in your code? What do you say? What's it called?

Right now it's expression API SDKV1H. What we want to replace this with, since we think that Expression API is maybe not the kind of term that we, you know, that we want to have for like, you know, branding purposes. Maybe it would be wolfram language runtime sdkv1h.

I mean, we can, we can show this right, if you. Okay, so I've stopped sharing and Chris, you can take over and show that example that we looked at earlier.

Yeah, so, yeah, right now, this is the current one, but what we are kind of thinking about placing it with is this. And so the version stuff is, Is kind of important because. So the V1 I want you to.

Leave out language, I don't think that adds anything. Just Wolfram runtime V1SDK. Yeah.

And I'll just note that the prefix. Right. That does include the language part, but I don't think it matters if the header name doesn't have it.

I see.

Well, that's a big question. I mean, we talked about this before about sort of branding, the naming and this, and we. It's kind of settled on Wolfram Language runtime in various places. But if you do. Are you saying you think that should be just Wolfram runtime? It's a pretty simple change. We should sort of settle on our, on our phrasing.

Do you have an opinion? I. I'm not sure.

Well, you know, I hadn't really thought about it, but now that you mentioned taking out like language, I mean, Wolfram runtime sounds very sensible to me, but I don't really, I hadn't really thought of that in the past. I don't know what other people think versus Wolfram Language runtime.

So I kind of like having the three letter prefix rather than like just wr. As for, you know, for our Expression API functions. But I'm. I don't think it's bad if the prefix was still wlr, you know, the full name is Wolfram Language Runtime, but even so, the header is just Wolfram Runtime. You know, we're just abbreviating it a little.

Yeah, I think that's fine.

What do we do in other client libraries like the one for Python? What, is there a prefix there too? Is it consistent with that? Talking about the client library for Python.

That is called Wolfram Client. Workfram client for Python is the name of the repl. The name of the library itself is Workframe Client.

Is this similar to that or is it completely.

No, it's not. It's the other way around, I think, because in that case it's. Go ahead.

Yeah, yeah, that's, that's right, Steven. It's kind of the other way around. And we wouldn't really, we wouldn't have the word runtime, for example, in the, in the Python side of things. Yeah, but we, we call it the Wolfram client, not the, you know, Wolfram client for.

Which is something. Yeah. Inside Python, it is a Wolfram client inside Python. Whereas this isn't really what we're emphasizing here is the access to our runtime. I don't know, it's a little con.

I mean, well, you're, you're talking to a standalone. I mean, a separate installation of something like Mathematica or the Wolfram engine with the Wolfram client for Python. Here you are, you're instantiating Wolfram or Wolfram language runtime right in your C program. I think it's, it's nice to have the name runtime in there for this case.

Fine. I think this is fine. Okay, so keep going with what we're seeing here.

Yeah, so just in terms of what makes the SDK useful, another thing that is useful is that you can tell it to use any layout anywhere, you know, so if you look at the second argument here, this is just, this is just a path to a layout right now. But it could be anywhere. And what it does is it'll, you know, it uses like dlopen the SDK does to load it. So this is useful for what we're calling the JRE model of standalone applications, where you're distributing the stale application without a bundled layout. So, you know, you can just tell it to use anything anywhere, and there's not.

Could that anywhere be on the. Be in the cloud?

Well, it has to be a file that, you know, we need dynamic libraries to load.

Yeah, okay, but I mean, No, I understand, but could people get this thing and then have logic so that if they try to run it, it says, oh, you've got to download this thing from, you know, from this location to run this? Or, or is it expected that in the layout for the product that this is coming with that, this, that our library will be in that layout, which is not quite, I mean, I thought in the, in the JRE thing, doesn't that come up with, oh, you need to download this thing from the, from the web?

Well, you can get that. I mean, there was this thing called, what was even called Java Start in the JRE model. You're just expecting that on the user's path there's a Java runtime available. That's what we're calling the JRE model. And that's kind of the Java style. I think in this case, the typical example, like for example with my LSB server app, is that it's just a completely standalone thing. It bundles its own internally without really the user having to know or care that down inside of it is a.

And so. And this all becomes realistic because of Chris's great achievement of having gotten the size of this runtime down.

Right.

Okay. Okay, so that's, I'll note, I'll put.

A proviso on that. That's, that's a very kind of experimental thing, you know where. And very dependent on the application that you're pruning. But yeah, okay, so in terms of that case that Todd was just talking about, this is one of the places where the SDK is useful because with the bundled layouts you need to kind of know where you know where the layout is relative to the application binary. So that's one of the kind of pieces of common code that's in the SDK is being able to start a kernel that's relative to you. So that's what this third argument is here is. Well, let me just say something about how it's kind of how everything is relative to each other. So this, this test executable. Right. It's an, it could be an executable and then the layout is placed alongside the executable so there'd be a resources directory. Then underneath it is layout files. But like finding the location on the file system of where the executable is, that takes like some platform specific code. So that's some kind of useful stuff that's just nice to kind of stuff in the SDK and kind of similarly, if you're a dynamic library, it's different code. If you just Want to know where the dynamic library is? So you don't care about that executable because that, you know, maybe you're a developer who's creating a dynamic library that somebody else is going to use and you're just packaging the layout alongside your dynamic library.

Right.

And so that first argument kind of controls, well, what are we relative to? Are we relative to.

Yeah, I get it.

Yeah, yeah.

Why are these all caps macro, like looking things?

Well, so these are. This, this is, they're enum. Enums. And this, this is a literal macro here. Because there is a function, there is a lowercase function, you know, wlr, SDK, Start kernel. And what that doesn't have is the, the start kernel function takes a version, you know, what, what version of the Expression API are we using? So, but since the header that you're including has a version tied to it, you don't want to have to feed in that version. So the macro is just, it uses the versioned form of the function.

Okay, so two questions. When this is distributed. So is it the case that there's an SDK for Visual Studio, an SDK for, I don't know, some other, you know, for Pure make or something, an SDK? I mean, are there multiple versions of the SDK or is there one package that contains all of the, you know, somebody's version of a packlet like thing that contains all these components?

So, so right now the SDK is just a, just a static library and it's up to you to incorporate it into.

Where are these header files, for example? I mean, where.

So it just. So what we want is that in the layout, right? Under Components, system files, components, there'd be kind of like how we have a math link directory, you know, that has the MathLink static library. MathLink include files. We'd have a standalone applications SDK directory under Components that would have the static library, would have the include files and everything. And that, you know, when you're making standalone applications, that would be the thing that you use.

Okay, so you just, you're fishing it out of a layout, is that, is that right? I mean, you're fishing the files you need. Like the include files are being somehow. I mean, do you copy it into the project or something to use it or how does that work?

I think you would just point it to look at the layout.

Okay, so when you say hash, include or from runtime, whatever, how does it know what the path is to go find that include file?

Well, you would include, you know, configure your include directories to include to contain the. The path.

So that's the thing that's in the. In the. In the ide. You would configure the include directories to do that and then it would find it. Yeah. Okay. And is that. Which is why I was wondering why you need the version one inside this. You know, you were saying before that you wanted to have version 1 inside expression API version 1 SDK. But why is that? I mean, if you are configuring this thing, you know which version you're picking. It's not that you can. What?

Ricardo, what if you want to eventually call different version for a specific function? That may happen. Okay.

No, I'm just not sure how those things are typically designed.

Well, I think also if you. Let's say we introduce a V2, we would just put these two header files side by side, I think in one direct. You wouldn't have to point at a subdirectory for the v1 or v2. That's why it's useful to have it in the header name.

Fair enough. Okay. All right, what's next to see here. This looks cool.

So another thing that we were working on is trying to make code signing more convenient.

So.

Right now, in this example here, you'll notice that we're starting in code signing mode. So this is. Right, this is the kind of lockdown mode where you can only run things that are signed. So right now it's not going to work because integrate, for example, when you're using the Expression API, you can only evaluate expressions that contain signed symbols. So integrate. That's not a signed symbol. X isn't a signed symbol.

Right, right, right. Why is it called code signing mode rather than signed code mode? Code signing suggests that this is in the act of signing, whereas what you're really telling me is that this is a mode for signed code. Am I not correct?

You're correct.

I like that better. I like that better. Signed code. It rhymes.

It even rhymes. Yes. Okay, so in signed code mode, you're starting a kernel in signed code mode. Where is there a signature file or something? That is what you're giving there or what?

How do you.

Go ahead.

The layout is signed, so that in the layout there's a file that contains all the signatures for everything in the layout that you have to worry about, but the application component of it isn't signed. And that's kind of what the developer has to worry about since.

Yeah.

So typically with standard applications, thing will be. Things will be running in signed code mode.

You know yeah. When you're. When you're distributing it to people who won't have a license. Right. You know, then it has to kind of operate in this lockdown mode.

Right. Okay.

And then why don't you show how the signing looks like? I mean, this.

Yes. How do I sign something?

Or how you incorporate the signatures? I mean, the working version of this example.

Yeah. So right, as I was saying, this won't work because the, you know, been signed with that.

Yep.

Yeah. So what we want people to be able to do is as kind of a proof of concept, we have like an online form for generating signatures. So, you know, don't look too hard at, you know, the how the form actually looks. Right now, it's just proof of concept. And, you know, we have like this developer code thing. So, you know, any customers of Stalin applications that are just kind of trying.

This out, shouldn't that really be developer id.

Maybe? I was kind of thinking of it as like a combination of an ID and like a password or, you know, just some kind of, you know, secret that you could use. But, yeah, maybe. But, you know, you just do ECE team, you know, for internally, and you get a whole bunch of applications and you select what application you want to create a signature in. You know, and you say, okay, how many. How many files do I want to sign? How many symbol names do I want to sign? So right now, for this example, we want to sign two symbol names integrated in X. And for form reasons, we have to manually click a link. So, you know, then I just type that out. And if I had a file, then there'd be like a file picker to sign a file. So then you can submit this, and you'll get a little C file here. And all you have to do is compile this C file into your application, and the SDK will kind of automatically know that you've compiled this signature into your application and load the signatures. So I've already put that file here in this. In this directory, you know, and so if I go and I'll show what the actual command looks like. Right. This is what it would look like. You know, you're compiling test executable, and also the. The code signature file.

Can you do it? You compiled. Wait a minute, wait a minute. You already compiled. Where was the compilation step?

So it's right here where I've got it highlighted.

It's just. It was so fast, you didn't even see it go by.

Okay, so that's a command line. What is CL C language or something.

That'S like the Windows version of cc, as far as I know.

Oh, really? Okay. I'm out of date. Never heard of it. Okay. Okay, I see. And that, I mean, that was not. Oh, I see. You got it right there on the command line. You've got the linking information. Okay.

Yeah.

And then you run it.

Yep.

Run again. Run again. Just run again.

It takes a little bit to start the curve.

That's what I was wondering. That was what I was wondering. How long is a little bit? Didn't seem terribly slow.

It kind of really depends, you know, on where you're running it. And it's something we want to look into and we've kind of looked at, you know, how we can.

Yeah, and also this, this kernel is stripped down, so it doesn't spend the same amount of time starting as a full, as a full kernel.

Well, this kernel right here is. It hasn't been proven. So it's a. It's a full layout.

Okay.

That's very respectable in terms of startup time. Well, this is really cool. So let's just walk through what, what exactly is needed here. So somebody says, I want to make a standalone application. Well, somebody has. What do you imagine the typical workflow is? Are they going to make something that's a Wolfram script file first? What are they going to do? Or are they going to. What's a typical place this comes from? In other words, they could run, you know, they got a piece of C code and sort of. What's the, what's the development path? Is it to run it against a Wolfram engine through Wolfram Script or what is it?

So I think eventually what it'll. What it could be is, you know, oh, you've got like a Wolf Script script file, you know, and maybe one case is you want to turn that into an executable. And we could have, you know, we could have a system for guiding you along that path. But then there's also other cases where, you know, maybe you have a more complicated thing that you want to turn to, to an executable, or maybe you have a packlet that you want to turn into a dynamic library.

And if you've got the LSB LSP server standard standalone app somewhere where you could just show how that, that one, you know, that real life example looks like.

Yeah, I'll take a look. I think I may have turned that simple file into a mess. No, it's not. It's not too bad.

Why don't you show it, Todd?

Okay, I'll share here. I had PRUNED this file down for our demo a while back. But this is really the only thing that you have to do. This line right here. Right. And I think, Stephen, this is a perfect example of the simplest possible workflow. I basically have a Wolfram language program. It's a single function. It's like LSP Server, Start Server. And I've got, I've got a Wolfram language file. This, this is this main wl, which I won't show. This is now filled with debugging and crazy stuff. But it's this basically like a one line file that just says Start Server and that I've written, essentially written a standalone program in the Wolfram language. I didn't write this program. It already existed. We were calling it just by launching it. Um, and so I, I literally have a program written in the Wolfram language that has a single entry point. And I want to make a C program that wraps around this as a standalone app. And I basically do nothing more than load the file and call, you know, call get on this file. And that is my program. And all the rest of this stuff is kind of boilerplate. Here's my.

Okay, but so the alternative to calling get would be to use Wolfram Script, which is providing a command line mechanism for calling Wolfram language code.

Right, But I, but, but I don't want that because I. Wolframscript is a standalone program. I have my own standalone program.

No, no, I understand that, I understand it, but what you want to do is to, is to take something. In Wolfram script there is just a function, you know, in the function mode of Wolfram Script, there is just a function that you give in the Wolfram language code. And then Wolfram script is set up so that its entry just, it just says call this function.

Right. So this could have been, I could have sort of mocked this up with Wolfram script dash run, you know, and then Start Server, LSP Server, start Server. Right. And then I'm just basically replacing the Wolfram script dash run with this, my own C program that runs that file. Right, that's effectively, this is effectively what Wolfenskrit would be doing. If I asked it to load, you know, to run a file, it would just load the file. And that's what I'm doing here in my own C code.

Yeah, Just as an aside, hopefully, you know, if for simple cases, you know, like just a file, you know, maybe at some point you won't have to write any expression API code because it's kind of, we can make it boilerplate, you know, what, what has to be done right?

And it's a perfect example of this. This entire thing could truly be generated by, you know, by a tool because it's. It's as simple as it could possibly be. I just. We don't have that tool yet. I just. I basically just took, you know, example standalone program and changed a few lines to. To make my.

But I mean, just so I understand, you know, in developing this, before I do any code signing or anything like that, wouldn't I want to just write C code and call some random Wolm script, you know, desktop or cloud instance of the Wolfram engine to just get things working? I mean, maybe I'm wrong about that.

Well, I would think the thing you'd be more interested in is. I mean, I don't know why you would use wolfenscript or anything, but, you know, maybe you're interested in what you would run with Wolf script, like some wolfenscript script file. But. Okay, I don't think you would want to use wolvenscript.

Okay, okay, fine. All right, but, but anyway, but what you've got here is a. You know, you might. You've. Chris, you've probably seen the configuration notebooks for private clouds. Yes, maybe.

No.

Those notebooks. Okay, so you should look at those, because I think that a system like that is probably what's needed for standalone application configuration.

Yep, I think that's exactly what we would do. You know, you just fill in a bunch of fields in a notebook and then some tool takes it from there or some tool in the cloud.

The point about those notebooks is they contain both long narrative explanations of what's going on. And then fill this in here type thing. Right? So the sort of combination documentation and forms, which I think is a useful way to do it. Okay, so let's go back. Is this okay, back to the Roman, I think you were sharing.

Yes.

Well, but maybe. Chris, do you have some other. Or maybe that's the end. Do you have anything else you wanted to show?

Well, I'd just say that, you know, with that form, right. You know, you can keep on generating code signatures. So if you like, if you signed.

Like 20 files, put something up on the screen, please. Somebody. Roman, please put the agenda up. Thanks.

If you sign 20 files, right? And you have one C file that has 20 files, you know, signatures for 20 files. But maybe you change one file. Well, then you can go back to that form and assign only one file. And then you would have two code signature modules, you know, one for the 20 files and one for the one file you change and then you compile them both and then you're, you know, you're fine.

Right. One nice feature of the system he's got is that there's zero footprint in your main C, your sort of your file that you write by hand for the, for the code sign. Right.

It's a nice piece of software engineering. What can I say? Looks good. Let's just hope that we can get the right marketing pages up there so people understand what it is and can really use it. And who, who is also, what documentation is it going to have and where is it going to get documented? Is it going to have some workflows or is it going to have its own kind of monograph like documentation? Or what, what's, what's it going to look like?

Well, well, we want documentation for all of the Expression API functions. Of course we want a workflow, but I don't know when we'll be ready to have public documentation for the workflow. But I think we want public documentation for the Expression API because that's going into the product. But the workflow that requires more things and maybe we're still working, you know, more closely with people.

What we need is a shingle page up that tells people we have this capability. So when somebody needs it, they know to contact us and maybe we have to babysit them to actually go through all these processes right now, but at least they know it's a thing.

Yeah, that's what we want. You know, that, that sounds like a good idea. You know, we want people to contact us right.

About knowing this capability exists. So we're going to need a description. That's probably Yezabel's territory. We're going to need a description of kind of, you know, this thing described for the world type thing. Right. So, okay, all right, quick, quick things on IDE support and then I think our very next meeting, which is also being live streamed, is. Okay, extension name.

So there's one issue that we have discussed a lot and hand over to Soman in a minute. The idea is that in Visual Studio code, several languages have this kind of notebook support in the style of Jupyter notebooks and they all have their own file extensions. And so now we also have notebook support.

Where's the dot? N.B.

Well, I mean, it cannot read front end, full front end notebooks and it cannot render full front end notebooks. I mean, implementing a full front end like in the cloud, which would be possible because it has a web browser, would take a long time and it's a business decision whether we want to take the time and also whether we actually need this. Because I mean, this is for developing code and not for running.

Well, so what is it? What is. If you say wlnb, what is it?

It's. It's a VS Code Notebook API supported notebook. Is it a JSON file? Yeah. Is it HTML?

What is its interoperability with our notebooks?

Right now it's none. Yeah.

So what is this thing?

It's Microsoft's own format for these notebooks and we can, you know, we don't have much control over that. We can create notebook functionality within their sort of framework and that's what these notebooks are. We could write tools to kind of.

And then us building a, you know, third hand hack tower based on some, you know, lamefied version. It's very weird.

I mean, it's very useful for. If you develop code, then you can quickly try out your examples in a.

Kind of richer environment that we invented in 1987.

Yes, yes it is. But I mean it. The seat. The fact that it runs within Visual Studio code and you can have your input and output lines with formula and graphics and everything. Everything except Dynamics is quite useful for code development.

Well, not everything. A totally lame version without cell structure. Without everything. I mean, totally bare bones. Yeah. Okay, so what's the question?

What is a good question? Extension? Yes. For the fight. Wolfram Notebook. Wolfram Language. Notebook. Visual Studio. Wolfram Notebook. Wolfram Language. What is the I for what stuff?

Interactive Node.

Interactive Notebook.

Interactive Notebook.

I mean it's kind of all the other. We looked at the ones that exist.

Okay. If the main thing about this is it should probably be wlnb. But is it special to Visual Studio?

Yes.

Or is it useful elsewhere? I mean, is it. Is ides going to use the same format or is this only ingestible by Visual Studio?

What's the underlying format? Isn't it just a regular like JSON jupyter type thing? In this case you can open this. You can open these in other IDEs than just Visual Studio Code, right? Yeah, it's a JSON. JSON. Underlying, it's JSON, but we cannot evaluate in other IDs except VS code. Is that what you're saying? Wait a second. I used to think that IntelliJ IDEA supports iPyNB files with evaluation. I think I even used that at some point. So I don't think at least some of these notebook formats can be consumed, not just by.

Let's find out the answer to that and let's find out whether. Okay, let's find out the answer definitively not guess it.

Okay, well, the answer to which question. We know we can't evaluate anything in any ides other than Visual Studio because we wrote a bunch of special code in Visual Studio to allow this evaluation. Whether or not you could open and look at some sensibly view this file somewhere else.

If this is specific to Visual Studio.

I think we need to test this out. Stephen. This is. This we.

Yeah, right. We don't know. So if it's specific to Visual Studio, then that's one thing. If it is, You know, I don't think we should be giving it, you know, we should be making it clear that this is not our notebook. This is some, you know, bastardized version that runs in this, this other environment. We're not going to make the claim that is compatible with, consistent with, you know, feature compatible with anything. Yeah, so I think what it wants to be. I mean, I would say that I would call it a bare bones notebook or something or a, you know, bbnb, you know, wbbnb.

I mean this extension would at least make it clear that it's Visual Studio.

Well, if it is Visual Studio specific, then that's what it should be. Otherwise it should be something like bbnb, wbbnb.

But we should. For this format, which is, this format should work on multiple.

Well, let's find out. Let's find out. We don't know. So there's nothing.

The question is whether we could open this in for example, Jupyter.

So let's find out. We don't know the answer. So let's go find out the answer. But I think that the concept of a bare bones notebook file makes some sense to me. Do you see what I'm saying?

I know what you're. Yeah, but I don't really like that because it's. It's not like our notebook made. I mean, functionally it's a bare bones notebook. But that to me that sounds too much like a variant of our own notebook.

Okay, fair enough. Well, what do you think it should be?

Well, I kind of just like the WLNB or something.

I don't like that because it suggests that it's an actual thing supported by us. It's not. It's a hack based on other people's ripoff of our technology. I mean, it.

But all of these formats, you know, Jupyter started this. Everyone has NB in their file.

Well, yes, because we did.

Right, but, but so the question is.

I mean, yes, I understand, but we don't want to say. We want to make it clear that this is not our notebook format. It is something that is specialized for IDEs that read JSON files. So I'm saying. So the emphasis is not that it's Wolfram language. The emphasis is that it's some kind of. I was thinking something. So maybe J's on notebook or something. I don't know.

Yes.

Yes. That makes more sense. Okay, let's find out what it is first and then let's act accordingly.

Okay. Should he just focus. Focus on the opening part or the evolution? But I think we should focus on the evolution part.

We don't have the fact.

So let's get what he meant. What he means is that we. We can only evaluate these things in Visual Studio.

How do you know? How do you know? You don't know right now. You don't know. It's a JSON file that may or may not be, you know, importable by other things. Let's find out. Not speculate.

Fine. But importable to view.

But I don't think you're right.

There's all sorts of code in the Visual Studio plugin to evaluate these things. It's not like.

But maybe there's. I don't know what there is in other plugins, so maybe we should be supporting it in other plugins. I don't know. We don't have the facts.

So we will look at the. We will look at what. What can be done in.

Fine. That sounds like the right thing. Yes. Okay. What else is there to look at here? And then I think we're about to roll into our next meeting, which is.

Yeah, I mean, these are the main topics that we wanted to. And then we can cover the. All the external evaluate things in the next meeting, starting with the design review and then followed by. Alec.

Great. Can you just show me the underway projects here for a second? Okay. By the way, did you understand my comment from yesterday about parallel tools? Here's my comment. I have like, for me personally, I have like 170 kernels that I'm running across the network of machines. I would prefer that the machine that I'm sitting. Typing at, if I have like a hundred parallel evaluations that I'm doing, I would prefer that it allocates those hundred parallel evaluations to cores other than the one on the machine that I'm actually sitting at. See what I'm saying?

Yes, I understand that, but I mean, at the moment, the. There is a single parallel environment that consists of all the kernels. We have launched and those are the ones that are used. But launching and closing kernels is not that expensive. So, I mean, you can't just, for example, easily.

I know, but all I'm saying is, in preference, you know, you've got 170 kernels. Which one are you going to use first? See what I'm saying? That's all I'm talking about. How do you define which one?

Okay, so you have an evaluation with less than 100 jobs to do.

Less than 170 jobs.

Okay. And then you want control over which, which kernels.

And maybe all it is is that if you tell me that if I put them in a certain order in the list of parallel kernels, that it will be, you know, that that will be the. The priority order in which they're used.

That is not the case currently.

But I mean, okay, it's a minor.

Point, but it would have kernel priorities. Yes.

Yeah. Just which ones get used first? Because, I mean, maybe it's just a real, really weird corner case, but anyway. All right, we should wrap this meeting up and we'll see some of you again soon.

And so we have to switch to a different meeting, right?

I believe we're switching to a different meeting.

So should I stop sharing?

No, you should. Okay, so we will say bye bye to anybody who's on the live stream. We will reappear.