The chain is as strong as the weakest link. Espruino can save a state, but if you have a peripheral (link) in it that cannot save its state (or configuration) non-volatile, this great Espruino feature fails. This is typical for a lot of products that introduce a great (enhancement) feature to their detriment:
The user blames Espruino not working when in real it is all the stuff around it that is inferior to support the same level of features. Espruino is taken down by its own strength.
Therefore, any feature with such a potential should not be implemented - EXCEPT - where a significant number of use cases that benefit from the feature AND a clear NOTE / DISCLAIMER goes with the documentation about the feature's constraints and the overall context - exquisite to Espruino .
Even with all precautions taken, a feature may open pandora's box because users may not be aware of the ramifications of the constraints in their project. I experienced first hand what it means to withdraw a feature that jeopardizes the reputation of a product. Luckily it is not that serious with the 'save()' feature of Espruino. The repeated occurrence over time though shows that Espruino has reached a level of complexity where for some 'issues' there are no simple answers anymore.
Nevertheless, a loose (breadboard) wire connection can still be the cause, as simple as that.
© Espruino, powered by microcosm.
Report a problem