Tasking Library

' schrieb:Ja gut. Reentrant (das meinte ich hier) hat halt den Vorteil, dass keiner warten muss, bis er das VI verwenden darf.

Genau

' schrieb:Dieses Argument geht vor: Des Menschen Wille ist sein Himmelreich.

Na ja.. Siehe auch andere Argumente

' schrieb:Das gefällt mir nicht, weil ich dann immer so viele SubVIs offen hab.

Dafür aber Debugging

' schrieb:Virtuell? Das klappt nicht. Oder willst du deinen abendlichen Schoppen virtuell trinken?

Jeder für sich. Ich habe mein Abendbierchen da

' schrieb:Ja. Und?
"Datenklassen" sind auch in Delphi verpöhnt. Da muss nach Aussage der OOP-Fachleute alles als private deklariert und per Property handlebar sein. Nee. Ich kann auf meine Pointer noch selbst aufpassen.

Sobald es um eine Library zur allgemeinen Verwendung geht, würde ich die Empfehlnugen einhalten, es gibt ja auch unterschiedliche Leute, unterschiedliche Meinungen und unterschiedliche Vorgehensweisen.

Hier geht es wirklich wie im privaten Chat ab. Ich glaube ich werde mit dem Veröffentlichen irgenwelcher Libs aufhören und behalte alles für mich

P.S. nächste Library ist gerade in der Entwicklung, ich warte nun ungeduldig wann es endlich soweit ist, dass ich diese allgemein in vielen Projekten anwenden kann. Zur Zeit nur ans Projekt angepassten Kopien.

Anzeige

' schrieb:Sobald es um eine Library zur allgemeinen Verwendung geht, würde ich die Empfehlnugen einhalten, es gibt ja auch unterschiedliche Leute, unterschiedliche Meinungen und unterschiedliche Vorgehensweisen.

Ja stimmt, du hast Recht. Bei Librarys liegt die Sache etwas anders. Bis jetzt hatte ich nur wenig Sachen, die als Library zu verwenden waren. z.B. Serielle Schnittstelle an sich (in Delphi) oder einen Klimaschrank (CTS/Weis). Wenn etwas komplett projekt-unabhängig ist - wie ein Klimaschrank respektive dessen Ansteuerung - dann ist ein Modul in Form einer Library - samt Styleguide - sinnvoll.

' schrieb:Und ja... Funktionale globale VIs sind eine Verarsche für LV, sind zwar datenflußgeschützt, aber nicht G-Language kompatibel (IMHO, hoffentlich wird Christian damit angeregt hier teilzunehmen).

aber Hallo!

Old Style Globals, bzw. Action Engines sind IMHO immer noch die fortschrittlichste Technik der sich ein LV-Programmierer bedienen kann. Es gibt nichts besseres, wenn es darum geht die Daten dort zu behalten wo sie gebraucht werden. Wenn man natürlich drauf steht baumdicke "Kabelstränge" von der 1. Initialisierung bis zum Ende des VIs quer durch sein Blockdiagramm zu ziehen, dann kann man das gerne machen, ich steh da nich so drauf. Man kann auch ein riesen Framework aus 200 VIs und von mir aus auch LVOOP Klassen aufbauen um Daten hin und her zu schubsen, schneller und effektiver geht's aber mit einer OSG:)kleiner Seitenhieb: LVOOP Objekte können übrigens keine Member Variablen selbst speichern. Wenn du sowas haben willst musst du eine OSG verwenden(AQ hat das "liebevoll" LVOOP style Globals genannt)

Old-Style Globals sind SEHR WOHL Datenfluss-kompatibel:
da für jedes VI gilt (sofern es nicht reentrant ist) dass es nur einmal im Speicher vorhanden ist und "parallele" Aufrufe nacheinander abgearbeitet werden (wodurch die Race Conditions verhindert werden) und der SubVI Call immer genau dann erfolgt wenn die Daten gebraucht werden ist da nicht der geringste Widerspruch zum Datenfluss-Konzept, der einzige Unterschied zu einem "Draht" ist, dass man "den Draht im diesem Fall nicht sieht" und näher kommt man in LV nicht an einen Pointer - selbstverständlich ohne sich um die manchmal tatsächlich grauenerregende Pointer-Arithmetik Gedanken machen zu müssen. Für mich sind OSGs der "anschlusslose, intelligente Draht in der gleiche Farbe wie dein BD-Hintergrund":D- wireless Strom sotusay, davon träumen die Elektriker seit Jahrhunderten!

Und nu bin ich mal ganz offen, und ich hoffe du verzeihst mir (manchmal schaun mich die Leute 5 Jahre lang nicht mehr mit dem Ar*** an, wenn ich "mal ein offenes Wort" spreche):
Das Konzept ist als Konzept, an sich interessant, ich hab auch schonmal an sowas gedoktort, und anschließend wieder verworfen, denn es taugt überhaupt nix, ausser um sich selbst weiterzubilden, Know how in Sachen Architektur aufzubauen und tieferes Verständnis für die Zusammenhänge in LV zu entwickeln. Das k.o. Kriterium bei deiner Achitektur ist: du wandelst alle Daten in Strings um, und ganz ehrlich: du möchtest mir jetzt nicht ernsthaft weismachen, dass ein Konzept, das FREIWILLIG auf die Type-Propagation verzichtet und alle Daten in ihrer Binärrepräsentation zu behandeln (du MUSST am Ende der Queue immer wissen was du reingeschoben hast, sonst kommt zwangsläufig Müll dabei raus - und das stell mal bei 10+ Tasks sicher!!) einer OSG überlegen ist. Und gleichzeitig zu schreiben dass OSG's eine Verarsche sind, ganz ehrlich Eugen, da fällt mir nur noch ein "STEINIGT IHN" ein

Witzigerweise hab ich am Freitag an genau der gleichen Problematik gebastelt (ich benutze recht viele Action Engies um Queues zu erstellen und wollte aus einer dieser Action Engines eine Klasse machen um sie als Basisklasse zu verwenden...) und ich bin zu dem Schluss gekommen - und ich vermute mal da bist du auch drüber gestolpert, sonst hättest du die Daten, die du übertragen willst, nicht als String geflattet - Queues verhindern die Type Propagation von Objekten. Mein Fazit war mal wieder: "ach verdammte Scheisse, wär ja gar nich so schlecht dieses OOP, wenn man's denn nur vernünftig einsetzen könnte *heul*". d.h. so lange man nicht über das dynamic dispatch Terminal den Datentyp der Queue beim "Dequeue Element" festlegen kann, bleibt die Umsetzung in LVOOP einfach nur ein Muster ohne Wert, eine Spielerei, nicht tauglich für "in Production Projekte" ...

so far,
CB

' schrieb:aber Hallo!

Old Style Globals, bzw. Action Engines sind IMHO immer noch die fortschrittlichste Technik der sich ein LV-Programmierer bedienen kann. Es gibt nichts besseres, wenn es darum geht die Daten dort zu behalten wo sie gebraucht werden. Wenn man natürlich drauf steht baumdicke "Kabelstränge" von der 1. Initialisierung bis zum Ende des VIs quer durch sein Blockdiagramm zu ziehen, dann kann man das gerne machen, ich steh da nich so drauf. Man kann auch ein riesen Framework aus 200 VIs und von mir aus auch LVOOP Klassen aufbauen um Daten hin und her zu schubsen, schneller und effektiver geht's aber mit einer OSG:)kleiner Seitenhieb: LVOOP Objekte können übrigens keine Member Variablen selbst speichern. Wenn du sowas haben willst musst du eine OSG verwenden(AQ hat das "liebevoll" LVOOP style Globals genannt)

Ich wollte eigentlich nicht über die Vor- und Nachtele der Programmiertechniken (OSG vs. LVOOP) diskutieren, aber warum eigentlich nicht.
Also 200 VIs packst du nicht in eine einzige OSG, sonst hast du viele viele Auswahlmöglichkeiten und Einstellmöglichkeiten, die nicht in eine Enum-Liste passen. Ich meine klar, ne Liste kann mehr Elemente beinhalten, aber man braucht ja auch ausser dem Kommando noch die Parameter. Somit brauchst du mehr von OSGs, die die gleiche Daten in Form eines Clusters zueinander übergeben.

Die Werte der Member Variables befinden sich im Klassen-Wire, warum sollte man die noch extra irgendwo abspeichern. Oder besser gesagt, ich verstehe nicht so ganz was gemeint ist.

' schrieb:Old-Style Globals sind SEHR WOHL Datenfluss-kompatibel:
da für jedes VI gilt (sofern es nicht reentrant ist) dass es nur einmal im Speicher vorhanden ist und "parallele" Aufrufe nacheinander abgearbeitet werden (wodurch die Race Conditions verhindert werden) und der SubVI Call immer genau dann erfolgt wenn die Daten gebraucht werden ist da nicht der geringste Widerspruch zum Datenfluss-Konzept, der einzige Unterschied zu einem "Draht" ist, dass man "den Draht im diesem Fall nicht sieht" und näher kommt man in LV nicht an einen Pointer - selbstverständlich ohne sich um die manchmal tatsächlich grauenerregende Pointer-Arithmetik Gedanken machen zu müssen. Für mich sind OSGs der "anschlusslose, intelligente Draht in der gleiche Farbe wie dein BD-Hintergrund":D- wireless Strom sotusay, davon träumen die Elektriker seit Jahrhunderten!

Keine Frage, dass sie zumindest so funktionieren, aber von aussen sehen sie nicht so aus. Ich will auch keinen überzeugen sie nicht zu verwenden. Ich habe nur gesagt, dass OSGs für mich fremd aussehen, obwohl ich auf die schnelle diese immer wieder gerne verwende.

' schrieb:Und nu bin ich mal ganz offen, und ich hoffe du verzeihst mir (manchmal schaun mich die Leute 5 Jahre lang nicht mehr mit dem Ar*** an, wenn ich "mal ein offenes Wort" spreche):
Das Konzept ist als Konzept, an sich interessant, ich hab auch schonmal an sowas gedoktort, und anschließend wieder verworfen, denn es taugt überhaupt nix, ausser um sich selbst weiterzubilden, Know how in Sachen Architektur aufzubauen und tieferes Verständnis für die Zusammenhänge in LV zu entwickeln. Das k.o. Kriterium bei deiner Achitektur ist: du wandelst alle Daten in Strings um, und ganz ehrlich: du möchtest mir jetzt nicht ernsthaft weismachen, dass ein Konzept, das FREIWILLIG auf die Type-Propagation verzichtet und alle Daten in ihrer Binärrepräsentation zu behandeln (du MUSST am Ende der Queue immer wissen was du reingeschoben hast, sonst kommt zwangsläufig Müll dabei raus - und das stell mal bei 10+ Tasks sicher!!) einer OSG überlegen ist. Und gleichzeitig zu schreiben dass OSG's eine Verarsche sind, ganz ehrlich Eugen, da fällt mir nur noch ein "STEINIGT IHN" ein

Also erstens - es ist wirklich so, dass ich Kritik zur Verwendung und Verbesserungsvorschläge hier brauche.
Zweitens - Strings sind im Unterschied zu den Typedef-Enums speicherfressender und langsamer, dafür aber universell. Anders (abgesehen von Variant o.ä.) kann ich mir keine Library solcher Art, die projektunabhängig verwendet werden kann, vorstellen.

' schrieb:Witzigerweise hab ich am Freitag an genau der gleichen Problematik gebastelt (ich benutze recht viele Action Engies um Queues zu erstellen und wollte aus einer dieser Action Engines eine Klasse machen um sie als Basisklasse zu verwenden...) und ich bin zu dem Schluss gekommen - und ich vermute mal da bist du auch drüber gestolpert, sonst hättest du die Daten, die du übertragen willst, nicht als String geflattet - Queues verhindern die Type Propagation von Objekten. Mein Fazit war mal wieder: "ach verdammte Scheisse, wär ja gar nich so schlecht dieses OOP, wenn man's denn nur vernünftig einsetzen könnte *heul*". d.h. so lange man nicht über das dynamic dispatch Terminal den Datentyp der Queue beim "Dequeue Element" festlegen kann, bleibt die Umsetzung in LVOOP einfach nur ein Muster ohne Wert, eine Spielerei, nicht tauglich für "in Production Projekte" ...

so far,
CB

LVOOP ist, meiner Meinung nach, eine Erweiterung von Clusters. Ich glaube du hast viel zu viel AQ-Belaber bei LAVA gelesen um den Eindruck zu bekommen, dass LVOOP ein Super-Wooper-Wunder ist. Betrachte es einfacher, und du wirst sehen dass es eine bessere Sache als Cluster ist. Zumindest ist der Icon einer Klassenkonstante nicht so gross, wie eine Riesencluserkonstante. Was die Ableitungen angeht, da bin ich noch nicht so weit, dass ich es fachlich diskutieren kann.

Aber ganz sicher - vielen Dank für die Teilnahme am Gespräch. Ich warte auf weitere Kommentare



P.S. habe aus dem Topic eine Umfrage gemacht, denn ich überhaupt an irgendeiner Veröffentlichung irgenwelcher Libraries zweifle. Ich werde lieber direkte Fragen im Forum stellen, falls ich welche hab.

Würd mich freuen, wennst die Bibliothek nochmal hochladen würdest.
Möchte/Muss mich mal näher mit Queues befassen, und wozu das Rad neu erfinden.

Oh ja, sorry. Ich habe die neu hochgeladen, aber vergessen den Download-Link anzupassen. Kannst jetzt holen.

Gruß

Anzeige

Hallo zusammen,
eg ich habe mir die library auch heruntergeladen und probeweise getestet und finde sie auf den ersten Blick
sehr interessant.
Ich werde mich bestimmt damit näher beschäftigen wenn ich Zeit und Ruhe (genau hier ist mein Problem) habe.
Es ist in meinen Augen eine tolle Sache wenn solche Ideen hier eingestellt und diskutiert werden.
Nun kann ich noch nicht viel beitragen, jedoch habe ich das "Get Notifier Status" Modul vermisst,
da ich diese Funktion auch häufig nutze.

Gruß
Ralf

PS: OSD/FGV benutze ich ebenfalls immer häufiger und kann deine Argumentation nicht nachvollziehen (Provokation?)

' schrieb:Anders (abgesehen von Variant o.ä.) kann ich mir keine Library solcher Art, die projektunabhängig verwendet werden kann, vorstellen.

genau DAS is der Punkt. Nach meinem Empfinden MÜSSTE das mit LVOOP gehen. Wenn ich die entsprechenden Dokumentationen zu dem Thema richtig verstanden haben ist es ja genau dafür gemacht, dass man sich Bibliotheken erstellt, die man in vielen Projekten verwendet und lange pflegt, aber GENAU IN diesem Punkt versagt das Konzept immer wieder, und das find ich nicht nur schade, das regt mich sogar auf, weil ich mich irgendwie verarscht fühle.

' schrieb:Die Werte der Member Variables befinden sich im Klassen-Wire, warum sollte man die noch extra irgendwo abspeichern. Oder besser gesagt, ich verstehe nicht so ganz was gemeint ist.

nach meinem Verständnis speichert und verwaltet ein Objekt seine Members. Das ist bei LVOOP nicht der Fall, allerdings kann man es relativ schnell "nachrüsten" in dem man eine Feedback Node ins Blockdiagramm legt ...

Aber zurück zum Konzept: Meine Meinung nach läßt sich sowas nur sinnvoll und zukunftssicher implementieren, wenn LVOOP "vernünftig" funktioniert: man schreibt sich eine Basis-Klasse, die sich um den ganze Queue Kram und die Typ-Sicherheit kümmert, mit dem Datentyp "leerer Cluster". Die eigentlichen Tasks (ich nenn das "Module") sind dann immer Kinder von der Basis-Klasse und erben alle Methoden und überschreiben den "leeren Cluster" mit ihrem eigenen Datentyp. Aber leider stoß ich immer wieder an die Grenzen von Objekten und Queues *grrrr*. Mein Haupt-Kritikpunkt ist: man muss - bisher - die Type-Propagation aufgeben und damit verliert man einen der großen Vorteile von LV, aber gerade das sollte man doch verhindern können, wenn man dynamic Dispatching verwendet, aber renn ich immer vor ne Wand ...

' schrieb:Hallo zusammen,
eg ich habe mir die library auch heruntergeladen und probeweise getestet und finde sie auf den ersten Blick
sehr interessant.
Ich werde mich bestimmt damit näher beschäftigen wenn ich Zeit und Ruhe (genau hier ist mein Problem) habe.
Es ist in meinen Augen eine tolle Sache wenn solche Ideen hier eingestellt und diskutiert werden.
Nun kann ich noch nicht viel beitragen, jedoch habe ich das "Get Notifier Status" Modul vermisst,
da ich diese Funktion auch häufig nutze.

Gruß
Ralf

PS: OSD/FGV benutze ich ebenfalls immer häufiger und kann deine Argumentation nicht nachvollziehen (Provokation?)

Get Notifier Status habe ich noch nicht gebraucht, ich kann mir aber gut vorstellen, dass es jemand braucht. Es ist nicht zu schwer es nachzurüsten. Ich kann es machen, falls du es nicht machen kannst. Es sind nur ein paar Mausklicks. Bei dieser Librrary geht es eigentlich viel mehr ums Koncept der Verwendung.

Provokation? Was? Ich weiß gar nicht warum und wozu.

' schrieb:genau DAS is der Punkt. Nach meinem Empfinden MÜSSTE das mit LVOOP gehen. Wenn ich die entsprechenden Dokumentationen zu dem Thema richtig verstanden haben ist es ja genau dafür gemacht, dass man sich Bibliotheken erstellt, die man in vielen Projekten verwendet und lange pflegt, aber GENAU IN diesem Punkt versagt das Konzept immer wieder, und das find ich nicht nur schade, das regt mich sogar auf, weil ich mich irgendwie verarscht fühle.
nach meinem Verständnis speichert und verwaltet ein Objekt seine Members. Das ist bei LVOOP nicht der Fall, allerdings kann man es relativ schnell "nachrüsten" in dem man eine Feedback Node ins Blockdiagramm legt ...

Dieses versagt in jeder anderen Programmiersprache. Man muss den Datentyp entweder global und projektabhängig definieren, oder halt datentypunabhängige Übertragungsmethode verwenden und Datentyp casten.

' schrieb:Aber zurück zum Konzept: Meine Meinung nach läßt sich sowas nur sinnvoll und zukunftssicher implementieren, wenn LVOOP "vernünftig" funktioniert: man schreibt sich eine Basis-Klasse, die sich um den ganze Queue Kram und die Typ-Sicherheit kümmert, mit dem Datentyp "leerer Cluster". Die eigentlichen Tasks (ich nenn das "Module") sind dann immer Kinder von der Basis-Klasse und erben alle Methoden und überschreiben den "leeren Cluster" mit ihrem eigenen Datentyp. Aber leider stoß ich immer wieder an die Grenzen von Objekten und Queues *grrrr*. Mein Haupt-Kritikpunkt ist: man muss - bisher - die Type-Propagation aufgeben und damit verliert man einen der großen Vorteile von LV, aber gerade das sollte man doch verhindern können, wenn man dynamic Dispatching verwendet, aber renn ich immer vor ne Wand ...

Ich glaube du verwechselst etwas mit dem Polymorphysmus. Du kannst mit LVOOP ruhig solche überladende Methoden machen und es ist ähnlich oder fast genauso wie polymorphe VIs im nativen LV.

Ich denke du stellst viel zu viele Anforderungen an LVOOP. Es ist wirklich fast nur ein Datencluster mit einigen Verbesserungen.