Хоть и говорят, что SearchItems быстрее, но я наблюдал такое поведение: Если таблица для выборки мала, то SearchItems будет предпочтительней. А вот если она большая, скажем таблица обезличенных сделок, то здесь уже не все так очевидно. SearchItems вызывало большую нагрузку, нежели прямой перебор. При этом выборка идет с запоминанием последнего прочитанного индекса, чтобы сузить последующие запросы. Т.е. размер исходной таблицы как-то влиял на результат, хотя, по идее, реализация должна быть тоже простым перебором с вызовом функции фильтрации для каждой строки.
Если просто написать некий цикл на 10 млн. повторений перебора, скажем таблицы из 10 строк, то особой разницы нет. Здесь я бы предпочел SearchItems, т.к. памяти меньше уйдет.
Сначала решил проверить на вашем тестовом контуре в вечений клиринг. Кулено 2 контракта SRU0.
Вот простейший скрипт:
Код
local isRun = true
local logFile
local function log_tostring(...)
local n = select('#', ...)
if n == 1 then
return tostring(select(1, ...))
end
local t = {}
for i = 1, n do
t[#t + 1] = tostring((select(i, ...)))
end
return table.concat(t, " ")
end
local function myLog(...)
if logFile==nil then return end
logFile:write(tostring(os.date("%c",os.time())).." "..log_tostring(...).."\n");
logFile:flush();
end
local function GetFuturesHolding(Sec)
local futures_client_holding = _G.getFuturesHolding(Sec.FIRM_ID, Sec.ACCOUNT, Sec.SEC_CODE, 0)
if futures_client_holding then
return futures_client_holding.totalnet
end
return 0
end
local function GetTotalnet(Sec)
local num = getNumberOf('futures_client_holding')
for i = 0, num - 1 do
local futures_client_holding = getItem('futures_client_holding',i)
if futures_client_holding and futures_client_holding.sec_code == Sec.SEC_CODE and futures_client_holding.trdaccid == Sec.ACCOUNT then
return futures_client_holding.totalnet
end
end
return 0
end
function _G.main()
logFile = io.open(_G.getScriptPath().."\\test_log.txt", "w")
local Sec = {SEC_CODE = 'SRU0', CLASS_CODE = 'SPBFUT', ACCOUNT = 'SPBFUT001nw', FIRM_ID = 'SPBFUT000000'}
local curOpenCount = GetTotalnet(Sec)
while isRun do
local new_count = GetFuturesHolding(Sec)
if new_count ~= curOpenCount then
myLog('----------------------------------------------------------------------------------')
myLog('getFuturesHolding new_count', new_count)
curOpenCount = new_count
for i = 0, _G.getNumberOf('futures_client_holding') - 1 do
local fut_pos = _G.getItem('futures_client_holding', i)
myLog('futures_client_holding', i, 'sec_code', fut_pos.sec_code, 'avrposnprice', fut_pos.avrposnprice, 'totalnet', fut_pos.totalnet)
end
myLog('----------------------------------------------------------------------------------')
end
sleep(100)
end
end
function _G.OnFuturesClientHolding(fut_pos)
myLog('----------------------------------------------------------------------------------')
myLog(' OnFuturesClientHolding ', 'sec_code', fut_pos.sec_code, 'avrposnprice', fut_pos.avrposnprice, 'totalnet', fut_pos.totalnet)
myLog('----------------------------------------------------------------------------------')
end
function _G.OnStop()
isRun = false
myLog("Script Stoped")
if logFile then logFile:close() end
end
function _G.OnClose()
isRun = false
myLog("Script OnClose")
end
А вот, что происходит во время вечернего клиринга. Я так понимаю это технологические изменения позиции. Реальные скрипты не проверяют баланс во время клиринга, но здесь вопрос: а согласованы ли параметры TRADINGSTATUS и CLSTATE с изменением баланса? Т.е. не может ли быть так, что статус клиринга еще не успел обновиться, а баланс через getFuturesHolding обнулился?
Правда также возникает вопрос: а с чего он так скачет туда-обратно? Если вывести позицию в торговую панель стакана, то там стабильно позиция остается правильной.
Собирали сами? У меня стабильно падала после некоторого времени. Надо заново проверить, вдруг починили. Техподдержка Квика так и не ответила, по моему обращению.
Самая главная проблема - это расход памяти. При переборе каждый раз получатся строка таблицы, в которой может быть много полей. Если это делать на каждом цикле алгоритма, то память прямо улетает.
SearchItems возвращает массив индексов отфильтрованных строк. Что само по себе уже меньше по объему, ну и, зачастую, надо просто последний взять, например.
function SQL_Rows(connection, sql_statement)
local cursor = assert(connection:execute (sql_statement))
return function ()
return cursor:fetch()
end
end
Кстати, у Вас библиотека на х64 стабильно работает? Я бросил попытки еще в январе.
На этом форуме вы очень часто просите привести текст скрипта. Но я же написал просто про функцию. Я не могу привести конкретные примеры, т.к. это сообщения от клиентов. Анализ логов явно указывает на то, что эта функция возвращает результат пустой. Я всего лишь обращаю ваше внимание, что такое поведение проявляется в редких случаях перед клирингом. Это происходит на счетах с единой позицией.
Я попробую промоделировать. Правда у меня нет счета с единой позицией. Вам же прогнать unit тесты не составит труда.
На версии 8.х столкнулся на реальных счетах разных брокеров, что функции получения текущих позиций как getFuturesHolding, getDepoEx работают нестабильно. Чаще всего это происходит с getFuturesHolding на едином счете. В течении сессии часто (обычно перед клирингом) функция не возвращает ничего. При этом если перебрать строки прямым итератором, то все нормально находится.
Приходится отказываться от использования функций. Но перебор - это существенный расход памяти и просто медленней.
Я уже давно ушел от редактирования чего либо в колбеках Квика. Есть глобальная очередь сообщений, в колбеке в нее идет только запись информации о событии.
А уже в main идет обработка и очистка. Также реализованы свои колбеки - задача в очередь, когда выполнилась дернул свою функцию. Многопоточность - это опять решать проблемы потоков. Блокировка поможет, но тогда зачем потоки, если блокировать остальные.
Цитата
Старатель написал: Что-то никак не пойму, работа с QLua-таблицей - это синхронные или асинхронные сообщения?Саппорт, можете просветить?
Предположу что синхронный. Квик виснет если сделать бесконечный цикл в колбеке окна.
Вы этот код как реальный пример рабочего кода приводите, либо как некий тестовый пример?
Если просто как пример, что repeat until выполняется всегда хоть один раз пока истинно условие. Т.е., если надо выполнять пока есть лимиты, то это будет условие until asset > 0 У Вас было 5, начинаем выполнять: 4, 3, 2, 1. Все, т.к. на последнем шаге 1 станет 0 и мы выйдем из цикла.
Также и с другими цифровыми порогами. Выполняете пока у вас asset больше. Вы же вычитаете 1 в процессе, значит asset будет уменьшаться.
Если же это рабочий код, то он не предусматривает, что транзакция может не пройти, баланс может обновляться долго, ответ транзакции идет долго. Сервер же далеко, он может быть занят.
Ну раз у Вас нет ошибок при запуске индикатора как скрипта а я его вижу перед глазами в версии > 8.5, то, скорее всего, не подгружается maLib через require('maLib')
Можете заменить загрузку библиотеки такой конструкцией: _G.load = _G.loadfile or _G.load local maLib = load(_G.getWorkingFolder().."\\Luaindicators\\maLib.lua")()
Либо пропишите пути поиска библиотеки через package.path
Что касается priceAvgProfile, то тоже вижу его перед собой. Но возможно, у Вас проблема в данных и надо отловить ошибку. Посмотрю еще на разных бумагах.
Здесь уже и не знаешь что это... Возможно и расход, хотя при закрытии закладки она не высвобождается. Только перезапуск освобождает память.
Выглядит это так: загружаю одну сохраненную закладку с графиками, через секунду виртуальная память резким скачком становится 17 гб. Далее можно закрывать ее, графики - не важно, память уже выделена. Только перезапуск с закрытыми проблемными графиками и таблицами.
Если разработчикам интересно, то я могу выслать одну из проблемных закладок. Что-то бета тест у нас затянулся с 8.x версиями.
Пришлось с нуля установить Квик. Далее последовательно восстанавливал ранее сохраненные закладки. Выявились закладки, которые приводили к такому расходу. Как только загружал их в чистый Квик сразу подскакивал расход на десятки гб. Две из них ожидаемо содержали склейки фьючей. Но одна была с графиком Аэрофлота. Но ее добавление давало 17 гб расхода.
Добавьте файл индикатора в окно доступные скрипты: Сервисы - Lua скрипты. Запустите его. Будет показана ошибка компиляции. Именно она не дает добавить индикатор в список. Файл я посмотрел - он в правильно кодировке.
Также обновил priceAvgProfile. Напомнили, он был не совместим с lua 5.3
Отладчик Вам не поможет, если ошибка спонтанная, т.е. зависящая от данных. Допустим индексация значения nil, ожидая table.
В этом случае Вам проще обернуть критические функции в pcall, перехваченные ошибки записывать в лог. При этом надо обязательно добавить assert на входяшие данные. Если ожидаете таблицу, проверьте что она и пришла. Ждете строку, проверьте, что она есть. Тогда исключение по таким проверкам Вам и дать искомую ошибку.
Это, конечно, похвально написать свой RabbitMQ, но, в результате, получится схема не меньшей сложности. Т.е. мы пишем свой терминал. Он будет собирать события терминала, исполнять команды скриптов и читать их ответы, передавать им поток данных.
При этом мы итак находимся внутри такого окружения... Что мешает написать скрипт исполняющий сразу несколько алгоритмов, по многим инструментам. Будет один скрипт, одно окружение. А колбеки Квика слишком ненадежная конструкция. Проще без них. Хотя, конечно, от части из них отказаться сложно, как, например, OnTransReply.
Медленней чем, что? У меня код с использованием десятка библиотек выполняется с одной итерация цикла где-то за 150-250 мс. При этом 60 мс - это установленная задержка. Вариантов то нет, если надо писать сложный код. Это будут классы, модули, функциоанальный подход и т.д. Иначе будет совсем не разобраться через некоторое время, открыв свой же код.
Это относится не только к скриптам для Квика. Это общая практика программирования.
Цитата
Вызов отдельной функции требует больше времени, чем исполнения кода в основном потоке
А где, собственно, это функция вызывается... Все выполняется в дополнительном потоке Квика - функции main. Функцию можно только упрекать в расходовании памяти на дополнительные локальные переменные, но скорость то тут причем.
А универсальное пишем как раз для того, чтобы писать скрипты быстро и удобно. Иначе код придется писать с нуля каждый раз. А если ошибка, то что, исправлять в каждом файле.
Если Вы скачали файлы с GitHub, то необходимо провести конвертацию файла в кодировку 1251, т.к. на сайте все хранится в UTF-8. Также не забудьте положить рядом файл maLib.lua т.к. индикатор зависит от нее. Впрочем, это видно из кода.
Когда у Вас скрипт на тысячи, десятки тысяч строк, то писать в одном файле это смело. А когда у Вас уже написано много скриптов, то придешь к модулям, т.к. каждый раз писать одно и тоже - это тоже смело. При этом модуль - это не команда dofile в глобальном окружении, а нормальный модуль, подключаемый через require.
Выводить значения надо для каждого бара. Также, обычно, не выводят значения, пока число баров не стало больше чем период расчета (т.к. выборка недостаточна).
Вы можете просто инициализировать переменную в замыкании, отвечающую за результат расчета, и выводить ее всегда. Иначе у Вас могут образовываться дырки в расчете (это и приведет к такой прямой линии), когда бара нет и CandleExist(I,ds) вернет ложь.
В тех ссылках, что я скидывал подробно описана как строить индикатор. Вы сейчас зацепились за какой-то отрывок кода, не понимаю зачем он. Лучше, все же, взять руководство, его же не зря написали.
В данном случае, что-то с логикой. Функция math.fmod - это остаток от деления двух чисел. Раз деление идет на P+1,то результат лежит в диапазоне от 0 до P. Это значение передается как индекс таблицы it. Что далее не ясно, всего когда нет.
Явно что-то с логикой. Вы бы себе алгоритм на любом языке написали, хоть на блок схеме, чтобы понять где проблема.
Код явно не весь. Где функция GetValueEX? Таблица it является upvalue замыкания. А где же она заполняется, кроме первеого индекса? В этом, скорее всего, и есть ошибка, т.к. выполняются арифметические действия с nil.
Lua, на самом деле, простой язык. Если знаком любой другой язык, то он изучается очень быстро.
Определения функции Squeeze не представлено, поэтому сказать, что она делает невозможно. Чтобы получить порядковый номер надо либо организовать итерацию с таким численным праметром от 1 до P или привести саму переменную i к такому виду.
Так: for i = 1, P do MD = MD + (GetValueEX(it[Squeeze(it.l-P+i,P)], VT, ds)) * i end
Или так: for i = it.l-P+1, it.l do MD = MD + (GetValueEX(it[Squeeze(i,P)], VT, ds)) * (i - it.l+P) end
Выложил простой пример отправки почты через консольную программу на С#. Я не знаю язык, но он простой, поэтому просто адаптировал пример, найденный в MSDN. https://github.com/nick-nh/SendEmail
Я предпочитаю именно такой вариант, потому что не надо думать о бинарной совместимости Квика и проблемах библиотек.
nikolz написал: На самом деле посылать письма из квика на смартфон или оповещать через приложение, работающие через интернет, которое установлено на смартфоне - это какой-то мазохизм. --------------------- У вас терминал квика в режиме торгов постоянно включен в интернет и смартфон тоже в интернете. Ну так что же вам мешает передать сообщение по схеме pоint to point, а не гонять письма и сообщения через сторонние сервера? Скорость передачи будет раз в сто выше, а накладные расходы раз в сто меньше. Делал такое, давно это было. -------------------------- Подумайте на досуге.
Почта - это один из самых надежных способов доставки сообщений. Плюс реализация ptp обмена - это переусложнение простой задачи. Тем более, что я не хочу держать лишние аппликации типа мессенджеров на устройствах. А почтовый клиент - есть везде, даже на древней нокиа е61.
И первая строка и вторая. Первая неравномерно обновляется, нет плавной подсветки. Вторая часто замирает. На темной теме все намного плавнее. Вот, для наглядности: https://yadi.sk/i/S-T2kh3s2u59hA
nikolz написал: На первом этапе на вечерней сессии торгуются 25 ликвидных акций из списка индекса МосБиржи, а до конца года в список торгуемых инструментов войдут все акции из индекса МосБиржи (38 акций), а также 50 наиболее ликвидных иностранных акций из американского индекса S&P 500.
Конечно, эта информация известна. Только что она дает? Даже до введения этого режима было такое поведение потока данных. И это не корректно. Просто была возможность обойти эту проблему. Теперь надо придумывать более изощренные "костыли". Только зачем.
Начались торги в вечернюю сессию на фондовой секции. Я уже задавал вопрос про трансляцию времени сессии, но вот сейчас она идет и можно посмотреть на реальный поток данных.
Что мы видим:
Вот утро. Начало торгов. По фьючерсу все ожидаемо и понятно. Есть и времена и статус. По акции я вижу только статус, а время заполнилось только утренним аукционом.
Вот данные пор акции внутри дня. Время утреннего акциона. Это как понимать? Уже сессия к концу идет, а время старое. [INFO 2020-06-23 17:33:32] : SBER TRADINGSTATUS {param_image = "открыта", param_type = "4", param_value = "1.000000", result = "1"} [INFO 2020-06-23 17:33:32] : SBER STARTTIME {param_image = "9:50:00", param_type = "5", param_value = "95000.000000", result = "1"} [INFO 2020-06-23 17:33:32] : SBER ENDTIME {param_image = "9:59:34", param_type = "5", param_value = "95934.000000", result = "1"}
Вечер. По фьючерсам все адекватно, а вот по акциям:
Времена аукциона я еще могу понять. А вот что это такое при старте вечерней сессии уже с трудом. И опять - времена то где? Почему нельзя заполнить времена прямо при подключению к серверу, как это делается для фьючерсов и менять их, если они меняются внутри дня? Поля же есть.
Часть акций торгуется, часть нет. А информации о времени сессии нет. Раньше можно было хотя бы определить константы, когда времена были фиксированными (хоть это было и спорное решение), но сейчас то как.
Старатель, если Вы не можете объяснить свою идею, то это Вам не поможет. Мне без разницы в какой манере Вы отвечаете, просто буду пропускать сообщения. Что, наверно, сделают и представители разработчика.
Т.к. я часто работаю с клиент-серверной архитектурой, то мне сложно понять абстрактные изложения, без объяснения технической составляющей реализации. Общение с сервером - это не тоже самое, что индексировать локальную таблицу. Даже сервер базы данных в локальной сети уже заставит применять другой подход к написанию кода.
Ваша фнкция DS:Чё_Есть_На_Сервере_Брокера() обращается к справочной информации, т.к. Вы просто хотите получить данные о признаке наличия данных, а не их количестве. Эта информация итак приходит вместе со всеми информационными таблицами. Технически, сейчас просто нет информации о наличии баров по каждому интервалу. Есть, допустим, информация о Статусе инструмента, его классе и т.д., а по барам нет. Ваш псевдокод как раз и организует подписку на получение этих данных.
Только вот использование этой функции будет таким же неудобным, т.к. придется писать постоянный вызов этой функции, Вы же не значете когда придет ответ. Это синхронный подход. Он плохо работает.
Также вызникает вопрос: Если CreateDataSource вернул нам объект. т.е. запрос был корректным, инструмент правильный, интервал правильный (сейчас правда не проверяют это, но надеюсь это исправят) - значит бары есть. Если их 0, то что? Не было торгов? Сервер брокера сломался? Вы же не просите тип ошибки: 404 или 204 и д.р.. А я как раз хотел бы видеть коды ответа сервера. А не просто ничего нет на сервере. Если CreateDataSource выполнился, значит информация есть в локальном кеше. Как же она к нам попала, если на сервер ничего нет.
Цитата
честный ответ: если сервер ещё ничё не прислал, то и ответ будет буквально "ничё", nil. Ежели с сервера уже получили ответ, то там будет признак наличия/отсутствия свечей на сервере.
Если сервер ничего не прислал, то это не значит, что там ничего нет - это значит, что идет процесс передачи, обработка запроса. А если с сервера получили ответ, что там не свечей, то такое может быть только если их физически нет (первый день торгов) или ошибка базы данных или что-то еще. Так вот и надо различать эти состояния. В одном случае это не помешает мне анализировать инструмент, а в другом я просто выкину исключение, чтобы не возвращаться более к нему. А в третьем, я увижу статус: в процессе и буду ждать колбек о приходе данных, не дергая постоянно функцию.
Старатель, если я правильно понимаю Ваше пожелание, то это прямой серверный вызов. Но это принесет много проблем. Сейчас у нас вызовы синхронный, мы получаем ответ сразу, т.к. берем это из кеша терминала. Ответ приходит после проверок на клиенте. Ваше же предложение просто не поддерживается сейчас языком от слова совсем. Если попробовать использовать синхронный вызов к серверу, то это пусть в никуда, т.к. пока не пришел ответ, что делать коду?
Вы ввели команду x = ServerX()
И что? Все, код встал? Ответ же не ясно когда придет. Поэтому такие вызовы делают асинхронными. А у нас их нет. Это потребует разработки функциональнсти типа async-await, promice и т.д.
Потом, если разобрать запрос CreateDataSource, то это же простой заказ данных, не получение. Он возвращает nil, если не прошла проверка на входящие параметры. Т.е. нет такого потока и нечего ждать. Size - это число баров. Оно тоже не может быть nil, т.к. если их нет, то это 0. А что такое nil баров, если проверка на корректность потока прошла? Нам остается только определить ситуации когда есть некая ошибка получения данных по заказанному потоку данных и метод, определяющий, что мы еще в процессе передачи исторических данных, т.к. их может быть много.
Я как раз говорю про методы определения состояния потока, а не прямое обращение к серверу. Это, на самом деле, не самое лучшее решение делить контексты вызовов. Ваш код превратится в кошмар. Придется использовать аннтотации - это сервер, это клиент. Здесь ждать, здесь сразу.
Конечно было бы хорошо иметь возможность задать что-то типа такого: CreateDataSource(class, code, i, callBack)
где callBack - это ссылка на функцию или лямбда. Тогда такой вызов станет асинхронным и получив ответ, принимать какие-то решения. Это же относится и к остальным "как-бы" серверным вызовам, в частности отправка транзакции. Я бы предпочел получить гарантированный асинхронный ответ вызова, чем искать его в потоке смешанных ответов.
Текущая схема колбеков просто не дает их использовать, если нужна гарантия получения ответа.
Я как-то писал индикатор показа линий большего таймфрейма на меньшем https://github.com/nick-nh/qlua/blob/master/bigPeriodLines.lua Вы напомнили мне про него своей темой. Обновил его для совместимости с lua 5.3. Возможно частично подойдет Вам для решения задачи.
Вот для примера сколько идет заказ данных интервала минута
[Fri Jun 19 11:00:35 2020 4938.594] SiU0 SPBFUT size 0 [Fri Jun 19 11:00:35 2020 4938.634] SiU0 SPBFUT size 0 [Fri Jun 19 11:00:35 2020 4938.655] SiU0 SPBFUT size 0 [Fri Jun 19 11:00:35 2020 4938.676] SiU0 SPBFUT size 0 [Fri Jun 19 11:00:35 2020 4938.697] SiU0 SPBFUT size 0 [Fri Jun 19 11:00:35 2020 4938.718] SiU0 SPBFUT size 0 [Fri Jun 19 11:00:35 2020 4938.739] SiU0 SPBFUT size 0 [Fri Jun 19 11:00:35 2020 4938.76] SiU0 SPBFUT size 65596 [Fri Jun 19 11:00:35 2020 4938.781] SiU0 SPBFUT size 65596 [Fri Jun 19 11:00:35 2020 4938.802] SiU0 SPBFUT size 65596
т.е. 200 мс я имею 0 в качестве размера, а потом сразу резко весь размер. Можно, конечно, предположить, что если число отлично от 0, то все загружено, но в марте когда была сильная волатильность и сервера висели, получались и промежуточные числа.
С тиками еще сложнее - их много пройдет после заказа данных и до "окончания" загрузки.
В связи с этим хотелось бы понять: первый size отличный от 0 - это что? Как его интерпретировать?
Вот простейший код. Он уже приводился в этой ветке. Добавил вывод анимации для более наглядного представления.
При использовании темной темы все более менее плавно. Светлая - замирания окна таблицы.
Причем видно, что это происходит при подсвечивании ячейки таблицы.
Относительно помогает сгладить замирания - увеличение периода подсветки до 1000 мс.
Но в темной теме все плавно для 500 мс и 60 мс задержки основного цикла.
Код
local sec_code = 'SRU0'
local class_code = 'SPBFUT'
local sleep = _G.sleep
local isRun = true
local t_id = nil
local SeaGreen = 12713921 -- RGB(193, 255, 193) нежно-зеленый
local RosyBrown = 12698111 -- RGB(255, 193, 193) нежно-розовый
local getParamEx = _G.getParamEx
local GetCell = _G.GetCell
local Highlight = _G.Highlight
local SetCell = _G.SetCell
local ds
function _G.OnParam(class, sec)
if t_id and sec == sec_code and class == class_code then
local last_price = tonumber(getParamEx(class_code, sec_code, 'LAST').param_value) or 0
local lp = GetCell(t_id, 1, 0).value or last_price
if lp < last_price then
Highlight(t_id, 1, 0, SeaGreen, 0, 1000)
elseif lp > last_price then
Highlight(t_id, 1, 0, RosyBrown, 0, 1000)
end
SetCell(t_id, 1, 0, tostring(last_price), last_price)
end
end
local function CreateTable()
t_id = _G.AllocTable()
_G.AddColumn(t_id, 0, "price", true, _G.QTABLE_DOUBLE_TYPE, 15)
_G.CreateWindow(t_id)
_G.SetWindowPos(t_id, 90, 120, 170, 100)
_G.InsertRow(t_id, 1)
_G.InsertRow(t_id, 2)
end
local function Animate()
local animation_symbol = "|"
local curSymbol = 0
local maxSymbols = 20
return function()
curSymbol = curSymbol + 1
curSymbol = curSymbol>maxSymbols and 1 or curSymbol
return string.rep(animation_symbol,curSymbol)
end
end
function event_callback(_, msg)
if (msg == _G.QTABLE_CLOSE) then
isRun = false
end
end
function _G.OnInit()
CreateTable()
_G.SetTableNotificationCallback(t_id, event_callback)
end
function _G.main()
ds = _G.CreateDataSource(class_code, sec_code, 1)
isRun = ds ~= nil
if ds then
ds:SetEmptyCallback()
end
local GetNextAnimationSymbol = Animate()
while isRun and ds do
SetCell(t_id, 2, 0, GetNextAnimationSymbol(), 0)
sleep(60)
end
end
function _G.OnStop()
isRun = false
ds:Close()
ds = nil
if t_id and not _G.IsWindowClosed(t_id) then
_G.DestroyTable(t_id)
end
end
Sergey Gorokhov написал: Если же говорить про архивные данные, то Вы и так уже сейчас можете определить что "все архивные данные загружены" без каких-либо доработок
Это какая методика мне позволит узнать, что все исторические данные загружены? При заказе размер 0. И сколько в итоге мы не знаем, пока не загрузим.
Мы же сейчас говорим не про аналоговое телевидение, а про асинхронную передачу дискретного потока данных. В момент заказа данных есть историчесике данные, это все что есть до этого момента времени. Это срез данных на момент времени. Он один. Мы начинаем отдавать этот массив. Да, параллельно появляются новые данные. Но в какой-то момент времени мы будем в окрестности границы множества, и в этот момент вы отдаете остаток исторических данных и пришедшее новое (с момента начала передачи) до конца выборки всего массива данных. Опять, это момент, срез времени, с точки зрения наблюдателя он один. Пока не посмотрим на новые данные для наблюдателя их еще нет.
Если Вы говорите, что именно в этот момент пришли новые данных и как-бы данные уже не все, то это как раз не проблема, т.к. это будет уже колбек по новым данным, истрия уже загружена.
Т.е. невозможно дать сигнал когда выбрана вся выборка? Вот у меня на сервере есть массив. Я отдаю его прциями через канал связи. В последней порции идет флаг, что это последний пакет. Терминал видит оный и после загрузки этого пакета дает колбек. У вас же есть колбек для получения новых данных по барам - это он и есть, т.к. он вызывается для каждой последней сделки, читай порции данных. Только в случае отсутвия сделок у нас колбека нет и приходится гадать получены ли все пакеты.
В вашем примере - это не будет проблема, т.к. появление нового бара всего лишь дать мне результат Size() = 101, а не 100. Но я уверен, что это уже послений бар. Его номер не столь важен, пока не все получено.