jimmo wrote: ↑Fri Sep 20, 2019 12:38 am
You've chosen a particularly difficult part of MicroPython -- the emscripten port is complicated
First the fact that running the VM can run without any "referenced" board - pricey or not - in multiple ways should open eyes to some about the fact they are missing a train.
But i did not choose anything, i don't even use javascript port or android ports though i honestly tried to promote them.
i only use my own wasm build to pop out I/O flaws because it's a tough platform but very fast build in order to backport solutions to cpython. The sad truth is there's no way to build something realistic with micropython on *any* platform for several reasons.
#VM:
- string interning is actually bad. =>
I was a hot debate at some point. Actually I think there are (...) usecases where users do want to be able to customise interning for literal strings. especially when doing module unloading after lazy loading on very low mem platform or for giving room to a compression scheme or translating engine
- lack of finalizers that's even worse.
can quickly become a real problem to solve common networking/clustering/object proxy task, that is really not good for an iot platform
- random disregard of some basic Python functions, ok it is called "The MicroPython Language" it's not "a" Python flavour but who need another crippled spinoff with no stdlib ?
There was only 2 small things to fix to be Python compliant (single inheritance model) and opening the way to promote a pure python stdlib but nothing was ever done to upstream fix that. Why ?
- the lack of documented code for building user modules ( objects AND classes ) alongside with the strain imposed on user C code ( forced removal of the use of #warning, unfriendly compiler/preprocessor flags mixup).
- no developper global switch to show TODO as warnings ( i'm ok to try to fix things when i can see them in the config used for current target i'm in no mood losing time on rgrep+volatile triaging ).
- no proper options for embedding as a library ( not even an option to create a single C file for any given port as a workaround).
- no easy to use protected panic handler.
- MicroPython dependency on C stack.
it's real, see further explanation and i can elaborate, C is not always nice with all design
- the github requests/issues swarm is a mess, unless someone start triaging instead of stalling i see no future there.
i have a joke on that but i'll restrain myself
#politics:
- frivolity and features frenzy eating time that could have been spent fixing above points to let MicroPython out of the toybox. Pushing away people for reasons unrelated to code who can *do* or could have done that in a jiffy.
- lack of an universally qualified reviewer, since obviously absolutely everything must pass by one way narrow passage approval on any subject ( that is intentionally sarcastic as a reaction to #5111 )
that was exclusively reserved to @dpgeorge, sorry i thought it was an EVIDENCE, he's a grown up (like me) and can defend himself as i do for his open indirect critiscim about my PR for solving a problem that isn't even mine in first place
#Every day use on major platforms:
unix: EINTR auto-retry is not handled on unix port ( cpython does -> script compatibility ).
esp8266: firmware must give MicroPython time not the other way around -> network problems (c-stack less /pre-emption required).
i did not put links but i think all points above are already referenced and some for a quite long time now. i'm sure more can be added so i guess it's not just "who" but:
"how many who and where".
*all links are now referenced in javascript port "checklist"
PS: What has the removal of nlr has to do with emscripten ? could you elaborate here
https://github.com/micropython/micropython/issues/4993?
the removal of NLR is only required for clang 10 upstream, standard emscripten use a custom clang 8