Is it really necessary to Ctrl-C on connect?

[espruino-discuss3]

Posted at 2015-10-29 by nailxx

Hello!

I have a saved program that sends some data from Espruino to PC via console.log every 100 ms. It works fine until I try to connect from IDE after the board reboot. Once powered up the board begins to do its job every 100 ms and when I connect it says “Ctrl-C while processing interval - removing it”. And as it said the scheduled job is cancelled.

The underlying reason is \x03 character (Ctrl-C) that IDE sends once connection established:

---> "\u0003echo(0);\nconsole.log("<<"+"<<<"+JSON.stringify(process.env)+">>>"+">>");\n"

OK, it is necessary to check out process.env to setup IDE properly but is there any reason to start with \u0003 in this case?

[espruino-discuss3]

Posted at 2015-10-29 by @gfwilliams

Yes, I can see that's annoying. If someone's left something on the input line, Ctrl-C clears it off (as well as breaking out of a loop if someone's code was in one), so it is often needed.

If you enter a few characters before you disconnect, when you reconnect do you get the same problem? If I changed the Web IDE to send a space before the Ctrl-C it might magically fix it?

The other thing you could do (if you just want to read data from USB with the Web IDE but don't want it breaking things), is to move the console away from USB on startup. For instance you could do:

Serial1.setConsole();

You'd then have to change your console.log(...) to USB.println(...), but whatever the Web IDE then did, it wouldn't be able to mess up your program's execution (until you explicitly moved the console back with USB.setConsole())

---

Posted at 2015-10-29 by nailxx

Ah… I see the reason, thank you.

If you enter a few characters before you disconnect, when you reconnect do you get the same problem? If I changed the Web IDE to send a space before the Ctrl-C it might magically fix it?

No few chars doesn't fix this. However looking at jsinteractive.c I can't understand why. Looks like jsvIsEmptyString(inputLine) always true… I need to inverstigate deeper.

---

Posted at 2015-10-29 by @gfwilliams

Hmm, that's a strange one - it works on the build I have here... If I do:

setInterval("",100);
blah [no newline]

And then hit Ctrl-C it's fine. It only breaks out of the code when I hit it a second time when the line is clear.

If I do setInterval("for (var i=0;i<10000;i++);",100) it'll break out first time around though, because the function has taken a long time to execute and it thinks you want to debug it.

It's a hard thing to get right - ideally if you've done something that's spamming the console with text or is stopped, Ctrl-C needs to break out of it... But then it's also frustrating to accidentally kill one of your tasks.

If there's anything I can do to make it a bit more intuitive, it'd be worth it.

edit: You'd need at least 1v81 though, I changed the logic quite recently.

---

Posted at 2015-10-29 by nailxx

I have github’s master. And, yes, the behavior is the same. It clears line for the first Ctrl-C and interrupts for the second. That's fine. What I cant understand is why if I ever add leading space to:

// string adds to stop the command tag being detected in the output
Espruino.Core.Serial.write(' \x03echo(0);\nconsole.log("<<"+"<<<"+JSON.stringify('+expressionToExecute+')+">>>"+">>");\n');

…I always get setInterval interrupt once connected.

The only reason to have \x03 here as you've said is just to ensure that the line is clear. Right? And if we add some leading trash it should never lead to interrupt. If it should work like this there is a bug somewhere. I can try to find it.

---

Posted at 2015-10-29 by nailxx

BTW, if I try this:

Espruino.Core.Serial.write('ffff\x03echo(0);\nconsole.log("<<"+"<<<"+JSON.stringify('+expressionToExecute+')+">>>"+">>");\n');

I get:

Uncaught ReferenceError: "ffffecho" is not defined
 at line 1 col 1
ffffecho(0);

Someone processed \x03 without clearing leading characters ffff.

---

Posted at 2015-10-29 by nailxx

Well, the root is here:

void jshPushIOCharEvent(IOEventFlags channel, char charData) {
  if (charData==3 && channel==jsiGetConsoleDevice()) {
    // Ctrl-C - force interrupt
    execInfo.execute |= EXEC_CTRL_C;
    return;
  }
  //...
}

If the board wasn't idle and didn't consume IO buffer, \x03 will be just extracted out of context. And next time idle routine will try to handle IO buffer the first thing it will see is EXEC_CTRL_C flag. No matter that there were characters before the flag was set. These chars will be processed later.

First possible solution is to add some magic to jshPushIOCharEvent so that \x03 will clear buffer. Not sure it's a good idea.

A quick fix that works is to send some trash chars, wait, and then send the expression that starts with \x03. I've made a pull request with this fix.

---

Posted at 2015-10-29 by @gfwilliams

Ahh - thanks! Yes, I didn't think of that...

Ctrl-C has to break out of a running loop, so it can't be processed on idle along with everything else. One potential fix is to make the IDE clear lines only on CTRL_C_WAIT - which is what gets set if CTRL_C is set and then not processed for 0.25 sec