cjrriley.com
Resilient Autistic that loves solving problems with Swift. Make the world more accessible. 🇨🇦 Currently working on ATProtoKit. #atdev
(Profile pic drawn by kaylee_acnh on Twitter.)
3,062 posts
2,055 followers
253 following
Regular Contributor
Active Commenter
comment in response to
post
A... bat credit card?
comment in response to
post
That said, I’m more of a “behind-the-scenes/library/full-stack” Swift developer kind of person, so I suppose I probably shouldn’t attend, since there may not be a lot of things that would work out for me.
I probably should have continued working on my app ideas by now.
comment in response to
post
It is now plotting for revenge.
Let’s hope its target isn’t any any of *us*. 😳
comment in response to
post
Hopefully, nothing stupid happens when I release this, but I understand that, no matter how much testing you can do, you'll always have some kind of bug slipping through the cracks.
comment in response to
post
I'm aiming for the end of tomorrow to complete the rest of the changes, and then I'll start working on the testing over the weekend.
I plan to release this along with other changes in version 0.29.0, which should be available by Monday.
comment in response to
post
The remaining ones that are left are the ones within the tools.ozone.* lexicon models. I'll be moving those into the models, but I won't go through the process of conforming them to ATUnionProtocol or make the other changes: I'm going to have them be done through generated code. It's... a lot. 😅
comment in response to
post
I think I had a CD of this very game (or Backyard Soccer... I don't remember which one). I clearly remember it as a pack-in in a cereal box.
comment in response to
post
Canadians spotted. 👀
comment in response to
post
Can’t wait to get my libraries to work on Wasm now. Excellent work! 😁
comment in response to
post
Of course, it will all be documented. Obviously, it will be open source. Unfortunately, I can't make it in such a way where all ATProto Swift libraries can use it: it's tightly coupled with ATProtoKit (in a loose way. Not sure if that made sense.).
comment in response to
post
It's also the number one source of bugs that happen within ATProtoKit, so hopefully, that package will make sure that it's less likely to happen. If it does happen, then I can purely blame it on the lexicon generator and I would have a stronger foundation because of it once it's fixed.
comment in response to
post
That said, I want to get that out by the summer, as it's very stressful to manually write all of this stuff out. I like doing tedious work, and I'm sure I've done worse, but this is a weird kind of tedious that I somehow am approaching my limits with, so hopefully this will ease me substantially.
comment in response to
post
8. DocC extensions may be created at a later date, with newer files, though I'm unsure how exactly that would work out, so it's not going to be a 0.1.0 feature.
That should be it for now, though that's a simplified version. I'll continue iterating as I have more knowledge about it.
comment in response to
post
5. Each lexicon model will be in a separate file as well, with their own specifications.
6. Union types will be generated based on the way they will be displayed beginning 0.29.0.
7. Each part of the namespace will be separate enums in a reverse DNS structure, just like it is right now.
comment in response to
post
3 (con't). The developer will need to additionally add a JSON file that helps out with respect to what each method will be named.
4. Each lexicon method will have their completed wrapped up method in a separate file.
comment in response to
post
3. Once the OpenAPI generator completes its code generation, the lexicon generator will begin to take each method or initializer that was created and start wrapping the method with things like:
- inline documentation
- naming structures
- restrictions (such as minimum and maximum lengths)
- etc.
comment in response to
post
1. The developer can feed either an OpenAPI types file compatible with ATProto, or use a group of lexicon JSON files to the lexicon generator. If the latter, then it will generate an OpenAPI types file as an intermediary.
2. The OpenAPI types file will then be fed to the OpenAPI generator.
comment in response to
post
For now, the only thing available is a method that attempts to decode the JSON into a [String: CodableValue]. If that fails, it will throw an error. I expect it to always succeed, but this is to strictly comply with Swift’s ethos of safety.
More methods and properties may be added in the future.
comment in response to
post
With that said, one of the things I’m doing is creating a new protocol, named ATUnionProtocol. This will be required for all union enums going forward. It’s mainly to help with boilerplate code.
comment in response to
post
That doesn’t mean it’s 100% paused: I’ll still be working on them, but it’s only going to take up, say, 1% of my time, whereas the rest of my code will be for migrating all of these union types and adding the needed changes for each.
It’s unfortunate, but that’s the reality.
comment in response to
post
That should be all in terms of what will arrive in 0.29.0 of ATProtoKit. Things may change, but this is what I have for now.
comment in response to
post
SwiftCBOR dependency will most likely be removed as well, given that nothing is using that package; CBOR usage will be used on other packages in the ATProtoKit family. Lexicon model and method updates will arrive for 0.29.0 as well.
Status record creation may arrive as well or in 0.30.0.
comment in response to
post
With respect to Wasm, it won't be available for 0.29.0. I still need to install some tooling so I can run builds and see what should be tweaked, though it's my understanding that SwiftCBOR is the only issue. Speaking of which,...
comment in response to
post
I also have news with respect to WebAssembly and FreeBSD.
Given that Swift appears to be officially supporting both platforms, I'll also do the same. Though I can't seem to find anything related to FreeBSD beyond that WWDC video, unfortunately, so that will be on hold until I have more info.
comment in response to
post
It's honestly a little upsetting to see it go, because seeing the union enums now feels a little bit verbose: the macro was supposed to make things easier to read. And while I'm not going to get rid of the idea of a macro entirely, I'm going to add them into separate packages instead.
comment in response to
post
That said, the ATUnionBuilder macro will be deprecated. I've had various occasions where devs have wished to use ATProtoKit but didn't want to because of the macro: namely because it was difficult to use in Swift Playground and Xcode Cloud. Also, working on it was a bit of a hassle.
comment in response to
post
3 (con't) If it does happen, then I need to tweak "CodableValue," but that has been in the ringer for a long time and it should be robust now.
comment in response to
post
3. The way union enums handle unknown parts of the lexicon will also change. Now, instead of throwing an error, it will simply decode into a dictionary, where the key is "String" and value is "CodableValue." If everything absolutely fails, then an error is thrown, but I don't see that happening.
comment in response to
post
2. When decoding, it will now use a switch statement instead of if statements. It will also look at the ”type" property instead of decoding every struct. This should improve performance, even if it’s only a few milliseconds.
comment in response to
post
1 (con't). This also helps with naming, since the current way is awkward.
The only exception to this rule is that union enums where the lexicon's definition is something other than an object (such as an array). In those cases, the union type will automatically be below the definition model.
comment in response to
post
Yeah, that's fair.
comment in response to
post
I'm inclined to agree with you: wanting something that's distinctive enough where it's challenging for those two companies in particular to copy would probably be something Apple would like to have.
Now, hopefully, Apple can refine this in the way they're showing in the videos.
comment in response to
post
Now it's just making sure people *actually* send feedback through the proper channels.
comment in response to
post
Yeah, this is what I thought: their demos and the actual implementations are pretty different, so it's clear that what we're seeing now in the beta isn't what they're hoping for. So I feel more confident in what I said earlier.
comment in response to
post
This makes sense and I think their vision is sound.
Though the execution for some places need to be refined: some a little, others a lot.
But thankfully, they're not going to just wash their hands and call it a day: at least they will iterate like they did between iOS 7 Developer Beta to RC.
comment in response to
post
Okay: I see that swift-system has support for FreeBSD since (around) February. Well, I at least see *some* kind of movement, but I want to try building ATProtoKit on it now...
comment in response to
post
I'm looking at the forums and the official website, but I don't see anything related to FreeBSD support. Where's my FreeBSD? 😭
comment in response to
post
You don't understand how happy I am to hear about this.
I said this quite a few posts ago when talking about ATProtoKit's support for Android and WASM. I wanted to see FreeBSD as a supported platform. Now it's a supported platform.
I'm... I'm so happy! 🥹
comment in response to
post
To be fair, now that Java interoperability is a thing in Swift, the community can make Swift binding libraries of the Android APIs, thereby bridging that gap.
But I do agree that it was a strange move to make. 😅
comment in response to
post
Yep. Time for me to start writing a Launchpad app. 😅