Уведомление о необходимости обновления торговых терминалов в связи с изменениями на срочном рынке Московской биржи, Список проблем при работе устаревших версий QUIK после обновления торговой системы срочного рынка МБ
Думаю, что надо разработчикам терминала предупридить всех брокеров, чтобы версию QUIK обновляли до 8.8.4.3, чтобы как можно меньше было ошибок в QLua, иначе накроет волна жалоб уже не только от энтузиастов-тестировщиков, но и от всех остальных пользователей.
В этой версии поломано поле balance, которое используется в функции обратного вызова OnOrder в QLua. Если это Вам не критично, можете использовать 7.27, если критично, то откатывайтесь на 7.16, например. В какой именно версии была поломка, я не помню точно.
Предлагаю ещё раз вернуться к теме поддержки кодировки UTF-8 в терминале QUIK. Кажется, что QUIK -- это одна из последних программ, которая ещё не перешла на современные стандарты.
Постарались ли разработчики рассмотреть это пожелание? Приняли ли решение реализовать?
Провёл исследование на тему работоспособности wine для терминала QUIK.
1) Если использовать wine 4 (например, в текущем Debian 10.5), то терминал работает. 2) Если использовать wine 5.16 (текущий development-релиз; подключение репозитория см. на сайте WineHQ.org), то терминал тоже работает (пробовал в Linux Mint 20). 3) Версии 5.0 - 5.5 поломанные или недоделанные. Как я понял, там серьёзная переделка кода идёт. С какого момента починилось -- не исследовал уже.
Для меня работает -- это запускаются скрипты QLua.
Я хоть и не техподдержка, но скажу, что начиная с 8.5, чем больше версия, тем стабильнее терминал. Ошибки устраняются быстрее, чем создаются новые, пока что.
Повышенное потребление оперативной памяти при открытых таблицах «Купить/продать» и «Состояние счета».
В некоторых случаях наблюдались расхождения в значениях доходности по облигациям, вычисленных в форме ввода заявки и в Таблице заявок.
При использовании специализированной формы ввода заявок добавление транзакции в карман транзакций могло приводить к отправке данной транзакции в торговую систему.
Некорректный расчет доходности в специализированной форме ввода заявок, который не соответствовал доходности заявки.
Тема называется "Что нужно знать перед обновлением на новую версию".
Вот я хочу знать, как запустить терминал, чтобы он всегда работал с ключом -full-dump. Это будет сильно востребованная функция для отсылки дампов разработчикам после релиза Спектры на МосБиржи.
Пропишем в ярлыке этот ключ, тогда через ярлык терминал запустится с этим ключом (в диспетчере задач в колонке "Командная строка" видно). Если сделать перезаказ всех данных с перезагрузкой, то терминал перезапускается, но ключи ставит сам (что-то типа -nologo -connect -refresh_tables) и там больше нет ключа -full-dump. Почему? Как сделать, чтобы он там всегда был?
Как только падает тестовый терминал -- шлю вам дампы (CQ02798550). Архив терминала и QLua-скрипты выслать нет возможности. На реальную эксплуатацию страшно ставить, т.к. при завале 10 скриптов потом долго и дорого последствия разбирать.
По субъективным ощущениям, падения учащаются при параллельной эксплуатации нескольких QLua-скриптов, которые интенсивно запрашивают свечные данные из DataSource-объектов. В принципе, могу попытаться написать тестовый стенд. Может, на нём удастся воспроизвести эти падения.
Игорь написал: Надо ли дамп присылать как предлагается? У меня за месяц использования 8.5.2.11 от ВТБ (так и нет обновления кстати) только вчера один раз вылетел при попытке поиска инструмента.
Эту сырую версию нужно срочно обновлять до более стабильной 8.8.1.5. Странно, что ВТБ этого не делает.
Опасно. Терминал 8.8.1.5 ещё не готов к работе, т.к. падает с дампами. Пользователям ещё повезло, что у биржи менялись приоритеты (возможность отрицательных цен) и из-за этого дата всё отодвигалась.
Неясно, успеют ли разработчики за оставшийся месяц залечить дыры.
Запускаю терминал через info.exe -clear. Если не подключаться к серверу QUIK, то из программы можно выйти без дампа. При попытке подключения происходит падение с дампом.
Попробовал, получится ли запустить QUIK 8.8.1.5 под Ubuntu 20.04.1 LTS. Вот "Инструкция по установке".
1) Поставить Wine 5.0 (5.0-3ubuntu1) и WineTricks (0.0+20200412-1) из Ubuntu Software. При запуске WineTricks видим сообщение:"Вы используете 64-битный WINEPREFIX." 2) Указать через "Поменять настройки", что версия Windows 10. 3) В папку .wine/drive_C поместить папку QUIK, внутри которой файлы терминала как они работают на Windows-компьютере. 4) Выбрать в WineTricks "Запустить explorer", потом найти через "Мой компьютер" папку C:\QUIK и запустить оттуда info.exe. 5) Терминал как-то запускается. Пока не подключаемся к серверу QUIK. 6) Жмём "Система -> Выход". Программа завершает работу, при этом вылетает сообщение о созданном дампе.
В принципе, дальше можно экспериментировать с устойчивостью всего этого хозяйства и разборками, что не работает и почему.
Круто, что поделились опытом и указанием на конкретные баги! Правильно указали на то, что идёт движение в сторону отказа от Windows в сторону Linux. Поддерживаю эту точку зрения. Присоединяюсь к призыву к разработчикам терминала обратить внимание на важность выпуска дистрибутива под Linux.
Мне тоже хочется перейти на Linux, но использовать терминал только для алготрейдинга: немного таблиц и графиков + десяток QLua-скриптов. Недоработки в графическом интерфейсе не так критичны. Хотелось бы, конечно, чтобы терминал работал напрямую в deb-системах. Ну, или, хотя бы, через Wine.
Неужели в коде разработчики используют столько нестандартных наворотов, что всё это нестабильно работает в Wine? Скорее, какие-то баги просто не вылезают под Windows.
Пока на Windows происходят регулярные падения терминала вплоть до версии 8.8.1, переходить рано, но когда-то же это закончится.
Поскольку 7-я версия QUIK уже не актуальна, а с введением 19-значных номеров заявок будет просто несовместима со срочным рынком МосБиржи, то инструкция для установки для Linux + Wine64 + QUIK 8, всё-таки, кажется весьма нужной.
В терминале версии 8.8 вызываем пункт меню "Перезаказ данных", отмечаем галочку "Архив данных для построения графиков". После перезагрузки терминала кажется, что архив не был очищен (в QLua-скриптах количество свечей в datasource-объектах заметно больше 3000 свечей).
Если же руками почистить папки archive и archive\bak, то количество свечей становится 3000.
1. Некорректный расчет стоимости портфеля по клиентам со схемой кредитования МД+ при использовании валюты в качестве базового индикатора при настройке множеств с зависимыми ценами. 2. После редактирования пользователем настроек индикатора его целочисленные параметры ошибочно становились вещественными. 3. При смене учетной записи на графиках ошибочно отображались заявки и сделки предыдущего пользователя. 4. Ошибка, которая в некоторых случаях приводила к отображению пустых строк в Таблице заявок. 5. Ошибка, которая при закрытии таблицы, созданной при помощи скрипта Lua, могла приводить к зависанию Рабочего места QUIK. 6. В некоторых случаях в таблицах «Позиции по деньгам» и «Позиций по инструментам» могли отображаться ранее удалённые позиции. 7. Ошибка, из-за которой в некоторых случаях не отображались данные в таблице «Состояние счёта».
1) Сделайте так, чтобы каждый робот раз в минуту писал в отдельный файл текущую дату и время. Все такие файлы логично организовать в одной папке.
2) Напишите отдельный скрипт, который периодически проверяет содержимое этих файлов. Если в файле дата и время отличаются от текущих более чем на 3 минуты, значит робот, который должен был писать в этот файл, не работает.
Если хотите более оперативной реакции, надо чаще писать в файлы и чаще проверять их содержимое.
Единственная проблема состоит в том, что бывает, что один скрипт читает файл, а другой туда пишет в этот же момент. Тогда некоторые глюки могут быть. Проблему тоже можно решить: писать в файлы, скажем, в промежуток от 10 до 20 секунд каждой минуты, а читать содержимое с 30-й по 40-ю секунду.
_sk_ написал: Да ещё и регрессы в тех местах, которые не ожидали увидеть (см. второе сообщение темы).
Строго говоря это не баг, а наоборот в соответствии с пожеланием не то чтобы давним . Вот поэтому и приходится влезать в некоторые темы и пытаться доказать некоторым пожелателям, что их некоторые пожелания не так уж хороши, как им кажется. Ну в этом конкретном случае я скорее за, оно так логичнее.
Пожелатели просили, чтобы терминал не портил целочисленные значения параметров индикатора. Раньше терминал всё преобразовывал в float. Теперь вообще не даёт пользователю ввести дробное число, если инициализация была целым.
Думаю, лучше сделать так: если пользователь изменил значение параметра, оставив его целым, всё хорошо, а если пользователь хочет поставить дробное значение параметра, пусть ставит, после чего происходит преобразование в тип float.
Юрий написал: Зато я отправлял уже раз 6.. полные дампы.. из них половина полностью с квиком без своих скриптов индикаторов и ключей. Но почему-то так причина и не установлена. Во всяком случае об обратном они не сообщали.
Спасибо Вам за это. Иначе и после 19-значных номеров на таком же качестве софта будем сидеть.
Все колбеки вызываются из одного потока и каждый из них повторяется в различных скриптах. В итоге получается дублирование одних и тех же действий многократно.
Мне кажется, что если бы релизы выпускались чаще, было бы гораздо проще выискивать и устранять ошибки.
Пусть будет бета-версия для тестирования. Разработчики починили что-то важное, собрали бета-релиз, выложили, получили обратную связь от пользователей в течение нескольких дней. Как более-менее устоялось -- выпустили официальный релиз.
А так, как сейчас, всё очень медленно происходит. Пользователи начинают терять интерес, не верят в то, что их баги будут починены в ближайшее время. Да ещё и регрессы в тех местах, которые не ожидали увидеть (см. второе сообщение темы).
Я отправлял 2 раза дампы, причину разработчики установить не смогли. Но я не отправлял архив терминала и расширенный дамп не делал. Один раз терминал упал без QLua-скриптов. Тоже дамп отправил в техподдержку, пока ещё не ответили.
Исправленные недоработки, касающиеся QLua: 1) Аварийное завершение работы Рабочего места QUIK, происходившее при повторном заполнении таблиц (например, из QPILE-скрипта). 2) В некоторых случаях не освобождалась память при использовании скриптов на языке Lua. Плюс: Излишнее потребление памяти при использовании тиковых графиков
Вчера опять терминал 8.6.0 упал с дампом. Дамп выслан разработчикам. Нестабильная работа, к сожалению. Когда будет новая версия -- не говорят, цикл выпуска релизов медленный, хотя ошибки критические.
Поэтому я решил, что Lua 5.3 в своих скриптах проверил, правки для восстановления работоспособности внёс, а теперь откачусь к версии 8.3, чтобы финансово не терять из-за таких внезапных падений в неподходящее время. Пусть останется один тестовый терминал с малыми торговыми объёмами, а основные объёмы пока доверять новым терминалам не будем.
Вчера терминал упал с дампом. Выслал его разработчикам для анализа.
Получилось так, что сначала терминал нормально работал несколько дней, потом я его решил перезапустить для профилактики с перезаказом всех данных, после чего на 2-й торговый день внезапно произошло падение.
А теперь хотелось бы увидеть ответ от разработчиков терминала, что они по этому поводу думают.
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. Не выставлялись заявки на досрочную экспирацию опциона.
В крайнем случае, можно сделать справочник классов как таблицу, где ключ -- код инструмента, значение -- код класса. Будет такой справочник, скорее всего, один, заполнить его несложно и потом везде применять.