Also, if we compile to WASM we could use JupyterLite to build an interactive on-line tutorial that runs entirely on the browser and doesn't depend on Binder or external tools.

First challenge to take note: rand_pcg::Pcg64 is not available in WASM, we will probably have to fallback to Pcg32 in WASM

error[E0432]: unresolved import `rand_pcg::Pcg64`
  --> src/layout/random.rs:16:5
   |
16 | use rand_pcg::Pcg64;
   |     ^^^^^^^^^^-----
   |     |         |
   |     |         help: a similar name exists in the module: `pcg64`
   |     no `Pcg64` in the root

error[E0432]: unresolved import `rand_pcg::Pcg64`
  --> src/layout/spring.rs:30:5
   |
30 | use rand_pcg::Pcg64;
   |     ^^^^^^^^^^-----
   |     |         |
   |     |         help: a similar name exists in the module: `pcg64`
   |     no `Pcg64` in the root

error[E0432]: unresolved import `rand_pcg::Pcg64`
  --> src/random_graph.rs:28:5
   |
28 | use rand_pcg::Pcg64;
   |     ^^^^^^^^^^-----
   |     |         |
   |     |         help: a similar name exists in the module: `pcg64`
   |     no `Pcg64` in the root

Also, if we compile to WASM we could use JupyterLite to build an interactive on-line tutorial that runs entirely on the browser and doesn't depend on Binder or external tools.

That would be great!

One way to do this would be to try to get rustworkx on Emscripten Forge (like conda-forge but for emscripten) by adding a new recipe to the repo: https://github.com/emscripten-forge/recipes

The package would then be available for use with the Xeus Python kernel for JupyterLite: https://github.com/jupyterlite/xeus-python-kernel/

Otherwise for Pyodide support that would mean opening a new PR on the repo to add the package: https://github.com/pyodide/pyodide. And waiting for a new Pyodide release.

Either way it would indeed be nice to be able to try the library directly in the browser!

Also, if we compile to WASM we could use JupyterLite to build an interactive on-line tutorial that runs entirely on the browser and doesn't depend on Binder or external tools.

That would be great!

One way to do this would be to try to get rustworkx on Emscripten Forge (like conda-forge but for emscripten) by adding a new recipe to the repo: https://github.com/emscripten-forge/recipes

The package would then be available for use with the Xeus Python kernel for JupyterLite: https://github.com/jupyterlite/xeus-python-kernel/

Otherwise for Pyodide support that would mean opening a new PR on the repo to add the package: https://github.com/pyodide/pyodide. And waiting for a new Pyodide release.

Either way it would indeed be nice to be able to try the library directly in the browser!

That is very interesting! I wans't aware of that. I remember someone created a conda-forge recipe for us: https://github.com/conda-forge/rustworkx-feedstock. So we could look into creating an emscript-forge recipe as well.

One of the biggest challenges though is that wasm32-unknown-emscripten is the first architecture that our code hasn't compiled to. So we will need to make sure rustworkx-core and rustworkx work with it first

I'm interested in having this feature and I'm available to put in the work

I'm interested in having this feature and I'm available to put in the work

I was taking a look at https://github.com/sorin-bolos/rustworkx/pull/1/files, I think for rand_pcg using features to detect the platform is fine.

But for rayon, really it should have a fallthrough. There's a discussion in rayon-rs/rayon#1155. If we need to patch each use of rayon in rustworkx and rustworkx-core the PR will become unmergeable. We need to make it default to single threaded by default somehow.

Even exploring something among these lines seems more approachable: https://github.com/RReverser/wasm-bindgen-rayon?tab=readme-ov-file#building-rust-code

This is worth exploring as well: https://www.reddit.com/r/rust_gamedev/comments/1dvumtw/multithreaded_rust_in_the_browser_via_emscripten/?rdt=43533

Two things:

• Update rand crate to 0.9 and bump related dependencies #1445 takes care of rand thankfully, at least rustworkx-core compiles. I don't know about rustworkx yet as I have not set up the pyodide build
• For rayon, feat: Polars build for Pyodide pola-rs/polars#20383 has a possible way forward. They compile the emscripten build with a threadpool of just one thread. We could get away with it
• Following up the previous point, maybe instead of having to refactor to use thread pools, we could get away with https://docs.rs/rayon/latest/rayon/struct.ThreadPoolBuilder.html#method.build_global by setting the global to use just one thread