Settings functions causes crash(Fixed by @nopid!)

[SuperPupperDoggo]

UPDATE 2022.06.05 by @Vegz78:
This issue was finally fixed by @nopid for Raspberry Pis!:
microsoft/pxt-arcade#3812 (comment)
Check out the fix already rolled out on arcade.makecode.com/beta here!


@SuperPupperDoggo's original post:
Occurs with the settings blocks and JavaScript/python functions.

[SuperPupperDoggo]

This is really annoying because it makes it impossible to store anything more than a high score.

[Vegz78]

Hi @SuperPupperDoggo,

Thanks for trying McAirpos!

Could you please try to run the game directly from the Linux command line(not inside an X or ssh terminal emulator) and check if there are any differences?
./game_file.elf

The game will hang on exit/reset, and you would need to use the keyboard(default mappings would work for keyboard)/EV_KEY controller with working button mappings, and the correct /dev/input/eventX for "SCANCODES=" directly in /sd/arcade.cfg. You can exit with a combination of CTRL+C and CTRL+D or reboot.

There seems to be some differences in support for extensions between the web similator and compiling on various hardware. Idealy it would be nice also to test and map if there are differences between the uf2 images of games for Microsoft's own RPi image and the .elf file downloaded for RPi Linux(My impression is that they should be the same(contains the same executable code), but the different runtime environments might be at play).

Happy to hear back from you with results, and to see if there's anything I can do, or whether this is on Microsoft's side and maybe a flavor of the differences in support for HW-extensions:
#12

[Vegz78]

Hi @SuperPupperDoggo,
I am wondering whether we can close this issue and conclude that non-working extensions are due to the compilation for RPi hardware @makecode.com, or whether you have testet and made any findings that require further action/a different conclusion?

[Vegz78]

Closing due to inactivity and lacking feedback from the author. Issue unresolved. Suspect that the setting blocks do not compile natively for the RPi from @makecode.com. Encourage the author and others who have similar experiences to open an issue @https://github.com/microsoft/pxt-arcade/issues

[SuperPupperDoggo]

Ok, I'll try that

[SuperPupperDoggo]

How do I unclose issue

[Vegz78]

Ok, I’ll try that

Originally posted by @SuperPupperDoggo in https://github.com/Vegz78/McAirpos/issues/19#issuecomment-883768057

Ok, hope to hear back from you with some results. I will close this issue under same assumption as last time in 5 days if we haven't heard from you.

[SuperPupperDoggo]

I did some testing, and it appears that it doesn't crash if the executable is in the home directory, but if it's in the /roms/makecode folder it does
Edit: The folder permissions appear to be the issue. Creating a PR with a fix.
(Running chmod -R 777 <rom directory> will fix this on existing installations)

[SuperPupperDoggo]

Update: Still seems to happen though...

[Vegz78]

Thanks for looking into this, your quick reply and PR, @SuperPupperDoggo!

It would indeed be in accordance with my intentions that as many as possible of the MakeCode Arcade functions and extensions also should work natively and with McAirpos. But my old basic Unix training from the Airforce makes me a little wary about setting write permissions to groups and others, especially the latter.

Could you please:

1. Check if it could be sufficient with 775,
2. Double-check/confirm that this applies to both RetroPie and Recalbox(the latter launches a tmp copy of every game, because of special Recalbox read-only file system. How about when launching from CLI on a distribution with user pi?)
3. Provide me with an official shared link to a MakeCode Arcade game/program using settings functions which I could compile and test myself, and
4. If possible/you have an idea, provide me with a theory as to why this extended write permission is necessary?(I thought, loosely from memory, that RetroPie/Recalbox launches as pi/user with full permissions, and would maybe like to confer with the MakeCode team about this write permissions need(maybe they could remove this requirement officially instead)).

I am also sorry to inform that I might need a little time figuring out how to handle a pull request, as I am currently only on my laptop and I have only once before done a PR, and that was from your side of the repo... ;-)

Hope to hear back from you again soon!

[Vegz78]

Update: Still seems to happen though...

Ok. Saw this just now.

I would really appreciate, as a start, the link requested in point 3 above, so I, and other minds brighter than me and frequenting the MakeCode corners of GitHub, could help investigate.

PS: Any help from anyone in this matter is really appreciated! -My 10-year-old son is the family's expert using MakeCode, I am just a guy who stumbled over a way to demo his game creations on the big screen for last year's family Christmas dinner... ;-)

[Vegz78]

Hi again @SuperPupperDoggo,

It’s really hard for me to follow up this issue or get a clue about what is wrong or what I might do without testing one of your games using the settings functions you mention.

What do you think?

[SuperPupperDoggo]

Ok, here's a program that uses them:
https://github.com/SuperPupperDoggo/makecode-settings-tester

[Vegz78]

Hi @SuperPupperDoggo,

I am finally back from vacation and just tested an .elf compilation of your program linked to above from the CLI on my RPi4.

I am not really sure what to make of my observations:

1. On my first couple of executions with the regular 755 permissions, the program would not respond to button presses.
2. Then I chmod -R 777 the .elf file and the .elf.data folder, and everything worked ok, with the files test1, test2 and test3 written inside the .elf.data folder
3. Lastly, I deleted both the .elf file and the .elf.data folder, and copied a new version of the .elf file to the makecode games folder with 755 permissions. This time it would execute perfectly and write all three test files into the .elf.data folder.

I really do not know what to conclude from this yet, or what to change. Maybe I could add a function inside launCharc that changes permissions to the .elf.data folder once it is created after the first game launch.

But then again, the .elf games seem to have running processes with the pi user as owner, so it shouldn't really make a difference...

Is there maybe some sort of caching at play here somewhere that I am not familiar with? Do you have any suggestions or know about anyone who might shed some light.

At the moment, i will keep this issue open for further investigation, but I conclude from my tests and your last comment, that your pull request might not be a spot on solution, so I will close it until we find out more.

Looking forwared to hearing back from you(and maybe others) with further tests and working theories!

[Vegz78]

Today I tested again on my RPi4 the same file, but with a different file name and permissions 755 and everything worked fine. I will continue to search for and test other MakeCode Arcade programs utilizing the settings namespace/extension on other hardware and OS'es.

Any new insights from your side or anyone else?

I have also reached out for further help here:
microsoft/pxt-settings-blocks#2, and
https://forum.makecode.com/t/quick-tutorial-on-the-settings-namespace/1013

Hoping to hear back from you soon!

Here is the underlying pxt code, for those inclined and competent to review it and maybe find some answers there:
https://github.com/microsoft/pxt-common-packages/tree/master/libs/settings

[Vegz78]

Ok @SuperPupperDoggo,

I've found 5 more MCA games on the forum that are using the settings namespace and tested on 3 different Raspberry Pis.

I think that I now can make the following conclusions:

1. The settings namespace functions and properties mostly work when running natively as .elf executables on the RPi, but one usually has to run/execute the game 2 times and with the usual chmod 755 all around to ensure that the storage is written properly in the game_file.elf.data folder.
2. Except the settings.exists("string") property, which causes segmentation fault and terminates the games.

A work-around for the 2nd point, for instance in an if statements, could be:
https://arcade.makecode.com/#pub:_816E0X0brPog?nolocalhost=1&compile=rawELF&hw=rpi

Since the 2nd point seems to be a bug in the pxt-arcade compiler itself, I've opened an issue there, which I hope will be resolved some time in the future:
microsoft/pxt-arcade#3812

Here are my the projects that I have tested, which you and others might try, as well:

1. twentieth-stream Treasure on the North Pole(Working):
   https://arcade.makecode.com/#pub:_KRxUjgR1UKXr?nolocalhost=1&compile=rawELF&hw=rpi

2. blocks-leaderboard(Settings extension - Not working):
   https://arcade.makecode.com/#pub:46238-89332-69341-89890?nolocalhost=1&compile=rawELF&hw=rpi
   
   Only using settings namespace, not the extension(Not working):
   https://arcade.makecode.com/#pub:_dH1asvKAaUF8?nolocalhost=1&compile=rawELF&hw=rpi
   
   Using the work-around above, without the exists property(Working):
   https://arcade.makecode.com/#pub:_816E0X0brPog?nolocalhost=1&compile=rawELF&hw=rpi

3. Untitled(Working - image saving):
   https://arcade.makecode.com/#pub:_4xAFW4P8gHF5?nolocalhost=1&compile=rawELF&hw=rpi
   (changed pins.createbuffer to Buffer.create from the original, since RPis do not have the pins namespace...)

4. example(Working):
   https://arcade.makecode.com/#pub:_3uF6WxXu9VX7?nolocalhost=1&compile=rawELF&hw=rpi

5. Stream #88 - MATHS IS FUN(Not working without the above work-around):
   https://arcade.makecode.com/#pub:15706-05354-13916-98714?nolocalhost=1&compile=rawELF&hw=rpi
   
   Using the above work-around(Working):
   https://arcade.makecode.com/#pub:_c7gX7PF84Rge?nolocalhost=1&compile=rawELF&hw=rpi
   
   

With that, I am closing this issue until further notice or pending a fix from Microsoft.