Hey,

I'm writing something that uses a lot of memory and initially was running out of memory, I've been dealing with the issue all day, but went back to an old file (where I was running out of memory) and ran it however I didn't run out of memory this time.

I started printing stat(0) to see what was going on and for maybe the first ~1k of memory I used I was getting a result of 0 memory used back from stat(0).

I tried loading the file on my laptop and got the out of memory error. Went back to my PC, reopened Pico, ran the file, out of memory.

Is this a known bug? Am I being an idiot and missing something?

To be sure, you'd have to share the file so we can run/test.

One possibility though... a recent update to pico8 changed the memory from 1k to 2k. Maybe the one that crashes is on an older version before that update..?

psst, enargy means 1MiB to 2MiB

edit: actually, I guess it'll report 2048 at max, since it reports the number of KiB used, so maybe that's what enargy meant.

Hey, thanks for the thoughts.

The version is the definitely same on my PC and laptop as I used the same installer file from my USB stick for both.

To clarify:

I tried on my PC and seemed to have more memory than I should.

Tried on my laptop which correctly reported out of memory.

Went back to my PC and restarted Pico-8 and at that point it correctly reported out of memory. It seemed that restarting Pico-8 solved the issue.

Before restarting (i.e. when the bug was still active), I created a new program which just created a bunch of variables in the table and stat(0) was returning 0 usage for a while and then started counting up towards 2048

ahhh.. well, as far as I have seen, memory is persistent if you don't start a new session (close/open a new instance of pico-8, or use "REBOOT").

So old variables and tables will stay in place if you load a new cart and then run it. This is part of why it's important to initialize any variables you plan to use in _init since you can't assume they'll not already be defined and in use.

Before, I'd only tested this using memory locations, but from what I can tell this applies to variables and such in lua memory as well... Personally, I like this behavior BUT I also understand how that would be a pain if you're pushing memory limits and trying to run benchmarks.
For accessing those things ("metatables", I think?) and making sure they are cleared, you'd probably need someone like @Felice to explain that.

FWIW, if your typical user is playing the game on an html export, this forum, or a binary export this shouldn't affect them. But it would affect a pico-8 desktop user accessing the game via Splore.

@enargy

The global Lua state, specifically the hidden _G table that globals are members of, is reset at the start of every run. No old vars/tables should remain.

If you have an example where they do, you should let zep know, because that's a bug.

Edit: looks like loading a cart doesn't reset globals, but running it does. This might be what you were seeing...?

@Felice: Ah yeah that was it then; the only test I did was:

• run cart
• print variable in interpreter
• load new cart
• print variable in interpreter

But running that new cart resets the value to nil (even if the new cart doesn't initialize that same namespace).

Makes sense.

It would suck if you couldn't rely on the reset. So many of my little apps outright rely on everything defaulting to nil...

The one thing that catches me out sometimes is the T() abbreviation for TIME(). I forget sometimes and expect the variable T to be nil when I'm playing with a tweetcart.

Edit: Hey, that's actually useful. A lot of people use '_' as a 'FALSE' value in tweetcarts, because it's an undefined variable that therefore defaults to nil. Since 'T' defaults to a non-nil function, that means you can use '_' and 'T' in please of 'FALSE' and 'TRUE' to keep tweetcarts short. You could already use '_' and '1', but I like 'T' for 'TRUE' better. :) (Heck, you could use 'F' for 'FALSE', come to think of it.)

@Felice: huh, so I was going to point out that using "_" as 'false' would make it so you couldn't use it as a label. Which would have been bad, because ::_:: looks like an adorable spider.

..but apparently you still can, since ::labels:: for use with goto don't share the same namespace as other variables..? Or at least that's what it looks like:

_=0::_::
_+=.025  // <-- less seizure danger than "+=1"
cls(_)
flip()
goto _