A bit of a weird one...

I'm getting random results from code that doesn't have any random/changing elements.

I have a cart that, whenever I run it, it has one of two behaviours, apparently at random? However, the code doesn't involve any randomness (and I seeded the random number generator just in case), and doesn't load anything from the disk or mess around with memory in weird ways - I would expect the results of this code to be completely deterministic prior to user input. It should just execute one line at a time, with all the same initial values. However, the result is something that is inconsistent.

This is demonstrated below. All I am doing below is hitting ctrl-r to run the cartridge. You can see when this happens by the timer at the bottom. Each time I run it, shows one of two behaviours, seemingly at random:

This happens both when running the cart from the RAM and running it normally, it's just easier to demonstrate from the RAM.

The code for determining the dimensions of the white rectangles is a bit complicated and involves quite a few recursive calls, which I'm guessing might be the cause of this? e.g. behind the scenes Picotron's doing some stuff in parallel that's leading to a weird race condition?

I'm not sure if this is a bug or is some weird edge case I'm running into, but thought it was worth flagging as it's not at all clear to me why this would happen.

This is running on the latest version of Picotron (0.2.0c).

The cart with all the code is below - apologies, pretty messy. Happy to try to explain any parts of it if it's useful but essentially, it's implementing a gui. The width of the white rectangles is dynamically determined by the width of red card they're in, and the width of that is determined by the width of the column, and the width of that is determined by the width of the window. Each time the width of the window changes (and at start-up), it triggers updates first to the column, then the card, then the text-editor. However, elements can also change dynamically based on their contents, so checks are triggered for parent and children each time each item changes dimension. As such, there's quite a few calls happening right at start-up to potentially update/reference the same values. This is why I think a behind-the-scenes race condition problem is a possibility.

More testing makes me think this probably isn't a race condition issue - spacing out the updates over multiple frames doesn't change the behaviour at all. Otherwise, not any closer to figuring anything out.

EDIT: I had an idea about it being during the first frame of execution, turns out that was wrong.

EDIT 2: Also, the inconsistent behaviour isn't just in how it initialises - whatever is going wrong persists in weird ways. See the gif below, where the behaviour on resizing the window isn't consistent:

It should be that everything resizes when the window resizes, but sometimes the text boxes don't? And when that happens, generally the performance is a lot more choppy and unresponsive (not sure how clear that is in the gif), despite it reporting to be running at 60fpg with minimal CPU usage.