The low.js PC binaries are updated. Please try it out.

The ESP32 version will hopefully be out tomorrow. The release will be announced here: https://neonious.com/documentation/changelog

Fixed, in the three commits:

The real problem:
https://github.com/neonious/lowjs/commit/40fd0097c7fe1252762b0e4bccfd79ae02dac914

Makes the server also work:
https://github.com/neonious/lowjs/commit/85f3b7a37560ced9e83021190c081a42fcee4f5c

To fix that axios can handle timeouts:
https://github.com/neonious/lowjs/commit/6b833f2fe172f8a0d4a911b06b66c5c491d9cc24

Now axios should be working perfectly!

The new macOS binary will be compiled and put online automatically within the next 24 hours.
The ESP32 version will be out hopefully this week, it also includes other large developments..

I do not think this is a bug. The password belongs into lowsync.auth.config.json, not into lowsync.config.json . Reason for this is to have a seperate file which might not go into your repository but rather stay local.

If you add the password in lowsync.auth.config.json like this:
{
"password":"12345678"
}

Does it work?

Thank you,

Thomas

Thank you for the report!

I will try to find the error till tomorrow and report here.

A big lowsync update is coming up till end of this week and if it is an error (what I think this is) this will be fixed together with the release.

@ygageot With a very small test project which I can start on my own machine I can see the problem quickly and fix - if there is something to fix - without guessing. If you can help me here, that would be perfect!

Most npm modules out there were written without any CPU/RAM/Disk restrictions in mind... They often just make code a bit better to write, and consume lots of resources while doing that.

request is such a module. If you rewrite with using the built-in http/https modules, you will notice that the code is not so much larger or more difficult to read.

And if you need request for example because the built-in http/https modules do not handle redirects, take a look at axios. Far smaller and more modern design.

How much code do you have? If transpilation takes so long, it might be a too big project for the microcontroller. Just warning

In any case:

Babel, the transpiler, is CPU draining, and low.js is naturally far slower than Node.JS on CPU draining things, because it does not include all the JIT features (see This comparison from the Blog). So it takes time.

You can always do the transpilation step with Node.JS before running low.js. With TypeScript setting up the transpilation to do the whole directory is easy (here a config). With Babel it should also work somehow.

lowsync and the neonious IDE transpile the code when they are pushed onto the microcontroller.

To test the code on the PC, you can run the code with low --transpile <file>. This transpiles all files on-the-fly, however it is slow because it is done every time and low.js is not as fast as Node.JS. But for testing it works!

Thomas

The JavaScript files are on the microcontroller file system, when running them they are compiled to byte code which is kept in (external) RAM. This byte code is what is being run.

You cannot read the script from the bytecode. toString() of a function does not return the source code, as it does with the real Node.JS, this is just not feasable for lower mem platforms. But you can read the script from the file on the microcontroller file system.

Does that help?

Thomas

Thank you. I'm expecting a slow adaption of the forum, but I do get some mails with help requests every month, so I guess something will happen