Most recent activity
-
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.
-
IMO it would be worth to replace Esprima minification with the recently merged Terser minifier (see https://github.com/espruino/EspruinoTools/pull/80).
@Gordon Another reason to deprecate Esprima (it has all kinds of issues with ES6 code).
-
@Frida Thanks! Will try that once I convince myself to dig into the lamp guts again :)
@tve The approach you are using is basically what I do as well.
@MaBe
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.