Adobe Photoshop Lightroom doesn’t support Adobe Photoshop files

I need a ‘facepalm’ category apparently.  There’s been a lot of that lately.

You cannot import, let-alone work on, Photoshop files (“PSB” file extension) in Lightroom.  It flat-out doesn’t support them.  That’s such a weird limitation & oversight, for a program that Adobe now officially names ‘Adobe Photoshop Lightroom’.

See also this six year old thread on Adobe’s website, asking for this feature.

Your system has run out of application memory HUR HUR HUR

I hate this dialog with the fire of a thousand suns.

When this appears, it basically means one (or both) of two things:

  1. Some application went nuts and chewed through all your memory and/or disk space.
  2. macOS got itself into a darkly comical & embarrassing deadlock.

Quitting any of the listed applications is rarely the correct move.  It’s often enough the case that none of them are the root cause, and you can kill all of them if you want, but it won’t fix the problem.

One important thing to clarify first, though, is that this dialog does not necessarily use the term ‘memory’ in the conventional sense – i.e. RAM.  It can also refer to disk space.  Unfortunately it doesn’t bother to distinguish between the two, which is particularly stupid of it since any possible resolution of the issue is highly dependent on which of the two cases it in fact is.

Thank goodness for iStatMenus, though, which in the most recent incident showed that I had ~20 GiB of RAM completely free (not even inactive, actually outright free).  So immediately that rules out what the daft bloody dialog’s actually saying.

The worst thing about all this is when it’s #2 the occurs.  For example, I had Lightroom do a 63-image panorama merge.  As Lightroom is a gross memory pig when doing panorama merging, it consumed something like 40 GiB of memory.  Which caused a bunch of stuff to page to disk.  Which consumed all the disk space.  Which led to that obnoxious dialog.  Which further led to macOS in its infinite fucking wisdom ‘pausing’ (SIGSTOPing) almost all running programs, including evidently whatever daemon actually handles paging.  Thus when Lightroom actually completed the panorama merge and released all that memory, I now had 20 GiB of free memory and the system refused to use any of it to page back in all that memory it’d paged out.  Because it was out of disk space.

The only solution – short of hard rebooting and hoping it resolves itself – was to delete a bunch of files I actually do still want, but which will now have to be recovered from a backup.  Great job macOS, thanks for all your help.

Of course, even once you do that and recover the system from the derpeche mode it put itself into, it won’t actually unpause any of the shit it broke.  You have to do that manually.  It pretends you can do that via that dialog that started the whole thing – assuming you left it open the entire time, blocking your view as you actually help the situation – but that only shows user-visible applications, not all the other system & background processes that it also rudely halted.

So, simple tip for resuming everything:

sudo killall -CONT -m '.'

Elegant, after a fashion.  Though every time, it reminds me that whomever named it ‘killall’ was either not very friendly or not very wise.

Note that the system will probably still be a bit broken in places, as despite what macOS thinks, you can’t just blindly pause random system tasks and not have things get really, really confused.  A reboot is always wise after seeing this dialog, to properly undo its fuckery.

#if DEBUG in Swift


The Swift team give an impeccable impression of a group of people who’ve never actually tried to use Swift.

An incredibly basic compiler task is to provide code a way to distinguish between debug & release builds, in order that it can behave accordingly (e.g. change the default logging verbosity, change asserts from fatal to non-fatal, etc).

Long story short there is no way to do this that works correctly with swift build.

You can make it work with Xcode only by way of a simple workaround – you manually define a custom Swift flag in your target’s settings (here’s one of a bajillion explanations of how do this).  You end up with basically identical code to other C-family languages, e.g.:

    let logVerbosity = 1
    let logVerbosity = 0

But there is no way, when using swift build, to specify custom Swift flags in your package config.

You can specify them manually with every single swift build invocation, e.g.:

swift build -c debug -Xswiftc ‘-DDEBUG’

But now you have extra work and the possibility of screwing it up (e.g. omitting the flag, or mismatching it to your actual build style).

The closest you can get is to use some undocumented, hidden Swift internal library functions:

func _isDebugAssertConfiguration() -> Bool
func _isFastAssertConfiguration() -> Bool

These are defined in swift/stdlib/public/core/AssertCommon.swift.

Only the first is likely to be useful.  The second applies in the case where you’re building not just for release but unchecked (-Ounchecked).  If you just want to conditionalise on release builds generally, you have to do !_isDebugAssertConfiguration().

The additional problem with this approach is that these are then, in your code, runtime checks.  And the compiler then thinks it’s being helpful by pointing out that some of your code that uses them is unreachable.

And of course Swift has absolutely no way to silence compiler warnings, or otherwise tell the compiler not to trust its reachability checks.


Update (February 2018)

While the above method – using the _isDebugAssertConfiguration() method – does still work at time of writing, in Swift 4.1, there are some marginally better ways now available.  There’s still not a proper solution, infuriatingly, but with some creativity, as you’ll see momentarily, you can get pretty close to expected functionality.

First alternative

This will only suit some cases, but its relative cleanliness & simplicity makes it appealing when it is an option.

You can use #if targetEnvironment(simulator).  This of course only distinguishes between the simulator and a real iDevice environment, though that can often be useful too, perhaps orthogonally to DEBUG vs RELEASE concepts.

Second alternative

Wrap all uses of _isDebugAssertConfiguration() inside a minimal set of functions.  All this gets you is a reduced (and fixed) number of unreachable code warnings, though.

For example:

func inDebugBuilds(_ code: () -> Void) {
    if _isDebugAssertConfiguration() {

func inReleaseBuilds(_ code: () -> Void) {
    if !_isDebugAssertConfiguration() {

You can then use these in a fairly streamlined way:

inDebugBuilds {
    print("Hello, I only greet in debug builds!")

inReleaseBuilds {
    print("While I only greet in release builds - aloha!")
Third alternative

It’s possible to do one better than the above, and eliminate those unreachable code warnings entirely.  Plus, doing so actually removes any use of unofficial APIs… but it requires abusing the official API a bit.

The built-in assert() method is implemented atop _isDebugAssertConfiguration() just the same as inDebugBuilds() is, above.  However, because it’s part of the Swift standard library, you don’t have to be concerned about its implementation, its use of private / undocumented language, compiler, or library features – that’s up to the Swift compiler team.  Most importantly, use of it in your code doesn’t emit an unreachable code warning.

So we can do something like:

func inDebugBuilds(_ code: () -> Void) {
    assert({ code(); return true }())

Ugly and obtuse, but functional and reasonably expected to work in all future versions of Swift.

You can similarly create a variant for release-build-only code, though it’s even hackier:

func inReleaseBuilds(_ code: () -> Void) {
    var skip: Bool = false
    assert({ skip = true; return true }())

    if !skip {

Icky, but it works.  On the upside, you only have to define this ugliness in one place in your module, and then you can try to forget about its implementation. 😝

One caveat is that I don’t know if the above approach will properly strip out the unreachable code from your built binaries.

Another caveat with these is that since you’re invoking a function, you can’t do a natural if … else … pattern – instead you need explicit, distinct inDebugBuilds & inReleaseBuilds blocks.  So it can’t be completely like the vanilla #if DEBUG … #else … that C-family languages have had since before the dinosaurs.  You could create versions that take two closures as parameters – one for the affirmative case, one for the other… the trade-off is that your invocations are then a little more verbose and obviously function-cally, e.g.:

func forBuildStyle(debug debugCode: () -> Void,
                    release releaseCode: () -> Void) {
    var debugBuild: Bool = false
    assert({ debugBuild = true; return true }())

    if debugBuild {
    } else {

    debug: {
        print("I'm built for debuggin'!")
    release: {
        print("I'm built for the wild!")

Up to your personal preferences as to which API you adopt, and which implementation you choose (streamlined but private-Swift-bits-dependent with bonus unnecessary compiler warnings, or official-APIs-only but hacky).