You are reading a single comment by @allObjects and its replies.
Click here to read the full conversation.
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.
@allObjects
As soon as you have to touch the code (manually), it's getting messy. I understand that it is a challenge, because between source code and uploaded code there is no simple mapping - for various reasons.
One major uniqueness of Espruino's is the fact that it runs on the source code. Taking advantage of that should make it possible to have some kind of a source map. Since this is major work, a slightly different approach could be taken: holding on in the IDE of the uploaded / runtime code. It would at least cover the non-dynamic stuff. It means, it does not cover the dynamically loaded modules loaded from board/runtime accessible SD cards at run time. IDE and interpreter can then exchange information / markers... yes it slows down the interpreter, but it could be built to the point that it is to the order of established break points. Since there is something like a PC - program counter - that 'runs' over the code, it shoud be possible that at statement begin the interpreter could check against a list of break points and stop there.
If the uploaded code('s reperesentation) is still 'too far away' from the code as it is stored by Espruino on uploade, not the uploaded code is held on, but the code as it is on Espruino is down loaded into kind of a debugger and used for debugging.
This are just all ideas.
Since we are in an object-oriented AND very dynanic world, I'm thinking about aspect oriented programming using (debug) annotations. The (debug) annotations are considered on code upload when upload for debug is enabled. Same thing - option - for module building (and may holding on to 'for debug built/minified' modules. May be this looks like node's approach.
For now I'm thinking more of having some simplifying support for unit and regression testing of modules on Espruino and building my application as composition of modules - of the rack modules and custom modules. It's not perfect and looks like 'heavy' in process, and it also does not help to figure out some very strange, unexpected, temporary behavior. Having a solid unit/regression testing though in place reduces the potential of such behaviors immensly. Doing TD / XP development is for me the approach. Any other approach interferes with the code at runtime.