Stack Overflow Error with too many variables - how exactly does stack behave

In my Weathergraph watchface I often run into this error (as I seem to be pushing into many CIQ limits) - I think it has to do with too many variables declared in various scopes (global, class, method).

Failed invoking <symbol>
Stack Overflow Error

I have enough free RAM, so this seems like there is another limit (stack < free RAM), I'd like to understand how exactly stack in Monkey C works so that I can know how to work around this:

- what exactly counts as stack? global variabes? class variables? scope variables? all of them?
- what exactly is the limit? Is there a limited memory for stack? Or is that a number of entries in some variables table? Can I work around this by using eg. an array (have one larger array with all variables instead of having many separately named variables)?
- is there a known workaround for this (having lot of free ram, but running into Stack Overflow limit)?

Thanks - I searched the docs, but I believe this isn't documented anywhere.

Top Replies

FlowState over 2 years ago in reply to DaveBrillhart +1

DaveBrillhart said:
I think they could easily support 512 items. As the power and memory allowance increases, that just makes sense. Saying it worked fine in the past, so no need to expand, sounds like…

All Replies

0 DaveBrillhart over 2 years ago in reply to jim_m_58

I think they could easily support 512 items. As the power and memory allowance increases, that just makes sense. Saying it worked fine in the past, so no need to expand, sounds like that famous Bill Gates quote. :-). Seriously, I bet they are clever enough to allow 512 or 1024 for large memory devices, and if really an issue, keep the 255 constraint for old/small/limited footprints. Maybe not, but this smells like an artificial barrier for some developers who are developing more sophisticated CIQ apps.

I'm pretty close to the limits for my most popular datafield. If I tried to add any internet queries, I'd be in trouble. But that isn't needed thankfully.

0 FlowState over 2 years ago in reply to DaveBrillhart

DaveBrillhart said:
I think they could easily support 512 items. As the power and memory allowance increases, that just makes sense. Saying it worked fine in the past, so no need to expand, sounds like that famous Bill Gates quote. :-). Seriously, I bet they are clever enough to allow 512 or 1024 for large memory devices, and if really an issue, keep the 255 constraint for old/small/limited footprints. Maybe not, but this smells like an artificial barrier for some developers who are developing more sophisticated CIQ apps.

Not to be too opinionated, but:

- The next highest logical limit would be 65535 (2 bytes instead of one), not to state the obvious, unless there's just 1 or 2 bits lying around somewhere that nobody is using.

- The real artificial barrier for more sophisticated apps is in the restricted capabilities and scope of the CIQ API, IMO.

- Another more important (IMO) barrier than this is the limited amount of total memory available to CIQ apps (still 32 KB for a data field on a Vivoactive 4, a non-discontinued watch released 2 years ago). There are ways to work around the various 255 item limits, but you can't work around lack of RAM once you've optimized your app to the bone

The most common complaints I've seen from end users are:

- the 2 CIQ data field limit for activities

- the lack of big names in the app store. The problem IMO is the market for CIQ apps is extremely small and it's not easy to monetize apps

Increasing the 255 item limit is not going to fix either of those problems.

I can def see how the limit would be annoying if you run into it tho.