Autor Thema: Perl-Hasser unter uns?  (Gelesen 7378 mal)

Offline devo

  • New Member
  • *
  • Beiträge: 44
Antw:Perl-Hasser unter uns?
« Antwort #30 am: 02 Januar 2018, 08:13:52 »
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
SW:FHEM 5.6; Raspbian-Wheezy 09.09.14
HW:Banana pro; Raspi B+; FritzBox 7240; 3x BC-RT-TRX-CyG; 2x BC-SC-Rd-WM; BC-TS-Sw-PI; HM-ES-PMSw1-PI; HM-Sys-SRP-PI; HM-LC-SW1-FM; 2x HM-Sys-SRP-PI;

Offline M.Schulze

  • Commercial User
  • New Member
  • *
  • Beiträge: 13
  • Principal Strategist, Maker
Antw:Perl-Hasser unter uns?
« Antwort #31 am: 02 Januar 2018, 11:00:21 »
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

Offline zap

  • Developer
  • Hero Member
  • ****
  • Beiträge: 2873
    • HMCCU
Antw:Perl-Hasser unter uns?
« Antwort #32 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.

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, diverse Komponenten (Fenster, Rolladen, Themostate, Stromzähler, Steckdosen ...)
FHEM mit Raspi für CCU Integration.
IOBroker für UI (VIS), Hue, Sonos usw.
Maintainer der Module FULLY, Meteohub und HMCCU (Schnittstelle CCU-FHEM = best of both worlds approach

Offline Thorsten Pferdekaemper

  • Developer
  • Hero Member
  • ****
  • Beiträge: 5551
  • Finger weg von der fhem.cfg
Antw:Perl-Hasser unter uns?
« Antwort #33 am: 02 Januar 2018, 12:14:00 »
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
RasPi
Heizkessel-Steuerung per Arduino und HTTPMOD
und einen Haufen Homematic (Wired)

Offline marvin78

  • Developer
  • Hero Member
  • ****
  • Beiträge: 5517
Antw:Perl-Hasser unter uns?
« Antwort #34 am: 02 Januar 2018, 19:50:19 »
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.
Zustimmung Zustimmung x 2 Liste anzeigen

Offline zap

  • Developer
  • Hero Member
  • ****
  • Beiträge: 2873
    • HMCCU
Antw:Perl-Hasser unter uns?
« Antwort #35 am: 03 Januar 2018, 18:32:06 »
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, diverse Komponenten (Fenster, Rolladen, Themostate, Stromzähler, Steckdosen ...)
FHEM mit Raspi für CCU Integration.
IOBroker für UI (VIS), Hue, Sonos usw.
Maintainer der Module FULLY, Meteohub und HMCCU (Schnittstelle CCU-FHEM = best of both worlds approach
Gefällt mir Gefällt mir x 1 Liste anzeigen

Offline schnitzelbrain

  • Full Member
  • ***
  • Beiträge: 190
Antw:Perl-Hasser unter uns?
« Antwort #36 am: 03 Januar 2018, 18:57:22 »
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

Offline CoolTux

  • Developer
  • Hero Member
  • ****
  • Beiträge: 21668
Antw:Perl-Hasser unter uns?
« Antwort #37 am: 03 Januar 2018, 19:14:43 »
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://paypal.me/pools/c/8gULisr9BT
FHEM GitHub: https://github.com/fhem/
kein Support für cfg Editierer
Gefällt mir Gefällt mir x 2 Liste anzeigen

Offline marvin78

  • Developer
  • Hero Member
  • ****
  • Beiträge: 5517
Antw:Perl-Hasser unter uns?
« Antwort #38 am: 03 Januar 2018, 19:57:19 »
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.
Gefällt mir Gefällt mir x 1 Liste anzeigen

Offline herrmannj

  • Global Moderator
  • Hero Member
  • ****
  • Beiträge: 5053
Antw:Perl-Hasser unter uns?
« Antwort #39 am: 03 Januar 2018, 20:14:03 »
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 ?
smartVisu mit fronthem, einiges an HM, RFXTRX, Oregon, CUL, Homeeasy, ganz viele LED + Diverse
Gefällt mir Gefällt mir x 1 Liste anzeigen

Offline justme1968

  • Developer
  • Hero Member
  • ****
  • Beiträge: 19287
Antw:Perl-Hasser unter uns?
« Antwort #40 am: 03 Januar 2018, 20:42:10 »
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.
« Letzte Änderung: 03 Januar 2018, 21:08:45 von justme1968 »
FHEM5.4,DS1512+,2xCULv3,DS9490R,HMLAN,2xRasPi
CUL_HM:HM-LC-Bl1PBU-FM,HM-LC-Sw1PBU-FM,HM-SEC-MDIR,HM-SEC-RHS
HUEBridge,HUEDevice:LCT001,LLC001,LLC006,LWL001
OWDevice:DS1420,DS18B20,DS2406,DS2423
FS20:fs20as4,fs20bs,fs20di
AKCP:THS01,WS15
CUL_WS:S300TH
Gefällt mir Gefällt mir x 1 Zustimmung Zustimmung x 4 Liste anzeigen

Offline CoolTux

  • Developer
  • Hero Member
  • ****
  • Beiträge: 21668
Antw:Perl-Hasser unter uns?
« Antwort #41 am: 03 Januar 2018, 20:51:03 »
Danke Andre!!
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://paypal.me/pools/c/8gULisr9BT
FHEM GitHub: https://github.com/fhem/
kein Support für cfg Editierer

Offline M.Schulze

  • Commercial User
  • New Member
  • *
  • Beiträge: 13
  • Principal Strategist, Maker
Antw:Perl-Hasser unter uns?
« Antwort #42 am: 03 Januar 2018, 22:40:21 »
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

Offline herrmannj

  • Global Moderator
  • Hero Member
  • ****
  • Beiträge: 5053
Antw:Perl-Hasser unter uns?
« Antwort #43 am: 03 Januar 2018, 22:44:32 »
Ich sprach von der (hypothetischen) Möglichkeit einzelne Module für FHEM auch in den Sprachen C und python zu erstellen.
smartVisu mit fronthem, einiges an HM, RFXTRX, Oregon, CUL, Homeeasy, ganz viele LED + Diverse

Offline justme1968

  • Developer
  • Hero Member
  • ****
  • Beiträge: 19287
Antw:Perl-Hasser unter uns?
« Antwort #44 am: 03 Januar 2018, 23:09:10 »
@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.
FHEM5.4,DS1512+,2xCULv3,DS9490R,HMLAN,2xRasPi
CUL_HM:HM-LC-Bl1PBU-FM,HM-LC-Sw1PBU-FM,HM-SEC-MDIR,HM-SEC-RHS
HUEBridge,HUEDevice:LCT001,LLC001,LLC006,LWL001
OWDevice:DS1420,DS18B20,DS2406,DS2423
FS20:fs20as4,fs20bs,fs20di
AKCP:THS01,WS15
CUL_WS:S300TH
Gefällt mir Gefällt mir x 1 Liste anzeigen