Fork me on GitHub

@mike858 I found a difference between Linux and macOS which probably explains the slowness of a fresh build for you. I've committed the change and replaced the build cache with a new one on Hopefully fresh builds will be a lot faster now 🙂


(At its core, the macOS build was missing most of the GCL, and the fix now includes it, and thus all the GCL is now in the updated cache that I built.)


@mfikes I did notice it wasn't a complete cache but I thought that might have been intentional—good to know new builds should all be quick! My problem is still stumping me but it's not that high priority, I don't think. I'm using an entry-level Linode as my development machine and when trying to compile all of the bundled libraries, it will always hang at some point during the AOT phase (specifically when running decode.cljs). I've tried running both the Bash script and decode.cljs with the --verbose switch set but the hanging happens at the point planck decode.cljs <input> > <output> is called but before any execution apparently happens. Anyway, somewhat of an edge case. It'll be helpful not having to worry so much about this in future. Thanks!


@mike858 Which operating system? I don't encounter any issues building with Ubuntu 18.04. Perhaps I can add the problematic one to


When running the unit tests on an Ubuntu box with 1 MB allocated, it will hang in when it runs planck.closure-test, but this hang doesn't occur if the box has 8 MB.


@mfikes I'm on Debian 9. The machine has 1 "CPU core" (whatever that means) and 1GB of RAM. I was just able to successfully go from go to whoa with the new bundled cache so it's likely this problem isn't one I'll encounter much in the future.


OK—I successfully tested on Debian 9 as well.


In the above I incorrectly use "MB" units; should have been "GB"


Ah, OK. Maybe it is a RAM issue, then.


Yeah, that's my guess. That's the only hanging I've seen recently.