💻 Implemented "is" and sleep command for Micro:bit for level 2

[rmagedon97]

Added the assignment to a variable from level 2 in Hedy to Micro:bit
Added sleep functionality for Micro:bit

How to test

Follow these steps to verify this PR works as intended:
Open Hedy and choose level 2. Assign a variable and then print it. This will generate a hex file that can be uploaded here:
https://python.microbit.org/v/3/reference.
You should see the correct python code after you upload the file.

• Contains one of the PR categories in the name
• Describes changes in the format above
• Links to an existing issue or discussion
• Has a "How to test" section

If you're unsure about any of these, don't hesitate to ask. We're here to help!

[boryanagoncharenko]

As agreed during the meeting with Teodor:

• I am converting both PRs to draft, since some changes are needed
• All added whitespacing needs to be removed from the microbit transpiler and added where the program is put together with the while True: cycle.
• Tests need to be added for the commands that are changed (the extent depends on the overall status of the project)

[jpelay]

While looking at your code I see that you generate a file in the backend and then send it to the frontend, where it downloads. What would happen if there are concurrent calls to the endpoint? I'm pretty sure that will cause either slowdowns or race conditions. I think that a much better approach would be to send the transpiled code to the front-end and generate the file directly in the user's machine, this will prevent having to write to disc for every call.

[Felienne]

While looking at your code I see that you generate a file in the backend and then send it to the frontend, where it downloads. What would happen if there are concurrent calls to the endpoint? I'm pretty sure that will cause either slowdowns or race conditions. I think that a much better approach would be to send the transpiled code to the front-end and generate the file directly in the user's machine, this will prevent having to write to disc for every call.

Do we do that for dst files too (if not, that is probably a wise idea!) Maybe we can combine this into one part of the code that does that?

[jpelay]

Do we do that for dst files too (if not, that is probably a wise idea!) Maybe we can combine this into one part of the code that does that?

I just checked and for those files we generate a unique random filename, this would also prevent race conditions in this case!

[rmagedon97]

While looking at your code I see that you generate a file in the backend and then send it to the frontend, where it downloads. What would happen if there are concurrent calls to the endpoint? I'm pretty sure that will cause either slowdowns or race conditions. I think that a much better approach would be to send the transpiled code to the front-end and generate the file directly in the user's machine, this will prevent having to write to disc for every call.

That's a good idea. I basically did the same was as we are doing the files for the turtle. I had some issues converting the file to hex that's why i used he same name for the file. After your comment i'll try to use a random file name.

[rmagedon97]

fixed

[mergify]

Thank you for contributing! Your pull request is now going on the merge train (choo choo! Do not click update from main anymore, and be sure to allow changes to be pushed to your fork).

[mergify]

Thank you for contributing! Your pull request is now going on the merge train (choo choo! Do not click update from main anymore, and be sure to allow changes to be pushed to your fork).