-
Hi @Gordon, I agree that if RESIZABLE_JSVARS is not stable, and until it is, the default builds should not use it, but I would definetively suggest to leave it there so that it can be compiled directly as an option from the main branch. Otherwise keeping it up to date and bring it up to stable would be a nightmare.
Just one question : I understand from your comment that it is not really working in LINUX ? Regarding "flat string support", do you mean that not everywhere in the code strings are accessed thorugh iterators ? (sorry if this is a naive question).At least a couple of my code changes are bug fixes for the existing LINUX RESIZABLE_JSVARS part and should anyway be applied. What is the best way to get this done?
Regarding the "variable cache" branch, it is a different topic as I understand it in your comment : RESIZABLE_JSVARS leaves as much heap as possible free when not used for JSVars, and "variable cache" would allow (as you speak of flash cache) to have more JSvars than would fit on RAM. They are two related things, but different in approach and implementation (and complementary to each other in some way).
By the way, wouldn't this kind of "live" jsvar storage in flash kill it really fast ? (too many refresh cycles) I rendered one ESP8266 unusable by leaving it only one night in a reboot cycle that wrote to the system config area at every reboot.
You are reading a single comment by @Gordon and its replies.
Click here to read the full conversation.
Pedro
@Gordon
It'd be worth checking that the firmware update over WiFi can still function in the 1MB/1MB config
However as I said above, you can potentially execute JS directly from flash, so if there were a way to write larger JS (eg in chunks, or with the bootloader) then it could be an option.
Wrt RESIZABLE_JSVARS - it's fun to play with, but I think it'd be a huge mistake to make the default builds use it. As I said above, the problems with flat string support could really trip people up - not to mention issues with garbage collection (I'm not sure when that happens currently).
There is a branch for 'variable cache' which IMO would be the most exciting if it had a little work done on it. It would use the RAM only for most-used variables, and would journal the rest in flash - giving you potentially 65000 variables.