-
• #2
Sounds like someone had working code thrashed by a change to a module?
I totally understand the motivation for these features. Currently, there isn't a direct way to copy files to the SD card in the Espruino from a computer. I suppose the IDE could send reset(); var fs=require("fs"); fs.writeFile("/node_modules/first_module.min.js", "content of module goes here"); The diff could be achieved in a similar way - but either of these are a little awkward. It would be really cool to be able to put things onto the SD card easily through the WebIDE though.
You could also take the SD card out, and load the files onto it that way using the usual tools.
Also - are you aware that you can specify a URL in the require statement, ie:
require("http://localhost/module.js")
This will still only work if the require statement is sent from the right-pane of the IDE, but at least it gives you control over the module that gets loaded without having to have stuff on the SD card. For the webserver, I'd recommend XAMPP on windows (note - if UAC is enabled, you'll need to set the shortcut to the control panel to always run as admin under properties -> compatibility), or Apache on Linux. Either of these can just be installed (almost all linux distros include or have an easy way to install Apache) and used without further configuration.
Edit: Just remembered a caveat to specifying URLs when doing require - the modules get cached, and there doesn't seem to be a way to clear the cache. I'm not sure what resets it - probably restarting the webIDE. Clearing Chrome's cache doesn't work, though. This means that if you're developing a module and testing it that way, each version needs a different file name... Though at least you have all the intermediate versions afterwards.
-
• #3
Well, you could use the file stream api to fetch and write each file one at a time in a loop. It wouldn't matter how big the file was, but it might take a long time.
-
• #4
If you're serving them up from a personal server then you just need to tell it to serve up the files with the correct cache control header.
The other option is to use urls that point straight to github, and then you can reference a specific file revision. Diffs are also automatic there.
I'm interested to hear what problems you've had that have prompted this though. I usually try pretty hard to be backwards compatible, with the only recent 'difficult' change being the addition of exceptions - which loads of people wanted, but which wasn't possible do without breaking stuff that previously produced warnings.
-
• #5
Well, I know there's a break with my DHT modules, when the event processing changes came in, if anyone other than me uses those.
-
• #6
Yes, that's fixed now though?
In that case something that was broken in Espruino got fixed. I guess at some point I could switch to a more comprehensive package management system, with a 'works with Espruino version' tag on each module revision.
My hope has always been that Espruino would stabilise enough that this wasn't a major problem. I think we're pretty much there now... I'm struggling to think of anything in the list of issues that would really cause a problem for existing modules.
Feature 1. Copy all the latest Modules, from the Internet, to the Espruino SD card.
Feature 2. Compare all Internet Modules versions with Module versions on the SD card and indicate any differences.