Python 3.2 Migration in develop bzw. 1.0 Release

[Robert]

Hi!

Die Verzögerungen hatte ich auch gestern bemerkt - schätze mal lib/connection wartetete auf Timeouts?

//edit: Fix für unten stehendes Problem:

diff --git a/lib/logic.py b/lib/logic.py
index faafd05..23ee2ac 100755
--- a/lib/logic.py
+++ b/lib/logic.py
@@ -97,7 +97,7 @@ class Logic():
         self.prio = int(self.prio)
         if self.crontab is not None:
             if isinstance(self.crontab, list):
-                self.crontab = ','.join(self.crontab)  # rejoin crontab entry to a string
+                self.crontab = '|'.join(self.crontab)  # rejoin crontab entry to a string

     def id(self):
         return self.name

Habe leider Probleme mit crontab-Einträgen nach der Konvertierung:

crontab = 45 5 * 0,1,2,3,4 | 0 7 * 5,6

führt zu

2013-10-09 07:27:05 ERROR    Main         Unhandled exception: too many values to unpack (expected 4)
<class 'ValueError'>
  File "/usr/local/smarthome/bin/smarthome.py", line 646, in <module>
    sh.start()
  File "/usr/local/smarthome/bin/smarthome.py", line 334, in start
    self._logics = lib.logic.Logics(self, configfile=self._logic_conf)
  File "/usr/local/smarthome/lib/logic.py", line 50, in __init__
    self._sh.scheduler.add(name, logic, logic.prio, logic.crontab, logic.cycle)
  File "/usr/local/smarthome/lib/scheduler.py", line 211, in add
    self._next_time(name, offset)
  File "/usr/local/smarthome/lib/scheduler.py", line 265, in _next_time
    ct = self._crontab(entry)
  File "/usr/local/smarthome/lib/scheduler.py", line 340, in _crontab
    next_event = self._parse_month(crontab, offset=0)  # this month
  File "/usr/local/smarthome/lib/scheduler.py", line 347, in _parse_month
    minute, hour, day, wday = crontab.split(' ')

zudem (wenn obiges auskommentiert):

crontab = init | 00 21 * *

führt zu

2013-10-09 07:31:02 ERROR    Main         Unhandled exception: invalid literal for int() with base 10: 'init'
<class 'ValueError'>
  File "/usr/local/smarthome/bin/smarthome.py", line 646, in <module>
    sh.start()
  File "/usr/local/smarthome/bin/smarthome.py", line 334, in start
    self._logics = lib.logic.Logics(self, configfile=self._logic_conf)
  File "/usr/local/smarthome/lib/logic.py", line 50, in __init__
    self._sh.scheduler.add(name, logic, logic.prio, logic.crontab, logic.cycle)
  File "/usr/local/smarthome/lib/scheduler.py", line 211, in add
    self._next_time(name, offset)
  File "/usr/local/smarthome/lib/scheduler.py", line 265, in _next_time
    ct = self._crontab(entry)
  File "/usr/local/smarthome/lib/scheduler.py", line 340, in _crontab
    next_event = self._parse_month(crontab, offset=0)  # this month
  File "/usr/local/smarthome/lib/scheduler.py", line 349, in _parse_month
    minute_range = self._range(minute, 00, 59)
  File "/usr/local/smarthome/lib/scheduler.py", line 459, in _range
    item = int(item)

scheinbar funktioniert das Parsen noch nicht zuverlässig bei kombinierten Einträgen?

[callidomus]

Hallo Ihr beiden,

ich habe an der Performance-Schraube gedreht. Es müsste jetzt wesentlich schneller als vorher sein.

Bis bald

Marcus

[mode]

Dass es langsamer ist als mit py2 habe ich auch bemerkt. Die Reaktionszeit auf einfache Logiken ist merklich angestiegen.
Vorher war praktisch keine Verzögerung spürbar. Nun ist es 0,3 bis 0,5 sek.

Edit:
Habe es mir gerade im Busmonitor angesehen. Die Verzögerung liegt bei 0,7 sek.
Meine Test - Logik ist sehr einfach. Listen auf eine GA auf der eine Szenen Nr von einem EIB Taster gesendet wird. Ist dies der Fall wird von Smarthome.py eine Bool GA auf den Bus geschrieben. Anschließend werden in der gleichen Logik noch weitere Werte auf den Bus geschrieben - hier mit einer Verzögerung von 0,05s zum ersten Schreiben auf den Bus - also ganz fix.

Lt. Smarthome Log liegt zwischen der ein eingehenden und der ausgehenden KNX Nachricht eine Zeit von 0,005 sek - auf dem bus sind es wie oben beschrieben 0,7 sek.

[JNK]

Python 3.2 Migration in develop bzw. 1.0 Release

@Marcus: geht auch. Den Error 11 habe ich aber immer noch bei vielen Daten.

Gruß,

der Jan

P.S.: insgesamt ist es langsamer als vor der Umstellung. Mein 'nachdimmen' kommt zu spät.

[callidomus]

Config-Format

Hallo,

das habe ich gerade im Eingangspost ergänzt:

# Das Config-Format hat sich leicht geändert. Statt ',' werden '|' für das Aufteilen von Attributen verwendet.
# Es gibt ein kleine Script das die Konvertierung übernimmt
# Unter items/NAME.conf.bak liegt die alte Config
# Bitte nur einmal ausführen
$ ./tools/conf2-1.0.sh

Bis bald

Marcus

[callidomus]

Hallo Hendrik,

mir geht es ja darum, dass Fehler nur gefunden werden, wenn auch jemand mal Develop ausprobiert.

genau, deswegen bin ich ja auch über das Feedback froh. Normalerweise hätte ich das besser getestet bevor ich es einchecke. Aber die Änderungen waren zu massiv und hätten zu einem Auseinanderdriften von develop und meinem Branch geführt.

Bis bald

Marcus

[henfri]

Hallo,

mir geht es ja darum, dass Fehler nur gefunden werden, wenn auch jemand mal Develop ausprobiert.
Und ausprobieren geht am besten eben produktiv, oder in einer fixen, reproduzierbaren Test-Umgebung.
Ich nutze Develop, weil ich helfen möchte.

Wenn jetzt jeder auf das Release wartet, dann wird das Release mehr Bugs haben.

Gruß,
Hendrik

[callidomus]

Hallo,

es gibt ca. alle 4 Monate ein Release.
2011-04-09 kam das erste Release raus. Bald kommt das zehnte Release 1.0 raus nach 2,5 Jahren.
Das sollte doch ausreichend aktuell für normale Benutzer sein.

develop != stable

Wenn man develop verwendet, muss man damit rechnen das auch mal was kaputt ist. Normalerweise ist das aber nicht so und soll auch nicht so sein.
Der Ruf nach einem weiteren Branch ist leicht. Die Pflege nicht.

Die Umstellung auf Python 3.2 ist ein, hoffentlich einmaliger, Sonderfall.
Die notwendigen Änderungen sind so weitreichend und übergreifend gewesen, dass ein zusätzlicher Branch und der Merge einen großen Aufwand bedeutet hätten.
Man kann es ein bisschen mit einer Haus-Renovierung vergleichen. Es gab einige Auswirkungen bei der Migration die unvorhergesehenen Aufwand nach sich gezogen haben. So musste z.B. der Scheduler angepasst werden, da es das "dict < dict" Problem gab. Oder ich hab einen eigenen Config-Parser geschrieben, da der alte nicht Py3 kompatibel ist. Die Liste könnte ich noch eine Weile fortführen.

Bei mir in der Entwicklungsumgebung (VirtualBox) läuft die aktuelle develop mit Visu, KNX, 1-Wire stabil. (Keine Exceptions, kein Speicherleck).

Ich werde bald die Testumgebung (mit einem neuen Pi-Image) umstrukturieren um die neuen Elabnet-Sensoren einzubauen. Dann fange ich mit dem systematischen Testen des Systems inkl. der Plugins an. Die Tests sind leider z.T. nur händisch durchzuführen und man benötigt dafür häufig auch die Hardware bzw. Umgebung.
Das kann und werde ich nur für "meine" Plugins machen können.
Hier sehe ich die Plugin-Entwickler und Poweruser um die anderen Plugins zu testen.

Wenn die Test soweit durch sind, dann geht es in eine Beta-Phase und dann erst stelle ich mein Produktivsystem um.
Das Release kommt dann wahrscheinlich in der ersten Novemberhälfte.

Bis bald

Marcus

[JuMi2006]

Ich mag VMs nicht Ich sehe da auch Probleme wenn Plugins mehrmals laufen und verschiedene Instanzen/Logiken gleichzeitig laufen. Das gibt garantiert hier und Ärger.

Naja tut schon ein bisschen weh wenn was nicht läuft aber im Zweifel ist das ja auch nur eine Zeile in der shell und man ist wieder zurück auf einem "stabilen" Stand. Ob man sich das antut oder nicht ist natürlich jedem selbst überlassen. Ich habs gewagt und konnte Mangels Zeit und wissen ben nur nen Bug-Report machen. Nachdem mir der Fernseher mangels 1-Wire-Scheduler Bug 3x ausgegangen ist bin ich dann einfach zurück mit

git checkout 55efdfdd187d29bc94828b90b6f9248690845caf

und alles lief erstmal wieder. Klar dass es in develop mal Einschränkungen geben wird aber hoffentlich nicht oft solch große Sprünge.
Heute vormittag dann mal eben ein

git checkout develop
git pull
service smarthome.py restart

und der Drops war gelutscht.

Für die Plugin Maintainer ist es eben auch etwas haarig. Aber das ist selbstgewähltes Leid, jeder könnte sich zurücklehnen und sagen "Machen wir wenn develop wieder stabil ist." Ansonsten erstmal Danke an Marcus für die schnellen Fixes.

[henfri]

Hallo,

Wenn etwas großes im Kernsystem umgestellt werden muss, wäre es vielleicht besser einen branch zu machen wo die richtig kritischen Sachen reingehen?

master - rock-solid (evtl. könnte das aber auch "develop" mit Tags sein?)
develop - Kernsystem stabil und nur Plugins etc. "develop"
bleeding - Änderungen am Kernsystem

das habe ich doch mal irgendwo gelesen... genau:
https://knx-user-forum.de/345353-post17.html
:-)
Mir geht es genau so.

Davon abgesehen:
Wäre es möglich/sinnvoll eine Test-Umgebung in einer VM laufen zu lassen, auf der alle Plugins und diverse Logiken/sqlite-Aufrufe/websocket-Aufrufe etc. automatisiert getestet werden?

Jeder Autor müsste ja "nur" eine items.conf&Co die das Plugin testet mitliefern.

Ich denke, das würde die Fehlersuche vereinfachen, oder?
Ich glaube die Jungs&Mädels von xEib machen das so.

Gruß,
Hendrik

[Robert]

Hi Max,

ja, alles korrekt. Nur hat es mich halt heute nach zerrissen (alles ok, ist halt develop) -> Marcus sagt (dankenswerterweise!) "ist im aktuellen GIT gefixt" -> Zielkonflikt (nicht pullen vs. Fix ziehen, für cherrypicking habe ich keine Zeit) -> Mein Squeezebox-Plugin ist platt -> ich muss instantan fien um wieder lauffähig zu sein.

Alles gut, denke auch das beruhigt sich wieder in ein paar Tagen wenn "alles" gefunden und gefixt wurde.

Ansonsten freu ich mir einen Ast ab über smarthome.py. Hier hat sich ein System gebildet, dass denke ich nur in OpenHAB Konkurrenz auf Augenhöhe hat.

Grüße
Robert

[l0wside]

Hallo Robert,

ich verstehe dein Anliegen. Für mich selbst habe ich es so gelöst, dass ich nach der Ankündigung von Marcus keine Updates mehr gefahren habe. Das Ding läuft schließlich im Produktiveinsatz.

Während der Umstellung auf Python 3 wäre es vermutlich sowieso sinnvoll, die Plugins nicht zu ändern. Wenn das Kernsystem auf Python 3 läuft, können dann die Plugins angepasst werden. Im dritten Schritt kommen dann wieder neue Features dazu.

Du kannst es auch so sehen: der develop ist im Moment bleeding. Wenn die Blutung gestoppt ist, mutiert er wieder zum normalen develop zurück.

Max

[Robert]

Und Änderungen am Kernsystem wird es hoffentlich erst zu Python 4 wieder geben. Das ist aber wohl noch eine Weile hin...

Aktuelles Beispiel:

my_asynchat -> connection

Die Aufrufe wurden automatisch getauscht, leider "lib.connections" statt "lib.connection". Zudem das öffentliche Attribut list(addr) zugunsten str(address) gekillt. Sprich, da müssen die Plugin-Maintainer unerwartet was portieren.

Für viele ist halt "develop" ein Branch, der zumindest lauffähig sein sollte (also durchstarten kann solange ich nicht an Plugins oder geringfügigen Features was ändere).

[l0wside]

Hallo Robert,

fände ich nicht gut. KISS ist ein gutes Prinzip.
Und Änderungen am Kernsystem wird es hoffentlich erst zu Python 4 wieder geben. Das ist aber wohl noch eine Weile hin...

Max

[Robert]

Deine Version ist zu alt.

Hi Marcus,

vielen Dank fürs drüber schauen! :-)

Ja, ich habe halt seit deiner Warnung letzten Samstag keinen pull mehr gemacht!?

Dazu muss man sagen: Ich setze gerne den develop "produktiv" ein um die neusten Features zu testen, Bugs zu finden bzw. den ein oder anderen Hotfix selber zu coden. Bzw. auch weil meine Plugins ja ins develop wandern. Andererseits muss ich aber auch zusehen, das Frauchen morgens direkt warmes Wasser hat (Zirku) und die Handtuchheizung warm ist (etc etc etc). Denke so handhaben das hier einige "Poweruser".

Wenn etwas großes im Kernsystem umgestellt werden muss, wäre es vielleicht besser einen branch zu machen wo die richtig kritischen Sachen reingehen?

master - rock-solid (evtl. könnte das aber auch "develop" mit Tags sein?)
develop - Kernsystem stabil und nur Plugins etc. "develop"
bleeding - Änderungen am Kernsystem

Grüße
Robert