Catch a syntax error when parsing an input file with the --stay-connected flag active

[shaggysa]

Most errors are caught by the robot after the program has been sent, but a few will abort the entire program.
While this used to be fine, it can be annoying when the --stay-connected flag is active.

Currently, this only works after the program has been successfully sent once, but I'm open to applying it more broadly. However, getting that to work would probably require a small refactor.

[shaggysa]

I just moved the menu into a function so that I can call it from an except block. Please let me know if there is a cleaner way to do this that I'm not thinking of.

[dlech]

Hi @shaggysa. This got buried in the backlog. For future reference, I personally don't mind a gentle ping if it has been more than two weeks and it seems like I forgot about something.

[shaggysa]

I moved it to a separate function, but I am unable to test it with a robot at the moment. The linter is happy, but I can't guarantee that it will work the way I intended.

[dlech]

Apparently I've done something to mpy-cross that makes it segfault instead of reporting a SyntaxError.

I made some other changes that I just merged to fix a different issue, but it means we no longer get the SyntaxError raised from ModuleFinder, so we will need to reconsider this a bit. But it looks like I will need to figure out what is going on with mpy-cross first and fix that.

[shaggysa]

Apparently I've done something to mpy-cross that makes it segfault instead of reporting a SyntaxError.

Ouch... That seems like a pretty big vulnerability...

I guess let me know if I need to adjust anything to make the cli catch/report it properly once you have that figured out.

[dlech]

OK, the crash is fixed now (you will need to merge the master branch and then poetry install to get the updates).

Because of the other change I made, it will now raise subprocess.CalledProcessError instead of SyntaxError. We can catch this new exception and print the stderr instead of catching the SyntaxError.

It would also be nice if we could get some unit tests for this.

[shaggysa]

Ok, I'll see what I can do about fixing it to work with the new mpy-cross. I haven't really messed with unit testing before, but I can give that a shot as well.

[shaggysa]

Ok, I think I'm catching the error properly now (I was actually able to test with a robot this time). The error seems to always show stdin as the file, which should probably be changed to make it a bit more helpful on multi-file projects.

[shaggysa]

I added a few tests related to the menu, but it'll probably need some major reworking (any possibly some additions) since I don't have any experience with writing unit tests.

The final test I wrote (test_stay_connected_menu_interruptions) appears to be leaking coroutines, but I can't figure out how to fix it.

[shaggysa]

It also appears that a couple of the tests failed on the gh runner. I'll have to look into that.

[shaggysa]

I decided to go ahead and add program-cancelling from the terminal. I decided on a non-signal keypress because I didn't want to intercept a KBI in the case that the "racing" function was not active and I didn't want to worry about double presses cancelling everything. I briefly tried EOF, but it looked like I had to manually re-open stdin every time that EOF was received.

I landed on an invisible PromptToolKit app that listens for the letter 'q'. The letter it listens for can be easily modified if desired.

This should at least partially address #67.

One quirk that I can't seem to figure out is that

{'pybricks.tools'}
{'pybricks.tools'}

is printed on every call to hub.download. I didn't touch that function, and I know that the race_keypress function isn't causing it because it doesn't happen on hub.start_user_program (which uses race_keypress) and it does happen on hub.download standalone (which doesn't use race_keypress).

[dlech]

I decided to go ahead and add program-cancelling from the terminal.

Sounds great. Can we save that for a separate pull request? One feature is enough for one pull request. 😄

[shaggysa]

Alright, fair enough. I moved that to a separate branch for the time being.

It looks like the random printing in the hub.download function is still an issue in the reverted timeline.

shortdemo double-prints "{'pybricks.tools'}", longdemo double-prints "set()", sockfw dobule-prints "{'utime'}", module1 double-prints "{pybricks.parameters}", etc.

The printing occurs prior to the loading bar starting.

[shaggysa]

Ok, the master branch seems to have the exact same issue, so I think that the mpy-cross update has something to do with it.