Time for a new release?

Hi everyone,

As you probably noticed, it's been ages since the last 'official' release - not just of Espruino, but of the Web IDE too.

Things have slowed down a bit as I try and get the Espruino Pico ready, but there have been loads of pretty exciting changes to the firmware. Some of them have been quite big so I needed a while to test them.

I know some of you (@DrAzzy, @allObjects, @JumJum) have been using the latest firmware (either my builds, or @DrAzzy's nightlies). How are you finding it? Do you think it's stable enough for a release? Personally I think it's in a pretty good state right now.

If anyone wants to try it, you can:

• click here
  
• right click on the link named espruino_1v72_espruino_1r3.bin and 'Copy Link Address'
  
• Open Settings on the Web IDE
  
• Go to 'flasher' and paste the URL in under 'Advanced Flash'
  
• Click the button, and you should be sorted!
  
  

Please let me know how you get on - if it all seem ok then I'll do a release.

Had used 1v72... but it is a bit ago. So I missed out on the most recent goodies (the other things will fade...). Will load it and move on with most recent. Should it unexpectedly get weird, I'll let you know. ;-)

What does this mean? Make Press-poweron-release-press boot back into Espruino (this may confuse your OS)

What things are stored as flat strings currently?

The boot thing was if you go into the bootloader by accident, and want to leave. It won't affect the normal Espruino board as you don't replace the bootloader via the normal update process.

At the moment the only things in flat strings are typed arrays and inline assembler/compiled code

any more thoughts?

I guess nobody has found anything horribly wrong or they would have said!

Flat string: continuous memory instead of chained blocks? In other words, when memory somehow fragmented, creation of 'larger' of those typed arrays and assembler/compiled code entities most likely will trigger a garbage collect to get that contiguous memory?

Yes. If it's not possible then Espruino won't actively 'compact' the variables to make them fit (yet). Typed Arrays will just silently fall back to being fragmented, but Native code will fail.

The solution is to allocate your big arrays/native code at the start of your program and keep them allocated - which is good practice anyway.

Ic. Is there a way to find out if created flat or 'fallen back to be fragmented'?

I assume that a compact is not possible because of chosen memory architecture, last but not least saving memory. GC needs forward AND back references and that is pretty expensive.

Is there a way to find out if created flat or 'fallen back to be fragmented'?

You can check manually with trace(var)

I assume that a compact is not possible because of chosen memory architecture

It is possible, and it would be pretty easy to create an 'old->new' mapping on the stack and use that to re-map everything (as long as you left the 'locked' variables alone). It just hasn't been done yet because I don't have as much time as I'd like :) I have to focus what time I have on the enhancements and fixes that matter to most people, and I don't think that the fragmentation will actually be a big issue in most use cases.

It's also important to note that the thing that might fail (native functions) will tend to allocate quite small flat strings - which is extremely unlikely to fail even when the memory is very fragmented.