• I wouldn't worry about MEMORY_BUSY, it's just a warning and is unlikely to affect the code.

    I think what's been hit is something I noticed with the slopeclock as well.

    Basically when you have a custom font, you've got the code in something like setFontLatoSmall which does this.setFontCustom(E.toString(require('h­eatshrink').decompress(atob('...

    The issue is that E.toString is used here to create a string from the array, but it has a second effect - it tries to force what is has into a 'flat string' and if it can't it returns 0. Over time the memory can get fragmented and then sometimes it gets so fragmented there's no way to allocate a contiguous memory area of the length needed, and 'E.toString' returns undefined and this breaks.

    It's a tricky one to fix nicely, since I can't change E.toString to add an option like {forceFlat:false}as it's supposed to use all it arguments. I could add E.asString or something like that and then we change all the font code to this.setFontCustom((E.asString||E.toStri­ng)(require('heatshrink').decompress(ato­b('...?

    I guess the nice solution would be to rename E.toString to E.toFlatString, and to make E.toString just use a string if a flat one can't be allocated - but that would make anyone's code that uses Inline C/assembly unstable unless they changed it.

    The way to work around it in your clock is to pre-allocate the font bitmap as was done here: https://github.com/espruino/BangleApps/c­ommit/c47bc078acf593e3e7554c557c1fa01fd6­8fc14a

    The side-effect is your clock actually works a bit faster too, at the expense of more RAM usage.


Avatar for Gordon @Gordon started