support open files relative to script url parameter

[stepansnigirev]

If script=... parameter is provided to the editor, the simulator will try to open resources with the same path.
Example:
https://stepansnigirev.github.io/sim/?script_startup=https://gist.githubusercontent.com/stepansnigirev/d360caaca643a17989b1b41ceef417d1/raw/init_script.py&script=https://gist.githubusercontent.com/stepansnigirev/87032c693fd12eeb9dfd219535630691/raw/page.py

This page is loading the license content from the file stored in the same gist.

I also commented out print statements in imp.py as in my build I had an error that sys.stderr is not available.

[amirgon]

@embeddedt, @pmp-p - Could you review?

[embeddedt]

We now have this line duplicated in every branch of the if statement. Can we consolidate these duplicated portions into a static function?

[stepansnigirev]

Oh, you are right! I will refactor.

[pmp-p]

the changes to file.c make local files a priority, it's a caching behaviour instead of filesystem implementation :

• caching behaviour would need more tests to be efficient.
• That makes it impossible for user to override firmware prebuilts files.

regarding imp.py : i'm against suppressing file open logs in browser console (stderr), chrome is already hiding emscripten stderr in the "android way" ( chromium does not) and i'm wary of that.

[stepansnigirev]

regarding imp.py : i'm against suppressing file open logs in browser console (stderr)

Ok, I will return it back. I just need to figure out why my mycropython is missing sys.stderr...

[stepansnigirev]

the changes to file.c make local files a priority, it's a caching behaviour instead of filesystem implementation

I was doing it to make sure that if the user opens the file and writes something to it, reading it will return him what he wrote.
If we will prioritize remote files over local we will always get the content of the remote file even if we wrote to this file localy.
Should we then consider these files as read only and return file access error if the user is trying to open it in write mode?

[pmp-p]

Should we then consider these files as read only and return file access error if the user is trying to open it in write mode?

i think it's safer to always consider local filesystem as read only, and never assume one can write anywhere without an browser/user-auth at some point ( storage size is already restricted on some browsers because in fine you are writing to a ramdisk without knowing how much space is free).

I was doing it to make sure that if the user opens the file and writes something to it, reading it will return him what he wrote.

that's a good idea but maybe it need some "this file is a product of "copy-on-write"" flag to set priority over the real up2date (remote) file.

[stale]

This issue or pull request has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[embeddedt]

@stepansnigirev @pmp-p Was there any consensus on the points raised above? Does this PR need further refactoring?

[stepansnigirev]

Yes, it needs further refactoring. I failed to compile emscripten port with warnings in stderr back then and now I don't have time to continue working on this... I think it's better to close this pull request for now. Maybe someone else will find time.

[embeddedt]

Okay, no problem. Hopefully, someone takes an interest in completing this in the future! It seems that the main issue was fixing the issue with stderr.

As a note to future readers: I did make some changes to stdio handling since this PR was last worked on so that may no longer be an issue.