MicroPython Forum (Archive)

bitninja wrote: ↑

Wed Mar 27, 2019 9:48 pm

I find this funny ...

Nice ... not long ago someone mentioned 'having fun' as a good reason to use MicroPython. And see, here you have it.

If you choose to setup your own distro/community ... would it not be nice to find a name which actually makes you feel good about it? That tells something about your distro usp? Like Adafruit did with CiruitPython. They also copied the MicroPython project (hence, they also could have chosen PyCopy),...

Unless the thread objective is endless meta-discussion it might be helpful if you enumerated the "simple steps and decisions" you have in mind. It could be helpful indeed, but I've experienced oftentimes that it is very difficult to come up with a solution for non-existent problems. No one recogniz...

Ah, that indeed sounds logical. But what about the shared copyright statement in the documentation (more than one name)? Why is that, and ... does that last for long time too?

Well, I just dont understand and it seems odd. It seems to conflict with the MIT License. The copyright statement in the MIT License (as found in the root of the micropython repo) currently reads: 'Copyright (c) 2013, 2014 Damien P. George'. Should that not be updated to 'Copyright (c) 2013 - 2019 D...

At the bottom of the docs page on this url: http://docs.micropython.org/en/latest/
It mentions the following copyright statement ...

© Copyright 2014-2019, Damien P. George, Paul Sokolovsky, and contributors Last updated on 26 Mar 2019.

Is this correct? Anyone able to explain this?

@stijn
You are right. I rest my case. Everyones time is scarce ... mine too. Why bother ...

I don't think the problems for the no-firmware builders are difficult to solve. As long as the community wants it, and as long as the comunity does not dismiss every attempt with the 'minimal' dogma. I'm quite optimistic that with some simple steps and decisions, we can set out the path to make micr...

The other take-away from these tests is the performance of Viper. A penalty relative to assembler of well under 2 is astounding. Perhaps the figures for the faster options are dominated by a fixed overhead in doing a function call. The Viper emmitter performance results are indeed very impressive ....

Would this problem be avoided if the wiznet5k drive was written in python? Or would that have been impossible?