49: 64 bytes of guaranteed uniqueness

So I think we can start with lots of news this week. It's been a few weeks since our last episode. We had to postpone last week, which has given us a little bit of a chance to get a little bit more queued up news, but we have several things to talk about this week. - Yeah, indeed we have. Actually last week, I had just finished participating in the Server-Side SWIFT meetup, the third one, organized by the SSWG, which is the SWIFT on Server Working Group.

There's just so much SWIFT and server in those names. And I think this is of general interest. I mean, it's a Server-Side SWIFT meetup and working group, but the topics were actually not all that Server-Side specific, I'd say. So there was a great talk by Jutta Seito about SWIFT WASM. And there's a package also that I can mention while we're at it, WASM Kit. It's not a single thing. So there are a number of things that are sort of in the category of WASM.

And WASM, what does WASM actually stand for? I keep forgetting. It's Web-- - WebAssembly, I think, yeah. - WebAssembly, exactly. So effectively it's sort of, I think, and Jutta had a really great way of phrasing what, why WASM is such a big deal. Think about what JSON has done for data exchange. Like really, you mentioned JSON and you want to receive JSON. Everyone knows what you're talking about. And it's just about what fields do you want? But all the exchange format is really, really clear.

It's sort of become the de facto standard for data exchange. And WASM could be that for executable, for logic. Because it's essentially something that can be produced by various different languages, Swift being one of them. So, you know, Rust, I don't know, I guess Python, you know, all manner of JavaScript, all manner of languages can produce WASM as an executable format, which can then run on many different, in many different places. Like the browser, they are just runners.

Like there's a thing that's actually written in Swift that can execute WASM. So it's a proper exe exchange format, executable exchange format. And it could be sort of the lingua franca for exchanging logic. You know, think plugins, you know, what if you wanted to have plugins that are shippable? That could be WASM. There's a really great- - I think that's- - Yeah, go on. - I think that's a really nice way to think about it, actually, because I'm much more excited.

So I actually, I attended the meeting and watched this talk on WASM. And I actually, I asked the question halfway through, which was, you know, how does it interact with the browser APIs? And I'm, and it does interact with those browser APIs, but I'm much more excited about WASM as a non-browser technology.

So I don't think I'm going to be rushing to interact with the DOM when we're doing the bits of JavaScript that we need to do on the Swift package index in WASM, because I don't really see any advantage to that. In fact, all you get is a slightly degraded experience because those browser APIs, they work, but they're, you, it's not, it's not how they were intended to be interacted with.

But for other bits of code where you might have to either re-implement something that you had in your server-side code or something like that. And as you say, as maybe like an interchange format for code, I think it's a much more exciting technology in those cases. - Yeah, exactly. I mean, think of all the places where you have executable code that should run cross-platform, for instance. And like one example that's been brought up that has actually been pitched is macros.

So right now you have to include Swift syntax, right? When you have macros and you want to generate the source code and you have to build all of Swift syntax, and that's a huge strain on the build system, on your builds in particular, if they release builds. WASM could be the exchange format, such that you don't have to ship Swift syntax in source, but you could ship it as, my understanding is at least that it would be shipped as a WASM build that then gets run. So you skip the build step of it.

You automatically have a cross-platform plugin and you don't need to ship like five different slices of, you know, how would you even do that with Linux? You know, you can ship a binary that runs on macros, Intel and ARM, you know, by having a binary that has the two aspects of it, but that wouldn't work for Linux. And then you'd have to bundle that up somehow. But with WASM, it's just one thing that gets run on different platforms because they know how to execute that.

So that's quite interesting. Just give the, the meeting has been recorded. So there's a YouTube up where you can watch the presentation or it's really nice, really interesting. Opens up lots of possibilities around that topic, you know, executable logic exchange. - Sure. - Yeah, and there was a second interesting talk by Konrad Marowski of the Swift team at Apple. And that's also not, wasn't really server specific because he talked about getting ready for Swift 6.

And that was a really interesting talk as well. Was, he started, I think he started off with a reminder, you shouldn't panic, don't panic about Swift 6. It might even have been his first slide, but he also had great tips on how to hold your towel when you do panic. And if you don't know the towel reference, you can do a web search, but you know, you might end up in places where you get warnings and you don't know how to deal with it. And Konrad had examples of those and how you deal with them.

And I think that's a great talk to take the edge off because I think, and we've talked about this a number of times, there is a lot of concern around Swift 6 and Konrad really addresses that and calms people down, I think. And he's done a really great job laying out how you should approach it. - That's great, yeah. And talking of events, Swift events, you are actually at an event where you will be, by the time this gets released, you will be at, you're not at, talk about a Swift event.

(laughing)

- Yes, I will be at the Swift on Server Conference in London next week. In fact, I'll be leaving tomorrow and this podcast, I'll be ahead of the podcast and the podcast will arrive after me there. Yes, I'm really looking forward to this one. Lots of people I've interacted with. Online that I've never met in person, so I'm excited to meet lots of folks. I've already got a list of names of people to get in touch with. Yeah, exciting times.

Unfortunately, you're not one of these people on the list, but we'll manage here. - I'm afraid I'm not. Yeah, like I said, I've not been super well recently and I'm not gonna be able to be there this week, which is a tragedy because I was there the last time this conference was put on and it was not only a fantastic conference, but a great opportunity to meet a lot of people who I hadn't yet met in the server-side Swift community and it was a great event. Fantastic venue.

I think it's at the same venue this year. It's the Science Museum in London, which is a fantastic venue. And as you say, just a really good chance to meet a lot of people. But it unfortunately does mean that we won't get a chance to meet up again this time. - Yeah, unfortunately not. But you mentioned, we were on a call yesterday, you mentioned a cardboard cutout that exists of you. And do you own that? Could you ship that so I can prop you up here in my office? - I don't own it.

No, at the end of, so we'll pop a link in the show notes too. This is something that happened a few years ago and there's a whole story behind it, which is too long to go into on the podcast. But at WWDC and Alt Conf 2019, there ended up being a life-size printout of me that was put in the Alt Conf kind of main lobby area for the entire week of WWDC. And it was there for people to take pictures with, which is the strangest possible backstory to this.

So strange, in fact, that I felt I had to clarify it in a blog post, which I did do, and we'll include a link in the show notes to that. But the main reason I wanted to clarify it is just to make sure that people understood that I didn't make a huge life-size cutout of myself because nobody wants to be that person. And that's not what happened.

But the slightly worrying thing is I didn't make it, I don't own it, and I don't know where it is, but I'm pretty sure it still probably exists somewhere. - This was spawned by PicswithDave, right? There was this Twitter thing. - It was, yeah. - I mean, be honest, you just outsourced the PicswithDave to a cardboard cutout, right? (laughing) - Exactly, yes. Yeah, it's all Kevin Hocter's fault. That's all everyone needs to know. - Right, right. - We also have a bit of contribution news

to talk about this week. We have a couple of things I'd like to mention. First is a contribution which is kind of in progress at the moment. So we've had a discussion around an enhancement with Daniel Lyons, who came to the discussions board on our GitHub project and suggested that we add a new type of filter to the search options. So we already have filters for things like license and platform.

So you can say, show me all packages that match this search string, but also are compatible with iOS or have a specific license or something like that. And one of the filters that you can add there is a filter on last activity. So when was the last commit or pull request closed or issue opened or something like that. So how active is the project? And Daniel suggested that we had a first activity filter as well, so that you can start to filter packages by effectively how old they are.

So you can filter to only packages that have been created within the last year, for example. Or you can say packages that are at least six months old or something like that, which is maybe a more realistic way to use it. And so we had a little discussion on the discussion board and that got transitioned into an issue. And Daniel is on his way to producing that as a pull request, which will get into the system and add that functionality into the software, which is great.

And then another contribution, which is a little bit further along. In fact, I think the final part of it is going to be merged today, which means it will be live on the site by the time you hear this. It's from Mirza Ucchanbalik. And that is a feature that we had in our heads since almost the very beginning of this project. It's a three digit issue number, which is pretty rare these days, that this was originally there.

And it's to add some information on package pages for packages that have been forked from another Git repository. And so what's going to happen is, as of by the time you hear this, you'll be able to, if a package is a fork of another package, you'll be able to see that right at the top of the metadata description on the package page. And it will say this package is forked from and then give you a link to the previous package.

And this is one of those features that is really interesting because it sounds much more simple than it is. And it's one of those that has a couple of little edge cases and it's been kind of interesting going through with Mirza to find those and then decide what to do with them and cope with them. So the idea is a couple of these are like, for example, the idea is that we could provide a link to the parent package, of course, that seems an obvious thing to do.

But then we have the choice of, well, what do we do? Do we link to the GitHub repository? Do we link to the Swift package index page? In that case, what happens if the package isn't in the index? I think most of them are, but we have to cope with those edge cases where it might not be, or for some reason, the original package author of the fork wants their package removed. And that the fork is now the definitive package or something like that.

So you have this condition of, well, what happens depending on where that repository currently, where that parent repository currently is. So that was kind of interesting. And then you've got things like, well, what happens if the parent repository is renamed or the child repository is renamed? And you've got all these kind of little edge cases around a feature like this. That something quite simple initially can turn into a much bigger feature than you might've thought it was.

But it's been great to work with Mirza on this. And I think it's turned into a really great little feature. And I'm really happy to see it ship finally, because this is something that's, well, this is something that tripped me up recently that I thought I was talking about a package and actually I was talking about a fork of a package. And it is really useful. There's nothing wrong. I'm happy that we have forks in, and I'm happy to have as many forks in the package repository as can exist.

That's not the problem at all. But the knowledge that you are looking at a fork is really quite important. - Yeah, exactly. I'm really glad we're getting to this finally, so to speak. And I actually was thinking about that as well. I mean, I think that prompted it effectively, right? Us revisiting that issue was the fact that we ourselves were tripped up, not realizing that the package is actually a fork. - Yeah. - Right, in other news,

there are a couple of important packages we wanted to mention that have seen recent updates. This is also server-side Swift. So Hummingbird 2 has come out. So the second version of Hummingbird. I believe you also linked to this in iOS Dev Weekly, didn't you, Dave? - Both of them, yeah. - Yeah, both of them, exactly. Yeah, and Hummingbird 2 is out. Beautiful webpage. I want to give out a shout out to the webpage. Looks fantastic. Really, really nice to navigate.

Briefly, what's new in version two, it's fully async/await. So written with async/await in mind from the start, and it is Swift 6 ready. Give it a go. I always, when I talk about Hummingbird and Vapor, the other package that I'll mention in a minute, to compare them, and this, apologies if you don't know Python, but in the Python world, there's two packages that are Flask and Django.

And Django is the one where everything comes, you pull in Django, you have everything, and Flask is the one where you pull in a core package and then you add things as you need them. And that's how I think about when I compare Hummingbird and Vapor. Vapor's the one where you get everything off the bat, and Hummingbird is where the one where you're more focused and more diligent about where you start and what you then pull in, in addition. - It's a really common pattern in the Ruby world.

There's Rails, which is the whole everything, and then there's Sinatra, which is the one where you start with the minimal and then bring other modules in as you need. - Right, yeah. Yeah, and it makes perfect sense, right? Sometimes, especially early on, maybe, when you're learning a framework or a language, it's nice to have something where you don't need to worry about finding the best thing to do, X. You know, how do I do database? And then you have to go hunting, well, what's the package?

It's really great on those occasions to have everything at the ready. If you know your way around, it's also nice to start small, right, and not incur the build costs and all that, and stuff that might be confusing or might be in the way when you actually know already, well, I'm not going to need that. So it's really great to have the choice.

And as I mentioned, Vapor also hasn't had the release, the next release, which is version five, but they've put up a post about the future of Vapor, and it's laying out the plans for version five of Vapor, which is, it's very similar to what Hummingbird 2 is really. It's fully async/await, using structured concurrency throughout, and it's Swift 6 ready, which isn't to say that neither of those is the case for Vapor 6.

It's just that in Vapor 6, it is async/await ready, so you can use it, and it's fully Swift 6 ready as well, but the async/awaitness has been sort of retrofitted, and in lots of places, stuff has been made sendable via locks.

So as a user, as an API user, you wouldn't notice it, but under the hood, I think you're going to, if you're very performance sensitive, perhaps, you would probably see that there's locking going on under the hood, but I think, and we've been using Vapor for years now, and we've transitioned to async/await fully.

We don't notice any downsides of this right now, but it's still nice to have the plan laid out, and there's also a couple other things, like moving to use a few more upstream packages, like for instance, the HTTP types from the Swiftlang, Swift HTTP types repository, so there's, and that's going to make it easier once you use these types as currency types to exchange.

If you have different packages that all use these types, it becomes easier to exchange those types because they then live in an upstream library, so imagine you have a router that returns some common HTTP type. You can easily plug it into another component that uses that same type without having to write a little converter for that, so that's really nice to see. The first alpha should be released really soon. In fact, it might be released already. I haven't seen it, but I might have missed it.

I didn't go actively looking. It certainly should be imminent, perhaps around the conference end of this week, or maybe shortly after. You should see the first beta of Vapor V. - The only other thing I'd add there is I think I should add some clarification on version numbers because there were a lot of Swift 6 and Vapor Vs and Homebird 2s and Vapor 4s in there, and I think you may have got the numbers mixed up a little bit, a couple of points. - Oh, did I?

- Yeah, so you were talking about Vapor 6, which is not a thing. That's Vapor V. - It will be, though. It will be, I'm sure. (laughing) - Yeah, so that's Vapor V with Swift 6 support, and Hummingbird 2 also with Swift 6 support. - It's, you know. - Just to clarify that. - I was 18 on the iPhone 17, right, and running on MacOS, oh God, it's all so terrible. - Exactly, yeah. And the Swift package index is still on version 2 and has been for the last three and a half years.

- Yeah, but for a minor version 101. (laughing) So yes, lots of version numbers. We shall, as an industry, we shall one day solve the mystery of how to do version numbers. - Oh dear. - So should we do some package recommendations? - Let's do some packages. Do you wanna kick us off? - Sure thing.

I'm gonna talk first about a package called Swift Snowflake by Jaehong Kang, and this is, so I hadn't actually come across the idea of this Snowflake ID. Had you? Do you know about a Snowflake ID? - No, it sort of rings a bell. I might've read about it, but I can't recall any details. - Right, okay, yes, it might, yeah. You probably will have heard something about it, or at least there are lots of technologies which I'm sure you do know.

Like for example, UDIDs are a similar, solving a similar problem to this. A Snowflake ID in best Wikipedia terminology is a form of unique identifier used in distributed computing. It was initially created in the early days of Twitter and used for the IDs of tweets, but now it's used by Masterdard, it's used by Instagram, it's used by Discord, it's used by a whole load of other products.

And it is a kind of guaranteed unique number that an individual machine can generate without needing to know what the previous number was. So 64 bytes binary, it starts with a timestamp, it then has a machine ID, and then has a sequence number for that machine after that. And a little bit like UUID or UD- - UUID? - No, UDID is unique device, isn't it? And UUID is universally unique.

Yes, you can then generate these numbers which are good for, maybe you can use them as database ID, but you can certainly use them for public identifiers for unique resources inside your application. And Swift Snowflake is a implementation of Snowflake IDs for Swift. So it's very, very simple to use. You can either represent a specific Snowflake ID if you would like to represent one that you already have, or you can ask it to generate one.

And there are various different strategies for encoding that if you want to put it into JSON. And yeah, it's a very, very simple package to use, but I hadn't come across the Snowflake IDs before, and I thought they were kind of interesting. - Interesting. Just to clarify, you said 64 bytes. Did you mean bytes or bits? - Bits, I meant bits. Like it's like Vapor 6 and 64 bytes. Yeah. (laughs) Yeah, a 64 byte identifier would be amazing.

That would be more identifiers than there are grains of sand in the world, I'm sure. - Yeah, that's for sure. But also, I mean, UUID is 128, and that is, that bears, I mean, it's a small risk, but there's a risk of collision. You said guaranteed unique. I mean, and that's half the size, I guess, that- - Probably. There is no mention of the word guaranteed unique on the Wikipedia page. - Oh, okay. (laughs) - That is me projecting my wishes onto this forum.

- Okay, that's a wishful thinking addition. It does say, it does say, I mean, per machine secrets number two, allow creation of multiple snowflakes in the same millisecond, which is quite reasonable. - Yeah, yeah, I mean, even with, especially with UUID, the chances are really, really slim. I mean, if you think your problem is a UUID collision, then in all likelihood, you need to think again, if that was really what's happening. - Right, yeah, exactly. Yeah, yeah.

And I think maybe that's the place to think about this rather than maybe a UUID, which is if it tends to be used for identifiers that might end up in like a URL. So where a UUID might be a little bit long for a URL, this is a little shorter and might fit into a URL more conveniently than some of the longer identifiers. - Yeah, yeah. Plus also not always, there are scenarios where you can think you might need an ID.

And if, I mean, even in the remote chance that there is a collision, it might not be fatal, right? You might be able to detect and just regenerate. You know, that's also sometimes an option. - Right. - Uh-huh, interesting. Nice. Right, my first pick is called Versionator by Sam Dean.

And that's a nice little package. It's a build plugin that generates a source file with version control info. So I think that's quite a common scenario. And I even thought we talked about a package like this before, but I didn't find anything in the show notes. So if this is a repeat mention of a, not this package in all likelihood, but a similar package, apologies.

But this covers the scenario where you have an app and you want to expose version information that is, you know, like what git hash did generate this build, that sort of thing. And you don't want to automatically, you know, don't want to manually track that version number. This plugin will generate a source file that you can use and reference in your application and then, you know, display it and whatnot.

It has a number of different things in the struct that it generates, like for instance, the build count. And this is using git under the hood to determine these values. So it counts the number of commits since the start. So that's a good thing to use for build count. The git commit, as I mentioned, the hash, the shah. And it can generate a git describe string. So that's typically the tag, but it can also include additional information if you're not exactly on a tag, it'll add some extra info.

It's really nice, you just stick that in there and you get this source file that you can then use. It's a bit like in the old days, which doesn't work with git anymore, but in older version control systems, you could place special tags in your source code that would be replaced by the version control system whenever you made a commit. CVS, if people old enough to know CVS will know the little dollar. I think it was $CVS$ that you put in your source code and it replaced that under the hood.

So yeah, that's Versionator by Sam Dean. - Fantastic. My next package is Game Controller Kit by Wesley de Groot.

And this is predictably a package that allows you to easily interface with game controllers on lots of platforms, iOS, macOS, VisionOS, tvOS. No support yet for watchOS, which I'm terribly disappointed about because I desperately want to. Actually, how would you hold the controller and look at your watch? Maybe that's why it doesn't support watchOS. (laughs) - You got there eventually. - But... (laughs) It was only as I actually looked at my watch and realized the difficulty that would cause.

So we'll forgive the lack of support for watchOS. But yes, what it is, is it's a package that really gives a nice, convenient programming interface to a game controller. Both the detection of button events and joystick events, but also control of the haptics. So most, if not all game controllers have pretty sophisticated haptics these days and you get control of... I actually can't see at what level you get control of the haptics, but it does say that you get control of the haptics.

So that may just be as simple as, you know, give it a vibrate, or it may be something a little more subtle like we have on the iPhone. But yeah, I thought this was just a very, really super simple way to get access to an input device that you may not be thinking about at the moment.

Comes with a demo app that for the iPhone or for the Mac, or there's also a tvOS screenshot here, which I guess is a great platform for game controllers where it has every input and button mapped out onto the screen, including things like the touchpad. So I think it's the PlayStation controller has a touchpad. All the trigger buttons, all the left, right, up, downs, the X, Y, A, Bs, and of course the two joysticks as well. So it seems like a great and comprehensive library to get access to that.

Should we add game controller support to SwiftPackage Index? Is that something that people are crying out for? - That's a tough sell, but who knows? Maybe open a discussion first. - That's a very polite way of saying no. - That's a standard way of dealing with feature requests. - Yes, please put it in a discussion. So yes, that's a game controller kit by Wesley de Groot. - Nice. Right, my second pick,

I was going to snipe you in iOS Dev Weekly, but then because we pushed it back by a week, you actually sniped me. And the package is called Swift Export by Frank Lefebvre. And it's a package, it's a command line tool to make it easier to sign and authorize executables on macOS. And that sounds like a great tool to help with this. So it's been a while that I actually redeployed my app or our SPI app.

And what I normally do, I've sort of written down the steps that I go through in Xcode, you know, like clicking through dialogues. But I always love having something that I can make file or a script that I can run that sort of encodes the steps in like actual code that I can check in because I can never, like a few months later, I don't remember how to release things. And I would absolutely use this and change this and use this to notarize an executable because I could then put it in a script.

So this is really nice way of automating that and dealing with this sort of, yeah, taking out the dialogue based distribution. Yeah, so that's Swift Export by Frank Lefebvre. - I believe, so I did link to that in our Dev Weekly. And I believe it also has some extra features like it can automate the generation of a package-based installer.

So a .pkg file, which if you, yeah, if you need to do additional things like, you know, move files into places that are not just in the applications directory, for example, you can again automate and create a configuration file to perform those steps as part of the installer. And it will then generate that package installer as well. I think as long as I didn't get it mixed up, but I believe that's the case. - That's great, I didn't even notice that. That's fantastic.

- Well, I think probably because we're not going to need that with the SPI app, because that is just a pure, simple copy into the applications directory and you're done. But yeah, it reminds me of the old, and this is going back a long time now, the old install shield. Did you ever have to use install shield on Windows? - Oh God, yeah, yeah. I mean, it's still, they still run installers, right? - It is, yeah, yeah. It does still exist.

And I believe it still makes package, installer packages for Mac OS, I believe. But it's certainly, it's a bit of a, I think it's a bit of an old technology now of that whole, well, let's build our installer. But certainly this would be a simpler way of doing that than some software like that, I'm sure. Maybe I'm being terribly unfair to install shield, but I somehow doubt it. - Nice. - My final package this week is a little bit of a fun one.

I like to occasionally include a fun package in the recommendations here, and it's called Chip8i Emulation Core by Danijel Stracenski. And I also hadn't heard of the Chip8 system, which is, again, an old, it's an old microprocessor originally used on the Cosmac VIP and Telmac 1800 that were 18, eight-bit microcomputers in the, from the '70s. And what it is, is it's a swift emulation of the, that whole processor. So what you get as an API from Swift is a way to load ROM files in.

So you don't get to code in the basic or whatever the language of the thing had. It just enables you to load the ROM files in. And then you get to call this emulation function, and it has 16 input keys, which, again, so it didn't even have a full keyboard. It had one, zero to nine numbers, and A to F, so it could input hex, I guess, is effectively what it could do. And then you get to hook into various key presses. So you can say on key down or on key up on any of the keys.

You can observe the output. You also get a 64 by 32 grid of Boolean values, which represent the pixel states on the screen. So it was a very high resolution display, which you could then represent in SwiftUI or whatever technology you would like to represent those pixels as. In fact, there is an example in the readme file, which is a Mac OS SwiftUI app that generates CG images and lays them out on a SwiftUI display based on this 64 by 32 bit grid of Booleans.

So it's kind of interesting that something like this would end up emulated in Swift, but I thought it was an interesting thing to have a quick look at. - That's amazing. Actually, if you think about it, as you were talking, I was looking at my watch and I thought, well, this is a tiny piece of a complication on my watch. (laughs) - Exactly. Yeah, I mean, 64 by 32 is really low resolution. It's like super low resolution. - Yeah, but it's not that far off where we started.

But my first computer was the Commodore 64, and I think that was 320 by something or 480 by 320, something like that. It wasn't that much more. I mean, a little bit more, but- - No, not that much more, yeah. - Not way more. So yeah, really fun. - So you could take a little trip down. It's probably not exactly a trip down memory lane because I'm not confident that many people will have used this system listening to this podcast, but it's always fun to look at a bit of the history of computing.

- Yeah, absolutely. Right, my third and final pick is called Spectricate

by Patrik Svensson. And can I just say, great last name, Patrick. (laughs) The package is a library to help you create beautiful terminal applications. I think that's a quote I lifted from the package. And just look at it. If you open that up and look at the screenshot that Patrick has placed there of a table, a panel and a table created with it, it's just fantastic. We had a couple of packages to create terminal applications in the past, I believe. And I always pick them.

So if you want to get mentioned, I think that's a package you sort of need to create. But it's just beautiful. I think the UI is Swift UI like, but even if it isn't, just look at the result. You'll implement this with any API, I think, to get results like this. I recall having written a little tool that deals with our ProSquare database in the past. And I was looking around for packages that output nice table views, like tables in the terminal.

And I'm very sure that that hadn't existed at the time because I would have certainly picked it. But it kind of makes me want to go back and substitute that one in now. - Yeah, I just had a look at it and it looks great. It's really, I quite like the kind of curved edge boxes as well as the straight edge boxes. Is that using, they're not characters. Are they being drawn or are they characters? - Yeah, those are, so all these use Unicode glyphs to generate the tables.

So this would be fully selectable and pasteable. I mean, obviously you'd have, you wouldn't get just the text, you'd get the text and the Unicode stuff. So it'll, formatting might change if you have a non, you know, a font that doesn't support all the glyphs or if you paste this into a proportional font thing, then it would be messed up. But no, it is proper text. - I'm very familiar with the single and the double boxes from back in the old DOS days.

But I haven't yet seen the boxes with curved corners before. So that's news to me. There are still characters in the Unicode character set that I'm unfamiliar with. - Yeah, it's beautiful, isn't it? - That's, it is, yeah, it's great. It takes me back to the days of Ball and IDEs where they used the double box characters to great effect to create all their windows and UIs. Very fond memories of that. There we go. So that brings us to the end of another episode.

And if you are at the Server-Side Swift conference, please do try and find Sven and say hello. And if not, then we'll see you back here in a few weeks time. - Yep, see you in a few weeks. Bye-bye. - All right, bye-bye.