Взаимодействие OLua и Lua под Виндой

А как тестер писали ? он на Луа у Вас ?

По теме, можно на С++ он запускает Луа скрипты спокойно, только нужно будет источники данных делать думаю и скрипты квика переписывать под тестер. По сути программа - тестер. (первое что в голову пришло)

Проще всего написать программу думаю которая будет реализовывать все функции Lua - к примеру берет файл с котировкой банально в цикле прогоняет и дергает события Lua (приход нового тика, совершение сделки и прочие...)

Мне кажется, нет я уверен, что хороший все сторонний тестер под Lua не написать (как мин без подключения доп. библиотек на языках типа плюсов и С#) Однако лучше да и правильнее скрипты Lua тестить а не в скриптах тестить) Тот же МТ5 для тестов намного лучше будет (там практически все что нужно есть для оптимизации и прочего...) Но в квике больше возможностей для торговли (опционы к примеру...) Если же использовать MT5 для тестов, то нужно будет переписывать робота на Mql и затем там тестить, оптимизировав уже можно торговать (останется только график нужного Вам инструмента в Мт загрузить там есть такая возможность.).

Вот пара полезных ссылок, возможно Вам пригодятся:
https://habrahabr.ru/post/197300/
https://habrahabr.ru/post/237503/
Все с хабра - сайт и сам по себе популярный так что надеюсь меня не сочтут за рекламщика))

Вот еще кстати одна ссылка в догонку так сказать, тут очень даже хорошо создатель сайта расписал метод стыковки С++ и квика. Сам сейчас сижу с жтой стыковкой воюю. https://quikluacsharp.ru/qlua-c-cpp-csharp/vyzov-funktsij-qlua-lua-iz-dll-napisannoj-na-c-c/

МТ5 довольно гибок, да и для тестов история как раз и нужна, ну что там у Вас я не знаю, так что это вам решать уж...

в теории одинаково. На практике нет. В терминале скрипты исполняются медленнее.

Функции qlua здесь не при чем.

достаточно написать цикл и заменить время выполнения из под ос и из под терминала.

я как-то задавался этим вопросом раньше и сейчас еще раз проверил - в терминале медленнее.

вопрос "почему" не по нужному адресу -не я приклеивал луа к квику.

Готов взять обратно свои слова о слабом быстродействии Qlua. Оптимизацией алгоритма добился того что скрипт обрабатывающий таблицу в 6500 строк делает 15 проходов в секунду. Опять же оговорюсь что это для моего железа - для кого то возможно это так себе показатель. Замедление происходит в основном при взаимодействии виртуальной машины с квиком - при опросе графиков, таблиц, выводах в таблицы, сохранении в файл .... Если эти операции ограничить до необходимой целесообразности то все работает довольно шустро.

О нюансах.
У меня старенький ПК, 2 ядра, Windows XP. Запускаю 3 скрипта-близнеца, имена только разные. Подобрал параметры цикла, чтоб каждый в одиночку на не очень нагруженном ПК исполнялся около 1 минуты.

function main()
 message("00c-start",2)
 s=0
 for i=0, 580000000 do
   s = s+1
 end
 message("00c-finish",2)
 return
end

Я запускаю их поочередно, жду завершения, а затем запускаю все три одномоментно.
При последовательном запуске каждый выполняется около минуты. Вполне ожидаемо.

При параллельном выполнении какому-то ядру достался один скрипт, какому-то - два. Наблюдаю загрузку процессора в Диспетчере задач Windows -  оба ядра по 100%.
Через минуту завершается один скрипт - тоже ожидаемо. Была одна из вспомогательных гипотез, что те скрипты, что попали в одну воронку, завершатся еще через минуту.
По факту они завершились через полминуты. Эти полминуты оба ядра были загружены полностью. При полной загрузке ядер вся работа трех скриптов была выполнена за полторы минуты.

Приятный нюанс - произошло перераспределение нагрузки, освободившееся ядро стало выполнять один из двух отставших скриптов. Два ядра, у каждого свой скрипт, осталось выполнить половину работы каждого, по полминуты.
Итого: 3 минуты/2(ядра) = 1.5 минуты.
Прямо задачка про трубы.

Неприятный нюанс. Все знают что основной поток QUIK, в котором последовательно обрабатываются асинхронные выходы, в частности - индикаторы, нельзя грузить долгой работой, можно многое притормозить и даже заблокировать.
Три (даже два) "тяжелых" скрипта в соседних потоках при двух ядрах тоже справляются с такой задачей - на полторы минуты  практически блокируют работу QUIK. Вероятная причина - приоритеты всех потоков одинаковы.

Разработчикам - оцените, пожалуйста, целесообразность и возможность повышения приоритета основного потока QUIK.
Не думаю, что только у меня ресурсоемкие алгоритмы.
Оптимизировал алгоритмы, "тяжесть" унес в DLL(C++), использовал особенности внутреннего устройства LUA, межпоточную сихронизацию, уйду (ушел) из индикаторов, перейду на многоядерный ПК, но мину за спиной оставлять не хочется, как не хочется и жить на костылях.  


   

Наверно это возможно через общие объекты, доступные как в квике, так и в  Луа самой винды, например простой текстовый файл. Он может создаваться и там и там и соответственно читаться тоже. Или через файл HTML, с ним наверно даже проще его не нужно открывать и закрывать как текстовый, на одной стороне он просто дописывается, а на другой стороне он читается, единственная проблема, что если прочитать раньше времени, то данные будут не обновленные, а старые. Это на мой взгляд самая простая передача данных, а по времени она не затратная, скорость записи на диск на современных ПК составляет 133 Мбайт/сек. Можно наверно через MySQl, но мне кажется это все будет работать медленнее, хотя как вариант можно и через какую либо локальную БД.