Live CEOing Ep 779: Design Review of Compiler Features

Okay. Hello, everyone. Welcome to another Wolfram Language Design review, this one part of our cycle for version 14.1. And we are talking about the compiler, an exciting topic. Tom, please.

Right, yes, fine. So there's a bunch of topics. I could give you a broad outline of each of them, and then we could go cycle back or.

Let's do that. Let's do that. Let's get the basic idea. So, progress reporting.

Right, progress reporting. You know, when you do a progress, you get a progress monitor thing that tells you what's happening as. As it goes along.

Okay, so hold on. Let's just take what we need to take a look at what's actually in there. Okay. All right. So. Okay, maybe we should go through.

Let's go back.

Yeah. Then we'll come back.

Okay. Error reporting when you do something. So here's a compilation. It fails because there isn't sign of a boolean. You now get this. In the thing here. You get this thing that says show compiler error. And it shows, you know, source code and where the error is. And here's a bigger thing that, like this is taking some of the implementation of BIN counts. And I overrode it by messing. Giving it a messed up thing. And this is what you get in the case of. So it's. You see the code that you're compiling with little markup things.

What's the VAL triple, quadruple, $1? That wasn't in the original code.

No, that wasn't. That's part of the renaming scheme to deal with local variables. So I would imagine we could start to eliminate things like that. But I haven't done all of that. Nonetheless, this is pretty useful to be able to see where the error.

All right, great. Let's keep going and then let's.

Great. Right. Right, fine. So this is when you compile something and there's a runtime error it the default action, it runs it in the evaluator. But sometimes there are things like, you know, to RAW pointer that don't work. And we have now an option that by default doesn't run. It doesn't run things it thinks won't work. And you've got various settings for the option to control the by. Won't work.

You mean will cause your process to crash?

No, it won't cause the process to crash, but you'd get some strange messages. So, like, let's come back and look at that in detail. Okay. Right. We have some enhancements to type declarations. So I'm declaring a type here, but I can also now in the type declaration, give a default function to create instances of that type. And so then when I call, you know, like some instance thing, it automatically uses this function that was used. And in conjunction I can also set like a bunch of operations. So this is like how data structures are made, but this is making like the data structure mechanism to be visible. Yeah, four types of. And in a. Not this version, but hopefully soon there'll be a thing for like making your own data structures and instantiating existing data structures for different, you know, different types. And here's the last one. Right. This is Little Christopher might be good. So this is a new property to add to. We have these compiled components, so we add things to them with declare compiled component. And this is making a pure library interface. And this is saying that export from the library the function square, which is also in the component and instantiated for these types, and that makes a library. So this is not making something that you can embed in the evaluator. This is something that you can call from other compiled code. And in fact, I even had a thing of using it from a foreign function. So right now.

Wait, wait, wait, wait, wait, wait, wait, wait. Let me just understand what that last thing is. Right, so this is a library that you got from the outside world, is that right?

No, no, no. This is making a library with the compiler, but setting up various things to.

Go into entry points of some kind.

Right, so this is. Right, so right now, in compiled components, there's a thing called build compiled component that lets you build a library from a component. Right now there are two sorts of things that can be built into that dynamic library. There is what's currently called library functions and installed functions. Functions, if I remember right.

Yes.

So installed functions are functions where it basically compiles the function and some apparatus around it so that it can be installed as down code so that, you know. Right. So it can be used when you import it into Mathematica. Then there's library functions which are sort of similar in that it compiles the actual core function and it compiles some sort of expression wrapper around it so that you can get a library function object that again, you can call from a kernel. So this is a new thing, a third type of thing which is currently being called library interface, though I'm not sure that name is exactly right because it sounds a lot like library function. But the point of this is, instead of exposing something that can be imported by a kernel, it exposes just like a pure dynamic library function thing that could be Loaded with DL Open or dlsim. And so, you know, for example, it can also be loaded by ffi. And this is also, I think, correct me if I'm wrong, Tom, this is the sort of thing that you want to expose if you want to call compiled code from the kernel as well. Yes, kernel C code.

That's right. So developers want to get, want, you know, they want to call it from the C level of the kernel. Then this is like super use. This is what they want. I mean, they need something.

So this one last. Yeah, yeah, sorry, one last. One last case where it's useful is if you want to compile something so that it can be called by other compiled code without recompiling it. That makes sense.

Yes, but. Yeah, okay, so wait a minute. So what this is doing is normally the compiler produces something that has the interface to be called by the kernel.

By the evaluator. The evaluator, yes.

Okay, but. But I mean, don't you have a thing. What? Can you show me the. The collection of functions that you already have?

So these are all different. These are all different types within fields, within compiled components.

If I go to.

But how do I get. I mean, these are from this. So this is a way. I'm still a bit confused here. This is. I mean, I understand what this is trying to do. This is trying to make something which is a. A dylib. I mean, is it going to emit a file?

Should I run the demo? Would that be helpful?

Well, yes, but is it going to emit a file which is a DYLIB or something like that?

Yes, when you call build compiled component, which already. That. That mechanism already exists and already produces a UI library. This is just another sort of thing you can put in it.

Extension on it.

Okay, but when it produces. That's what I thought was that it produces a dylib. But the existing one has. What entry point is this? Defining a new.

Entry point has like. Like exports, but they're like special exports that are set up for the installed functions or the.

Okay, so it's like a main right now.

What.

The export right now is like a main. And what you're providing is a way of. Of giving a specific function that is an entry point. Is that right?

No, not really. That's not really right. So the, the real difference is just that the existing. Maybe you'll be good, Tom, if you add a library function or. Or an installed function or we could.

Look at an example. I can't add one. Oh, maybe I could.

Actually, I think it wouldn't be hard. But, but, but, but. Okay, but the point is, basically. Right, the point is, is, is there's already a mechanism for creating dynamic libraries you can already specify. I want these functions be. You know, I want here the functions from my compiled code that I want to be included in the dynamic library. But there are just different ways of including it. They're including it. There are ways of including it so that it can be easily loaded into the evaluator. This is a way of including it so that it can be easily loaded from some other compiled code that knows how to load generic dynamic libraries that might know nothing about the evaluator.

Right, but just so I understand, in the end you're going to call some external function F whose argument is an integer, let's say. Right.

Who is you? You use the user of this. The consumer of this library.

Yes, the consumer of this library. And one thing you might do is have the evaluator call that and then it has some way of setting up the whole call mechanism to call an F of an integer because it's got to convert. The other possibility is that it is a RAW interface where you're literally having some other piece of C code make a call into this library that's F of the integer. Is that correct?

Yes, yes.

Okay, that sounds useful.

So now here I've loaded it and this is the thing I can call from top, you know, from the evaluator. So I would. Do, you know. Right.

Understand the library interface. There is a thing you can call for another C program like an ffi. Like you could load this in with FFI and call it.

Yes, you've got it. Yeah.

Right. Okay. So I would have said in terms of. I mean, the main issue here seems to me to be the name of this library interface thing.

Correct.

Yeah.

Could you go back to the. Could you just show that. That association again, the one you were just showing.

This one here.

Right, right. Which contains. Ok, so library functions. So those are functions that are to be called by the kernel, correct?

Yes.

So to me it seems like it will be like raw library functions or something.

Well, actually, maybe the word is foreign because that's the thing that we use.

I see. That makes sense.

I mean, it might be a little weird, but like in FFI stuff, the distinction we made was library star functions are for dealing with library link libraries, and foreign star functions are for dealing with generic libraries that you don't know anything about them.

Well, why don't we say library foreign functions? I don't think we want to say Foreign library. Because it's not the library that's foreign.

Yeah. Or foreign function diaries.

The only thing with that, it's suggests that the, the functions are foreign to the library and. And they're not foreign to the library. They're native to the library.

Well, fair enough, but so, okay, look, library functions. I mean, what? Just pushing again on RAW library functions. Is that crazy?

No, no.

What else do we have that's called raw? Don't we have raw?

RAW memory functions and we have RAW to and from RAW pointer? Yeah.

So I think RAW library functions is reasonable given raw pointer score. Yeah, this seems quite reasonable to me. Raw library functions, that's fine with me.

Yeah.

Okay, so in terms of the creation of these things is that. That that's what they come back as. But how did you create this?

Right, so I. You have your library RAW functions here, RAW library functions, RAW library functions here. And then you give the name. It's an associate.

Okay, I get it. So that's all fine.

Yeah.

Wait a minute. Why is that a symbol square? I don't understand that.

Because this is the name of the. This is the implementation of the function which.

Yeah, I get it.

Yeah. Right.

Okay, this seems like a nice thing.

Good. Can I just show you. There's another name to be. To be used here. So I'll just show you usage so we can load the thing. Now I'm doing some compiler code, so I'm doing library function declaration. And I can call it do function, compile and I can call it. Now here's another thing I want to do is I want to reference the library. I want to pull out the functions from this component, but just the RAW library interface. You see, if I did, right, if I did this, then it would like suck in the definitions. But I don't want to suck in the definitions. I just want to use the library, you see. And so if I do this and we have this thing, compile component library interface, and that's saying suck in the raw. And if we look at the llv, if you can stand looking at this, you see, this is what the. You see, it's. This is the RAW code that it's. That it's using. Whereas if I did. This is such a nice, such a nice system we have here. Why the heck didn't that work? Oh, no, right. I want this to be square like that. And here we go. Now you see, it's expanded out all of the code into this sort of low level LLVM code. And that's kind of the difference and this is like super important for the compiler because this is how we're compiling the compiler. So we have this thing we call, you know, add the definitions of the RAW interface. So we could, with this new naming scheme, call this compiled component raw library function. Well, it's the whole thing. Or raw library, compiled raw library or.

Okay, hold on, let me understand what that is.

So that.

Yeah, go ahead, Christopher.

Well, I was going to say, I mean, basically what this is doing is that that thing that says compile component, raw library is expanding to essentially a list of library function declarations.

Literally what it does. Yes.

Does it actually evaluate to the list or.

Yeah, yeah, yeah, it.

Okay, show it, show us that with the, with the other.

No, no, no, sorry, it doesn't evaluate to it. No, these, sorry, it does internally.

So it could, though it probably could.

I don't think so, but.

Okay, well, all right, but Compiled component, raw library. So that's a library that is to be called raw as opposed to being called through sort of evaluator friendly function calls. Is that correct?

Well, right, you see, but there's another way of using these components is you, you pull in all. They're like. It's a packaging system. So this is saying pull in all the compiler declarations that are, that are in this component and then use them for compiling. And that's, that's what it's doing here, you see, and that's why I get it.

But whereas the other one, you have to use library function of square.

Yes, yes. And this is kind of like trying to say, well, I know what the library functions are. I've, I've, you know, I don't want to go and enumerate them all. Just, just go and take them. So. Right. You see, obviously if you don't have to compile these declarations, it's like super, it's much faster.

I don't understand why you say compiled component there of the demo library.

Yes.

Why is it not raw Compiled component. Why isn't that the correct name for the thing at the top?

Well, it's using this thing here, you see.

Right.

Yeah.

I think the distinction is not. Ok, so actually, actually here's a quick question, Tom.

If.

Is that demo library above, is that the name of a compiled component or the name of a dynamic library?

It's the name of a, of a component. This is a feature of a component.

Okay. Okay. Yeah, right. Well, I guess the. Yeah, well, although. Okay, so I think that the difference is not. Right. The question is the one below, the one that just says Compile a component of demo library. You don't need to have ever built the compiled component for that to work. Right. Ultimately it just references the compiled component that you have in memory. Yes, the, the one above though, the compile component raw library that's also operating in reference to dynamic library, which actually Tom, is there a way of specifying where the library is?

I don't. I think it just uses find library. So it's going to look for the library. I mean, that's the same as it.

Might be if you use, I believe, load compiled component and the other ones all have a second or optional second argument where you can tell then it should work.

It should work the same way, obviously, I would say for sure.

So yeah, let me check that I'm right about that.

Yeah, go ahead. Okay, go ahead.

Yeah, I mean the point is that the, when you just write compiled component, it's just referencing this in memory compiled component stuff. When you say compiled component, raw library or whatever it's going to be called, that's referencing a compiled component and its associated built dynamic library that's somewhere on disk.

Yeah, no, it might even work, Christopher, but it certainly should do so.

Hold on, hold on, hold on. Compiled component of Light of Demo quotes. Demo library does what again?

Well, on its own that just represents the compiled component called demo library, which is just a thing that you can, you know, you can add stuff to it, you can move it around. It just basically contains a bunch of stuff. But the thing, but in this context.

Yeah, yeah, but the way you call it is through these evaluator friendly entry points. Is that correct?

That's one of the ways. Another way is you can compile things that use it. It has declarations and you could compile something that has, has these declarations.

Okay, but the difference with a compiled component raw library is that you, it isn't. I mean, in, in the, in the, in the regular compiled component library thing, you get to use the top level square fun function there to call it. Whereas in the other case you have to explicitly say library function to call it because you are synthesizing something that is the analog of calling a raw C function in there. Is that right?

Yes, I think, I think so, yes.

I think the distinction is really just the one below is. The one below is basically just like a hash include in your C code. The one above is like dlsim, like I'm importing something from a library. That's the difference. So the one below is just importing the code and it's going to compile the whole thing. And the one above is loading it from a dynamical library.

So I see. In.

In line 36, couldn't you call square directly? Didn't we do some bindings so that it calls the library function instead?

So I'm not. I'm not sure what you mean. Instead of calling library function, couldn't you.

Just call the square and that will.

Call the levering function? Well, that's what I'm doing here. No, no, I know, but using the library interface. Well, not necessarily, because it's better. I think it's better to. Because square might have more than one type. It might be polymorphic. It might be, you know, so. So how do you know which one you're.

Well, so my library function of square. Right.

No, light library functions only have one. They're monomorphic. Single monomorphic.

Daniel is saying is that on line 36 you could replace library function of square by the symbolic square. He says, well, you.

Well, no, right.

I think.

I know that. I know that. But that's using a different declaration.

I know. I. I think that you can't do it the way it's set up right now, but maybe in the future it could. Because the problem is that somewhere when you run declare compiled component, you need to tell it that here's the symbol name and then here are the functions that I want to be associated with that symbol name. But the problem is that it's not clear. Like right now, you give it an association with string name, arrow definition. So you couldn't have, for example, a polymorphic function like that, because you can't have multiple keys, multiple values for the same key and stuff.

Okay, hold on. The basic point here is, as you're saying in line 38, there you are in the function compile, you're just snuffing in the code from the library and compiling it all together. Whereas in the in line 36 or the previous line, you are indirectly referencing, you are linking against that library and calling into the libraries. Is that right?

Yes. The only thing will be the first one, the lower one. It's not that you're importing code from the library, you're importing code from the compiled component from which the library was built.

Yeah, I see. So the fact that, the fact that it says demo library. It could have just said demo.

It's not just a demo. There's no library involved in the second one.

Sorry. By the way, I've been giving a bad. I wrote this a while ago. You can just reference the symbol here. Oh, yes, yes. You see, and that's what's so nice about this, is I can refer to square and I can either load it like by, you know, cassafling out all of the, you know, expanding out all the codes, which I'm doing here. I prefer the word just with no cassnaffling, just by calling into a library. And there are pros and cons to both of those. So.

Is casnafling a word, by the way?

It ought to be.

Okay, fine. All right, so we're looking at this name here. And the issue is this is a compiled component. It is. It's a compiled component that is a raw library. Is that right?

It's a compiled component that one of its artifacts is a RAW library.

What do you mean one of its artifacts?

Yes.

What do we mean, one of?

Well, it has all of.

No, I think the point is that you compile. A component is just a thing that lives in memory, right? Like you've declared it, it's in memory, has a bunch of functions and stuff like that. Whatever.

Well, why isn't this. So why isn't the library just one of those things that's declared in it? Why is it a separate wrapper than composer?

No, because the library is actually a file that's not tied to a kernel session. It's just a dynamic library that sits on disk. And you created it by calling build compiled component with one of these in memory things. So the point is that the in memory thing, I mean, it's like. It's like I have the source code for my library and then I have the dylibond disk. These are kind of two different things.

And then the source code for the library is compiled Compiles component is the source code.

Yeah.

Why is the only reason RAW library. Why is it called compiled component at all? Why isn't it just called raw library?

Because it needs the component to know, like, the types and the things like that. You see.

So, right, so essentially what it's doing is it's looking at. Right? You might think you can just give it the dynamic library and it can load everything. But the, but the point is, what we're. The way to actually working is you give it the source code for the library and then you tell it where the library is or it finds the library or whatever. And then the point is it looks at the source code to figure out these are the functions that. I mean, it's like C header file parsing, but it works, right? Like, you know, here are the functions that were exported. Now I know what to import modern.

Yeah, yeah, that's all right.

Okay, so what should it be called?

Well, if we're changing RAW library functions, it should probably have RAW in it.

Yeah, I think it should be something like Compiled component, RAW library, which is what I was suggesting that.

That would be fine with me.

Christopher, does that make sense to you?

Yeah, no, I think that's. Yeah, yeah, I think that's okay.

Daniel?

Yeah, I think it could be RAW interface.

But yeah, I think interface is confusing because it's.

Everything's an interface.

Oh, well, yes.

Well, actually one. One argument, one problem maybe with the word library is that. So it sounds like that the first argument to this thing is actually references a compiled component and then the second argument, maybe if it exists, is like telling it where it helps it find the library. Right, so. So it's a little interface. Yeah, yeah.

I agree. It should maybe be RAW interface.

That would be fine as well.

Customer.

Well, yeah, I mean, I'm not sure what I'm advocating for. I mean the complaint about interface would be that it's not. That name doesn't always make. Doesn't make it totally clear that like, oh, you need to have a built library in order to use this.

Right?

Like. Like you, you might just look at it and say, well, the default usage, you just give it a compiled component. That's it. Well, we might have realized that we.

Could have the longest name in the system and we could call it compiled component RAW library interface.

That would quite be the longest, but it would be close.

I think it's better to be clear. This stuff is pretty complicated.

Yeah, I agree with that.

So if that is what it really is, RAW library interface, then we should call it that. Okay, that. Tentatively let's do that. But let's go on to the other parts of this agenda.

Right, Fine. So do you want to loop back to the beginning or.

I think so. Let's loop back to the beginning. Okay, progress reporting. The one thing I want to comment about that is telling me how many seconds have elapsed, while amusing is kind of like you're just telling me the most embarrassing thing.

Yeah.

Can you show me a longer thing that we're trying to compile here? Well, something that isn't trivial.

Start your kernel bin counts is non trivial question whether it's cached.

It's pretty cached.

Just take a piece of serious code and compile it and let me see the thing doing its thing.

Hang on, just let me.

The bin counts is somewhat serious. It's just that it's been cached yeah.

Come and do this.

But so the number one thing if you don't remember is that basically we know what passes are happening, but we don't know what, how many passes need to happen until like you don't know if you're at step 12 of the compilation process. You don't know how many steps there are in total.

So it's telling you how many functions it's actually compiled. So it's had to compile, you know, it's like 200.

So listen, listen, there are lots of parts of speech issues there. I mean could you set, could you. Let's, can you open up the list of what all the things it could say are.

Maybe just take a screenshot or something or.

No, no, no.

But not, not, not just a snapshot, but just it said something like. I mean it flashed by something or other finalize and that said something else in a completely different part.

I would have to prepare something for that. But, but I mean I certainly do that.

Right? Can we. Okay, for now, okay, fine. Take a screenshot. Just run the compiler environment again and do it again. And now after it's when it's in mid. Whatever. Okay, now take a screenshot. Okay, now just display, put the screenshot in the notebook. One of them, I don't care which one.

Okay, here we go.

Okay. Okay, first question is, does anybody know in these focus monitors, have you looked at other ones? Do you know if the capitalization is the same? An elapsed time can't be, can't be camel case and can't be smooshed. The other ones are not smooshed. You get what I'm saying?

Yeah, I, I, fine, I'll. I'll have to check into that. So.

But yeah, right, so I mean is it stage or functions completed?

That's quite, that's actually quite useful.

No, I understand that. I'm thinking about the name. Yeah, I mean you say function stack. Are these like iterated. Those are all user defined functions, is that correct?

No, no, none of them are user defined. This, this is the only user function. Everything else is, you know, being pulled in and sub compiled.

Okay, but iterate account is, comes from where, where is that name from?

That's some internal thing that, that deals with how many times it go. You know that.

Oh for goodness sake. Okay, so, so wait a minute.

This is like the stack. This is like the, the call stack, right? As it's compiling each function, I realized where would this function be? The call stack.

Yeah, but those functions, I mean some of those functions are User level functions. Some of those functions are deep inside the innards of the compiler. Is that correct?

That's correct, yes.

So surely we should annotate that with color or something like that. Which one is a user level function, which one is an internal?

We could do that, yes.

I have no idea what, what I mean, lighter gray maybe for the internal.

Ones perhaps Noah is here, so I'm sure useful ideas.

So cost, maybe older italic or something.

Yeah, go ahead.

Well, I was going to say light to gray for the non user one seems reasonable.

Okay, but now functions, I mean you say function stack and functions completed, is that the same and current function, is that. Is that the same use of the word function in all those cases?

Yes.

So by functions completed, I mean how many user level functions are there and how many. I don't understand why there are, you know, I'm doing a trivial compilation. Well, I don't understand that. What does the 51 mean?

It has it. It has had to compile 51 functions to reach this point.

Right, but it's in. The functions are things like plus. It's like in order to compile bin counts, I needed to compile plus of two integers. I also need to compile plus of r2. I also need to compile, you know, iterator count of something. Rather.

Right. It only does these once. So the second time round, you know, you don't see any of this and it's much quicker.

I don't understand why you have to compile plus don't. Isn't that already compiled?

I'm not, I'm not.

Maybe have to generate machine code for it. But plus is so common. It's only going to compile it plus it is also for different, you know, there might be integers or reals or something. You know, there's different types and things it might have to compile, but. But it only does it once.

In the end there has to be something in the LLM LLVM code. It's like here's the function to call for plus. Right? It might be trivial, but it needs to do it.

Yeah.

Okay, but so now you're saying okay, so at the top it says compiling. What else could it say at the top? I mean, in other words, is that the only message that the compiler can put there?

Well, it could say the current stage.

Or something like could also say function compile or something.

What is it? I mean, you know, normally the current stage would be. Would go up there and I think that would be a better place for it.

That's that would be fine. I think that's. I think that's.

Okay. Compiler. I don't know how. What's the right way to say it? I mean, so in other words, that's going to flash, typically, that's going to be somewhat constant for a while. It's going to be in function resolution and then it's going to go to something else. Is that right? Or does it. Is it function resolution?

That's correct.

What's that? Yeah, yeah, this would be something like.

Maybe it could be.

Maybe we could have verbs for all of them. So it's like inferencing types, resolving functions, et cetera.

That would be nice that, that that's possible.

I mean, I think they're like a hundred different types of passes or something, but.

Yeah.

Oh, Daniel just posted that. Yeah, those are the.

Could you post this into the notebook that we can see? Tom?

Hang on, where did that. I send it through chat. Right, okay, hang on a sec. Right, Right.

What's the difference between memory management and memory management finalized?

Well.

It, it makes. Right. Memory management finalized is like actually adding the code for the memory management instructions. Like, like the actual implementation of the ref counts and things like that.

Okay, hold on. The. Inferencing types, resolving functions, converting expressions. What's a closure?

Well, it's not converting expressions, really. It's creating code for converting expressions.

Okay, well then that.

If it says managing memory, that makes it sound like it's running the garbage collector, but it's not.

Okay, well then maybe we should use these nouns. Well, exception handling is not handling an exception, it's setting up the exception handler. But look, if we put it in the top bar, it can be slightly longer saying what it's doing.

Yeah, could we just say compiling in front of every one of these? Like compiling memory management, compiling, exception handling. I don't know if compiling type inference makes any sense, but maybe just put compiling in front of all the ones that are nouns. Or setting up memory management.

Yes, why not? Setting up memory management and don't have the word compiler top there. Do we typically do that in these progress monitors? Do we say what the overall thing.

Is in training progress, Reporting. It says training progress.

Okay, fine. So, well, then why don't we say compiler progress.

Could. Could do.

And then say what, what the action is. Compiler progress, colon, setting up memory management, dot, dot, dot. I would put the elapsed time. I would not put it at the top. I would put it at the bottom. Show progress first rather than admitting horror. So I would say functions compiled or Something or functions. Defined functions. What is the right word?

Maybe. I think maybe the current function could be at the top or maybe. Well, I would argue like there's sort of an ordering where it's like the most to least granular or something. Like the most.

Fair enough.

The most kind of small picture thing is probably the stage or the current function. And then as you get, you know, then it's, well, where are we in the function stack? And then it's like, well, how many have we compiled? And then it's like, how long has it all taken?

So for every current function, you go through multiple stages, is that right?

No, well, yes and no. So it's like memory management is done globally on all the functions. When it's so. So it, it varies.

So what does it say for current function when it's doing the memory management stuff? Does it say none? What does it say?

Well.

When it's processing, Doing memory management, that might also have to re enter the compiler. So if it does, it'll put the name of the function in there.

But if it doesn't, what will put. What will.

Then it's empty. It doesn't show anything.

Okay, so maybe we just put at the top, compiler progress, and then we put current stage as the first item.

Right.

Current function as the next item, function stack, Then functions completed, then elapsed time. Does that seem reasonable?

I think that sounds quite feasibly interesting. Yeah.

Right, okay.

You had compiler progress colon.

But no, I'm saying just at the top, in the top bar, put compiler progress and don't put anything else on the top.

Oh, I see. Fine. Okay, got it. Right, okay. Yeah.

And then just have the stack that you have right now, starting with current stage.

Yep, yep, yep. That sounds interesting.

And then for current stage, do we like these various names or. I mean, setting up memory management. I think it should be saying and then finalizing memory management or something. Or memory management setup. I don't know what you want to call it. Well, I don't think it has to be all nouns or all verbs there.

Right, right.

That seem reasonable. Setting up memory management. What's memory management finalized?

What, what does it do?

Yeah, what, what should it be called? Because that's not a good name for it. Setting up memory management and then finalizing memory management. But for wants of anything better, that's what I suggest.

Okay, okay.

What is expression conversion?

Expression conversion is setting up the interface to the evaluator.

Okay, then why don't we say setting up evaluator interface?

Yeah.

Okay.

What's closure Resolution.

Well, that's. There's a bunch of work that has to be done for, you know, nested functions and like bindings and environments and things like that.

How would you say that better?

Setting up anonymous functions.

Was that what it is?

Yes.

How about setting up variable binding environment? Is that what it is?

No, it's much more than that. It's very focused on anonymous functions.

I think it's just very weird if it comes up saying setting up anonymous functions, especially if it says current function foo. Setting up anonymous functions.

Well, the current function foo has a name and these are just like, you know, lambda functions that.

No, I understand that, but is it going to say current function and then have a name and then say doing stuff with. With lambda functions, I think it'll always.

Have the name of the function that you're. You know, the upper one, the one that it's a member, The parent or the.

Sorry, sorry, sorry, I spaced out for a second. Could you say that again, please?

I'm just saying that I think the current function for a lambda function will always be the parent, you know, the. The thing at the top of the chain that it's contained in. So lambda functions always contained inside something.

Okay, Well, maybe we could call it pure function resolution. Resolving pure functions or setting up pure functions.

Yeah. Yes.

Okay. And then setting up exception handling.

Yeah, so. Yeah, yeah.

Generating final code. What's function resolution, By the way? Type inference should be inferring types.

Yeah, I think we.

Okay, what is function resolution again?

Well, that's the stage where it just enters lots of, you know, it just goes down recursively, you know, through every function, you know, processing, generating code, doing type inferencing, you know, etc. So that's, that's what it's doing.

Okay.

It's typically the most expensive part. You tend to see that for the longest.

Okay, but can you say again, can you, Christopher, could you give a description of what that. What that is?

I don't know what it is.

Well, it's the K snafling. I mean, we called it K snarling earlier and you asked me if that was a word.

Okay, we come.

Why don't we say kissnafling function? I mean, is it just like figuring out which implementation to use for each function? Which it knows the name of the function?

You kind of know from inferencing, you know, which function it is, but then you've got to go and generate code for it, and then you have to do, you know, it itself might be calling other functions. So you Know, there's some chain of things that you go down through all of these things. So that's why you get this. You know this.

Why don't we say analyzing function structure or something like that?

That's interesting.

Let me say. Okay. Analyzing functions or analyzing may. Analyzing function structure.

I, I like that. I, I think that's okay.

All right. Otherwise known technically as K snafling.

Yeah, we could put that in brackets.

Yeah, we could put caing in brackets. And then the only place one will be able to find out what it is is by the transcript of this live stream, which probably doesn't work because I'm sure that the system that's doing transcribing doesn't know how to. It'll be interesting to see what it produces for the word K snaffling. Okay. Function stack those arrows. That's not how we present stacks normally. I don't know whether it's bad idea. I mean, it looks okay to me.

Well, I think the reason we did that is there was an earlier version that I think might have done a column, but it makes it so that the, The. The length of this box is flickering rapidly.

Yeah, it's okay. I think it's okay. All right. And lighter gray for the internal stuff and maybe lighter gray for the arrows. Make sense. Should we move on to error reporting?

Yeah, sure. Right. Error reporting. So this. Right, so we compile something and there's an error in it. And we now have a somewhat useful mechanism to see where your error actually.

Okay, so look, look, look, look. First point. We really should expose that more obviously than. Oh, you have to press the dot.

Yeah, yeah, I get that. I. Lou says sometime, though I'm, I'm completely reliant on Lou to provide this interface. He believes he can have a button to show up in the. In. In the text here.

Okay, so. So what would the button say?

It could.

Button would say details or something.

Something like details. Yes.

Well, then that should say show details, not show compiler error.

But shouldn't it say something? Actually in the, in the.

In the original spec, it says source. So it's at the end of the message.

I see.

And it's a button that says source, I think.

Yeah. On the other hand, it doesn't say compiler in it. People look at this and they don't know which.

Well, they're not going to look at that. So you might as well take that. I mean, show error source or something. All right, but maybe just show compiler. But I don't think it needs a separator. Line before show stack trace.

Right. I'll have to. That. That comes from Lou, but.

Okay, but it doesn't. I mean, it's not the most important thing in the world. Okay, let's take a look at that source now.

Right. So we click on this and we get a, you know, thing.

A thing. But what's a thing?

So we get this box that comes up.

Yeah.

Now this currently says anonymous function, but we could use the label pure function.

We should.

We decided to do that, so I think so.

Okay, but. But how do I see more?

Well, there isn't any more. This. This is the source and this is the error.

Why the heck aren't we just generating that? As.

This one is short. But they're not in general short.

This is.

It's annotating the input code. So the input code can be really long.

Yeah, this. This is. This is. Yeah.

Okay, now what happens if I want to edit that? Does that box stay up when I edit?

No, no, it's not editable.

But I know it's not editable. There. Edit the source code. Edit the source code.

Oh, this source code.

Yes. I could shoot that box goes away. That will be infuriating.

Right, so, so I think it should be. It should be the same as, as the, the. The stack trace thing for the evaluator where it has this pop out and.

I think we should have a pop out. We. We haven't done this yet, but I think a pop out thing would be useful.

Yes. Okay, so to run it again.

Run it again.

Okay. Okay, so now. Okay, it shouldn't say compiler error at the top there, because that's not what this is.

This is.

What's that?

Well, what is it then?

It's the annotation of the source code for what led to the uncompilable piece.

Right, but this is an error. This isn't. This is.

It's not an error. That in and of itself is not the. I mean, it's more subtle. What's that?

It is. It's cosine of a boolean. That's a. That's a. Well, okay, but that's an error.

Okay, but it's a. It's merely. It's uncompilable.

I mean, it's probably nonsense, but.

Okay, but hold on, hold on, hold on, hold on. Is the only thing that can come up here an annotated version of the source code?

Correct.

And is that header bar and the giant header footer, are those determined by some other system? I mean, they're very, very big.

They are this. Quite a lot of this is determined by some other system. The label, the text in there comes, you know, is provided by this, you know, the compiler.

Okay, but then just say what this really is. This is annotated source that shows what couldn't be compiled. Is that correct?

Yes. Or the location of the error in your source.

I don't think it's an error, it's just something that couldn't be compiled. It might be the compiler's limitation that it couldn't compile it. Right.

Yeah, maybe.

Yes. If I. I mean, the whole point is, what I think we're going to see most of the time here is if I'm trying. Look, I had an example yesterday, I think Brad was trying to do this, of compiling some stuff, and of course it didn't compile. Okay, but what I want to see. And you know, why didn't it compile? Because something isn't supported in the compiler. That's not a compiler error.

Right.

Right. So you know, it's more like uncompiled elements.

Well, it's not.

Yeah, it's pieces that couldn't be compiled, isn't it? And the reason they couldn't be compiled is. Is various. Like it was a bad idea to ask it, or we simply haven't supported that yet, or whatever. Because the main thing somebody's going to do is try changing it and rerunning with that thing modified and they may say, oh, I made a mistake. Or they may say, oh, the compiler doesn't support that yet. Let me rewrite that. Using simpler functions.

Either of those are possible.

Right, so then it is not a compiler error, it's a. Okay. Cannot find a definition of the function. Cause that takes an argument with a type Boolean.

Actually, again, in the original spec, that message was essentially the title. But as Tom mentioned, I don't know whether we can actually get rid of that sort of, you know, the forehead. But if we could, then maybe that would be fine.

Well, I'm sorry, to do what? To have the.

Well, so essentially there's that compiler error stripe at the top. Wouldn't be there. And so that really, the heading becomes just what the message was.

I see. So there just isn't. But there has to be an X somewhere, so there's got to be some kind of header at the top.

Okay.

I mean, this thing is very easy to dismiss, given that by just kind of clicking elsewhere. I'm not sure it's completely necessary, but I think. I think finding a place for the X button is a smaller problem than sort of thinking of something to put in that enormous header. Right.

Well, okay, so let's see if we can remove that. But if we can remove that.

Remove what? I can remove the text is easy to remove, to have no text, but there's still going to be some sort of bar here.

Well, I think it'd be better to have no text then. I think compiler error is not helping anything.

Yeah, fine. Okay, that's entirely feasible and maybe we.

Can minimize that bar. But that's a separate implementation. Assume that's fine.

Yeah, I can ask Lou about that as well, and he can probably do these things quite quickly quite often.

So now, is the word source what we really want to have or show source or something like this.

In this thing here?

No, no, I don't mean in there. In the button, which I'm hoping we're going to get, because nobody's ever going to find it without the button.

Yeah.

We have other things that have actions there, so there's got to be a way to do it.

I think it's feasible.

Do we Button?

No.

We also have it in the. The update function. Obsolete function.

Oh, sure, sure. Okay.

Okay. So I think that should.

What.

What is the thing that we most ATT. Show? Source. I mean, it's a little weird because you've got the source sitting right there.

I mean, it could have more information or details would be pretty attractive.

It's also that the source is not necessarily just above both because you might be doing something like build compiled component where the source is in a compiled component and because there's an example lower down where it's more complicated where, you know, the error is deeper in the stack.

I see.

Should I show that?

Yes.

Right. So here we've gone to.

I remember, I remember. Just show the thing.

So then we run this. Oh, I can just come and open this up so we get this very nice little courtesy of. And I can open and close.

Hold on, hold on, hold on, hold on, hold on. So compute position is a, is a user defined function here.

Well, in this case, someone makes a mistake in their own functions, it's going to be a user function. Like, like, like, like here.

What's that? Compiled type system declarations, blah, blah, blah. What is that?

That?

That.

That's just. He, he copied this out of a long piece, a piece of code deep in some weird context. But okay, fine, but it's, it's alighting that. It's aligning that context. Unless you mouse over it in the.

Yeah, yeah, okay, fine. But that's Great. But I mean, but that thing isn't that. That's just because you happen to be showing a piece of internal compiler code.

Yes. Yeah, it was a.

To.

To generate some errors. Yes, Just. Just to generate some errors without.

Okay, now how do I know what the red squiggle means?

Well, I think the red, the red squiggle isn't that annoying.

Isn't that unbelievably annoying that it just goes away?

Yeah, I think a pop out thing would solve that.

So. Really what it is, is show location. That's what this is really doing, right? It's showing you where that error occurred or where that thing that it's commenting on actually is.

Maybe, but there's going to be a source file for these, like, like a source file or a notebook, and that's the location. But it's not, it's. It's not showing you that.

Well, I know, but it's showing you the, the. Okay. And it's annotated code, basically, is what it's showing you.

Yes, yes.

So maybe we should just say annotated code. But that's a little bit unattractive. I mean, by the way, in the header bar we could put annotated code if we wanted to. Well, it's pretty obvious we're going to.

Try and get rid of that, so.

Yeah, I know, I know.

I think that's better because. What else is this? Can I show some of the other ones?

Okay, but hold on, I'm thinking about what that should be. Show source seems like the one that is most reasonable to me right now. Okay, so open up Bin Run, for example.

There.

Okay, what was that? What's, what's the line? What's the underline there for? Why is that underlined? Because that, because that stack trace the.

Underneath thing, you see. Whoops. Hang on. This is the thing. So it called Compute position. Here's Compute position and Compute position had the error. So it's going down through this chain of, you know, function structure. So function call stack. Right? Yeah.

Okay, so here. What, what's the do while. Why is the do while in that weird color?

Well, because. Yeah, I, I could probably change that to some.

But what is it? What is it? I don't understand what it is.

Do while is a function that we don't have. It's just convenient for the compiler because it makes sure. Sure that for, you know, continue and things.

Is it not until now?

Not quite. Because there's always.

But I don't understand what it is here. Is it, Is it an Internal context function or what is.

It's an internal context function. Yes.

Which you are synthesizing here along with the val. Well, VAL dolla dollar. I understand, but you had those VAL quadruple dollar one. What the heck is that?

It's just renamed because VAL appears. I think appears more than once. So.

Right, so, so this is using. Yeah, I mean, okay, so I think this is basically using the general utilities print definition thing for formatting in terms of code.

So.

But, yes, right, but that has, I.

Mean, I know that's General utilities has to be expunged. We have to turn those things into wfr.

They're somewhat useful.

Yeah, I know.

So I think most of them are WFRs. I think most of them are.

Yeah, I know. So let's finish that job. Yeah, can we please finish that job and make sure that the function repository people, you know, we farm that out and get it done. We just don't want to be calling this weird because then you're loading the whole event General utilities, which contains all kinds of definitions.

Well, I think that happens if you call the WFR as well, isn't it?

No, no, I mean, that's the whole point is to untangle it. So you're not doing that.

Okay.

Okay.

Well, in any case, the function, this is, well, this is calling, I think, modified code from print definitions, which is in fact in function repository.

Okay, okay, fine. But that do while is an internal context thing that is being, you know, weirdly variegated colored to indicate that it is an internal thing. Is that correct?

That's, that's, that's correct, yes. And I could improve.

Yeah, so I think that, I'm just looking at print definitions. I think what they do is system stuff is just black stuff that is not system stuff is gray and underlined. And it's underlined because it's a link, because you can click on it and then see that, you know, recursively see the definition of that thing. So here I think it's just, it's still a gray, but it's not being underlined anymore because you can't click on it anymore.

So. Okay, so I don't understand why do while, unlike unchecked, which is gray, why is do while in that kind of neon color or something?

That I have no idea.

Yeah, I, I, yeah, it seems just wrong.

I mean, we definitely don't want to, we neither want to emphasize it.

I'm sure that could be improved.

Right. But nor do we want to indicate that it's in red, like an error.

Yeah, yeah, yeah, no, I'm sure it can be improved, like grayed out.

Okay. All right. So were you going to show some other examples of these error?

Well, this, this was the only thing, you know, we just go down through the thing, see. And these things are not tiny, you know, it's okay.

So everything that's listed here hasn't. Has an error in it, is that correct?

Well, right. So this is what you typed in. You typed in bin counts. Bin counts called, you know, this other version of bin counts called a couple of versions of bin.

So it's the call stack that you're seeing?

Yes, yes, eventually right at the bottom in this compute program position thing here.

It.

It. There's a mistake, there's a bug in the thing. Super helpfully.

Can I ask the question. When the call stack is presented in the progress monitor, which way round is it? What comes first? Compute stack or the. Or the compute.

It would show this anonymous function first and the compute position would be on.

Should the arrows go the opposite way around?

Oh, they could do.

Or shouldn't it go? I mean, which way up should the call stack be in the. In the progress reporting. What's. Okay, if we were showing the thing.

That changes the most on the right hand side, I think.

Okay, but, but Right. Which is the bottom of the. That's not right. That's not right. When you show the function stack in the. When you get a message. Right. If you go to the function stack there under. Under the dot dot dots.

Where's that? Sorry?

Well, I don't know where it is. It wasn't there possibly because this happens at top level. But normally it would be there. No, normally it would be there.

Yeah.

Which way up is the function stack? I believe the first entry is the lowest one.

Show stat trace. This is the thing you typed in and this is the message. Right.

So the most rapidly changing the proximate cause is on top in the stack trace.

Yes.

Which is the same thing you're doing here, right?

Yes.

The proximate cause is on top.

Yes, that's. That's right.

But it is the opposite thing from what you're doing in the. In the compiler trace.

Yes. I think it would be very annoying to have on the left hand side to have the thing because the thing would be flickering a lot more.

Then put the arrows the other way around.

I can do reverse the arrows.

Does that make sense to other people?

So I'm not quite sure what you. What you mean.

Well, okay, so we've got in the way he was representing the Stack is blah, arrow blah, arrow blah. Okay, but the first entry there is actually the bottom of the stack. That is the most rapidly changing thing. And so what I'm saying is put the arrows the other way around. Since he says he wants the. No, wait a minute. Do you want the most rapidly changing thing first? Right, Tom, in the progress report.

Yeah, in. In the error reporting. Yeah, definitely. Yes, and that's.

Yes, I understand that. I understand that. So which is the same as the stack trace. Yes, I think the problem is that the. Okay, so which is the same as the order that you're reporting it? Is it or is it not the same as the order that you're reporting it in the progress monitor in the progress panel?

Well, I mean. I mean, this is done vertically and the progress monitor is done horizontally.

Okay, but it's the same order. It's not the opposite order.

Well, I don't know what. I mean, if you took the thing you're looking at here and moved it, flattened it on the left, then it would be opposite, and if you flattened it on the right, it would be.

No, no, no, no, no, no, no, no. I'm asking, if this was being presented in the progress monitor, would it say, compute position, arrow bin run, arrow bin.

Anonymous function, arrow bin counts, arrow bin counts, bin run.

That's bad, right? That's the opposite way around from the way the stack trace works or the way that this works. Why do we want that? Why not put.

Because the thing that. On the left is the thing that doesn't move. So if you reverse that, it would. There'd be a lot more flickering and.

All right, so then the only way to avoid that is to have arrows pointing the other way around, presumably. Is that right?

That's possible to do that? Yes. I mean, that's easy to play with. Yes.

Hold on, let me think about that. Is that even. Right? Is that even the right thing to say? It's the thing on the. No, maybe the arrows are the right way around.

I mean, it's the thing. The top is the causality. So something is calling something else.

All right. Okay, okay. It's fine. Okay, let's. Let's consider it fine.

Right, Right.

Okay.

I think this is beautiful, by the way.

It is beautiful. It will be even more beautiful when.

And it'll be better. We're making it better, so I'm not disagree with that.

Right. Okay, can we. Very quickly.

Errors like this is. Is astonishing. It's so useful.

Of course it's useful. That's why I was pushing you to do it over many years. Yeah, yeah, yes, well, it's very nice. I mean, and as a practical matter, I'm sure it allows you to understand how to compile things much more easily.

Oh, yeah, yeah. We, we, we, we can go much more with this. You know, this is, this is just the beginning here. I think so, yeah.

So as a practical matter, as you're trying to compile the compiler, you're presumably doing this all the time.

Yes, well, Daniel's the. Daniel. Yeah, it's really helpful.

Before I had to do some internal tracing, but this is much easier.

Good. Well then hopefully we will be able to train some other people to do this as well. Yeah, yeah, like Brad and Nick and people like that should be able to, you know, do more self service. Compiler debugging. All right, can we look very quickly at the other items here?

Yep, yep, yep.

I need to run.

Yeah, sure, sure. So, runtime error action. So there's a runtime error, you know, X.

And the question is, does it just abort completely or does it has to.

Abort but by default it reruns the calculation in the evaluator? Sometimes that's useful, sometimes that's like completely annoying. So. Yes.

Okay. And this is a top level symbol for what? Top level.

This is an option runtime error.

Of what?

Of the compiler, compiled code, function that's generated by function compile, etc.

So. But it's an option to function compile, correct?

Yes, yes.

Seems reasonable to me. Do we not want to put compiler. Hold on, hold on. Do we not want to put compiler in the name of the, of the option? Because a runtime error could be a runtime error in the evaluator as well.

Maybe you'd want the same option name for that. You might want error. An error action for that.

Well, how would that work? I mean, I don't know how it works.

I'm just saying it's not inconceivable that you'd want.

No, I agree, but I'm not sure this is the right thing. I mean, it's a little weird to me that this is a. I mean this seems very general runtime error action, yet it's for something very specific inside the compiler. Well, I mean, runtime error action.

So say that again, sorry.

Compiler runtime error action.

So I think there's a thing called for reference. I think there's a thing called. Was error action.

Yeah.

Or no, not air action. What would prefer data set failure failure action.

We had on noise, right?

This is for query and data set.

That's incredibly absurd.

This is semi modeled on that.

The fact that it is a kind of a crazy thing. One craziness doesn't justify another craziness. Look, if we put compiler runtime error action, we will be safe. At least it's defensive naming Compiler runtime error action. Yes. Okay, let's just look at type declaration enhancements for a second, please.

I'm just writing that down.

Right, I understand, but we, we have notes, so you don't actually need to write it down.

Yeah, that's fine. Right, so this is adding. There's two options to type declaration and a new dec. You know, a new type of declaration.

This does not seem like a five minute discussion.

Possibly not. Right.

I think we should reschedule for another.

Yeah, there's another meeting that I've asked for, so we should just add that.

All right. There's a comment on a live stream from Ahoy. Be helpful for the box form there to show what is loaded and the checksum for external libraries so a person could inspect and verify. This was, I think from.

Is that on the first. The first one? Maybe.

So we have do with this. We've been discussing.

We actually have. I was just gonna say we. We have for. I'm trying to remember where this gets used for installed functions. If nothing else. We do have a check thumb that makes sure that the. The library matches the component, but it basically just. It prints a message if it doesn't match.

But I think having visible. I mean, by the time we've got this whole stack of other information here, why not have the checksum there?

Yeah.

Right in that. In that displayed stack.

Well, the thing is you need to be able to. There's. There's two things you need to be able to do. You need to be able to get the checksum from the compiled component. That's easy. We, you know, we could easily add a property for that. But then you need to be able to get the checksum for the. From the library. And that might not be totally trivial.

Well, you mean that's an external file and one of the things that would be an interesting function to have would be file checksum.

But if the library is loaded, it's.

Not just getting the checksum of the file, it's getting the checksum of the code that was compiled to generate that file.

Exactly. Yeah. Yeah.

Wait a minute. But the thing you can verify to find out it's not kind of a tampered library. Oh. Is.

Well, okay, you're right. This is not. This is doing a different. There. There's two. There's a couple reasons why you might want to check some. One is to make sure it wasn't tampered with. The current mechanism does not do that. Right. The current mechanism, all it does is it checks that the code. Right. It checks that the code that was compiled to generate the library is in fact the same code that you have in your compiled component or assuming. Assuming no adversarial stuff. And the reason for that is for versioning so that you don't. If you, if you have an old library, it'll throw a message instead of it just failing when it tries to load a function that doesn't exist or something. Yeah, but for the adversarial case, it's hard because the problem is that right now all the fields in a compiled component are, are just declared by running declare, compiled component and stuff. So it doesn't know anything. You know, if you, if you built a library in a previous session, it doesn't know anything about that library anymore. And so how would you get the correct checksum into the compiled component?

Well, I mean, if, if it said in the compiled component here, if it said it's, it's current checksum, you could copy that.

It doesn't know the checksum of the library. It only knows the checksum of the source code. Like you would have to build the library and then hash it in order to get the checks. And I'm not even sure it's deterministic.

Because it's some randomness in the compiler. Optimizer. Optimizer or something might change that gets.

Added by the compiler or LLVM or.

Yeah, right. Like if you compile something twice, I'm not sure they're actually okay, but.

So what is the use case? I mean, the computer security case is somebody sent you a library and they say, be happy, just run this.

Well, I think, I think that if you, if you want to verify it's correct, they should send. They should. Like, like when you get the component, you should also. There should be a hash that's hard coded into the source code of the pack, let's say, and then should run file hash and check that. That that's correct.

Yes.

Okay, but it would be nice to provide a pipeline for that.

I mean, the only way I think you could really have a pipeline for that is if you have a field, like a declarable field in your compiled component that is the hash of the library. And that's something that it can't automatically put that in. You would have to run file hash get the hash and put it in.

Right. Somebody has to send it to you separately. Somebody could send you the source code here that says. I mean, okay, it's a question of what's tampered with. If the library is external and comes separately, then this would.

So actually, I think the real way to do this is whatever would be packlet wide. Because. Because here's the thing, right? When is someone going to send you a library for this? The answer is when there's a packlet. When. When this compiled component is in a packlet and it comes with a library inside of it. And in that case, really, you might as well just. Just hash the whole packlet and make sure that the packlet is really what you think you're getting.

I agree.

And I don't know if we already have a mechanism for that, but we obviously could and should.

All right, so that's the thing for Todd and ECE to discuss. And a worthwhile one. All right. Anything else here?

No, we'll have a follow up thing. Can I start, you know, putting fun. I mean, I've written tentative function pages. Do you want to look at those or shall I just start adding them?

Christopher, why don't you and Christopher go over them?

We. We went over them a bit, but we can do that again. Yes. So.

Right.

And then I. I could look at them, but I'm sort of hoping that you guys can resolve them.

Yeah, yeah, fine. We can do that. And I'll knit them into places and things like that, so.

Sounds good.

Good.

Yep, excellent.

All looking very nice.

Fantastic.

Good stuff. All right, see you all soon. Bye.

Bye.