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

Ошибку надо в main сделать. Разработчики скажут, что такое поведение. Методов по управлению сейчас нет и вряд ли в обозримом будущем появятся. Окно запуска скриптов до сих пор не масштабируется.

Идея, судя по всему, чтобы не бегать по скриптам при запуске терминала, которые работали в момент закрытия терминала.
События же разные, одно - остановка скрипта, другое - закрытие терминала. При закрытии терминала нет ручной остановки скрипта, а значит при рестарте он будет запущен, т.к. работал.

Для тех, кто вечером выключает терминал, а утром запускает - это вполне ожидаемое, рабочее поведение.

Так что если хотите, чтобы не запускался, просто сделайте ошибку исполнения при остановке. Он тогда не стартует сам.

Нет. Это все не так. Корутина точно также работает. Где в корутине yield, в процедуре return. Где коде coroutine.resume - просто вызов процедуры. Все с точностью до стоки кода. Никаких чудес.
Полная аналогия.

Нет такого. Я просто переделал Ваш пример. У Вас там есть задержка. Уберите, если хотите и не будет никаких задержек.

Тогда давайте еще раз, на пальцах. Берем этот пример и "брюки превращаются":

local is_run = true
-- "Лёгкий поток" для фоновой задачи
local function create_task()
   local count = 0
   return function()
       count = count + 1
       message("Фоновая задача: шаг " .. count)
       return  -- уступаем управление
   end
end
function main()
   local co = create_task()
   message("Запуск фонового лёгкого потока...")
   while is_run do
       co()                  -- возобновляем поток
       sleep(1000)           -- имитация "асинхронного" поведения
   end
end
function OnStop()
   is_run = false
   message("Остановка фонового потока.")
end


Как говорится - найдите десять отличий.

Я на него смотрел еще в году так 16-ом. Как он работает предельно понятно. Подход далеко не новый, да и с чего ему быть новым если корутины в Lua появились в далеком 5.0 от 2003

Правильно. А значит с тем же успехом можно планировать и вызовы процедур, созданных иначе. Какая разница что вызывать - корутину или процедуру. Вызывается из одного и того же места, с тем же ритмом и скоростью. Отличия только в обертке одних в корутины, а другие нет.

Вам, наверно,  стоит все же внимательней изучить работу корутин. По крайней мере создается такое ощущение. Нет ничего асинхронного в операторе yield. Это просто выход из процедуры в этой точке. При повторном вызове вернетесь в нее же.
Сама корутина ничего не делает после выхода по yield. А значит выполняться она может тоже только через вызовы в основном цикле mian. И тоже частота вызовов регулируется задержкой цикла main.

Собственно ваш любимый hacktrade так и работает.

--[[ MAIN LOOP ]]--
working = true
function main()
 --create_table()
 log:trace("Robot started")
 if Start ~= nil then
   Start()
 end
 if Robot ~= nil then

   --Создаем корутину, заворяаивая в неё процедуру Robot
   local routine = coroutine.create(Robot)
   while working do

     --Выполняем корутину в бесконечном основном цикле скрипта
     local res, errmsg = coroutine.resume(routine)
     if res == false then
       log:fatal("Broken coroutine: " .. errmsg)
     end
     if coroutine.status(routine) == "dead" then
       log:trace("Robot routine finished")
       break
     end
     -- Orders processing calls after every coroutine iteration
     for trans_id, smartorder in pairs(SmartOrder.pool) do
       smartorder:process()
     end
   end
 end
 log:trace("Robot stopped")
 if Stop ~= nil then
   Stop()
 end
 io.close(log.logfile)
end

function Robot()

-- Вынуждены создавать еще один бесконечный цикл, чтобы корутина жила. Иначе при втором вызове она умрет.
   while true do
       if feed.last > ind[-1] then
         order:update(feed.last, size)
       else
         order:update(feed.last, -size)
       end
       Trade() - это просто замаскированный yield
   end
end

Логика проста - создали корутину и дергаём ее в цикле постоянно пока она жива. При этом процедура Robot тоже предельно проста - в ней создается бесконечный цикл (еще один), внутри которого есть yield.
Т.е. приходится сооружать корутину, внутри которой городить цикл, чтобы она не умерла. Все это накладывается на работу с глобальными переменными....

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

Ну так и в примере, что я показал, все можно сделать не прямолинейно. А колбек сам вызовется по исполнению. Это мало чем отличается от использования тех же корутин. Пишите менеджер вызова исполняемых процедур, а что он вызывает - не важно. Важно чтобы процедура исполнялась столько сколько надо. Если бы корутина работала сама, без менеджера, то это было бы совсем другая среда. Но такого в lua нет.

Если цель помнить состояние, то это прекрасно делают замыкания. Я, например, так пишу таймеры. Можно и счетчик.

Вот ваш счетчик с колбеком по достижению через замыканиеЭто просто пример с прямолинейной реализацией.

Ну так и функция - это код, который выполняется тогда, когда вызываешь, а не иначе. Т.е. если надо периодически вызывать какой-то расчет, то почему просто не функция. Корутина с остановкой удобна, если надо запомнить состояние и вернуться к выполнению, не передавая заново весь набор параметров. Например, итераторы. Но это далеко не единственный способ так делать. Сделали набор функций и вызывает их в цикле main, пока он крутится.

main в скриптах - это уже дополнительный поток, выполняющийся отдельно от потока терминала. Создавать внутри него псевдо-потоки можно, но это уже не имеет никакого отношения к фоновому исполнению, т.к. все внутри main выполняется фоново к терминалу, если использовать эту терминологию.  

Не вижу смысла. Тем более, что приведенный код выглядит нагроможденным. Если цель проверить какое время необходимо для вычисления c = c + 1 N раз с остановкой на каждую итерацию, то зачем такое количество кода.

К сожалению, это не так. Корутины в Lua - это просто один из инструментов, далеко не идеальный. Я уже говорил, что это же можно сделать через замыкание и через очередь вызовов их. Т.к. они не обеспечивают ничего нового, уникального, то это просто дело вкуса. Если бы это был другой язык, например Go, то это был бы другой разговор.

Так что если нравится использовать корутины - на здоровье. Но сказать, что без них никак, точно нет. Я бы сказал, что к ним стоит прибегать в очень редких случаях - например, создание своего итератора (хотя и здесь можно обойтись без них). Или, например, завернуть некий вызов в корутину, отправить в очередь и потом вызвать.

Это уже не дает ошибку, т.к. после OnCleanUp внутри сессии происходит сброс индексов таблицы ордеров и заново ищем ордера по номеру, когда они появятся. Некорректные индексы появились с выходом 12 версии, ранее такого никогда не было.

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

Еще брокеры с таким поведением

SERVER: ВТБ24, IPCOMMENT: Сервер1
quik_version 12.5.0.20

[INFO  2025-10-24 12:39:35] :           OnDisconnected

INFO  2025-10-24 12:41:37] : OnCleanUp

[INFO  2025-10-24 12:47:56] :           OnCleanUp

[INFO  2025-10-24 12:48:00] : OnConnected flag true

-------------------------------------------------------------------------

Брокер Кит-финанс
quik_version 12.7.1.8

[INFO  2025-10-22 11:34:16] :  OnDisconnected

[INFO  2025-10-22 11:34:48] :  OnCleanUp

[INFO  2025-10-22 11:35:02] :  OnCleanUp

[INFO  2025-10-22 11:35:41] :  OnConnected flag true


Все же возникает вопрос - зачем в середине торговой сессии вызывать OnCleanUp?

При этом данные после такой чистки загружаются минуты.

Не важно какой подход используется - важно как он работает и работает ли он надежно. Если Вы делаете решение для себя и готовы постоянно заниматься отладкой пограничных ситуаций, то делайте как угодно.
Хотя уже здесь корутины начинают привносить излишнюю сложность. Те же замыкания прекрасно справляются с запоминанием окружения и позволяют решать ту же задачу.
Далее, что самое важное - это воспроизводимость результатов, обработка ошибок. И здесь колбеки - это не лучшее решение, т.к. они не гарантированы, приходят в случайном порядке. Для задач реального времени - это приговор.

Представьте, что датчик выдает данные. Вы решаете использовать "модную" библиотеку с колбеками. Но начиная использовать её, получаете данные с пропусками, данные могут приходить из прошлого. Во многих отраслях - это просто недопустимое поведение.

Так что нет, я уж как нибудь сам организую чтение данных, как эти делали последние лет 50.

Я понимаю, что есть соблазн использовать подход со слугой - сказал ему, что делать, он сообщит когда будет результат. Но такой подход всегда требует надсмотрщика, проверки. Так что самому подойти к кастрюле и проверить как там каша - надежней.

Это не так.

trans_id - это просто некий ключ, задаваемый при подаче транзакции. При этом, что важно, он не обязательно уникальный. Т.е. необходимо обеспечить уникальность trans_id для нескольких скриптов, если они есть. Иначе очень вероятна ситуация когда trans_id будет одинаковый у разных скриптов. Более того, если отправите транзакцию через команды интерфейса терминала, то trans_id будет пустой.
Т.о. trans_id - это ваш ключ. Его необходимо использовать только для понимания, что транзакция принята сервером брокера, ядром биржи. Читая ответ транзакции по нему можете увидеть причину отказа.

Если же транзакция прошла, то наступает следующий этап - получить ключ в ядре биржи, и это order_num. Он будет уникальным. Какой там был ключ транзакции бирже не важно, она получает запрос, отправляет ответ. Сервер брокера перенаправляет ответ биржи клиенту.

Если ошибок при отправки транзакции нет, то после регистрации ордера в ядре бирже, в таблице ордеров появится новая запись, в которой будет order_num и trans_id. При этом trans_id может появится не с первого колбека, а, скажем, со второго. Задача - отслеживать записи в таблице ордеров, и по trans_id найти номер ордера - order_num. После его получения про trans_id уже не столь важен. Почему - все просто, ордер может жить дольше чем одна торговая сессия.

Запоминая номер ордера уже можно отслеживать его состояние. Кто-то предпочитает колбеки, т.к. именно так показано в большинстве примеров на просторах ...., я же предпочитаю читать состояние прямо из таблицы ордеров, в реальном времени. Это делать не так и сложно, т.к. всегда можно запомнить номер индекса записи в таблице ордеров. Т.о. order_num будет ключом для скрипта, по которому он всегда может понять что случилось с его ордером. И скрипт при этом должен уметь отличать свои ордера от чужих.


Поэтому нельзя использовать один ключ при клиент-серверном взаимодействии. Есть ключ запроса, есть ключ ответа. Запрос - это просто действие "сейчас". Ответ же может содержать информацию, которая имеет смысл более длительный промежуток времени.

Т.к. с 7-ой версии, кажется, разрешены пропуски на графике, то в теории первый бар может иметь не индекс 1.

Только учитывайте, что этот подход рассчитан на то, что будет вызван OnCalculate для индекса 1. Что в большинстве случаев верно, конечно. Но, судя по сему - не гарантировано. Но предпочитаю более надежный подход через инициализацию переменных в замыкании и проверке первого вызова для любого индекса.  

Его не стоит применять в Init. Запуск индикаторов у Квика устроены очень странно. Вызывайте на первом вызове колбека OnCalculate.

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

CreateDataSource (STRING class_code, STRING sec_code, NUMBER interval, [, STRING param])

Третий параметр - это число. "INTERVAL_H1" - это строка.

INTERVAL_H1 (без кавычек) - это константа = 60

Лучше использовать просто числа, а не константы из qlua.

Ну так перейдите на индексацию временем в виде числа, время-то не убегает.

Опять эти разговоры про параллельное исполнение. Lua - синхронное, однопоточное изделие. Корутины - это просто созданный стек и выполнение через переключение. Работать может либо тело скрипта, либо корутина, но не параллельное исполнение. Как только вы начинаете с помощью внешних средств пробовать сделать параллельное исполнение, то сразу же возникает вопрос о защите стека, т.к. всегда возникнет ситуация когда кто-то пишет в стек, а другой, параллельный, читает и очищает стек. Квик в этом плане падает сразу, если небрежно уронить стек скрипта. Что отдельная тема, прочему скрипт убивает весь терминал.

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

Нет, мне это не надо. Просто замечание, что если предлагаете какое-то открытое решение, то зачем скрывать код, его подключающее.

Я понял про что это библиотека. Я говорил, что нет исходников.

Просто к слову, т.к. используется неизвестная библиотека QluaUser.dll то запускать это не видя исходники будут сложно. По крайней мере мне, не знаю как другим.

Судя по всему это так и не будет исправлено. Сейчас при смене инструмента не то что OnDestroy не вызывается, а происходит полная инициализация индикатора заново, т.е. выполняется с тела фала. Это легко можно проверить сделав инициализацию лог файла с отметкой времени в теле скрипта индикатора. И по традиции, при добавлении индикатора на график а также иногда и при смене инструмента, это происходит два раза, первый раз без вызовов Init, второй раз уже с ним. Поэтому лог файл определенный в теле, закроется как мусор, а первый холостой вызов даст еще и холостое создание лог файла.

Спрашивается... Зачем? Почему так до сих пор? Об этом говорили еще в 2016 году.

По этой причине логи в индикаторах очень часто повреждаются, т.к. не закрываются корректно при смене инструмента на графике. Также при смене инструмента на графике происходит перенумерация ранее выведенных меток и это происходит явно параллельно с выполнением индикатора. Поэтому иногда старые метки уже считываются, а иногда нет. И это приводит к невозможности управлением меток на графике, сводя к ограниченному использованию, запрещающему смену инструмента.

Это-то зачем? Проверено - если в процессе ожидания OnStop возникает ошибка, то скрипт не стартует. Здесь важно учитывать, что когда скрипт останавливается (5 секунд), то main не стоит ничего делать. А также, если остановка происходит когда скрипт выполняет какую-то функцию, работает с окнами, итерирует цикл, то очень вероятно нарваться на ошибку, т.к. начинают высвобождаться объекты, те же окна скрипта. А из кода обращаемся в этот момент - получите ошибку, что объекта нет. В этом плане оборачивать функции в pcall не самая плохая практика.

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

Если уж уделяете столько времени этому вопросу, то, наверно, стоит сделать устойчивый вариант. Ошибка же была о сравнении nil с числом.
А во всех предлагаемых реализациях нет проверок на наличие бара, полученных значений перед арифметикой, перехвата ошибок, чтобы Квик не умирал от потока сообщений об ошибках на графиках с 60 тыс барами и т.д. Даже если отбросить саму реализацию, то это все не рабочие решения.

Возможно. Но подумайте, что к Вам приходят на работу и говорят - сделай мне. Очень надо. А то что кто-то тратит на это время - не важно.

Кажется Вам уже выдали множество рекомендаций. Даже если взять код индикатора от ARQA, что Вы сами нашли, то там еще проще - убрать вывод не нужных линий. Собственно, как нам говорят со всех углов, ИИ должен с этим справится на раз. Deepseek Вам помощь, если другие не доступы - и проведете с пользой время в выходные.

Ошибка заключается в том, что если график содержит дырку, т.е. нет бара в отсечку времени, то H и L выдадут nil.
А nil нельзя сравнивать с числом. Поэтому необходимо проверять, что вернули H и L. И если это nil, то пропускать такое, переходя к следующему бару.

Ну и конечно, данный код далек от оптимального - постоянно бегать на 26 бар назад, получая значения, которые только что уже получали - так себе идея. Но ИИ он же скоро заменит всех программистов, веселое время настанет...

Это уже сложнее, т.к. если график дырявый, то необходимы проверки. Советую Вам все же погрузится в тему или пойти простым путем. Время - это самое ценное, что есть.

   local max_high = High(index - kijun_period + 1)
  local min_low = Low(index - kijun_period + 1)

Вот строки. Вместо High и Low, H и L

Ну ошибка же очевидна - В Квике нет методов High и Low, есть H и L.Открываете любой, так всеми рекламируемый ИИ, и просите исправить. С такой простой задачей он справится. Хотя терминал Квик для него, конечно, совсем экзотика.

Не проще ли сделать цвет линий встроенного индикатора = цвету фона окна и сдвинуть бары выше индикатора, чтобы линии не были видны на барах.

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

И самое веселое в современном vibe программировании - запускаешь такой скрипт, а он висит. Нет обработок прерывания, как понять висит он или ждет ответа сервера, что вообще происходит сейчас с ним - вывода индикаторов загрузки ведь нет.
Т.е. очевидные вещи, которые не надо говорить при постановке задачи он не делает.

И даже в этом простом коде ошибка - код обработки файла конфигурации не соответствует структуре json.

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

Просто к слову - Вам похоже просто нравится процесс, а не результат. У многих программистов есть такая уязвимость. По идее, необходим результат, даже если он иногда не выглядит красиво, но работает - это лучше, чем постоянное переписывание.

Это и было сказано: рыночная заявка - это просто смещенная от текущей цены к границам текущего клиринга. Что не сказано в документации - изменение ГО при удалении от цены последнего клиринга. Чем дальше - тем больше.
Что приводит к неявному ответу от брокера о нехватке средств у любителей торговать на грани обеспечения. Нажимают кнопку в стакане "купить по рынку" - ответ: не хватает средств для покупки по цене (граница).
Вводишь руками цену, скажет на 100 пунктов от текущей - и магически уже денег хватает. Как же так - ошибка терминала, явно. Поэтому на срочном рынке нет заявок по рынку - есть ордера по указанной цене, и брокер проверит наличие средств именно для указанной цены, т.к. есть ненулевой шанс, что когда заявка дойдет до биржи, именно по этой цене она и исполнится.

Вы определитесь уже - хотите исполнения ордера, сдвигаете цену и платите комиссию. Хотите экономить - читаете лучшие цены (для этого не надо сканировать стакан) и ставите в спред, ожидая исполнения. Если цена убегает, то придется реализовать алгоритм, чтобы догнать цену или отменить вход. Также можно реализовать порционное исполнение. Либо, действительно читаете стакан и понимаете на сколько пройдет цена при исполнении вашего ордера, оцениваете результат и принимает решение. На некоторых инструментах только так и можно войти.

Алгоритмическая торговля - это именно про это: алгоритм входа. Никто кроме Вас не знает какая ваша цель, какой объем и т.д. Алгоритм входа для 1-ого контракта существенно отличается от такового для 1000 контрактов, даже для 100 на многих инструментах.

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

Это Вам решать, понимая, что чем дальше цена, тем больше ГО. ГО по факту будет по цене исполнения, но брокер проверит наличие средств именно по цене ордера.
Ну и учитывая ликивдность инструмента, для кого-то отступ 100 шагов - достаточно, а для другого 500 и более.

Это ждать не стоит, т.к. данная разработка тянет за собой новые признаки баров. Необходимо же понимать, что это бар выходного, праздничного и других типов дней. Т.е. еще нужен календарь - а это уже не так просто, как кажется, особенно в данной географии.

Тем более, что кто-то скажет - а давайте еще уберем аномальные дни, они тоже портят статистику. Так что это вопрос субъективный. Каждый сам решает как отсекать хвосты.

На срочной секции нет рыночных ордеров. Можно только устанавливать ордера внутри ценовых границы последнего клиринга. Причина проста - сумма ГО зависит от цены.
Поэтому устанавливая ордер далеко от цены клиринга, ГО возрастает и существенно.

Вывел скриптом, используя метод AddLabel, указав путь к файлу с расширением png

Большая просьба не исправлять данное поведение, т.к. оно как раз ожидаемо в 2025 году.

Видимо, поддержка устранилась. Впрочем, если это случайная ошибка, то просьба НЕ устранять её. Наконец-то можно использовать нормальные иконки на графике.
Еще бы ввели параметр установки модификаторов шрифта: жирный наклонный для методов AddLabel, SetLabelParams - было бы вообще хорошо.
А то при вводе метки руками это есть, а из кода нельзя.

Случайно вывел картинку в метку в формате png и она вывелась. Что-то изменилось в последних версиях? Раннее, да и сейчас руками на график, только bmp.