Perl-Hasser unter uns?

Begonnen von mahowi, 03 November 2017, 08:24:41

Vorheriges Thema - Nächstes Thema

devo

Zitat von: M.Schulze am 02 Januar 2018, 00:28:48
Wenn man sich die Mühe machen würde FHEM in C zu konvertieren ...

So einfach geht das sicherlich nicht. Siehe folgenden Beitrag: https://www.perl.com/pub/2001/06/27/ctoperl.html/
Perl hat einige Features, die sich nur Aufwendig in C/C++ umsetzen lassen. Um Fhem in C/C++ umzusetzen, müßte man sicherlich einiges komplett neu programmieren und ob der Aufwand gerechtfertigt ist?

Gruß Detlev

M.Schulze

Zitat von: devo am 02 Januar 2018, 08:13:52
So einfach geht das sicherlich nicht. Siehe folgenden Beitrag: https://www.perl.com/pub/2001/06/27/ctoperl.html/
Perl hat einige Features, die sich nur Aufwendig in C/C++ umsetzen lassen. Um Fhem in C/C++ umzusetzen, müßte man sicherlich einiges komplett neu programmieren und ob der Aufwand gerechtfertigt ist?

Gruß Detlev

Ich glaube nicht das der Aufwand für ein absolut minimales System groß ist. Man benötigt ja für initiale Experimente nur Teile der FHEM.pl umgesetzt, ein Telnet-Modul und Test-Modul als Vorlage für weitere. Das ist überschaubar.
Anschließend kommt erst die Arbeit und das System muss halt wachsen. FHEM ist ja auch über Jahre gereift. Erschwerend kommt eher hinzu, das man ja vermutlich mehrere Cores nutzen will und dafür zusätzlicher Code notwendig ist (mit Semaphores arbeiten).

POSIX C hat auch Regex Funktionen
Muss ich das Licht aus machen?

zap

Man würde wohl eher C++ verwenden, wo die Standard Libraries im Prinzip alles mitbringen, was in Perl auch geht.

Das wäre echt ein Traum: Alle Module / Devices laufen in separaten Prozessen/Threads und können sich nicht gegenseitig behindern/zum Absturz bringen. Kommunikation der Module untereinander über einen Messagebus.

Könnte man natürlich auch in anderen modernen Sprachen umsetzen, die das besser unterstützen als Perl. Von mir aus auch in Nodejs oder Python.
2xCCU3, Fenster, Rollläden, Themostate, Stromzähler, Steckdosen ...)
Entwicklung: FHEM auf AMD NUC (Ubuntu)
Produktiv inzwischen auf Home Assistant gewechselt.
Maintainer: FULLY, Meteohub, HMCCU, AndroidDB

Thorsten Pferdekaemper

Zitat von: zap am 02 Januar 2018, 12:04:18
Man würde wohl eher C++ verwenden, wo die Standard Libraries im Prinzip alles mitbringen, was in Perl auch geht.
Eine wirklich funktionierende Speicherverwaltung? Debugger?

Zitat
Das wäre echt ein Traum: Alle Module / Devices laufen in separaten Prozessen/Threads
Naja, eher ein Albtraum. Momentan kann man sich ziemlich sicher sein, dass man immer einen konsistenten Zustand vorfindet. Das wäre dann nicht mehr so.

Man könnte natürlich schon so ein System bauen. Aber wäre das dann noch FHEM?

Gruß,
   Thorsten
FUIP

marvin78

Zitat

Man könnte natürlich schon so ein System bauen. Aber wäre das dann noch FHEM?

Nein. Sehr guter Punkt. Das wäre was neues, das dann sicher auch Daseinsberechtigung erlangen kann aber FHEM wäre es nicht mehr.

zap

Zitat von: Thorsten Pferdekaemper am 02 Januar 2018, 12:14:00
Eine wirklich funktionierende Speicherverwaltung? Debugger?

Ja, das soll es in C++ tatsächlich geben ;-). Zumindest benutze ich das seit >15 Jahren zwecks Broterwerb.

Zitat
Naja, eher ein Albtraum. Momentan kann man sich ziemlich sicher sein, dass man immer einen konsistenten Zustand vorfindet. Das wäre dann nicht mehr so.

Der Albtraum ist eher, dass jeder kleine Bug in einem Modul das komplette Smarthome in den Abgrund reißt. Bei getrennten Prozessen oder Threads würde nur ein Teil ausfallen. Und wenn man parallele Programmierung vernünftig einsetzt, hat man auch kein Problem mit inkonsistenten Zuständen.

Aber Du hast Recht: es wäre kein FHEM mehr. Aber wäre das schlimm? FHEM ist Mittel zum Zweck.


2xCCU3, Fenster, Rollläden, Themostate, Stromzähler, Steckdosen ...)
Entwicklung: FHEM auf AMD NUC (Ubuntu)
Produktiv inzwischen auf Home Assistant gewechselt.
Maintainer: FULLY, Meteohub, HMCCU, AndroidDB

schnitzelbrain

Würde etwas gegen eine Entwicklung von
C-Fhem ;-D sprechen?
So aus der Urheberrecht Ecke?

Wenn sich doch genug fähige C++ Programmierer mit Zeit und Kenntnissen finden kann doch eine Entwicklung gestartet werden.

Wenn die Maintainer nix dagegen haben, es wird da ja code buchstäblich übersetzt.
Vielleicht dann auch schon mit einigen oft angesprochenen Anpassungen am Frontend /Backend.

Vielleicht dann auch in Git oder so.
Ich sehe halt viele verschiedene Threads mit Themen die sich mit einer Um-entwicklung sicher lösen lassen würden.
Es muss ja kein Rad neu erfunden werden.

Wenn irgendjemand vielleicht mal mit VB6 um die Ecke kommt könnte ich sogar was dazu beitragen. :-O träumen darf man doch.

Grüße

Schnitzelbrain

CoolTux

Kommt es nur mir so vor, das der Thread langsam albern wird?

Plattformunabhängigkeit geht verloren. Man wird abhängig von Systembibliotheken.
Wir wechseln von eine Hochsprache in die Steinzeit zurück. Sowas kann man doch unmöglich wollen. In Perl sind super tolle Projekte entstanden. Ganze Ticketsysteme die selbst in Großkonzernen verwendet werden.
Du musst nicht wissen wie es geht! Du musst nur wissen wo es steht, wie es geht.
Support me to buy new test hardware for development: https://www.paypal.com/paypalme/MOldenburg
My FHEM Git: https://git.cooltux.net/FHEM/
Das TuxNet Wiki:
https://www.cooltux.net

marvin78

Es wird immer ein  paar C(++) Jünger geben, die die Welt verschlimmbessern wollen und keine Ahnung haben, was sie damit anrichten. Diskussionen sind da zwecklos. Mein Vorschlag: FHEM nehmen, "übersetzen" und glücklich werden aber alle anderen möglichst nicht stören. Und ja, auch dieser Beitrag ist so albern, wie einige davor. Nur nicht ganz so undurchdacht.

herrmannj

was wäre denn, mal ganz hypothetisch gesprochen, die Meinung zu FHEM modulen in perl, c und python. Jeweils in einem eigenen thread ? ;)

Gäbe es Developer die bereit wären Ihre Zeit, sehr ernsthaft und selbstlos, zu investieren und die perl _und_ c / perl _und_ phyton echt gut (!) draufhaben ?

justme1968

#40
meine 'haupt' programmier sprache ist auch c/c++, aber ich würde nie auf die idee kommen so etwas wie fhem damit zu entwickeln. weil:
- threads sind eine noch größere katastrophe (mal abgesehen davon das man threads so gut wie nie nie braucht)
- die platform unabhängigkeit ist eine mittlere katastrophe sobald man nicht mehr nur ansi c/c++ ohne externe libs verwendet
- der mögliche geschwindigkeit zuwachs ist in 99.99 aller fälle für einen einsatz wie fhem unnötig
- plugins, paket manager, ... sind wenn überhaupt sehr platform spezifisch
- einen zusätzlichen interpreter (und eventuell sogar compiler) zu integrieren um das von fhem gewohnte verwenden von 'echtem' code in notifys oder myUtils zu verwenden ist ein ziemlicher aufwand
- memory management ist schwer
- ...

eine kompilierte sprache hat absolut keine vorteile die uns hier nützen.


wenn überhaupt wäre node tatsächlich eine wunderbare option. das asynchrone model ist wirklich gut, es gibt viele viele pakte und einen guten paket manager. als interpretierte sprache erlaubt es die gleiche introspektion und einfache erweiterbarkeit durch zusätzlichen code zur laufzeit. es gibt ein paar konzepte an die man sich gewöhnen muss und man sollte sich an ein paar regeln halten.

was man mit node und ein paar nativen c komponenten machen kann sieht man z.b. an atom.io oder dem neuen plexamp player.

aber wie auch immer: die diskussion hier ist zwar ganz amüsant, aber nicht besonders zielführend. so lange sich niemand aus eigenem interesse hinsetzt und etwas neues/anders aus eigenem antrieb und zumindest zu 80% funktionsfähig vorstellt gibt es keinen grund nicht lieber fhem weiter zu entwickeln. es ist schon interessant aus welcher ecke solche diskussionen immer wieder kommen. wie bei den x tot geboren frontends die sich jemand wünscht weil fhem ja so altmodisch ist.
hue, tradfri, alexa-fhem, homebridge-fhem, LightScene, readingsGroup, ...

https://github.com/sponsors/justme-1968

CoolTux

Du musst nicht wissen wie es geht! Du musst nur wissen wo es steht, wie es geht.
Support me to buy new test hardware for development: https://www.paypal.com/paypalme/MOldenburg
My FHEM Git: https://git.cooltux.net/FHEM/
Das TuxNet Wiki:
https://www.cooltux.net

M.Schulze

Also ich würde an einer zunächst experimentellen Umsetzung in C mitarbeiten. Nicht C++ (also es wäre wohl möglich trotzdem C++ in den Modulen zu verwenden)

Aber das Ziel wäre der Einsatz auf IoT Geräten mit SoC, Linux oder FreeRTOS, die Clients vom konventionellen FHEM sein könnten, oder an Cloud Dienste angebunden werden können.
Zunächst eher für einfache Dinge. Relays, RGB-Controller, Raumsensoren, ...

Amazon ist da ja auch sehr aktiv:
https://www.youtube.com/watch?v=PerMQkl1QkE

Um Mißverständnisse vorzubeugen: Das würde in keinster Weise eine Konkurenz zum jetzigen FHEM darstellen und unter neuem Namen Firmieren.

MFG
Muss ich das Licht aus machen?

herrmannj

Ich sprach von der (hypothetischen) Möglichkeit einzelne Module für FHEM auch in den Sprachen C und python zu erstellen.

justme1968

@M.Schulze: das was du im auge hast sind sensoren und aktoren die daten an fhem senden bzw. kommandos von fhem empfangen. dafür gibt es heute schon mindestens 20 möglichkeiten mit den unterschiedlichsten protokollen in allen nur denkbaren programmiersprachen. auf diesen geräte muss absolut kein wie auch immer abgespeckter teil von fhem laufen. die müssen nur daten liefern und kommandos entgegen nehmen.

da gibt es nichts 'umzusetzen' sondern das muss man einfach nur machen und benutzen.

@herrmannj: welche hypothetischen module meinst du denn hier? so lange es extern ist braucht es nur eines der oben angesprochenen protokolle, sobald es 'intern' und ein echtes fhem modul ist wird es ohne perl schwierig.

das alte sandbox konzept das ich immer noch nicht weiter verfolgt habe würde einzelne module oder gruppen voneinander abschirmen. das ganze ist aber immer noch perl.

die alte idee das longpoll protokoll zu einem echten json aufzubohren und bidirektional zu nutzen habe ich immer noch nicht beiseite gelegt. damit könnte man komponenten bauen die mehr oder weniger lose an fhem gekoppelt sind. völlig unabhängig von der sprache. das funktioniert mit homebridge-fhem und alexa-fhem die komplett in node.js geschrieben sind ziemlich gut.

in beiden fällen geht es mehr um protokolle als um sprachen. und hier ist es normalerweise besser sich so weit wie möglich an standards zu halten statt das rad immer wieder neu zu erfinden.
hue, tradfri, alexa-fhem, homebridge-fhem, LightScene, readingsGroup, ...

https://github.com/sponsors/justme-1968