add 10KB of RAM to your esp8266

Want more RAM? Try this build:
https://s3.amazonaws.com/s3.voneicken.co­m/espruino/espruino_1v81.tve_esp8266-fla­sh-strings_662306b_esp8266.tgz
This does not add more JS variables, it adds more heap to be used for network connections and stuff like that. Before this improvement I couldn't make an HTTP GET complete, now it's no problem. The extra RAM is gained by moving string constants to flash, so some performance impact is to be expected. (Don't ask me to quantify.)

Well, I can now run 5 concurrent HTTP GET requests and not crash, that's progress :-). I can also run 100 successive GET requests and they work. Trying to run 1000 has one fail at some point, but doesn't crash. We have progress but we ain't there quite yet...

Wow, that's definitely looking a lot better! So presumably that means there are no memory leaks when using HTTP GET then - you only have 1000 vars so even if it lost 1 each time it should have failed if there was a problem :)

Tested the flash-strings version. Everything is running fine.
During testing of http-server the logger below was added.
freeHeap was always between 10500 and 12300.
freeMemory was always between 200 and 350.
http-get is not a part of my test, will add this later.

BTW, there was a discussion about large(1400 ?) and small(576 ?) buffers. Which one is used in your build ?

setInterval(function(){
  console.log(srv.ESP.getState().freeHeap
                        ,process.memory().free);
},200);

@tve great stuff!

Some more testing :-)
In my http-server an Url was added http://198.168.178.26/get?host=184.168.1­92.49&path=/
Server uses this information to get data from that server and forwards this to browser.
This works fine, heap was more than 10000 all the time and free memory about 200.
Next opened a websocket on my server and then called the url again.
This ended in a desaster, could see memory going down and got Execution interrupts and after that tons of errors. Even a HW-reset did not help anymore, had to reflash.
Tried to reproduce this error by:

• open an url that causes a delay on server for about 10 secs bevor sending response.
  
• during this 10 secs called another page, everything fine
  
• still during this 10 secs called the url mentioned above (the get url) and could see, heap going down to 9800, but memory going down to 78 bevor Out of memory, followed by tons of Execution interrupt. Good news, this time I did'nt have to reflash.
  
• did some more testing and got out of memory and execution error often, but couldn't reproduce the flash corruption
  Hope, this is of some help :-)
  

Would it be possible to place builds here:

https://github.com/espruino/EspruinoBuil­ds/tree/master/ESP8266

I'm thinking that as long as a build is consistent with what is in Github, then we should be good.

Later ... build placed at ...

https://github.com/espruino/EspruinoBuil­ds/tree/master/ESP8266

BTW, there was a discussion about large(1400 ?) and small(576 ?) buffers. Which one is used in your build ?

I'm using the 536 MSS libwip, i.e., TCP packets have 536 bytes max. Due to the way the Espruino sockets library and the esp8266 SDK interact there are a number of buffering issues so I think that a smaller MSS at the expense of some top-speed is worthwhile. We will be trading some of the RAM gained in for extra features and perhaps more JsVars, so I'm sure it will get tight again...

Yes, 536 MSS is definitely the way to go! As things currently stand, Espruino's never going to fill up even those packets.

As far as builds go, I'll include the binary in the download bundle and on the Espruino site itself. I still need to polish http://www.espruino.com/binaries/travis/­ but when that is done with symlinks to the latest build I think we should put builds there and retire EspruinoBuilds - so it's then the same as every other board.

I looked at doing GitHub uploads from travis, but as @tve said it's a bit of an abuse of GitHub, and it also seemed a bit awkward to do.

Cool, can't wait. In the end, for me the litmus test is to be able to look at a message like http://forum.espruino.com/conversations/­278147/#comment12647395 and see something like 1v82.627 Copyright 2015 G.Williams and then be able to go and (a) download the same version as the user and (b) identify the exact commit at which this was produced. (I don't think the current build number lets you do this, a travis build number probably a bit more easily.)

Yes, maybe it's actually better for us to put the commit hash directly in the Espruino startup screen. After all, it's reported in process.env.GIT_COMMIT, I guess for non-release builds it could just be shoved in there?

And the latest builds are now at: http://www.espruino.com/binaries/travis/­master/

Note: ironically Espruino and Pico builds won't work out of the box, because when flashed to the board they need offsetting by the bootloader size (16384 on the Pico, and 10240 on the Espruino board).

@Gordon Can you clarify the last post? Are you saying that for ESP8266 users, the latest build as build by Travis can now be downloaded at the URL provided above. Does this mean that should now be where we point end users to obtain the latest build? If that is the case, then we probably need to shutdown EspruinoBuilds to reduce the sources of confusion.

Yes, that's correct - at that link there will be the absolute latest build of Espruino available.

However that may not be what everyone wants, as it could be a bit hit or miss whether it works or not. It might be better to keep EspruinoBuilds going for a bit with a Neil-curated version of Espruino for the ESP8266.

I think when I do the next full release (probably 1v84 - I plan to rush 1v83 out now because of an issue with the Pico's 1v82 firmware) I'll stick ESP8266 in the downloads and get the Wifi class documentation pulled into the Reference - and then we could retire EspruinoBuilds - because there'll be 'stable' build available, and a proper 'release'.