Folks who squash their #git merges, I’m curious why you are making that trade-off. I’m guessing the pro argument is a cleaner merge graph?
The big argument against it for me is that you lose granularity for git bisect. I've often been able to narrow down breakage (sometimes long past the merge) due to individual commits in the merge. If I'd merged in a giant blob all I'd have had to go by is that giant blob. (1/2)
@finestructure@fabianfett It is still a tooling issue, I don't see why you'd ever want to throw away history.
The fixit commits are hidden exactly the same way in the collapsed mode and you could also just hide them if you wanted to, and the tool allows for that.
@schwa@jackbrewster I think people actually did think a lot about this. And actually (not) used iPads for a long time to understand the issue.
iOS is a shrunk down OSX built specifically for very weak hardware. Scaling that up again is kinda funny (and didn't work).
In a fit of madness I've agreed to give an internal talk about advanced Swift at my company. Has anybody got any favorite Swift tricks they'd like to share?
@cocoafrog@ctietze@nicklockwood For this you can also use sequence, like for item in sequence(item) { $0.parent } { ... }.
But I also like the where, though I don't actually use it that often.
@tonyarnold No, I don't think it fits. Apple just introduced a new product category they make. And did so before w/ set-tops, speakers, watches, etc. I really don't think it is run by marketing, the issues are elsewhere.
The idea of using Wasm to solve compilation performance issues with Swift Macros feels to me like sidestepping the actual problems that are affecting us all. Given how long the blockers and problems with SwiftPM's handling of binary artefacts have hung around, this'll end up being a "for now" solution that never goes away.
Cool use of tech, but it's plastering over the cracks.
I can't fathom that this still hasn't been fixed. It's not as if Xcode has a teeny tiny user base and this is an obscure edge case. Every single Swift developer experiences this all the time. It's our IDE failing to communicate whether our codebase could compile or not. That's kind of a biggie.
@passim@simonbs More importantly fixing that bug won’t yield a bonus. (I think they don’t even consider it a bug, the “feature” was shown and explained on stage at WWDC, 2022 I think)
So what does rewriting a Swift app in Swift 6 actually get you, that staying on Swift 5.x won’t? Will new Swift language/compiler features come to both language modes for the foreseeable future?
@cocoaphony@aleck@stroughtonsmith The key question is whether you found the bugs because of the actual language feature or because you did the rewrite (and had to rethink the code). It's probably not b&w, but I suspect more of it can be attributed to the rewriting itself.
It is a bit unfortunate that one can't backup to and restore a #SQlite database from a byte buffer. Otherwise one could also use it to send serialized data over the network 🙈
@inthehands Yes, but you have to do the I/O to write it to a file, and then load it into a buffer, then delete the file. I'd like the byte representation of an in-memory db w/o doing any I/O.
@finestructure@inthehands This is not the ask, SQLite has an in-memory DB which that stuff is probably using.
The question is how to serialize that in-memory SQLite DB to say a Data. I think the only way is to backup the DB to a file, then load the file into a Data and drop the file.
@finestructure@inthehands SQLite has a backup API, but it can only backup to a file (or another in memory DB), not into a buffer.
There is also some kind of virtual file system thing, maybe that could be used somehow. 🤷♀️
