-
Sat 2020.01.04
'never ever save() with timers or connections going'
Thanks again @allObjects for that sage advice. I adopted and have been using that technique for over a year. I do find that comment a bit odd and out of place as I never mentioned the use of save() during my development, nor did @Oscar even bring it up until #11 post.
While that may have been contributory in @Oscar 's case, we all missed that, nor did any of us consider that possibility. We all wasted a ton of time chasing a ghost!
I only point out #15 Observations as I got burned on the same task again today, with multiple timers and set watches, even knowing that their use was problematic!
While it is possible to over write a variable with a new value, and Espruino is acceptable at (seems to be always) over writing functions (even after a save();) with a unique new definition, there are issues as I pointed out with specifically those two functions. I even had an issue where using a global var to accept the ID of an interval, did not get cleared with
clearInterval( id ). When I uploaded a new function including a new interval timing, I discovered (it's getting quicker now that I know this situation may exist) that there were multiple timers running, despite the fact usingdump()showed the timer ID value to be accurate. I've now adopted the sequence of always usingreset( true )before any intentional overwrite of anything. caveat emptor
You are reading a single comment by @allObjects and its replies.
Click here to read the full conversation.
Robin
@allObjects
never ever save() with timers or connections going... put all of your real startup code in the onInit() function... most of this classic conversation about simple explanation how to save code that Espruino run on start? is still true to the day... and if considered, saves hours... therefore: when thinking about save(), save yourself hours by sticking with some basic parameters (when it comes to timers and watches... BLE connectivity is a bit different...)