Librerie: MultiTester - pagina 30

Nuovo commento
 
Stanislav Korotky #:

Non ho visto nelle modifiche ai sorgenti che è stato fatto qualcosa con gli appunti.

  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);
  }

Se si esegue l'ottimizzazione, non si utilizzano tutti i core disponibili in una volta sola? Non capisco come un singolo test abbia "tolto" un core all'ottimizzazione (infatti anche 2 agenti di MT ottimizzanti sono segnati come disabilitati).

Credo di averlo scritto subito. Il terminale ottimizzante ha due agenti disabilitati. Ogni agente abilitato prende un core.

 
fxsaber #:

Credo di averlo scritto subito. Optimising Terminal ha due agenti disabilitati. Ogni agente abilitato prende un kernel.

Non dice esplicitamente nulla sulla disabilitazione manuale (o su altre configurazioni degli agenti) - e questa sfumatura viene ancora aggirata. Questo è il motivo per cui ho una domanda su quanto lavoro parallelo sia automatizzato. Dalla descrizione dell'argomento e del blog ho pensato ingenuamente che fosse stata realizzata un'automazione completa.

LockWaiting è stato visto - è quello che ho formulato come blocco del lavoro sui file. È chiaro che lock può essere usato per accedere alle risorse, compresa la clipboard. Confusione terminologica.

PS. Forse ho frainteso qualcosa, ma se fosse richiesto solo l'accesso esclusivo alla clipboard, allora lo stesso blocco (un ciclo con controlli periodici) è più logico da fare sulle funzioni della clipboard stessa (OpenClipboard, che è già menzionato nel codice sorgente).

 
Stanislav Korotky #:

Non dice esplicitamente nulla sulla disattivazione manuale (o sulla configurazione degli agenti) e questa sfumatura viene ancora aggirata. Questo è il motivo per cui ho una domanda su quanto lavoro parallelo sia automatizzato. Dalla descrizione dell'argomento e del blog ho pensato ingenuamente che fosse stata realizzata un'automazione completa.

Automazione completa sul lato MQ. Su qualsiasi macchina, anche se lavoro con un solo terminale, spengo 1-2 agenti in modo da poter lavorare sulla macchina senza ritardi.


Terminale1 (ottimizzazione): Agenti 3000-3017 - abilitati, 30018-3019 - disabilitati. Così su tutti i terminali, perché tutti gli altri terminali sono una copia completa del primo. Non vengono effettuate impostazioni manuali.

Terminale2 - per passaggi singoli.


Due scenari.

  1. Prima ho eseguito l'ottimizzazione sul Terminale1, 3000-3017 erano attivati. Poi ho eseguito i passaggi singoli sul Terminal2 - 3018 funziona.
  2. Prima ho eseguito i singoli sul Terminal2, si è acceso il 3000. Poi ho eseguito l'ottimizzazione sul Terminal1, con 3001-3018 attivi.
Tutto è automatizzato sul lato MQ. È questione di un minuto per verificarlo. Il dialogo ha richiesto molto più tempo.
 
Stanislav Korotky #:

PS. Probabilmente ho frainteso qualcosa, ma se fosse richiesto solo un accesso eccezionale agli appunti, allora sarebbe più logico fare lo stesso blocco (ciclo con controlli periodici) sulle funzioni degli appunti stessi (OpenClipboard, che è già menzionato nei sorgenti).

Non vedo la logica di questa soluzione.

 
fxsaber #:

Automazione completa sul lato MQ. Su qualsiasi macchina, anche se lavoro con un solo terminale, spengo 1-2 agenti in modo da poter lavorare sulla macchina senza ritardi.


Terminale1 (ottimizzazione): Agenti 3000-3017 - abilitati, 30018-3019 - disabilitati. Così su tutti i terminali, perché tutti gli altri terminali sono una copia completa del primo. Non viene effettuata alcuna impostazione manuale.

Terminale2 - per passaggi singoli.


Due scenari.

  1. Prima ho eseguito l'ottimizzazione sul Terminal1, 3000-3017 sono attivi. Poi ho eseguito i singoli sul Terminal2: 3018 è in funzione.
  2. Prima ho eseguito l'ottimizzazione su Terminal2, con 3000 in funzione. Poi ho eseguito l'ottimizzazione sul Terminal1 - 3001-3018 funziona.
Tutto è automatizzato sul lato MQ. È una questione di un minuto per verificarlo. Il dialogo ha richiesto molto più tempo.

Se questa descrizione fosse stata riportata nel blog, non ci sarebbero state domande. Ancora una volta, questa descrizione indica la configurazione manuale degli agenti, imho, non l'automazione. Non c'è nulla da controllare.

 
Stanislav Korotky #:

Se questa descrizione fosse presente nel blog, non ci sarebbero dubbi. Ancora una volta, questa descrizione indica la configurazione manuale degli agenti, imho, non l'automazione. Non c'è nulla da controllare.

Non c'è alcuna configurazione manuale. Non si può fare nulla con gli agenti, il comportamento non cambierà. Sorprendente.

 
fxsaber #:

Non esiste una configurazione manuale. Non si può fare nulla agli agenti, il comportamento non cambierà. Sorprendente.

È stato dichiarato "per evitare possibili conflitti quando si lavora con tester paralleli". Questa frase è fuorviante nel contesto dei core, perché ciò che viene effettivamente fatto è la configurazione manuale degli agenti. Per qualche motivo ci si ostina ad associare l'allocazione delle porte ai core. Le porte non possono sovrapporsi, ma i kernel (processi) possono farlo - dipende solo dalla preconfigurazione. Suppongo che abbiamo nozioni diverse sulla risoluzione automatica dei conflitti tra processi paralleli.

 
Stanislav Korotky #:

È stato dichiarato "per aggirare i possibili conflitti quando si lavora con tester paralleli". Questa frase è fuorviante nel contesto dei kernel, perché in realtà la configurazione manuale degli agenti viene effettuata.

Avete interpretato male la parola "elusione". Il problema si verifica quando più terminali lavorano contemporaneamente con la clipboard. Una volta era possibile che i lavori di un terminale finissero accidentalmente in un altro terminale. Ora è escluso.

 

Le seguenti modifiche sono disponibili in MTTester.mqh.

  • GetLastTstCacheFileName ora restituisce il nome del file tst SENZA il percorso.
  • GetLastTstCache è in grado di recuperare il file tst corrispondente al passaggio appena completato. Questo evita che vengano recuperati file tst errati.
  • ClickStart funziona correttamente anche quando il Tester reagisce istantaneamente alla pressione del pulsante di avvio. In questi casi, ClickStart riconosce che il pulsante di avvio è stato comunque premuto con successo.
 

A volte è necessario fare la stessa cosa sui terminali di lavoro. L'automazione di questa azione è illustrata nell'esempio seguente.


È necessario raccogliere i dati su ogni terminale eseguendo uno script simile RunMe.mq5.

#include <fxsaber\MultiTester\MTTester.mqh> // https://www.mql5.com/it/code/26132
  
void OnStart()
{
  if (MTTESTER::LockWaiting()) // Se si desidera eseguire le azioni in modo sequenziale.
  {
    const int handle = ::FileOpen(__FILE__, FILE_WRITE | FILE_READ | FILE_ANSI | FILE_COMMON);

    // Scrivere i dati richiesti nel file.
    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); // Rilascia il blocco dell'esecuzione parallela.
  }
}


Questo è il modo in cui viene eseguito.

// Eseguire lo script su tutti i terminali.

#include <fxsaber\MultiTester\MTTester.mqh> // https://www.mql5.com/it/code/26132
  
void OnStart()
{
  HANDLE Handles[]; 
  
  // Eseguire tutti i terminali
  for (int i = MTTESTER::GetTerminalHandles(Handles) - 1; i >= 0; i--)
    MTTESTER::RunEX5("Scripts\\RunMe.ex5", Handles[i], true); // ed eseguire lo script appropriato su ciascuno di essi.
}


Il risultato è che abbiamo raccolto i dati da tutti i terminali con un solo clic. Grazie a MTTESTER::RunEX5 - esegue EX5 sul terminale richiesto (portatile).

1...232425262728293031323334353637...51
Nuovo commento