Change main filename to run next

[tannewt]

Add the ability to set the next main filename before triggering a reload. This can be used to switch between games on a system or between memory heavy animation scripts. https://forums.adafruit.com/viewtopic.php?f=60&t=139041

[kevinjwalters]

My similar discussion: https://forums.adafruit.com/viewtopic.php?f=60&t=150016 (#737 gets mentioned in that).

[robertgallup]

Mentioned this awhile ago on Discord, but thought I'd chime in here.

I'm working on a tutorial and have a bunch of example scripts all stored on the CIRCUITPY drive. Switching between them requires manually renaming or copying files to code.py/main.py. This gets tedious so I wrote a menu script that lists the available other scripts on the CIRCUITPY drive. Selecting one runs it using Import. This works, in general. The problem is that larger scripts can overflow the heap when imported even though they work fine on their own.

There might be a more general solution, but for me, it would be great to have something like sys.exit('next.py') that would restart the vm with the named script. No need for this to disrupt any existing behavior. e.g. ctrl-D from the REPL and sys.exit() could still load code.py/main.py by default.

The way this would work for my case is that the menu would be code.py/main.py and use sys.exit('next.py') to run the chosen script. All the example scripts would act normally, you'd use ctrl-C,ctrl-D to restart the menu, no special hooks to get back to the menu. Of course, if you wanted to chain several scripts, each one could use sys.exit('next.py').

[deshipu]

I have exactly the same use case for my game consoles.

[dhalbert]

We would not enhance sys.exit() for that purpose, because we aim to be a subset or the same as the CPython version. But we could certainly add it to supervisor, such as adding an arg to supervisor.reload().

[robertgallup]

Adding it to supervisor.reload() would be perfect.

[tannewt]

Note that the hardest part of this is storing the filename because the heap gets reinitialized before running the file.

[robertgallup]

Good point. Is this same issue handled in supervisor.set_next_stack_limit()? Or, is it a different problem?

[tannewt]

Ya, it is similar but stack size is a fixed size so it's easy to just statically allocate it. We could simply have a char* array with a limit to start. If folks hit the limit often we could either increase it or make the allocation dynamic.

[robertgallup]

Ah ha. I see the issue. Picking a good limit is key (though, no matter what you pick, someone will have a use case for more :) ).

[dhalbert]

If the heap memory is not touched when the VM shuts down, then I think the following would work. It relies on being to able to use the stale data in the old heap.

1. Copy the location of the string object that is the filename into a pointer variable at a fixed location
2. Reload exception throws us back to somewhere in main.
3. VM gets shut down. Loop back to restart VM
4. Before heap is re-initialized (is it zeroed?), examine the string object pointed to. Allocate an array on the stack large enough to hold the filename, and copy the filename to there.
5. Initialize the heap.
6. Pass the filename on the stack to run_code_py().

[deshipu]

I just realized there is one more piece of the puzzle missing — after the code finishes running, it would be best if the device restarted again, with the default main.py this time, instead of dropping into the REPL. I wonder if this is too much to ask for an obscure use case, though.

[dhalbert]

@deshipu If each of the alternate programs did a supervisor.reload() with no args when it's done, that would just happen. Are you thinking that is an extra piece of code that the alternative programs wouldn't have?