‘Fake error’ about immutable values when using popFirst() on Array

It’s been a while since I wrote any meaningful Swift.  How I didn’t miss the Swift compiler’s bullshit error messages.

var someArray = ["Foo", "Bar"]

if let foo = someArray.popFirst() {
    print("Who cares, we never get here anyway.")

That yields, on the popFirst() method:  “Cannot use mutating member on immutable value: ‘someArray’ is immutable”.

No it’s not.  It’s simply not.

For whatever reason, if you instead call popFirst() on ArraySlice – ostensibly indistinguishable from a real Array – it works just fine.

var someArray = ["Foo", "Bar"][0...]

if let foo = someArray.popFirst() {
    print("Yet this works correctly.")


I presume it’s trying to tell me something stupidly obscure about Swift’s byzantine type system.  Good luck finding out what.  Good luck even finding the definition of the popFirst() method, since Xcode claims it doesn’t exist if you Command-Control-click on it.  But Xcode can’t find most things, so that in itself says very little.

Handbrake’s H.265 ‘Preset’ setting affects ‘constant’ quality

I always consternate over what the ‘Preset’ setting should be when doing H.264 encodes with Handbrake.  It’s always tempting to slide right on over to ‘placebo’ to, in theory, ensure you’ve got the best possible encoding.  And in my experience that at least roughly works – file size decreases (marginally) as you use more time-consuming encoding Presets, for equivalent quality.

Now that I’m transitioning to H.265 instead, I thought I’d do a ‘quick’ experiment to see how it behaves in comparison.  The result is baffling.

Handbrake H.265 file size vs Preset

PresetFile size (MiB)Encode time (Hours)
Encoding from ProRes 422 of a 4000x3000 timelapse, at constant quality 22. A 270° rotation was performed in the process. No audio.


The outputs should all be visually essentially identical, by virtue of constant-quality encoding with the same quality factor.  However, they are not – there’s a small but quite visible difference in quality, with the slower-encoded versions having progressively more detail retained, while at the other end, the faster encodings, it looks like a strong noise reduction pass has been applied (which isn’t literally what’s happened, I assume, but rather the consequence of a lower-quality encoding).

Regardless of the specifics, this shouldn’t be happening.  ‘Constant quality’ seems quite self-explanatory.

Note also how the encoding times go up exponentially – ‘placebo’ was really gruelling, as the equivalent H.264 encode would have been an order of magnitude shorter, and that’s what I’d budgeted my time from.

So I guess the moral of the story is… leave ‘Preset’ on its default value for now, until it stops misbehaving?  Choose it based primarily on your encode time constraints, or file size concerns – whichever is highest priority?  Frustrating.

Note: I used the Handbrake Nightly build as of mid-November 2017 (version 20171113130119-17a4bb7-master), as the latest released version (1.0.7) produces H.265 files that macOS High Sierra refuses to play.  Apparently it’s using a different codec tag – ‘hev1’ instead of ‘hvc1’ – from what Apple’s expecting (see for example this thread).  I have no idea which is correct, or maybe both are in some contexts… either way it’s a concern for ongoing H.265 device compatibility.

Lightroom “Classic” doesn’t play well with others

So far the new “Classic” Lightroom looks & feels mostly identical to the prior version(s), which isn’t really a compliment, but could be worse.  There’s no apparent performance improvements, that’s for sure, so as expected Adobe’s promises to suddenly learn how to write efficient & performant software, well… at least their marketing department gave it the college try.

One thing I have very quickly discovered, however, is that Lightroom “Classic” deliberately chooses not to perform some functions if it is le tired.  Or it thinks your computer is le tired.  By which I mean, if there is pretty much anything else running and consuming CPU time (and/or RAM?), it refuses to even attempt some operations.  HDR merges is the first one I hit.  I was a bit flummoxed by it just happily queuing up a number of HDR merge operations, and them just sitting there in its queue, with no indication of error – just never executing.

Only after I quit or disabled a bunch of other processes – any and all that were using any measurable CPU time – did it finally, about ten seconds later, decide that it was now willing to consider my ‘requests’.

#%@!ing fussy little turd.

It’s worth noting that it’s not the only popular app, on macOS, that does this same bullshit.  Time Machine is another big one.  At least in Time Machine’s case I can see a more plausible line of reasoning behind it, even if it is misguided – the user’s probably not explicitly waiting for a Time Machine backup to complete.  As in, not all the time.  Sometimes they are. And they certainly expect backups to happen at all, which on a consistently busy machine simply doesn’t happen.  So Time Machine’s reluctance to function on a working machine is still stupid overall.  But Lightroom refusing to complete a user initiated, user-interactive, and user-blocking operation, is just patently stupid by its very notion.

Update:  Worse, now it doesn’t work at all.  And a quick web search shows many other people having the same problem, and Adobe as usual doing nothing about it.

Incidentally, I tried to log in to Adobe’s forums in order to ‘Me too’ those issues, only it won’t let me log in anymore, falsely claiming my password is invalid.  Good job, Adobe, good job.