 The T2 Tile project is building an indefinitely scalable computational stack. Follow our progress here on T Tuesday updates. The purpose of the technology is to connect physics to value, physics being what stuff just does anyway and value being something that's good for us, people, something like that. And information technology is the same way. And there's a lot of layers in connecting physics to value via information technology. And at the lowest level, near the physics, you have things like voltages and individual bits and so forth. And at the other end of the stack, at the top of the stack, close to value, you have things like shopping carts and credit card numbers. And building an information technology stack is really expensive. And the number one trick of making it all work out economically is to make the stack programmable so that you can take the same, essentially the same program, the information technology stack and sell it into a whole bunch of different markets where it can then be customized relatively inexpensively to get value in many different ways, all of which feeds back indirectly into the stack overall. So the programmability of an information technology stack is absolutely critical for making it an economically viable proposition. But in traditional computing, we have taken that and gone completely crazy with it. And the idea that we should make everything as programmable as possible and as low a level possible as close to the physics as possible has just been the backbone of the way we've been thinking we'd need to do all of this stuff. And from a point of view of robust first and best effort computing, that is a terrible, crazy evil idea. And what we need is not a notion of Turing equivalence that all universal programming things are the same so that it doesn't matter where we stick it in, but it should be a notion of Turing anti equivalence that no matter what your alleged computing model is, it's only once you've actually embedded it in the physics somewhere in the stack and put it in that stack in the actual physical world and deployed it to let it do something that you can actually know what the consequences of the unpredictability implied by programmability really are, because that's what programmability is always a two edge sword. Make it easy to change the behavior makes it easy for bad guys to change the behavior too. So in the T2 tile project in the movable feast machine, the language Ulam is the program is the sort of lowest fundamental programmable layer that we're trying to decide to expose. We have layers below it now, but they're for research purposes and we'd like to get rid of them and burn all that lower level stuff into hardware down the road. Ulam would remain a programmable layer, but it's got a lot of restrictions on it compared to typical languages. You know, it doesn't have pointers. It has very little pro persistent state and so forth deliberately because we don't want to provide more programmability too close to the physics than we need to get the job done. We've had a new version of Ulam just about every year for the last several years. It's time to get Ulam five out the door. It's not released yet. I'll show you how to get access if you're a programmer because I would like to get some feedback on it soon. I'm also considering making some breaking changes to the libraries to clean them up a little bit that's going to mess with backward compatibility of the code. I want to hear from people. I really hate breaking backwards compatibility, but I just don't know how many programmers we have out there. And if we can clean it up before it gets too welded in stone, that would be a helpful thing. So the big point, the big programming language feature Ulam five is multiple inheritance. You can you can inherit from multiple classes simultaneously. Sometimes that's just a convenience, but where it really counts is when you want to tell the world, you can interact with me as a Q content. And it's typically when we have the cells going, everything that was supposed to be allowed inside a cell would all have to inherit from a base class, which we typically called Q content. Well, that's fine. But now you've used up the base class in a single inheritance language. You can only have one base class. What if you also wanted to have other features that so someone else would say, can you bond to me? Yes. I say, you can bond to me with multiple inheritance. You can state that you can say I am of this. I am of that. I am many things. In addition, we have a printf for anybody who's tried to debug in Ulam. There should be going, it's a limited printf. It's a re-implementation. It's not the real thing. It only has a few percent codes, but it's still a huge help. And we also have this new programming language feature. Well, new standard library feature in the event window library called get site number where you can give it an object like anything, an atom, a reference. You can give it self and so forth. And it will give you back the site number in the event window where that object is located. If, in fact, it is in the event window anywhere. It might return a thing saying, no, it's not in the event window. But this allows you to write code that does not assume that the object that is running is in event windows zero. This is very powerful. It's going to help us a lot with abstraction put together with multiple inheritance. Let's take a really quick look at it. So in order to do this, you got to check out from the GitHub on MFM, the branch is dev MFM for Oolong five on the Oolong side. It's dev Oolong five provides and then rebuild everything in creation. I've done that here code. I've changed my make file so that it's pointing at these special ones. I just came out and and here's so here's the out of the box element. So so just as a completely stupid example. Well, so the so the syntax for base class is colon. That's that's the superclass. Whatever you're choosing to be the superclass. But now you can add other things like I can inherit from fail. What does that let me do? It lets me write this for example. Why can I do that? Well, because the fail method is now a method inside the class that we're part of. Well, let's just do this and then I'll move on. Byte stream logger log log.print of you can print multiple lines. You need to end each line with a new line or else it won't actually show up in the log. What is the answer? Well, let's do this. All right. And so let's let's see if that'll go. It's looking pretty good. Usually syntax errors come quickly if they're going to come. All right, let's get this off my head. And we will make a my element. That's going to be way too small. So we'll just look at it. We'll use the magic wand. The magic wand allows you to give events to specific sites. Bam. Okay, it's gone. Well, so was that a big impression? Well, let's take a look at the compilation output. Where is it? Where there it is right there. Look at that. The answer is 11. Who knows? It was a random number. There's our next line. So there and furthermore, when we failed, we had a string message saying something that can help us debug the thing. It's still the case that the backtrace that you get after a failure is very unhelpful because it's all full of incredibly mangled names. But step by step. So you get the idea. Multiple inheritance is there. We get around the diamond inheritance problems for people who know about that sort of thing because all our base classes are shared. It's not possible to inherit twice and end up with two copies of the data members of any particular class. Fail and random and a bunch of other things that you can hear from. They're all zero length. They don't have any data members. So it doesn't matter. But that's the rule. All data members, all base classes are shared in 5. So. Oh, well, I really can't take the time to do get site number, but it's really very cool. We'll see demos about that going forward. Let's push on. All right. So in the hardware division, yes. You know what these things are? These are the little feet that the tile feet click into and click out of. I've made a bunch of them. So there's an example of them here in here. Each of them has two feet. So it ultimately takes two of these things to do a tile. And I've been collecting up in a bag. It turns out there are about 2.6 grams apiece. And the bag itself is about 31 grams. So here's a bag that I made over the last week or so of these feet. And according to my calculations, it weighs just over a kilogram now. So 1015 grams minus 31 divided by 2.6 divided by 2. We have enough feet for 189 tiles. That's pretty much going to do it. I mean, we may have up to 200 tiles, but no way they're all going to work. I'm targeting 144 to 150 plus reserves for failures and updates and so on and so forth. So it looks like the feet are done. What we need now is the... So we saw this before, the hooks that allow the interface between the frame pieces that we've got and this sort of pipe hook thing to support it. I didn't really like those things because they seem too long. This area up here is doing nothing. Don't really want that. So I did a bit of a redesign to move the interface higher and so on. And so I tested it out. I got a suitcase. I put some books in a suitcase, tied a string to the handle, tied that string around one of these straps. And I hung it from the ceiling. This is with about 14 pounds of load on that one thing. Now, I worked it all out and assuming we have a 3x3 grid of power zones, which is I'm imagining what we're going to have, each one of these individual things is going to be carrying a max of about 10 pounds. That's including power supplies and wall warts and room for extra stuff and so on. So this is about 50% over what we expect the max would be in the delivered system. I still wasn't completely happy about how much flex there was. It's a little bit hard to see here, a little bit there as well. It didn't seem to be anywhere near failing, but I didn't really like it very much. So I went back, well, number one on Andrew Walpole's recommendation. I switched to PETG from PLA. This stuff is great. I really love it. I already went through a spool and now I've gotten some more stuff, this Prusament stuff, which seems wonderful. And it runs at a pretty high temperature, which is good in the sense that it means once the stuff is done, it's not going to start softening up just because it's running near the Beagle bones, which are running hot. So I redesigned this piece down here. Now has a closed back. It also has this tongue sticking down over the mating piece that comes in from the power zone frame to help support it. I also changed the angle on this interface where they connect in so that it's now tipped six degrees in so the pipe interface gets a little bit of a better hook over the pipe when it goes. And I hung it up with the 14 pounds of load on it and I left it for several days. There's still a little bit of flex. You can see the support thing now running behind it. The whole thing is just generally beefier. But it really seems to have held really quite fine. And so here that is. Here's the piece we can take the, this thing comes off. So if you can see, probably you can, but probably not. The one that was holding the weight for four days or whatever. It's just a teeny bit flexed compared to the one that was loose, but really not very much at all. I think this is fine. I think we're done. And in fact, I am now in production on the frames itself. We need to make 80 of these pieces. We now have, well, we have this. So it takes eight for each one. So this is a single power zone. This is eight pieces and we need nine more. We've got almost the next one completely done. All right, that's the hardware situation. The planning division. Yeah, we just said last week that it was all about intertile events. Why am I not talking about intertile events this week? And the reason is, is because I've been blocked on this for a couple of weeks. And fundamentally, I feel like in the run up to the end, in the run up to the end of the first year, I was making a lot of kind of cheesy software decisions and I was kind of sleezing it out. And I was doing all the sort of thing that I used to give my students trouble for when they did it in my programming classes. And really what I need to do is step back and focus on the redesign from a slightly higher level, design an explicit state machine, the detailed state machine, like the lock stuff has a detailed state machine. And that's been really helpful. The cash processor update. It's all sort of implicit in a bunch of code that needs to be all pulled out. So I'm re re re gearing, retrenching to make a cleaner run at intertile events. Now that may get pushed back in addition because I'm considering sort of taking kind of November off for sort of a special project. I haven't decided whether to do it or not. We'll find out about that over the next week or two. But the long and short of it is you can say I'm chicken and I'll say, yeah, I'm chicken to actually get to intertile events, working and deal with it. But really it's so important we need to get the software base cleaned up a little bit before we start striking at, you know, hacking that and hacking it and changing things. So all right. That's the story. The next update will be out in a week. Trying to keep these 15 minutes max now. Thanks for being here. Have a good week.