pmp-p wrote: ↑Fri Sep 20, 2019 2:19 am
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.
I agree - like I said, this whole area is exciting for MicroPython. But like anything else, it's all tradeoffs. Whether it be developer time, how features are implemented, etc. Sadly, you just can't build a thing that does everything perfectly.
MicroPython was built to run on microcontrollers. It does an amazingly good job of that. It makes difficult design decisions that will fundamentally always revolve around saving RAM and ROM. Where possible, flexibility exists to enable/disable things, but microcontrollers will always come first.
Many people want MicroPython to be other things too. It's great when that works, but sadly sometimes it doesn't.
pmp-p wrote: ↑Fri Sep 20, 2019 2:19 am
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.
stjin and pythoncoder have already covered this well, but I feel strongly about this too. Have a search on youtube for presentations from people who have built real products. Read about the hundreds of thousands of children who've learnt robotics for the first time using MicroPython (and CircuitPython). The scientists who use MicroPython every day in their experiments and spent their valuable funding money and time on other more useful things than writing C code or buying very expensive test equipment. You can even watch the creator of MicroPython talk about the ESA using it. Or vendors like Digi and ST who sell products based on MicroPython.
pmp-p wrote: ↑Fri Sep 20, 2019 2:19 am
#VM:
- string interning is actually bad.
I'm genuinely curious as to what you mean. As a _user_ of MicroPython, I'm not sure I've ever written any code that could notice that string interning exists. As a developer, other than one time I had to figure out how to make a MP_QSTR_ value that had a special character in it, it's never been an issue. It... just works? Seriously, considering how much goes on behind the scenes to make interning work, I always thought of this as quite an achievement.
And more importantly, string interning saves bytes. Precious bytes! And with interning it's both RAM _and_ ROM. Do you have an alternative approach in mind?
pmp-p wrote: ↑Fri Sep 20, 2019 2:19 am
- lack of finalizers that's even worse.
I think there's some confusion about this feature.
Finalisers in MicroPython work. They do exactly what you need (call __del__ at some point in the future when all references are gone), for any type (user defined or written in C),
but only if you enable it when allocating the instance. Support for it is enabled on most ports, and most ports actually rely on it for a few features.
The only thing that is missing is a way for a user-defined type to indicate that it should be created with finaliser support by default. But how to do this?
stinos's suggestion in the PR is correct -- you just enable it always. Done! Send PR!
But this perfectly highlights the "micro" of MicroPython. A vanishingly small number of users of MicroPython want this feature. So should they pay the cost on every object creation (and I believe there's also the memory overhead required to remember that the block has a finaliser). This seems completely obvious to me, the answer is definitely no.
OK, so maybe you adapt stinos' suggestion slightly and somehow figure out whether the object being created has a __del__ method. But now you've just moved the performance cost from the GC to object creation (at least you've saved the memory cost though).
MicroPython has a solution to this -- feature flags. So, if finalisers are important to you, the way to progress this issue is to add an additional flag, dependent on MICROPY_ENABLE_FINALISER, perhaps named MICROPY_ENABLE_FINALISER_ALL_OBJECTS, that conditionally does stinos' suggestion. That way a port (or a custom build) can enable it. And then perhaps there can be a discussion about enabling it by default in the Emscripten (and maybe even Unix) ports?
This would be much easier than demanding a roadmap from the maintainer for a feature that likely isn't on their radar.
pmp-p wrote: ↑Fri Sep 20, 2019 2:19 am
- 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 ?
I've seen four really good reasons why MicroPython is not 100% CPython compatible:
- Saving bytes. (This is the big one. microcontrollers.)
- It just isn't done yet. (Some features are hard to implement!)
- It isn't a feature that makes sense for microcontrollers (i.e. very difficult to implement)
- A suitable compromise can be reached (i.e. partial compatibility). Most people don't notice, many people don't need it anyway, very few need actual workarounds, and extremely few complain.
f-strings are worth discussing here. They're clearly a great feature. Once we can move past the bytes cost (compatibility with a growing amount of existing code is a great reason, notwithstanding the two existing ways of doing string formatting), the first part is someone needs to actually do it. #4998 is a good PR, it got quick attention, it'll hopefully get merged once the (very reasonable and quite helpful) review comments are addressed. But the implementation is subtle, and the resulting CPython incompatibility is quite interesting.
It would be fantastic if f-strings could be implemented exactly like CPython, but then literal concatenation would have to move to the parser. See why it was moved to the lexer in the first place. This PR is making a compromise.
Back to your question. The answer to "who needs (this)"? Embedded developers who would otherwise be writing C.
To put it another way... I would still prefer to write C-style MicroPython than actual C (and sometimes I do occasionally need do this).
As for the stdlib... as MicroPython grows, to bigger ports with more functionality, I agree some of the stdlib functionality will become more relevant. asyncio is one that is personally relevant to me. The current implementation goes a long way (and there are excellent community-supported extensions and improvements), but it would be great to improve it. (I think the general point there though is... "PRs welcome!").
pmp-p wrote: ↑Fri Sep 20, 2019 2:19 am
- the lack of documented code for building user modules ( objects AND classes )
Yep, absolutely, the developer documentation could use some work. But other than the fact that whomever writes it first has to understand it, there's very few barriers here. Documentation PRs are always welcome. I'm excited to see where
viewtopic.php?f=3&t=6874&start=10#p39242 goes.
pmp-p wrote: ↑Fri Sep 20, 2019 2:19 am
- 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).
This has not been my experience, and I do not understand what you mean by the second part. I have worked on (professional) projects that embedded MicroPython, it's worked really well.
pmp-p wrote: ↑Fri Sep 20, 2019 2:19 am
- MicroPython dependency on C stack.
I agree, and clearly so does Damien -- see MICROPY_ENABLE_PYSTACK which resolves exactly this. It's not enabled by default yet for a couple of reasons (again, everything is tradeoffs, and there's still some more work to be done), but I can see it possibly becoming the default in the future.
And related, see MICROPY_STACKLESS. These two features go well together. (And they're _good_ features).
pmp-p wrote: ↑Fri Sep 20, 2019 2:19 am
- 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 ).
Couldn't agree more. It would be wonderful if there was a whole team of reviewers. One for every time zone, etc! But who? There are very few people contributing to the core on a regular basis, and it takes a lot for the owner of a project to (figuratively) hand over the keys.
Maybe if they weren't "universal" (in the sense that maybe you could have port-specific maintainers, etc). That would be great too, and probably easier to find such people.
I personally don't have a huge amount of experience with open source, but this is a fairly common situation in corporate software development too. There's always going to be some parts of the code base that have fewer "owners" than is ideal.
I'd be curious to hear any suggestions you have?
Re #5111 (and #4875), happy to send some private feedback as a neutral observer, but I don't think anyone was actually saying anything negative about #4875? #5111 is objectively a simple PR, and the current state of #4875 is a little hard to understand (this is true of any PR that goes through a lot of discussion).
It seems like you've already explained this there? Removing NLR means not having to use setjmp/longjmp. (NLR is a bit of a confusing term because it both refers to the overall feature (which may or not be implemented with setjmp), and also the "native" implementation of NLR (the alternative to setjmp)).