Espruino 1v95 released!

I've just released Espruino 1v95, with a whole bunch of extra changes:

Regular Expressions

They're here - finally! On all official Espruino boards (and many others, if there's enough memory).

While it's not 100% full support, it's enough for the majority of things, with String.indexOf, String.split, RegExp.exec and crucially String.replace - even with the ability to specify a function as the replacement.

>"Hello world".replace(/l/g, function(match,idx) { return "[L"+idx+"]"; })
="He[L2][L6]o wor[L15]d"

Fast File IO

• Added E.setFlags({unsyncFiles:1} which doesn't sync the file to the SD card after each write - it's much faster
  
• Filesystem API now uses flat strings (avoiding the 512 byte copy for each call)
  
• Increase default internal SD card bitrate to 4MHz (from 100k) - eg the Original Espruino
  
  

Other Additions

• Added ES6 Object.assign
  
• Puck.js gets a bump in variables from 2000 to 2500
  
• NRF.setScan automatically decodes service and manufacturer data packets now
  
• NRF.findDevices aggregates multiple advertising packets from the same device if they contain different information.
  
• Add E.errorFlag event to allow JS to respond to internal errors
  
• ESP8266 can now use GPIO16
  
• ESP8266 and ESP32 now support UDP with dgram thanks to @opichals awesome work, and official Espruino boards will be able to support it for AT command devices (eg ESP8266/Espruino WiFi) when the libraries are updates
  
• The REPL now outputs non-numeric elements in arrays
  
• digitalWrite/Read will now call .read on an object if it is passed in. This means you can now use port expanders with most Espruino libraries!
  
• Added E.getAddressOffor super low-level work - you can get the actual address of the variable's data in RAM for things like DMA
  
• Manufacturer Data can now be specified with setAdvertising in Puck.js (and we have an official Puck.js manufacturer code - 0x0590)
  
• You can now overwrite Puck.js's memory protection with E.setFlags so you can write wherever you want
  
• E.HSBtoRGB can now output as [R,G,B] for neopixels.
  
  

Improvements

• nRF5x boards like Puck.js can now run UART reliably at 115200 baud, and will work connected to ESP8266 or GSM/GPRS
  
• Exception/error reporting is a bit tidier now
  
• We not use the Esc[J VT100 code when cycling through command history (much faster REPL on low bandwidth connections)
  
• JSON.stringify for arrays is faster
  
• Added support for negating pins in software (eg. buttons/LEDs), for boards like NRF52832DK
  
• Bluetooth LE events (specifically promise completions) now use the event queue - removing the dreaded MEMORY_BUSY message
  
  
  

Bugfixes

• Fix a memory leak in tab completion
  
• Commands that previously didn't work correctly with sparse arrays now do
  
• Fix a memory leak when allocating DataViews, which fixed a memory leak on BLE notifications
  
• net/http .listen now return the server instance (like node.js)
  
• Fixed lexing of '/*/' as a complete block comment
  
• E.HSBtoRGB to wraps 'hue' value properly
  
• Remove spikes when changing pin state using digitalWrite
  
• E.setBootCode() (without an empty string) now works
  
• Thanks to @JumJum and @Wilberforce ESP32 setWatch now works correctly
  
  
  

Dang, thats some good shit!

So excited to see this; I was just about to go on an Espruino f/w updating binge around my room too, so it's great timing on that front too. One thing though - did you mis-read your calendar? It's the 15th, not the 25th - Christmas isn't for another 10 days...

Timing is so perfect for the ESP32 setWatch fix (that issue kinda made the ESP32 an incomplete platform) - one of my top priorities tonight is/was to load something onto an ESP32 on my new prototyping breakout board and make sure I didn't botch anything so I can put them up for sale.

What was the issue with the spikes while changing pin state?

Add E.errorFlag event to allow JS to respond to internal errors - does this mean that we could, say, react to these internal errors by rebooting the Espruino with load()? If so, that's a great way to proof it against jsvar leaks and the like.

How does unsyncFiles work? If we're not syncing it to the SD card after each write, how and when does it decide to actually sync the file to the SD card?

Now, does anyone know where I can download a wetware update to add support for writing regex's? I've always found regex's very hard to write... ;-)

did you mis-read your calendar? It's the 15th, not the 25th

I know... I was tempting, but if I messed something up I didn't want to spend boxing day hunched over a laptop trying to fix it :)

What was the issue with the spikes while changing pin state?

If the pin was an input and hadn't been previously set - but then you wrote 1 to it then the pin would be set to an output (outputting 0) before it output 1. @allObjects found it. Most people wouldn't have noticed and it was easy to work around with pinMode, but it's one less thing to trip people up :)

E.errorFlag - does this mean that we could, say, react to these internal errors by rebooting the Espruino with load()?

Yes, absolutely! It'd definitely be useful for things like out of memory.

To be absolutely sure, the watchdog timer could be used as well, but it's another handy thing to be able to check.

How does unsyncFiles work? If we're not syncing it to the SD card after each write, how and when does it decide to actually sync the file to the SD card?

It syncs when you close the file, or you can also flip the flag off and write something, and that'll sync it as well. There's no difference to fs.writeFile and fs.appendFile, it's just when you write to something opened with E.openFile that it takes effect.

@Gordon, amazing L_ E__ A____ P________ S!

...can we soon expect also the version number to leap to 2.0+? - A minor > 100 and all the major steps that Espruino made since the 50' I'm with it, 2.0 is more than justified. If you are worried that 2.0 will invalidate dwarf 1.0, it does not: 2.0 is still true to the version 1.0 paradigm shift of making IoT accessible as count to 3 while leaping ahead in front of everything else available with its introduction of event drivenness: Espruino *makes* IoT as easy as 1 2 3! ...

Espruino *is* IoT as easy as 1 2 3!

@DrAzzy, can sh.t ever be good?... I don't think so... but I guesss I understand what you want to say: good things should 'hit as hard as' - or even harder as - the real sh.t does when it hits the fan (of a jet engine... not just a house fan).

You can now overwrite Puck.js's memory protection with E.setFlags so you can write wherever you want

...expecially the ...wherever you want and send it to puck nirwana... final olympic hockey goal/score! ...Stanley Cup?

Big thanks, I'm only eager to use this new version which seems much faster. But on ESP8266, strangely, save() now erase 6 of the first free flash pages (only 1 on v1.94, 0 on v1.93), even when I send a short code. This leave available only 5 of them under 1mb, too few for my custom modules needs, still too big to be included with require and sent with the main code (not more than 10ko total). Aren't we supposed to be able to place code in these pages ?

@Polypod maybe you could ask on the ESP8266 forum about this? I haven't personally changed anything to do with ESP8266 memory.

@Gordon, thanks for your reply. Finally v1.95 worked for me perfectly when I switched to package espruino_1v95_esp8266.tgz, I can finally run it with all my modules. The problem was only with package espruino_1v95_esp8266_4mb.tgz. I'll ask about this in the ESP8266 forum.