Just noticed this, that wasn't apparent as I typed the posts. Traversing backwards, I see the large code chunk is part of a known function named 'dl()' In the history, which I believe is what is uploaded before parsing as block #440 and then again as the string identifier in memory at block #428 that points to the function configured in memory as block #438, made of other linked blocks, it's ID of #437 and the function as a FlatString object at #637
What I would like to do is be able to traverse the trace results and get at block #637 but not knowing the actual function by name. Maybe a traverse the results and list the blocks containing more than 'x' (?ten?) blocks might be a good start.
As typeof trace() returns ="undefined" I'm starting to wonder if it is in fact just a function that prints to the console, values that are extracted under some rules, as I expected "object" to be returned.
'If you paste the whole trace up I could show you'
So, yes please, a small sample to get going would be appreciated.
Incidentally, I'm initially guessing there is a parsing issue when using both embedded individual commented lines and block commented lines within a function whose length spans a large amount forcing a newline char to get inserted which then affects code content parsing during runtime. Just a guess, but ran into a similar situation back in 2017 I just can't reproduce that manually, yet.
What happens in the suspect code file, is an attempt to execute a function roughly 20 JsVars in size when 400 JsVars are available and I get an immediate error/lockup and unable to access the console. Using the above idea, will attempt subsequent test passes inserting/moving this trace read function each time to see what is going on immediately before lockup. This code file pseudo representation is extremely stable until attempting to write a large block knowing there isn't enough memory. Thus, a close approximation to what occurs in the other file.
Also, found this unproven snippet: global["\xFF"].history = []; that was a suggestion to reduce memory, but felt that performing intentional destruction without allowing Espruino to clean up the linked tables, that it is in fact an inproper suggestion.
Espruino is a JavaScript interpreter for low-power Microcontrollers. This site is both a support community for Espruino and a place to share what you are working on.
Part 3
Just noticed this, that wasn't apparent as I typed the posts. Traversing backwards, I see the large code chunk is part of a known function named 'dl()' In the history, which I believe is what is uploaded before parsing as block #440 and then again as the string identifier in memory at block #428 that points to the function configured in memory as block #438, made of other linked blocks, it's ID of #437 and the function as a FlatString object at #637
What I would like to do is be able to traverse the trace results and get at block #637 but not knowing the actual function by name. Maybe a traverse the results and list the blocks containing more than 'x' (?ten?) blocks might be a good start.
As typeof trace() returns ="undefined" I'm starting to wonder if it is in fact just a function that prints to the console, values that are extracted under some rules, as I expected "object" to be returned.
So, yes please, a small sample to get going would be appreciated.
Also, found this unproven snippet:
global["\xFF"].history = [];
that was a suggestion to reduce memory, but felt that performing intentional destruction without allowing Espruino to clean up the linked tables, that it is in fact an inproper suggestion.