Espruino 1v94 released!

[gfwilliams]

Posted at 2017-08-29 by @gfwilliams

Espruino 1v94 has just been released! It features a whole bunch of changes that should improve speed and reliability, on all boards:

Improvements

• Tab complete now works for Pins
• nRF5x/Puck.js: more resilient handling of BLE events when also executing JS code
• Puck.js: A very long button press at boot (until after the 5 red LED flashes) will now clear out all stored program code from flash
• nRF5x/Puck.js: Add hardware watchdog timer support with E.enableWatchdog
• Faster Flat String allocation which now avoids blocking
• nRF5x/Puck.js: Better error reporting for BLE errors
• nRF5x/Puck.js: Fix typo so we wake every 4 min for RTC, not 0.25 sec. Improves power consumption!
• Change order of execution for init - E.on('init',...) now executed before onInit (allowing modules to init before they can be called by the user)
• Added Error flag to show if a UART overflow has occurred
• Exceptions with stack traces now thrown in more areas (where untraceable warnings were printed before)
• Avoid printing interpreter error messages during execution, and report to console on idle when if errors were flagged
• Increase HTTP server and client version from 1.0 to 1.1 (needed for Websockets on Safari)
• Stop require dumping filesystem errors as well as 'module not found'
• Now throw an exception when writing to a closed socket
• process.memory() now reports time taken for GC and vars GC'd
• Slightly more aggressive idle GC threshold on most platforms (at 5% free)
• Add an argument to reset. reset(true) will now cause all Flash memory to be cleared as well.
• Added support for Seeed's Wio LTE board

Fixes

• Fix length calculation for typed arrays with an offset
• Fix Date.toString for dates before 1970
• STM32: Fix occasional RTC jumps (wrong month when setting RTC)
• nRF5x/Puck.js: If a task is in progress, report the task ID in errors
• nRF52/Puck.js: Report central mode promise errors correctly if returned by the softdevice
• nRF5x/Puck.js: Don't disable IRQs completely for some things - only disable Espruino ones, which will help reliability
• ESP8266: Fix load() causes endless loops
• ESP8266: Fix Wifi library not handling {password: null}
• Stop require creating an undefined Module entry in the modules list if no module exists
• Set the internal 'conn' variable to false when a connection closes to avoid confusion
• Fix issue drawing on right-hand side of rotated graphics where H>W (regression in 1v93)
• If >1 button, set pin state correctly at boot/reset
• STM32: Remove the 'utility timer' from the list of available PWM pins, fixing A0/1/2 PWM on F4

For a full list of changes with their bug numbers, check out https://github.com/espruino/Espruino/blob/RELEASE_1V94/ChangeLog

[espruino-discuss]

Posted at 2017-08-29 by @yerpj

Tab complete now works for Pins

Cooool! (1)

STM32: Fix occasional RTC jumps (wrong month when setting RTC)

Cooool! (2)

getting closer and closer to release 2.0 !!:-)

[espruino-discuss]

Posted at 2017-08-29 by @allObjects

...greatly appreciated! Espruino is always moving forward!

[espruino-discuss]

Posted at 2017-08-29 by @allObjects

Expansion - seeed's Wio Tracker - LTE CAT1... the references of Espruino on their site though are practically absent... I noticed that @opichals has contributed... I hope that the expansion is not just a distraction on multiple levels...

[espruino-discuss]

Posted at 2017-08-29 by @allObjects

About items in this release:

Avoid printing interpreter error messages during execution, and report to console on idle when if errors were flagged

I understand why, but it makes problem determination a bit more difficult, because sequence between user logging and system logging falls apart; does it?

Stop require dumping filesystem errors as well as 'module not found'

What is the notice now?

Fix length calculation for types arrays with an offset

...I assume typed arrays...

Stop require creating an undefined Module entry in the modules list if no module exists

...great... this threw me some curve balls in the past (now gona-go fix the fix in my code), but the workaround was not that bad... What I'm looking for in this area is an option in require to remove the module from the Modules cache when on (first and only) require invocation. I have situations where after 'consummation' of modules there is no value anymore to keep it in the Modules cache. Modules cache is only used to move the code onto the board and survive the first stretch until save().

I understand why hiding makes things more fluent... but at the same time also more fluid..., such as:

Don't warn the user when we had to run a GC pass during execution

How is this information now passed on to monitoring applications? Is there an option to put watches on such events / flags? I'm thinking also about

Added Error flag to show if a UART overflow has occurred

It is helpful to get this information. Option of adding setWatch()-like constructs would be of great help...

[gfwilliams]

Posted at 2017-08-29 by @gfwilliams

To be fair, the same as with Ruuvitag, Seeed are actually paying me a monthly fee to keep their board in the repo and produce builds for them. It's not a lot, but it covers my time making sure the builds always stay working - and is less than it'd cost them to pay an engineer to do the same.

There are only two companies doing it at the moment, but it's a big win for everyone. People get up to date builds for their boards, and we don't end up with what happened with RedBear where they came up with a firmware for the KickStarter and then never made any new builds.

We'll see - if more people do it, it could really help to increase Espruino's reach in a more sustainable way :)

Realistically I think Seeed will update their documentation soon, but if they choose not to mention Espruino much on their site it's really only them that loses out :)

[espruino-discuss]

Posted at 2017-08-29 by @allObjects

@gordon, thanks for this clarifying - transparent - post. In deed, I notice more an more makers exploring Espruino from all kinds of corners, because moving up for coding in a much more application oriented language/IDE/context increases fun. Most projects aren't anyway of the the sort where timing / bit-banging does decide over life and dead. And even if a project includes such things for some areas, Espruino does handle it under the cover... I need only to mention the hardware/software event queue...

[gfwilliams]

Posted at 2017-08-29 by @gfwilliams

Avoid printing interpreter error messages

I understand why, but it makes problem determination a bit more difficult

The errors that get reported are those from E.getErrorFlags() - generally they don't have much to do with the code that's running... For instance the 'out of memory' error is probably because something's being appended to an array - but it will rarely happen where the append itself is (more likely it'll be some other area of completely useless code).

If it is an issue, you can still track it down by adding E.getErrorFlags() in your code, or even calling it from the debugger.

require ... What is the notice now?

It's the same error as before. It just doesn't also tell you that there was a filesystem error (which is a bit of a red herring if you have no SD card!).

I have situations where after 'consummation' of modules there is no value anymore to keep it in the Modules cache.

Just do Modules.removeAllCached or Modules.removeCached once you have required what you need?

However in many cases that may not save you much memory at all, since in JS a function has to have access to the scope it was defined in - so if you've kept any function at all, it'll stop that whole module from being freed.

Don't warn the user when we had to run a GC pass during execution... How is this information now passed on to monitoring applications?

Check out the E.getErrorFlags docs: http://www.espruino.com/Reference#l_E_getErrorFlags

You get 'LOW_MEMORY' - it's just that it isn't reported to the user, as in nearly all cases it doesn't matter.

It is helpful to get this information. Option of adding setWatch()-like constructs would be of great help...

Potentially there could be an E.on event fired when the error state changes? I just wonder whether anyone would use it... You're the first person to ever request something like that as far as I know.

[espruino-discuss]

Posted at 2017-09-11 by @allObjects

may not save you much memory at all (with removing a module from Modules cache

In my case it was a lot of human readable data and thus quite verbose that gets binary-ized and stored in vars on execution of require() and before save() - transformation from source data into runtime data - and the source is not needed anymore, nor the transformation function (and with the removal from the Modules cache I would expect the garbage collect collecting all, because nothing in runtime references anymore anything of this data in source format and it's related transformation function code.

You're the first person to ever request something like that as far as I know.

In the spirit of Espruio's event driven-ness, I'm surprised... I would like to have something like that... because I do not want to put try/catches around the code or ask for error flag after execution/call of code that could set any of these flags, but it would be nice to be able to hold on / get notice of the even. It is good for monitoring that status / health of an app. E.on(..., is most likely the right place to hook in, because it is Espruino specific but not a hw pin / signal thing.

[gfwilliams]

Posted at 2017-09-12 by @gfwilliams

In my case it was a lot of human readable data and thus quite verbose

It is automatically executed when you run Modules.addCached - so your original verbose text version will no longer exist in memory. I'd check process.memory().usage and make sure you're actually freeing yourself a lot of memory and not just making your life difficult:

This is done on a linux-based Espruino so the memory usages might be different, but you get the idea.

>Modules.addCached("foo","/* lots and lots of text here */exports.hello = function() {};")
=undefined
>process.memory().usage
=32
>foo = require("foo")
={ 
  "hello": function () {}
 }
>process.memory().usage
=33
>Modules.removeAllCached()
=undefined
>process.memory().usage   
=32

Removing the module from the cache saves just one memory block - the one with the module's name in.

[espruino-discuss]

Posted at 2017-09-13 by @allObjects

I hear what you are saying... Perception is not always 'Reception' - last but not least because you made Espruino much more memory efficient. - I'll go back and provide feedback comes time to touch on that subject again.