Monday, July 1, 2024

SpamSieve 3.0.5

SpamSieve 3.0.5 is a maintenance release for my Mac e-mail spam filter. It seems to work great with the current macOS Sequoia beta, though I expect another update will be required when Apple releases the AI-enabled beta of Mail later this summer. Unfortunately, Apple tends to make big changes to Mail through August, so we never quite know where we stand until the GM, and a couple times there were even significant changes after that.

Some interesting issues were:

Previously:

5 Comments RSS · Twitter · Mastodon

What Apple should do with future versions is use the Blocked file that people have been creating since they introduced it and have it write rules when some enters when blocking the email address. It should also work across the Apple ecosystem on a Mac, iPhone and a iPad, though my thinking right now Apple is having problems with their ecosystem and not really saying anything about it since everything from iCloud to Messages and Photos have come to almost a grinding halt.

SQLite UNIQUE constraints really cannot be relied upon. I’ve now seen multiple cases of duplicates (sometimes dozens of the same row) because the database was damaged and so the index enforcing the constraint didn’t work. Recovering such databases is not straightforward because building a new database will fail due to constraint violations.

This occurs regularly? Is this new? Did the version of SQLite change?

That this would be common enough to include in release notes is amazing and amazingly depressing.

@Ruffin It’s not common or new. I’ve been seeing this now and then since SQLite 2. I presume it’s because the drive/SSD is not fully reliable rather than anything to do with SQLite. I also used to see customers with damaged plist files all the time, even when using atomic writes. It’s depressing, and I’m not sure why these issues aren’t discussed more. But, context: the posts here are my development notes, not the release notes.

Wes Campaigne

Regarding @retroactive, in the Swift Evolution proposal related to that, it mentions that you can suppress the warning in a backwards-compatible way by fully-qualifying all the type names in the extension declaration.

@Wes Thanks! That’s kind of obscure, like suppressing GCC warnings by adding extra redundant parens. I wish Swift had a real preprocessor so that we could, e.g., conditionally compile out stuff that the old compiler doesn’t understand.

Leave a Comment