Steffen

Most recent activity

• Is setting the pretokenise flag advisable?

  in JavaScript • 5 years, 7 months

  

  Glad to hear eval does it :)
  I've actually grabbed your pretokenise.js from EspruinoTools and done something similar already. First the code was not executable because "return" is defined twice, as LEX_R_BREAK and as LEX_R_RETURN. The returns from a function need to be tokenised as the latter one, but the pretokenise routine returns the first one. After obfuscating the token for LEX_R_BREAK (as "XXreturn") everything runs fine.
  The pre-tokenised code uses many of the tokens including class, new, switch/case, try/catch and some bit shift operators.

• Is setting the pretokenise flag advisable?

  @Steffen started

  • 12 comments
  • 4,593 views

  @Steffen replied
• Is setting the pretokenise flag advisable?

  in JavaScript • 5 years, 7 months

  

  Just had a glance at it and it looks neat.
  Currently my Espruinos have a small 'bootloader' set via E.setBootCode (I think I understand now how to tokenise it). It receives strings via TCP and evals them - large strings with class definitions, instantiation etc. Does the code processed by eval get pretokenised, provided the flag is set?

  (side note: I once had a Sinclair ZX81 with 1kB of RAM. The code was immediately entered as tokens.)

• Is setting the pretokenise flag advisable?

  in JavaScript • 5 years, 7 months

  

  Wow, this is pretty impressive.
  From your example I conclude that I can just put E.setFlags({pretokenise:1}); as the first line in the code passed to E.setBootCode and after the next reboot everything in the boot code and all code I upload later gets tokenized. Is this correct? (please say yes :)

• Is setting the pretokenise flag advisable?

  in JavaScript • 5 years, 7 months

  

  It doesn't seem to work from the console neither from the IDE.
  After

  E.setFlags({pretokenise:1})
  function test() {print('Hallo')}
  dump()
  

  function test ... is shown as plain text, no tokens.
  The output of E.getFlags() is

  >E.getFlags()
  ={ deepSleep: 0, pretokenise: 1, unsafeFlash: 0, unsyncFiles: 0 }
  

  Version is 2v02, Espruino Wifi.
  There seems to be something I'm missing.

• Is setting the pretokenise flag advisable?

  in JavaScript • 5 years, 7 months

  

  Sounds good, I'll give it a try. Thanks for the quick reply.

• Is setting the pretokenise flag advisable?

  in JavaScript • 5 years, 7 months

  

  I've stumbled upon the pretokenise flag (E.setFlags({pretokenise:1})) and I'm wondering if it's worth setting it on an Espruino Puck or WiFi.
  As far as I can guess pretokenised JS code doesn't need to get eval'ed anymore, which has the potential to speed up execution significantly.
  Does it accelerate the execution of long running code, or has the code already been pretokenised after a while?
  Are there any gotchas except of readability and changeability of the tokenised code?
  Any comments are appreciated.

  • Steffen
    
    
• Socket onerror callback not honored

  @Steffen started

  • 4 comments
  • 2,531 views

  @Gordon replied
• Socket onerror callback not honored

  in JavaScript • 5 years, 9 months

  

  Wouldn't the same trace information be in the error callback? The advantage of no exception thrown is that you attach the callback once, while one has to do try/catch in all places now.
  I'm fine though with the current behaviour. Espruino is great and pretty powerful!

• Socket onerror callback not honored

  in JavaScript • 5 years, 9 months

  

  Socket instances don't seem to use the attached 'error' listener on error:

  >s = net.connect({host: 'xxx', port: 1883}, print)
  >s.on('error', (e)=>print('EEE',e))
  >s.end()
  >s
  =Socket: { type: 0, 
    "#onconnect": function () { [native code] }, 
    opt: { 
      host: "neptune", 
      port: 1883 }, 
    conn: false, 
    "#onerror": function (e) { ... }, 
    clsNow: true, cls: true, endd: true }
  
  >s.write('x')
  Uncaught Error: This socket is closed.
   at line 1 col 12
  s.write('x')
             ^
  

  Is this expected behaviour?
  I'm asking because in NodeJS, when an error listener is attached, no exception is thrown but the listener called (with the exception message) instead. If Espruino did the same, the last line should read like this:
  EEE Error: This socket is closed. ... (EEE because the listener prints it, then the error.)