Log In  

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

P#12079 2015-07-31 07:00 ( Edited 2015-07-31 15:29)

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.

P#12081 2015-07-31 08:17 ( Edited 2015-07-31 12:17)

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.)

P#12082 2015-07-31 09:16 ( Edited 2015-07-31 13:16)

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.

P#12088 2015-07-31 11:29 ( Edited 2015-07-31 15:29)

[Please log in to post a comment]

Follow Lexaloffle:          
Generated 2023-03-25 13:16:59 | 0.005s | Q:11