Need to create mutiple instances of scripts and output elements on the same page

[cyust]

Thank you for working on this project! I am interested in using it in an educational setting. After some experimentation, I believe there is at least one architectural issue that would block us from using it in a production environment. Primarily, a typical "lesson" web page will need to display multiple, independent examples on the same page.

If I understand the current setup correctly, turtle-pyscript is hard-coded to display output in a

with fixed ids, e.g.:

    <div id="tps-game-area">
        <div id="tps-game-box"> </div>
    </div>

A <script> element containing code will then automatically interact with those well-known divs.

What we'd need is the ability to add multiple <script> elements and output

elements on the same page, with each script independently interacting with its own output div. Perhaps something like this...

    <div id="tps-game-area1">
        <div id="tps-game-box1"> </div>
    </div>
    <script type="py" something="... some way to target this script to tps-game-area1 for I/O...">

code for instance 1...

    </script>

    <div id="tps-game-area2">
        <div id="tps-game-box2"> </div>
    </div>
    <script type="py" something="... some way to target this script to tps-game-area2 for I/O...">

code for instance 2...

    </script>

...or even better, perhaps convert from id to class, then have each script placed within a parent

and automatically work with that

, e.g.:

    <div class="tps-game-area">
        <div class="tps-game-box"> </div>
        <script type="py">

code for instance 1...automatically interacts with the parent tps-game-area

        </script>
    </div>

    <div class="tps-game-area">
        <div class="tps-game-box"> </div>
        <script type="py">

code for instance 2...automatically interacts with the parent tps-game-area

        </script>
    </div>

In our experimentation, copying multiple <script> elements within the same page meant that each script element tried to use the same

with the unique tps-game-area id. We also received errors that indicated multiple scripts running on the same page would interfere with each other (e.g. errors from screen.register_shape() running twice).

Possibly, there are already workarounds we didn't catch for these issues - would love to see a sample HTML page demonstrating multiple instances if available :)

[DavidLeoni]

Hi, thank you for your interest in the project!

Currently we envision a couple of use cases:

a. Showcase untrusted scripts in a gallery

Typically in this case the teacher wants to place student scripts in a gallery.

To prevent conflicts, each script must have its own interpreter.

I guess the only really sane solution is to use iframes (especially if you have to handle lots of projects), there is an example in the testing page although it's unpolished. Also, if you have many scripts loading times may become a problem and then you may be forced to choose pyodide / micropython with different trade offs according to your needs.

b. Showcase trusted scripts in a page in a single interpreter

Typically in this case we may have a teacher who wants to showcase his scripts in a page (not necessarily develop/debug)

For efficiency reasons he might want to share the interpreter between scripts.

As you noticed this is not currently supported because:

• the original turtle api has lots of globals and was not meant to handle multiple Screens anyway
• potentially, you may need to address unforeseen conflicts with other stateful libs you may need for your projects
• asyncio stuff could give issues (especially if you choose micropython)
• pyscript config system could get in the way

Fixing the ugly html unique id problem would be easy and I will surely do it in the future, but the other problems I listed would remain and are more complex in nature. First I would like to address bugs and stabilize the api.

As a workaround, you can still use the iframes approach as in a) testing page, if you want to follow that route and have questions / need some fixing I can provide support.

Does your use case fall into one of the categories above or have something else in mind? I would be interested to hear.

Cheers,
David

[cyust]

Thanks for your quick response. Let me experiment with the iframes approach and see if that will resolve all of the issues.

For us, a typical lesson page has 3-4 live code examples that students should be able to edit/run independently. Each example might start with some unique code and students can further modify/run those examples as desired. To use iframes, we'll need some JavaScript to take the python source code from an edit field in the main page, wrap an HTML page around that code, and send it over to the corresponding iframe for dynamic display. Please give me a bit of time see how this will work out and I'll share the results.

[DavidLeoni]

Ok, so in your case, given that students can access UI you definetely want the iframe approach to prevent accidental damage to main UI. The remaining problems I see are the following:

1. currently the architecture is designed to be file-based on local computer, so as you already noticed you'll need some work to make it read the forms
2. a bigger problem is student scripts that go into infinite loops / stress the UI, which may hang even the container page.
   When you only have a single script that is already saved on file, it's enough to reload the page. But with multiple scripts as in your case, there is concrete risk students lose the work unless the forms are synchronized in some way with a server or store the code in local browser cache (in theory one could also think about writing to local file system). To see possible issues, I recommend you check the stress tests here (in particular 'Async stress Test' for ui and 'Danger forever' for loops):

https://coderdojotrento.github.io/turtle-pyscript/test.html?s=test/uitests_stress.py

Probably students would need to be instructed about the magic Shift Esc keys to pop up the internal process manager of Chrome (if you use that). In the future (but I don't know when), I would like to put in place some partial remedy like checking at least for obvious infinite loops, but it wouldn't completely solve the problem anyway. I've checked ways to pre-emptively stop pyodide but seems too complicated / not possible.

[cyust]

Good afternoon,

I was able to get the iframe approach to support multiple, independent script examples; thank you. We already have a code editor panel that lets students modify existing code or create their own code in a <textarea>, then send that code "somewhere" for execution when a button is clicked. In this case, "somewhere" is a new <iframe> element (reusing a placeholder iframe will not work multiple times). We understand the possibility of infinite loops to hang the browser, and this isn't hugely different than our other online coding environments, so we won't worry about it for now.

Documenting the general approach for others, we have some JavaScript that runs when the student clicks a "Run" button. First, we create a new <iframe> underneath a placeholder

in the main page:

var turtlediv = $(caller).parent().find('div.turtleoutput'); // turtleoutput is our placeholder div that will hold the new iframe
var turtleframe = $("<iframe class='turtleframe' style='width:100%;height:100%;></iframe>");
$(turtlediv).append(turtleframe);
turtleframe.focus();

We then build an "html" string with complete content, with all required turtle-pyscript dependencies in the and content in the , including the "tps-game-area" and "tps-game-box" divs, and the <script> element dynamically populated with the student code. Then we send that html to a new <iframe>:

// insert code into empty iframe
var domFrame = $(turtleframe)[0];
var frameWindow = (domFrame.contentWindow) ? domFrame.contentWindow : (domFrame.contentDocument.document) ? domFrame.contentDocument.document : domFrame.contentDocument;
frameWindow.document.open();
frameWindow.document.write(html);
frameWindow.document.close();

With this approach, there is NO delay loading the initial web page due to turtle-pyscript, no matter how many examples we have on the page. The main page knows nothing about turtle-pyscript and just has the Python source code examples in <textarea> elements. The turtle-pyscript is re-initialized through a new <iframe> each time the student clicks a "Run" button, and that process seems to take a few seconds. which we find acceptable.

I have a variety of other discussion topics that fall beyond the scope of this ticket, so I'll find somewhere else to raise them :)