You are reading a single comment by @dwallersv and its replies. Click here to read the full conversation.
  • Thanks very much for the detailed discussion! I'm a geek about this sort of stuff, so the more understanding the better :-)

    In the end, the problem can be summed up pretty simply: Scope.

    Rereading the primer on making modules I think I found the solution -- the section declaring public members. I didn't do that. Giving that a try in a bit...

    Also, ran across this again (I need to get kicked in the head twice sometimes to notice I've been kicked at all :-)):

    Can I dynamically load (and unload) modules?

    Yes. By default each module that is loaded will be cached (to avoid loading modules >twice). However you can call Modules.removeCached('modulename') which will remove >the module from the cache and free the memory that it uses.

    I think this is what's doubling the space usage over just loaded the same code directly from the IDE. IOW, there is a cached copy of the code, and another copy in the working space of the interpreter.

    I'll try using Modules.removeCached() in the main demo code to see what happens, but I suspect it will make the loaded code non-functional (as if it wasn't there). @Gordon?

    In the end, I may just have to structure this as a set of code files that must be literally appended to the application source in order to keep from wasting the very precious RAM on the F1, if code duplication because of the Module mechanism wastes all that space.

    It's ironic, because the Module caching mechanism seems intent on SAVING rather than WASTING space, and for the problem its intending to solve, it does. However, looks like there's an unintended side-effect of wasted space when there isn't the circumstance of loading the same module more than once.


Avatar for dwallersv @dwallersv started