The last commit is a hack, and I don't like that it's necessary. To avoid thenull function or function signature mismatch at runtime, I've had to unhide all the FreeType symbols. This seems to be a bug in the toolchain somewhere.

This also does not fix anything in browsers; I'm unable to run any code that requires FreeType with the same exception.

2 PDF tests seem to not fail, but see an unclosed file leak; this is possibly related to the above test failures.

I've figured out what these are:

• PdfPages._ensure_file creates aPdfFile when saving a figure.
• ThisPdfFile.__init__ writes some information to the output about the overall PDF structure.
• Some of this involvesXObjects, which reference file offsets, and usefh.tell().
• Pyodide for some strange reason doesn't support this, and raises an exception.
• Because this is inPdfFile.__init__, no variable is assigned inPdfPages._ensure_file, and the file object is left floating.
• Thus, even thoughPdfFile implements__exit__ and the test uses a context manager, the file is never closed.
• Sincepytest turns resource warnings into errors, this leaks into some other test.

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.

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 testsdon't raisenumpy.linalg.LinAlgError; haven't investigated at all." statement and on other things you've noticed:

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.

FreeType inpygame-ce isn't supported well either:pygame-community/pygame-ce#1967. I don't know if that's related or helpful.

these are geared towards testing only, and not publishing

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 thehttps://anaconda.org/scientific-python-nightly-wheels index. We're uploading them for NumPy,statsmodels, PyWavelets (pywt),scikit-image, andpandas right now already – and more packages are planned; they shall potentially be used for interactive documentation with JupyterLite/jupyterlite-sphinx.

xrefpyodide/pyodide#4510 because this effort will be helpful there, too.

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.

OK, I will skip them, then.

FreeType inpygame-ce isn't supported well either:pygame-community/pygame-ce#1967. I don't know if that's related or helpful.

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.

these are geared towards testing only, and not publishing

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 thehttps://anaconda.org/scientific-python-nightly-wheels index. We're uploading them for NumPy,statsmodels, PyWavelets (pywt),scikit-image, andpandas right now already – and more packages are planned; they shall potentially be used for interactive documentation with JupyterLite/jupyterlite-sphinx.

We can publish there; it's just that these include the test images and are 5 times bigger as a result.

We can publish there; it's just that these include the test images and are 5 times bigger as a result.

I see. In thein-tree recipe, we provide the test images in a separatetest_data folder, but I am not sure when they were separated out. They don't seem to match the images in/matplotlib/lib/matplotlib/mpl-data/, though, so maybe we can work with different combinations for testing and uploading?

That is, we could use the standardpyodide build invocation to build and test Matplotlib WASM wheels out-of-tree in CI, but usecibuildwheel and leave out the "tests" install tag when publishing to Anaconda.org in order to get smaller wheels (plus, not test when building withcibuildwheel). Another reason why this could make sense, besides making the wheel smaller by not including ancillary data, is that the Pyodide version available incibuildwheel remains coupled to thecibuildwheel version – at least, this will be the case until I finishpypa/cibuildwheel#2002. We currently don't have a minimum supported version policy or LTS releases for Pyodide, so the latest Pyodide version is the one we can reasonably support and recommend using – and thepyodide xbuildenv install command viapyodide-build will more freely allow you to choose a particular (compatible) Pyodide version in case you wish to pin it.

P.S. this is under the assumption that the images listed under/matplotlib/mpl-data/ are required in the test suite.

This also does not fix anything in browsers; I'm unable to run any code that requires FreeType with the same exception.

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):

<!DOCTYPE html><html><head><scriptsrc="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/><buttonid="run"onclick="evaluatePython()">Run</button><h2>Output:</h2><textareaid="output"style="width: 50%;"rows="100"disabled></textarea><canvasid="canvas"style="vertical-align: top;"></canvas><scripttype="text/javascript">construn=document.getElementById("run");constoutput=document.getElementById("output");constcanvas=document.getElementById("canvas");output.value="Initializing... ";run.disabled=true;asyncfunctionmain(){letpyodide=awaitloadPyodide();pyodide.setDebug(true);pyodide.setStdout({batched:(s)=>output.value+=`${s}\n`,});pyodide.setStderr({batched:(s)=>output.value+=`[ERR]${s}\n`,});awaitpyodide.loadPackage("micropip");letmicropip=pyodide.pyimport("micropip");awaitmicropip.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;returnpyodide;}letpyodideReadyPromise=main();asyncfunctionrunStuff(code){letpyodide=awaitpyodideReadyPromise;output.value+=`>>>${code}\n`;try{returnpyodide.runPython(code);}catch(err){output.value+=`[EXC]:${err}`;}}asyncfunctionevaluatePython(){awaitrunStuff(`            import sys            print(sys.version)        `);awaitrunStuff(`            import matplotlib            print(matplotlib.__version__)        `);constfig=awaitrunStuff(`            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();constwidth=fig.bbox.width;constheight=fig.bbox.height;constbuffer=fig.canvas.buffer_rgba();constdata=buffer.getBuffer("u8clamped");constimageData=newImageData(data.data,width,height);canvas.width=width;canvas.height=height;constctx=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.

Pyodide doesn't seem to support file.seek/file.tell? That seems an odd limitation, especially for the latter.

I'm surprised to hear this, what's the best way to reproduce the failure?

Thanks so much@QuLogic for working on this!

Running this myself I'm getting a crash inft2font:

.venv-pyodide/lib/python3.12/site-packages/matplotlib/tests/test_agg.py .Pyodide has suffered a fatal error. Please report this to the Pyodide maintainers.The cause of the fatal error was:RuntimeError: null function or function signature mismatch    at ft2font.cpython-312-wasm32-emscripten.so.af_autofitter_load_glyph (wasm://wasm/ft2font.cpython-312-wasm32-emscripten.so-0044c45a:wasm-function[558]:0x7f032)    at ft2font.cpython-312-wasm32-emscripten.so.FT_Load_Glyph (wasm://wasm/ft2font.cpython-312-wasm32-emscripten.so-0044c45a:wasm-function[192]:0xfad4)    at ft2font.cpython-312-wasm32-emscripten.so.FT2Font::load_char_with_fallback(FT2Font*&, unsigned int&, std::__2::vector<FT_GlyphRec_*, std::__2::allocator<FT_GlyphRec_*>>&, std::__2::unordered_map<long, FT2Font*, std::__2::hash<long>, std::__2::equal_to<long>, std::__2::allocator<std::__2::pair<long const, FT2Font*>>>&, std::__2::unordered_map<unsigned int, FT2Font*, std::__2::hash<unsigned int>, std::__2::equal_to<unsigned int>, std::__2::allocator<std::__2::pair<unsigned int const, FT2Font*>>>&, long, int, int&, int&, std::__2::set<char*, std::__2::less<char*>, std::__2::allocator<char*>>&, bool) (wasm://wasm/ft2font.cpython-312-wasm32-emscripten.so-0044c45a:wasm-function[190]:0xf4ac)    at invoke_iiiiiiiiiiiii (/home/rchatham/Documents/programming/pyodide/dist/pyodide.asm.js:103252:40)    at ft2font.cpython-312-wasm32-emscripten.so.PyFT2Font_set_text(PyFT2Font*, std::__2::basic_string_view<char32_t, std::__2::char_traits<char32_t>>, double, std::__2::variant<LoadFlags, int>) (wasm://wasm/ft2font.cpython-312-wasm32-emscripten.so-0044c45a:wasm-function[366]:0x43795)    at ft2font.cpython-312-wasm32-emscripten.so.void pybind11::cpp_function::initialize<pybind11::array_t<double, 16> (*&)(PyFT2Font*, std::__2::basic_string_view<char32_t, std::__2::char_traits<char32_t>>, double, std::__2::variant<LoadFlags, int>), pybind11::array_t<double, 16>, PyFT2Font*, std::__2::basic_string_view<char32_t, std::__2::char_traits<char32_t>>, double, std::__2::variant<LoadFlags, int>, pybind11::name, pybind11::is_method, pybind11::sibling, pybind11::arg, pybind11::arg_v, pybind11::arg_v, char const*>(pybind11::array_t<double, 16> (*&)(PyFT2Font*, std::__2::basic_string_view<char32_t, std::__2::char_traits<char32_t>>, double, std::__2::variant<LoadFlags, int>), pybind11::array_t<double, 16> (*)(PyFT2Font*, std::__2::basic_string_view<char32_t, std::__2::char_traits<char32_t>>, double, std::__2::variant<LoadFlags, int>), pybind11::name const&, pybind11::is_method const&, pybind11::sibling const&, pybind11::arg const&, pybind11::arg_v const&, pybind11::arg_v const&, char const* const&)::'lambda'(pybind11::detail::function_call&)::__invoke(pybind11::detail::function_call&) (wasm://wasm/ft2font.cpython-312-wasm32-emscripten.so-0044c45a:wasm-function[365]:0x42d4a)    at invoke_ii (/home/rchatham/Documents/programming/pyodide/dist/pyodide.asm.js:102969:40)    at ft2font.cpython-312-wasm32-emscripten.so.pybind11::cpp_function::dispatcher(_object*, _object*, _object*) (wasm://wasm/ft2font.cpython-312-wasm32-emscripten.so-0044c45a:wasm-function[295]:0x224a9)    at _PyEM_TrampolineCall_JS (/home/rchatham/Documents/programming/pyodide/dist/pyodide.asm.js:7289:33)    at pyodide.asm.wasm.cfunction_call (wasm://wasm/pyodide.asm.wasm-029ee13e:wasm-function[2190]:0x20b80b) {  pyodide_fatal_error: true}

Pyodide doesn't seem to support file.seek/file.tell? That seems an odd limitation, especially for the latter.

I'm surprised to hear this, what's the best way to reproduce the failure?

Looking closer, these two tests usePath(os.devnull) as output filename. It appears that this specifically is what doesn't allowseek/tell (though the exception text confusingly references the opposite operation):

>>>importos>>>fh=open(os.devnull,'w')>>>fh.tell()Traceback (mostrecentcalllast):File"<stdin>",line1,in<module>io.UnsupportedOperation:underlyingstreamisnotseekable

I pushed a change to avoid usingos.devnull.

Running this myself I'm getting a crash inft2font:

Are you building withcibuildwheel? You need all the flags in there, or else the compiler is buggy with things somehow. Also, if you already have a checkout, Meson won't recreate the subprojects, so you'd need to apply the change to the FreeTypemeson.build in the cached copy (or deletesubprojects/freetype-2.6.1 to recreate it).

Are you building with cibuildwheel? You need all the flags in there

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.

if you already have a checkout, Meson won't recreate the subprojects

I bet this is the problem.

Are you building with cibuildwheel? You need all the flags in there

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.

You can skip the tests by building with:

CIBW_TEST_COMMAND= cibuildwheel --platform pyodide

• 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.

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:

• Building uses--exports whole_archive; I'm not sure why this is necessary as we really should only need thePyInit_* extension symbols.
• FreeType also needs all symbols to not be hidden:a568b27

There are 2 things that may be workarounds for pyodide/emscripten/wasm issues:

• Building uses--exports whole_archive; I'm not sure why this is necessary as we really should only need thePyInit_* extension symbols.

• FreeType also needs all symbols to not be hidden:a568b27

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.

/dev/null will be seekable in the next version of Pyodide =)