- √ - Logiken / Editor?

[makki]

Darf man fragen, wie du es heute machen würdest?

Klar, fragen darf man alles
Wenn ich auf der grünen Wiese wäre, vermutlich in C++ mit LUA-"Plugins"
Bin aber nicht auf der grünen Wiese, also wird an einer C(++)-Laufzeitumgebung (daemon) für die Perl-Plugins gearbeitet. API-kompatibel natürlich, wegen der Wiese..

Perl ist Klasse, aber nicht als Basis für nen daemon, ich nutze es selbst gerne und kenne mich darin wohl auch ein bisschen aus, durfte hierbei aber ganz deutlich die Grenzen kennenlernen.
Auf einem Octacore-Xeon mit 32GB RAM ist mir das freilich wurscht, ob das gelegentliche Skript jetzt 50 oder 500ms braucht und 150kb oder 5MB RAM (so in etwa ist das Verhätniss zwischen schlechtem Perl-code und gutem C-Code, wo man einfach mehr nachdenken muss..)
Aber Perl braucht eine strenge "Mama" (siehe Apache mod_perl z.B.) sonst versabbert es Resourcen ohne Ende, am laufenden Band..

Auch die Perl-Philosophie (es gibt mehr als einen Weg...) spricht mich sehr an.

Für die Plugins ansich ist es schön, weil (IMHO) einfach erlern- und benutzbar, das soll, wird und muss auch so bleiben!
Für den Unterbau wird Anwendertransparent mittelfristig was anderes kommen, so Gott will

Makki

[Fry]

Klar, fragen darf man alles
Wenn ich auf der grünen Wiese wäre, vermutlich in C++ mit LUA-"Plugins"

Na da bin ich aber froh, dass du nicht auf der grünen Wiese bist.
Ich kenne LUA nicht, hab gerade mal den Wikipedia-Artikel überflogen und, naja, hab nichts gesehen was ich brauche... Ein extrem kompakter Interpreter mag "elegant" sein, ich brauche aber "komfortabel". Und da ist Perl mit seinem Sprachumfang, der flexiblen Syntax usw. einfach optimal.

Bin aber nicht auf der grünen Wiese, also wird an einer C(++)-Laufzeitumgebung (daemon) für die Perl-Plugins gearbeitet. API-kompatibel natürlich, wegen der Wiese..

(was ist die Wiese eigentlich, wenn sie nicht grün ist?)

Guter Ansatz, allerdings viel Arbeit... nutzt du libperl++ oder was anderes?

Perl ist Klasse, aber nicht als Basis für nen daemon, ich nutze es selbst gerne und kenne mich darin wohl auch ein bisschen aus, durfte hierbei aber ganz deutlich die Grenzen kennenlernen.

...und die wären? Geschwindigkeit?

Auf einem Octacore-Xeon mit 32GB RAM ist mir das freilich wurscht, ob das gelegentliche Skript jetzt 50 oder 500ms braucht und 150kb oder 5MB RAM (so in etwa ist das Verhätniss zwischen schlechtem Perl-code und gutem C-Code, wo man einfach mehr nachdenken muss..)

Ich glaube DAS ist der springende Punkt. Wenn man "high-level" (Skript) programmiert, muss man mitdenken, was man da eigentlich schreibt und ob es effizient ist. C++ verzeiht einem da sicher etwas mehr.

Aber Perl braucht eine strenge "Mama" (siehe Apache mod_perl z.B.) sonst versabbert es Resourcen ohne Ende, am laufenden Band..

Eines verstehe ich natürlich: du möchtest den wiregated gegen wildgewordene Plugins schützen. Andererseits: Memory-leaks kannst du in C++ eher noch leichter produzieren, und falsche Algorithmen auswählen ebenfalls (ohne Hashes und regexp kommt schnell mal ne lineare Suche rein, die dann Zeit verbrät, usw...)

Für die Plugins ansich ist es schön, weil (IMHO) einfach erlern- und benutzbar, das soll, wird und muss auch so bleiben!

Prima, dann sind meine Bedürfnisse jedenfalls schon mal abgedeckt.

Grüße,
Fry

PS. Habe gerade mein Schlüsselbrett erweitert: jetzt sagt es die Außentemperatur auf, wenn jemand einen Schlüssel wegnimmt. Sowas würde in C++ wenig Freude machen, in Perl ist es ruckzuck gehackt.

[makki]

Na da bin ich aber froh, dass du nicht auf der grünen Wiese bist.

Keine Bange

Ich kenne LUA nicht, hab gerade mal den Wikipedia-Artikel überflogen und, naja,

Es sehr schlank, weniger verbreitet aber auch egal weil es steht nicht auf der Options-Liste..
Ich zitiere einfach nur mal perldebguts:

Perl is a profligate wastrel when it comes to memory use. There is a saying that to estimate memory usage of Perl, assume a reasonable algorithm for memory allocation, multiply that estimate by 10, and while you still may miss the mark, at least you won't be quite so astonished. This is not absolutely true, but may provide a good grasp of what happens.

Assume that an integer cannot take less than 20 bytes of memory, a float cannot take less than 24 bytes, a string cannot take less than 32 bytes (all these examples assume 32-bit architectures, the result are quite a bit worse on 64-bit architectures). If a variable is accessed in two of three different ways (which require an integer, a float, or a string), the memory footprint may increase yet another 20 bytes. A sloppy malloc(3) implementation can inflate these numbers dramatically.

On the opposite end of the scale, a declaration like

sub foo;

may take up to 500 bytes of memory, depending on which release of Perl you're running

ich brauche aber "komfortabel". Und da ist Perl mit seinem Sprachumfang, der flexiblen Syntax usw. einfach optimal.

Da bin ich (aus Anwendersicht) völlig bei dir und das soll sich auch nicht ändern, aus Design-Sicht bereitet es jedoch einiges an Schmerzen..

(was ist die Wiese eigentlich, wenn sie nicht grün ist?)

Hmm, gute Frage, meine ist gerade gelb weil ich nicht vertikutiert habe, die des Nachbarn braune Erde weil er

Guter Ansatz, allerdings viel Arbeit... nutzt du libperl++ oder was anderes?

Perl ist in C geschrieben, perlembed.. Viel Arbeit ist es aber..

...und die wären? Geschwindigkeit?

Auch, aber nicht nur. Das Threading in Perl ist schlicht keins, sondern forking mit kostenlosem segfault bei 80% der PM's aus CPAN, das steht halt so nirgends, ausser wenn man zwischen den Zeilen lesen kann..

C++ verzeiht einem da sicher etwas mehr.

Eher das Gegenteil, vorher muss man mehr denken, das soll aber ja auch bei den Plugins so sein, das man da nicht soooviel denken muss

Andererseits: Memory-leaks kannst du in C++ eher noch leichter produzieren,

Ganz klar, dort macht man diese aber bewusst durch Fehler/Unwissen.
Der Perl-Skripter (ist nicht negativ gemeint, ich bin selbst ein solcher) kennt das ganze Thema eigentlich nicht - sollte er aber - weil Perl einem diese kostenlos und völlig intransparent - auch als Sahnehaube gibt

und falsche Algorithmen auswählen ebenfalls

Ein weiteres Problem, kein Feature: ich behaupte viele der CPAN-Module sind grausig schlecht; man verwendet diese sorglos bis man sich (Negativ-Beispiel Config::Std) irgendwann frägt, warum zum Henker das jetzt 2sek dauert; dann schaut man in den Source und fällt vom glauben ab, welcher Praktikant das wohl geschrieben hat..
Natürlich kann man in jeder Sprache schlechten Code schreiben, keine Frage, aber in Perl ist schon sehr auffällig, wieviel es davon gibt.. Vielleicht weil es soviel gibt..

PS. Habe gerade mein Schlüsselbrett erweitert: jetzt sagt es die Außentemperatur auf, wenn jemand einen Schlüssel wegnimmt. Sowas würde in C++ wenig Freude machen, in Perl ist es ruckzuck gehackt.

Schon klar, ich mag das so auch lieber aber wenn man für solche Aufgaben auf einem PIII-500 an die Grenzen stösst bin ich halt immernoch der Typ eher über den Code nachzudenken, als eine fettere HW zu empfehlen

Makki

[Fry]

Auch, aber nicht nur. Das Threading in Perl ist schlicht keins, sondern forking mit kostenlosem segfault bei 80% der PM's aus CPAN, das steht halt so nirgends, ausser wenn man zwischen den Zeilen lesen kann..

DAS ist mal ein Argument. Wusste ich nicht, habe bisher in Perl nur forks gebraucht und dann auch verwendet (ohne segfault).

Ein weiteres Problem, kein Feature: ich behaupte viele der CPAN-Module sind grausig schlecht; man verwendet diese sorglos bis man sich (Negativ-Beispiel Config::Std) irgendwann frägt, warum zum Henker das jetzt 2sek dauert; dann schaut man in den Source und fällt vom glauben ab, welcher Praktikant das wohl geschrieben hat..

...und dann schreibt man es eben selbst, ist in Perl ja meist nicht sooo schwer...

Übrigens: wie sieht es mit der Qualität der C++ STL aus? (ich habe früher viel C++ programmiert, allerdings bevor die STL die C++-Welt revolutioniert hat). Ich glaube, zwischen C-Programmierung und C++/STL-Programmierung ist ein ebenso großer Unterschied wie zwischen C und Perl. Naja, zumindest ähnliche Größenordnung.

Natürlich kann man in jeder Sprache schlechten Code schreiben, keine Frage, aber in Perl ist schon sehr auffällig, wieviel es davon gibt.. Vielleicht weil es soviel gibt..

Ja, das stimmt: Perl lädt dazu ein, "quick hacks" zu schreiben, und nichts lebt so lange wie Provisorien...

Schon klar, ich mag das so auch lieber aber wenn man für solche Aufgaben auf einem PIII-500 an die Grenzen stösst bin ich halt immernoch der Typ eher über den Code nachzudenken, als eine fettere HW zu empfehlen

Stimme ebenfalls zu. Es sei denn, es liegt an den eingesetzten Algorithmen. Dann hilft weder Wechsel der Hardware- noch Softwareplattform.

In jedem Fall: DANKE für das Wiregate. So wie es ist. Es macht sehr viel Freude.

Grüße, Fry

PS. Auf meiner persönlichen Wunschliste steht übrigens einen russconnectd in RIO für Russound C5 deutlich VOR einem wiregated in C++...

PS2. ein weiteres Spielzeug ist die Fermax/Alphatec-Türstation. Ein sehr günstiges SIP/Videotelefon, enthält eine Webcam in ok-Qualität (nicht wie Mobotix, aber wesentlich besser als analoge Anlagen) und ebenfalls Linux mit root-Zugang, allerdings sehr viel (!) schwachbrüstiger als das Wiregate. Habe dem Wiregate Asterisk draufgeladen und der Fermax gerade beigebracht, den Zahlencode für den Zugang täglich zu ändern. Das sind so die kleinen Freuden des Hobbyisten...

[MicHau]

PS2. ein weiteres Spielzeug ist die Fermax/Alphatec-Türstation.

Off-Topic, aber ich frage trotzdem, da ich keinen gescheiten Link dazu per Google finden kann. Vielleicht interessiert es ja noch jemand anderen.
Hast du einen Link? Bin auch auf der Suche nach einer neuen Türstation.
Danke

[Fechter65]

ALPHATECH TECHNOLOGIES s.r.o. – Czech developer, producer and exporter of telco solutions
http://www.provu.co.uk/products/prot...e/cityline.pdf

siehe auch hier:
https://knx-user-forum.de/85267-post2.html
https://knx-user-forum.de/103217-post6.html
https://knx-user-forum.de/knx-eib-fo...hstelle-2.html
https://knx-user-forum.de/182055-post7.html
https://knx-user-forum.de/207405-post19.html
https://knx-user-forum.de/207411-post20.html und weitere in diesem Thread

Gruss
Diego

[MicHau]

Danke, dann hatte ich es eigentlich doch gefunden, nur die Kombination "Fermax/Alphatec" hat mich nicht weitergebracht.

[Fry]

ALPHATECH TECHNOLOGIES s.r.o. – Czech developer, producer and exporter of telco solutions

Einfach emailen, Petr ist sehr hilfsbereit.

Ich sollte vielleicht noch erwähnen, dass meine Türstation tadellos funktioniert, im Web Interface sehe ich auch das Videobild (Qualität ist ok), auch SIP-Audio (gute Qualität, natürlich kein Hifi), aber im Windows-basierten Softphone kommt das Videobild irgendwie noch nicht an. Liegt aber sehr sehr wahrscheinlich an einer fehlerhaften Konfiguration... in jedem Fall das nächste Problem auf meiner Todo-Liste

Ich habe übrigens eine 5CP201KIP (die Produktnamen sind etwas kryptisch), die hat ein Klingelschild, links und rechts je einen Knopf, darüber die Kamera (Microsoft-Webcom) und darunter eine Zahlentastatur fürs Wählen und Code-eingeben. Bei mir wird das Ganze komplettiert mit einem Türöffner per iButton (finde ich fast so komfortabel wie Transponderchips, und WESENTLICH günstiger).

Hier ein Bild.

Auf Fingerprint verzichte ich. Es wäre die vierte Art, die Tür von außen zu öffnen - so viel Auswahl brauche ich nicht.

Fry

[Chris M.]

Andererseits: Memory-leaks kannst du in C++ eher noch leichter produzieren, und falsche Algorithmen auswählen ebenfalls
[...]
PS. Habe gerade mein Schlüsselbrett erweitert: jetzt sagt es die Außentemperatur auf, wenn jemand einen Schlüssel wegnimmt. Sowas würde in C++ wenig Freude machen, in Perl ist es ruckzuck gehackt.

Die Logik-Engine gehört in eine native Sprache wie C++ - aber nicht die Logiken.

Die Logiken kann man in beruhigt in Skript-Sprachen schreiben, wobei ich der Meinung bin, das sollte grafisch geschehen!

Übrigens: wie sieht es mit der Qualität der C++ STL aus? (ich habe früher viel C++ programmiert, allerdings bevor die STL die C++-Welt revolutioniert hat). Ich glaube, zwischen C-Programmierung und C++/STL-Programmierung ist ein ebenso großer Unterschied wie zwischen C und Perl. Naja, zumindest ähnliche Größenordnung.

STL ist inzwischen (seit ein paar Jahren) allgemein sehr gut.
Und mit BOOST ist eine (manchmal: zu) geniale Erweiterung verfügbar.

Wem modernes C++ zu modern ist, der kann aber beruhigt Qt verwenden. Schönes, solides klassisches C++ mit dem man schnell mächtige Programme schreiben kann (auch mit CLI!)

[Fry]

Die Logik-Engine gehört in eine native Sprache wie C++ - aber nicht die Logiken.

Mag sein, aber meine Meinung dazu wäre nicht so gefestigt.

Die Logiken kann man in beruhigt in Skript-Sprachen schreiben, wobei ich der Meinung bin, das sollte grafisch geschehen!

Da bin ich ganz klar der Meinung, das sollte der User auswählen dürfen. Ich arbeite bspw. wesentlich effizienter mit Tabellen und Skripten als mit Klick-Orgien.

Beispiel: ich habe meine Gruppenadressen so mit sprechenden Namen versehen, dass manche Zuweisungen zu Geräten und Funktionen klar hervorgehen. Im WG kann ich Zuordnungen automatisieren (mit regexpes). In der ETS4 muss ich durch alles durchklicken. Mühsam und schikanös.

STL ist inzwischen (seit ein paar Jahren) allgemein sehr gut.
Und mit BOOST ist eine (manchmal: zu) geniale Erweiterung verfügbar.

Wem modernes C++ zu modern ist, der kann aber beruhigt Qt verwenden. Schönes, solides klassisches C++ mit dem man schnell mächtige Programme schreiben kann (auch mit CLI!)

Danke für den Einblick. Ich habe allerdings schon lange nichts mehr gemacht. C++ liest sich noch ok, aber mit der STL wird's schnell unübersichtlich für mich...

Fry

[makki]

DAS ist mal ein Argument. Wusste ich nicht, habe bisher in Perl nur forks gebraucht und dann auch verwendet (ohne segfault).

Tja, wenn das so ginge wie es geschrieben steht, wäre das alles kein Problem gewesen - seit Jahren - denn so war es gedacht Ist halt nur leider so das wenn man in Perl einen "sog. Thread" startet ist plötzlich der doppelte RAM weg und ein Prozess mehr da (also theoretisch ist es ein Thread, nominell aber eine Kopie im Speicher und wenn man perl* mal gelesen hat weiss man auch warum..weil es eine Kopie ist..)

...und dann schreibt man es eben selbst, ist in Perl ja meist nicht sooo schwer...

Nö, kein Thema, wenn ich mir dann jeden Pimpfunz wie einen INI-Parser mit unter 3MB verschwendung (ohne die Daten!) jedoch selber schreiben muss, dann ist das in C(++) auch nicht schlimmer

und nichts lebt so lange wie Provisorien...

Wohl wahr, der wiregated.pl so wie er ist, sollte nie das Licht der Welt erblicken sondern als Proof-of-concept friedlich in die Schublade.. Es kommt erstens anders und zweitens als man denkt

In jedem Fall: DANKE für das Wiregate. So wie es ist. Es macht sehr viel Freude.

Danke und bitte, so schlimm kanns ja nicht sein, ich muss mich auch ab und zu ausheulen, warum ich das in einer perfekten Welt gerne besser machen würde

PS. Auf meiner persönlichen Wunschliste steht übrigens einen russconnectd in RIO für Russound C5 deutlich VOR einem wiregated in C++...

Nun, gerne!, RIO braucht man dafür eigentlich nicht, die können dasselbe RNet, da müsste sich nur mal jemand ein bisschen reinknien und herausfinden, welche 2-3bytes (mehr ist es vermutlich nicht!) da nicht 100% passen..
Ich hab keine C3/5, auf der CA* funktioniert das aber seit Monaten wie ein glöckerl (im Gegensatz zu den Jahren vorher auch ohne 2-10s delay..)
Oder eben mit RIO wenns denn sein muss, bevor man da was komplett neues anfängt könnte es sich aber rentieren ein paar Wochen zu warten, ich hab da was modulares im Kopf (ETA: 2020..)
Aber es ist ein gutes Beispiel: es war hier nach vielen Fehlschlägen als Plugin auch nicht wirklich realistisch, also warum nicht mal einfach an 2WE in C runterhacken, Standalone auf den KNX, geht, fertig

Die Logik-Engine gehört in eine native Sprache wie C++ - aber nicht die Logiken.

Die Logiken kann man in beruhigt in Skript-Sprachen schreiben, wobei ich der Meinung bin, das sollte grafisch geschehen!

Ack&Ack..

Wem modernes C++ zu modern ist, der kann aber beruhigt Qt verwenden.

Zu der Kategorie gehöre ich sicherlich (ich liebe bekanntermassen Qt, weil man auch mit Perl&VB-Erfahrung sehr geile - und portable! - GUI-Anwendungen schreiben kann
Das es z.B. für den qHSMon Windows, Linux aber keine Mac-Binaries gibts, daran sind nur die fähigen Mac-Anwender schuld [oder die die es können, nutzen es und sind nur still..]
Aber Qt, Boost ist mir dafür schon wieder ein ticken zu fett, da verschmimmt die Grenze schnell, was noch nativer, effizienter, durchdachter Code und was Bloatware ist - am Ende steht als mahnendes Beispiel CPAN!*1
Man hat halt dazugelernt, so eine richtig gute LE im Kern ist sicherlich genauso eine harte Nuss wie eine (IMHO ein zwingend notwendiger GLE!) aber da geht es weniger darum was man nehmen kann, sondern worüber man vorher nachdenkt.. Und das ist ne Menge..

Makki

*1) Hatte heute (neben 12h aufarbeiten vom nächsten PL) Modbus auf dem Tisch, nur so ein Beispiel, also das Perl-CPAN.pm kann das auch, das ist sogar garnicht so schlecht wie die restlichen 80% dort aber subba-OO (heisst im Klartext, es kann keine verständlichen Fehlermeldungen mehr ausgeben..)
Im Endeffekt ist es mir mit der libmodbus und C leichter gefallen, obwohl ich C sicher um Welten schlechter als Perl kann..

[Fry]

Zweites Beispiel: für vieles ist der Edit-Mode in der CometVisu praktisch. Aber bspw. für die Russound-Zonen-Einrichtung ist Makkis Skript viel praktischer. -> grafische Einrichtung per Klickerei ist manchmal gut, aber sollte nur optional sein. QED
Fry

PS. Zu Russound RIO vs RNET: ich habe das bisher so verstanden, dass RIO das Netzwerkprotokoll ist und RNET über RS232 geht. Falsch?
Und falls dem nicht so ist, woran genau hakt es denn, den russconnectd auf die C5 zu übertragen. Vielleicht kann ich da helfen? (ich habe eine C5, funktioniert prima mit ChrisM s RIO-Skript mit minimalen Anpassungen für die 7. und 8. Zone)

[Fry]

Aber Qt, Boost ist mir dafür schon wieder ein ticken zu fett, da verschmimmt die Grenze schnell, was noch nativer, effizienter, durchdachter Code und was Bloatware ist

Das war genau mein Punkt weiter oben: der Unterschied zwischen

C (wo man recht genau weiß, was man gerade hackt und wieviel Runtime es kosten wird)

und Perl (wo man vage hofft, der Interpreter wird es schon effizient ausführen - in den meisten Fällen wird man dann positiv überrascht, weil Perl schon ziemlich gut ist)

ist ähnlich groß wie

zwischen C und C++/STL/BOOST (was zwar sicher "magisch" ist - hab mal in die Webseite gesehen - wo man aber die Kontrolle über die Algorithmen abgibt in der vagen Hoffnung, jemand anderes hat das schon gemacht).

Nochmal zu Logiken: eine grafische Oberfläche, gerne, wenn die als Speicherformat aber bitte keine binäre Datenbank nutzt sondern XML o.ä., das man ggf auch direkt hacken kann.

(Für Plugins ist aber nach wie vor Perl optimal. Denkt nur mal einen Moment daran, es wäre Visual Basic...)

Fry

[Chris M.]

PS. Zu Russound RIO vs RNET: ich habe das bisher so verstanden, dass RIO das Netzwerkprotokoll ist und RNET über RS232 geht. Falsch?
Und falls dem nicht so ist, woran genau hakt es denn, den russconnectd auf die C5 zu übertragen. Vielleicht kann ich da helfen? (ich habe eine C5, funktioniert prima mit ChrisM s RIO-Skript mit minimalen Anpassungen für die 7. und 8. Zone)

RIO geht wohl auch über RS232 - aber wozu? Ein Netzwerk-Port ist für mich billiger als ein RS232<->USB-Adapter (+ ggf. USB-Hub-Port)

Wenn Du verbesserungen für's Skript hast (wie Zone 7+8), dann bitte in's SVN hochladen, damit alle etwas davon haben.

(Da mein WireGate sich aber immer wieder Zeit zwischen Paket und Plugin gönnt, wäre ich für eine erweiterte Lösung des Deamons durchaus offen...)

Das war genau mein Punkt weiter oben: der Unterschied zwischen

C (wo man recht genau weiß, was man gerade hackt und wieviel Runtime es kosten wird)

und Perl (wo man vage hofft, der Interpreter wird es schon effizient ausführen - in den meisten Fällen wird man dann positiv überrascht, weil Perl schon ziemlich gut ist)

ist ähnlich groß wie

zwischen C und C++/STL/BOOST (was zwar sicher "magisch" ist - hab mal in die Webseite gesehen - wo man aber die Kontrolle über die Algorithmen abgibt in der vagen Hoffnung, jemand anderes hat das schon gemacht).

Stimmt nicht so ganz: zum einen weiß ein guter C++-Programmierer genau, was die gerade gewählte Variante auf Maschinenebene bedeutet - und dank der Templates kann kann man sogar Optimierungen machen, die erst mal undenkbar scheinen (vgl. Barton&Nackman-Trick - wobei die Relevanz im Artikel IMHO nicht sichtbar wird)
Zum anderen ist die STL inzwischen so alt, dass viele Optimierungsschleifen über die Implementierung gelaufen sind. Außerdem garantieren die entsprechenden Container z.B. die Zeitkomplexität der entsprechenden Algorithmen.
Und BOOST wird von einer Community der besten C++-Programmierer geschrieben - oder genauer: BOOST wurde von Mitgliedern des C++-Standard-Komitees gegründet um über entsprechende Bibliotheken sprechen zu können, bevor die in den Standard aufgenommen werden.
Das ist auch quasi die größte Schwäche: die Bibliotheken können sich leicht ändern, bevor sie in Stein gemeißelt werden (was aber kein Unterschied zu normalen Bibliotheken ist)
(Eine andere Schwäche ist, dass so gerne mal C++ bis an die Grenzen des machbaren ausgereizt wird - was nicht zwingend einsteigerfreundlich ist)

Nochmal zu Logiken: eine grafische Oberfläche, gerne, wenn die als Speicherformat aber bitte keine binäre Datenbank nutzt sondern XML o.ä., das man ggf auch direkt hacken kann.

(Für Plugins ist aber nach wie vor Perl optimal. Denkt nur mal einen Moment daran, es wäre Visual Basic...)

Ich habe da in Gedanken immer Simulink und Stateflow. Und genau so wie dort, sollte man bei einer Logik-Engine einzelne Blöcke durchaus auch in anderen Sprachen erstellen können - aber die Verknüpfungen (inkl. der meisten Blöcke) können durchaus grafisch erfolgen.

Wenn ich endlich die nächste CometVisu Version draußen hätte, würde ich mich um die Logik-Engine kümmern können...

[Fry]

RIO geht wohl auch über RS232 - aber wozu? Ein Netzwerk-Port ist für mich billiger als ein RS232<->USB-Adapter (+ ggf. USB-Hub-Port)

Wenn Du verbesserungen für's Skript hast (wie Zone 7+8), dann bitte in's SVN hochladen, damit alle etwas davon haben.

ja klar. Wie geht das? Einfach einchecken? (da könnt ja jeder kommen...)

Stimmt nicht so ganz: zum einen weiß ein guter C++-Programmierer genau, was die gerade gewählte Variante auf Maschinenebene bedeutet -

In dem Satz steckt eine wichtige Einschränkung.... nichts ist so unterschiedlich wie die Qualität von Programmierern.

und dank der Templates kann kann man sogar Optimierungen machen, die erst mal undenkbar scheinen (vgl. Barton&Nackman-Trick - wobei die Relevanz im Artikel IMHO nicht sichtbar wird)

Danke für den Link. Die Relevanz kann man erahnen, verstanden hab ich's aber nicht ganz. Beim Lesen ist mir leider klargeworden, dass ich durch ~12 Jahre ohne aktive C++-Programmierung doch ziemlich "abgehängt" wurde. Würde mich übrigens interessieren, welcher Prozentsatz der C++-Programmierer da überhaupt durchsteigt. Ich erinnere mich an einen durchaus erfahrenen Softwareentwickler mit C-Erfahrung, der nicht wusste, wie Compiler und Linker miteinander spielen (Wirkung des Wortes "static" in Variablendefinitionen außerhalb von Funktionen). Und einen mit C++-Erfahrung, der nicht wusste, warum es "private" und "protected" gibt (is-a / has-a).

Zum anderen ist die STL inzwischen so alt, dass viele Optimierungsschleifen über die Implementierung gelaufen sind. Außerdem garantieren die entsprechenden Container z.B. die Zeitkomplexität der entsprechenden Algorithmen.

Das ist natürlich ein riesiges Argument dafür. Bei modernen Problemstellungen geht es IMHO sowieso mehr um die Zeitkomplexität (N^2 vs N ln N) als um den Faktor davor. Deshalb meine ich ja auch, dass sehr oft Skriptsprachen reichen, auch bei Problemen, die früher klar in Assember oder C gelöst wurden. (C ist ja eigentlich vornehmes Assembler :-)

(Eine andere Schwäche ist, dass so gerne mal C++ bis an die Grenzen des machbaren ausgereizt wird - was nicht zwingend einsteigerfreundlich ist)

Wieder ein anderes Problem sind Compilerbugs.

Ich habe da in Gedanken immer Simulink und Stateflow. Und genau so wie dort, sollte man bei einer Logik-Engine einzelne Blöcke durchaus auch in anderen Sprachen erstellen können - aber die Verknüpfungen (inkl. der meisten Blöcke) können durchaus grafisch erfolgen.

Jep. Nur bitte neben der grafischen Möglichkeit immer auch die Textform erlauben! - dann kann jemand wie ich sich Klickorgien sparen und stattdessen kleine Perl-Skripte die Config-Files erzeugen lassen :-)

Wenn ich endlich die nächste CometVisu Version draußen hätte, würde ich mich um die Logik-Engine kümmern können...

Go! Die CometVisu ist jetzt bereits fantastisch. Hab ich schon erwähnt, dass ich keinen Homeserver habe und auch keinen brauche, dank des Wiregate+CometVisu? Was mehr braucht es?

Schönen Abend,
Fry

PS. Würde gern zum Stammtisch auf der LB am Montag kommen, bin aber leider verhindert, wie es aussieht.