Closed christianp closed 1 year ago
The binaries sometimes get generated too large for jsDelivr (even so, it's not great keeping more binaries in the repo history) and we don't have an npm package set up yet for unpkg. webR runs in a worker now too, and the infrastructure that makes that work well requires SharedArrayBuffer
, so the binaries need to be served with special headers and I don't think the simple CDNs expose that configuration.
So, currently I have things setup so that GitHub Actions builds WASM binaries and uploads them to Cloudflare for serving via a Cloudflare worker URL. So, the current state of the main branch is available at https://cdn.webr.workers.dev/latest/webr.mjs
. When we are confident enough to tag a versioned release, this should automatically be uploaded to https://cdn.webr.workers.dev/v0.1.0/webr.mjs
.
Loading webR into the page has changed quite a bit since March, I'm currently in the process of writing docs.
I don't think we'll be able to use anything that relies on SharedArrayBuffer
, because we can't arrange for the right headers to be sent on either the CDN end, or by the host serving Numbas exams.
Just how deeply does webR use SharedArrayBuffer
? Could it be made to compile in a way that doesn't use them, dropping features that need them?
I've left a comment in #75 describing our current plan. The short version is that I'm going to look into providing way to launch a minimal version of webR without using SharedArrayBuffer
. Probably such a limited version would just skip attempting to set up any Workers at all. I will need to consider things further before I can say for sure, though.
In any case it will indeed have some limitations - particularly around interactive REPL use.
In the case of the Numbas exams, since you're just wanting to run some code provided in a string and await the printed output I think a limited version would work OK. Possibly you could probably manage your own Worker and communication channel without using SharedArrayBuffer
, in a similar way as you currently do with pyodide_worker.js
.
An alternative communication channel between the main thread and worker thread based on JavaScript Service Workers, rather than SharedArrayBuffer
, is available from commit 0918433.
This could work as an alternative if the HTTP headers can't be controlled, but also has a different security requirement in that a Service Worker script must served by the web server at the same scope or above as the page currently loaded. That is, trying to load a service worker script from a subdirectory won't work.
I know Numbas at the moment serves extensions and standalone scripts from subdirectories relative to the exam page, could this be tweaked/extended so that the programming extension is able to drop a serviceworker.js
script in the same directory as index.html
? If so this Service Worker method can be used directly.
If that is not possible, some other alternative will have to be used. At the moment the Numbas programming extension loads Pyodide in a worker and manages its own communication between the page and worker threads. Possibly the extension could load the webR worker thread directly and manage the communication itself in the same way, but this might be fragile. I will look into it.
Closing this thread in favour of https://github.com/numbas/numbas-extension-programming/pull/27
We've just realised that the Numbas extension is fixed to a commit from March, loaded from jsdelivr. It looks like you got rid of the
dist
folder at some point in April, and the demo page loads a local copy.It looks like you're just working on the repl at the moment, but the standalone script is useful for us. Would it be possible to use something like
unpkg[https://unpkg.com]
to automatically produce the compiled files?Could GitHub Actions do the compilation?
I'm happy to put together a pull request doing this (or something like this) if you'll accept it.