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

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

Представьте, что Вы в начале 90-ых, когда почти все писалось синхронно. Задачи же решались.

Потому что так делать нельзя. Любой блокирующий цикл - это зло.

OnTransReply - это колбек, ответ на отправку транзакции. Это не результат, а все лишь ответ. Он нужен чтобы прочитать ошибку отправки, чтобы не ждать ордер далее, т.к. он уже не появится. Все. В этом плане - это единственный колбек, который не вызывает вопросов.
Поэтому если отправили транзакцию на ордер, то результат - это не колбек OnTransReply, а появление записи по этому ордеру в таблице ордеров. Колбек же OnOrder - это уже следствие появления этой записи, а не наоборот. Любители обработки колбеков вынуждены решать вопросы с их приходом: гарантированность, последовательность, многократный приход, пропуск колбека за время простоя.
Т.е. если Вы решили их использовать, то сначала решите все эти вопросы на бумаге, потом уже в коде.

И подход решения этих проблем не связан с асинхронность. Я подозреваю, что Вы за этим термином понимаете просто "непоследовательность". Но это не решает вопрос, тем более, если пишите скрипт для одного инструмента.
Вот когда их много, тогда уже необходимо задумываться о разбивке одной задачи на подзадачи. Например, установить 100 ордеров при старте торговой сессии.

Задача сведется к подзадачам:

- Отправить транзакцию, с учетом лимита на число транзакций в секунду.

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

- Если это ордер с ожиданием сделок (рыночный), то если есть флаг исполнения ордера ожидать сделки по ордеру до исполнения количества. Но можно и не ждать, если алгоритм позволяет игнорировать это.

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

-- и т.д.

Т.о. выполнение задачи может быть долгим, но смысл разбиения в том, чтобы пока одна подзадача ждет результат (ждет не в блокирующем цикле), другая начала выполнение. И этот подход - это просто оптимизация. Как Вы это будете решать - дело ваше. Можете ждать колбек, может сами сканировать флаги, таблицы на новые записи.

Если вернуться к "Ожидание ответа в цикле main приводит к проблеме - зависанию", то решение - это по приходу колбека OnTransReply записать в некую таблицу результат по номеру транзакции. А уже подзадача проверки просто проверит в этой таблице на наличие записи. И сделает она это тогда, когда к этой подзадаче вернетесь, т.е. никакого ожидания с циклом. Тем более, что совершенно не понятно какое время ожидания указать. Много видел примеров с ожиданием 30 секунд. Всегда было интересно откуда эта цифра, а почему не 45? А если ордер пришел раньше ответа транзакции, то и проверка будет уже не особо нужна.

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

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

OnTransReply может не вернуть номер ордера. Более того, он может прийти после первого OnOrder.

Так что он нужен только для проверки ошибка транзакции. Для получения номера ордера необходимо обращаться к таблице ордеров по номер транзакции.

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

Ну и главное - колбек дело хорошее, но он не гарантирован.

Ожидания - это просто проверка флагов. Например, ожидание появления ордера в таблице ордеров - это проверка, что пока еще ордер на найден. А если не найден, то ищем. нашли - переходим к следующему шагу.
Пока не найден - остаемся в этом же состоянии.

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

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

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

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

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

local function check_chng(ctx, cur)
   if (cur or 0) <= 0 then return end
   if (ctx.base_price or 0) == 0 then return end
   local drop = (cur - ctx.base_price) / ctx.base_price
   if drop <= -ctx.drop_trigger then
       return drop
   end
   if drop >= ctx.drop_trigger then
       return drop
   end
end


local function process_chng(ctx)
   local cur   = tonumber(getParamEx(ctx.class, ctx.sec, "LAST").param_value)
   if (cur or 0) <= 0 then return end
   local drop  = check_chng(ctx, cur)
   if drop < 0 then
       log(string.format("[%s] v Падение %.2f%% > Покупка", ctx.sec, drop * 100))
       cur = fit(cur, ctx.step, ctx.scale)
       send_order(ctx.class, ctx.sec, "B", cur)
       ctx.entry = cur
       return true
   end
end


local function process_close(ctx)
   if (ctx.entry or 0) == 0 then return end
   local now = tonumber(getParamEx(ctx.class, ctx.sec, "LAST").param_value)
   if (now or 0) <= 0 then return end
   local change = (now - ctx.entry) / ctx.entry
   if change >= ctx.take_profit then
       log(string.format("[%s]  Тейк +%.2f%% > Продажа", ctx.sec, change * 100))
       now = fit(now, ctx.step, ctx.scale)
       send_order(ctx.class, ctx.sec, "S", now)
       ctx.base_price = now
       return true
   elseif change <= -stop_loss then
       log(string.format("[%s] Стоп %.2f%% > Продажа", ctx.sec, change * 100))
       now = fit(now, ctx.step, ctx.scale)
       send_order(ctx.class, ctx.sec, "S", now)
       ctx.base_price = now
       return true
   end
end


local function strategy(class, sec)


   log(string.format("[%s] v Старт стратегии", sec))


   local ctx = {
       sec             = sec,
       class           = class,
       step            = tonumber(getParamEx(class, sec, "sec_price_step").param_value),
       scale           = tonumber(getParamEx(class, sec, "sec_scale").param_value),
       drop_trigger    = drop_trigger,
       base_price      = nil,
       entry           = nil,
       take_profit     = nil
   }


   local step = 1


   local steps = {}


   steps[1] = function()
       local price = tonumber(getParamEx(class, sec, "LAST").param_value)
       if not price or price <= 0 then
           return
       end
       if not ctx.base_price then
           ctx.base_price = price
           log(string.format("[%s] Базовая цена: %.2f", sec, price))
           step = step + 1
       end
   end


   steps[2] = function()
       if not ctx.base_price then
           step = step - 1
           return
       end
       if process_chng(ctx) then
           step = step + 1
       end
   end


   steps[3] = function()
       if process_close(ctx) then
           log(string.format("[%s] Позиция закрыта, возвращаемся к ожиданию.", ctx.sec))
           step = step - 1
       end
   end


   return function()


       if not steps[step] then
           log(string.format("[%s] x Стратегия завершена", sec))
           return 0
       end


       steps[step]()


   end
end

Такое запускать только с надписью - "на свой страх и риск, понимая, что вероятность потери 99.5%"

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

Контроль текущей цены необходимо организовывать сложнее и аккуратнее, т.к. многие брокеры в период клиринга, транслируют цену 0.
А т.к. я не вижу вообще никакого контроля статуса сессии, то можно предположить, что он где-то есть. Но очень вероятна ситуация, когда статус сессии уже "открыта", а текущая цена еще 0 - по причине, например, что ещё не прошла ни одна сделка, просто не пришли еще пакеты с данными о ценах. Впрочем, т.к. в этом примере разрешены только положительные цены, то эта проблема нивелируется. Но для инструментов с отрицательными ценами (и с нулевыми) - это важно.

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

Далее, что еще более настораживает - это как организованы сделки. Почему-то отправка транзакции приравнивается к сделке. При этом транзакция лимитная, что никак не гарантирует исполнение. Она может быть отвергнута, может не исполнится, цена банально убежит от неё. Также, если за время отправки транзакции, цена ушла от цены внутрь, то ордер исполнится не по цене отправки. А в примере нет контроля сделок по ордеру, т.е. нет реальной цены исполнения. Также стоит учитывать, что исполнение транзакций может быть долгим. Отправили транзакцию, а ответ и сам ордер появились через минуты. За это время цена сходит десять раз туда и обратно. Т.е. организация работы с транзакциями должна быть транзакционной. Собственно поэтому она так и называется. Да и любое взаимодействие клиент-сервер должно быть таким: Запрос->ответ->принятие решения.

Это просто что первое бросилось в глаза. Напоминает пакеты для торговли через Web - интерфейс к командам, контроля работы ноль, К реальности малоприменимо.

Я могу понять, что это пример, показывающий работу корутин. Ок. Но к реальной торговле он малоприменим. Как это выглядит - дело вкуса. Как по мне - элегантности здесь нет, т.к. приходится сооружать длинные конструкции с большой вложенностью. Если вложенность кода больше 3-4 (а я здесь вижу аж 8), то уже стоит задуматься, что явно что-то не так.

Ну так в индикаторах замыкания используются не зря. Это позволяет хранить стек между вызовами OnCalculate. Сделки смогут проходит раз в час. И вызовы будут помнить все, что было час назад. И не надо городить глобальных переменных, ничего передавать не надо (в этом плане примеры от ARQA некорректны, т.к. передают каждый раз настройки). Т.е. это конструктор некого алгоритма расчета. Да, это можно реализовать через корутины, а кто-то будет упорно доказывать, что это надо решать через классы, они ведь тоже помнят контекст. Тем более, что целое поколение всем вдалбливали, что ООП - это основа, основ. Но как все в истории повторяется, теперь уже не так активно стали это говорить, и даже больше, ООП - это не очень удачная затея в целом.

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

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

Думаю, что спорить дальше не стоит. Как уже писал, я корутины использую только для своих итераторов (hack-trade, кстати, и есть бесконечный итератор) или если надо пробросить varargs ... на следующий уровень. Более нужды нет.
Любая длительная операция, требующую ожидания неопределенное время, выполняется через очередь задач, построенную на простых функциях, где-то замыканиях.  

Любая процедура, вызванная из main не блокирует QUIK. Любая. Хоть завернутая в корутину, хоть вызванная напрямую, хоть в замыкании.
Также любая процедура сама принимает решение когда выйти из неё. Для этого есть оператор return. В корутине для этого используется yield. return тоже просто возвращает управление в точку вызова процедуры, тоже не останавливая скрипт.

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

Ошибку надо в 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 пунктов от текущей - и магически уже денег хватает. Как же так - ошибка терминала, явно. Поэтому на срочном рынке нет заявок по рынку - есть ордера по указанной цене, и брокер проверит наличие средств именно для указанной цены, т.к. есть ненулевой шанс, что когда заявка дойдет до биржи, именно по этой цене она и исполнится.