Undocumented limitations - which ones do you know?

E.g. I found out following the hard way:

functions do have a maximum number of parameters - use arrays if you hit the limit. I don't remember the error anymore (maybe it's invalid symbol)
functions do have a maximum number of lines - you will see a stack overflow exception anywhere in the middle of the long function that will mislead you...

I just found out about the second limitation today after refactoring my code to eliminate functions and optimise my WFs size. Anyone knows other exceptions? If I've heard of them I may not spend so much time searching for something that is not there the next time just because of such weird limitations...

Top Replies

jim_m_58 over 5 years ago in reply to Joe Berger +1

Sleep mode (as far as settings in the sim) might not be what you think it is. On the f3, you could do a manual "sleep time".

All Replies

jim_m_58 over 5 years ago

Not sure it's the number of lines of code for the second one, but perhaps the number of local variables. The locals are likely on the stack, as there is recursion in CIQ.

9635560 over 5 years ago in reply to jim_m_58

Recursion, yes, but not very deep... more than eight or so gives stack overflow.

jim_m_58 over 5 years ago in reply to 9635560

As the local variables are put on the stack...

Michael over 5 years ago in reply to jim_m_58

is there some way to check this? and is there something I can do here? Is a array of size n better than n variables in this case? Does it help to nullify variables after usage or does this not make a difference in this case?

jim_m_58 over 5 years ago in reply to Michael

Try a function with little code but a bunch of local vars. This is probably related to the number of passed arguments too - space is set aside on the stack for X parameters.

Michael over 5 years ago in reply to jim_m_58

That does not help in the real world. My WF is finished and released - I would like to check how near to the limits I am now - can I somehow do this? Can I somehow check the stack and it's max usage or similar? Whenever I do define variables for readability (I'm already avoiding functions, a lot of variables, constant defininitions and a lot more - although a compiler could easily optimise those things but sadly monkey c is not doing much here) I must fear that some program paths do crash because of this? It would be easier to make some tests now and check how near to the limits I am already...

jim_m_58 over 5 years ago in reply to Michael

Not sure there is a way. Stack Overflow means it's out of stack space, but there's a reasonable amount or folks would be running into this more often.

Michael over 5 years ago in reply to jim_m_58

It would still be nice to be able to check this as this is a very relevant information if all optimisations have to be done by the dev. The variables are taken from the stack as soon as they go out of scope, don't they? I'm unsure about this because splitting up a large function into two parts does help in my case... And it seems like both functions do use a very similar amount of internal variables, although that's just an estimation so far

jim_m_58 over 5 years ago in reply to Michael

This is pretty much "it works all the time" or "it doesn't ever work" thing. And when it doesn't the "Stack overflow" error tells you want to do. Reduce what you're code is putting on the stack and that's local vars. When combining functions, look at reusing local variables for example.

Michael over 5 years ago in reply to jim_m_58

jim_m_58 said:
This is pretty much "it works all the time" or "it doesn't ever work" thing

sorry, but if a code path is not executed in a setup it may work where as with another setup it may crash - or am I wrong here? (let's exclude recursion for simplicity here, recursive functions may of course create variables over and over again which should be avoided of course)