MicroPython Forum (Archive)

That was expected though when adding a quite a lot of documentation in one go. Personally I'd had that split up in smaller dedicated commits, leading to less parts having a chance of getting outdated.

deshipu wrote: ↑

Sat Jan 16, 2021 9:55 am

So sad it will be outdated even before it merges.

On second thought: can you elaborate what you mean specifically? The last version has lots of the specifics moved out of it and mentions either general things or dedicated core ones which aren't going to change anytime soon? Only thing at first sight is that it doesn't specifically mention one can use C++ for user modules, but the README it links to does have that information.

stijn wrote: ↑

Sun Jan 17, 2021 9:50 am

deshipu wrote: ↑

Sat Jan 16, 2021 9:55 am

So sad it will be outdated even before it merges.

On second thought: can you elaborate what you mean specifically?

It's the fate of any large project in which the coders refuse to update the documentation as they make changes, instead relying on others to catch differences and fix it.

Well, ok, but you can't expect people writing new code which affects docs which aren't merged yet to go and update those docs right? Anyway, I thought you had something specific in mind perhaps in that PR which is now out of date.

stijn wrote: ↑

Wed Jan 20, 2021 9:24 am

Well, ok, but you can't expect people writing new code which affects docs which aren't merged yet to go and update those docs right?

Of course I can. And I do. In most projects I have worked on, a patch that breaks documentation would never pass the review. And this can even be automated (Sphinx can run your code examples as unit tests, and you can setup your continuous integration to refuse a merge if those don't pass).

That is a reason to keep the documentation in the same repository as the code, by the way.

Sorry I'm confused - I'm still talking about the outstanding documentation PR https://github.com/micropython/micropython/pull/6543 which is not merged yet. You're talking about existing documentation, right? Yes of course that shouldn't break.

But my point was: suppose I change something in MicroPython which makes documentation in other PRs invalid I cannot possibly go and check them all and try to fix them? At that point shouldn't it be the job of the other PR authors to do that?

No, of course, it's the job of the authors of those other pull requests to resolve any conflicts before merging.

From https://www.raspberrypi.org/blog/raspbe ... w-on-sale/
Meet Raspberry Silicon: Raspberry Pi Pico now on sale at $4
21st Jan 2021

...
For beginners, and other users who prefer high-level languages, we’ve worked with Damien George, creator of MicroPython, to build a polished port for RP2040; it exposes all of the chip’s hardware features, including our innovative PIO subsystem.
...

And here is https://github.com/raspberrypi/micropython
https://www.raspberrypi.org/documentati ... g-started/

P.S. I agree that Micropython needs more people.