Сергей (Все сообщения пользователя)

Добрый день!

Обновился до QUIK версии 8.7.0.6 и появилась следующая проблема:
В таблицах, создаваемых Lua скриптом, теперь при клике правой кнопкой в каждой ячейке появляется контекстное меню с настройками сортировки.
В итоге коллбэк, который в скрипте навешивается на событие QTABLE_RBUTTONDBLCLK, не работает. У меня этот эвент активно используется, и я не могу его ничем заменить.
Как разрешить эту ситуацию ?

Все таки хотелось бы подробнее узнать насчет фикса "В таблице «Доска опционов» неверно отображалась своя позиция.".
У ваших разработчиков ведь есть трекинг система и есть тикет по этому  поводу. Хотелось бы узнать детали.

Спасибо что попробовали у себя. У вас тоже все нормально. Пока причина почему у меня не работает, непонятна. Я специально останавливал все другие скрипты во время теста. Кстати аналогичные действия с таблицей "futures_client_holding" на новой версии у меня отрабатывают корректно.

Egor Zaytsev написал:
Кроме того, что я писал в этой теме, я больше никаких запросов не отправлял.

Никакие другие программы тоже не могли повлиять (я про изменение интервала таймера), так как у меня запущены одни и те же программы, когда я тестирую с версией 19 и с версией 27.
Может сам QUIK что-то стал делать с интервалом в последних версиях?

Сделал скрины









Все остальные скрипты во время тесты не были запущены, так что повлиять не могли.


Если вообще убрать вызов getItem из моего первого сообщения, естественно все быстро работает и не тормозит.

Нет, это не тот же эффект.
Хотелось бы чтобы на первом мониторе было содержимое одной вкладки, а на втором - содержимое другой вкладки. Чтобы сразу могу обе видеть.
А если растянуть, то получится просто большая одна вкладка.

Если я предоставлю тот же самый скрин, когда отключен терминал, этого будет достаточно?
Просто у меня пока нет возможности, потому что приходится каждый раз обновлять версию и откатывать. Я могу дать такой скрин позже, если это действительно нужно. Но это 100% будет тоже самое, потому что я вчера воспроизводил такие тормоза именно в оффлайне.
Какая еще дополнительная информация нужна?

Что значит отключенном, какая разница отключен или нет? Я думаю это совершенно не зависит от того, подключен ли сервер или нет.

Разве вы не видите, сколько у меня времени занимает getItem и не видите, сколько у меня строк в таблице и у вас? Как я не могу менять код. Это совершенно необходимо чуть поменять код, чтобы было значимое количество итераций и у меня чтобы не занимала час работа скрипта. Я думаю вы в состоянии понять смысл моих минимальных правок в тестовом скрипте.

Я думаю из моих скринов совершенно все ясно, что апгрейд QUIK'а влияет на производительность getItem и действительно как-то связан со стандартным виндовым периодом таймера, так как у меня среднее время итерации 15,6 мс пополам.
Почему у вас такое отношения к багам от пользователей? Почему вы все время пытаетесь убедить, что программа ваша идельная , а пользователи тупые?

Разве вы не можете просто передать мою информацию (а по моему из работы тестового скрипта ее достаточно) разработчикам?

Если ко мне нет доверия, вот мои скрины и код.

Кроме того, я никаких таймеров не взводил. Если это QUIK выполняет данный цикл через таймеры, то это значит что он неправильно работает.

Как я вынесу getItem из цикла? Мне нужно найти нужный инструмент из таблицы. Для этого нужно перебирать каждый элемент. Если это не QUIK, почему тогда на 19 версии все работает?

Хотелось бы не просто вынос вкладки за пределы основного окна. Хотелось бы следующего: чтобы при соответствующей настройке (предположим два монитора), запускалось сразу два окна QUIK'а, одно на первом мониторе, второе на втором. И пользователь может хоть как переносить окна и вкладки между двумя окнами на каждом мониторе так, как будто это один монитор.

Здравствуйте!

Планируется ли ввести поддержку нескольких мониторов в QUIK. Хотелось бы одновременно видеть содержимое одной вкладки на первом мониторе, и второй вкладки - на втором мониторе.

Ситуация не воспроизвелась, однако вы пофиксили проблему в версии 7.19 с описанием "В таблице «Доска опционов» неверно отображалась своя позиция.". Хотелось бы объяснений, почему на мой запрос адекватного ответа не было, но проблема существовала.

Скрипт на Lua,
Обычный обход item'ов таблицы "depo_limits".

Цикл работает чрезвычайно медленно, что приводит к тормозам моего скрипта. Всего кол-во строк в таблице (items_num) чуть более ста.
Трассировка говорит, что вызов getItem занимает 0,015 с. Можно посчитать, что каждый такой цикл занимает 1,5с.


Проявляется на новых версиях QUIK'а. Последняя версия QUIK где работает нормально - 7.19.3.1.

В связи с этим больше не обновляю QUIK.


Данный код просто лишь загружает в мою таблицу баланс по инструменту. Кол-во отслеживаемых инструментов более сотни, можете посчитать, сколько у меня занимает инциализация таблицы (1,5с x 100 = 150сек это в лучшем случае).

SearchItems работает аналогично для этой таблицы. Остальные таблицы кажется отрабатывают корректно, но проверял не все.

Смотрите документацию Lua

https://www.lua.org/manual/5.3/manual.html#3.3.3

Там сказано:

Мой небольшой опыт.
В своем роботе, когда фильтровал нужные ответы в onTransReply,
мне приходилось фильтровать также по полю time, типа такого
Кроме того, при генерации trans_id, у меня в потоке всех заявок иногда случались одинаковые числа при использовании hh:mm:ss +  math.random(1, 999), что меня порядком удивило и приводило к багам, поэтому пришлось проверять дополнительно:



Есть конечно множество других ньюансов, но о всех и не вспомнишь. Вообще весь механизм OnTransReply -> OnTrade -> OnOrder в QUIK'е (или на бирже) баганутый. Довольно редко, но transReply иногда просто не приходит. Приходится придумывать всякие воркараунды.

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

Продолжил работать над задачей описанной в начале темы. Поместил методы записи в базу в отдельную dll (таким образом почти полностью переписал функционал с lua на c++), к сожалению проблема осталось той же: QUIK падает через некоторое время работы. Зато теперь падает с дампом. Уважаемая тех. поддержка, куда мне нужно направить файл дампа, чтобы кто-нибудь мог посмотреть возможную причину? Так как pdb у меня нет, то символы из дампа я загрузить не могу, вижу только ошибку "Access violation reading location xxxx".

Да, именно так.
Чтобы вопроизвести баг, необязательно открывать вторую такую же таблицу. Нужно просто перевыбрать инструмент в той же самой таблице - и значение в поле позиция обнулится.

Вот скрин. Только по нему   видно, что показывает ерунду. Реальная позиция PUT = 8.

Здравствуйте,


Начиная с версии 7.16, поле Позиция в доске опционов иногда показывает неправильное значение. Какой-то конкретной закономерности не заметил, но что-то точно не так. В версиях 7.14 и ранее это поле всегда показывало корректное значение.

Кажется, причина ясна.Дело оказалось вовсе не в БД, а в одновременном доступе к мапу из разных ниток.
В потоке main() делалось чтение из базы и загрузка данных из нее в глобальный мап типа { "SR" = {...}, "GZ" = {...}, "RI" = {} } (то есть таблица, где ключом является не индекс, а строки).
В функции обратного вызова делалось чтение из этого глобального мапа с использованием pairs(). Пока вторая нитка перебирала элементы, первая как раз в этот же момент изменила мап, и все упало.
Я конечно знаю про потокобезопасные функции table.sinsert и т.д., но они только для нумерованных таблиц.
Так что придется использовать что-то типа эмуляции критической секции, как описано здесь https://forum.quik.ru/forum10/topic3272/ или поменять структуру данных. Сделать все в один поток не получится, потому что скрипт сложный и большой и он не только занимается работой с базой.

Не вполне пойму, в чем противоречие. У меня в скрипте довольно тонкая прослойка к упомянутым третьесторонним библиотекам - открываю соединение, получаю данные из QUIK'а о нужных инструментах, делаю вызов INSERT, как в примере https://keplerproject.github.io/luasql/examples.html. У LuaSQLite3 другой API и обращение к другой dll - и падение то же самое повторяется. Если бы в моем скрипте была бы ошибка, то не работало бы вообще.




Не очень знаком с технологиями "Protocol Buffers", "ZeroMQ", которые тут указаны. Я так понял смысл в том, что мой скрипт будет запущен обычным интерпретатором Lua и будет RPC-клиентом. Для получения данных из QUIK он будет делать RPC вызовы на скрипт (RPC-сервер) запущенный в это время в QUIK'е. Я правильно понимаю? В итоге получается, что "вынести в отдельный процесс" означает по сути "переписать всю программу" на этих неизвестных мне технологиях. Думаю легче сделать по другому: написать dll, которая сама будет делать inset'ы в базу, а lua-скрипт из QUIK'а просто будет давать dll'ке нужные данные.

Есть проблема, с которой борюсь довольно давно, но к сожалению, так ее и не удалось решить, и похоже все дело именно в связке QUIK-QLua-Lua.
Я написал скрипт на Lua, который периодически записывает данные о параметрах опционов (волатильность и т.д.) в БД, чтобы в дальнейшем использовать данную информацию для сложных запросов. Для записи в БД пробовал пользоваться несколькими сторонними библиотеками: LuaSQL (https://keplerproject.github.io/luasql/) и LuaSQLite3 (http://lua.sqlite.org/index.cgi/index). При этом в случае LuaSQL пробовал реализацию для sqlite и mysql.
Сами библиотеки прикрутить к QUIK'у удалось, хотя это непросто. Но итоговый результат к сожалению печальный: скрипт работает определенное время, делает записи в БД, как надо, но потом QUIK просто падает (без дампа, без всего). Если записи в БД делать два раза в секунду, то падает через несколько минут. Если писать раз в минуту (как изначально мной предполагалось), то падает через полчаса, а может через пару часов. Мне нужна стабильная работа в течение всего дня. За одну итерацию пишу около сотен строк в БД, что полная ерунда для современных мощностей. Смотрел на использование ЦП QUIK'ом во время работы скрипта - все нормально. Пробовал запись как из потока main, так и из функций обратного вызова - результат один и тот же.
То, что один и тот же результат воспроизводится для различных библиотек и различных СУБД, говорит о том, что дело не в них, а в QUIK'е или QLua. Если записывать все нужные данные просто в файл csv, а не в БД, то все стабильно работает. По опыту могу сказать, что падение может быть вызвано ошибкой при одновременном доступе к одному участку памяти в QUIK'е или запил памяти, но так как у меня нет исходного кода ни qlua.dll, ни quik.exe, то я не могу ничего сказать и сделать. Неужели моя задача никак не решается с использованием QUIK? Хотелось бы получить ответ от разработчиков. Я могу дать код скрипта, если нужно. Пробовал на версиях QUIK 7.14 и 7.16.

Здравствуйте!
Хотелось бы узнать точно, какая версия Lua используется в QLua. Я имею ввиду 5.1.4 или 5.1.5. Это важно при использовании сторонних библиотек в скриптах, так как постоянно проблемы с совместмостью.

Если это возможно, я бы хотел данное улучшение зарегистрировать.

Многократные вызовы SearchItems для поиска нужного инструмента в таблице лимитов по бумагам приводят к утечкам памяти, которые не может устранить сборщик мусора Lua.

Следующий метод возвращает баланс по заданному инструменту и коду клиента:
Вызывается этот метод часто (несколько раз в секунду) и приводит к серьезным утечкам памяти (объем используемой памяти проверяю через функцию collectgarbage("count")). За день работы набирается больше 2 Гб.

Если я буду искать нужный инструмент просто прямым перебором всех строк в таблице, то все нормально.

Могут ли разработчики взглянуть на данную проблему? Версия QUIK 7.5.0.72, Lua версии 5.1.

Мне нужны данные расширенной таблицы котировок EXT_ORDERBOOK из ftp://ftp.micex.ru/pub/ClientsAPI/ASTS/Bridge_Interfaces/Equities/Equities23­_Broker_Russian.htm
Можно ли ее получить из скрипта Lua?

Как известно, информацию о котировках в стакане можно получить с помощью функции getQuoteLevel2.
Но она возвращает только цены и количество заявок.
В интерфейсе же QUIK, если в таблицу котировок добавить столбец "Доходность", доступна также информация о доходности облигации, вычисленной для каждой котировки в стакане. Как мне программно ее получить?
По сути нужна функция getYield(price), возвращающая для конкретной облигации доходность по цене заявки.