Release: LiveCode for RPi 6.5.1

[bogs]

I took a half hour and knocked together the testing I did into a video. This is not comprehensive by any means, nor even on the right system ( this is on 'nix x86/64), but it is using 6.5.1 and posting long seconds and milliseconds to 'a half dozen fields'

I sped the video up, if it is moving too fast for you, go to the youTube gear and set the speed to .5 or so. Video length is 7 mins. + / -

I didn't get a memory crash, but, was able to hit a recursion hang (executes too fast? Maybe I should drop the pending messages? dunno, didn't test it out).

Have fun all.

https://youtu.be/R85d9c9rSLM

P.s. - This video *does* also point out something I posted elsewhere, give your 'wait with messages' statements at least a few milliseconds to complete pending tasks, I think waiting 0 with messages is pointless and keeps your CPU%'s unnecessarily high, which in turn probably has a negative impact on speed of execution.

Wait 0 sounds like a cool thing, but is probably slower than 'wait 10' or higher, unless you are seriously into thrashing your CPU for no gain.

[jacque]

The engine only does garbage cleanup on idle, so running a repeat loop for a long time without yielding time to the engine will accumulate a lot of cruft. I'd expect the results you saw.

Even waiting 0 should help but a few milliseconds might be better. Or use "send in time" with a few milliseconds delay (this is the preferred way) and run the tests again.

[jacque]

Wait 0 sounds like a cool thing, but is probably slower than 'wait 10' or higher,

The amount of time in a wait statement determines the order of the pending messages, so "wait 0" just moves the execution to the front of the queue.

[bogs]

Makes sense from what I saw

[jacque]

I wrote that wrong, should have been referring to the send command. A wait inside a handler happens when specified.

[jwkuehne]

The memory leak I'm talking about is on the Raspberry Pi 4 OS with LC 6.5.1 standalone, and not some other platform.

It doesn't matter if you wait 10 milliseconds, or send in 10 milliseconds, or both wait and send in 10 milliseconds, or repeat forever, or what you're writing, or the options for building the standalone: writing repeatedly to a field leaks memory.

I just ran Bog's script, first as written, and then waiting and sending with 10 millisecond delays, and memory just goes up monotonically. Here are two screenshots. The standalone is called 'Untitled 1' in top.

[FourthWorld]

It doesn't matter if you wait 10 milliseconds, or send in 10 milliseconds, or both wait and send in 10 milliseconds, or repeat forever, or what you're writing: writing repeatedly to a field leaks memory.

I just ran Bog's script, first as written, and then waiting and sending with 10 millisecond delays, and memory just goes up monotonically. Here are two screenshots. The standalone is called 'Untitled 1' in top.

Very helpful info. Thanks.

It's looking increasingly unlikely we'll find resources to update the LC 9.x engine for RPi, but if we do and the issue persists with the current code base, the info you've posted here will be very helpful in pinning down the cause of the issue.

[jwkuehne]

Thanks, Richard. I was just in the process of deleting my whole post out of frustration.

I've been working on building the standalone for 9.5.1 using the gnu cross compiler. It's not easy!

[bogs]

The memory leak I'm talking about is on the Raspberry Pi 4 OS with LC 6.5.1 standalone, and not some other platform.

I understood that, which is why I said, not once but twice, that I don't have the hardware for properly testing or diagnosing the issue you expressed having.

It doesn't matter if you wait 10 milliseconds, or send in 10 milliseconds, or both wait and send in 10 milliseconds, or repeat forever, or what you're writing, or the options for building the standalone: writing repeatedly to a field leaks memory.

I think I may have confused you, I was just actually looking for a clearer explanation on the steps to build a standalone by creating a symlink to another directory. That wasn't connected to the crashing thing in any way shape or form, that was just a question for my own information.

As for the 'waiting' part, the assumption I was making was that if your not giving the engine time to dump messages, then those messages would be accumulating and eventually your going to run out of memory, which might look like a leak, but is actually just a logic error. It isn't the "wait xx ms" that I expected to see change the problem, it was "wait xx ms with messages that I expected to see change the problem.

Of course, for the 3rd time, I was unable to get the problem to occur because AGAIN, I don't have access to a rPi anything.

I just ran Bog's script, first as written, and then waiting and sending with 10 millisecond delays, and memory just goes up monotonically. Here are two screenshots. The standalone is called 'Untitled 1' in top.

I never saw the screen shots (which you apparently decided to delete), but I'll take your word for it, just as I said maybe 3 posts ago.

I'm not actually asking for your help, or speculation, or proposed workarounds for me to try.

I wasn't trying to give you any help, speculation, or proposed workarounds, I just saw something that might be an interesting problem and took a closer look at it for my own selfish interests.

For the last time, good luck with whatever your doing, I'm out of this thread before I start a problem, I see you already almost deleted your post, I don't need to add to your frustration levels.

[SparkOut]

I am 550 miles away from the Pi4 I could use to try this out. But it's already in deployment as well. I'd like to help confirm/test/analyse/provide data but it might be quicker to wait for me to buy the next Pi4 I was planning on getting, but that isn't going to be in a hurry.