Description
easy to fix
-
heap/stack init is not clear
mp_js_init(stack_size) with stack= parameter instead of heapsize=
https://github.com/micropython/micropython/blob/master/ports/javascript/wrapper.js#L59
but in fact is heap https://github.com/micropython/micropython/blob/master/ports/javascript/main.c#L88 -
add more .exp test files so one can write a browser testsuite or use run-tests-exp.sh.
-
browser example is minimalist and does not provide a default micropython web server and possibly a websockify example
-
builtins time.sleep and input should at least throw a warning/error instead of crashing browsers.
-
an asyncio flavour should be provided as a frozen module.
-
please use cpython C-API names when interfacing JS and C that will save everybody's time. either for understanding api or writing documentation see https://docs.python.org/3/c-api/veryhigh.html. that would ease transition later to https://github.com/pyhandle/hpy
-
provides simple sync I/O for snippets run cases POC port-javascript: add sync file access for scripts compatibility lvgl/lv_micropython#6
annoying things :
-
not so easy to use a pure async stdlib out of the box because of basic discrepancies
butilin iterator tool RFC: MICROPY_PY_BUILTINS_NEXT2 always set to (0) ? #5046 -
not so easy to interface with browser nor subprocess ( proxies )
class.mro() is notimpl RFC: class.mro() is notimpl #5106
-
why isn't javascript port yet the experimental platform of choice avaiable to everyone ?
nodejs has a sandbox mode equivalent to browser.
and import of online module can be done.
cf triaging : separate ideas-features-request from BUGS #4444 -
passing script data for interactive or script should be separate functions, actually all use mp_js_do_str(text) and alloc context of text is not clear if pausing/resuming is needed. But those are not the same :
https://docs.python.org/3/c-api/veryhigh.html#c.PyRun_SimpleString
https://docs.python.org/3/c-api/veryhigh.html#c.PyRun_InteractiveLoop -
parser/lexer should work on a pre allocated buffer either for interactive or script mode, filled with stringToUTF8( text, pointer, max_size ) as a real C string.
- why pre alloc ? because max size of code that interpreter can compile is fixed by heap limit anyway so save useless/unclear malloc/free operations beetween js/C
- execution mode could be simply set at end of buffer in a # comment when using asynchronous execution.
-
mp_js_do_str(text) is not wasm compliant and won't work when using clang 10 from latest-upstream emscripten branch. so better implement the two previous point and just get rid of it.
-
javascript port can't blink a led.
well not yet but soon https://wicg.github.io/webusb ;)
apart from the usb joke it can via websocket and a networked board but there's no sample.
heavy lifting :
-
not so easy to interface with browser nor subprocess
non GUI threads are available on wasm but GC is not under stdlib control turning everything simple into a leak source :
py: __del__ special method not implemented for user-defined classes #1878
Do we want to have weakref support? #646 -
internationalisation is deeply missing.
-
extra features available as diff only.
f-string py: Implement partial PEP-498 (f-string) support #4998
assignment expressions py/compile: Implement PEP 572, assignment expressions. #4908
=> problem is that port is not meant to be user built and parametric, it is expected to be full options and on a CDN. -
files fd, sockets fd, pipes and not only stdin/stdout should be multiplexed via stdin/stdout via a common interface for node / browser and worker. zero copy rpc would be better ( arrow / capnproto ? )
- why ? because MicroPython has ability to get a lot better than brython and cpython on the web.
- do not expect WASI to solve any async problem specific to python main thread in the browser.
- even if WASI get async, it's polyfill is not yet ready to load emscripten .wasm.
probably too heavy without branching/forking/redesign.
- micropython core
shouldcould be switched to non nlr with [proof of concept] completely remove nlr from py, extmod and unix port #4131. emscripten-upstream gets seriously confused with setjmp but fastcomp branch is to be dropped ( and anyway is troublesome with function pointers ).
UPDATE 05/09 : a fix is in progress https://reviews.llvm.org/D66784
- performance and I/O : asyncify is 10x slower than real thing : the solution is C-stackless design
that's both solve asynchronous I/O on any port and Allow pausing and resuming execution #3619 ( also called "checkpoint and restore in userspace" ).