Page 1 of 2
Pycopy, "Advanced MicroPython fork" by pfalcon
Posted: Thu Dec 20, 2018 9:53 pm
by pfalcon
There's information here and there on the forum, this is dedicated thread to it.
As a contributor of 30% of the commits, and the author of many important subsystems in MicroPython, I have my repository at
https://github.com/pfalcon/micropython . The fork exists for a year now. Well, it actually exists for 5 years, except during initial 4 years, 95% of changes were going directly to upstream.
The focus of the port is:
- Finishing/making complete subsystem/features started in the upstream
- Optimizations
- More complete documentation (at http://pycopy.readthedocs.io/)
- Exploring new "computer science"-level ideas (new for MicroPython, not computer science )
There's a short "fork FAQ" in the README of the repository. More detailed background information about fork is in the
viewtopic.php?f=2&t=4358 thread.
For as long as possible (was possible for a year), the fork is rebased on the upstream. As much as resources allow, I submit changes back to upstream, but my resources for that are limited, and pipe there is narrow.
Re: Pycopy, "Advanced MicroPython fork" by pfalcon
Posted: Fri Dec 21, 2018 9:59 am
by uCTRL
Micropython sounded promising at one stage.
Now with so many "fragmented" (no pun intended) ports, it looks more like a train-wreck.
At least pfalcon has admitted some sad truths about state of micropython affairs, while Damian has been doing ?????
Re: Pycopy, "Advanced MicroPython fork" by pfalcon
Posted: Sat Dec 22, 2018 11:17 am
by pythoncoder
uCTRL wrote: ↑Fri Dec 21, 2018 9:59 am
...it looks more like a train-wreck...
I suggest you define exactly which aspect of the project you regard as a "train-wreck".
Forks are a feature of open source: anyone can fork a project. The existence forks therefore has no bearing on the quality of the upstream code. I lack practical experience of forks of MicroPython so I can't comment on their quality (although I'd expect Paul's to be excellent).
I do have substantial experience of the official version on the Pyboard and the ESP8266. In my view, on those platforms it's a product of the highest quality. Stability and performance are first class and development is done to professional standards.
Re: Pycopy, "Advanced MicroPython fork" by pfalcon
Posted: Sat Dec 22, 2018 8:33 pm
by pfalcon
Gentlemen, let's please keep this thread focused on the technical matters, there're other thread(s) for other matters.
And as was said, multitude of forks is unlikely a sign of "train wreck". Otherwise, it's an ecosystem/community, where everyone does what they can. Yes, it would be better if different parties cooperated more, not less, but doesn't always happen like that.
Re: Pycopy, "Advanced MicroPython fork" by pfalcon
Posted: Sat Dec 22, 2018 9:24 pm
by pfalcon
One feature of my port is micropython-dev, described here:
viewtopic.php?f=2&t=5711
Re: Pycopy, "Advanced MicroPython fork" by pfalcon
Posted: Sun Dec 23, 2018 5:45 pm
by pfalcon
Pycopy is needed for the latest version of uasyncio, again:
viewtopic.php?f=15&t=85&p=32852#p32852
Re: Pycopy, "Advanced MicroPython fork" by pfalcon
Posted: Tue Jan 22, 2019 11:27 pm
by pfalcon
As some stats, as of now Pycopy is 138 commits ahead of MicroPython upstream. The latest change made: fix for overbloated allocation of interned strings in chr(), as reported in
https://github.com/micropython/micropython/issues/4422
Re: Pycopy, "Advanced MicroPython fork" by pfalcon
Posted: Sat Feb 02, 2019 8:34 am
by pfalcon
Pycopy now has a fix for long-standing issue with the uasyncio framework, more details in
viewtopic.php?f=15&t=85&p=33767#p33767
Re: Pycopy, "Advanced MicroPython fork" by pfalcon
Posted: Sat Feb 02, 2019 4:57 pm
by fos
How does Pycopy compare to the mainstream 1.10 that was recently released.
I am most interested in string handling and memory usage/capacity for strings.
Thank you,
v/r
Jeff
Re: Pycopy, "Advanced MicroPython fork" by pfalcon
Posted: Sat Feb 02, 2019 9:36 pm
by pfalcon
Well, description and README at
https://github.com/pfalcon/micropython provide the info how this fork is maintained - it's rebased on the mainline regularly. That means it has everything which 1.10 has, has further changes in the master branch after the release, and on top of that, has ~150 more changes.
Regarding strings, my forks features less aggressive string interning (interned strings can never be freed), and memory usage optimization for string formatting operations.