Bibliotheken: MultiTester - Seite 30

 
Stanislav Korotky #:

Ich habe in den Quelltextänderungen nicht gesehen, dass etwas mit der Zwischenablage gemacht wurde.

  static bool GetSettings2( string &Str, const int Attempts = 10 )
  {
    bool Res = false;

    if (MTTESTER::LockWaiting())
    {
      Res = MTTESTER::GetSettings(Str, Attempts);

      MTTESTER::Lock(false);
    }

    return(Res);
  }

Wenn Sie die Optimierung ausführen, werden dann nicht alle verfügbaren Kerne auf einmal verwendet? Ich verstehe nicht, wie ein einziger Test einen Kern von der Optimierung "weggenommen" hat (in der Tat sind sogar 2 Agenten der optimierenden MT als deaktiviert markiert).

Ich glaube, ich habe es gleich geschrieben. Optimising Terminal hat zwei deaktivierte Agenten. Jeder aktivierte Agent nimmt einen Kern.

 
fxsaber #:

Ich glaube, ich habe es gleich geschrieben. Optimising Terminal hat zwei deaktivierte Agenten. Jeder aktivierte Agent nimmt einen Kernel.

Es wird ausdrücklich nichts über die manuelle Deaktivierung (oder andere Konfiguration von Agenten) gesagt - und diese Nuance wird immer noch umgangen. Das ist genau der Grund, warum ich eine Frage dazu habe, wie viel parallele Arbeit automatisiert ist. Aufgrund des Themas und der Blog-Beschreibung bin ich naiverweise davon ausgegangen, dass eine vollständige Automatisierung stattgefunden hat.

LockWaiting wurde gesehen - es ist das, was ich als Sperren der Dateiarbeit formuliert habe. Es ist klar, dass Lock für den Zugriff auf Ressourcen, einschließlich der Zwischenablage, verwendet werden kann. Terminologische Verwirrung.

PS. Vielleicht verstehe ich etwas falsch, aber wenn nur exklusiver Zugriff auf die Zwischenablage erforderlich war, dann ist die gleiche Sperre (eine Schleife mit periodischen Überprüfungen) logischer, auf die Funktionen der Zwischenablage selbst (OpenClipboard, die bereits im Quellcode erwähnt wird) zu tun.

 
Stanislav Korotky #:

Es wird ausdrücklich nichts über die manuelle Deaktivierung (oder sonstige Konfiguration von Agenten) gesagt - und diese Nuance wird immer noch umgangen. Das ist genau der Grund, warum ich eine Frage dazu habe, wie viel parallele Arbeit automatisiert ist. Aufgrund des Themas und der Blog-Beschreibung habe ich naiverweise gedacht, dass eine vollständige Automatisierung erfolgt ist.

Vollständige Automatisierung auf der MQ-Seite. Auf allen Maschinen, auch wenn ich mit einem Terminal arbeite, schalte ich 1-2 Agenten ab, damit ich ohne Verzögerungen auf der Maschine arbeiten kann.


Terminal1 (Optimierung): Agenten 3000-3017 - aktiviert, 30018-3019 - deaktiviert. Also auf allen Terminals, denn alle anderen Terminals sind eine vollständige Kopie des ersten Terminals. Es werden keine manuellen Einstellungen vorgenommen.

Terminal2 - für einzelne Durchgänge.


Zwei Szenarien.

  1. Zuerst habe ich die Optimierung auf Terminal1 laufen lassen, 3000-3017 waren eingeschaltet. Dann Einzeldurchläufe auf Terminal2 - 3018 funktioniert.
  2. Zuerst lief die Einzeloptimierung auf Terminal2, 3000 wurde eingeschaltet. Dann Optimierung auf Terminal1 - 3001-3018 laufen.
Auf der MQ-Seite ist alles automatisiert. Es ist eine Sache von einer Minute, um es zu überprüfen. Der Dialog hat viel mehr Zeit in Anspruch genommen.
 
Stanislav Korotky #:

PS. Wahrscheinlich verstehe ich etwas falsch, aber wenn nur ausnahmsweise ein Zugriff auf die Zwischenablage erforderlich wäre, dann wäre es logischer, die gleiche Sperre (Schleife mit periodischen Überprüfungen) für die Funktionen der Zwischenablage selbst (OpenClipboard, die bereits in den Quellen erwähnt wird) zu verwenden.

Ich sehe die Logik einer solchen Lösung nicht.

 
fxsaber #:

Vollständige Automatisierung auf der MQ-Seite. Auf jeder Maschine, auch wenn ich mit einem Terminal arbeite, schalte ich 1-2 Agenten aus, damit ich ohne Verzögerungen an der Maschine arbeiten kann.


Terminal1 (Optimierung): Agenten 3000-3017 - aktiviert, 30018-3019 - deaktiviert. Also auf allen Terminals, denn alle anderen Terminals sind eine vollständige Kopie des ersten Terminals. Es werden keine manuellen Einstellungen vorgenommen.

Terminal2 - für einzelne Durchgänge.


Zwei Szenarien.

  1. Zuerst habe ich die Optimierung auf Terminal1 durchgeführt, 3000-3017 sind eingeschaltet. Dann habe ich die Einzeloptimierung auf Terminal2 laufen lassen - 3018 läuft.
  2. Zuerst habe ich die Einzeloptimierung auf Terminal2 laufen lassen, 3000 läuft. Dann Optimierung auf Terminal1 - 3001-3018 funktioniert.
Auf der MQ-Seite ist alles automatisiert. Es ist eine Sache von einer Minute, um es zu überprüfen. Der Dialog hat viel mehr Zeit in Anspruch genommen.

Wenn diese Beschreibung im Blog stünde, gäbe es keine Frage. Nochmals, diese Beschreibung bedeutet manuelle Konfiguration von Agenten, imho, nicht Automatisierung. Es gibt nichts zu überprüfen.

 
Stanislav Korotky #:

Wenn diese Beschreibung im Blog stünde, gäbe es keine Frage. Nochmals, diese Beschreibung bedeutet manuelle Konfiguration von Agenten, imho, nicht Automatisierung. Es gibt nichts zu überprüfen.

Es gibt keine manuelle Konfiguration. Sie können nichts mit den Agenten machen, das Verhalten wird sich nicht ändern. Erstaunlich.

 
fxsaber #:

Es gibt keine manuelle Konfiguration. Sie können nichts an den Agenten ändern, das Verhalten wird sich nicht ändern. Überraschend.

Es wurde angegeben, "um mögliche Konflikte bei der Arbeit mit parallelen Testern zu vermeiden". Diese Formulierung ist im Zusammenhang mit Cores irreführend, denn was tatsächlich geschieht, ist die manuelle Konfiguration von Agenten. Aus irgendeinem Grund beharren Sie darauf, die Zuordnung von Ports mit Kernen in Verbindung zu bringen. Ports können sich nicht überschneiden, aber Kernel (Prozesse) schon - es hängt nur von der Vorkonfiguration ab. Ich nehme an, wir haben einfach unterschiedliche Vorstellungen von der automatischen Konfliktlösung zwischen parallelen Prozessen.

 
Stanislav Korotky #:

Es wurde angegeben, "um mögliche Konflikte bei der Arbeit mit parallelen Testern zu vermeiden". Diese Formulierung ist im Zusammenhang mit Kerneln irreführend, da die Konfiguration der Agenten tatsächlich manuell erfolgt.

Sie haben das Wort "Umgehung" falsch interpretiert. Das Problem tritt auf, wenn mehrere Terminals gleichzeitig mit der Zwischenablage arbeiten. Früher konnte es passieren, dass Aufträge von einem Terminal versehentlich in ein anderes Terminal gelangen. Jetzt ist dies ausgeschlossen.

 

Die folgenden Änderungen sind in MTTester.mqh verfügbar.

  • GetLastTstCacheFileName gibt jetzt den Namen der tst-Datei OHNE den Pfad zurück.
  • GetLastTstCache hat die Fähigkeit, die tst-Datei zu holen, die dem gerade abgeschlossenen Durchlauf entspricht. Dadurch wird verhindert, dass fehlerhafte tst-Dateien abgerufen werden.
  • ClickStart arbeitet auch dann korrekt, wenn der Tester sofort reagiert, wenn die Start-Taste gedrückt wird. In solchen Fällen erkennt ClickStart, dass die Starttaste dennoch erfolgreich gedrückt wurde.
 

Manchmal muss man das Gleiche auf Arbeitsterminals tun. Die Automatisierung dieser Aktion wird unten im Beispiel gezeigt.


Es ist erforderlich, Daten auf jedem Terminal zu sammeln, indem ein ähnliches Skript RunMe.mq5 ausgeführt wird.

#include <fxsaber\MultiTester\MTTester.mqh> // https://www.mql5.com/de/code/26132
  
void OnStart()
{
  if (MTTESTER::LockWaiting()) // Wenn Sie die Aktionen nacheinander ausführen wollen.
  {
    const int handle = ::FileOpen(__FILE__, FILE_WRITE | FILE_READ | FILE_ANSI | FILE_COMMON);

    // Schreiben Sie die erforderlichen Daten in die Datei.
    if (handle != INVALID_HANDLE)      
    {
      FileSeek(handle, 0, SEEK_END);
      FileWriteString(handle, "Account = " + (string)AccountInfoInteger(ACCOUNT_LOGIN) + ", " +
                              "Balance = " + (string)AccountInfoDouble(ACCOUNT_BALANCE) + "\n");
      
      FileClose(handle);
    }

    MTTESTER::Lock(false); // Geben Sie die Sperre für die parallele Ausführung frei.
  }
}


So wird es gemacht.

// Führen Sie das Skript auf allen Terminals aus.

#include <fxsaber\MultiTester\MTTester.mqh> // https://www.mql5.com/de/code/26132
  
void OnStart()
{
  HANDLE Handles[]; 
  
  // Alle Terminals durchlaufen
  for (int i = MTTESTER::GetTerminalHandles(Handles) - 1; i >= 0; i--)
    MTTESTER::RunEX5("Scripts\\RunMe.ex5", Handles[i], true); // und führen Sie das entsprechende Skript für jedes aus.
}


Als Ergebnis haben wir Daten von allen Terminals mit einem Klick gesammelt. Dank MTTESTER::RunEX5 - läuft EX5 auf dem gewünschten Terminal (portabel).