Native Applications for Command-line and IDE

There are a whole bunch of solutions out there for communicating with Espruino boards (http://www.espruino.com/Programming), but they pretty much all require a reasonably big install of some kind (Chrome, Node.js or NW.js) and are also dependent on big projects which keep randomly changing and breaking things (The recent Node.js 10 serial/bluetooth issues for instance).

It strikes me 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) that:

• Could communicate over Serial (USB), Bluetooth LE and TCP/IP
  
• Could access files on the local hard disk (for proper file loading/saving)
  
• Contained an HTTP server that served up the Espruino IDE via an iframe and communicated with websockets like we do for http://forum.espruino.com/conversations/318472/
  
  

In that way we'd have a very small, lightweight (<1MB) application that was fast and easy to install and was basically immune from all the changes and deprecations that go on in these big projects.

I did look at this with https://github.com/espruino/EspruinoHost using Qt as a multiplatform library, but it was the worst of both worlds - big installs required, not looking like it belongs on any platform, not very reliable, still requiring some OS-specific tweaks, and dependent on Qt's APIs.

It seems that going fully native in the easiest language for each platform is preferable, but that's not something I really have the capacity to deal with.

So... Are there any developers out there for Windows, Mac OS or Linux that would be willing to give this a try?

Another option is to actually add serial and Bluetooth support to Espruino itself on each of those platforms, and use Espruino as the Native application. There is a certain symmetry in it, and having Espruino executables available for Windows, Mac and Linux with a standard API could be quite exciting - however it is definitely a much bigger project (and would restrict the language choice to C/C++).

sisyphus is the term coming to my mind when reading about this - your - journey!

It's very clear that you voluntarily mastered that task... which though does not mean that it will ever be easier... something will be broken all the time, no matter what the chosen approach. I usually tend for the integrated approach out of one hand than a bag full of fleas (Germanism)... they tend to be jumping around all the times: the perfect implementation of the anti-pattern of stability. Over time though - when things mature and get more standardized / normed - life gets easier... road has less bumps... sailing becomes smooth(er): just thinking of the browser builder specifics in html / css / JS / etc... 20 years ago versus today...

Said so, it cold become possible with docker to compose such a setup more easily, easier to test and maintain. The 'bridges' between SW and HW will though stay contentious subjects.

@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.

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 select for networking and so not consuming 100% cpu all the time and I am sure there are more things to think about.

Another option is to actually add serial and Bluetooth support to Espruino itself on each of those platforms, and use Espruino as the Native application. There is a certain symmetry in it

Interesting idea. At least for linux port it is doable and would benefit the platform itself e.g. when running on Raspberry Zero W which has Bluetooth LE.

Most people on windows now have windows 10 - which supports the Linux subsystem, so that might simplify the windows side of things as the sample Linux tool chain could be used for that and share then same code.

I'm less convinced about Go just because it's another layer. I just checked and it looks like none of the existing BLE libs support Windows, and it looks like the ones that exist use 'CGo' anyway - so now instead of just having a C toolchain you have to have the tools (eg Xcode, Visual Studio) to build C and Go.

Do you have a link to that Docker build that'll compile Mac OS images? (edit: I found https://github.com/multiarch/crossbuild)

There doesn't actually seem to be a C/C++ library to handle Bluetooth LE in a multiplatform way (there's https://github.com/mbientlab/Warble which doesn't do MacOS, and which seems to only be allowed to be used with mbientlabs devices). All the various language implementations (in Chrome itself, Node's Noble, Python's bluepy, Go's various implementations) seem to have their own implementations for each platform. Also only Noble seems to do Bluetooth HCI which is a really good fallback for any platform, and is the only option on Windows 7 and earlier.

I don't want to be this guy: https://xkcd.com/927/

But... rather than do the same with Espruino (or with a new tool) one option might be to start a new project that was a multiplatform C(or C++?) library for accessing Bluetooth LE and Serial, and then to use that library to add BLE/etc support to Espruino. Bonus if it could be compiled to a command-line tool as @opichals suggests so it could be a swiss-army knife for accessing any IO device on any platform.

A library like that is likely to get an awful lot of use/contributions from all kinds of people, so should get to be pretty solid pretty quickly.

Also only Noble seems to do Bluetooth HCI which is a really good

So do you think Noble js code could run on top of espruino with the native noble C stuff moved to espruino linux target? Or is it too heavy? Actually the only native part seems to be https://github.com/noble/node-bluetooth-hci-socket/tree/master/src and the rest is pure js (?), can't find anything else.

BTW just recently I used noble as part of https://github.com/DigitalSecurity/btlejuice to reverse engineer communication between android app and fitness trackers and it worked for most of them (well, except the DS-D6 one I wanted the most - perhaps it uses some security features unlike the rest of cheap fitness trackers I got). bltejuice needs two bluetooth devices so I used raspberry pi 3b+ for btlejuice and Zero W for btlejuice-proxy and it worked. Node startup is a bit slow on the Zero but then it run just fine.

do you think Noble js code could run on top of espruino with the native noble C stuff

Wow. Honestly I have no idea - it's an interesting thought. I guess in terms of creating a multiplatform library it wouldn't help, but it'd be great to be able to get something working with Espruino in a bare-bones kind of way.

Having said that it looks like HCI might be reasonably low-level, but is probably relatively trivial to write a driver for to allow it to maintain a connection and read/write characteristics as you don't try to handle anything like bonding.