[issue40280] Consider supporting emscripten/webassembly as a build target
Simon Biggs added the comment: Hi pmp-p and Serhiy, I'd be more than happy to attempt a pull request, but I imagine a change such as this needs to be discussed first, trying not to "rush to make a patch" (https://www.youtube.com/watch?v=voXVTjwnn-U=youtu.be=2546). Also, I doubt I will do a good job of it... but I am more than happy to try. A note regarding "supercharged full stack pyodide", potentially without efforts such as upstreaming into CPython and emscripten the relevant patches, that supercharged full stack may just unfortunately stagnate. See https://github.com/iodide-project/pyodide/issues/635#issuecomment-613408912 With respect to blocking when running Python as WASM, I have found running the WebAssembly CPython within a webworker and signalling data back and forth causes there to be no UI issues. It ends up being quite a neat set up. Main down side right now however is the set up is currently going stale, hence me believing reaching out like this is in the best interests of Python going forward. Cheers, Simon On Tue, 14 Apr 2020 at 18:58, pmp-p wrote: > > pmp-p added the comment: > > you can add > * > https://github.com/pmp-p/pydk/tree/master/sources.em/Python-3.8.0b4.patchset > -- Python 3.8.x > > (wasm not asm.js, clang-10+ required) > > demo https://pmp-p.github.io/python-next/test.html > > CPython can already run in the browser with very little patching, but > major issues are : > > - asyncify'ing the whole wasm VM to have pre-emption over cPython's one > to prevent blocking I/O slows down things *a lot* (10x) > => (very?) bad user experience. > > - the size of vm + stdlib ~ 30 MiB and wasm compilation time. > => bad user experience on first load or slow connexion. > > - the lack of threading in wasm MinimumViableProduct specification (but > this is the browser standard for now), that leads to rewrite bits of stdlib > ( like eg asyncio module ) > => adding more maintenance burden on stdlib (!) > > > i tested them all and my personnal opinion is : I can see no use case that > would favour "stock" cPython wasm versus a blazing fast MicroPytho (or > pycopy) wasm flavour or supercharged full stack pyodide. > > -- > nosy: +pmpp > > ___ > Python tracker > <https://bugs.python.org/issue40280> > ___ > -- ___ Python tracker <https://bugs.python.org/issue40280> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40280] Consider supporting emscripten/webassembly as a build target
New submission from Simon Biggs : Since asm.js came on the scene, and now Web Assembly people have created CPython patches to support building CPython with emscripten. See: * https://github.com/PeachPy/EmCPython -- Python 2.7 * https://github.com/dgym/cpython-emscripten/tree/master/3.5.2/patches -- Python 3.5.2 * https://github.com/iodide-project/pyodide/tree/master/cpython/patches -- Python 3.7.4 To ease the compiling of CPython with emscripten it would be helpful if patches that achieved these ends for the compiling to Web Assembly with emscripten were built into the upstream source repository itself. If web assembly were to became a supported compilation target of the upstream CPython repository this would significantly reduce the friction of allowing CPython, and the latest CPython, to become a language readily usable within the browser. Cheers, Simon -- components: Build messages: 366369 nosy: Simon Biggs priority: normal severity: normal status: open title: Consider supporting emscripten/webassembly as a build target type: enhancement versions: Python 3.9 ___ Python tracker <https://bugs.python.org/issue40280> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
Python WebApp where Python runs on the client's machine using Pyodide
It's still a massive work in progress, but I though people here might be interested in the progress made thus far: https://app.pymedphys.com/ It is a file processing application. It has input files and output files. Users select input files from their computer, select a script to run (or edit a script to create their own) and then it produces the output files which can be downloaded. At the moment when Python is running the user interface freezes but to fix that I am told I just need to get my head around web workers ( https://github.com/iodide-project/pyodide/issues/435#issuecomment-493928297 ). It's been quite fun! Also, adding new scripts to the web app should be as simple as following the steps laid out over here: https://github.com/pymedphys/pymedphys/issues/312 I'm keen for feedback, please let me know what you think! I'll likely post this again in the near future once I fix up the freezing and I have also provided a few more example scripts. Cheers, Simon -- https://mail.python.org/mailman/listinfo/python-list
