“SyntaxError: invalid syntax” always show on mu-editor at REPL mode with micro:bit

[seiferthan]

Dear creator:

I use mu-editor 1.0.0 on Ubuntu 18.04. When I try to do a very simple calculation such as "2+2"(without ""), the REPL mode always show the error message as follow:

on v1.9.2-34-gd64154c73 on 2017-09-01; micro:bit v1.0.0-rc.2 with
nRF51822

Type "help()" for more information.

2+2
Traceback (most recent call last):
File "", line 2
SyntaxError: invalid syntax

the detail is written on stackoverflow:

https://stackoverflow.com/questions/51509698/syntaxerror-invalid-syntax-always-show-on-mu-editor-at-repl-mode-with-microb

I try to find out answer on internet, but I still can't figure out how and why. Please help me try to handle this problem.

Thank you so much anyway.

[tjguk]

@carlosperate would you know whether MicroPython on the micro:bit allows for this form? (I don't have a m:b nearby to check for myself)

[ZanderBrown]

Also running MicroPython v1.9.2-34-gd64154c73 on 2017-09-01; micro:bit with nRF51822:

Can only assume there is some invisible char or something

[seiferthan]

Thank you, Dear @tjguk and @ZanderBrown :)

I have made some progress on this issue. However, I still have not solved this problem completely.

@ZanderBrown said: "Can only assume there is some invisible char or something". This makes me wonder if it is possible to relate to my input method, input device, or language(locale).

Since I am a Taiwanese, we use Traditional Chinese (unlike Simplified Chinese used in mainland China). In /etc/default/locale, my original settings are as follows:

LANG="zh_TW.UTF-8"
LANGUAGE="zh_TW:zh:en_US:en"
LC_NUMERIC="zh_TW.UTF-8"
LC_TIME="zh_TW.UTF-8"
LC_MONETARY="zh_TW.UTF-8"
LC_PAPER="zh_TW.UTF-8"
LC_IDENTIFICATION="zh_TW.UTF-8"
LC_NAME="zh_TW.UTF-8"
LC_ADDRESS="zh_TW.UTF-8"
LC_TELEPHONE="zh_TW.UTF-8"
LC_MEASUREMENT="zh_TW.UTF-8"

Then, I change the content to be as follow first:

LANG=en_US.UTF-8
LANGUAGE=
LC_CTYPE="en_US.UTF-8"
LC_NUMERIC=lzh_TW.UTF-8
LC_TIME=en_US.UTF-8
LC_COLLATE="en_US.UTF-8"
LC_MONETARY=lzh_TW.UTF-8
LC_MESSAGES="en_US.UTF-8"
LC_PAPER=lzh_TW.UTF-8
LC_NAME=lzh_TW.UTF-8
LC_ADDRESS=lzh_TW.UTF-8
LC_TELEPHONE=lzh_TW.UTF-8
LC_MEASUREMENT=lzh_TW.UTF-8
LC_IDENTIFICATION=lzh_TW.UTF-8
LC_ALL=

Second, I tried to change my Region & Language to be English and United States.

Third, I set my keyboard input method system to be none

Finally, I reboot my system. We can see an interesting result：
If I copy the code from other text editor then paste on REPL mode, it can print correct result, but the words after >>> mark will be strange...

If I try to use keyboard to input directly, it will not repeat the characters, or not respond.

Besides, I can use minicom mode to use REPL, but it still repeat chars....

[tjguk]

I'm not sure what's happening there. I haven't been involved with the remote REPL part of Mu to date, so I don't know what stack of serial-bytes-encoding it's using. Might have to wait until @ntoll can have a look, as he put all that together.

In any case, thanks for doing the legwork to try to narrow things down @seiferthan. Please let us know if you get any more clues, and I hope that someone else on the team might be able to get some insight from what you've shown us.

[ZanderBrown]

As @seiferthan still has issues when using minicom (thus skipping Mu completely) this could be a MicroPython (@dpgeorge?) or even a Ubuntu issue.

I don't know if you have different computer or micro:bits to play with but it could be interesting to see what different combinations do.

[dpgeorge]

@ZanderBrown :

Also running MicroPython v1.9.2-34-gd64154c73 on 2017-09-01; micro:bit with nRF51822:

can you confirm that you actually tried the latest version, and the banner at the REPL was actually:

MicroPython v1.9.2-34-gd64154c73 on 2017-09-01; micro:bit v1.0.0-rc.2 with nRF51822

Your window title of Mu it says "Mu 1.0.0" so I assume you got v1.0.0-rc.2 of the MicroPython micro:bit firmware?

[seiferthan]

Thank you all. I have almost solved this problem. Here are my solutions and possible reasons.
My friend, a hardware engineer told me to try using a kit of linux minicom. We connected micro:bit with PC(ubuntu), and then used the minicom to check the status of connection.

$ minicom /dev/ttyACM0
(if you want to know the port that you connect with micro:bit, you can use a command named dmesg.)
Select the Serial and Port Setup

Check the option Serial Device is as same as the result printed by dmesg. If it is not, change it.
And, the most important, keep the option Hardware Flow Control is YES. I don't understand the principle, but after testing, it is necessary to keep YES.

After above, you can choose EXIT(not EXIT from MINICOM) to enter the REPL mode in minicom with connecting micro:bit. You May can use python coding at the situation, even my console screen still show any character I input while I was keying once...

What I did on next step is TOTALLY POWER OFF my computer. And POWER ON my PC(ubuntu) again.
Miracle happened.
After I TOTALLY POWER OFF and POWER ON my pc(ubuntu) again, I can use REPL mode in MU-editor and minicom without twice-character and other problems.
Please forgive me can not put my ScreenSchot pic because I forgot bringing my micro:bit chip to my office.

However, on my laptop(Debian 9), the way I used as above can work after changing the input method system to en but Chinese input method.

So, I think the two main causes of the problems are:

1.Locale setting and Input method system: We are better to use English locale setting and pure English input methods.

2.Check the Hardware Flow Control is set on YES.

3.After setting all, please TOTALLY POWER OFF and POWER ON your pc or laptop again. DO NOT just logout or reboot.

[carlosperate]

Thank you @seiferthan for the detail report and steps to solve it.

The micro:bit doesn't have hardware flow control pins wired, so enabling the Hardware flow control feature in the application shouldn't make that much of a difference. However, your first point about changing the locale and then rebooting (to make sure the locale is applied correctly) does look to be the main issue.

As Damien has also mentioned (thanks Damien!), that REPL start string looks like an older version of MicroPython than the one included in Mu v1.0.0. @seiferthan Could you try creating a new empty script and flashing that? By doing so Mu should detect it and flash the latest interpreter, and then when the REPL is opened it should print the string Damien showed:

MicroPython v1.9.2-34-gd64154c73 on 2017-09-01; micro:bit v1.0.0-rc.2 with nRF51822

If that doesn't happen, is it possible you have included an alternative runtime in the Mu settings?
If you click in the cog at the bottom right corner, and go to the micro:bit tab you should see that option.

[ntoll]

Epic debugging here. Thank you, glad it's been solved.

[carlosperate]

@ntoll, I would argue this hasn't been solved. It shoudn't be a requirement for Mu to change the operating system locate for the REPL to work.

@seiferthan With your original locale, were you able to use the Python3 REPL without issues?

[ntoll]

@carlosperate I'm not sure I follow. Mu has no control over what the user has set, right..? Since we can't do any more, but point users who have the same problem, to this GitHub issue, then what more can we do (except close it)..?

[carlosperate]

Yes, Mu doesn't have any control on the user-set OS language and encoding, but if there is an issue with unexpected encodings that stops the user from using the REPL, then perhaps there is something Mu can do to detect this and do any conversion required.

The repeating characters in the REPL could be an issue with MicroPython, there was an issue in this area already fixed a little while ago, which is also why we'd like to know if the user is using the RC2 version in their micro:bit (based on the REPL opening string it looks like an older version than that shipped with Mu v1.0.0).

However, the fact that writing the text on an editor, then copying it and pasting it into the REPL and getting the right result would suggest that there could be a problem on how Mu is serialising the user input.

[ntoll]

@carlosperate but cut and paste into the REPL is exactly the same as typing the commands in with a keyboard. My guess is if you're pasting 2+2 you get just 2+2. However, if you type 2+2 in the context described at the start of this issue, then, as we've discovered, more than just 2+2 is getting sent.

I'm not sure how Mu is supposed to detect such a problem? The best, easiest and simplest thing for us to do is log this somewhere in the documentation so it's easy for people to discover.

If you're asking for Mu to detect invisible characters, then you're likely advanced enough to know how to follow the instructions kindly provided above. If we try to solve this problem in code then we're adding complexity. That ain't gonna happen, ergo this issue should be closed. ;-)