Unglaublich, sechs Jahre und immer noch kein supersimples Doku-Update.
-> Projekt wird von Leuten gesteuert, denen einiges egal ist. Ergo:
Micropython ist nichts fuer mich. Die lassen einen einfach hinten runter fallen.
Da "kehrt" keiner. Noch schoener ist das die Doku nicht mal konsistent ist.
Da micropython ja Open Source ist und Du das so auch umsonst bekommen hast steht es Dir frei, Dich dem Projekt zur Verfügung zu stellen und eine gute Doku dazu zu schreiben.
Da micropython ja Open Source ist und Du das so auch umsonst
bekommen
hast steht es Dir frei, Dich dem Projekt zur Verfügung zu stellen und
eine gute Doku dazu zu schreiben.
Sachen gibt's. Brrr
Das ist mir bekannt. Ich bin Open Source Fan der ersten Stunde. Aber so eine schlechte Doku habe ich noch nie gesehen. Blender z.B. hat eine belebte Versionsgeschichte. Aber die Blender Doku ist Gold dagegen. Ergo: Du benutzt kein Micropython, hast dir nicht die Muehe gemacht meinen Links zu folgen. Aber hier den Open Source White-Knight markieren und mit dem Beidhand-Schwert mal vorsorglich die Koeppe rollen lassen... Brrrrrrr!
Ausserdem hast Du ueberlesen, das ich (Micro-) Python Anfaenger bin und mir aufgrund der mangelden Anfaengerdoku Zeit und Wille fehlt. Da bleibe ich lieber bei anderen Loesungen.
Du hast Recht: Ich verwende kein Micropython.
Aber das ist nun mal meistens so bei Open Sorce. Doku schreiben ist unbeliebt und umsonst machen das nur die wenigsten gerne.
Wenn es dann endlich so aussieht, laeuft es dann auch:
...
<sch..ße formatierter code>
Und du bekommst es nicht einmal hin, hier im Forum die Code-Tags zu benutzen, um ihn lesbar zu machen. Aber die Klappe über andere aufreißen ...
Die Tags gibt es schon bedeutend länger als 6 Jahre.
Da micropython ja Open Source ist und Du das so auch umsonst bekommen
hast steht es Dir frei, Dich dem Projekt zur Verfügung zu stellen und
eine gute Doku dazu zu schreiben.
Echt jetzt?
Wenn man sich als Kunde die Doku selbst erarbeiten muss, dann ist das ein reichlich nutzloser Scheiss.
steht es Dir frei, Dich dem Projekt zur Verfügung zu stellen und
eine gute Doku dazu zu schreiben.
Diese Scheiße als Antwort wenn es um OpenSource geht kann doch keiner mehr hören.
Entweder bekommt man von OpenSource Projekten überhaupt keine Reaktion wenn man einen Patch senden möchte oder es wird ein Regelwerk auf den Tisch geschmissen dass dicker als die deutschen Steuergesetze ist. Anhand des Regelwerks muss man sich dann qualifizieren damit man nach ein paar Jahren den ersten trivialen Patch abliefern darf.
Dann wundern sich OpenSource-Projekte dass sie nur schwer Freiwillige finden. Die Mehrheit der OpenSource-Entwickler (60% - 80%) sind bezahlte Entwickler, keine Freiwilligen, weil freiwillig macht man den Zauber nur ungern mit.
Wenn man sich als Kunde die Doku selbst erarbeiten muss, dann ist das
ein reichlich nutzloser Scheiss.
...du und die anderen Meckerer habt das Prinzip von Open Source (noch ;-)) nicht verstanden! Es gibt keine "Kunden" die einen "Rechtsanspruch" auf irgendetwas haben, du bezahlst ja auch nicht für die Nutzung der Software, Dienstleistung o.ä..
Da micropython ja Open Source ist und Du das so auch umsonst bekommen
hast steht es Dir frei, Dich dem Projekt zur Verfügung zu stellen und
eine gute Doku dazu zu schreiben.
Ausserdem hast Du ueberlesen, das ich (Micro-) Python Anfaenger bin und
mir aufgrund der mangelden Anfaengerdoku Zeit und Wille fehlt.
...um so besser, eine Doku aus Sicht eines Anfängers ist vielleicht wertvoller als eine trockene Beschreibung von API-Aufrufen.
Dir fehlt "...Zeit und Wille...": zum Glück trifft dies nicht auf die Entwickler von Micropython im speziellen und Open Source im allgemeinen zu, denn dann hätte hier keiner etwas zum rummosern ;-)...
Entweder bekommt man von OpenSource Projekten überhaupt keine Reaktion
wenn man einen Patch senden möchte oder es wird ein Regelwerk auf den
Tisch geschmissen dass dicker als die deutschen Steuergesetze ist.
Anhand des Regelwerks muss man sich dann qualifizieren damit man nach
ein paar Jahren den ersten trivialen Patch abliefern darf.
Das ist ziemlicher Bullshit.
Man kann bei Micropython ziemlich einfach Doku-Patches einreichen und die sind auch sehr gerne gesehen.
Entweder bekommt man von OpenSource Projekten überhaupt keine Reaktion
wenn man einen Patch senden möchte oder es wird ein Regelwerk auf den
Tisch geschmissen dass dicker als die deutschen Steuergesetze ist.
Hast du es wirklich schon mal persönlich versucht oder hast du nur davon gehört?
AttributeError: 'Pin' object has no attribute 'low'
Man darf Fehlermeldungen auch verstehend lesen.
Daß Symbole nicht gefunden werden, wird Dir mit jeder anderen Programmiersprache auch passieren, wenn man sich wahllos was zusammen kopiert.
Es ist dann ein Leichtes, sich die Definitien anzuschauen und die passenden Symbole zu verwenden oder sich selber zu definieren. Man muß es nur wollen.
Aber hier den Open Source White-Knight markieren
und mit dem Beidhand-Schwert mal vorsorglich die Koeppe rollen lassen...
Das Problem ist einfach deine Ausdrucksweise. Mag ja sein, dass die Doku nicht gut ist, aber alleine die Überschrift ist schon echt das letzte. Mir ist auch nicht ganz klar, was du damit erreichen willst, hier über die Micropython-Doku zu schimpfen und feierlich zu erklären, dass du es nicht benutzen wirst.
Dann wundern sich OpenSource-Projekte dass sie nur schwer Freiwillige
finden. Die Mehrheit der OpenSource-Entwickler (60% - 80%) sind bezahlte
Entwickler, keine Freiwilligen, weil freiwillig macht man den Zauber nur
ungern mit.
Das Problem ist einfach deine Ausdrucksweise. Mag ja sein, dass die Doku
nicht gut ist, aber alleine die Überschrift ist schon echt das letzte.
Mir ist auch nicht ganz klar, was du damit erreichen willst, hier über
die Micropython-Doku zu schimpfen und feierlich zu erklären, dass du es
nicht benutzen wirst.
Das Problem ist, dass es ganz einfach eine Lüge ist.
Die Micropython-Doku war hier ja nicht das Problem, sondern die Lösung.
Das Problem lag in irgendeinem steinalten Tutorial von irgendjemandem.
Wenn man sich als Kunde die Doku selbst erarbeiten muss, dann ist das
ein reichlich nutzloser Scheiss.
...du und die anderen Meckerer habt das Prinzip von Open Source (noch
;-)) nicht verstanden! Es gibt keine "Kunden" die einen "Rechtsanspruch"
auf irgendetwas haben, du bezahlst ja auch nicht für die Nutzung der
Software, Dienstleistung o.ä..
...du und die anderen Meckerer-Bemeckerer haben das Prinzip von Dokumentation und Anleitungen nicht verstanden!
Völlig egal wieviel oder womit ein Gerät bezahlt wurde, ohne das KnowHow der Bedienung ist es komplett nutzlos.
Soll sich beispielsweise ein Zahnarzt die Bedienungen seiner Gerätschaften erst durch "Try und Error" an seinen Patienten erarbeiten?
Selbst solche simple tools wie 'ls' kommen mit man-page oder --help Hilfeoption daher, da verlangt keiner, das der Benutzer sich durch den source quälen muß um zu verstehen wie das Gedöhns bedient werden will.
Egal ob bezahlt oder nicht, wenn der Hersteller nicht erklären mag, wie seine Gerätschaft zu bedienen ist, kann er sich das Ganze dahin schieben, wo die Sonne niemals scheint!
Völlig egal wieviel oder womit ein Gerät bezahlt wurde, ohne das KnowHow
der Bedienung ist es komplett nutzlos.
Als Softwareentwickler ist man mit etwas Erfahrung gewohnt, daß Dokumentation unvollständig, fehlerhaft oder gar nicht vorhanden ist. Und man kommt trotzdem zurecht, einfach, weil man gelernt hat, die relevanten Stellen in fremdem Code zu finden.
Völlig egal wieviel oder womit ein Gerät bezahlt wurde, ohne das KnowHow
der Bedienung ist es komplett nutzlos.
Du hast die Wahl, es zu benutzen, auch eine Doku dazu zu schreiben oder es ganz sein zu lassen.
Und wenn Du SW nur mit einer gruendlichen Anleitung benutzen kannst, musst Du eben etwas mehr (als gar nichts) dafuer auf den Tisch legen. So einfach ist das.
Soll sich beispielsweise ein Zahnarzt die Bedienungen seiner
Gerätschaften erst durch "Try und Error" an seinen Patienten erarbeiten?
Der Zahnarzt zahlt eine Menge fuer seine Geraetschaften und darf daher mit Recht auch etwas dafuer erwarten.
Schade das viele hier nicht viel mehr als die Ueberschrift lesen und dann gleich draufhauen was das Zeug haelt. Ich wollte lediglich auf eine chaotische Anfaenger-doku hinweisen. Der von mir bemaengelte Teil, war der erste Link den mir G. anzeigte. Wenn der sooo veraltet ist, warum bekommt er da dieses Ranking?
Egal, ich gebe es auf und verzichte in Zukunft auf interessante, ambivalente Ueberschriften. Das ist ja wie wie ein Loch im Sack mit dem Trollfutter.
Falls einer der Moderatoren ein Padlock uebrig hat fur diesen Fred...bitte.
Schade das viele hier nicht viel mehr als die Ueberschrift lesen und
dann gleich draufhauen was das Zeug haelt. Ich wollte lediglich auf eine
chaotische Anfaenger-doku hinweisen. Der von mir bemaengelte Teil, war
der erste Link den mir G. anzeigte.
Schade das viele hier nicht viel mehr als die Ueberschrift lesen und
dann gleich draufhauen was das Zeug haelt. Ich wollte lediglich auf eine
chaotische Anfaenger-doku hinweisen. Der von mir bemaengelte Teil, war
der erste Link den mir G. anzeigte. Wenn der sooo veraltet ist, warum
bekommt er da dieses Ranking?
Achso, die anderen sind schuld, wenn du auf ein Tutorial aus den frühen Prototypjahren der Micropython-ESP-Ära reinfällst und nicht einmal das Datum prüfen kannst und dann behauptest die Micropython-Doku wäre schlecht.
MaWin O. (mawin_original) riss das einfach aus dem Satz
Egal, ich gebe es auf und verzichte in Zukunft...
und basht dann gnadenlos.
Aber besser so, da hast du voellig recht. Besser als viele Kommentare die an Sadismus grenzen und niveaumaessig oft unter dem liegen, was KI so liefert. Btw. das ist der Beweis: Wir leben in einer virtuellen Realitaet.
Als Softwareentwickler ist man mit etwas Erfahrung gewohnt, daß
Dokumentation unvollständig, fehlerhaft oder gar nicht vorhanden ist.
Und man kommt trotzdem zurecht, einfach, weil man gelernt hat, die
relevanten Stellen in fremdem Code zu finden
Ähm, wenn dir der Sourcecode vorliegt...
(übrigens ist es keine Gute Idee, im Source nach undokumentiertem Verhalten zu suchen, um es dann zu nutzen, denn es kann Absicht sein, dass es nicht dokumentiert wurde, oder schlicht fehlerhafter code und demnâchst korrigiert).
Aber heutige Programmierhansel kennen nicht mal die Basics.
Nachdem ja nun geklärt ist, dass es vielleicht nicht die hellste Idee war, veraltete Doku rauszusuchen um sich dann hier aufzuspielen und sich bitterlich drüber zu beschweren, dass die veraltete Doku veraltet ist, möchte ich zu diesem Einwurf noch kurz etwas schreiben:
Entweder bekommt man von OpenSource Projekten überhaupt keine Reaktion
wenn man einen Patch senden möchte oder es wird ein Regelwerk auf den
Tisch geschmissen dass dicker als die deutschen Steuergesetze ist.
Anhand des Regelwerks muss man sich dann qualifizieren damit man nach
ein paar Jahren den ersten trivialen Patch abliefern darf.
Meine Erfahrung ist: gerade bei trivialen Fixes werden die Pull-Requests in der Regel zeitnah und ohne weitere Umstände angenommen und die Änderung gemerged – ohne dass ich vorher was mit dem Projekt zu tun gehabt hätte. Gibt natürlich auch Leute, die auf ihrem Kram sitzen wie die Glucke auf den Eiern, aber das ist eher selten.
Selbst wenn ich auf die Idee käme, eine nur als Binary vorliegende Library zu nutzen, würde ich selbstverständlich in die begleitende Headerdatei reinsehen. Das macht der Compiler schließlich auch.
Aber heutige Programmierhansel kennen nicht mal die Basics.
Das ist ja der Punkt. (Solltest Du mich mit "heutige Programmierhansels" meinen, liegst Du sehr, sehr weit daneben)
steht es Dir frei, Dich dem Projekt zur Verfügung zu stellen und
eine gute Doku dazu zu schreiben.
Diese Scheiße als Antwort wenn es um OpenSource geht kann doch keiner
mehr hören.
Doch, ich schon. Weil sie wahr ist. Die einzigen, die das nicht "mehr hören" wollen, sind jene, die sich zwar gerne an OpenSource bedienen, allerdings nichts zurückgeben und beitragen wollen. OpenSource lebt aber vom Mitmachen, nicht von mosernden Schmarotzern. Und in dem Fall des TO würde es vermutlich reichen, ein Issue im Bugtracker [1] zu eröffnen.
Abgesehen ist sie bei kommerzieller Software häufig auch nicht besser, zumal der eine oder andere Softwarehersteller dabei versucht, keinerlei Informationen über die interne Funktion seiner Software herauszugeben -- oder auch nur über Schnittstellen und Datenformate. Schließlich müssen seine hochwichtigen Geschäftsgeheimnisse gewahrt bleiben.
Entweder bekommt man von OpenSource Projekten überhaupt keine Reaktion
wenn man einen Patch senden möchte oder es wird ein Regelwerk auf den
Tisch geschmissen dass dicker als die deutschen Steuergesetze ist.
Komisch, ich selbst habe bei allen OpenSource-Projekten, bei denen ich bislang Patches eingereicht habe, vollkommen andere Reaktionen erlebt. Vielleicht liegt es aber auch daran, wie man die Leute anspricht.
Mir ist auch nicht ganz klar, was du damit erreichen willst, hier über
die Micropython-Doku zu schimpfen und feierlich zu erklären, dass du es
nicht benutzen wirst.
Er schimpft ja nicht einmal über die Micropython-Doku. Er schimpft über eine uralte Dokumentation von irgendeinem Dritten und war dabei sowohl zu dumm, den Footer der Seite zu lesen, als auch zu dumm, die offizielle Doku zu finden und zu lesen. Da [1] steht nämlich ausdrücklich drin, daß es die Methoden Pin.low() und Pin.high() durchaus noch gibt, aber nur auf einigen ganz bestimmten Plattformen -- die ebenfalls namentlich aufgeführt sind.
Komisch, ich selbst habe bei allen OpenSource-Projekten, bei denen ich
bislang Patches eingereicht habe, vollkommen andere Reaktionen erlebt.
Vielleicht liegt es aber auch daran, wie man die Leute anspricht.
Behauptest Du so flockig. Das kann man glauben, hmm, muss man aber nicht.
Komisch, ich selbst habe bei allen OpenSource-Projekten, bei denen ich
bislang Patches eingereicht habe, vollkommen andere Reaktionen erlebt.
Vielleicht liegt es aber auch daran, wie man die Leute anspricht.
Hier gehts doch um Doku um nicht um Patches!
Wenn ich mal in mein Fachbuchliteraturregal schaue, finden sich darin ausschliesslich Bücher zu OpenSource-Software (Gimp, Java,Python) und Grundlagen (Schaltungstechnik,FPGA, Mathematik, Engineering, Standards, ARM). Die komerzielle eingesetzte Software (bspw. Altium) dagegen ist mit online-Hilfetexten, intuitive Benutzerführung und Schulungen ausreichend abgedeckt. Auch die, die man kostenlos hintergeworfen bekommt (FPGA toolchains wie Quartus, Vivado).
Anderswo ist auch nicht anders, will man brauchbare Fachliteratur um sich um komplexere OpenSource Software einzu arbeiten, kauft man sich Bücher von Profis. Und man liest (abonnierte) Fachmagazine. Mit denen ist man auch als Windows-Anwender auf der Höhe der Zeit.
Open source lebt eben nicht von der Community, die sich selbst ausbeutet, sondern von den ganzen Freiberuflern/KMU die opensource für zahlende Kunden anpassen, einsetzen, schulen. Und von einem Bildungssystem, das Studenten und Doktoranden durchfüttert und Zugang zu Computernetzen ermöglicht.
Wirklich "Kostenlos" ist nur die Raubkopie und der gestohlenen Rechner.
Nö, eher nicht.
Python wird als Scriptsprache für die Büro/Labor-Automatisierung eingesetzt und mikro-python im embedded Bereich durch Ingenieure mit Elektrotechnik/Maschinenbau/Medizintechnik/physik-abschluss.
Skripting wie die klassischen DOS-Batches sind IMHO keine Softwar-entwicklung sondern 0815 Handwerkszeug.
Ingenieure wollen sich nicht mit irgendwelchen Interpreter/Parser/compilerbau-scheiß im Detail auseinandersetzen, die wollen schlicht, das ihr Gerät funktioniert.
Anderswo ist auch nicht anders, will man brauchbare Fachliteratur um
sich um komplexere OpenSource Software einzu arbeiten, kauft man sich
Bücher von Profis. Und man liest (abonnierte) Fachmagazine. Mit denen
ist man auch als Windows-Anwender auf der Höhe der Zeit.
Habe ich bisher noch NIE benoetigt. Micropython wuerde hier eine Ausnahme bilden.
Darauf verzichte ich aber lieber komplett zugunsten anderer, besser organisierten, Loesungen.
Fuer GIMP benoetige ich keine Anleitung, das finde ich intuitiv. Genauso wie bei Blender3D/Freecad/Solvespace gelegentliches Gockeln reicht. Andere OpenSource Anwendungen haben eine aufgeraeumte API, da kommt man schon mit einem Blick in die Header Files weiter (z.B. Arduino Dumb display, Armory3D [fuer Haxe Spezies]...)
Buecher kaemen nur in Frage bei Anwendungen die ich seltener benoetige. Macht aber nur eingeschraenkten Sinn bei der schnellen Entwicklung. Beim zweiten Blick in das Buch ist es schon veraltet. Oder man merkt direkt nach dem Kauf das es ein Fehlgriff war. Dafuer sind mir schon die Baeume zu schade und meine Knete erst recht. Was Fachmagazine angeht: Da gibt es leider seit Jahren keines mehr, das es wert waere privat zu abonnieren. Sieht man schon an deren Internetschnipseln. Heutigen Redakteuren faellt es schon schwer eine Schlagzeile ohne Rechtschreibfehler oder unertraeglichen Neusprech zu veroeffentlichen.
Na, endlich mal wieder ein Opfer zum Profilieren gefunden? Dann legst
du sogar noch einen nach und beleidigst mich auch gleich doppelt.
Kleingeist.
Ja, du armes armes Opfer.
Du bist aber auch ein armes armes armes Opfer.
Du bist wie eines dieser Kinder, was auf dem Schulhof herumläuft und alle anschreit und beleidigt und dann vollkommen perplex ist, wenn es eine Schelle bekommt.
Komisch, ich selbst habe bei allen OpenSource-Projekten, bei denen ich
bislang Patches eingereicht habe, vollkommen andere Reaktionen erlebt.
Vielleicht liegt es aber auch daran, wie man die Leute anspricht.
Hier gehts doch um Doku um nicht um Patches!
In der Regel liegt die Doku bei OSS-Projekten unter /doc oder an ähnlich beschrifteter Stelle im Verzeichnisbaum, und ist dort genauso bearbeitbar, wie alle anderen Teile des Projekts auch.
Selbst der im Eingangsbeitrag verlinkte Workshop bot die Möglichkeit (der mit „Edit on Bitbucket“ beschriftete Link oben rechts), bevor das Projekt vor sieben Jahren(!) aufgegeben worden ist.
Habe ich bisher noch NIE benoetigt. Micropython wuerde hier eine
Ausnahme bilden.
Darauf verzichte ich aber lieber komplett zugunsten anderer, besser
organisierten, Loesungen.
Doch, ich schon. Weil sie wahr ist. Die einzigen, die das nicht "mehr
hören" wollen, sind jene, die sich zwar gerne an OpenSource bedienen,
allerdings nichts zurückgeben und beitragen wollen. OpenSource lebt aber
vom Mitmachen, nicht von mosernden Schmarotzern. Und in dem Fall des TO
würde es vermutlich reichen, ein Issue im Bugtracker [1] zu eröffnen.
Du musst dir im Klaren sein, dass das open source ist. Das programmieren Leute, die gerne hacken und es in ihrem Job nicht können, weil sie dort sauber und transparent mit Dokumentation arbeiten müssen, was ihnen stinkt.
Deshalb suchen sie sich ein Projekt, um ihren Spieltrieb auszuleben, programmieren dann ohne Konzept wird durch den Garten, laden es auf GITHUB hoch und waren auf Zutimmung, um ihr Ego zu befriediegen. Haben sie keine Lust mehr, rennen sie weg und machen was anderes. Das Projekt verwaist.
In seltenen Fällen kommt dann etwas bei raus, was andere greifen es auf und vergrößern das Chaos, weil sie nicht alles verstehen, was sie da haben. Einige sorgen in solchen Projekten für Ordnung, aber die Zahl der Chaosstifter ist generell höher.
Open Source Software : Friss Vogel oder stirb!
(oder ziehe aus und lasse dir kostenpflichtig etwas auf den Leib schneidern)
Hättest vielleicht doch mal den Thread lesen sollen, in den du schreibst. Dann wäre dir vielleicht aufgefallen, dass deine Antwort mit dem zugrundeliegenden Problem so gar nichts zu tun hat.
Da sein Gewäsch auch mit der Realität von Open Source exakt gar nichts zu tun hat, ist stark zu bezweifeln, ob ihm -unter welchen Bedingungen auch immer- irgendwas hätte auffallen können.
