Diskussion zum Artikel "Paketbasierter Ansatz mit KnitPkg für die MQL5-Entwicklung"

[MetaQuotes]

Neuer Artikel Paketbasierter Ansatz mit KnitPkg für die MQL5-Entwicklung :

Um maximale Zuverlässigkeit und Produktivität bei mit MQL erstellten MetaTrader-Produkten zu gewährleisten, empfiehlt dieser Artikel einen Entwicklungsansatz, der auf wiederverwendbaren Paketen basiert, die von KnitPkg, einem Projektmanager für MQL5/MQL4, verwaltet werden. Ein Paket kann als Baustein für andere Pakete oder als Grundlage für fertige Artefakte dienen, die direkt auf der MetaTrader-Plattform ausgeführt werden, wie beispielsweise EAs, Indikatoren und vieles mehr.

Ein Trader-Entwickler muss häufig mehrere MQL5-Projekte (EAs, Indikatoren, Tools) pflegen, die denselben mathematischen und Hilfscode verwenden. Heutzutage erfolgt diese Wiederverwendung meist noch auf die altbewährte Art: durch das Kopieren von Ordnern zwischen Projekten und das manuelle Bearbeiten von #include-Anweisungen. Mit jedem Update kommt es zu Versionsabweichungen – hier gibt es einen neuen Fix, dort eine alte Datei –, und ein Build in einer „reinen“ MetaTrader-Umgebung hängt davon ab, was in diesem Terminal bereits manuell gepatcht wurde. Was wirklich benötigt wird, ist eine Möglichkeit, eine Komponente einmalig in Git zu implementieren, sie gemäß SemVer zu versionieren und in verschiedene Projekte einzubinden, sodass Installation und Builds auf jedem Rechner reproduzierbar sind: Die Abhängigkeiten sind fest vorgegeben, Artefakte werden automatisch generiert (als Include-Baum oder als flacher, generierter Header), und das Verschieben von Code zwischen Projekten erfordert keine Bearbeitung von Pfaden oder das Kopieren und Einfügen von Dateien mehr.

Dieser Artikel stellt einen solchen Workflow für MQL4/MQL5 vor, der auf KnitPkg-Paketen basiert: Jede Funktion wird als wiederverwendbare, versionierte Komponente definiert und anschließend projektübergreifend über ein Manifest statt per Copy-Paste genutzt. Im Laufe dieses Artikels werden wir sehen, wie dieser Ansatz die Zusammenstellung, die Wiederverwendung zwischen EAs und Indikatoren sowie die Veröffentlichung robuster macht, indem verstreute Code-Schnipsel in strukturierte, abhängigkeitsverwaltete Bausteine umgewandelt werden.

Autor: Douglas Nascimento Rechia

[Stanislav Korotky]

Klingt interessant, aber ich habe da einige Bedenken.

Wenn jemand ein Git-Repository mit einem MQL5-Projekt, -Programm oder -Paket klont, das eigentlich von KnitPkg verwaltet werden soll, erhält er höchstwahrscheinlich nicht kompilierbare Quelldateien, da automatisch generierte Dateien (wie z. B. _flat) im Repository fehlen. Wäre es nicht möglich, alle erforderlichen automatisch generierten Quelldateien in Git zu committen, damit die Version unabhängig davon, wie sie bezogen wird, kompilierbar ist?

Ich bin mir nicht sicher, wie praktisch es wäre, Änderungen an den Abhängigkeiten vorzunehmen, da wir den automatisch generierten Code tatsächlich kompilieren und debuggen und nicht einfach zum entsprechenden Ursprung „springen“ können – habe ich da etwas übersehen? Beispielsweise muss man das „bar“-Paket ändern, während man am Indikator (oder am Expert Advisor) arbeitet. Wie würdet ihr das machen?

Schließlich habe ich Bedenken hinsichtlich einiger Aspekte bei der Umsetzung der Beispiele (wahrscheinlich, weil es sich nur um Beispiele handelt), wie zum Beispiel „new/delete“ bei jedem Tick/Bar. Außerdem machst du zum Beispiel Folgendes:

int OnCalculate(const int32_t rates_total,
                const int32_t prev_calculated,
                const int32_t begin,
                const double &price[])
{
   ...
   douglasrechia::TimeSeriesArray<double> priceArray(price, prev_calculated - InpSMAPeriod - 1, rates_total-1, false);
   ...
   for (int shift=shiftStart; shift >= 0 && !IsStopped(); shift--)
   {
      SMABuffer[shift] = douglasrechia::SMA(priceArray, InpSMAPeriod, shift);
   }
   ...
}

Was ist der Zweck, das Preis-Array an den Konstruktor von `priceArray` zu übergeben (wo eine Kopie eines Teils des Arrays erstellt wird) und dann `priceArray` an SMA zu übergeben – warum übergibt man nicht das ursprüngliche Preis-Array per Referenz an SMA, ohne es zu kopieren?

[Douglas Nascimento Rechia]

Stanislav Korotky Git-Repository mit einem MQL5-Projekt, -Programm oder -Paket klont, das eigentlich von KnitPkg verwaltet werden soll, erhält er oder sie höchstwahrscheinlich nicht kompilierbare Quelldateien, da automatisch generierte Dateien (wie z. B. _flat) im Repository fehlen. Wäre es nicht möglich, alle erforderlichen automatisch generierten Quelldateien in Git zu committen, damit die Version unabhängig davon, wie sie bezogen wird, kompilierbar ist?

Ich bin mir nicht sicher, wie praktisch es wäre, Änderungen an den Abhängigkeiten vorzunehmen, da wir den automatisch generierten Code tatsächlich kompilieren und debuggen und nicht einfach zum entsprechenden Ursprung „springen“ können – habe ich da etwas übersehen? Beispielsweise muss man das „bar“-Paket ändern, während man am Indikator (oder am Expert Advisor) arbeitet. Wie würdet ihr das machen?

Schließlich habe ich Bedenken hinsichtlich einiger Aspekte bei der Umsetzung der Beispiele (wahrscheinlich, weil es sich nur um Beispiele handelt), wie zum Beispiel „new/delete“ bei jedem Tick/Bar. Außerdem macht man zum Beispiel Folgendes:

Was ist der Zweck, das Preis-Array an den Konstruktor von `priceArray` zu übergeben (wo eine Kopie eines Teils des Arrays erstellt wird) und dann `priceArray` an SMA zu übergeben – warum übergibt man nicht das ursprüngliche Preis-Array per Referenz an SMA, ohne es zu kopieren?

Hallo Stanislav,

vielen Dank, dass du dir die Zeit genommen hast, den Artikel zu lesen und diese Punkte anzusprechen.

Zum Committen von generiertem Code: Die Idee hinter KnitPkg ist, dass automatisch generierte Artefakte (Flat-Header, aufgelöste Includes usw.) nicht im Git-Repository liegen sollten, da man sonst effektiv Code über Repos hinweg dupliziert und riskiert, dass dieser nicht mehr synchron ist. Wenn eine Funktionalität in einem Paket/Repository implementiert ist, ist dies die einzige verlässliche Quelle; Nutzer deklarieren eine Abhängigkeit (unter Verwendung von SemVer-Bereichen) und lassen kp install bzw. kp autocomplete die abgeleiteten Dateien lokal neu generieren. Auf diese Weise kann Ihr Projekt, wenn eine Abhängigkeit innerhalb des zulässigen SemVer-Bereichs aktualisiert wird, die neue Version nahtlos übernehmen, anstatt mit veraltetem, generiertem Code „festzustecken“, der in das eigene Repo committet wurde. Ein konkretes Beispiel für die Aktualisierung von Abhängigkeitsversionen finden Sie hier in der Dokumentation.

Zu Ihrer Sorge, „wie bequem es sein wird, Änderungen an Abhängigkeiten vorzunehmen“: Das war ein Aspekt, über den ich bei der Entwicklung des Tools nachgedacht habe. KnitPkg unterstützt die Verwendung lokaler Abhängigkeiten, sodass Sie ein Projekt direkt auf ein Paket in einem lokalen Verzeichnis verweisen, dieses Paket ändern und die Änderungen während der Entwicklung in einem echten Verbraucherprojekt testen können. Der Arbeitsablauf wird im Abschnitt „Lokale Abhängigkeiten“ der KnitPkg-Dokumentation ausführlicher beschrieben: https://docs.knitpkg.dev/user-guide/local-dependencies/

Was „price“ → „TimeSeriesArray“ → „SMA“ betrifft: Dabei geht es nicht darum, die effizienteste Mikrooptimierung zu zeigen, sondern eine standardisierte Schnittstelle zu veranschaulichen. SMA erhält ein `ITimeSeries` (nicht direkt ein `TimeSeriesArray`) und achtet lediglich darauf, dass „der aktuellste Wert am Index 0 steht, der nächste am Index 1 usw.“. TimeSeriesArray ist lediglich eine im Beispiel verwendete Implementierung, die zufällig einen Ausschnitt von „price“ kopiert. Andere könnten eine andere ITimeSeries-Implementierung entwickeln, die eine cachefreundlichere Struktur nutzt. Der springende Punkt ist, die Berechnung vom konkreten Speicherlayout zu entkoppeln; wie intelligent oder effizient die ITimeSeries-Implementierung ist, wird zu einer Frage des Designs und der Kreativität.

Ich freue mich immer über Diskussionen zu diesen Designentscheidungen, und Feedback zu KnitPkg – sei es zum Workflow oder zum Beispielcode – ist sehr willkommen. Zögern Sie also nicht, diese Ideen zu hinterfragen oder zu erweitern.