Евгений, всё, что было до сообщения #26, касалось боевого квика. Скрины с Junior сделаны специально для саппорта, они знают почему.
Надо делать так, как надо. А как не надо - делать не надо.
Объемы торгов меняются на следующий день
Пользователь
Сообщений: Регистрация: 30.01.2015
Роботорговец
29.01.2021 19:24:31
*смотрим последнюю свечу предыдущего дня (28.01)
Надо делать так, как надо. А как не надо - делать не надо.
Объемы торгов меняются на следующий день
Пользователь
Сообщений: Регистрация: 30.01.2015
Роботорговец
29.01.2021 19:24:06
*смотрим последнюю свечу предыдущего дня (28.09)
Надо делать так, как надо. А как не надо - делать не надо.
Объемы торгов меняются на следующий день
Пользователь
Сообщений: Регистрация: 30.01.2015
Роботорговец
29.01.2021 19:22:14
Цитата
Alexey Ivannikov написал: Проблема некорректного отображения объема дневных свечек до начала новой торговой сессии
Это неточная формулировка. Последняя свеча предыдущего дня остаётся искажённой и после начала торговой сессии.
Цитата
Alexey Ivannikov написал: с искажениями данных в свечах меньших интервалов мы до сих пор не сталкивались.
Давайте посмотрим вместе: Открываем график H4 в Junior, смотрим последнюю свечу: Теперь тот же график в бинарнике:
Надо делать так, как надо. А как не надо - делать не надо.
Отладка QUIK 8.12
Пользователь
Сообщений: Регистрация: 30.01.2015
Роботорговец
29.01.2021 16:09:42
Цитата
swerg написал: Как такое можно было сделать?! Интересно, в компании Arqa есть отдел Quality Assurance? включают ли сотрудники этого отдела иногда голову?
Скрытый текст
"Крылатая" от саппорта:
Цитата
так поведение окон реализовано на данный момент. Поэтому в данном случае оно корректно.
Надо делать так, как надо. А как не надо - делать не надо.
Средства разработки многопоточных скриптов в QUIK., OS_Quesha, свидетельство регистрации в Роспатенте № RU 2020612905. Бесплатная для некоммерческого использования.
Пользователь
Сообщений: Регистрация: 30.01.2015
Роботорговец
28.01.2021 17:50:43
Цитата
Nikolay написал: Интерфейс на iup уже вызывает вопрос о необходимости даже пробовать.
Что не так с iup?
Надо делать так, как надо. А как не надо - делать не надо.
Объемы торгов меняются на следующий день
Пользователь
Сообщений: Регистрация: 30.01.2015
Роботорговец
28.01.2021 09:14:47
К объёму дневной свечи предыдущего дня примазывается объём вечерней сессии, т.е. вечёрка считается два раза. Утром сразу после подключения к серверу начинают грузится тики. И объём вчерашней дневной свечи и close меняются с каждым тиком.
Надо делать так, как надо. А как не надо - делать не надо.
Объемы торгов меняются на следующий день
Пользователь
Сообщений: Регистрация: 30.01.2015
Роботорговец
27.01.2021 20:31:31
*без текущего торгового дня (curr_data.log и info.log удалены)
Надо делать так, как надо. А как не надо - делать не надо.
Объемы торгов меняются на следующий день
Пользователь
Сообщений: Регистрация: 30.01.2015
Роботорговец
27.01.2021 20:31:01
Это часовой график без текущего торгового дня (curr_data.log и info.log)
А это график после подключения к серверу
Надо делать так, как надо. А как не надо - делать не надо.
Объемы торгов меняются на следующий день
Пользователь
Сообщений: Регистрация: 30.01.2015
Роботорговец
27.01.2021 20:20:19
Искажает данные QUIK-клиент: на минутных и часовых таймфреймах задваивает объём последней свечи предыдущего дня. На дневном таймфрейме не понятно, как считает.
Надо делать так, как надо. А как не надо - делать не надо.
Объемы торгов меняются на следующий день
Пользователь
Сообщений: Регистрация: 30.01.2015
Роботорговец
27.01.2021 19:59:49
Искажается последняя свеча предыдущего дня на каждом таймфрейме.
Надо делать так, как надо. А как не надо - делать не надо.
Объемы торгов меняются на следующий день
Пользователь
Сообщений: Регистрация: 30.01.2015
Роботорговец
27.01.2021 19:24:45
Похоже, к объёму предпоследней свечи приплюсовывается ещё какая-то левота.
Евгений, Проделайте следующее: закройте QUIK и удалите curr_data.log и info.log. После запустите QUIK. Не подключаясь к серверу, посчитайте объём. На всех таймфреймах сумма за 26.01 должна быть 4199489.
Надо делать так, как надо. А как не надо - делать не надо.
Объемы торгов меняются на следующий день
Пользователь
Сообщений: Регистрация: 30.01.2015
Роботорговец
27.01.2021 18:59:58
Графики перезаказал, если чё.
Надо делать так, как надо. А как не надо - делать не надо.
Объемы торгов меняются на следующий день
Пользователь
Сообщений: Регистрация: 30.01.2015
Роботорговец
27.01.2021 18:52:56
Цитата
Евгений написал: На подсказке вот эта цифра 4846095
Такая же фигня. На разных таймфреймах за 26.01 такие суммы объёмов по SiH1 : Причём, если по тикам считать, то будет 4 199 489 за день. В dat-файле такое же значение на дневном графике. Скрин из QMinEditor:
Надо делать так, как надо. А как не надо - делать не надо.
У снятой заявки не заполняется поле canceled_uid, если заявка снята вскоре после выставления
Старатель написал: В заявках, снятых в результате транзакций "MOVE_ORDERS" на FORTS и "Изменение заявки" на ФР, UID снявшего не заполняется
или только мне это мерещится?
Надо делать так, как надо. А как не надо - делать не надо.
У снятой заявки не заполняется поле canceled_uid, если заявка снята вскоре после выставления
Пользователь
Сообщений: Регистрация: 30.01.2015
Роботорговец
21.01.2021 11:09:43
Roman Azarov, о вашей заинтересованности говорит реакция на обращения (не только в этой теме): спустя три недели после сообщения о MOVE_ORDERS:
Цитата
Roman Azarov написал: Данная проблема нами не разбиралась.
Так ка на самом деле
Цитата
Незнайка написал: заполняется ли вообще поле сервером при перестановке заявок
или нет? О каких разных конфигурациях вы пишите, когда эта проблема общего характера. И рассматривать её надо не в частном порядке.
Цитата
Roman Azarov написал: устранение проблемы на демо, вовсе не обязательно приведет к скорейшему устранению проблемы на боевом сервере брокера
MOVE_ORDERS - это ведь проблема не демо, не так ли? Как только (и если) ошибка будет исправлена, и брокер накатит обновление, canceled_uid будет заполняться и на серверах брокера. Некоторые брокеры устанавливают обновления сразу после их выпуска, другие - прежде тестируют на своём тестовом контуре. Это решение брокера, что и когда обновлять.
Цитата
Roman Azarov написал: обращение будем вынуждены закрыть
Моё дело малое: сообщить об обнаруженной проблеме разработчику ПО. Если это никому не надо, так мне тем более.
Надо делать так, как надо. А как не надо - делать не надо.
Ошибка работы getScriptPath() из индикатора (версия 8.11.0.66), QUIK 8.11.0.66
Пользователь
Сообщений: Регистрация: 30.01.2015
Роботорговец
21.01.2021 09:34:37
Надо делать так, как надо. А как не надо - делать не надо.
ParamRequest и getParamEx2, Как получить актуальные данные через getParamEx2?
Пользователь
Сообщений: Регистрация: 30.01.2015
Роботорговец
20.01.2021 18:08:33
Цитата
BlaZed написал: определить что данные еще не загружены легко. Например для числовых значений getParamEx2 будет возвращать всегда 0
Это не показатель. Многие параметры легко могут быть равны нулю. И цена, наверное, тоже (?), тот же фьючерс на нефть. Но это не точно. Признаком, что данные в течение торговой сессии не были получены является пустая строка в param_image.
Надо делать так, как надо. А как не надо - делать не надо.
ParamRequest и getParamEx2, Как получить актуальные данные через getParamEx2?
Пользователь
Сообщений: Регистрация: 30.01.2015
Роботорговец
20.01.2021 18:00:25
swerg, ну давайте пофантазируем, что в ближайшем десятилетии нам дали такую функцию:
Цитата
ParameterReceived(STRING class_code, STRING sec_code, STRING param_name) Возвращаемые значения: nil - при ошибке 0 - подписка не включена 1 - подписка включена, но параметр ещё не получен с момента последней подписки 2 - подписка включена, параметр получен
Либо можно возвращать то же значение дополнительным параметром received в таблице, возвращаемой getParamEx2 Значение 0 - можно и не делать, не вижу возможности его использовать. Возможно, и сам клиент, узнаёт об успешности подписки только по факту получения параметра с сервера. В любом случае, сервер что-то шлёт клиенту (хотя бы дефолтные нули и пустые строки), даже если
Цитата
swerg написал: данных объективно этих может не быть (неликвид)
Использование:
Скрытый текст
Код
function main()
ParamRequest(class_code, sec_code, param_name)
local r = ParameterReceived(class_code, sec_code, param_name)
if r == 2 then
-- Параметр уже был заказан и получен
local param = getParamEx2(class_code, sec_code, param_name)
-- Далее можно сразу работать с этим параметром или ждать колбека
...
elseif r == 1 then
-- Параметр ещё не получен, ждём колбек
elseif r == 0 or r == nil then
message("Что-то пошло не так", 3)
end
end
function OnParam(class_code, sec_code)
local r = ParameterReceived(class_code, sec_code, param_name)
if r == 2 then
-- Параметр получен
local param = getParamEx2(class_code, sec_code, param_name)
...
else
-- Ждём следующий колбек
return
end
end
Либо то же с использованием параметра в таблице, возвращаемой getParamEx2:
Код
function main()
ParamRequest(class_code, sec_code, param_name)
local param = getParamEx2(class_code, sec_code, param_name)
if param.received == 2 then
-- Параметр уже был заказан и получен
-- Далее можно сразу работать с этим значением или ждать колбека
...
elseif param.received == 1 then
-- Параметр ещё не получен, ждём колбек
elseif param.received == 0 or param.received == nil then
message("Что-то пошло не так", 3)
end
end
function OnParam(class_code, sec_code)
local param = getParamEx2(class_code, sec_code, param_name)
if param.received == 2 then
-- Параметр получен
...
else
-- Ждём следующий колбек
return
end
end
Если дальше фонтазировать, то в OnParam можно добавить третьим таблицу изменившихся параметров. Но есть мнение, что сервер шлёт клиенту сразу всю строку заказанных параметров, в не зависимости от того, какой из них изменился. И дальнейший разбор отдан на откуп скриптеру. Можно было бы на стороне клиента, разобрать этот список и в таблицу записать только те, что изменились, и вернуть в OnParam.
Цитата
BlaZed написал: При отмене подписки на параметр в кеш ТТТ должен заноситься nil
Так-то, да, было бы понятней, но боюсь, не все с этим согласятся.
Цитата
BlaZed написал: Как временное решение, перезапуск квика с параметром "-clear", тогда кеш будет чистый
В начале сессии кеш и так очищается, а ежели в течение сессии, да ну нафиг такое решение
Надо делать так, как надо. А как не надо - делать не надо.
Нужны данные ТОС (Таблица Обезличенных Сделок) по SBER с 11 по 15 января 2021., К сообществу_Не к техподу_Нужна помощь для восстановления пропущенных данных.
Пользователь
Сообщений: Регистрация: 30.01.2015
Роботорговец
20.01.2021 16:04:15
В ЛС
Надо делать так, как надо. А как не надо - делать не надо.
У снятой заявки не заполняется поле canceled_uid, если заявка снята вскоре после выставления
Пользователь
Сообщений: Регистрация: 30.01.2015
Роботорговец
20.01.2021 14:29:40
Цитата
Roman Azarov написал: Не совсем понимаем, почему данный вопрос адресован нам. Никто не утверждал, что брокер в чем-то виноват.
Не совсем понятно, для чего привлекать брокера, когда ошибка в вашем серверном ПО QUIK, не связанная с каким либо конкретным брокером.
Цитата
Roman Azarov написал: Присылайте скриншоты и номера заявок, будем разбираться.
Это уже без меня. Я не могу быть заинтересован в исправлении ошибок вашего ПО больше, чем вы сами.
Надо делать так, как надо. А как не надо - делать не надо.
ParamRequest и getParamEx2, Как получить актуальные данные через getParamEx2?
Пользователь
Сообщений: Регистрация: 30.01.2015
Роботорговец
20.01.2021 12:50:05
Скрытый текст
Цитата
Старатель написал: Про время передачи данных по каналам связи ведь все в курсе?
Я к тому, что выражение "актуальные данные" в данном случае относительно. И, надеюсь, это понятно, и мы не будем в 100500 раз мусолить тему, о том, что "сам QUIK не знает, что вот прям щас происходит на бирже".
Надо делать так, как надо. А как не надо - делать не надо.
ParamRequest и getParamEx2, Как получить актуальные данные через getParamEx2?
Пользователь
Сообщений: Регистрация: 30.01.2015
Роботорговец
20.01.2021 12:40:37
Цитата
swerg написал: не позволяет вам узнать актуальные сейчас вы видите данные в терминале или нет.
Про время передачи данных по каналам связи ведь все в курсе? Надеюсь вы не это хотите обсудить, а вопрос:
Цитата
Старатель написал: Но пока сообщение о подписке дойдёт до сервера, тот будет слать раннее заказанные параметры (без Р). В результате, вызвав getParamEx2 в коллбэке OnParam(), мы получим старое значение параметра Р, сохранённое в кеше на момент времени Т0.
Если последнее, то давайте начнём хотя бы с сообщения
Надо делать так, как надо. А как не надо - делать не надо.
У снятой заявки не заполняется поле canceled_uid, если заявка снята вскоре после выставления
Пользователь
Сообщений: Регистрация: 30.01.2015
Роботорговец
20.01.2021 12:06:03
Так-то не брокер виноват?
Цитата
Старатель написал: В заявках, снятых в результате транзакций "MOVE_ORDERS" на FORTS и "Изменение заявки" на ФР, UID снявшего не заполняется в любом случае. Наблюдается как на демо, так и на боевом.
Ошибку в серверном ПО QUIK сами найдёте?
Надо делать так, как надо. А как не надо - делать не надо.
ParamRequest и getParamEx2, Как получить актуальные данные через getParamEx2?
Пользователь
Сообщений: Регистрация: 30.01.2015
Роботорговец
20.01.2021 12:01:51
Владимир, как я понял, у вас всегда открыта ТТТ, и в неё добавлены все интересующие вас инструменты и параметры. И вы принципиально не пользуетесь ParamRequest, которая в таком случае и не требуется. Эта же тема для истинных ценителей автоматизации, у которых в терминале открыто только одно окно: Доступные скрипты, ну ещё могут быть окна, созданные скриптами.
Цитата
Владимир написал: за это время котировка ТОЖЕ может поменяться
Имелось ввиду, что пока трейдер примет решение, котировка обновится до актуальной, а не то, что вы подумали.
Надо делать так, как надо. А как не надо - делать не надо.
ParamRequest и getParamEx2, Как получить актуальные данные через getParamEx2?
Надо делать так, как надо. А как не надо - делать не надо.
ParamRequest и getParamEx2, Как получить актуальные данные через getParamEx2?
Пользователь
Сообщений: Регистрация: 30.01.2015
Роботорговец
20.01.2021 10:57:40
Цитата
swerg написал: Но в скриптах почему-то неактуальность цифры становится принципиальной. Но почему?
Разное время реакции. Пока трейдер примет решение, котировка поменяется. А скрипт: получил котировку - выполнил действие.
Надо делать так, как надо. А как не надо - делать не надо.
Изменить версию Lua с 5.4.1 до 5.4.2
Пользователь
Сообщений: Регистрация: 30.01.2015
Роботорговец
18.01.2021 19:19:49
На самом деле, при использовании в боевом скрипте внутри цикла pairs, ещё много операций, а иначе зачем он нужен? Типа:
Код
for sec_code, class_code in pairs(p) do
p[sec_code] = nil
local last = tonumber(getParamEx2(class_code, sec_code, "LAST"))
...
end
И тогда ошибка возникает практически сразу (без форсирования). В таком случае, чтобы избежать ошибки, таблицу лучше обходить через next.
Надо делать так, как надо. А как не надо - делать не надо.
ParamRequest и getParamEx2, Как получить актуальные данные через getParamEx2?
Пользователь
Сообщений: Регистрация: 30.01.2015
Роботорговец
18.01.2021 13:25:33
Цитата
Sergey Gorokhov написал: Для понимания что заказанный параметр начал ехать нужно ждать коллбэк OnParam(), после чего вызывать getParamEx2
Даже в таком варианте вместо актуального значения можно получить не пойми что. Пример: в момент времени Т0 клиент был подписан на получение нескольких параметров по бумаге, затем подписка на параметр Р была закрыта. Через несколько часов в момент времени Т1 скрипт снова подписывается на параметр Р. Но пока сообщение о подписке дойдёт до сервера, тот будет слать раннее заказанные параметры (без Р). В результате, вызвав getParamEx2 в коллбэке OnParam(), мы получим старое значение параметра Р, сохранённое в кеше на момент времени Т0.
Надо делать так, как надо. А как не надо - делать не надо.
написал: Если источник-приемник один, то достаточно в источнике открыть файл в режиме записи, а в приемнике в режиме чтения и просто проверять новые данные в этом файле через read("*l").
Можно и так. Тогда отпадает необходимость в открытии/зактытии/удалении файлов, что затратно.
При частой записи данных файл обмена может сильно разрастись. В этом случае есть сомнения в скорости сброса данных на диск. Маленькие файлы кешируются в памяти операционной системой, а большие? Не получится ли так, что каждый новый flush будет дольше предыдущего?
Цитата
Игорь Б написал: Я делаю так же, только с одним файлом. Передатчик создает файл и пишет туда инфу. Приемник смотрит наличие этого файла. Для него это флаг, что можно читать свежую инфу. Он (приемник) ее читает и удаляет файл. Для передатчика отсутствие файла означает, что файл прочитан и можно создавать файл для передачи новой инфы. Если это и хуже варианта с двумя файлами, то интересно чем?
Думаю, не хуже. Но в обоих случаях при одновременном открытии файла обмена несколькими источниками гипотетически часть данных может быть потеряна.
Цитата
Владимир написал: файл - один, но для каждого скрипта выделяется собственное пространство (фиксированного объёма). Далее они читают и пишут только в свои зоны, а общий диспетчер (который эту таблицу формирует) ставит флаги "прочитано, можно писать следующую порцию".
Вариант, заслуживающий внимания.
Ещё вариант: читать/писать под локом. Файл один, открывается один раз, при остановке скрипта закрывается. Данные записываются в режиме изменения в начало файла, сообщение добивается нулями до фиксированной длины.
Надо делать так, как надо. А как не надо - делать не надо.
Подкиньте идею
Пользователь
Сообщений: Регистрация: 30.01.2015
Роботорговец
16.01.2021 18:29:46
Цитата
Nikolay написал: Конечно, все это для обмена большими объемами и несколькими источниками-потребителями. Если данных мало и они редки, то все это излишне.
ТС задал вопрос по выводу данных в общую визуальную таблицу. Врядли там большие объёмы данных.
Цитата
Nikolay написал: Если пара одна, то это приведет к тому, что все будут ждать пока он освободится.
А в других перечисленных вами вариантах ждать не будут?
Цитата
Nikolay написал: Если источник-приемник один, то достаточно в источнике открыть файл в режиме записи, а в приемнике в режиме чтения и просто проверять новые данные в этом файле через read("*l").
Можно и так. Тогда отпадает необходимость в открытии/зактытии/удалении файлов, что затратно.
Надо делать так, как надо. А как не надо - делать не надо.
Подкиньте идею
Пользователь
Сообщений: Регистрация: 30.01.2015
Роботорговец
16.01.2021 17:47:45
Цитата
Nikolay написал: Это надо для каждый пары источник-приемник создавать пару файлов. Как только несколько писателей, с двумя файлами может быть блокировка.
Второй файл как раз служит для писателей индикатором, что первый файл занят, и запись не возможна. Как только приёмник прочитает данные, он удаляет 2-й файл, что сигнализирует о возможности записи. Т.е. организуются синхронные запись/чтение.
Кстати, ни разу не видел, блокировок файлов, одновременно открытых несколькими Lua-скриптами. Если файл открыт другим приложением, то, да, было.
Надо делать так, как надо. А как не надо - делать не надо.
Подкиньте идею
Пользователь
Сообщений: Регистрация: 30.01.2015
Роботорговец
16.01.2021 16:24:47
Цитата
Kolossi написал: Номер окна выдает каждый раз следующий.16-17-18-19... и так по порядку каждый раз при убиении и запуске скрипта.
Так и есть. При перезапуске скрипта идентификаторы новых окон увеличиваются.
Цитата
Nikolay написал: Вариант 3 - файлы. Но взаимные блокировки будет проблемой.
Вот пример организации обмена с двумя файлами: 1-й файл для передачи данных, 2-й - пустой файл, служит флагом для индикации готовности данных к считыванию.
Надо делать так, как надо. А как не надо - делать не надо.
Подкиньте идею
Пользователь
Сообщений: Регистрация: 30.01.2015
Роботорговец
16.01.2021 15:29:59
Цитата
s_mike@rambler.ru написал: Имея номер окна, можно писать в него из любых скриптов.
Не знаю, может у меня версия квика какая-то другая. Но нумерация окон не сквозная, у каждого скрипта своя, начинающаяся с 1. Т.е., идентификаторы окон разных скриптов могут совпадать. И писать в окно другого скрипта не получается.
Надо делать так, как надо. А как не надо - делать не надо.
Как поставить заявку на LUA с переносом
Пользователь
Сообщений: Регистрация: 30.01.2015
Роботорговец
16.01.2021 08:43:48
Сохраните Lua-скрипт в кодировке ANSI (Win-1251)
Надо делать так, как надо. А как не надо - делать не надо.
Самый быстрый способ получить данные по инструменту
Пользователь
Сообщений: Регистрация: 30.01.2015
Роботорговец
15.01.2021 21:43:55
Цитата
Алексей Злобин написал: если мне достаточно цену сделки определить...то какой метод более эффективный?
Зависит от контекста. Если не нужны цены каждой сделки, то эффективней - getParamEx2
Надо делать так, как надо. А как не надо - делать не надо.
Самый быстрый способ получить данные по инструменту
Пользователь
Сообщений: Регистрация: 30.01.2015
Роботорговец
15.01.2021 18:50:50
Скрытый текст
Дурацкий форум. Удалите дубликаты
Цитата
Алексей Злобин написал: нужна лучшая цена спроса/предложения
Тот, который даёт нужную информацию - getParamEx2. В OnAllTrade спроса/предложения нет.
Надо делать так, как надо. А как не надо - делать не надо.
Самый быстрый способ получить данные по инструменту
Пользователь
Сообщений: Регистрация: 30.01.2015
Роботорговец
15.01.2021 18:47:48
ParamRequest только заказывает получение параметров с сервера. Сами значения параметров можно получить в getParamEx2. Т.ч., 3 + 1 - это один способ.
Цитата
Алексей Злобин написал: нужна лучшая цена спроса/предложения
Надо делать так, как надо. А как не надо - делать не надо.
Самый быстрый способ получить данные по инструменту
Пользователь
Сообщений: Регистрация: 30.01.2015
Роботорговец
15.01.2021 18:47:48
ParamRequest только заказывает получение параметров с сервера. Сами значения параметров можно получить в getParamEx2. Т.ч., 3 + 1 - это один способ.
Цитата
Алексей Злобин написал: нужна лучшая цена спроса/предложения
Надо делать так, как надо. А как не надо - делать не надо.
Самый быстрый способ получить данные по инструменту
Пользователь
Сообщений: Регистрация: 30.01.2015
Роботорговец
15.01.2021 18:47:47
ParamRequest только заказывает получение параметров с сервера. Сами значения параметров можно получить в getParamEx2. Т.ч., 3 + 1 - это один способ.
Цитата
Алексей Злобин написал: нужна лучшая цена спроса/предложения
Надо делать так, как надо. А как не надо - делать не надо.
Перестают работать события SetTableNotificationCallback
Пользователь
Сообщений: Регистрация: 30.01.2015
Роботорговец
09.01.2021 14:29:44
При нажатии клавиш с кодами 107 (+), 109 (-), 111 (/) на цифровом блоке клавиатуры не работают события QTABLE_CHAR и QTABLE_VKEY.
Надо делать так, как надо. А как не надо - делать не надо.
Изменить версию Lua с 5.4.1 до 5.4.2
Пользователь
Сообщений: Регистрация: 30.01.2015
Роботорговец
09.01.2021 14:23:47
Чтобы обход таблицы был более корректным, изменим тестовый скрипт, так, чтобы добавление и удаление полей таблицы осуществлялось в одном потоке:
Скрытый текст
Код
local run = true
function OnStop()
run = nil
end
local function f(t)
for i = 1, 100 do
t[""..i] = i
end
for k, v in pairs(t) do
t[k] = nil
end
t = {}
return t
end
p = {}
function OnParam(class_code, sec_code)
p = f(p)
end
a = {}
function OnAllTrade(alltrade)
a = f(a)
end
m = {}
function main()
while run do
m = f(m)
sleep(1)
end
end
Ошибка "invalid key to 'next'" никуда не делась. Для форсирования: перезаказать все обезличенные сделки.
Надо делать так, как надо. А как не надо - делать не надо.
Изменить версию Lua с 5.4.1 до 5.4.2
Пользователь
Сообщений: Регистрация: 30.01.2015
Роботорговец
08.01.2021 17:34:38
Цитата
Roman Azarov написал: С некоторой вероятностью может появиться следующая ошибка?
Верно
Цитата
Roman Azarov написал: У себя подобного за целый день не увидели
Можете форсировать события:
Скрытый текст
Код
local p = {}
function OnParam(class_code, sec_code)
for i = 1, 20 do
p[sec_code..i] = class_code
end
end
local t = {}
function OnAllTrade(alltrade)
for i = 1, 20 do
t[alltrade.sec_code..i] = alltrade
end
end
function main()
while run do
for k, v in pairs(p) do
p[k] = nil
end
for k, v in pairs(t) do
t[k] = nil
end
sleep(1)
end
end
и сделать перезаказ всех обезличенных сделок.
Надо делать так, как надо. А как не надо - делать не надо.
Изменить версию Lua с 5.4.1 до 5.4.2
Пользователь
Сообщений: Регистрация: 30.01.2015
Роботорговец
07.01.2021 09:40:25
В Lua 5.3 и Lua 5.4:
Цитата
invalid key to 'next'
Надо делать так, как надо. А как не надо - делать не надо.
Изменить версию Lua с 5.4.1 до 5.4.2
Пользователь
Сообщений: Регистрация: 30.01.2015
Роботорговец
06.01.2021 11:25:27
Существует ненулевая вероятность, что сборщик придёт как раз во время обхода таблицы в одном из потоков.
Скрытый текст
Код
local p = {}
function OnParam(class_code, sec_code)
p[sec_code] = class_code
end
local t = {}
function OnAllTrade(alltrade)
t[alltrade.sec_code] = alltrade.class_code
end
function main()
while run do
for k, v in pairs(p) do
p[k] = nil
end
for k, v in pairs(t) do
t[k] = nil
end
sleep(1)
end
end
Надо делать так, как надо. А как не надо - делать не надо.
Кривые шибки в QLua
Пользователь
Сообщений: Регистрация: 30.01.2015
Роботорговец
26.12.2020 17:00:43
QUIK v.8.11.0.66, Lua 5.4 Однократная ошибка
Цитата
attempt to call a nil value
в цикле for in pairs в main:
Код
local T = {}
function main()
while run do
...
for k, v in pairs(T) do -- тут ошибка
...
end
...
sleep(1)
end
end
stack traceback:
Цитата
in for iterator 'for iterator'
На момент возникновения ошибки таблица T была пуста: за время работы (3 часа) робота в таблицу элементы не добавлялись. Написать тестовый скрипт для воспроизведения или повторить ошибку не удалось.
Надо делать так, как надо. А как не надо - делать не надо.
У снятой заявки не заполняется поле canceled_uid, если заявка снята вскоре после выставления
Пользователь
Сообщений: Регистрация: 30.01.2015
Роботорговец
23.12.2020 12:22:26
Цитата
swerg написал: Согласитесь, то, что речь про демо-сервер
Да, как оказалось, отсутствие canceled_uid в заявках для "KILL_ORDER" относится к только демо-серверу. В боевом квике все заявки без canceled_uid были сняты "MOVE_ORDERS".
Надо делать так, как надо. А как не надо - делать не надо.
У снятой заявки не заполняется поле canceled_uid, если заявка снята вскоре после выставления
Пользователь
Сообщений: Регистрация: 30.01.2015
Роботорговец
23.12.2020 09:37:43
Roman Azarov, В заявках, снятых транзакцией "KILL_ORDER", не заполняется UID снявшего, если транзакция снята вскоре после выставления. В 8.11 наблюдается в junior. В заявках, снятых в результате транзакций "MOVE_ORDERS" на FORTS и "Изменение заявки" на ФР, UID снявшего не заполняется в любом случае. Наблюдается как на демо, так и на боевом.
Будете ли вы это исправлять в своём ПО - это ваше решение.
Надо делать так, как надо. А как не надо - делать не надо.
У снятой заявки не заполняется поле canceled_uid, если заявка снята вскоре после выставления
Пользователь
Сообщений: Регистрация: 30.01.2015
Роботорговец
22.12.2020 15:43:42
Хотя инициатором "MOVE_ORDERS" был пользователь. Иногда, не сразу разберёшь... Логичнее всё же проставлять canceled_uid
Надо делать так, как надо. А как не надо - делать не надо.
У снятой заявки не заполняется поле canceled_uid, если заявка снята вскоре после выставления