I think what I love the most about scale is that I can sit down for a couple hours and write a five-line patch that will, when taken in aggregate, save many lifetimes of waiting for things to load
By the way, if you’re using method_setImplementation/method_exchangeImplementations in your app, you may wish to reconsider doing so if possible for performance reasons. (If you’re using them to swizzle, there might be correctness reasons as well–but I digress.)
In particular, Methods don’t keep a backpointer to which Class they come from. This means that using either of those two functions means that the Objective-C runtime needs to blow out the method cache for *all* classes–potentially tens of thousands of them in a large app.
It’s often that case that you know which Class you are targeting–if so, try using class_replaceMethod instead. If used correctly, it works like method_setImplementation but lets you specify the class as a parameter, allowing the runtime to only have to flush caches on that class.
• • •
Missing some Tweet in this thread? You can try to
force a refresh
Just confirmed that @slackhq has fixed this issue, and I expect that they'll soon roll this out generally. If you noticed that your phone was getting poor battery life or would feel noticeably warm, this might help!
The main problem appeared to be an accidentally-quadratic loop in a part of the app that read log files between the app and an extension. For each file it would scan the entire directory, which doesn't really work if there are several thousand logs ;)
In addition, the loop had a high constant factor, because it was using readdir(3) from Swift. readdir returns a pointer to a struct dirent, which essentially declares the filename as "char d_name[1024]". Of course, in Swift this gets bridged to a 1024-element tuple…
Looks like the final iOS 15 is a different build than the RC from last week–19A346 verus 19A344. Maybe this one will have the security fixes iOS 14.8 shipped with?
(I hear that the new build actually mostly exists to fix a last-minute crash. I’m not seeing the bug in the security notes at the moment…)
Hey Mac Safari team, I know you're busy getting things ready for Monterey, but can you please fix the bug where Safari crashes when you try to reopen a window that has pinned tabs? I already filed FB9637329, but to make this as easy as possible I've already found the bug for you.
About halfway down -[BrowserWindowPersistentState initWithBrowserWindowController:encryptionProvider:skipTabStates:] you save the currently selected tab to self->_selectedUnpinnedTabIndex. The index you calculate includes all the pinned tabs…
…but at the top of -[BrowserWindowPersistentState restoreWindowContents:] you use this combined index to read from self->_tabStates, which *doesn't* include pinned tabs. Sometimes, you'll just end up selecting the wrong tab, but other times the index will be out of bounds…
I am so tired of watching people continue to juice numbers by doing things to boost short-term growth and causing attrition in places that are not tracked–spelling disaster in the long term. As an industry, we have really failed in creating "sustainable metrics".
The funny thing is that we all kind of already know exactly where these blinds spots are: if you are measuring engagement, it's easy to boost that by giving people things that keep them addicted to the platform. So you want to counterbalance by measuring conversation health.
If you're looking at new signups: you can easily boost this by putting a thing in everyone's face to ask for that. Obviously, you want to make sure that the people who are doing this actually stick around, rather than are just making a throwaway because you forced it on them.
Just patched yet another project to delete a “-Werror” just so it would build on my computer and I think I’ve finally come to the conclusion that we have *really* failed at explaining why compiler warnings exist to an entire segment of programmers. We need to fix this.
The problem has gotten so bad that some of these people are *working on compilers* right now! They are literally encoding these assumptions into programming languages millions of people use. The productivity cost is real–if you use Swift or Go, you’re already living through it.
As a concept, warnings are pretty simple! They’re not that hard to understand if you approach them from the bottom up. The problems arise when you look at them in the opposite direction, without really understanding why they exist. Here, I can go through them now:
Jokes aside, though, as engineers we regularly deal with complex systems that can be difficult for our users to understand. Having a hard time explaining how they work is one thing, but regardless of your position on this technology @Apple’s messaging has been unacceptable.
Their reluctance to clearly describe how the software works, their seeming inability to be straightforwards with the fact that it fundamentally detects CSAM using filters that they control and uploads it to them, is very concerning. This isn’t how you inspire trust.