Librerías: MultiTester - página 30

Nuevo comentario
 
Stanislav Korotky #:

No he visto en los cambios de la fuente que se haya hecho algo con el portapapeles.

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

Si ejecutas la optimización, ¿no tomará todos los núcleos disponibles a la vez? No entiendo cómo una sola prueba "quitó" un núcleo de la optimización (de hecho, incluso 2 agentes de optimización MT están marcados como desactivados).

Creo que lo he escrito bien. Terminal de optimización tiene dos agentes deshabilitados. Cada agente habilitado se lleva un núcleo.

 
fxsaber #:

Creo que lo escribí enseguida. Optimizando Terminal tiene dos agentes deshabilitados. Cada agente habilitado toma un núcleo.

Explícitamente no dice nada sobre la deshabilitación manual (u otra configuración de los agentes) - y este matiz se sigue obviando. Esta es precisamente la razón por la que tengo una pregunta sobre cuánto trabajo paralelo está automatizado. Ingenuamente pensé por el tema y la descripción del blog que se había hecho una automatización completa.

LockWaiting se ha visto - es el que formulé como bloqueo de trabajo de archivos. Está claro que lock puede usarse para acceder a recursos, incluyendo el portapapeles. Confusión terminológica.

PS. Tal vez he entendido algo mal, pero si sólo se requiere acceso exclusivo al portapapeles, entonces el mismo bloqueo (un bucle con comprobaciones periódicas) es más lógico hacer en las funciones del propio portapapeles (OpenClipboard, que ya se menciona en el código fuente).

 
Stanislav Korotky #:

No dice explícitamente nada sobre desactivar manualmente (o configurar de otro modo los agentes) - y ese matiz se sigue obviando. Esta es la razón por la que tengo una pregunta sobre cuánto trabajo paralelo está automatizado. Ingenuamente pensé por el tema y la descripción del blog que se había hecho una automatización completa.

Automatización completa en el lado MQ. En cualquier máquina, aunque trabaje con un terminal, desconecto 1-2 agentes para poder trabajar en la máquina sin lags.


Terminal1 (Optimización): Agentes 3000-3017 - activados, 30018-3019 - desactivados. Así en todos los terminales, porque todos los demás terminales son una copia completa del primero. No se realizan ajustes manuales.

Terminal2 - para pases individuales.


Dos escenarios.

  1. Primero ejecuté la optimización en Terminal1, 3000-3017 estaban activados. Luego pasadas individuales en Terminal2 - 3018 funciona.
  2. Primero ejecuté pases simples en Terminal2, 3000 se encendió. Después optimización en Terminal1 - 3001-3018 funcionando.
Todo está automatizado en el lado MQ. Comprobarlo es cuestión de un minuto. El diálogo tomó mucho más tiempo.
 
Stanislav Korotky #:

PS. Probablemente entiendo algo mal, pero si sólo se requiriera un acceso excepcional al portapapeles, entonces sería más lógico hacer el mismo bloqueo (bucle con comprobaciones periódicas) en las funciones del propio portapapeles (OpenClipboard, que ya se menciona en las fuentes).

No veo la lógica en tal solución.

 
fxsaber #:

Automatización completa en el lado MQ. En cualquier máquina, aunque trabaje con un terminal, desconecto 1-2 agentes para poder trabajar en la máquina sin lags.


Terminal1 (Optimización): Agentes 3000-3017 - activados, 30018-3019 - desactivados. Así en todos los terminales, porque todos los demás terminales son una copia completa del primero. No se realiza ninguna configuración manual.

Terminal2 - para pases individuales.


Dos escenarios.

  1. Primero ejecuté la optimización en Terminal1, 3000-3017 están encendidos. Luego ejecuté la optimización individual en Terminal2 - 3018 está en marcha.
  2. Primero ejecuté la optimización en Terminal2, 3000 funciona. A continuación, la optimización en Terminal1 - 3001-3018 funciona.
Todo está automatizado en el lado MQ. Comprobarlo es cuestión de un minuto. El diálogo llevó mucho más tiempo.

Si esta descripción estuviera en el blog, no habría ninguna duda. De nuevo, esta descripción significa configuración manual de los agentes, imho, no automatización. No hay nada que comprobar.

 
Stanislav Korotky #:

Si esta descripción estuviera en el blog, no habría ninguna duda. De nuevo, esta descripción significa configuración manual de agentes, imho, no automatización. No hay nada que comprobar.

No hay configuración manual. No se puede hacer nada con los agentes, el comportamiento no cambiará. Sorprendente.

 
fxsaber #:

No hay configuración manual. No se puede hacer nada a los agentes, el comportamiento no cambiará. Sorprendente.

Se dijo "para evitar posibles conflictos al trabajar con Testers en paralelo". Esta frase es engañosa en el contexto de los núcleos, porque lo que realmente se está haciendo es una configuración manual de los agentes. Por alguna razón persistes en asociar la asignación de puertos con los núcleos. Los puertos no pueden solaparse, pero los núcleos (procesos) sí - sólo depende de la preconfiguración. Supongo que tenemos nociones diferentes de la resolución automática de conflictos entre procesos paralelos.

 
Stanislav Korotky #:

Se dijo "para evitar posibles conflictos al trabajar con Testers en paralelo". Esta frase es engañosa en el contexto de los núcleos, porque de hecho se realiza una configuración manual de los agentes.

Ha malinterpretado la palabra "eludir". El problema se produce cuando varios terminales trabajan con el portapapeles al mismo tiempo. Antes, los trabajos de un terminal podían llegar accidentalmente a otro terminal. Ahora está excluido.

 

Los siguientes cambios están disponibles en MTTester.mqh.

  • GetLastTstCacheFileName ahora devuelve el nombre del archivo tst SIN la ruta.
  • GetLastTstCache tiene la capacidad de obtener el archivo tst que corresponde a la pasada que se acaba de completar. Esto evita que se obtengan archivos tst erróneos.
  • ClickStart funciona correctamente incluso cuando el Comprobador reacciona instantáneamente al pulsar el botón Start. En estos casos, ClickStart reconoce que, a pesar de todo, el botón de inicio se ha pulsado correctamente.
 

A veces es necesario hacer lo mismo en terminales de trabajo. La automatización de esta acción se muestra a continuación en el ejemplo.


Es necesario recoger datos en cada terminal ejecutando un script similar RunMe.mq5.

#include <fxsaber\MultiTester\MTTester.mqh> // https://www.mql5.com/es/code/26132
  
void OnStart()
{
  if (MTTESTER::LockWaiting()) // Si desea realizar acciones secuencialmente.
  {
    const int handle = ::FileOpen(__FILE__, FILE_WRITE | FILE_READ | FILE_ANSI | FILE_COMMON);

    // Escribe los datos requeridos en el fichero.
    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); // Liberar el bloqueo de ejecución paralela.
  }
}


Así es como se hace.

// Ejecuta el script en todos los terminales.

#include <fxsaber\MultiTester\MTTester.mqh> // https://www.mql5.com/es/code/26132
  
void OnStart()
{
  HANDLE Handles[]; 
  
  // Recorre todos los terminales
  for (int i = MTTESTER::GetTerminalHandles(Handles) - 1; i >= 0; i--)
    MTTESTER::RunEX5("Scripts\\RunMe.ex5", Handles[i], true); // y ejecuta el script apropiado en cada uno.
}


Como resultado, hemos recogido datos de todos los terminales con un solo clic. Gracias a MTTESTER::RunEX5 - ejecuta EX5 en el terminal requerido (portable).

1...232425262728293031323334353637...53
Nuevo comentario