Posts by __blackjack__

    LinAdmin Fehler und Warnmeldungen im Kernel-Log bedeuten nicht, dass das insgesamt nicht fehlerfrei läuft. Das ist eben die Relitätsferne, zu fordern das solche Meldungen komplett verschwinden müssten. Warnungen sind erst einmal nur genau das: das könnte ein Problem sein, muss es aber nicht. Und auch Fehlermeldungen bedeuten nicht zwangsläufig, dass am Ende tatsächlich etwas nicht funktioniert. Das kann auch das Resultat davon sein, dass ein Weg versucht wurde, der zu einem Fehler führte der bemerkt (und protokolliert) wurde, um daraufhin dann einen alternativen Weg zu beschreiten, der funktioniert. Es gibt bei Hardware beispielsweise nicht immer einen Weg um ohne es einfach auszuprobieren festzustellen welcher konkrete Chipsatz verbaut ist. Da probiert man dann Optionen durch und hat halt auch Fehler bis man den passenden Code zum passenden Chip hat. Wenn man die nicht protokolliert, macht man die Fehlersuche falls Probleme auftreten, schwierig bis unmöglich.

    Das hat nix mit Serial zu tun und die Klammern sind a) Teil des serialisierten JSON und b) sind die auch wichtig, denn es könnten ja auch andere Klammern sein für ein JSON-Array statt eines JSON-Objekts. Und im Grunde auch einfach ein einzelner Wert ohne Klammern.


    Das ist ja letztlich ein in ein weiteres Protokoll verpacktes HTTP und da ist der MIME-Typ letztlich auch egal wenn es darum geht was als Nutzlast dann gesendet wird: das sind dann immer einfach binäre Daten 1:1 die (hoffentlich) dem MIME-Typ entsprechen. Wenn dem nicht so wäre, müsste ein einfacher Download in eine Datei immer nach dem MIME-Typ schauen und da irgendwelche Sonderbehandlungen durchführen, statt einfach die Daten 1:1 in eine Datei zu speichern.

    190? Also ich zähle da 241 Bytes für das JSON, beziehungsweise 240 wenn das nicht mit einem Leerzeichen anfängt. Das sollte man vielleicht auch besser nicht von Hand zählen und fest in den Code schreiben, sondern die Daten kodieren und dann ermitteln wie viele Bytes das tatsächlich sind.

    Aus didaktischer Sicht ist es falsch das so wie in der Dokumentation zu machen. Und es gibt hier auch nichts zu Beweisen. Es geht um eine Meinung. Die kann man begründen, und das wurde ja hier jetzt auch schon mehrfach getan. Du hast halt eine andere Meinung. Die hauen wir ab jetzt jedem der dazu eine Frage hat um die Ohren, diskutieren zehn bis zwanzig Beiträge darüber, und gut ist. 😉

    Muskieg: Der gezeigte Quelltext ist syntaktisch falsch, weil da Code falsch eingerückt ist.


    Den ``try``-Block würde ich ein ganz kleines bisschen weiter fassen, weil man ja nicht weiss was bei `SimpleMFRC522` beim erstellen des Objekts intern so falsch laufen kann und zu einer Ausnahme führen könnte.


    Die Fenstergrösse sollte man nicht vorgeben, die ergibt sich automatisch aus dem Fensterinhalt.


    `id` ist der Name einer eingebauten Funktion, solche Namen sollte man nicht mit anderen Werten überschreiben/verdecken. Man kann dann die `id()`-Funktion nicht mehr verwenden in dem Namensraum, und es kann Leser verwirren.


    Zwischenstand wäre dann:

    Das ist so nicht wirklich sinnvoll und funktioniert nicht wirklich garantiert, denn soweit ich weiss, ist das nicht garantiert, dass die GUI vor dem Aufruf der `mainloop()` angezeigt wird. Und reagieren tut die GUI auch nicht. Unter Windows würde man da irgendwann die Nachfrage vom Betriebssystem bekommen ob man die nicht reagierende Anwendung beenden will. Das könnte eine Fensterverwaltung unter Linux theoretisch auch machen. Ist also nicht sauber programmiert.


    Wenn man eine blockierende Aktion in einer GUI machen will, kommt man um Threads in der Regel nicht herum. Da die GUI nur aus dem Hauptthread manupuliert werden darf, dort wo die `mainloop()` läuft, kommuniziert man üblicherweise mit einer `Queue` aus dem `queue`-Modul und fragt die von der GUI-Seite aus regelmässig mit Hilfe der `after()`-Methode auf Widgets ab, ob es Daten zu verarbeiten gibt.

    Da steht, dass das `subprocess`-Modul zu bevorzugen ist. Veraltet (deprecated) kann da nicht stehen, weil die `os.system()`-Funktion ja nicht entfernt wird, weil das nicht in der Macht der Python-Programmierer liegt. Also theoretisch schon, aber es würde endlose Diskussionen geben wenn die anfangen würden Standard-Funktionen aus dem `os`-Modul zu entfernen, und das war es wohl noch keinem Wert so etwas anzustossen.


    Ich weiss gar nicht ob ich das irgendwo gelesen habe, ich sage selbst mit voller Überzeugung, dass diese Funktion veraltet ist. Sie sollte IMHO deprecated sein. Und mit der Meinung bin ich anscheinend nicht alleine. Du kannst da jetzt gerne jedes mal so ein Fass aufmachen, ich werde bei dieser Formulierung, insbesondere auch gegenüber Anfängern bleiben. Denn die ganzen Details warum das veraltet ist, verstehen Anfänger in der Regel nicht, und die müssen sie auch nicht verstehen, wenn sie `os.system()` gar nicht erst verwenden.

    DeaD_EyE Wenn etwas veraltet (deprecated) ist, dann ist das sehr wohl ein Grund das nicht zu verwenden. Veraltet bedeutet in aller Regel, dass es einen neuen Weg gibt, und das es den gibt, weil der besser ist als der veraltete. Auf den neuen, besseren Weg wird in der Dokumentation von `os.system()` ja auch hingewiesen.


    Die erste Formulierung von hyle — „veraltet“ — war besser, denn einfach nur „alt“ ist in der Tat kein Grund etwas nicht zu benutzen.

    rehgum Randbemerkung: Der ``in``-Operator sieht ein bisschen verdächtig bis falsch aus wenn man sich die Beschreibung und die Eingabe anschaut. Es sei denn Du möchtest wirklich, das enthaltensein einer Teilzeichenkette das Suchkriterium ist, und nicht der gesamte Code in der Datei der Eingabe entsprechen muss.


    Wenn Du am Ende den Index brauchst/haben willst, warum fängst Du dann bei 1 mit dem Zählen an, und nicht einfach bei 0? Was auch der Default-Wert wäre.

    Dann darf man den halt nicht mit freier Software mischen und muss entsprechend mehr Code selber schreiben oder halt auch dazu kaufen. Wo ist das Problem? Die GPL zwingt niemanden Quelltext freizugeben, denn niemand wird gezwungen GPL-Code in seinem Projekt zu verwenden. Leute die GPL-Code benutzen, haben eine bewusste Entscheidung getroffen, und sollen dann bitte nicht rumheulen wie gemein und unpraktisch das ist. 🤷‍♂️

    Wobei aus heutiger Sicht die erste Antwort auf „was mache ich hier falsch“ wohl „Du verwendest noch Python 2“ lauten sollte. Da hat sich auch der Umgang mit Unicode geändert, also löst eine Portierung auf Python 3 vielleicht sogar das ursprüngliche Problem.

    andy.z Sowohl Abkürzungen auch als Nummerierung in Namen ist nicht so wirklich toll. Statt der Nummerierung sollte man entweder bessere Namen wählen, die dem Leser die Bedeutung des jeweiligen Relais verraten, damit man nicht immer nach dem Kommentar suchen muss, wenn man `REL_x` liest, oder zumindest eine Liste verwenden statt einzelner Namen. Wobei man sich dann magische Indexwerte einhandelt. Also Datenstruktur ist doch schon besser. Da könnte man dann auch gleich die Ein-/Ausschaltzeiten mit rein packen, statt das alles im Code zu verteilen.


    Die beiden `bewaessern_*()`-Funktionen braucht man hier nicht wirklich wenn die nur eine Methode auf dem Relais aufrufen. Da kann man auch gleich diese Methode für den Rückruf registrieren.


    Das könnte dann so aussehen (ungetestet):

    InterGeek Das ist Unsinn. Das Betriebssystem stellt eine API zur Verfügung, das ist auch nichts neues das war auch früher schon so, aber die Programme liefen und laufen immer noch auf der CPU. Wenn ich ein C-Programm schreibe das so etwas wie ``print(1 + 1)`` macht, dann wird da in der Tat eine ELF-Datei erstellt — die Maschinencode für den Zielprozessor enthält und auf dem dann auch ausgeführt wird. Und eine ELF-Datei für ARM wird nicht auf magische Weise auf einem x86-Linux durch das Betriebssystem ausgeführt, oder umgekehrt wird auf einem ARM-Linux keine ELF-Datei für x86 ausführbar. Weder Linux noch Windows interpretieren Programmcode — das machen die jeweiligen CPUs und die sind nicht beliebig austauschbar.

    Handschweiss: Der Kommentar vor der Funktion sollte eher ein Docstring sein. Und so ”Linien”-Kommentare sind eher sinnfrei.


    Das Auftrennen der Zeile(n) würde ich mit `partition()` machen, oder falls doch mit `split()`, dann die Anzahl der Trennstellen begrenzen, falls ein "=" im Dateinamen vorkommen kann, gibt es sonst Probleme.


    Die ``if``-Bedingungen schliessen sich alle gegenseitig aus, da wäre also ``elif`` angesagt. Bei der Bedingung selbst kann man das kürzer und leichter verständlich mit verketteten Operatoren schreiben. Also statt ``if i >= 10 and i < 100:`` besser ``if 10 < i < 100:``. Allerings wäre die erste Teilbedingung durch das ``if`` davor schon abgefrühstückt, also reicht ``elif i < 100:`` völlig aus. Aaaaaber, alle diese Abfragen und Zweige würde man nicht machen, weil man die Anzahl der führenden 0en für ein gegebenes `i` auch einfach beim Formatieren in die Zeichenkette angeben kann.


    Ungetestet:

    InterGeek Ständig, also eigentlich immer, jedes Programm. Denn entweder das Programm oder der Interpreter dafür läuft ja auf einem Prozessor. Deine Antworten klingen so als müsste ein Programm irgendwelche *speziellen* Befehle oder Register benutzen, damit man es nicht einfach so mit Wine laufen lassen kann. Das stimmt aber nicht. Jeder ganz normale x86-Befehl und jedes normale x86-Register muss von der CPU ausführbar sein, oder eben emuliert werden. Und da Wine keine CPU emuliert, kann kein noch so simples x86-Programm mit Wine auf einem ARM-Prozessor direkt ausgeführt werden. Ohne Wine auch nicht.


    hajos118 Nein das ist kein kleiner Teil des Problems. Das Problem ist x86 Anwendungen starten. Das steht so wörtlich im Betreff und im ersten Beitrag. Und da wird auch Windows 10 erwähnt, also handelt es sich wohl um x86-Windows-Anwendungen. Falls dem nicht so ist, müsste man das mit dem Fragesteller klären. Aber selbst einfach die Torpfosten verschieben und eine ganz andere Frage beantworten, ist eher nicht so hilfreich.

    Man könnte auch pigpio verwenden, entweder direkt oder per `gpiozero`. Man hat dann über das Netz natürlich eine zusätzliche Latenz und den Daemon über's Netz würde ich nicht produktiv verwenden wollen, aber zum Entwickeln/Testen geht das eigentlich. Wenn eine kleine zusätzliche Latenz kein Problem ist.