Add wasm CI #29093
Add wasm CI #29093
Conversation
|
The last commit is a hack, and I don't like that it's necessary. To avoid the This also does not fix anything in browsers; I'm unable to run any code that requires FreeType with the same exception. |
I've figured out what these are:
And this one doesn't seem to have failed on CI, so it does seem to be something to do with memory allocation patterns, and not something inherent to this test. |
|
Thanks for this, @QuLogic! Some quick comments for now on the "2 mlab tests don't raise This is generally because of the lack of observability for floating-point exceptions in the WASM runtime, so these tests will have to be skipped for now. Similar issues have been noted here: pyodide/pyodide#4859 and in previous conversations, too.
While support for PyPI is going to demand a PEP and some effort across packaging tooling, in the meantime, it would be great for Matplotlib to publish these WASM wheels when ready to the https://anaconda.org/scientific-python-nightly-wheels index. We're uploading them for NumPy, |
|
xref pyodide/pyodide#4510 because this effort will be helpful there, too. |
OK, I will skip them, then.
Unfortunately, I don't see anything obvious there; they appear to be changing their extension itself, but not anything on the FreeType side of the build.
We can publish there; it's just that these include the test images and are 5 times bigger as a result. 8000 |
I see. In the in-tree recipe, we provide the test images in a separate That is, we could use the standard P.S. this is under the assumption that the images listed under |
So this was unrelated now. The problem was in the debugger I had "Pause on caught exceptions" enabled, which for some reason made it crash. Now, with the following page (note I symlinked the wheel name to a generic one so I didn't need to edit the page repeatedly): Example HTML page<!DOCTYPE html>
<html>
<head>
<script src="https://cdn.jsdelivr.net/pyodide/v0.26.3/full/pyodide.js"></script>
</head>
<body>
<h1>Pyodide test page</h1>
Open your browser console to see Pyodide output
<br />
<button id="run" onclick="evaluatePython()">Run</button>
<h2>Output:</h2>
<textarea id="output" style="width: 50%;" rows="100" disabled></textarea>
<canvas id="canvas<
8000
/span>" style="vertical-align: top;"></canvas>
<script type="text/javascript">
const run = document.getElementById("run");
const output = document.getElementById("output");
const canvas = document.getElementById("canvas");
output.value = "Initializing... ";
run.disabled = true;
async function main() {
let pyodide = await loadPyodide();
pyodide.setDebug(true);
pyodide.setStdout({
batched: (s) => output.value += `${s}\n`,
});
pyodide.setStderr({
batched: (s) => output.value += `[ERR] ${s}\n`,
});
await pyodide.loadPackage("micropip");
let micropip = pyodide.pyimport("micropip");
await micropip.install("http://127.0.0.1:8000/matplotlib-3.10.0.dev0-cp312-cp312-pyodide_2024_0_wasm32.whl");
output.value += "Done!\n";
run.disabled = false;
return pyodide;
}
let pyodideReadyPromise = main();
async function runStuff(code) {
let pyodide = await pyodideReadyPromise;
output.value += `>>>${code}\n`;
try {
return pyodide.runPython(code);
} catch (err) {
output.value += `[EXC]:${err}`;
}
}
async function evaluatePython() {
await runStuff(`
import sys
print(sys.version)
`);
await runStuff(`
import matplotlib
print(matplotlib.__version__)
`);
const fig = await runStuff(`
import matplotlib.pyplot as plt
import numpy as np
x = np.linspace(0, 10, 1000)
y = np.sin(x * np.pi)
fig, ax = plt.subplots()
fig.text(0.5, 0.5, 'Test',
fontsize=24, horizontalalignment='center', verticalalignment='center')
ax.plot(x, y)
print(fig)
fig
`);
fig.canvas.draw();
const width = fig.bbox.width;
const height = fig.bbox.height;
const buffer = fig.canvas.buffer_rgba();
const data = buffer.getBuffer("u8clamped");
const imageData = new ImageData(data.data, width, height);
canvas.width = width;
canvas.height = height;
const ctx = canvas.getContext("2d");
ctx.putImageData(imageData, 0, 0);
data.release();
}
</script>
</body>
</html>
It's probably not the most efficient implementation, but it's enough to prove the wasm wheel is working. |
I'm surprised to hear this, what's the best way to reproduce the failure? |
|
Thanks so much @QuLogic for working on this! |
| CFLAGS = "-fexceptions" | ||
| CXXFLAGS = "-fexceptions" | ||
| LDFLAGS = "-fexceptions" |
There was a problem hiding this comment.
Someone was suggesting recently that we ought to make this the default.
There was a problem hiding this comment.
Yes, Henry was suggesting it in our Discord server, IIRC, through which pybind/pybind11#5298 came up (as linked in the code comment above)
|
Running this myself I'm getting a crash in |
Looking closer, these two tests use >>> import os
>>> fh = open(os.devnull, 'w')
>>> fh.tell()
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
io.UnsupportedOperation: underlying stream is not seekableI pushed a change to avoid using |
Are you building with |
I'm not building with cibuildwheel because there are test failures and I don't know how to get a copy of the wheel to inspect/debug if tests fail. @henryiii is there an easy way to do this? Anyways I did copy the exact build command out of the log and copied the environment changes. So I think I'm building it right.
I bet this is the problem. |
You can skip the tests by building with: |
More of these are happening now that the leaky file handle was fixed. I've opened #29102 to minimize memory usage in the image comparisons, and that should fix these. |
|
I've come back to this and think it's in a reasonable spot now. With a bit of modification of the testing procedure, the workflow is able to build normal wheels that don't include baseline images, so I've modified the nightly upload to publish the wasm wheels to the nightly index. There are 2 things that may be workarounds for pyodide/emscripten/wasm issues:
|
Further testing shows that I don't need the first thing. Perhaps something improved in the toolchain somewhere since last time. FreeType still needs all symbols or else everything using text crashes. |
This was originally for i686 on Fedora, but is now applicable to WASM, which is 32-bit. The older implementation doesn't OOM.
This checks `os.geteuid`, but this is only available on Unix, not Emscripten or WASM.
In Enscripten/WASM, this module can be imported, but doesn't work, so we can't fall back to `dummy_threading` at import-time as we used to do.
The file system is either sandboxed or there are simply no other fonts, so limit ourselves to our pre-shipped fonts.
On WASM, which is wholly 32-bit, casting unsigned int to signed long is a narrowing conversion, which it seems to treat as an error. The Agg buffer cannot be over `(1<<23)` in width or height, so this cast is safe even with the smaller sizes.
This adds a `pyproject.toml` config for it, so you can replicate locally with cibuildwheel.
On wasm, this file doesn't support seeking, which is sometimes necessary depending on file type.
PR summary
This adds wasm builds on CI through
cibuildwheel; these are geared towards testing only, and not publishing, as they usecibuildwheel's test command, which requires shipping the test result images (which we don't do for release wheels.)The wasm platform has several constraints:
threading(MNT: Remove dummy_threading because threading is always available #23073), it's not actually supported Threading support pyodide/pyodide#237 and we need to either ignore it, or skip tests that use it.shutil.whichreturns a real path, but due to the below, fails to run, so we need to explicitly catch that.mlab.stride_windowsimplementation, as the NumPystride_tricksimplementation OOMs. This is now in Use old stride_windows implementation on 32-bit builds #29115 for separate review.This gets us to about 80% tests passing, 19% skipped (mostly the SVG/PDF, I think), and a small handful that fail:
file.seek/file.tell? That seems an odd limitation, especially for the latter. -> patched here to avoidos.devnullmlabtests don't raisenumpy.linalg.LinAlgError; haven't investigated at all. -> @agriyakhetarpal says to skip these, so I have.tests/test_simplification.py::test_throw_rendering_complexity_exceededthrowsMemoryErrorinstead ofOverflowError; probably this will have to be skipped like the OOM ones, but I haven't checked the implementation.tests/test_skew.py::test_skew_rectangle[png]fails to allocate the (8, 8)-inch figure, but there are several tests with a larger figure, so I'm not sure why this one in particular fails. -> I've opened TST: Calculate RMS and diff image in C++ #29102 to optimize the image comparisons, which will fix these.cc @agriyakhetarpal
Closes #27870
PR checklist