You are reading a single comment by @allObjects and its replies. Click here to read the full conversation.
  • ////////////////////////////

    (note1): Browser javascript engines just-in-time compile the code block first before executing it, where as Espruino - because running of source code - immediately - 'streaming-ly' - interprets the code... you can see the difference in the way the the browser throws a syntax error before even doing something, where as Espruino already may have executed parts of the code when noticing that something is - syntactically - not adding up (@Gordon correct me if I'm wrong or leaning too much out of the window...).

    (note2): Before a piece of code is uploaded to Espruino, it is literally grep-parsed for require("moduleName") and referenced module is searched and sent to Espruino with the directly executed Modules.addCached(moduleName,moduleSourc­e);see Reference - which you btw can execute in the Web IDE's console with the same effect... and even for the module source this parsing and Modules.addCached(); is invoked. So when it the comes to the immediate or delayed execution of require("moduleName");, the 'code is found' in the Modules' singleton's cache... Now - afaiu - not the source code is stored in the cache, but the interpreted source code's return result... which means that local things need space only for the process to prepare for caching are then garbage collected if not referenced anymore (globally somehow or by closure).

    note3: This is the reason that upload should only contain a minimum of actual code execution. Therefore, it is better to stick ALL execution stuff into onInit(){ ... } and E.on("init",function(){ ... })-registered functions - even setting of pin mode, timeouts, and intervals. Of there is too much executed immediately beyond code (function) definitions, the upload may not have come to the code that in the timeout or callback will be called... (oooops... happened and created great confusion...).


Avatar for allObjects @allObjects started