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

hedyorg / hedy

Hedy is a gradual programming language to teach children programming. Gradual languages use different language levels, where each level adds new concepts and syntactic complexity. At the end of the Hedy level sequence, kids master a subset of syntactically valid Python.

https://www.hedy.org

European Union Public License 1.2

1.3k stars 285 forks source link

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

Closed rmagedon97 closed 3 months ago

rmagedon97 commented 3 months ago

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.

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

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

jpelay commented 3 months ago

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 commented 3 months ago

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 commented 3 months ago

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 commented 3 months ago

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.

mergify[bot] commented 3 months ago

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[bot] commented 3 months ago

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).