1 00:00:00,000 --> 00:00:05,900 Well, I think we do have a bit of news. We spoke about maybe not having that much, 2 00:00:05,900 --> 00:00:12,100 but there was a package that landed last week, I think. 3 00:00:12,100 --> 00:00:15,400 Yes, you wrote about it in IOS Dev Weekly as well. 4 00:00:15,400 --> 00:00:21,400 And that is Swift Win 32 by Salim Abdul Rasool. 5 00:00:21,400 --> 00:00:25,400 Yeah, I thought I'd maybe pull this forward into the news section, 6 00:00:25,400 --> 00:00:28,400 not just as a package towards the end. 7 00:00:28,400 --> 00:00:30,280 I think that's a great idea to talk about that. 8 00:00:30,280 --> 00:00:33,760 Yeah, I got good feedback on that opening comment, 9 00:00:33,760 --> 00:00:35,440 actually, this week, so yeah. 10 00:00:35,440 --> 00:00:36,920 Yeah, I really like that. 11 00:00:36,920 --> 00:00:39,120 And just to mention Salim Abdullah, 12 00:00:39,120 --> 00:00:41,760 who is also known as CompNerd. 13 00:00:41,760 --> 00:00:46,760 That's actually what I map his persona to 14 00:00:46,760 --> 00:00:48,240 on the Swift forums and everywhere. 15 00:00:48,240 --> 00:00:52,880 So he's the, I think, the maintainer of Swift on Windows 16 00:00:52,880 --> 00:00:57,880 and also the person who brought that into existence, 17 00:00:58,280 --> 00:00:59,280 I believe. 18 00:00:59,280 --> 00:01:00,280 Yeah. 19 00:01:00,280 --> 00:01:06,840 And so he submitted, or someone submitted, I'm not sure what the order of events was, 20 00:01:06,840 --> 00:01:15,160 but we have it in the index now, Swift Win 32, a Windows application framework in Swift. 21 00:01:15,160 --> 00:01:23,560 Unsurprisingly the compatibility matrix is all crosses because we only test on macOS, 22 00:01:23,560 --> 00:01:28,560 Mac OS, iOS and so on, the Apple platforms and Linux. 23 00:01:28,560 --> 00:01:30,800 So that's not a big surprise, 24 00:01:30,800 --> 00:01:35,460 but that sort of brings or mounts the pressure a bit 25 00:01:35,460 --> 00:01:39,860 what our strategy is with respect to the next platform, 26 00:01:39,860 --> 00:01:40,700 I suppose. 27 00:01:40,700 --> 00:01:44,800 I mean, Windows has always been one of the leading candidates 28 00:01:44,800 --> 00:01:47,440 and we've obviously talked about this before 29 00:01:47,440 --> 00:01:48,880 and tossed around the ideas, 30 00:01:50,240 --> 00:01:58,640 the idea to add it and when will we add it, how will we add it actually, because I've been thinking about this a bit 31 00:01:58,640 --> 00:02:05,120 and it's a bit of a departure because with Mac OS and Linux 32 00:02:05,120 --> 00:02:14,400 we have the option to run this pretty much ourselves, I mean just speaking for myself, I have no 33 00:02:14,400 --> 00:02:21,520 real access to a Windows machine where we could even experiment with building Swift packages on it. 34 00:02:21,520 --> 00:02:28,720 So it'd have to be either cloud-based or I'd have to get a Windows laptop or some kind of Windows machine. 35 00:02:28,720 --> 00:02:32,720 So that's sort of been an impediment to experimenting further with this. 36 00:02:32,720 --> 00:02:42,400 And in that same vein, there's another package that I saw just last week that mentioned one of the platforms that we're not supporting yet, 37 00:02:42,400 --> 00:02:46,560 that is WOSM. So there's an explicit mention, I believe it was a point free 38 00:02:46,560 --> 00:02:52,240 core package. And there it was just mentioned as an additional platform that 39 00:02:52,240 --> 00:02:56,320 they support. So which is different because the Win32 platform is actually 40 00:02:56,320 --> 00:03:02,320 one that is Windows only, right? So this is a package that is specifically for 41 00:03:02,320 --> 00:03:06,880 Windows. I'm sure we have other packages that will be compatible with Windows 42 00:03:06,880 --> 00:03:11,440 once we start testing. But you know, that's just because they happen to also 43 00:03:11,440 --> 00:03:14,720 work on Windows while this one certainly requires Windows. 44 00:03:14,720 --> 00:03:19,480 I think it's a great idea and we've talked about it several times but I think 45 00:03:19,480 --> 00:03:26,560 I think the time is is arriving for us to think seriously about adding Windows 46 00:03:26,560 --> 00:03:31,600 compatibility and you mentioned the Win32 package I think it was actually me 47 00:03:31,600 --> 00:03:36,520 that added that package on Thursday or Friday last week because I was I was 48 00:03:36,520 --> 00:03:41,200 doing a bit of research for that article I wrote on iOS Dev Weekly and ended up 49 00:03:41,200 --> 00:03:47,240 poking around in Selim's GitHub list, repository list, and I found that one. 50 00:03:47,240 --> 00:03:52,400 I think the WinRT one had already been added, but the Win32 one hadn't, or I may 51 00:03:52,400 --> 00:03:53,520 have got those the wrong way around. 52 00:03:53,520 --> 00:03:55,280 We had one, but we didn't have the other. 53 00:03:55,280 --> 00:04:01,280 But it's great to see that kind of work happening. 54 00:04:01,280 --> 00:04:08,000 And I think Selim deserves all the credit in the world for not only doing the work 55 00:04:08,280 --> 00:04:18,480 that he's done to bring SWIFT to windows, but also for having the momentum and the force 56 00:04:18,480 --> 00:04:23,720 of will to get it done, because it was probably not the—well, it was certainly not the easiest 57 00:04:23,720 --> 00:04:31,000 task in the world, I'm sure, but it was also probably not the most obvious thing to do 58 00:04:31,000 --> 00:04:33,680 as an independent person outside of the SWIFT project. 59 00:04:33,680 --> 00:04:35,800 So I think he deserves a huge amount of credit for that. 60 00:04:35,800 --> 00:04:38,700 Yeah, and he's been doing this for a long, long time, right? 61 00:04:38,700 --> 00:04:42,700 I mean, I don't even remember when he started adding Windows support. 62 00:04:42,700 --> 00:04:46,300 And initially, I believe it wasn't even in Swift itself. 63 00:04:46,300 --> 00:04:53,300 So there was a lot of absorbing upstream changes into his branch or fork of it, I believe. 64 00:04:53,300 --> 00:04:56,300 But I think that a lot of that has changed in the meantime. 65 00:04:56,300 --> 00:05:00,400 So yeah, there's a little for people watching what's going on. 66 00:05:00,400 --> 00:05:05,500 If you want a spoiler for iOS Dev Weekly, check out what stuff gets added to the package index on Thursdays, 67 00:05:05,500 --> 00:05:09,660 because that's when Dave spoils his newsletter. 68 00:05:09,660 --> 00:05:16,220 Pretty much. It's quite a common thing that I'll find something on a Thursday 69 00:05:16,220 --> 00:05:17,660 that I want to add to the index. 70 00:05:17,660 --> 00:05:26,460 Yeah, so I was thinking a bit about our next platform and May is probably not a great time 71 00:05:26,460 --> 00:05:31,180 to actually add a new platform because, you know, in June there might be something new happening. 72 00:05:31,180 --> 00:05:39,280 so we always have to be careful what we take on because adding a new platform isn't just a one-off thing, 73 00:05:39,280 --> 00:05:44,960 it then becomes an ongoing concern, you know, like maintenance. 74 00:05:44,960 --> 00:05:49,660 In particular a platform like Windows, which we'd have to, well that's something to discuss, 75 00:05:49,660 --> 00:05:52,460 but likely something that we'd have to maintain, right? 76 00:05:52,460 --> 00:05:54,400 We'd have to maintain Windows machines. 77 00:05:54,400 --> 00:06:00,940 Perhaps there's an alternative way to actually do it, which I want to maybe briefly talk about. 78 00:06:00,940 --> 00:06:11,540 and that's one I have high hopes for because it would solve a lot of the effort that we would have to bring and put in otherwise. 79 00:06:11,540 --> 00:06:15,540 And that's Swift's cross-compilation support. 80 00:06:15,540 --> 00:06:21,340 There's an evolution proposal out by Max Desiatov right now. 81 00:06:21,340 --> 00:06:29,340 Well, actually, I think it might have been approved by now, and that's about cross-compilation destinations. 82 00:06:29,340 --> 00:06:37,140 I think that's just the first step in a range of proposals to be coming to give Swift the capability, 83 00:06:37,140 --> 00:06:40,980 you know, across compilation capabilities. 84 00:06:40,980 --> 00:06:50,460 And having that would save us a lot of trouble because maintaining Windows machines for the Windows testing, 85 00:06:50,460 --> 00:06:57,820 I mean, it's possible, but then we'd have yet a third, yet another, you know, platform in the mix that we'd need to maintain, update, 86 00:06:57,820 --> 00:07:01,260 and also set up the build environment for. 87 00:07:01,260 --> 00:07:06,260 Whereas if we could rely on cross compilation, 88 00:07:06,260 --> 00:07:08,020 that would be really great because 89 00:07:08,020 --> 00:07:12,260 we'd probably still want to choose either Mac OS and Linux 90 00:07:12,260 --> 00:07:14,540 as a single one that does everything then, 91 00:07:14,540 --> 00:07:17,100 but we'd at least have that choice 92 00:07:17,100 --> 00:07:20,780 to run the compiles on a single platform. 93 00:07:20,780 --> 00:07:23,020 All the runners being the same 94 00:07:23,020 --> 00:07:26,700 would give us a lot of advantages. 95 00:07:26,700 --> 00:07:31,740 you know, we just we have an easier time managing our capacity because it's all the same. 96 00:07:31,740 --> 00:07:34,820 We could just add machines and every machine can build everything. 97 00:07:34,820 --> 00:07:36,260 That's that's really nice. 98 00:07:36,260 --> 00:07:38,820 So that would be great. 99 00:07:38,820 --> 00:07:47,500 But I just I don't have a sense for how far off that is and in particular how how long it'll take for that to be 100 00:07:47,500 --> 00:07:52,340 something we could truly rely on. 101 00:07:52,340 --> 00:07:55,620 I mean, we do effectively do cross compilation already, right? 102 00:07:55,620 --> 00:07:59,940 Because we're using Macs to compile iOS, tvOS, watchOS. 103 00:07:59,940 --> 00:08:02,220 So it's nothing new. 104 00:08:02,220 --> 00:08:08,380 But that doesn't automatically mean it'll be perfect for Linux 105 00:08:08,380 --> 00:08:12,940 and all the other platforms that are less common as those Apple platforms. 106 00:08:12,940 --> 00:08:16,620 The other big question I have with this is, 107 00:08:16,620 --> 00:08:21,940 how will it cope with things like, so for example, that Win32 package, 108 00:08:22,220 --> 00:08:25,500 has presumably bindings into the Windows APIs. 109 00:08:25,500 --> 00:08:26,500 Yes. 110 00:08:26,500 --> 00:08:30,300 And how does it, if it can, can it even cope with something like that? 111 00:08:30,300 --> 00:08:35,900 I would, I think that's a question we'll need to answer fairly early because, and again, 112 00:08:35,900 --> 00:08:39,860 we'd have the same questions with the Mac side of things, right? 113 00:08:39,860 --> 00:08:40,860 Yes. 114 00:08:40,860 --> 00:08:44,780 So I think there are some questions that need answering there. 115 00:08:44,780 --> 00:08:49,260 There is actually another option on how we could approach this, which is again, something 116 00:08:49,260 --> 00:08:56,540 that came from an article I linked to in IOS Dev Weekly this week, which was, it was a 117 00:08:56,540 --> 00:09:04,380 post on continuous integration at Airbnb from Michael Backhand and Xiaomeng Chen. 118 00:09:04,380 --> 00:09:07,260 And they were talking about, I don't know whether you spotted the article, but they 119 00:09:07,260 --> 00:09:13,780 were talking about an enormous kind of redesign of their continuous integration environment 120 00:09:13,780 --> 00:09:23,460 at Airbnb and switching it from, they had 300 CI machines, which is an enormous amount. 121 00:09:23,460 --> 00:09:24,460 I can't even imagine. 122 00:09:24,460 --> 00:09:28,780 They were talking about the problems of applying updates and making sure they were in a stable 123 00:09:28,780 --> 00:09:32,620 situation, logging onto one and rebooting it and that kind of thing. 124 00:09:32,620 --> 00:09:39,620 And they switched to a AMI-based environment in Amazon. 125 00:09:39,620 --> 00:09:41,660 So they have base images. 126 00:09:41,660 --> 00:09:46,940 And then on demand, they spin up a machine from that base image, they run some CI, and 127 00:09:46,940 --> 00:09:49,020 at the end of it, they shut it down. 128 00:09:49,020 --> 00:09:57,320 I mean, it's a long article, so I'm summarizing terribly here, but roughly that's the approach 129 00:09:57,320 --> 00:09:58,820 that they took. 130 00:09:58,820 --> 00:10:05,980 And we're running in cloud environments, so we have the potential to do something similar 131 00:10:05,980 --> 00:10:09,180 if we wanted to kind of look into that side of things. 132 00:10:09,180 --> 00:10:10,180 It's certainly another option. 133 00:10:10,180 --> 00:10:16,980 Yeah, that'd be great. I mean, we talked about Tart in the past, which on macOS offers virtualization, 134 00:10:16,980 --> 00:10:22,500 you know, like where you can spin up Macs, which would help a lot. I mean, on Linux, 135 00:10:22,500 --> 00:10:27,220 we're sort of saved a bit by Docker, which effectively does that to a degree. 136 00:10:27,220 --> 00:10:28,220 It's effectively doing it. 137 00:10:28,220 --> 00:10:35,700 Yeah. And I've every year in June at WWDC, I hope for something Docker like to happen 138 00:10:35,700 --> 00:10:39,580 for macOS, but I think that'll be a forever hope. 139 00:10:39,580 --> 00:10:41,580 Maybe this year, Sven, maybe this year. 140 00:10:41,580 --> 00:10:43,580 Oh yeah, right. 141 00:10:43,580 --> 00:10:46,580 Not long to wait. Four weeks, is it? 142 00:10:46,580 --> 00:10:48,580 Three, yeah, three. It's three weeks. 143 00:10:48,580 --> 00:10:50,580 The other thing I was thinking about, 144 00:10:50,580 --> 00:10:55,580 how would we actually decide what platform to pick next? 145 00:10:55,580 --> 00:10:58,580 I mean, it's unrealistic that we do multiple at the same time. 146 00:10:58,580 --> 00:11:01,580 How would we judge just effort? 147 00:11:01,580 --> 00:11:08,580 Do we have a sense for how much demand there is for Windows over Wasm, for instance? 148 00:11:08,580 --> 00:11:16,460 I think effort has to come into it, but I don't think it should be the primary metric. 149 00:11:16,460 --> 00:11:22,220 I'd go on really gut feeling what feels like the right platform. 150 00:11:22,220 --> 00:11:28,100 And to me, I think the gut feeling is very strong, actually, that it should be Windows. 151 00:11:28,100 --> 00:11:34,540 I think WASM is certainly one that we would like to add at some point, but it feels to 152 00:11:34,540 --> 00:11:36,780 me like Windows should be first. 153 00:11:36,780 --> 00:11:41,780 Do you have a use case in mind or do you think there's a, 154 00:11:41,780 --> 00:11:42,920 can you think of a project 155 00:11:42,920 --> 00:11:46,460 that actually has Windows demand? 156 00:11:46,460 --> 00:11:48,500 - I feel like I'm gonna refer to iOS Dev Weekly 157 00:11:48,500 --> 00:11:50,300 a lot in this episode. 158 00:11:50,300 --> 00:11:52,620 - I have to admit I'm prompting you a bit there. 159 00:11:52,620 --> 00:11:55,620 (both laughing) 160 00:11:55,620 --> 00:11:57,780 - What I was actually writing about on Friday 161 00:11:57,780 --> 00:11:59,580 in the newsletter was, 162 00:11:59,580 --> 00:12:03,340 so there's a web browser which has been around on Mac 163 00:12:03,340 --> 00:12:04,700 for a little while now, 164 00:12:04,700 --> 00:12:06,660 I think maybe like a year or just over, 165 00:12:06,660 --> 00:12:08,820 something like that, called Arc. 166 00:12:08,820 --> 00:12:11,940 And currently, so it's a Chromium-based browser, 167 00:12:11,940 --> 00:12:14,300 so it uses the Chromium rendering engine 168 00:12:14,300 --> 00:12:18,540 with a Mac user interface on top of it. 169 00:12:18,540 --> 00:12:21,620 And up until, well, still up until now, 170 00:12:21,620 --> 00:12:25,980 it is Mac only in terms of where you can run it. 171 00:12:25,980 --> 00:12:30,480 But they are currently doing a Windows version 172 00:12:30,480 --> 00:12:33,700 and using Swift to build that Windows version, 173 00:12:33,700 --> 00:12:37,500 which is, I think I described it as ambitious, 174 00:12:37,500 --> 00:12:41,540 because I think it is certainly quite ambitious. 175 00:12:41,540 --> 00:12:46,280 And so, and actually that's, Salim is working for 176 00:12:46,280 --> 00:12:49,460 that company, it's called the Browser Company, 177 00:12:49,460 --> 00:12:50,860 and he works there at the moment, 178 00:12:50,860 --> 00:12:53,660 and presumably he's leading that initiative. 179 00:12:53,660 --> 00:12:55,340 And I actually had a little chat, 180 00:12:55,340 --> 00:12:57,780 I actually kind of got it wrong in the newsletter. 181 00:12:57,780 --> 00:12:59,900 I've posted an update to it this morning 182 00:12:59,900 --> 00:13:01,980 just to correction. 183 00:13:01,980 --> 00:13:08,340 I kind of concluded that they were maybe not working on some kind of cross-platform UI 184 00:13:08,340 --> 00:13:14,220 framework but actually their CTO reached out to me over the weekend and he said, "That's 185 00:13:14,220 --> 00:13:15,220 not quite right. 186 00:13:15,220 --> 00:13:21,500 What we're doing is we're doing a different UI layer for Mac and Windows but both written 187 00:13:21,500 --> 00:13:22,500 in Swift. 188 00:13:22,500 --> 00:13:24,620 So we're not trying to make a cross-platform UI. 189 00:13:24,620 --> 00:13:28,980 We're trying to make a platform-specific UI but all using Swift." 190 00:13:28,980 --> 00:13:34,340 Which of course, if you want to get perfect platform native feel on both platforms, that's 191 00:13:34,340 --> 00:13:36,300 what you have to do. 192 00:13:36,300 --> 00:13:45,300 And so I think the fact that that project is in progress is one mark in the sand for 193 00:13:45,300 --> 00:13:46,300 Windows. 194 00:13:46,300 --> 00:13:47,300 Yeah. 195 00:13:47,300 --> 00:13:53,780 So, I've come across a requirement for Wasm in one context that might be quite interesting, 196 00:13:53,780 --> 00:13:55,980 and that is cloud deployment. 197 00:13:55,980 --> 00:14:00,980 That's a, the project where this popped up was Swift Cloud. 198 00:14:00,980 --> 00:14:06,200 It was an early testing I did before we actually started 199 00:14:06,200 --> 00:14:11,200 our Doc C uploader project that is using Swift Lambda. 200 00:14:11,200 --> 00:14:15,080 I came across Swift Cloud and that's by Andrew Barber. 201 00:14:15,080 --> 00:14:18,320 And that is actually, that is Swift. 202 00:14:18,320 --> 00:14:21,400 So you actually write a Swift package that deploys 203 00:14:21,400 --> 00:14:23,160 to that cloud very, very nicely. 204 00:14:23,160 --> 00:14:26,800 the process is super smooth, much smoother 205 00:14:26,800 --> 00:14:29,940 than it is to get something deployed on AWS Lambda. 206 00:14:29,940 --> 00:14:33,840 And there the requirement is that the packages 207 00:14:33,840 --> 00:14:38,340 actually supports Wasm or runs on Wasm 208 00:14:38,340 --> 00:14:43,340 because it gets actually compiled into a Wasm, 209 00:14:43,340 --> 00:14:45,720 I guess binary, I'm not even sure 210 00:14:45,720 --> 00:14:47,280 what the artifact is that comes out of it. 211 00:14:47,280 --> 00:14:50,760 And that is then deployed into that cloud. 212 00:14:50,760 --> 00:14:57,320 So in that context, I can see demand for WASM actually as a compatibility test. 213 00:14:57,320 --> 00:15:00,320 That would be quite useful and interesting. 214 00:15:00,320 --> 00:15:10,120 I suppose in terms of effort, I could imagine that WASM is probably quite a bit easier to get tested for, 215 00:15:10,120 --> 00:15:15,320 because we would effectively be using, I guess, the Mac or Linux, 216 00:15:15,320 --> 00:15:19,320 because I think all you need is a Swift compiler version. 217 00:15:19,320 --> 00:15:22,680 And that needs, I think, to be a certain compiler version 218 00:15:22,680 --> 00:15:24,360 that needs to be ready for Woz and Mitz, 219 00:15:24,360 --> 00:15:26,160 not upstreamed everything. 220 00:15:26,160 --> 00:15:29,800 But I think at least on the platform side, 221 00:15:29,800 --> 00:15:32,440 that would be different from Windows 222 00:15:32,440 --> 00:15:34,960 and less complex, I suppose. 223 00:15:34,960 --> 00:15:37,360 - Yeah, I mean, it's kind of exciting 224 00:15:37,360 --> 00:15:40,680 to have two more platforms 225 00:15:40,680 --> 00:15:43,760 that we could potentially add to our compatibility testing. 226 00:15:43,760 --> 00:15:46,080 That in itself is remarkable. 227 00:15:46,080 --> 00:15:47,440 - Yes, and beginning of June, 228 00:15:47,440 --> 00:15:49,280 there might be yet another one, who knows. 229 00:15:49,280 --> 00:15:57,960 So I'm going to combine my first package recommendation this week with a quiz. 230 00:15:57,960 --> 00:16:03,560 It was going to be a package recommendation because it popped up in the RSS feed of 231 00:16:03,560 --> 00:16:05,880 new major versions this week. 232 00:16:05,880 --> 00:16:12,640 But it is a package that I also then, or it's a tool that I also then ran on our 233 00:16:12,640 --> 00:16:18,040 code base and we can do a little quiz on the results of it. 234 00:16:18,040 --> 00:16:21,440 Oh, is that Paul Hudson's tool? 235 00:16:21,440 --> 00:16:23,000 It is Paul Hudson's tool. 236 00:16:23,000 --> 00:16:27,720 Oh, I haven't actually run it, so I'm unspoiled. 237 00:16:27,720 --> 00:16:30,080 I'm curious what the results are. 238 00:16:30,080 --> 00:16:31,200 That's good. 239 00:16:31,200 --> 00:16:39,080 So the tool is called SitRep, and it is a tool that will take a look at your Swift code 240 00:16:39,080 --> 00:16:42,300 base and give you statistics on it. 241 00:16:42,300 --> 00:16:50,940 So I ran the tool today because it just, the version three release gained support for Swift 242 00:16:50,940 --> 00:16:56,340 5.8, so it's right up to date with the current Swift version. 243 00:16:56,340 --> 00:17:02,460 And I ran the tool today and discovered various different stats on our code base. 244 00:17:02,460 --> 00:17:07,780 So let's start with a question about purely lines of code. 245 00:17:07,780 --> 00:17:12,580 How many lines of Swift code do you think we have in the Swift package index? 246 00:17:12,580 --> 00:17:20,580 Ooh, I ran a tool a few months back, and so I think I might have a sense of this, and 247 00:17:20,580 --> 00:17:23,180 I think it was 30k. 248 00:17:23,180 --> 00:17:25,180 Okay. 249 00:17:25,180 --> 00:17:26,780 You are underestimating. 250 00:17:26,780 --> 00:17:31,700 If in total lines of code, which I presume includes comments and all the rest of it, 251 00:17:31,700 --> 00:17:33,980 we have 46,000. 252 00:17:33,980 --> 00:17:36,840 And in source code, we have 40,000. 253 00:17:36,840 --> 00:17:42,040 So there are 6,000 wasted lines of code in our code base. 254 00:17:42,040 --> 00:17:45,160 Or maybe more, depending on how you look at it. 255 00:17:45,160 --> 00:17:47,560 But not far off, I guess, the correct ballpark. 256 00:17:47,560 --> 00:17:52,320 Well, I ran this three months ago, and we obviously wrote 10,000, 14,000 lines since 257 00:17:52,320 --> 00:17:53,320 then. 258 00:17:53,320 --> 00:17:57,760 So clearly, that's definitely what we did. 259 00:17:57,760 --> 00:18:07,200 How about structs, classes, and enums? Of those three different types, which of those 260 00:18:07,200 --> 00:18:10,560 do we have most of between just structs, classes, and enums? 261 00:18:10,560 --> 00:18:13,760 Oh, I think the order is structs, enum, classes. 262 00:18:13,760 --> 00:18:17,760 Interesting. Not quite correct, but you were correct with structs. So we have the most 263 00:18:17,760 --> 00:18:23,440 number of structs, but then we have classes behind that. 264 00:18:23,440 --> 00:18:24,440 No! 265 00:18:24,440 --> 00:18:27,480 And enums trailing behind. 266 00:18:27,480 --> 00:18:28,480 Yeah. 267 00:18:28,480 --> 00:18:38,920 So we have 149 tests, sorry, 149 structs, 111 classes, and 58 enums. 268 00:18:38,920 --> 00:18:41,080 All the vapor models are classes. 269 00:18:41,080 --> 00:18:45,720 Yes, because I was thinking only the views where we actually have classes, 270 00:18:45,720 --> 00:18:47,880 but all the vapor models are actually classes. 271 00:18:47,880 --> 00:18:48,880 Yeah. 272 00:18:48,880 --> 00:18:50,880 How many protocols do you think we have? 273 00:18:50,880 --> 00:18:53,720 Not a whole lot, I think. 274 00:18:53,720 --> 00:18:57,160 Give me how many classes did we have in the end or enums? 275 00:18:57,160 --> 00:18:59,880 We had 111 classes in total. 276 00:18:59,880 --> 00:19:03,160 Oh, wow. That many. Well, I don't know, like 40? 277 00:19:03,160 --> 00:19:07,160 We have eight protocols, which is way less than I would have thought. 278 00:19:07,160 --> 00:19:08,600 [laughter] 279 00:19:08,600 --> 00:19:11,720 We're obviously not particularly keen on the old protocols. 280 00:19:11,720 --> 00:19:15,640 And finally, one last question on types. 281 00:19:15,640 --> 00:19:17,640 How many extensions do we have? 282 00:19:17,640 --> 00:19:19,880 Oh, we have loads of extensions. 283 00:19:19,880 --> 00:19:22,120 We have lots of extensions. You're great. 284 00:19:22,120 --> 00:19:29,120 So I can give you a clue on this. We have more extensions than all of the other types put together. 285 00:19:29,120 --> 00:19:32,320 Well, that's not... So I was going to ask how is that actually counted? 286 00:19:32,320 --> 00:19:40,520 Because what I often do is I open an extension and then, you know, grouping a few things together 287 00:19:40,520 --> 00:19:47,520 and then I open in the same file another extension on the same type, grouping yet another set of things together. 288 00:19:47,520 --> 00:19:50,720 So is that two extensions? 289 00:19:50,720 --> 00:19:53,400 I don't know how it works, but I would assume, 290 00:19:53,400 --> 00:19:56,400 I would assume, given that this number is quite high, 291 00:19:56,400 --> 00:19:59,200 I would assume that it is every time you make an extension. 292 00:19:59,200 --> 00:20:00,200 - Right. - It counts that. 293 00:20:00,200 --> 00:20:02,000 I'm going to say 200. 294 00:20:02,000 --> 00:20:04,400 We have 354 extensions. 295 00:20:04,400 --> 00:20:07,080 [laughter] 296 00:20:07,080 --> 00:20:09,880 Okay, final-- well, not actually final question, 297 00:20:09,880 --> 00:20:12,920 but you'll see what I mean. 298 00:20:12,920 --> 00:20:15,640 What's our longest file? 299 00:20:15,640 --> 00:20:17,440 Oh. 300 00:20:17,440 --> 00:20:25,940 It's the same file, both in just pure number of lines in the file and actual longest amount of source lines in a type. 301 00:20:25,940 --> 00:20:27,940 I think it's going to be a test. 302 00:20:27,940 --> 00:20:32,240 And I'm going to say it's analysis tests. 303 00:20:32,240 --> 00:20:38,440 Not quite. I think you'll actually be pleased to hear what the file is. It is a test. 304 00:20:38,440 --> 00:20:45,240 And given that the package index is a search engine, it is actually our search tests that is the... 305 00:20:45,240 --> 00:20:50,400 Oh, of course, because all the SQL is expanded and tested. 306 00:20:50,400 --> 00:20:52,400 Right, yeah, yeah, yeah. 307 00:20:52,400 --> 00:20:54,400 I remember in school that's a test. 308 00:20:54,400 --> 00:20:56,400 Because those are massive. 309 00:20:56,400 --> 00:20:58,400 And it comes in at almost 1300 lines of code, yeah. 310 00:20:58,400 --> 00:21:00,400 Oh, wow. 311 00:21:00,400 --> 00:21:02,400 So actually at that point what I did 312 00:21:02,400 --> 00:21:06,400 was I deleted our tests directory and ran it again. 313 00:21:06,400 --> 00:21:08,400 Oh, no. 314 00:21:08,400 --> 00:21:10,400 Because I thought, well, what's the largest class? 315 00:21:10,400 --> 00:21:14,400 Or, I think it's not actually a class, 316 00:21:14,400 --> 00:21:18,000 But what's the largest type without the tests? 317 00:21:18,000 --> 00:21:19,200 So what's your guess on that? 318 00:21:19,200 --> 00:21:22,000 Oh, like type or file? 319 00:21:22,000 --> 00:21:24,200 It's actually both. They're both the same. 320 00:21:24,200 --> 00:21:26,400 Both the file and the type are the largest. 321 00:21:26,400 --> 00:21:29,400 I'd say again analysis, although that's not a type, 322 00:21:29,400 --> 00:21:33,600 that's just the file. So that can't actually be search? 323 00:21:33,600 --> 00:21:36,400 You should have gone with your gut feeling. 324 00:21:36,400 --> 00:21:40,400 The type is analyze and it's in analyze.swift. 325 00:21:40,400 --> 00:21:42,400 So analyze, just to give a bit of background, 326 00:21:42,400 --> 00:21:52,700 is the process that looks at all of the metadata from a local checkout of the Git repository for a package. 327 00:21:52,700 --> 00:21:58,200 So we check out the Git repository and then we run this analysis process on it, which looks at commit history. 328 00:21:58,200 --> 00:22:07,700 It analyzes the package.swift, it ingests all the metadata out of that package.swift file and a whole load of Git metadata as well. 329 00:22:07,700 --> 00:22:12,700 But actually, given that it is such a large process, 330 00:22:12,700 --> 00:22:16,840 the number of source lines is not that bad. 331 00:22:16,840 --> 00:22:19,260 It's 623 lines, which I think, 332 00:22:19,260 --> 00:22:20,860 given that's our very largest file, 333 00:22:20,860 --> 00:22:23,220 I think that's kind of okay, actually. 334 00:22:23,220 --> 00:22:25,740 - Yeah, I just remember I had started moving, 335 00:22:25,740 --> 00:22:27,780 I think that has now a top-level enum 336 00:22:27,780 --> 00:22:30,340 that sort of has a namespace analyze. 337 00:22:30,340 --> 00:22:33,100 And one of the reasons I wanted to do that, 338 00:22:33,100 --> 00:22:36,860 because then it's a bit nicer to break it up into segments 339 00:22:36,860 --> 00:22:40,420 and name them properly because they're named by the type. 340 00:22:40,420 --> 00:22:42,400 - I do have one final question. 341 00:22:42,400 --> 00:22:47,220 So once I ran the tool again without the tests folder, 342 00:22:47,220 --> 00:22:51,180 I was able to see how much of our code is in code 343 00:22:51,180 --> 00:22:53,460 and how much of our code is in tests. 344 00:22:53,460 --> 00:22:55,540 And I won't ask you for numbers here, 345 00:22:55,540 --> 00:22:59,780 but as a percentage, how much is code and how much is tests? 346 00:22:59,780 --> 00:23:05,620 - I think the tests are more lines of code, 347 00:23:05,620 --> 00:23:08,860 maybe 50% more, no 30% more. 348 00:23:08,860 --> 00:23:11,740 - Actually remarkably close. 349 00:23:11,740 --> 00:23:15,940 We have more code than we do tests, but only just. 350 00:23:15,940 --> 00:23:19,340 We have, we're 55% code, 45% tests. 351 00:23:19,340 --> 00:23:20,700 - Oh wow. 352 00:23:20,700 --> 00:23:23,000 I thought that was more the other way around, interesting. 353 00:23:23,000 --> 00:23:25,380 - Which again, I think is actually fine. 354 00:23:25,380 --> 00:23:29,620 I think that's a healthy balance of code 355 00:23:29,620 --> 00:23:31,540 to tests within a project. 356 00:23:31,540 --> 00:23:33,460 - I think in terms of time spent, 357 00:23:33,460 --> 00:23:38,740 I spend with, that's probably why I'm overestimating it so much because I only stay at the tests. 358 00:23:38,740 --> 00:23:50,020 So yes, that's both my first package recommendation for this week and also a little quiz for you, 359 00:23:50,020 --> 00:23:54,900 Fenn, and for everyone to hopefully get a bit of insight into what our project looks like. 360 00:23:54,900 --> 00:24:01,540 And I would recommend, it's very easy to install. It's actually, you can install it trivially with 361 00:24:01,540 --> 00:24:08,340 homebrew, you can just have brew install and then there's a path you can install and it installed in 362 00:24:08,340 --> 00:24:14,580 five minutes. And then running it is just as simple as typing sitrep in your source code 363 00:24:14,580 --> 00:24:20,660 directory. The only other thing that I'd mention here is I had to clean up our source directory a 364 00:24:20,660 --> 00:24:28,180 little bit before I ran it. So I had to remove the .build directory because it was looking and 365 00:24:28,180 --> 00:24:33,620 finding Swift files inside there for all of our dependencies as well. 366 00:24:33,620 --> 00:24:39,460 So I just completely removed that folder and then ran it on just our source code files. 367 00:24:39,460 --> 00:24:44,660 So just be aware that it may give you, if you use Swift build from the command line, 368 00:24:44,660 --> 00:24:47,860 you may have a huge .build directory which it's looking at as well. 369 00:24:47,860 --> 00:24:50,740 Really nice. That was a nice quiz. 370 00:24:50,740 --> 00:24:53,060 Do you want to do your first package? 371 00:24:53,060 --> 00:24:54,820 Let's do the other packages. 372 00:24:55,380 --> 00:25:02,500 So the first one I wanted to talk about is called "Gonzales" by Andreas Wendleder. 373 00:25:02,500 --> 00:25:06,420 Gonzolo also on GitHub. 374 00:25:06,420 --> 00:25:12,580 This is an interesting package because it's a package you're almost certainly not going to use. 375 00:25:12,580 --> 00:25:14,900 [laughs] 376 00:25:14,900 --> 00:25:19,460 I noticed this this week because there was a new release, 377 00:25:19,460 --> 00:25:24,100 but then I actually went back to look into it in more detail 378 00:25:24,100 --> 00:25:30,580 and found out that it was introduced in January 21 in a blog post and on the Swift forums. 379 00:25:30,580 --> 00:25:39,540 And this is a package that is the TLDR is "Render Disney's Moana scene in less than 10,000 lines of 380 00:25:39,540 --> 00:25:48,340 Swift code". And the thing about the package is it claims to be one of the only renderers 381 00:25:49,060 --> 00:25:55,460 of that scene, which is an elaborate 3D rendering scene from a Disney film. 382 00:25:55,460 --> 00:26:03,300 One of the only packages or things that does that, that isn't written in C++ or C. 383 00:26:03,300 --> 00:26:09,540 Okay, I'm going to need a bit of context here. So obviously I'm familiar with the film Moana, 384 00:26:09,540 --> 00:26:15,060 but what does it mean by render? Like, does it have the models? And does it have that kind of stuff? 385 00:26:15,060 --> 00:26:28,460 Yes. So we'll add a link to the show notes. You can actually download the assets for the Moana Island scene from Disneyanimation.com. 386 00:26:28,460 --> 00:26:29,060 Wow. 387 00:26:29,060 --> 00:26:37,260 And this is really interesting. So the base download is 45 gigabytes, 93 gigabytes unpacked. That's just the base scene. 388 00:26:37,260 --> 00:26:41,220 And there's 24 gigabytes of compressed animation data, 389 00:26:41,220 --> 00:26:44,060 15 gigabytes of USD, 390 00:26:44,060 --> 00:26:45,500 USD version of our data, 391 00:26:45,500 --> 00:26:47,400 along with that might be, 392 00:26:47,400 --> 00:26:48,940 I'm not sure what that is exactly, 393 00:26:48,940 --> 00:26:50,440 but we're talking about-- 394 00:26:50,440 --> 00:26:51,940 - USD is-- 395 00:26:51,940 --> 00:26:53,640 - That's a 3D format, yeah. 396 00:26:53,640 --> 00:26:55,740 - Yeah, that's model data because-- 397 00:26:55,740 --> 00:26:58,840 - But I'm not sure if that's just part of the base, 398 00:26:58,840 --> 00:27:00,940 if that's in addition or if that's actually required. 399 00:27:00,940 --> 00:27:03,440 But you're certainly looking at tens of gigabytes 400 00:27:03,440 --> 00:27:06,280 of input data to render this scene. 401 00:27:06,280 --> 00:27:12,760 So this is stuff that gets ingested by this package or other packages that render that scene. 402 00:27:12,760 --> 00:27:18,520 That's the underlying data that it uses to then generate a scene. 403 00:27:18,520 --> 00:27:23,400 So what this person, what Andreas has done, has written a Swift package, 404 00:27:23,400 --> 00:27:30,200 and he says, "I wrote it in VI and command line Swift on Ubuntu, Linux and Xcode on Mac OS." 405 00:27:30,200 --> 00:27:33,840 So I mean that first part, "I wrote it in VI and command line Swift." 406 00:27:33,840 --> 00:27:36,340 I thought, wow, okay. 407 00:27:36,340 --> 00:27:38,040 But apparently he's also used Xcode, 408 00:27:38,040 --> 00:27:41,580 and I think he's used that mainly to do performance testing 409 00:27:41,580 --> 00:27:43,380 because of instruments. 410 00:27:43,380 --> 00:27:44,220 He mentions that. 411 00:27:44,220 --> 00:27:46,520 I mean, that blog post from January 21 412 00:27:46,520 --> 00:27:48,320 is definitely worth reading. 413 00:27:48,320 --> 00:27:49,780 And there's a lot of interesting details 414 00:27:49,780 --> 00:27:53,980 about the project itself, how it's been developed. 415 00:27:53,980 --> 00:27:59,140 But what he did in January 21 is first run this, 416 00:27:59,140 --> 00:28:05,140 and he created a single image, 417 00:28:05,140 --> 00:28:08,420 he rendered a single scene, like one output scene, 418 00:28:08,420 --> 00:28:14,500 like 2K by 800 pixels in 64-bit something, 419 00:28:14,500 --> 00:28:17,060 I think that was the bit depth. 420 00:28:17,060 --> 00:28:20,220 And he did this on a 8V CPU, 421 00:28:20,220 --> 00:28:24,900 40 gigabyte memory cloud instance on Google Cloud. 422 00:28:24,900 --> 00:28:27,100 And it took 24 hours. 423 00:28:27,100 --> 00:28:32,820 So that's a single image, that's like a frame. He rendered a single frame in 24 hours. 424 00:28:32,820 --> 00:28:39,100 And the release he published last week, which he re-rendered that scene. 425 00:28:39,100 --> 00:28:44,620 Now it's not a one-to-one comparison. The image is slightly smaller, ever so slightly. 426 00:28:44,620 --> 00:28:49,740 I think it's maybe like 10% in each dimension. 427 00:28:49,740 --> 00:28:53,460 Also roughly 20% fewer pixels overall. 428 00:28:53,460 --> 00:28:55,160 and a slightly faster machine. 429 00:28:55,160 --> 00:28:56,660 So this will in the cloud instances 430 00:28:56,660 --> 00:28:59,100 was actually I think a physical machine, 431 00:28:59,100 --> 00:29:01,000 but he brought it down to 78 minutes. 432 00:29:01,000 --> 00:29:03,100 So that's quite remarkable in itself. 433 00:29:03,100 --> 00:29:04,340 - That's incredible. 434 00:29:04,340 --> 00:29:06,600 - But I thought this whole project is really interesting 435 00:29:06,600 --> 00:29:07,840 and the blog post certainly is. 436 00:29:07,840 --> 00:29:10,340 So you probably won't use it, 437 00:29:10,340 --> 00:29:14,580 but certainly you'll find the blog post interesting, 438 00:29:14,580 --> 00:29:16,920 I believe, if you're interested in Swift 439 00:29:16,920 --> 00:29:20,360 and that kind of Swift, which is sort of low-level-y 440 00:29:22,120 --> 00:29:24,680 and just very interesting cross-platform. 441 00:29:24,680 --> 00:29:28,440 It has lots of things that I find super interesting about Swift in general. 442 00:29:28,440 --> 00:29:33,240 I had no idea that those assets were public and available. 443 00:29:33,240 --> 00:29:37,800 Yep, there you go. That's Gonzales by Andreas Wendleder. 444 00:29:37,800 --> 00:29:44,920 Fantastic. So my next package is one called One Finger Rotation, 445 00:29:44,920 --> 00:29:51,640 which I spotted it because it's kind of an interesting title. 446 00:29:51,640 --> 00:29:58,360 I spotted it in the RSS list of package updates, and I opened up the package page for it, and 447 00:29:58,360 --> 00:30:08,280 instantly at the very top of the readme file is the most beautiful animation and explanation 448 00:30:08,280 --> 00:30:13,160 of - well, it's not even an explanation because it's not what it does at all, but it's a beautiful 449 00:30:13,160 --> 00:30:18,880 eye-catching animation, and it made me want to learn more about this. 450 00:30:18,880 --> 00:30:23,120 So the control in itself is a gesture. 451 00:30:23,120 --> 00:30:26,360 So you can add a one finger rotation gesture to any view. 452 00:30:26,360 --> 00:30:29,560 So if you imagine, if you were designing a UI 453 00:30:29,560 --> 00:30:33,240 that had a rotary dial on it, 454 00:30:33,240 --> 00:30:37,440 this would be a gesture so that you could move your finger 455 00:30:37,440 --> 00:30:41,880 across the surface in a kind of a circular motion 456 00:30:41,880 --> 00:30:46,120 and have the dial respond to your touch. 457 00:30:47,480 --> 00:30:52,480 But the animation on the top of this package page is wonderful. 458 00:30:52,480 --> 00:30:57,200 So it takes a very simple line drawing of a rotary dial 459 00:30:57,200 --> 00:31:02,800 and then in 3D spins it around to show this kind of incredible machine, 460 00:31:02,800 --> 00:31:05,760 like Rube Goldberg type machine underneath, 461 00:31:05,760 --> 00:31:08,040 which is creating this one fingerization. 462 00:31:08,040 --> 00:31:10,400 And of course, it's complete fiction, 463 00:31:10,400 --> 00:31:13,360 but it's a beautiful example of really catching. 464 00:31:13,360 --> 00:31:19,200 I mean, it caught my eye for sure, made me look more carefully at the package. 465 00:31:19,200 --> 00:31:20,480 And actually this package is great. 466 00:31:20,480 --> 00:31:26,600 So there is, you might think that this would be a very simple package, but there 467 00:31:26,600 --> 00:31:31,960 are so many things that you can do with this and you could have inertia on your 468 00:31:31,960 --> 00:31:36,640 rotation gesture, so you can, you can either just have it track your finger. 469 00:31:36,640 --> 00:31:41,600 Or if you kind of let go of your finger, you can have the dial carry on spinning. 470 00:31:43,040 --> 00:31:47,240 And you can rotate to specific values with or without inertia. 471 00:31:47,240 --> 00:31:49,240 You can have auto rotation. 472 00:31:49,240 --> 00:31:55,200 So there's an enormous amount of work that's gone into this one finger gesture. 473 00:31:55,200 --> 00:31:57,440 And I thought it was worth highlighting. 474 00:31:57,440 --> 00:32:02,480 And it's the kind of thing I actually have used in real world projects before. 475 00:32:02,480 --> 00:32:07,240 I think it depends on the project specifically, but a rotor and dial is 476 00:32:07,240 --> 00:32:10,600 certainly a valid UI control in a touch environment. 477 00:32:11,520 --> 00:32:15,120 Yeah, I mean, it's a virtual iPod click wheel, isn't it? 478 00:32:15,120 --> 00:32:17,520 Pretty much, yep. 479 00:32:17,520 --> 00:32:22,000 Yeah, I actually had this on my extended list as well. I saw that and I was... 480 00:32:22,000 --> 00:32:26,960 So that's One Finger Rotation by Matteo Fontana. 481 00:32:26,960 --> 00:32:36,160 Nice. Right, my second package this week is Swift Soup by Nabil Chatbi. 482 00:32:36,160 --> 00:32:39,920 And this is a package that we're actually using in the Swift Package Index. 483 00:32:39,920 --> 00:32:44,920 And what it does, it is a nice package to parse HTML, 484 00:32:44,920 --> 00:32:47,620 which we have some need for, 485 00:32:47,620 --> 00:32:52,620 I think in the context of adding the navigation bar 486 00:32:52,620 --> 00:32:55,140 to our Doc C pages. 487 00:32:55,140 --> 00:32:55,980 - You are correct. 488 00:32:55,980 --> 00:32:57,800 Yeah, that's the only, 489 00:32:57,800 --> 00:32:58,800 that's I think the only place 490 00:32:58,800 --> 00:33:01,440 we actually use it in production. 491 00:33:01,440 --> 00:33:06,440 So yes, we take the generated Doc C documentation page 492 00:33:06,520 --> 00:33:13,920 and we want to add some HTML to it above and below as headers and footers on that documentation site. 493 00:33:13,920 --> 00:33:20,560 And so we parse the entire HTML document so that we can insert various tags. 494 00:33:20,560 --> 00:33:26,160 We insert stuff into the head tag, which is the non-visible part of the page, 495 00:33:26,160 --> 00:33:33,560 and then we insert tags above and below all of the DocC rendering environment. 496 00:33:33,560 --> 00:33:38,480 Yeah, and you touched on a key point there, we're parsing the whole page. 497 00:33:38,480 --> 00:33:42,240 And I think that's maybe something interesting to briefly talk about, 498 00:33:42,240 --> 00:33:48,760 because the first thing you hear when someone wants to extract data out of HTML is, 499 00:33:48,760 --> 00:33:51,120 you can imagine the Stack Overflow question, 500 00:33:51,120 --> 00:33:55,200 what kind of regex do I need to write to get this out of the HTML? 501 00:33:55,200 --> 00:33:57,840 And the first response is, don't. 502 00:33:57,840 --> 00:34:03,000 So this package is for the time when you're reaching for regex, but you know you shouldn't. 503 00:34:03,000 --> 00:34:08,040 And I was trying, I mean, we have this immediate response, right? Don't do it. 504 00:34:08,040 --> 00:34:11,240 Why is that actually? 505 00:34:11,240 --> 00:34:16,760 And I looked into this briefly. I had some vague recollection of why that is. 506 00:34:16,760 --> 00:34:21,560 And the things that come up, you know, HTML is a context-free language. 507 00:34:21,560 --> 00:34:24,600 And I think it's, I don't even remember what the details are. 508 00:34:24,600 --> 00:34:28,760 I think it's mainly about the nesting, you know, you can have deeply nested structures 509 00:34:28,760 --> 00:34:35,840 that you eventually can't handle with RegEx because you can't write the RegEx for this 510 00:34:35,840 --> 00:34:37,960 recursive thing. 511 00:34:37,960 --> 00:34:45,160 I think the other part of it is just that HTML is so, what's the best word for this, 512 00:34:45,160 --> 00:34:48,400 so accepting of almost any input. 513 00:34:48,400 --> 00:34:52,320 It will do its best with whatever it gets. 514 00:34:52,320 --> 00:34:57,800 And so with a text format like that where you might have a closing tag or actually you 515 00:34:57,800 --> 00:34:59,640 you might not, or sometimes you will, 516 00:34:59,640 --> 00:35:01,920 sometimes you'll have white space, sometimes you won't. 517 00:35:01,920 --> 00:35:04,800 It's like it's a very rough environment 518 00:35:04,800 --> 00:35:08,520 to start doing searches through 519 00:35:08,520 --> 00:35:10,280 with a regx or something like that. 520 00:35:10,280 --> 00:35:12,920 - Yeah, and pages might still render okay 521 00:35:12,920 --> 00:35:16,240 even though they have technically incorrect HTML, 522 00:35:16,240 --> 00:35:17,080 I think you know that. 523 00:35:17,080 --> 00:35:18,000 - Absolutely, yeah. 524 00:35:18,000 --> 00:35:23,000 I mean, the browsers have over 20 years 525 00:35:23,000 --> 00:35:24,560 got all sorts of stuff in it. 526 00:35:24,560 --> 00:35:26,640 They'll render almost whatever they can. 527 00:35:26,640 --> 00:35:28,940 they'll render something no matter what the input. 528 00:35:28,940 --> 00:35:30,520 And that's a very challenging thing 529 00:35:30,520 --> 00:35:33,040 for anyone else to reproduce. 530 00:35:33,040 --> 00:35:34,940 - Anyway, I was briefly on this, 531 00:35:34,940 --> 00:35:37,080 you know, in this situation where I had 532 00:35:37,080 --> 00:35:39,080 way too many browser tabs open, 533 00:35:39,080 --> 00:35:42,240 and I ended up on the pumping lemma for regular languages. 534 00:35:42,240 --> 00:35:43,740 And I thought at that point, 535 00:35:43,740 --> 00:35:47,720 wait, you've got to stop, you're so deep in the weeds. 536 00:35:47,720 --> 00:35:50,680 And you're reading about stuff you don't even understand. 537 00:35:50,680 --> 00:35:53,880 But I thought that was really interesting and funny 538 00:35:53,880 --> 00:36:00,440 how you can have these stepping stones from things you almost understand. 539 00:36:00,440 --> 00:36:01,960 And you're just one click away. 540 00:36:01,960 --> 00:36:06,480 I think, oh, yeah, after reading this page, I'll certainly know what this is about. 541 00:36:06,480 --> 00:36:09,480 And you just, what you ended up with is just three more tabs. 542 00:36:09,480 --> 00:36:14,240 So there you go. Swift Soup by Nabil Shadbi. 543 00:36:14,240 --> 00:36:20,320 Yeah, and we can thoroughly recommend that because we've been using it now for a good amount of time, 544 00:36:20,320 --> 00:36:23,640 well over a year and it has been flawless. 545 00:36:23,640 --> 00:36:25,040 It's a great package. 546 00:36:25,040 --> 00:36:25,880 - Yeah. 547 00:36:25,880 --> 00:36:28,440 - So my final package this week 548 00:36:28,440 --> 00:36:31,400 is a package called Discord Kit. 549 00:36:31,400 --> 00:36:33,800 And the organization is SwiftCord, 550 00:36:33,800 --> 00:36:36,360 which is not something that I had actually 551 00:36:36,360 --> 00:36:38,000 come across before. 552 00:36:38,000 --> 00:36:38,960 - I actually have. 553 00:36:38,960 --> 00:36:42,320 There is a Discord client by that name 554 00:36:42,320 --> 00:36:45,480 and Discord Kit, I think, then obviously 555 00:36:45,480 --> 00:36:48,280 is the underlying package that drives 556 00:36:48,280 --> 00:36:50,620 the API access for it. 557 00:36:50,620 --> 00:36:51,860 I'm not sure what state it's in. 558 00:36:51,860 --> 00:36:55,260 I've been checking it out for over months now. 559 00:36:55,260 --> 00:36:58,400 Every once in a while I do download the latest release, 560 00:36:58,400 --> 00:37:00,860 but obviously with Discord and we use it so much, 561 00:37:00,860 --> 00:37:05,040 you need a lot of, you know, it needs to be quite mature 562 00:37:05,040 --> 00:37:06,980 before you actually start using it in earnest. 563 00:37:06,980 --> 00:37:10,340 But it is actually a client that connects to Discord 564 00:37:10,340 --> 00:37:13,640 and displays channels and all sorts of things. 565 00:37:13,640 --> 00:37:14,480 - Interesting. 566 00:37:14,480 --> 00:37:18,220 So I hadn't come across that third-party client 567 00:37:18,220 --> 00:37:24,300 But the reason I was interested in this package was you can create Discord bots with this 568 00:37:24,300 --> 00:37:25,500 package. 569 00:37:25,500 --> 00:37:31,980 So you could, the example in the readme file is a, just a simple ping bot where you can 570 00:37:31,980 --> 00:37:35,100 send a message to the bot and it will reply. 571 00:37:35,100 --> 00:37:37,900 You know, if you say ping, it will say pong. 572 00:37:37,900 --> 00:37:44,020 But that's a proof of concept for a bot, basic bot kind of scaffolding. 573 00:37:44,020 --> 00:37:48,900 And the whole thing is done in like five or six lines of Swift code. 574 00:37:48,900 --> 00:37:54,260 And the reason I was interested in this is, so we use Discord quite extensively in the 575 00:37:54,260 --> 00:37:55,700 Swift Package Index project. 576 00:37:55,700 --> 00:38:00,380 We have a Discord server where we chat with contributors and just have general chat about 577 00:38:00,380 --> 00:38:02,620 Swift Package Index, that kind of thing. 578 00:38:02,620 --> 00:38:07,860 But we also recently moved all of our reporting across. 579 00:38:07,860 --> 00:38:12,740 We used to use a combination of a tool called Rollbar, which is a web-based tool, and we 580 00:38:12,740 --> 00:38:22,940 We had a Telegram channel where it would report exceptions and logging events to that Telegram 581 00:38:22,940 --> 00:38:23,940 channel. 582 00:38:23,940 --> 00:38:28,900 And we've recently moved all of that into our Discord server. 583 00:38:28,900 --> 00:38:32,740 And so we have two channels, one for our staging environment, one for our production environment, 584 00:38:32,740 --> 00:38:37,820 where it's just constantly saying, "Well, it deployed this version," or, "This exception 585 00:38:37,820 --> 00:38:42,580 happened," or there's a whole load of information in there. 586 00:38:42,580 --> 00:38:49,360 And I find that sometimes I would like, not for every message, but I would like some messages 587 00:38:49,360 --> 00:38:53,180 to be more prominently notified to me than others. 588 00:38:53,180 --> 00:38:57,760 And so I was wondering whether I might have a little play with seeing what we can do with 589 00:38:57,760 --> 00:39:02,800 this bot to see if we can do some kind of fine-grain notifications there based on the 590 00:39:02,800 --> 00:39:04,160 actual information. 591 00:39:04,160 --> 00:39:08,800 I haven't done any of this work yet, but it just, it did stand out to me as something 592 00:39:08,800 --> 00:39:09,800 I might do. 593 00:39:09,800 --> 00:39:10,800 That's interesting. 594 00:39:10,800 --> 00:39:13,300 Yeah, I'm really curious about that. 595 00:39:13,300 --> 00:39:18,540 Why you added write something that kicks the one thing that seems to be happening every 596 00:39:18,540 --> 00:39:23,300 couple of days where you need to manually intervene, if that could be automated with 597 00:39:23,300 --> 00:39:29,060 a Discord bot, that would be amazing. 598 00:39:29,060 --> 00:39:33,220 So yeah, I think it's the kind of thing that, again, this probably is not going to be a 599 00:39:33,220 --> 00:39:39,100 package that many people use, but certainly being able to write a Discord bot in Swift 600 00:39:39,100 --> 00:39:45,740 is a nice little shortcut. Great, I think that wraps it up for this week doesn't it? 601 00:39:45,740 --> 00:39:50,500 Yeah, another set of package references, another quiz and we will be back 602 00:39:50,500 --> 00:39:58,380 in two weeks with yet more Swift Package news. Exactly and that's going to be just 603 00:39:58,380 --> 00:40:02,860 before WWDC. That is gonna be just before it isn't it? Yeah, absolutely. 604 00:40:02,860 --> 00:40:07,740 exciting times. 605 00:40:07,740 --> 00:40:11,020 All right, see you in two weeks. Bye-bye.