Changelog regahss?

[jmaus]

Ok, nun kann ich es nachvollziehen, danke. Konkret meinst du also, das ein ScriptRuntimeError() kommt wenn die Log1p() Funktion in eine Floating Point Exception rennt wie z.B. in das -inf oder -nan. Kann es hier mit diesem Beispiel nun auch entsprechend nachvollziehen.

und is ja nicht nur Log1p() wo der Bockmist ist.

Dann leg das bitte am besten genauso detailliert dar wie du das hier auch für Log1p() dankenswerterweise gemacht hast.

Genau solche Codebeispiele helfen ungemein dabei den Fehler nachzuvollziehen. Wenn du also mehr solcher konkreten Dinge hast die deiner Meinung nach repariert gehören dann melde das doch bitte auf GitHub entsprechend oder (wenn du das dort nicht willst) mach hier einen Beitrag dazu auf in dem du mit solch konkreten Beispielen die vermeintlichen Probleme aufzeigst und darum bittest das die entsprechend reproduziert und dann auf GitHub gemeldet werden. Nur so lässt sich das geordnet von meiner Seite aus dann bearbeiten und darauf eingehen.

EDIT:
Siehe https://github.com/jens-maus/RaspberryMatic/issues/2277

So, kurze Rückmeldung bzgl. dieses Problems hier: Mit der nächsten RaspberryMatic nightly snapshot wird es eine neue ReGaHss R1.00.0388.0234 Version geben die das Problem mit den falschen ScriptRunTimerError bei Floating Point Exceptions beseitigen sollte. Nach ein paar Tests war das in der Tat wohl nicht nur auf Log1p() beschränkt, sondern betraf eine Menge von 23 Mathefunktionen über Exp(), Mod(), etc. bis hin zu Log1p() eben. Ab ReGaHss R1.00.0388.0234 sollten nun keine ScriptRunTimeError mehr erzeugt werden wenn wenn diese Mathefunktionen in eine Floating Point Exception rennen, sondern geben dann eben Werte wie "inf", "nan" usw. zurück die man dann entsprechend in seinem Code auswerten Kann. Insofern sollte der Workaround via .ToString() dann also nicht mehr notwendig sein. Danke noch einmal fürs Melden dieses Problemes.

[[sprotte80]]

Hi

Mit der nächsten RaspberryMatic nightly snapshot wird es eine neue ReGaHss R1.00.0388.0234 Version geben

Wo (Link) find ich ne ReGaHss R1.00.0388.0234 Version wo auf ner CCU3 laufen tut?
Und wo für ne CCU2?

Thomas

[jmaus]

Mit der nächsten RaspberryMatic nightly snapshot wird es eine neue ReGaHss R1.00.0388.0234 Version geben

Wo (Link) find ich ne ReGaHss R1.00.0388.0234 Version wo auf ner CCU3 laufen tut?

Das ist nicht wirklich meine Baustelle, denn die CCU3 binaries von ReGaHss baut eQ3 dann wenn Sie selbst meinen es wäre die Mühe wert. Darauf hab ich keinen Einfluss. Du kannst aber probieren ob eines der ARM binaries im OCCU (https://github.com/eq-3/occu/commit/a42 ... 3adfbf4593) lauffähig auf der CCU3 sind. Kann aber gut sein das das nicht geht weil das Grundgerüst (Buildroot, glibc, etc.) der CCU3 inzwischen maßlos veraltet ist.

Und wo für ne CCU2?

Das wird vermutlich gar nix mehr werden. Die CCU2 ist abgekündigt. Insofern wird es von eQ3 hierfür keinerlei Updates mehr geben (inkl. ReGaHss).

[[sprotte80]]

Hi

Du kannst aber probieren ob eines der ARM binaries im OCCU (https://github.com/eq-3/occu/commit/a42 ... 3adfbf4593) lauffähig auf der CCU3 sind. Kann aber gut sein das das nicht geht weil das Grundgerüst (Buildroot, glibc, etc.) der CCU3 inzwischen maßlos veraltet ist.

Da funzt keine Version habs grad probiert.

Wo (Link) find ich ne ReGaHss R1.00.0388.0234 Version wo auf ner CCU3 laufen tut?

Das ist nicht wirklich meine Baustelle, denn die CCU3 binaries von ReGaHss baut eQ3 dann wenn Sie selbst meinen es wäre die Mühe wert. Darauf hab ich keinen Einfluss.

Nachvollziehen kann ich diese dauernde gedankliche Trennung von eQ3 vs RaspberryMatic im Bezug auf ReGaHss aber inzwischen nicht mehr.

Siehst du wie sich das beissen tut und wiso die Trennung wo du nicht nachvollziehen kannst gaaaaanz wichtig ist?

Thomas