Most recent activity
-
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. -
@Gordon As I suggested in the Rollup.js PR in my head all this communication interface should go into a single-purpose tool which is then called from other parts of the ecosystem (directly as a binary /think UNIX architecture/ or as a library).
that what would be perfect is a very small standalone (eg. not Node.js,
Python, Java, etc) Native Application for each platform (Windows/Mac/Linux)I totally agree here, access to hw is complicated otherwise.
As for the language of choice I would suggest golang as I hear (I didn't do anything substantial using it yet) it should have the required support in standard/external libraries. Quite complicated apps compile into a very small statically linked binaries which would be IMO just perfect for this purpose. There is ready-to-make docker to build all the required target architecture binaries. As an example project I'd suggest looking at is https://github.com/github/hub.
@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.