changes for gdscript browser activcode

[DavidCooperWCU]

I committed the 3 changes that I needed to make gdscript work with activecode in the browser.

I didn't add the change I needed to make to package.json, and package-lock.json in order to build. If you'd like me to commit those, please let me know.

[bnmnetp]

Where is the wasm file for Godot? I think at a minimum it needs to be in the js folder with the activecode_gdscript.js

[DavidCooperWCU]

The wasm file is hosted in the book. That's what we discussed over Zoom. The latest version of the wasm is in my fork of the pretext sample book.

[bnmnetp]

That is not what I thought we discussed. We can't make authors of books responsible for going out and finding wasm files. It also makes this feature unusable unless someone is aware of that.

If your code for activecode_gdscript correctly imports the wasm file, then it will automatically get copied into any book that wants to write an example like this.

[DavidCooperWCU]

The JavaScriptBridge filtering is to address the largest security concern with using a Godot WASM file.
This concern is that GDScript can call arbitrary javascript, which could potentially open up the site to known attacks.

The filtering restricts JavaScript calls that aren't specifically postMessages that have a JSON dictionary as a payload, and a known origin. As long as eval isn't used on the JSON dictionary, this should restrict calls to actual GDScript instead of allowing arbitrary javascript code to be run in the WASM.

[DavidCooperWCU]

That is not what I thought we discussed. We can't make authors of books responsible for going out and finding wasm files. It also makes this feature unusable unless someone is aware of that.

If your code for activecode_gdscript correctly imports the wasm file, then it will automatically get copied into any book that wants to write an example like this.

Okay,

The activecode_sql file uses:

import initSqlJs from "sql.js/dist/sql-wasm.js";

I'm not sure where sql.js is hosted, but perhaps hosting it a similar way would be useful rather than having a lot of bloat in the runestone/js directory.

[bnmnetp]

That is installed by npm which puts all of the files in the node_modulesq folder of bases/rsptx/interactives/`.

When we prepare a release of the components webpack traces all of the imports and bundles them up into easily chunkable parts, so that we only load what we need for each web page.

What you do for gdscript should work similarly.

[DavidCooperWCU]

So, I'm not sure if npm makes the most sense for this because index.html is required for this setup, but I could look into doing something similar to the way micro-parsons-element is done and make a repository that just has the godot-shell directory in it along with a package.json file that copies the files.

Does that make sense?

[DavidCooperWCU]

Alternatively I could put a directory somewhere in interactives/runestone since it's really designed to work with the runestone activecode framework. I'm just not sure the best place for it. activecode has js and css.

I could make a godot-shell folder there (in interactives/runestone/activecode with the wam and supporting pck, html, images, and javascript.

Do you think that's the best place for it? If so, then I just need to figure out how to make the appropriate package.json file so that it copies the files correctly.

[bnmnetp]

Definitely not the micro-parsons approach. We are working on moving that code directly into the hparsons folder.

We need to be careful to distinguish what is the framework needed to run a godot program and what is needed by individual problems. What is the purpose of the following:

• index.html ?
• other html files???
• pck ??
• images?

I'm starting to get the feeling that a godot program is not as simple as a SQL or a Python program. Which only need the text of the program and an interpreter to run it.

[DavidCooperWCU]

In the activecode container in a book, the index.html is loaded in an iframe. That uses the other files in the godot-shell directory:

% ls -1 ext/godot-shell
index.apple-touch-icon.png
index.apple-touch-icon.png.import
index.audio.position.worklet.js
index.audio.worklet.js
index.html
index.icon.png
index.icon.png.import
index.js
index.pck
index.png
index.png.import
index.wasm

Then, each activecode program lists a .pck file that is loaded from external/gdpractice.
The activecode program also specifies the starting scene for where the student's gdscript code is injected.

So, the problems in the book will put the required problem specific .pck files in the ext/gdpractice folder of the book, and we are just working out where to put the godot-shell folder so that it gets properly copied into _static, and then I'll need to change activecode_gdscript to look in _static instead of external, but that's simple enough.

[bnmnetp]

What is in the pck files? Is that something the student modifies?

Is index.wasm the gdscript interpreter or is there an other wasm file for that?

What we want to have packaged up by runestone is the infrastructure to run one of these programs. We want authors to be able to make their programs in PreTeXt markdown, and have PreTeXt + Runestone do the rest. PreTeXt should get all of the the things specified in PreTeXt translated to html and copied to the right place. Runestone should just render the editor, provide a run button and be able to call a function that runs the code entered by the author or modified by the student.

If all of the index.* files are common to ALL gdscript programs then authors should not have to think about them they just need to be somewhere that the interpreter can load them. If each example/program needs its own pck file how are those going to be authored?

@ascholerChemeketa keeping you in the loop as you may have more experience with Godot than I.

[DavidCooperWCU]

Yes, the index.wasm file is the godot-shell wasm. Agreed, the author should not need to think about them.

The student will not be making pck files. There is a pck file for the wasm, and then there is an additional pck file for each example program.

With the current design, the author provides the pck file for each problem. That file has a directory structure that includes testing code and environment for the particular problem. The system works this way so that each problem can have its own assets specific to the problem. Since this is a game, there is either a 2D or 3D environment for the program. This environment gets loaded from the problem specific pck file.

Authoring Godot Practice problems is a little bit more involved because of this.

We may want to settle on some default environments that are provided. This is straightforward. We'd just provide the default environments from rs. This would require a way for testing code injection in addition to the student code injection. That shouldn't be too hard since there is a place for it in the pretext. It's just different than my initial design.

I was looking at the way the sql.js wasm file was added:

new CopyPlugin({
                    patterns: [
                        {
                            // sql.js support: this wasm file will be fetched dynamically when we initialize sql.js. It is important that we do not change its name, and that it is in the same folder as the js.
                            from: "node_modules/sql.js/dist/sql-wasm.wasm",
                            to: ".",
                        },
                    ],
                }),

Based on that, I think we could do:

new CopyPlugin({
                    patterns: [
                        {
                            // sql.js support: this wasm file will be fetched dynamically when we initialize sql.js. It is important that we do not change its name, and that it is in the same folder as the js.
                            from: "node_modules/sql.js/dist/sql-wasm.wasm",
                            to: ".",
                        },
                        {
                            // godot support: this Godot-script file will be fetched dynamically. It is important that we do not change its name or try to minimize any of the code.
                            from: "extra_dependencies/godot-shell",
                            to: "./godot-shell",
                            // need this: Tells webpack to skip parsing or optimizing these files
                            info: { minimized: true } 
                        },
                    ],
                }),

[DavidCooperWCU]

I made the change I suggested above, and it works.

Are you okay with the following directory bases/rsptx/interactives/extra_dependencies?

Or should I place it somewhere else?

[DavidCooperWCU]

What we want to have packaged up by runestone is the infrastructure to run one of these programs. We want authors to be able to make their programs in PreTeXt markdown, and have PreTeXt + Runestone do the rest.

I've made some changes so that this can happen for a subset of problems, and I will work on expanding this.

My current plan is to have 2 folders in bases/rsptx/interactives/extra_dependencies that each get copied into _static.

• godot-shell - the wasm running code
• gdpractice - the place for .pdk templates usable by instructors for basic functions or a predetermined environment. These will not have default solutions, since the problems will be defined by the instructor.

If you agree to the location of the files and the scripting change in the webpack.config.js file to do the copying, then I'll commit and push that change for testing. If you'd prefer a different directory structure, please let me know.

[ascholerChemeketa]

The CopyPlugin mechanism would mean the WASM files are bundled with every book, correct?

Again, that is what I am concerned about. That would bloat the size of the _static directory of every book by a factor of something like 3x. Runestone interactives are the default mechanism for all interactive exercises. A math book that is using Runestone to add Parsons problems should not have to bundle 40Megs of unused wasm that is only needed for books using GDScript.

Even worse, extrapolate this pattern out over a few other new languages/tools.

It really feels like these should be loaded from a server and not bundled directly into the book.

[bnmnetp]

@ascholerChemeketa raises a very good point. One reason why I have stuck with skulpt all these years is that it is much smaller than going with one of the wasm implementations of Python in the browser.

From what I can tell there is not a standard place to get the distributed files for Godot. Which means we would have to self host them on our pseudo CDN on Runestone.academy. Or perhaps there is something somewhere I don't know about.

At a minimum I think we would need to version things on the CDN so that books are loading the version of Godot the author intends and not just whatever unversioned index.wasm happens to be there.

[DavidCooperWCU]

The CopyPlugin mechanism would mean the WASM files are bundled with every book, correct?

Again, that is what I am concerned about. That would bloat the size of the _static directory of every book by a factor of something like 3x. Runestone interactives are the default mechanism for all interactive exercises. A math book that is using Runestone to add Parsons problems should not have to bundle 40Megs of unused wasm that is only needed for books using GDScript.

Even worse, extrapolate this pattern out over a few other new languages/tools.

It really feels like these should be loaded from a server and not bundled directly into the book.

This is why I had the wasm in the book itself, instead of in rs.

I am not attached to a solution.

Whatever is easiest to maintain.

Right now the SQL wasm is attached to every book that uses activecode.

[bnmnetp]

Authors should not have to even know what a .wasm is in order to write a book.

Yes, we have the sql wasm bundled but the wasm for sql is just 1 MB.

If you can send me the index.wasm or point me to where I can grab it I will put it in:

https://runestone.academy/cdn/runestone/godot-X.Y/image.wasm

[DavidCooperWCU]

Authors should not have to even know what a .wasm is in order to write a book.

I agree.

Does your pseudo CDN do remapping? If not, then we'll need the whole godot shell directory to be on runestone.academy/cdn/runestone/godot-shell-4.6.3

The wasm file is in an older commit of my fork of the pretext book in ext/godot-shell/index.wasm.

If it's all you need, then you can download it from there. If you need the rest of the files also, then I'm happy to zip them up and share them with you.

If the the corresponding files that are needed to run with it will not be in the same directory as the wasm file, then should I put those in the directory structure as specified above?

Similarly, with the pck practice problem files.

One option would be to have some default files as part of rs, and the other would be to put them in the cdn directory. In that case, I think it could look like this, and there would be no need to do standard CDN remapping of the files:

• https://runestone.academy/cdn/runestone/godot-X.Y/godot-shell to hold all of the shell fiiles
• https://runestone.academy/cdn/runestone/godot-X.Y/gdpractice to hold the ready to use .pck files

[bnmnetp]

If it expects all those other js and image files to be siblings in the same folder that is fine. They can all go on our cdn.

I think the closest analogy to the pck files I can think of are the .db files that we use for the sql an instructor can supply those in a PreTeXt external folder - Can you configure gdscript to look for the pck files in a particular folder that isn't the same as the wasm folder?

[DavidCooperWCU]

Can you configure gdscript to look for the pck files in a particular folder that isn't the same as the wasm folder?

Yes, That's how it's configured now. The index.pck folder should be with the .wasm file, but the individual practice .pck files are in the external directory.

The only reason we might want to have some .pck files on your cdn in a different directory is so that instructors could have default environments that they could make problems from. Perhaps one without graphics, just to test functions, one with a sprite to test moving the sprite programmatically, one with 2 objects to test collisions, etc. It's not necessary, but it would lower the barrier to entry for authors who don't want to build their own test environments for their problems.