В изменениях исходников не увидел, чтобы именно с буфером обмена что-то делалось.
staticbool GetSettings2( string &Str, constint Attempts = 10 )
{
bool Res = false;
if (MTTESTER::LockWaiting())
{
Res = MTTESTER::GetSettings(Str, Attempts);
MTTESTER::Lock(false);
}
return(Res);
}
Разве если запустить оптимизацию, она не займет все доступные ядра сразу? Не врубаюсь, каким образом одиночный тест "отъел" одно ядро у оптимизации (на самом деле даже 2 агента оптимизируюшего МТ помечены как disabled).
Вроде, сразу написал. Оптимизирующий Терминал имеет два агента disabled. Каждый enabled-агент берет по ядру.
Вроде, сразу написал. Оптимизирующий Терминал имеет два агента disabled. Каждый enabled-агент берет по ядру.
Там явным образом ничего не сказано о ручном отключении (или другой настройке агентов) - и этот нюанс по-прежнему обойден. Именно из-за этого у меня и возник вопрос, насколько параллельная работа автоматизирована. Я по наивности из темы и описания блога подумал, что сделана полная автоматизация.
LockWaiting видел - именно её сформулировал как блокирующую работу с файлами. Понятно, что лок можно использовать для обращения к ресурсам, в т.ч. буферу обмена. Терминологическая путаница.
PS. Наверно, чего-то недопонимаю, но если требовался только исключительный доступ к буферу обмена, то такой же лок (цикл с периодическими проверками) логичнее делать на функциях самого клипбоарда (OpenClipboard, который уже упоминается в исходниках).
Там явным образом ничего не сказано о ручном отключении (или другой настройке агентов) - и этот нюанс по-прежнему обойден. Именно из-за этого у меня и возник вопрос, насколько параллельная работа автоматизирована. Я по наивности из темы и описания блога подумал, что сделана полная автоматизация.
Полная автоматизация со стороны MQ. На любых машинах, даже если работаю с одним терминалом, выключаю 1-2 агента, чтобы можно было работать на машине без лагов.
Терминал1 (Оптимизация): Агенты 3000-3017 - enabled, 30018-3019 - disabled. Так на всех терминалах, потому что все остальные терминалы - полная копия первого. Никаких настроек руками не делается.
Терминал2 - под одиночные проходы.
Два сценария.
Сначала запустил оптимизацию на Терминал1, включились 3000-3017. Затем одиночные на Терминал2 - работает 3018.
Сначала запустил одиночные на Терминал2, включился 3000. Затем оптимизацию на Терминал1 - работают 3001-3018.
Все автоматизировано со стороны MQ. Вам проверить это - вопрос минуты. Диалог сильно больше времени отнял.
PS. Наверно, чего-то недопонимаю, но если требовался только исключительный доступ к буферу обмена, то такой же лок (цикл с периодическими проверками) логичнее делать на функциях самого клипбоарда (OpenClipboard, который уже упоминается в исходниках).
Полная автоматизация со стороны MQ. На любых машинах, даже если работаю с одним терминалом, выключаю 1-2 агента, чтобы можно было работать на машине без лагов.
Терминал1 (Оптимизация): Агенты 3000-3017 - enabled, 30018-3019 - disabled. Так на всех терминалах, потому что все остальные терминалы - полная копия первого. Никаких настроек руками не делается.
Терминал2 - под одиночные проходы.
Два сценария.
Сначала запустил оптимизацию на Терминал1, включились 3000-3017. Затем одиночные на Терминал2 - работает 3018.
Сначала запустил одиночные на Терминал2, включился 3000. Затем оптимизацию на Терминал1 - работают 3001-3018.
Все автоматизировано со стороны MQ. Вам проверить это - вопрос минуты. Диалог сильно больше времени отнял.
Если б данное описание было в блоге, вопроса бы не возникло. Опять таки, данное описание означает ручную настройку агентов, имхо, а не автоматизацию. Проверять нечего.
Если б данное описание было в блоге, вопроса бы не возникло. Опять таки, данное описание означает ручную настройку агентов, имхо, а не автоматизацию. Проверять нечего.
Нет ручной настройки. Можете ничего не делать с агентами, поведение не изменится. Сумели удивить.
Нет ручной настройки. Можете ничего не делать с агентами, поведение не изменится. Сумели удивить.
Был заявлен "обход возможных конфликтов при работе с параллельными Тестерами." Эта фраза вводит в заблуждение в контексте ядер, потому что по факту делается ручная конфигурация агентов. Вы почему-то упорно связываете выделение портов с ядрами. Порты не могут пересекаться, а ядра (процессы) - могут - это зависит как раз от предварительных настроек. Полагаю, что у нас просто разные понятия в автоматическом разрешении конфликтов между параллельными процессами.
Был заявлен "обход возможных конфликтов при работе с параллельными Тестерами." Эта фраза вводит в заблуждение в контексте ядер, потому что по факту делается ручная конфигурация агентов.
Вы неправильно интерпретировали слово "обход". Проблема возникает, когда одновременно несколько терминалов работают с clipboard. Раньше задания одного терминала могли случайно попадать в другой терминал. Сейчас это исключено.
GetLastTstCacheFileName теперь возвращает имя tst-файла БЕЗ пути.
GetLastTstCache имеет возможность забирать tst-файл, который соответствует только что завершенному проходу. Это исключает взятие ошибочных tst-файлов.
ClickStart корректно работает даже при мгновенной завершенной реакции Тестера при нажатии на кнопку Start. В таких случаях ClickStart опознает, что кнопка Start все же была успешно нажата.
Иногда нужно на работающих терминалах выполнить одно и то же. Автоматизация этого действа ниже на примере.
Требуется собрать данные на каждом терминале, запустив там подобный скрипт RunMe.mq5.
#include <fxsaber\MultiTester\MTTester.mqh> // https://www.mql5.com/ru/code/26132voidOnStart()
{
if (MTTESTER::LockWaiting()) // Если надо последовательно выполнять действия.
{
constint handle = ::FileOpen(__FILE__, FILE_WRITE | FILE_READ | FILE_ANSI | FILE_COMMON);
// Записали в файл нужные данные.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); // Снимаем блокировку параллельного выполнения.
}
}
Вот так это делается.
// Запуск скрипта на всех терминалах.#include <fxsaber\MultiTester\MTTester.mqh> // https://www.mql5.com/ru/code/26132voidOnStart()
{
HANDLE Handles[];
// Бежим по всем терминаламfor (int i = MTTESTER::GetTerminalHandles(Handles) - 1; i >= 0; i--)
MTTESTER::RunEX5("Scripts\\RunMe.ex5", Handles[i], true); // и запускаем на каждом соответствующий скрипт.
}
В итоге одним нажатием собрали данные со всех терминалов. Благодаря MTTESTER::RunEX5 - запускает EX5 на требуемом терминале (portable).
В изменениях исходников не увидел, чтобы именно с буфером обмена что-то делалось.
Разве если запустить оптимизацию, она не займет все доступные ядра сразу? Не врубаюсь, каким образом одиночный тест "отъел" одно ядро у оптимизации (на самом деле даже 2 агента оптимизируюшего МТ помечены как disabled).
Вроде, сразу написал. Оптимизирующий Терминал имеет два агента disabled. Каждый enabled-агент берет по ядру.
Вроде, сразу написал. Оптимизирующий Терминал имеет два агента disabled. Каждый enabled-агент берет по ядру.
Там явным образом ничего не сказано о ручном отключении (или другой настройке агентов) - и этот нюанс по-прежнему обойден. Именно из-за этого у меня и возник вопрос, насколько параллельная работа автоматизирована. Я по наивности из темы и описания блога подумал, что сделана полная автоматизация.
LockWaiting видел - именно её сформулировал как блокирующую работу с файлами. Понятно, что лок можно использовать для обращения к ресурсам, в т.ч. буферу обмена. Терминологическая путаница.
PS. Наверно, чего-то недопонимаю, но если требовался только исключительный доступ к буферу обмена, то такой же лок (цикл с периодическими проверками) логичнее делать на функциях самого клипбоарда (OpenClipboard, который уже упоминается в исходниках).
Там явным образом ничего не сказано о ручном отключении (или другой настройке агентов) - и этот нюанс по-прежнему обойден. Именно из-за этого у меня и возник вопрос, насколько параллельная работа автоматизирована. Я по наивности из темы и описания блога подумал, что сделана полная автоматизация.
Полная автоматизация со стороны MQ. На любых машинах, даже если работаю с одним терминалом, выключаю 1-2 агента, чтобы можно было работать на машине без лагов.
Терминал1 (Оптимизация): Агенты 3000-3017 - enabled, 30018-3019 - disabled. Так на всех терминалах, потому что все остальные терминалы - полная копия первого. Никаких настроек руками не делается.
Терминал2 - под одиночные проходы.
Два сценария.
PS. Наверно, чего-то недопонимаю, но если требовался только исключительный доступ к буферу обмена, то такой же лок (цикл с периодическими проверками) логичнее делать на функциях самого клипбоарда (OpenClipboard, который уже упоминается в исходниках).
Не вижу логичности в таком решении.
Полная автоматизация со стороны MQ. На любых машинах, даже если работаю с одним терминалом, выключаю 1-2 агента, чтобы можно было работать на машине без лагов.
Терминал1 (Оптимизация): Агенты 3000-3017 - enabled, 30018-3019 - disabled. Так на всех терминалах, потому что все остальные терминалы - полная копия первого. Никаких настроек руками не делается.
Терминал2 - под одиночные проходы.
Два сценария.
Если б данное описание было в блоге, вопроса бы не возникло. Опять таки, данное описание означает ручную настройку агентов, имхо, а не автоматизацию. Проверять нечего.
Если б данное описание было в блоге, вопроса бы не возникло. Опять таки, данное описание означает ручную настройку агентов, имхо, а не автоматизацию. Проверять нечего.
Нет ручной настройки. Можете ничего не делать с агентами, поведение не изменится. Сумели удивить.
Нет ручной настройки. Можете ничего не делать с агентами, поведение не изменится. Сумели удивить.
Был заявлен "обход возможных конфликтов при работе с параллельными Тестерами." Эта фраза вводит в заблуждение в контексте ядер, потому что по факту делается ручная конфигурация агентов. Вы почему-то упорно связываете выделение портов с ядрами. Порты не могут пересекаться, а ядра (процессы) - могут - это зависит как раз от предварительных настроек. Полагаю, что у нас просто разные понятия в автоматическом разрешении конфликтов между параллельными процессами.
Был заявлен "обход возможных конфликтов при работе с параллельными Тестерами." Эта фраза вводит в заблуждение в контексте ядер, потому что по факту делается ручная конфигурация агентов.
Вы неправильно интерпретировали слово "обход". Проблема возникает, когда одновременно несколько терминалов работают с clipboard. Раньше задания одного терминала могли случайно попадать в другой терминал. Сейчас это исключено.
Доступны следующие изменения в MTTester.mqh.
Иногда нужно на работающих терминалах выполнить одно и то же. Автоматизация этого действа ниже на примере.
Требуется собрать данные на каждом терминале, запустив там подобный скрипт RunMe.mq5.
Вот так это делается.
В итоге одним нажатием собрали данные со всех терминалов. Благодаря MTTESTER::RunEX5 - запускает EX5 на требуемом терминале (portable).