• I'm crazy busy the next few weeks gearing up for a conference and a new product launch so I may not get time until after then I'm afraid. If I don't get around to it, maybe you could ping me after that?

  • Gordon, don't bother yourself with my pesky issue, it can wait. I'll ping you in mid/late-November or something. Until then, have a successful conference and product launch.

    Wait, did you say new product launch?? :-)

  • Mon 2019.10.28

    shhhhhhhhh don't let the cat out of the bag yet

    We may not be totally communicating here, as I made assumptions in #28 not knowing whether the data payload was tested on the actual device at that point. (rather than node)

    My observation of 4237 created is greater than 3995 available just popped out. If it was and as Gordon pointed out that Espruino may be creating an additional large string during decoding, you can see my concern.

    Any way to just call half the data payload in a pseudo MIDI All-Call SysEx message call, and then while monitoring free mem, just keep increasing the payload request until the error occurs? This would iron out whether the error is caused internally by the data itself, or an overrun of memory BEFORE Espruino renders the error.

    or are we at a point where the test using node will take less time than writing repetitive try test repeat trials?


    'so there's no 16-bit limitation involved'

    Again, are we communicating re: JsVar usage bottom of page?

    http://www.espruino.com/Internals

    Sixteen was used as a divisor, not a limitation

About