А теперь хотелось бы увидеть ответ от разработчиков терминала, что они по этому поводу думают.
1) Считается ли проблемой ACCESS_VIOLATION, упомянутый выше?
2) Как пользователям корректно сделать цикл по всем имеющимся данным внутри DataSource, чтобы не нарваться в процессе итерирования на изменение данных из-за поступившей новой рыночной информации или очистки объекта DataSource?
Я во всех своих скриптах при доступе к datasource-объектам внутри main применяю примерно такие фрагменты кода, чтобы во время доступа к datasource его содержимое внезапно не изменилось:
Код
local function getRawCandles(ds, maxSize)
local size = 0
local T, O, H, L, C, V = {}, {}, {}, {}, {}, {}
if ds and ds:Size() > 0 then
table.ssort({ 0, 1 }, function(a, b)
local dsSize = ds:Size()
if maxSize == nil then
maxSize = dsSize
end
local count, offset
if dsSize <= maxSize then
count, offset = dsSize, 0
else
count, offset = maxSize, dsSize - maxSize
end
for i = 1, count do
local j = i + offset
T[i] = ds:T(j)
O[i] = ds:O(j)
H[i] = ds:H(j)
L[i] = ds:L(j)
C[i] = ds:C(j)
V[i] = ds:V(j)
end
size = count
return true
end)
end
return { size = size, T = T, O = O, H = H, L = L, C = C, V = V, }
end
Недостатком является блокировка потока коллбэков, что плохо в случае большого количества скриптов и одновременных запросов данных из datasource.
Какой бы из вариантов не использовался, если запуск скрипта ведёт к падению терминала -- это хороший способ указать его разработчикам, где ошибка. Неоптимальные скрипты в этом смысле хороши, что напрягают систему и выявляют ошибки гораздо быстрее. Терминал же всегда должен без ACCESS_VIOLATION работать при синтаксически корректном коде скрипта.
Исправленные недоработки 1. В таблице «Текущие торги» не работал функционал «быстрых фильтров» по параметру «Размер лота». 2. В некоторых случаях при загрузке QPile-портфеля Рабочее место QUIK аварийно завершало работу. 3. Ошибка закрытия QLUA-портфеля при синтаксических ошибках в скрипте. 4. Аварийное завершение работы Рабочего места QUIK при переносе пользовательских индикаторов между диаграммами с помощью функции drag-anddrop. 5. Удаление QLUA-портфеля из таблицы «Доступные скрипты» приводило к некорректному сдвигу остальных скриптов. 6. Некорректный расчет объема заявки на закрытие фьючерсной позиции при использовании схемы кредитования «МД+». 7. Некорректная обработка в QLUA сбоев, возникавших при вызове функций callback из пользовательских библиотек. 8. Не выставлялись заявки на досрочную экспирацию опциона.
В крайнем случае, можно сделать справочник классов как таблицу, где ключ -- код инструмента, значение -- код класса. Будет такой справочник, скорее всего, один, заполнить его несложно и потом везде применять.
МосБиржа перенесла релиз на 06 июля 2020 года. Наверное, что-то дорабатывают, а у разработчиков терминала и его пользователей ещё один месяц на устранение багов появился. Но расслабляться не надо.
_sk_ написал: У меня 8.5.2 упал с дампом. Послал его разработчикам для анализа. Не всё пока хорошо.
у вас была возможность потестировать срабатываение колбэков на заявки? визуально если вручную заявки ставить, ответы довольно медленно приходят ну и вообще как-то кажется что иной раз терминал замирает, "чаще обычного"
На СПБирже на малых объёмах нормально колбэки отрабатывают. Подтормаживания, кажется, есть, но уверенности на 100% нет. В боевую эксплуатацию, когда много заявок по нескольким счетам боюсь пока ставить.
Anton, Вы меня поражаете своей компетентностью в различных областях в хорошем смысле этого слова! Спасибо за разнообразную помощь и доброжелательное отношение!
Вопрос к пользователям. Встречался ли кто-нибудь с падением терминала версии 8.5.2 без дампа? Если да, отпишитесь здесь с подробностями (что делали, сколько дней до этого проработал терминал и т.п.).
Подтверждаю, есть такая неприятность. Удаляем скрипт из середины списка, получаем некорректный сдвиг отображения оставшихся скриптов вверх. Если окно скриптов закрыть и открыть заново, список, вроде бы, актуальным становится. Чинить всё равно надо.
Тестирую терминал 8.5.2.11 с начала торгов 07.05.2020. Пока работает штатно. Кажется, что памяти под каждый отдельный скрипт стало больше выделяться, чем раньше, но программа справляется. Судя по логам, расхождений в арифметике не появилось. Выставление и снятие заявок пока не проверял.
Отдельное спасибо разработчикам за столбец, показывающий выделенную память под каждый lua-скрипт.
Исправленные недоработки 1. Исправлена некорректная конфигурация lua53.dll. 2. Исправлена ошибка загрузки lua53.dll в сторонние приложения. 3. Не работала функция lua_call. 4. Исправлена синхронизационная ошибка, которая приводила к аварийному завершению работы программы при выполнении lua-скрипта. 5. В некоторых случаях пропадал пункт «<Не указан>» в быстрых фильтрах таблицы OMS-заявок. 6. Неверное количество знаков в поле «Дисконт» диалога «Ввод адресной заявки РЕПО с ЦК маклером». 7. В некоторых случаях в Таблице котировок опция «Лучшие котировки видны всегда» работала некорректно. 8. В некоторых случаях при использовании функции QLUA SetUpdateCallback увеличивалось потребление оперативной памяти. 9. В некоторых случаях при наличии позиции только в иностранной валюте в форме ввода заявок не рассчитывалось максимально возможное количество. 10. В некоторых случаях была недоступна принудительная отправка «Margin Call».
Просьба 3. Поскольку новый релиз терминала для отладки не выходит уже 2 недели, вероятность получения рабочего QLua в обозримом будущем всё меньше, пусть ARQA попросит МосБиржу перенести релиз на срочном рынке с 8 июня 2020 года на более поздний срок.
В терминале в таблице текущий параметров по инструменту CLK0 вижу дату экспирации 30.04.2020, но до погашения, якобы, осталось 20 дней. Это на бирже в одном месте поправили, а в другом — забыли, или терминал глючит?
Очень хорошо, что 17 апреля 2020 года вы выпустили версию терминала 8.5.1, а мы смогли её протестировать. Довольно быстро пользователи выявили несколько проблем, которые надо исправить.
У меня есть один вопрос и две просьбы.
Вопрос. Когда нам стоит ожидать следующую версию для тестирования?
Возможно, что ещё какие-то недоделки всплывут. Чем регулярнее релизы, тем оперативнее будет обратная связь. Мы все хотим иметь надёжный софт к сроку релиза на МосБирже.
Просьба 1 в том, чтобы файлы выкладываемого обновления позволяли обновиться сразу с версии 8.4, а не накатывать сначала 8.5.1 (нерабочий релиз с точки зрения QLua), а потом ещё какие-то файлы. Так нам всем будет удобнее.
Просьба 2 в том, чтобы от разработчиков появилось уведомление в этой ветке, чтобы как можно больше пользователей сразу включились в работу по тестированию.
Уведомление о необходимости обновления торговых терминалов в связи с изменениями на срочном рынке Московской биржи, Список проблем при работе устаревших версий QUIK после обновления торговой системы срочного рынка МБ
--
-- Подсчёт количества событий, произошедших за последние несколько секунд.
-- При регистрации очередного события в массив событий добавляется новый элемент с указанием текущего момента времени.
-- При подсчёте числа событий учитываются только те события, которые произошли не более чем указанное количество
-- секунд назад, а остальные события удаляются из массива.
--
local EventsCounter = {}
local function systime()
local d = os.sysdate()
local mcs = d.mcs or 0
d.ms = nil
d.mcs = nil
return os.time(d) + mcs * 0.000001
end
--- Конструктор.
-- @param self объект
-- @param interval количество секунд, на протяжении которых отслеживаются события
local function new(self, interval)
local object = {
interval = interval,
id = 0,
events = {},
}
setmetatable(object, self)
self.__index = self
return object
end
EventsCounter.new = new
--- Зарегистрировать событие.
-- @param self объект
local function registerEvent(self)
self.id = self.id + 1
self.events[self.id] = systime()
end
EventsCounter.registerEvent = registerEvent
--- Узнать, сколько событий произошло за последние несколько секунд.
-- @param self объект
-- @return количество событий, произошедших за последние несколько секунд
local function getCount(self)
local now = systime()
local count = 0
local remove = {}
for id, time in pairs(self.events) do
if now - time <= self.interval then
count = count + 1
else
remove[id] = true
end
end
for id, _ in pairs(remove) do
self.events[id] = nil
end
return count
end
EventsCounter.getCount = getCount
return EventsCounter
Использовать примерно так:
Код
local EventsCounter = require("EventsCounter")
local eventsCounter = EventsCounter:new(1)
-- Перед отправкой транзакции проверяем количество событий и притормаживаем, если надо
while eventsCounter:getCount() > 40 do
sleep(10)
end
-- Ваш код, который отсылает заявку
sendTransaction()
--
eventsCounter:registerEvent()
Недостатком является ожидание, пока предыдущие события уйдут в прошлое. А можно было бы что-то полезное делать. Но для такой реализации уже более сложный код надо писать.
_sk_ написал: Раз уж QPILE больше не развивается и его всё больше заменяет QLua, давайте перенесём комбинацию Ctrl+F11 с пункта меню "QPILE скрипты" на пункт меню "Lua скрипты". Полагаю, что пользователей, довольных этим нововведением, будет больше, чем недовольных, а реализация от разработчиков терминала практически не потребует усилий.
Добрый день,
Мы рассмотрели Ваше пожелание. По итогам его анализа сообщаем Вам, что реализация пожелания признана потенциально целесообразной. Если по результатам дальнейшего анализа, включающего юридические аспекты, анализ на непротиворечивость с общей политикой компании, никаких возражений не возникнет, мы постараемся включить Ваше пожелание в план доработок при выпуске одной из следующих версий нашего ПО.
Может, уже пора, т.к. QPILE уже всё на срочном рынке в ближайшей перспективе?
Поскольку QPILE на срочном рынке при 19-значных номерах работать не будет и уже несколько лет не обновляется и не поддерживается, предлагаю удалить QPILE из терминала 8-й версии. Освободившиеся горячие клавиши отдать для более насущных нужд (например, для QLua).
Mikhail написал: Здравствуйте! Не подскажете почему во время приостановке торгов фьючерсами например сегодня в 11.17.55 LKH0 ф-ии getParamEx(class, name, "STATUS").param_value getParamEx(class, name, "TRADINGSTATUS").param_value возвращают 1? Кто ее ставит брокер или биржа? Какая функция в итоге показывает приостановку торгов инструментом?
Статус транслирует биржа. Если статус был некорректным, Вам следует обратиться к брокеру для проведения диагностики совместно со специалистами биржи.
По моему опыту, биржа не особенно следит за тем, что указано в статусе при приостановке торгов по инструменту.
Александр М написал: 2. Тип полей во всех текущих функциях, которые в качестве параметров требуют ввода номера заявки или сделки или возвращают номер заявки или сделки, НЕ поменяется.
По-моему, весь смысл перехода на 5.3 в том, чтообы тип этих полей поменялся. В NUMBER больше 51 бита не впереть даже на 5.3.
Там хитрее сделано. Пока идёт работа только с целыми числами, используются все биты как в стандартной целочисленной арифметике в других языках, а вот при смешивании целых чисел и double получается результат double. Например, для перевода целого числа x в double рекомендуют делать что-то типа x = x + 0.0
новичок написал: ну а версию луа апните или тоже не скажете? :)
Да апнем, будет 5.3
СУПЕР!
Все, кто при программировании скриптов использовал module, придётся обновить код, чтобы их не было. При переходе от Lua 5.1 к Lua 5.3 от этого отказались.
6. Проблемы работы с длинными номерами в QLUA (на любых версиях терминала на момент публикации данного уведомления). Для решения проблем пп. 5-6 следует установить версию терминала QUIK, которая на момент публикации данного уведомления еще не вышла, но планируется к выпуску до того, как данное изменение в торговой системе будет внедрено.
но текстовый номер заявки всё равно приходит в сообщении о транзакции? Его можно будет использовать, хоть он и 19 значный?
Такое есть только в OnTransReply, но нет в OnTrade, OnOrder, так что эта информация особенно не поможет, т.к. на одном OnTransReply далеко не уехать.
Цитата
что терминал версии 7.xx возвращает в полях: * trade_num таблицы, приходящей в функции обратного вызова OnTrade; * order_num таблицы, приходящей в функции обратного вызова OnTransReply; * order_num таблицы, приходящей в функции обратного вызова OnOrder? Желательно с примером, какой был номер на бирже и как этот номер отображается в QLua.
Вопрос остался без ответа. Можете привести реальный пример типа: на бирже был номер заявки 9876543210987654321, внутри QLua это будет видно как ... (и привести значение, которое в QLua получится). Тогда явно будет видно, с какими проблемами столкнёмся.
Поскольку разработчики терминала имеют возможность проверить поведение терминала на тестовом полигоне МосБиржи и это не связано с релизом 8-й версии, просьба к ним дать ответ на вопросы.
В рамках QLua, если используются 19-значные номера сделок, что терминал версии 7.xx возвращает в полях: * trade_num таблицы, приходящей в функции обратного вызова OnTrade; * order_num таблицы, приходящей в функции обратного вызова OnTransReply; * order_num таблицы, приходящей в функции обратного вызова OnOrder? Желательно с примером, какой был номер на бирже и как этот номер отображается в QLua.
Я предполагаю, что номера сделок с потерей числовой точности. Если да, то выходит, что алготрейдинг в 7-й версии терминала с использованием QLua станет невозможным на срочном рынке.
_sk_ написал: С этими номерами арифметические операции вряд ли кто-то производит.
еще как пользуются
Цитата
_sk_ написал: возврат номеров заявок и сделок в виде строки
поздравляю, #ВСГ
Приведите, пожалуйста, примеры того, как Вы работаете с номерами заявок и сделок, чтобы потребовались арифметические операции (+, 0, *, /) с этими номерами. Интересно.
Мне кажется, что наиболее подходящим решением для Lua будет возврат номеров заявок и сделок в виде строки. С этими номерами арифметические операции вряд ли кто-то производит. Номера используются в качестве ключей в таблицах. Если ключей много и хочется экономить память, то уже писатели скриптов могут этим заняться, разбивая длинные строки на более короткие подстроки и преобразовывая их в числа для формирования составных ключей.
Теоретически, можно как-то через userdata выкручиваться, чтобы сразу экономить память, но там ещё разбираться надо.