Ankündigung

**Fry** · 26.04.2012, 05:52

...wer lieber die vollen GA-Namen und keine Kürzel hat:

Code:

  $hash->{name}=~/^\s*(\S+)/;  
  my $short=$1;  
  $short='ZV_'.$1 if $hash->{name}=~/^Zeitversand.*(Uhrzeit|Datum)/; # short versions of "Zeitversand"

ersetzen durch

Code:

my $short=$hash->{name}

VG, Fry

**henfri** · 26.04.2012, 06:54

Danke!
Werde ich bestimmt in Zukunft nutzen!

**StefanW** · 26.04.2012, 09:00

Sehr schön!

**makki** · 27.04.2012, 01:11

Gut das zu posten, weil so nen sehr kreativen Spass muss man in .next auch berücksichtigen; das geht zwar noch, kratzt aber schon hart an der Grenze (die Erde ist (k)eine Scheibe

)

Makki

**Fry** · 27.04.2012, 06:43

Zitat von makki Beitrag anzeigen

Gut das zu posten, weil so nen sehr kreativen Spass muss man in .next auch berücksichtigen; das geht zwar noch, kratzt aber schon hart an der Grenze (die Erde ist (k)eine Scheibe

)
Makki

Ich weiß, du magst Zahlen lieber als Wörter. Bei mir ist es umgedreht. Deshalb ist dieses Tool für mich sehr nützlich aber wohl kaum was für dich.

Kreativer Spaß ist Perl immer, zumal fast alles mit wenigen Zeilen geht (selbst der wiregated.pl hat nur 2300 Zeilen, ich schätze mal unter C++/perlembed wären das ruckzuck 10k).

Aber was meinst du mit Erde keine Scheibe... also da bist du einen Tick zu kryptisch, wenn ich noch verstehen soll, was du meinst...

Fry

**StefanW** · 27.04.2012, 07:43

Guten Morgen Fry,

Makki will Dir damit sagen, dass es gut ist, wenn er deine kreativen Perl-Entwürfe kennt, weil wir an einer Neuimplementierung des Plugin-Systems arbeiten (das ist mit .next gemeint).

Das gilt für alle. Je mehr Plugins wir kennen, desto eher können wir diese darauf untersuchen, ob es Auswirkungen geben könnte, bei der Neuentwicklung der "Plugin-Engine".

Da die Frage ohnehin kommt: Die Zielrichtung der Neuentwicklung wäre deutlich bessere Skalierbarkeit und Parallelisierbarkeit. Insbesondere aber auch Abtrennung von anderen vitalen Bestandteilen, damit ein "totes" Plugin nichts anderes ausbremsen kann.

Nein, es gibt dazu KEINEN Termin.

lg

Stefan

**Bodo** · 27.04.2012, 07:51

Top Firma

Zitat von StefanW Beitrag anzeigen

Nein, es gibt dazu KEINEN Termin.

Hoi

Ich finde es toll wie Ihr unter dem ganzen Druck (soviele Beiträge zum WG wie zur Zeit hab' ich ja noch nie gesehen) noch entwickeln könnt.
Und das auch noch hard- und softwareseitig, Respekt.

Da hätte es mir schon öfter "den Nucki usse g'haue" wie man hier so schön sagt. (etwa soviel wie da wäre mir schon längst "die Hutschnur gerissen")

Man merkt den Stress bei Euch schon, ist auch normal.

**StefanW** · 27.04.2012, 08:09

Hoi Bodo, danke sehr

.

So ein wenig Balsam tut derzeit ganz gut.

Nunja, um ehrlich zu sein, geht die ganze Schreiberei hier im Forum schon ein wenig zu Lasten des Fortschritts.

Gestern früh war eigentlich eingeplant, für die Herstellung eines Produktes, die CAM-Daten produktionsreif zu machen um es an den Platinenhersteller zu senden. Stattdessen musste ich eine völlig überflüssige GPL-Diskussion wegen eines eigentlich unbegründeten Verdachtes führen....

Unsere Neigung, fast alles zu beantworten zieht vermutlich weitere Fragen und Diskussionen an, daher sind wir derzeit auch am Überlegen, unsere diesbezügliche Haltung zu überdenken.

Ach, ab und an platzt uns auch die Hutschnur. Insbesondere wenn einer das Haar in der Suppe sucht. Bei Makki spürt man das Platzen nur eher als bei mir...

Umso mehr freuen uns Lob, freundliche Kommentare und einmal haben wir sogar ein tolles Paket voller Schokolade für das Wiregate Team nebst handgeschriebenen Brief dazu von einem lieben Kunden bekommen. Und wer hats erfunden?

glg

Stefan

**Fry** · 27.04.2012, 14:36

Lieber Stefan,
beim positiven Feedback schließe ich mich (wieder einmal) an.

Zum Thema Plugin-Engine: ich finde die existierende Plugin-Engine bereits sehr gut, aber falls das für euch hilfreich ist, liefere ich hier ein paar Anregungen, die aus meiner Sicht gerade dem Anfänger die Plugin-Schreiberei erleichtern würden:

* Einfache Unterscheidung des Aufrufgrundes durch eine entsprechend vorbesetzte Variable $event (siehe Plugin-Skeleton für einen Vorschlag)

* %plugin_subscribe: separat für Telegrammtypen (write/read/response) ermöglichen -> reduziert Aufrufe mit sofortigem return, vermeidet mögliche Anfängerfehler

* %eibgaconf auch invers indizieren (also $eibgaconf{$ga}{name} sollte genauso funktionieren wie $eibgaconf{$name}{ga}) -> das ist sehr leicht zu realisieren, vermutlich eine einzige Zeile oder foreach-Schleife im wiregated.pl. Ein "Schmankerl" für mein GA-Schema wäre dabei die Verwendung nur des ersten Wortes im GA-Namen (bei meinem GA-Namensschema ist das erste Wort ein eindeutiges Kürzel, zB TA_TE3 = Außentemperatur Terrasse Obergeschoss).

* "Wecker"-Funktion: man sollte den Zeitpunkt des nächsten zyklischen Aufrufs absolut festlegen können -> vermeidet Zeitrechnerei

Jetzt wird's noch ein wenig esoterisch:

* Möglichkeit, aus einem Plugin ein anderes Plugin mit definiertem Zeitversatz aufzurufen.

* Sub-Arrays und -Hashes in %plugin_info erlauben (aktuell arbeite ich mit einer Krücke, siehe zB im Heizungsregler) -> erleichtert dem Anfänger die Persistence.

* %plugin_info verschiedener Plugins so trennen, dass _versehentliches_ Beschreiben "fremder" (zu anderen Plugins gehörender) Variablen vermieden wird (public/private/friend-Feature). -> vermeidet Fehler durch schlechte Kapselung

* Zeitbeschränkung auf 10s aufheben, stattdessen in einem parallelisierten System aber verbieten, dass ein noch laufendes Plugin nicht ein zweites Mal aufgerufen wird (no reentry).

* Möglichkeit, die EIB-Telegrammqueue einzusehen. Beispiel: Wackelkontakt am Schlüsselbrett führt heute zu "Auf Wiedersehen XY - Willkommen XY"-Meldungen - das muss umständlich mittels Analyse von $plugin_info{$plugname.'_last'} entprellt werden - hilfreich wäre eine Möglichkeit, im Plugin nachzusehen ob schon weitere Telegramme auf den abonnierten GAs anliegen und diese ggf. schon zu verarbeiten)

NICHT SO WICHTIG: Ausführungsgeschwindigkeit. Die ist bereits gut.

Das fällt mir einfach auf die Schnelle ein.

Grüße,
Fry

**Fry** · 27.04.2012, 14:42

Zitat von Bodo Beitrag anzeigen

(soviele Beiträge zum WG wie zur Zeit hab' ich ja noch nie gesehen)

Daran sieht man: Das WG hat als GPL-Projekt ein Riesenpotenzial. Und das meine ich nicht als Stichelei, sondern ganz ehrlich. Ich bin dabei!

Fry

**StefanW** · 27.04.2012, 14:56

Vorschläge sehen für mich erstmal sehr gut aus, muss aber Makki bewerten, weil das ist sein Verantwortungsbereich.

Danke sehr!

Stefan

**makki** · 28.04.2012, 01:44

Zitat von Bodo Beitrag anzeigen

Man merkt den Stress bei Euch schon, ist auch normal.

Nun, da geht ab und zu das überdruckventil auf und dann triffts vielleicht auch manchmal den (gerade) falschen. Aber im Kern muss man sich auch nicht täglich denselben Fundament-losen sch*** anhören, wenn mir jemand die GPL zu erklären versucht,fühle ich mich besonders verletzt..
Weil man zeige mir mal den Hersteller, der *alles* per apt-get source bereitstellt und sogar noch drauf achtet, das des auch cros-plattform geht..

Zitat von Fry Beitrag anzeigen

* Einfache Unterscheidung des Aufrufgrundes durch eine entsprechend vorbesetzte Variable $event (siehe Plugin-Skeleton für einen Vorschlag)

Das wurde bereits "in die Liste" aufgenommen..

* %plugin_subscribe: separat für Telegrammtypen (write/read/response) ermöglichen -> reduziert Aufrufe mit sofortigem return, vermeidet mögliche Anfängerfehler

Die Plugins waren anfangs so nie vorgesehen, "Schuld" ist irgendwie Chris durch vehemenz

Und nun ist es halt so
Du musst aber immer bedenken, die meisten sollen/wollen/müssen solche Detail nicht verstehen!
Die Zielgruppe sind Menschen die den Unterschied zwisch hash und Array nicht kennen, sollen sie auch nicht müssen,,

* %eibgaconf auch invers indizieren

Naja, das kostet abwärtskompatibel den 8fachen Speicher; nur so ein Beispiel: 40kb %eibgacon mit Conifg::Tiny einzulesen braucht mal flockige 2MB weniger als das mit Config::Std multipliziere man mit 10-50 Threads; (daher meine Meinung das 100% auf CPAN 100% kaputt/Schrott sind..)

(also $eibgaconf{$ga}{name} sollte genauso funktionieren wie $eibgaconf{$name}{ga}) -> das ist sehr leicht zu realisieren, vermutlich eine einzige Zeile oder foreach-Schleife im wiregated.pl.

Kann sein, muss aber nicht, das muss man sich leider vorher sehr genau ansehen, das ich von Perl nicht so begeistert wie 2008 bin steht nicht nur zwischen den Zeilen aber dazu habe ich nun zu stehen..
Mir bleibt die Karre gerade bei 5% an 30 min des Tages zwischen Config::Std und DB::File sehen, herzlichen Glückwiunsch..

* Zeitbeschränkung auf 10s aufheben, stattdessen in einem parallelisierten System aber verbieten, dass ein noch laufendes Plugin nicht ein zweites Mal aufgerufen wird (no reentry

).
Faktisch sind es schon länger 30s, mit dem nächsten Update 60s; macht aber wenig Sinn weils single-threaded halt brutal bremst.. Multi-threaded ist in perl aber so nicht vorgesehen bzw. komplett kaputt!Sollten daran zweifel bestehn bitte ausprobieren..

Dazu (parallel) gibts schon länger ne Idee, das Problem war bisher das jegliches threading unter Perl halt nur in der Doku gut klingt, in der Praxis leider eine komplette Lüge ist (ausser man empfindet das forken von prozessen, um posix unter windows zu emulieren als "threading")

Ich weiss, das ist gejammer, soll nur sagen das das Leben eben kein Ponyhof ist

Makki

**Fry** · 28.04.2012, 11:39

Zitat von makki Beitrag anzeigen

Nun, da geht ab und zu das überdruckventil auf und dann triffts vielleicht auch manchmal den (gerade) falschen. Aber im Kern muss man sich auch nicht täglich denselben Fundament-losen sch*** anhören, wenn mir jemand die GPL zu erklären versucht,fühle ich mich besonders verletzt..

Kann ich verstehen, wobei ich das nicht persönlich nehme, wenn ich gerade der Falsche bin :-) . Meine Nachhaken wurde durch die Aussage provoziert, es gebe da einen owfs-Patch, der ein Problem löse, "upstream" geschickt wurde, allerdings hier auch auf Nachfragen nicht gepostet wird. Wobei ich mir nicht die Mühe gemacht habe, die Sources zu prüfen. Warum auch, bin ja kein Privatdetektiv (obwohl ich früher immer "Magnum PI" gemocht habe...)

Zitat von makki Beitrag anzeigen

Weil man zeige mir mal den Hersteller, der *alles* per apt-get source bereitstellt und sogar noch drauf achtet, das des auch cros-plattform geht..

Canonical? Lass uns das Thema jetzt aber bitte ablegen. Read on...

Zitat von makki Beitrag anzeigen

das ich von Perl nicht so begeistert wie 2008 bin steht nicht nur zwischen den Zeilen aber dazu habe ich nun zu stehen.. Mir bleibt die Karre gerade bei 5% an 30 min des Tages zwischen Config::Std und DB::File sehen, herzlichen Glückwiunsch..

Diese Aussage ist vergleichbar mit "ich hab die Schnauze voll von C++, denn libXYZ ist nicht stabil. Du meinst CPAN, hackst aber auf Perl.

Naja, ich will ja helfen, so gut ich kann. Ich programmiere alle möglichen Hacks in Perl, nutze dabei CPAN aber so wenig wie möglich. Mit DB::File bspw. kenne ich mich gar nicht aus - kann mir allerdings nicht vorstellen, dass gerade Datenbankzugriffe buggy sind (Hauptanwendung von CGIs, und welches Paket nutzen die?).

Zum Thema Config::Std habe ich mich jetzt mal hingesetzt und den wiregated.pl mit so gepatcht, dass er ohne Config::Std funktioniert. Das macht ihn potenziell schneller, weniger speicherfressend, und dein Comment "FIXME" ist ja schon fast wie eine Bestellung :-).

Nebenbei habe ich auch noch meinen kleinen Wunsch bzgl. eibgaconf eingebaut (Indizierung der %eibgaconf nach GAs, Namen und Kurznamen), und da hier mit Referenzen gearbeitet wird, dürfte das auf gar keinen Fall den mehrfachen Speicherplatz in Anspruch nehmen.

Meine eibga.conf hat jedenfalls 104k, und alles läuft bisher problemlos.

Jetzt noch der Disclaimer: EXPERIMENTAL! - nur wer weiß was er tut, sollte diesen Patch ausprobieren und vorher Backups machen usw usf.

Have fun!
Fry

Code:

--- wiregated.pl.mod    2012-04-28 11:04:31.000000000 +0200
+++ wiregated.pl        2012-04-28 11:59:49.000000000 +0200
@@ -31,7 +31,8 @@
 use IO::Socket;
 use IO::Select;
 use FileHandle;
-use Config::Std { def_sep => '=', read_config => 'my_read_cfg', write_config => 'my_write_cfg' }; #FIXME: 1244kB
+sub my_read_cfg;
+sub my_write_cfg;
 # fork daemon
 use Proc::Daemon;
 Proc::Daemon::Init unless $opts{d};
@@ -95,7 +96,6 @@
 
 my %wg_config;
 my %eibgaconf;
-my %wg_config_local;
 my %wg_state;
 my @a_owdev_buttons;
 my @a_owdev_pio;
@@ -1126,8 +1126,7 @@
 # (re)read config
 if ((stat($owdev_cfgfile))[9] > $lastreadtime) {
     if (-e $owdev_cfgfile) {
-        my_read_cfg $owdev_cfgfile => %wg_config_local;
-        %wg_config = %wg_config_local;
+        my_read_cfg $owdev_cfgfile, \%wg_config;
         $lastreadtime = time();
         while( my ($k, $v) = each(%wg_config) ) {
                 DEBUG("CONFIG: Sensor $k Type $wg_config{$k}{'type'} !");
@@ -1152,7 +1151,7 @@
       }
     }
     if (-e '/etc/wiregate/eibga.conf') { 
-      my_read_cfg '/etc/wiregate/eibga.conf' => %eibgaconf;
+      my_read_cfg '/etc/wiregate/eibga.conf', \%eibgaconf;
     }
     } else {
         LOGDIE("unable to read config $owdev_cfgfile");
@@ -1342,7 +1341,7 @@
     if($wg_config{''}{'eib_logging'} eq "1") { close FILE_EIBLOG; }
     $xpl->send_hbeat_end() if defined $xpl; 
     # save state 
-    my_write_cfg %wg_state, $owdev_statefile;
+    my_write_cfg \%wg_state, $owdev_statefile;
     threads->exit(); 
     };
 $SIG{KILL} = sub { 
@@ -1350,19 +1349,19 @@
     if($wg_config{''}{'eib_logging'} eq "1") { close FILE_EIBLOG; }
     $xpl->send_hbeat_end() if defined $xpl; 
     # save state 
-    my_write_cfg %wg_state, $owdev_statefile;
+    my_write_cfg \%wg_state, $owdev_statefile;
     threads->exit(); 
     };
 
 # Read state
 if (-e $owdev_statefile) {
-        eval { my_read_cfg $owdev_statefile => %wg_state; };
+        eval { my_read_cfg $owdev_statefile, \%wg_state; };
         if ($@) { #statefile trashed, recreate
-      my_write_cfg %wg_state, $owdev_statefile;
+      my_write_cfg \%wg_state, $owdev_statefile;
       INFO("statefile unreadable $owdev_statefile re-created");
     }
 } else { # create state file 
-    my_write_cfg %wg_state, $owdev_statefile;
+    my_write_cfg \%wg_state, $owdev_statefile;
     INFO("statefile $owdev_statefile created");
 }
 
@@ -1425,7 +1424,7 @@
   # save state
   if (time() > $laststatesaveime+30) {
     $laststatesaveime = time();
-    my_write_cfg %wg_state, $owdev_statefile;
+    my_write_cfg \%wg_state, $owdev_statefile;
     DEBUG("statefile $owdev_statefile saved");
   }
 
@@ -1475,7 +1474,7 @@
 }
 DEBUG("Thread ow2eib normal exit;");
 # save state 
-my_write_cfg %wg_state, $owdev_statefile;
+my_write_cfg \%wg_state, $owdev_statefile;
 $xpl->send_hbeat_end() if defined $xpl; 
 } # END ow2eib-thread
 
@@ -2269,6 +2268,98 @@
   return @ret;
 }
 
+
+sub my_read_cfg
+{
+    my $cfgfile=shift;
+    my $cfghash=shift;
+    %{$cfghash}=();
+
+    open CONF, "<$cfgfile" || die "Could not open $cfgfile for reading";
+    $/="\n";
+    
+    my $record={};
+    my $key=undef;
+
+    while(<CONF>)
+    {
+       if(/^\s*\[\s*(.+?)\s*\]\s*$/)
+       {
+           my $newkey=$1;
+                     
+           if($key) # flush last record
+           {
+               if(defined $record->{name} && $cfgfile=~/eibga/)
+               {
+                   $record->{ga}=$key;
+                   $cfghash->{$record->{name}}=$record;
+                   
+                   # specific to my GA scheme (Fry)
+                   $record->{name}=~/^\s*(\S+)/;
+                   $record->{short}=$1;
+                   $record->{short}="ZV_$1" if $record->{name}=~/^Zeitversand.*(Uhrzeit|Datum)/; # short versions of "Zeitversand"
+                   $cfghash->{$record->{short}}=$record;
+                   # end of specific part
+               }
+               $cfghash->{$key}=$record;
+           }
+           
+           # start new record
+           $record={};
+           $key=$newkey;
+       }
+       elsif(/^\s*(.+?)\s*\=\s*(.*?)\s*$/)
+       {       
+           $record->{$1} = $2;
+       }
+    }
+    close CONF; 
+    
+    if($key) # flush last record
+    {
+       if(defined $record->{name} && $cfgfile=~/eibga/)
+       {
+           $record->{ga}=$key;
+           $cfghash->{$record->{name}}=$record;
+           
+            # specific to my GA scheme (Fry)
+           $record->{name}=~/^\s*(\S+)/;
+           $record->{short}=$1;
+           $record->{short}="ZV_$1" if $record->{name}=~/^Zeitversand.*(Uhrzeit|Datum)/; # short versions of "Zeitversand"
+           $cfghash->{$record->{short}}=$record;
+           # end of specific part
+       }
+       $cfghash->{$key}=$record;
+    }
+} 
+    
+
+sub my_write_cfg
+{
+    my $cfghash=shift;
+    my $cfgfile=shift;
+
+    open CONF, ">$cfgfile" || die "Could not open $cfgfile for writing";
+    
+    for my $s (keys %{$cfghash})
+    {
+       next if $cfgfile=~/eibga/ && $s!~/^[\'\/0-9]+$/;
+       
+       print CONF "[$s]\n";
+
+       for my $k (keys %{$cfghash->{$s}})
+       {
+           print CONF "\t$k = $cfghash->{$s}{$k}\n";
+       }
+    }
+    
+    close CONF;
+}
+
+
+
+
+
 =pod
 
 =head1 NAME

**makki** · 29.04.2012, 20:19

Zitat von Fry Beitrag anzeigen

..es gebe da einen owfs-Patch, der ein Problem löse, "upstream" geschickt wurde, allerdings hier auch auf Nachfragen nicht gepostet wird.

Weils nunmal gepostet wurde, wers nicht findet soll Google fragen (ich spar mir jetzt den LMGTFY), der komplette Source im repo liegt -> und das hier einfach nichts verloren hat, weil es den gemeinen Anwender eher verwirrt als hilft

Aber um das Thema hoffentlich abzuschliessen: Re: [Owfs-developers] Problems in owfs2.p14 DS9490 , http://repo.wiregate.de/wiregate/poo...-2+nmu1.tar.gz

Du meinst CPAN, hackst aber auf Perl.

Nene, ich mein schon beides, weil wer sich das forken in Perl ausgedacht - und es dann fälschlicherweise Threads genannt hat, muss IMHO schon auch ganz schön hartes Zeug geraucht haben

(Oder den Unterschied zwischen Prozessen, Threads, Fibers, .. nicht verstanden haben)

DB_File ist ja core, nicht CPAN und das wirft (auch ohne Threads) halt mal so zu 2-10% beim laden einfach so mal einen segfault, was mal sicher nicht an der libdbd liegt; irgendwo hab ich auch den Link zu den Bugreports aus den früher 2000ndern, der dann lapidar mit sowas ähnlichen wie "is halt so" abgetan wurde

Klar, solange man Perl-scripts in der crontab aufruft ist das natürlich alles eher egal..
Aber das ist nun eh Vergangenheit, zum Glück ist der Mensch lernfähig..

Zum Thema Config::Std habe ich mich jetzt mal hingesetzt und den wiregated.pl mit so gepatcht, dass er ohne Config::Std funktioniert. Das macht ihn potenziell schneller, weniger speicherfressend, und dein Comment "FIXME" ist ja schon fast wie eine Bestellung :-).

Das ist doch mal ne Massnahme! Danke! Sehe ich mir an sobald sich der Nebel an der Ostfront lichtet. aber wird sicher übernommen. Weil bestellt

Und wenn Wünsche durch funktionierenden Code formuliert sind, habe ich damit für gewöhnlich gleich garkein Problem

(Nachdem da aber im Hintergrund gerade kräftig geschraubt wird und das doch eher ziemlich "individuell" ist, da hat jeder so einen eigenen Slang mit der bez. von GA's: keine Garantie für zukünftige Versionen!)

Makki

Ankündigung

Utility: Gruppenadressen in Logdateien decodieren

[wiregate] Utility: Gruppenadressen in Logdateien decodieren

Kommentar

Kommentar

Kommentar

Kommentar

Kommentar

Kommentar

Kommentar

Kommentar

Kommentar

Kommentar

Kommentar

Kommentar

Kommentar

Kommentar