Most recent activity
-
@allObjects @Konkery Unfortunately I did not test it in Espruino before so sorry for pronouncing it a problem.
I can confirm now that for the
RELEASE_1V96this doesn't work as shown in the comments above and works appropriately inmaster. -
An Arrow function is different from a normal one in that its context is not bound and is taken from the scope lexically above it. Here is an article explaining the differences.
The code looks as correct ES6 wrt to context use and it should work (I had to fix class inheritance and undeclared variable use in order to run it in Chrome). It looks like an Espruino bug.
-
@tve The approach you are using is basically what I do as well.
Tested with tinyMQTT and a strip down of SSD1306 for I2C only (SSD1306_I2C).
Using Rollup https://github.com/espruino/EspruinoTools/blob/f8a5ed8bd565070d33154d9196ad9e51f8aa3c33/plugins/minify.js#L52-L65 you'll be able to create bundles that only contain the module exports that were actually used in the application.
My CLI preferred approach is to use the https://github.com/opichals/rollup-plugin-espruino-modules to do all the JS magic and use the espruino cli to only 'upload' the resulting bundle to the board just as @tve mentioned.
-
I use an HTTPS gateway in the cloud which provides a tunnel which is established from within my LAN using secure WebSocket. On LAN I run the MQTT server for the pub/sub IoT stuff and also other HTTP-based services.
-
@dave_irvine I run the whole application on my local machine. I mock any HW stuff and so the application graphics rendering is done as usual but uses some fake data to render.
-
It should be capable of working on boards but I have actually only ran it on my OSX laptop.
I guess the bandwidth and the lack of WS binary support might be a little problematic memory-wise as it is getting 8kB (screen buffer for 128x64 1bpp) over to the browser on every
flip()call. -
@dave_irvine from http://forum.espruino.com/comments/14535405/
I have played with the idea of having an easy way to debug graphics locally and made the following module https://gist.github.com/opichals/8f74cc494a3e2d7cf122c6013e8935cf
It wraps the Graphics.createArrayBuffer by calling require('./webGraphics').add(Graphics) and exposes http://localhost:8000 endpoint with canvas renderer for Espruino.
I used it to debug the morphing clock. With some mocking it is possible to debug graphics related stuff nicely before you put the code to the board.
-
@Mrbbp As the same code runs in Chrome I believe this is an Espruino parser bug. Please submit an issue at https://github.com/espruino/Espruino/issues.
-
add serial and Bluetooth support to Espruino itself on each of those platforms, and use Espruino as the Native application.
Thinking about this a bit more this sounds like it would make the rest of the project benefit as well. I might require fixing the stack to actually use
selectfor networking and so not consuming 100% cpu all the time and I am sure there are more things to think about.
@nistvan.86 There is a different philosophy behind the new module. It has been created so that I could separate the JS mangling stuff like module resolution, optimizations and minification from the actual code upload to the boards. We exchanged ideas on this with @Gordon earlier here.
So the workflow it has been designed in mind with is:
rollup-plugin-espruino-modulesto create the final .js bundleespruinonpm module) to send the bundle to the boardOr you could use the EspruinoTools (there a config/job variable for that) to run rollup for you with predefined config suitable for using with Espruino. I admit that this needs to get documented better... but you can have a look here.