You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I've expanded the wiki stubs crudely. Damien do you want any of this info here ?
Specifically I am thinking:
only short overview.
Concentration on the pyb module and/or other aspects like that ?
how to handle different architectures and chip variants.
e.g. if we did the '407' we might add camera capabilities. For themonster 386 based SOC I pointed to the other day - well its almost a completely diff codebase.
Thanks Mark! How do you imagine the wiki being used? I want to put tutorials and documentation on the micropython.org website. Here on github we have the code and the bug tracking system.
Maybe on the github wiki we can explain the core implementation of the code and how it works. And also the different variants (unix, stm, etc) and what work is needed.
the github wiki system relies on gollum a simple but yet powerful wiki
system based on git.
It can be used with a set of different markup languages including org-mode
(for the emacs friends among us ;) ).
More important, since it relies on git, you can pull it in the same way
like the source code and work offline on it.
It could become the companion of the source code for devs keeping all kind
of notes, infos, and help in a single repro.
Devs could easily pull both wiki and code and work offlline on it until
they finally pushing it back.
Not sure how flexible the wiki is in terms of branches and forks but maybe
that is not such a big issue for a wiki.
Thus, I would vote to use the github wiki as a pure dev wiki. Adding all
kind of stuff which couldn't be discussed via the bugtracker.
E.g. internal structures, internal implementations, links for further
reading, porting infos, roadmaps, contact details, explanations for certain
design decisions, coding style rules and stuff which comes handy during
coding (offline), etc.
Thanks Mark! How do you imagine the wiki being used? I want to put
tutorials and documentation on the micropython.org website. Here on
github we have the code and the bug tracking system.
Maybe on the github wiki we can explain the core implementation of the
code and how it works. And also the different variants (unix, stm, etc) and
what work is needed.
—
Reply to this email directly or view it on GitHubhttps://github.com/dpgeorge/issues/6#issuecomment-31328175
.
It sounds like we should pitch it at dev support and put everything else on the main site.
So discussions, collations of information about the various topics and problems that need to be solved.
It can also hold the recommended approaches.
e.g. for making a new port or adding a c lib or...
Activity
dpgeorge commentedon Dec 29, 2013
Thanks Mark! How do you imagine the wiki being used? I want to put tutorials and documentation on the micropython.org website. Here on github we have the code and the bug tracking system.
Maybe on the github wiki we can explain the core implementation of the code and how it works. And also the different variants (unix, stm, etc) and what work is needed.
torwag commentedon Dec 30, 2013
Hi,
the github wiki system relies on gollum a simple but yet powerful wiki
system based on git.
It can be used with a set of different markup languages including org-mode
(for the emacs friends among us ;) ).
More important, since it relies on git, you can pull it in the same way
like the source code and work offline on it.
It could become the companion of the source code for devs keeping all kind
of notes, infos, and help in a single repro.
Devs could easily pull both wiki and code and work offlline on it until
they finally pushing it back.
Not sure how flexible the wiki is in terms of branches and forks but maybe
that is not such a big issue for a wiki.
Thus, I would vote to use the github wiki as a pure dev wiki. Adding all
kind of stuff which couldn't be discussed via the bugtracker.
E.g. internal structures, internal implementations, links for further
reading, porting infos, roadmaps, contact details, explanations for certain
design decisions, coding style rules and stuff which comes handy during
coding (offline), etc.
Just my two cents
Torsten
On 30 December 2013 00:28, Damien George [email protected] wrote:
Neon22 commentedon Dec 30, 2013
It sounds like we should pitch it at dev support and put everything else on the main site.
So discussions, collations of information about the various topics and problems that need to be solved.
It can also hold the recommended approaches.
e.g. for making a new port or adding a c lib or...
[later]..Done.
atmel-samd: Update bossac_osx with one that works.
Merge pull request micropython#6 from emfcamp/fix-tests
Merge pull request #6 from mwelling/master
Merge pull request #6 from adafruit/master
Merge pull request #6 from adafruit/master
Merge pull request micropython#6 from robert-hh1/master
sharpdisplay: Fix memory corruption across soft-reset
Merge pull request micropython#6 from kwagyeman/openmv
Merge pull request micropython#6 from adafruit/main
py/repl: Don't read past the end of import_str.
3 remaining items
extmod/zephyr_ble: Fix recursion prevention deadlock in work queue.
docs: Update status with Fix #7 and Issue #6 details.
docs: Verify Fix #7 working, confirm Issue #6 persists.
Fix 2 NULL pointer vulnerabilities in lwIP network stack
extmod/zephyr_ble: Fix double-unref crash during deinit.
docs: Add Zephyr BLE integration status report.
extmod/zephyr_ble: Fix BLE IRQ handler reinit on Pico W.
extmod/zephyr_ble,ports/rp2: Fix BLE connection callbacks on Pico W.
docs: Update CLAUDE.local.md to reflect current Zephyr BLE status.
py/repl: Don't read past the end of import_str.