!Usage - Too many nested structures at line 145.0

Just as the title says.

The !Usage application supplied on the RC-6 download for the Pi fails with Too Many Nested Structures At Line 145.0

This is not the most easily understood Basic code, so I can not see why. (Why does nobody use sensible variable names any more?)

That error almost always means it ran out of memory.

Have you tried increasing the WimpSlot parameter in the !Run file? (Assuming it has one, which it should.)

That error almost always means it ran out of memory.

Isn’t the classic method of causing that, on something like usage, that the author did something in a loop that doesn’t release memory and thus the app fails after a number of loops?
IIRC one such is a DIM inside the loop.

In which case a larger wimpslot just delays things.

Why does nobody use sensible variable names any more?

Damn BASIC compression utilities – the bain of all learners (and anyone trying to bug fix)

I just had a quick look at the source, and there are some DIMs inside routines. That does not mean they are not set-up routines called once, but it might be the problem. If running RO5 you can DIM LOCAL, as you can with Basalt. There are also a number of tricksy ways to use temporary memory.

Damn BASIC compression utilities – the bain of all learners (and anyone trying to bug fix)

At least supply the uncompressed version unless there are strong commercial reasons to obscure the code.

I agree, I see absolutely no point in compressing Basic code in this way. Either supply the original properly written Basic – or compile it and supply the compiled code.

That error almost always means it ran out of memory.

It is of course trivially easy to monitor the internal fiddly bits of any BASIC program while it is running, and one would hope that authors (in general) and investigators (in this case) would do so rather than guessing.

It is typical (and normal) for BASIC programs to use up memory as various actions are performed for the first time – causing PROC/FNs to be found and cached and variables to be defined. Once they’ve been covered BASIC also needs enough headroom for its stack (though I don’t usually leave more than 8K).

If it continues to use memory beyond this, it’s broken. If it uses BASIC memory (via any kind of DIM) in response to things outside its control, then it’s broken (bad author, bad!).

@nemo

You are right. It breaks when faced with events outside of its control. The test I was running created new task windows and new WebJames style CGI scripts at a rate varying between a few every second and a one every few seconds. The tasks lasted for anything between milliseconds and a couple of seconds.

@Martin

Yes, I have now tried a bigger wimpslot. It runs for hours and hours with the same stress test and a bigger wimpslot (I tried 380Mbytes)

The good news is that RIS OS Pi handles this test very well. :)

If it continues to use memory beyond this, it’s broken

I am sure you know of the pathological case of string allocation gobbling up user memory. Even in a normal program using strings with changing sizes the memory required can grow for some time after all the initial requirements you mention. If you are too parsimonious with the wimp slot this can generate the error. [promo] This can be addressed using Basalt’s LET a$, which allocates string memory from the heap above HIMEM.

If it uses BASIC memory (via any kind of DIM) in response to things outside its control, then it’s broken

[promo] Which is why you might want to use Basalt’s DIM HIMEM for runtime memory requirements. ;-)

I am sure you know of the pathological case

A$="":B$="":FORZ%=4TO255STEP4:A$+="Shut":B$+="Shot":NEXT

It is amusing to guess how much memory that line uses before trying it. ;-)

Half of the RAM memory in a model B. That is 0.003% of the RAM memory on a model B.

Well that wasn’t confusing was it.

But yes, that one line wouldn’t work on a BBC Micro Model A, and certainly not on a Model B in a hi-res mode with DFS. (s/+=/=…+ of course)

Apropos of nothing. I hate Textile.

It is amusing to guess how much memory that line uses before trying it. ;-)

<starts emulator> <tappy-tappy>

Good Lord! Really? <sigh>

Apropos of nothing. I hate Textile.

Shouldn’t hate be the emboldened word? Either way, take a number and stand in line. It’s a very long line, I’d bring a book…

[ the saddest thing is when I type “bq.” in other forums and wonder what the hell the parser has choked on for it to not work…until it clicks that, nope, this one uses Wiki markup, or this one uses [quote]…[/quote] markup… ]

Good Lord! Really?

The reasons are:

• BASIC has no garbage collection
• Unless the string is the last variable created, it can’t grow in place (very much)
• Growing strings get reallocated and the previous allocation is added to the free string list
• The free string list is never coalesced

Hi ho. All of that was fair enough on a 2MHz Beeb. It’s a bit shonky on a 1GHz+ ARM. :-(

It is a well publicised recommendation that strings should be intialised at the start of any program with a length which will be long enough for any subsequent use.

I did not get around to commenting on nemo’s post that:

All of that was fair enough on a 2MHz Beeb

Which was wrong, because strings on the BBC BASIC II were allocated a fixed space, unless they increased in size, when memory was lost. Hence:

It is a well publicised recommendation that strings should be intialised at the start of any program with a length which will be long enough for any subsequent use.

was then the right thing to do. BASIC V string allocation is a completely different beast, and doing that would most likely be a complete waste of memory.

strings on the BBC BASIC II were allocated a fixed space, unless they increased in size, when memory was lost.

That’s right, they were. I forgot. :-/

s/2MHz Beeb/4MHz ARM/ ;-)