'Try stripping your code back until you get just that error'
As I did that, that particular CALLBACK error goes away. Hoping that might give a clue here.
'but it's possible you are executing code on upload'
No, making sure all code lines are within functions. Occurs during runtime setInterval.
'Normally, . . . there'll be a stack trace written to the console'
Well, I guess this isn't normal. A few console.log lines that I expected did occur, then just that output before the next interval ticked off.
'I imagine you modified code such that a callback function caused an error'
Yes, I stripped out all console.log statements within a setWatch under the assumption this was a timing or update to the console delay issue, and I removed any single line comments used for debug notes inside that function, in order to free up JsVars. I find it a bit of a stretch to think it is that one, after doing all that, but the wonderment still exists, how to distinguish.
'sometimes it happens if you Ctrl-C out of a function'
Okay, makes sense, but didn't do that in this case.
Any other ideas, tips, suggestions to narrow down to which of the three? I'll continue to parse clean up, as I have no other right now.
At this point, adding back in console.log statements is the only idea I could come up with. I also noticed that I had 600+ JsVars before I started to run individual functions. As soon as the setWatch was assigned, that dropped down to 47. Did a simple memory check with a text line such as "abcdef..." out to 216 chars. Under the assumption 12 JsVars, that string would use 18 JsVars plus a bit of overhead for the var name and function wrapper. In this case 550 JsVars got used up, somehow. 550 x 12 = 6600 chars! But, there just aren't that many inside any of the setWatch functions.
Does this seem a reasonable (6600 seems exsessive to me) number just creating/adding the setWatch to the environment? Do any called functions inside the setWatch have to be re-added in to that total?
I remember elsewhere (two years ago and can't locate in forum) that 100 JsVars was a minimum needed for execution overhead, plus what ever arrays/vars were in use. To upload, the total number of bytes, times two to allow for unpacking/parsing plus some large margin, divided by 12 or 16 maybe, is a really rough estimate of what has to be on hand before an upload should start. Am I remembering that correctly?
Espruino is a JavaScript interpreter for low-power Microcontrollers. This site is both a support community for Espruino and a place to share what you are working on.
Tue 2020.03.31
As I did that, that particular CALLBACK error goes away. Hoping that might give a clue here.
No, making sure all code lines are within functions. Occurs during runtime setInterval.
Well, I guess this isn't normal. A few console.log lines that I expected did occur, then just that output before the next interval ticked off.
Yes, I stripped out all console.log statements within a setWatch under the assumption this was a timing or update to the console delay issue, and I removed any single line comments used for debug notes inside that function, in order to free up JsVars. I find it a bit of a stretch to think it is that one, after doing all that, but the wonderment still exists, how to distinguish.
Okay, makes sense, but didn't do that in this case.
Any other ideas, tips, suggestions to narrow down to which of the three? I'll continue to parse clean up, as I have no other right now.
At this point, adding back in console.log statements is the only idea I could come up with. I also noticed that I had 600+ JsVars before I started to run individual functions. As soon as the setWatch was assigned, that dropped down to 47. Did a simple memory check with a text line such as "abcdef..." out to 216 chars. Under the assumption 12 JsVars, that string would use 18 JsVars plus a bit of overhead for the var name and function wrapper. In this case 550 JsVars got used up, somehow. 550 x 12 = 6600 chars! But, there just aren't that many inside any of the setWatch functions.
Does this seem a reasonable (6600 seems exsessive to me) number just creating/adding the setWatch to the environment? Do any called functions inside the setWatch have to be re-added in to that total?
I remember elsewhere (two years ago and can't locate in forum) that 100 JsVars was a minimum needed for execution overhead, plus what ever arrays/vars were in use. To upload, the total number of bytes, times two to allow for unpacking/parsing plus some large margin, divided by 12 or 16 maybe, is a really rough estimate of what has to be on hand before an upload should start. Am I remembering that correctly?