You are reading a single comment by @fanoush and its replies.
Click here to read the full conversation.
-
Thanks for that heads up. I have tested that the return value from E.getAddressOf is not 0, and I still have to upload to file for it to work. Mb its related to that old post I made about the interpreter uploading line by line idk, I'm trying to think how it can go wrong here, its essentially a call to
E.NativeCall(offsetInBlob, funcTemplate, binaryBlob). Thinking...Btw: Whats really annoying/strange is that if you add some random lines of code, like eg. adding
print("a")into the function, it magically starts working. So such tiny irrelevant edits contribute to the crash (when running via ram)...
d3nd3-o0
@fanoush
did not have time to test your code but in general there is garbage collector and memory defragmentation done from time to time so the address of variables in memory may change, also the
E.getAddressOf(xxxx,true)may return zero if the variable data is not a flat block of memory (both arrays and strings can be fragmented).SO you should test the address for zero and better allocate flat string via E.toFlatString (or E.toString in older versions), there is also E.toArrayBuffer to convert such flat string to array.
Passing by reference makes better sense when the array is larger (and flat) otherwise passing by value is simpler/faster.
You can use
trace(variable)to see what it is made of. If it is not backed by flat string I am guessing that it can freely move in memory when garbage collection comes.You can use peek8/16/32 to see if the address really points to expected data.