_sk_ (Все сообщения пользователя)

Не скажите, много кто помогает.

В связи с выходом QUIK 8.11 становится актуальным файл core.dll для socket для Lua 5.4.1.

Также mime.dll и ssl.dll надо искать, но уже для других целей.

В частности, появилась Lua 5.4.1, исправлены ошибки, на которые Anton указывал, и прочее. Кто может -- потестируйте.

Полный список внутри архива в папке UpdateDocs.

Новая версия терминала QUIK 8.11 для отладки.

ftp://ftp.quik.ru/public/updates/8.11/quik_8.11.0_upd.zip

Изменений очень много.

Просто напоминаю, что аварийные падения терминала продолжаются, а на отосланные дампы приходит ответ разработчиков:

При этом новой версии уже давно нет. Как-то плохо это выглядит со стороны пользователей.

Благодарю, очень помогли.

Добрый день всем!

Пытаюсь подключить LuaFileSystem (lfs), чтобы это заработало в QUIK 8 с Lua 5.3.


Нужен файл lfs.dll. Если есть у кого, поделитесь, пожалуйста.

Спасибо.

Я у себя сделал так:

1) создал в папке терминала подпапку socket и положил туда файл core.dll, который взял отсюда:
https://github.com/finsight/QUIKSharp/blob/master/src/QuikSharp/lua/clibs64­/53_MD/socket/core.dll

2) в папке с lua-скриптами создал папку lib, куда положил файл socket.lua, который взял отсюда:
https://github.com/finsight/QUIKSharp/blob/master/src/QuikSharp/lua/socket.lua
(в этой же папке ещё и другие файлы библиотек лежат)


3) в скриптах пишу

Возможно, есть какие-то другие способы.

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

В общем-то, терминал 8.9.0.107 по-прежнему падает во время торгов с дампами.

Идея прикольная :) Осталось окно скрипта куда-нибудь спрятать и будет "зачётный костыль".

Терминал является уже достаточно сложной системой, чтобы в нём были такого рода "дыры", которыми можно пользоваться в благих целях.

Ладно, а разработчики могут нам что-то человеческое предоставить?

P.S. Вот было бы здорово создать реестр подобного рода маленьких хитростей. А то я, кажется, только

для синхронизации знаю.

Костыли типа отправки какой-нибудь транзакции на сервер, чтобы OnTransReply сработал, не предлагать.

Есть список слушателей, которых надо уведомлять о коллбэках (каждого слушателя о своём подмножестве коллбэков) как можно быстрее. При этом в main() время от времени возникают вычислительно тяжёлые задачи (заранее нельзя контролировать время их выполнения и разбивать на мелкие подзадачи).

Если пробрасывать события из потока коллбэков в поток main(), то будут возникать задержки, чего не стоит допускать.

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

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

Антон, спасибо за предложенные варианты по п.1. Опасения по поводу п.2 понял. Получается, что лучше просить разработчиков реализовать п.1.

swerg, я же не просто так написал, что

Не помню, предлагали уже такие пожелания или нет.

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

Пускай первый раз функция OnTimer() запускается сразу после OnInit() и возвращает число число миллисекунд, через которое будет сделан следующий вызов функции OnTimer(). Если возвращается не число, то пусть следующий вызов будет через 1 секунду.

Реализация на стороне терминала кажется несложной.

2) Дать пользователю возможность из main-потока подать команду на запуск своей функции в потоке коллбэков. Нормальное название не придумал, но надо что-то типа

В принципе, имея п.2, пользователь сможет самостоятельно реализовать п.2, если только в main-потоке не выполняются тяжёлые вычислительные задачи.

Надо всё это для того, чтобы можно было выполнять в потоке коллбэков регулярные задачи, которые удобнее и архитектурно правильнее делать там, а не в main.

В документации про getMoneyEx написано:

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

Не соглашусь с оценкой 8.7 и 8.9, там есть проблемы при активной эксплуатации. 8.9 лучше, конечно, чем 8.7.

Тогда это страшный симптом. Я надеялся, что следующая версия терминала уже будет без ошибок. :(

Не придётся. А тема показывает, насколько У СТРАХА ГЛАЗА ВЕЛИКИ.    

А где вы взяли такую версию терминала? Официально только 8.9.0.107 есть, если не ошибаюсь.

Спасибо. Это тоже вариант, который позволит узнать нужные заголовки.

Про особенности национальной DestroyTable и, вообще, о корректной работе с окнами в QLua написал бы кто-нибудь хороший мануал с примерами и объяснениями, почему именно так надо. И на форум выложить на память и для начинающих. Или уже есть где такое в интернете?

Проверил Ваш прототип. Думаю, что эта штука вполне может заменить рекомендуемый разработчиками подход с DDE-экспортом. Спасибо!

Отдельное уважение за скорость реакции!

Спасибо.

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

Я не умею, да и разбираться с устаревшими технологиями как-то не хочется.

Наверное, это неплохие варианты. Надобность в таком, по-видимому, будет редкая (один раз запустил и всё). Как сделать по уму и наиболее просто, пусть разработчики подумают.

Спасибо за ответ.

Хотелось бы иметь возможность без DDE обойтись. У меня нет Excel на компьютере, а LibreOffice не поддерживает эту давным давно устаревшую технологию.

Зарегистрируйте тогда пожелание о возможности выгрузки формальных заголовков в обычный текстовый файл выбором пункта меню.

Про настройки на стороне брокера я уточню у брокера.

Да, бирже пофиг на это. В крайнем случае, она вас за неэффективные транзакции оштрафует. Трейдер за всё в ответе, даже если не виноват. :)

А если серьёзно, то для ликвидных инструментов можно отслеживать количество сделок по классу или по классу+инструменту. И если в последние, скажем, 10 секунд нет ни одной сделки, полагаем, что торговля остановлена. Для неликвидных инструментов это будет плохо работать, понятное дело.

Похоже, что параметры "Мин." и "Макс." -- это что-то непонятное, а для акций TQBR и облигаций TQOB параметры "Мин. возм. цена" и "Макс. возм. цена" просто не транслируются.

Ещё вопрос, почему при запросе параметра last для TQBR и SBER за 10 минут до начала торгов мы видим нули:


а не отсутствие результата result="0"? Это биржа нули транслирует или терминал нулём заполняет отсутствующее значение?

Во прямо сейчас я вижу в ТТТ для класса RTSIDX и инструмента RTSI значения Мин. 1151,45 и Макс. 1165,58, но внутри QLua эти значения пока не смог получить.

А в потоке котировок для Акций вообще нет параметров Макс. и Мин. (есть Максимальная цена сделки и Минимальная цена сделки, но это же не то, кажется), при том, что сервер квик на аутсорсинге у Арки стоит и должен быть настроен как надо.

Вопрос, как узнать английское название для параметров Мин. и Макс. остаётся открытым.

И как понять название параметра на английском, если в справке они перечислены в разделе про QPile, а он уже не обновляется? Как называются параметры "Мин." и "Макс." внутри Qlua?

Не пора ли перенести эти описания в справку QLua и актуализировать?

Продолжим тему. Получается, что в Lua-скрипте для получения верхней границы цены надо писать примерно так:

Какие ещё коды классов помимо TQBR и RTSIDX надо указать, чтобы это всё работало корректно?

Нет никакой проблемы, просто убрать сортировку по номеру сделки и всё станет нормально.

Цитата
У себя воспроизвести не смогли, просим предоставить снимок экрана, на котором наблюдается проблема, будем разбираться.

Да чинили же такое в версии 8.6, кажется. Странно, что техподдержка не помнит об этом.

Версию 8.5.2.11 надо СРОЧНО обновлять до последней 8.9, поскольку 8.5 совсем нестабильная версия была.

Это известный глюк с удвоением. Бывает такое. По-хорошему, надо исправлять.

Я понимаю, что нельзя гарантировать, что в терминале есть вся последняя информация с биржи. Но трудно писать код, когда ты проверил в if условие, что всё должно быть хорошо, а после then всё сразу стало плохо (ситуация поменялась). Нет атомарности.

Вот и приходится без проверки всяких условий isConnected() делать какой-нибудь getXXX(), а потом проверять заполненность полей таблицы внутри результата, потому, что с очень малой вероятностью "что-то пошло не так".

Может, я что-то не до конца понимаю, и мне кто-нибудь прояснит ситуацию по приведённым ниже пунктам.

1) isConnected(), конечно, хорошая функция, но мне кажется, что её корректное использование таково: если она вернула 0, то разработчик может предусмотреть запрет на выполнение каких-то действий в скрипте, поскольку информация в терминале не соответствует действительности (устарела). А вот если isConnected() вернула 1, то это ничего не гарантирует: может, нужные шлюзы ещё не подключены, может информация не до конца загрузилась с сервера. Т.е. мы можем избежать гарантированных ошибок при isConnected() == 0, но не сделать ошибок при  isConnected() == 1 эта функция не помогает.

2) При разрыве соединения и повторном подключении терминала к серверу в какой-то момент происходит пропадание информации в ТТТ (и других) и её повторное появление. При работе скриптов в момент "пропадания" информации справочные функции типа getSecurityInfo() могут вернуть пустые таблицы. Это приводит к тому, что скрипт, скажем, читает информацию о размере лота, а там его нет. Неприятно.

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

Может кто поделиться своим опытом по данному поводу? Из каких ещё функций, кроме getSecurityInfo(), будут получаться пустые таблицы в моменты перезагрузки данных? Могут ли разработчики прокомментировать это (и отразить в документации, что возвращается, если нет данных)?

Да откуда же вы такие берётесь?    

В начало функции поставьте проверку на nil и выводите сообщение (через message, например, или в лог, если он у есть). При работе со вложенными массивами/таблицами часто бывает, что забыли внутренние структуры инициализировать.


Тут же явно на nil намёк.

Можно ещё всё в xpcall завернуть и печатать стек, чтобы было понятно, откуда вы попали со значением nil. Пример, как это обычно делается в моём коде приведён ниже. При любой ошибке видно, где она произошла.
 

Владимир, рекомендую прежде чем возмущаться, ознакомиться с учебниками по языку Lua, раз уж приходится на нём программировать в терминале. Также можно почитать информацию о динамически типизируемых языках и зачем так сделали их создатели.

Хотите узнать тип переменной -- есть функция type(переменная), которая возвращает строку с названием типа.

Если tonumber возвращает nil, значит аргумент не может быть представлен в виде числа.

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

Винить кого-то в своих ошибках -- самый простой способ, конечно.

Новая версия для отладки.

ftp://ftp.quik.ru/public/updates/8.9/quik_8.9.0_upd.zip

Исправленные недоработки:

1) Некорректная работа кнопки «max» в специализированной форме ввода заявки.

2) Фильтр по времени в настройках графика теперь недоступен при использовании интервалов
длительностью в «День», «Неделю» и «Месяц».

3) Зависание программы при вызове функции QLUA DestroyTable.

4) В некоторых случаях создание таблиц «Позиции участника по деньгам» и «Позиции участника по
инструментам на выбранных счетах» было недоступно.

5) В некоторых случаях в таблицах «Позиции по инструментам» отображались дубликаты позиций.

6) Некорректное автозаполнение полей торгового счета и кода клиента в панели торговли таблицы
котировок.

7) В некоторых случаях программа аварийно завершала работу при запуске.

8) Некорректная работа фильтра классов и инструментов Таблицы обезличенных сделок.

9) Программа аварийно завершала работу в некоторых случаях после разрыва связи с сервером QUIK и
последующим восстановлением соединения.

10) В некоторых случаях оценка позиций в таблице «Состояние счета» выполнялась по инструменту
некорректного класса.

11) В некоторых случаях на форме ввода заявки рассчитывался некорректный объём комиссии.

12) На форме ввода заявки FX-плагина рассчитывался некорректный объём комиссии.

13) В некоторых случаях программа аварийно завершала работу.

14) Для индикаторов на LUA значения параметров свечей не учитывали младшие разряды, если они
равны «0».

15) Некорректная работа программы на Windows Server 2003.

16) В некоторых случаях не отображались имеющиеся позиции по деньгам и инструментам.

17) Программа аварийно завершала работу при работе скриптов на LUA с данными графиков. Набор
функций для работы с данными графиков описан в пункте 3.10 Руководства пользователя LUA –
Интерпретатор языка LUA / 3. Функции взаимодействия скрипта LUA и Рабочего места QUIK / 3.10
Функции для работы с графиками.

Интересно, разработчики прислушаются или нет?

Вот пример, где 3 класса: фьючерсы, валюта и акции. После столбца времени идёт столбец с микросекундами. Монотонность нарушена.
 

Если в таблицу обезличенных сделок добавить классы TQBR и SPBFUT, то можно убедиться, что время не будет монотонным. Внутри класса TQBR -- да, а всё вместе -- нет, т.к. эти классы торгуются в разных биржевых системах.

Я не проверял ещё, что после нововведений на срочном рынке внутри класса SPBFUT время останется монотонным. Возможно, что сейчас это пока так, но сохранится ли это в будущем -- неясно.

Интересует, исправлены ли ошибки, упомянутые тут:
https://forum.quik.ru/messages/forum10/message48049/topic5119/#message48049
Хоть это и не мои ошибки, внимательное чтение сообщений на форумах подсказывает, что основные причины проблем именно там. Потом эти проблемы могут по-разному проявляться у разных пользователей.

Сегодня не будет релиза? Надо знать, чтобы принимать решение о дальнейшей эксплуатации.

Повторю, что я сам не знаю, как стабильно воспроизвести ошибку. Поэтому высылать код скрипта не имеет смысла.

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

Резюмируя гипотезу: из-за ошибки в другом месте (аварийные завершения работы терминала) получаются "битые" графики, которые потом портят нормальную работу.

Как справиться с проблемой я описал выше.

Есть косвенные признаки того, что в терминале 8.8.4.3 (и, возможно, других версий) могут получаться "битые" графики при склейке 3000 свечей, которые выдаёт сервер, и архива свечей, накопленных в терминале.

Проявляется это как ошибки в скриптах при работе с данными, получаемыми из объектов DataSource. Выходят сообщения типа
хотя код до этого нормально работал несколько дней.

Как стабильно воспроизвести ошибку я не знаю. Помогает закрытие терминала, удаление dat-файлов из папкок archive и archive\bak, повторный запуск терминала. История сбросится до 3000 свечей в этом случае.

Перезаказ данных с указанием всех галочек не помогает.

Может, у кого-то ещё есть похожие симптомы.

Вопрос к разработчикам: когда будет очередной релиз терминала или нам придётся торговать 14 сентября с помощью 8.8.4.3, про который ТОЧНО известно, что там РЕГУЛЯРНО происходят аварийные завершения работы из-за QLua?