Notice the program's characters are smaller than 15360 but the compressed version is bigger, and so saving fails

Note also that "saved test3.p8" is a lie

Oh man, that is a bummer if you lost work. The command line should definitely be fixed to not report a save that didn't occur.

On the more from-a-distance perspective, it looks like this is a case of using very long tokens, which I was just thinking about yesterday as a potential exploit of the move to a token-based code limit -- if each word is a token, you can cram a lot of extra bytes into each very long word for "free", which means an array of a bunch of very long words is some sort of magic in action. Look at that token vs. chars count here, for example -- average token length is over 100 characters long.

So as a structural constraint, the sanity check of testing the compressed cart size too makes sense for putting pressure on that exploit -- basically a Keeping Us Honest deal.

But that doesn't un-lose work if how it behaves in terms of saves is incorrectly reported, for sure.

Actually I was testing the possibility of storing raw data in the code's comments. (it works, sort of, except for the aforementioned issue and you can't use values 0x00 or 0x0A.)

yoinks. thanks -- buglisted for 0.1.2

At some point I will also improve cstore()'s behaviour in the code section. It should be possible to store arbitrary binary data after the compressed code, instead of having to hide it in comments.