МосБиржа перенесла релиз на 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 выкручиваться, чтобы сразу экономить память, но там ещё разбираться надо.
С этим не поспоришь. Только лучше бы знать, к чему нам готовиться. Время то уже тикает, до 16 декабря не так уж много времени осталось. Хотя бы спецификации уже есть? Номера будут строками приходить, раз они в Lua NUMBER не укладываются? Или будет обновление Lua до 5.3, где есть поддержка long на 64-бита?
Прочитал уведомление "Уведомление в связи с обновлением торговой системы срочного рынка Московской биржи (Spectra 6.3)", где говорится о 19-значных номерах заявок и сделок.
Там было написано так: Внимание! Это крайне важно!
В связи с этим вопросы:
1) Если внутри QLua для номеров заявок и сделок используются переменные числового типа, то появятся ли отрицательные значения в этих переменных?
2) Если появятся, то будет ли корректно работать постановка/снятие заявок через sendTransaction?
Просьба добавить любые другие подробности касательно того, с какими проблемами могут столкнуться роботописатели?
Старатель написал: В какой версии была добавлена ошибка? 7.16 - это последний релиз 7 версии, где нет этой ошибки?
Точно не отслеживал. У меня в какой-то момент при попытке обновиться на более позднюю версию с версии 7.16 вылезла проблема, пришлось откатиться. Так теперь на 7.16 и сижу. В последней версии 7.х терминала ошибка осталась.
У меня была такая проблема. Разработчики больше не поддерживают 7-ю версию терминала. Откатитесь на версию 7.16 (там ещё нет этой ошибки) или перейдите на 8.1 (там уже нет этой ошибки).
А вообще, плохо, конечно, что последний релиз 7-й версии терминала оказался таким вот образом сломан.