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

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

И это удобно, красиво и т.д.

Мне нужен таймер в одной функции, в другой, в третьей и т.д.

Шаблон создания таймера должен быть одинаковый типа

local cf = functon()
end

local t = timer.new(24, cf)

а далее его просто проверять

t:check()

Развели....

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

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

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

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

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

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

Как часто смотреть - постоянно. Если это сделано корректно, то это не вызывает существенных накладных расходов. И смотреть во все необходимые таблицы.
Необходимы сделки - таблица сделок. Необходимы ордера - таблица ордеров. Необходимы данные лимитов по бумагам - таблица depo_limits, куда, собственно, метод getDepoEx и смотрит.
Вы же смотрите в таблицу текущих торгов, и, наверно, постоянно.

Скрипт-то с какой радости "не работал"?

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

А если скрипт временно не работает, то  это не значит, что заявки снимаются (а значит могут быть исполнены). Или Вы предлагаете при каждой остановке скрипта снимать все?

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

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

Если бы в Квике была гарантированная доставка сообщений, как в RabbitMQ, то да. Но раз нет гарантий, то я не очень понимаю, как можно выбирать это для такого рода решений.

Если Вы используете колбеки, то да. Но если скрипт не работал в момент совершения сделки (пропустили колбек), то это не должно приводить к проблемам в работе скрипта.

Что значит отсутствует. Я Ваш код не видел, а свой вижу. И у меня, ленивого, нет никакого желания сидеть за монитором и контролировать. Зачем тогда автоматизация торговли, если все равно сидишь за терминалом. Много других полезных занятий есть. Поэтому скрипт должен все помнить, считать, проверять, корректировать. А если что-то не так, то пришлет оповещение на почту.

Зачем рассказывать про то как скрипты работают месяцами - это само собой разумеется, а как иначе.

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

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

Да currentbal - это необходимо поле.

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

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


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

есть таблица depo_limits
Вы можете простым перебором получить данные, можете отфильтровать SearchItems и уже их перебрать. И скажу, что это будет надежнее.

Зачем Вы сравниваете с true. Это булевый тип. А таблица - это table.

getFuturesLimit(p_firmid, p_account, 0, "SUR") возвращает таблицу. В ней есть поле cbplimit типа number.

Только сейчас обратил внимание.

Формат вызова функции такой getFuturesLimit(STRING firmid, STRING trdaccid, NUMBER limit_type, STRING currcode)                        

первым идет код фирмы, а не код класса. Это же лимиты всей срочной секции, а не одного класса.
А фирма firmid   = SPBFUT000000

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

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

Нет. значение же не true, зачем с ним сравнивать. Зада же посмотреть, что в таблице. 4 - цикла, значит там 4 - записи

Лучше выводить не в сообщения, а в лог файл. Но раз через сообщения, то можно так:

Пройдитесь циклом по таблице futures_client_limits и посмотрите, что там. Чаще всего на этом этапе и находится проблема.

Если речь про параметр "Количество сделок за сегодня", то это данные из таблицы Текущих торгов. Имя параметра  NUMTRADES.

Все зависит от задачи.

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

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

Да, но округление не нужно в данной операции.

Можно так, а можно просто math.modf

Только в скобках, т.к. функция возвращает два значения - целую часть и дробную часть

int_x = (math.modf(a/b))

Вот для примера простой скрипт https://github.com/nick-nh/qlua/tree/master/quantScript

Изначально разбивать не надо. Это же арифметическая операция (правда можно кеширование сделать, если память есть).

цена 127 - это целое(127/10)*10 = 120
цена 127 стала 120, т.е. период квантования = 10. Значит все числа из диапазона 120-129 становятся 120. А значит и их объем будет для числа 120.

А как получить объемы по ценам 123 или 134?
Если у Вас задача суммировать обемы сделок по каждой цене, то тогда это более простая задача - просто суммировать объемы с одной и той же ценой.

t ] {}
....

t[123] = (t[123] or 0) + deal.qty

t[134] = (t[134] or 0) + deal.qty


И получите таблицу со всеми объемами, где ключ - это цена, а значение - это объем.

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

Просто кластиеризуйте ценовой диапазон.

Для примера кластер в 10 рублей.

цена 127 - это целое(127/10)*10 = 120
цена 144 - это 140
цена 142 - это 140

и т.д. Тогда сумма объемов на одинаковых кластерах и даст нужный результат.

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

Загрузка в 12% - это не значит, что одно ядро все занимает. Чтобы однозначно сказать, необходимо открыть монитор ресурсов и посмотреть подробную картину для каждого ядра.

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

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

Статус стоп-заявки - это всего лишь индикатор того в каком состоянии заявка на сервере брокера. Исполнилась - значит исполнилось условие.
Далее идет подача команды на установку лимитного ордера по указанным параметрам. Если команда не пройдет шлюз, то можно проверить это через бит 10 и 11 флагов стоп-заявки.
Если же лимитный ордер был установлен, то у стоп-ордера будет заполнено поле linkedorder Номер заявки в торговои? системе, зарегистрированнои? по наступлению условия стоп-цены.
По нему и можно найти лимитный ордер в таблице orders и проверить уже его статус, предпринять какие-то действия.

       

Вопрос целесообразности подписки на колбек.
Если - это необходимо для получения цены сделки внутри бара, то это не лучшая идея, т.к. этот колбек медленный и будут пропуски.А если это для того, чтобы узнать, что пришел новый бар, то не проще ли запомнить прошлый Size и сравнить с новым. Когда придет тогда и делать что-то. А так колбек будет дергаться много раз, ради одного события.

Состояние заявки можно получить в колбеке OnOrder или найти в таблице ордеров запись по номеру ордера order_num (индекс записи можно запомнить).

Из таблицы сделок можно (а значит и из колбека OnTrade), конечно, но это на каждую сделку придется переходить в таблицу ордеров. Если ордер большой, то это уже может быть накладно.
Колбек OnOrder прямо вернет запись таблицы ордеров.

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

Не очень понятно зачем именно дата торгов, если есть дата время самой сделки datetime.

На демо серверах такое как раз чаще встречается.


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

Правда здесь есть вероятность того, что именно во время проверки это аномальное изменение и случится. Для этого можно организовать счетчик. Т.е. если такое случается больше чем 1 раз проверок, то это подтвержденное изменение. Для примера:
Проверяем 1 - нет изменений. Счетчик 0.
Проверяем 2 - есть изменение. Счетчик 1.
Проверяем 3 - уже нет изменения. Счетчик сбрасывается в 0.

В результате изменение пропущено как ложное. Вот если в течении двух отсчетов изменение сохранится, то есть.

Он не поддерживает кодировку Win1251. Квик же в 2022 только ее понимает...
Правда для ZeroBrane можно скрипт на том же lua для перекодировки при открытия файла настроить. Но это не лучший вариант. Часто файлы потом не открываются вообще.

Очень спорное утверждение. Почему не Vim или Emacs?
Notepad++?, если речь про него, хорош если быстренько открыть водном файле, посмотреть, закрыть.

Установить в настройках кодировку по умолчанию win1251.
Можно только для рабочей зоны, можно доля всех файлов lua. По желанию.

Для примера:

По всей видимости, это был сарказм. Окружение терминала в рамках qlua не предоставляет методов по доступу к окну доступных скриптов lua.

Вариантов два:
-- Разобраться с утечкой памяти. Это будет единственно правильным решением.\
-- Написать некий proxy-метод в библиотеке, который будет приводить к перезапуску основной логики. И дергать его по таймеру уже из скрипта lua или прямо организовать цикличность в запуска в самой библиотеке.

Правда есть еще вариант: написать скрипт, использующий w32.dll. Найти окно доступных скриптов, виртуально нажать кнопки остановки и запуска. Для примера, как это сделано в автологинах.

Если я правильно помню luasql от keplerproject под win32. Возьмите сборку под x64, хотя бы от swerg https://github.com/swerg/qlua-luasql
Либо сами внесите изменения.

И соберите через make или прямо в VC.

Это не мой тест. Я просто запустил вышеприведенный чужой код на чистом луа. И вижу, что я также ничего не вижу.

Странный спор.

Берем тот же скрипт, приводим к универсальному виду:

В чистом lua:

begin: 0.0
end: 0.006, memory: 25.41796875

В Квике 8.13

begin: 1796.016
end: 1796.032, memory: 39.4013671875

В Квике 9.3

begin: 31.48
end: 31.499, memory: 39.4013671875


Да, разница с чистым lua есть, но не сказал бы, что это как-то мешает. Тем более, что накладные расходы при запуске скрипта в окружении терминала есть.

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

Если данные транслируются в ТТТ, то и getParamEx вернет их. Укажите корректный код класса и код инструмента. Можете увидеть их в информационном окне: правая клавиша в строке ТТТ - информация об инструменте.

Ну так

Как уже правильно сказали выше, файл должен быть в бинарном представлении открыт.

Вот отрывок из книги создателя языка:

Lua принимает предкомпилированный код практически везде, где он допускает исходный код. В частности, loadfile и load принимают предкомпилированный код.

Мы можем написать упрощенную версию luac непосредственно на Lua:




Основная функция здесь — это string.dump: она получает функцию Lua и возвращает ее предкомпилированный код как строку, правильно оформленную для ее обратной загрузки в Lua.


Т.к. в Квике теперь две версии lua, то необходимо запускать все в одной версии.

visual stidio code + plugins:
https://marketplace.visualstudio.com/items?itemName=keyring.Lua
https://marketplace.visualstudio.com/items?itemName=sumneko.lua
https://marketplace.visualstudio.com/items?itemName=actboy168.lua-debug
ну и для git  https://marketplace.visualstudio.com/items?itemName=eamodio.gitlens

Или IntelliJ IDEA + EmmyLua

Дело вкуса. Но idea тормоз, особенно при глобальном поиске.

Если версия Квика 7, то там lua 5.1. А вот с ним уже не все так очевидно. Он, действительно, может не переварить номер из 19 символов. Поэтому, собственно, и был переход на lua 5.3. https://forum.quik.ru/forum10/topic5119/
Поэтому обновляйте версию.

Если тип number и предположительно целое, то достаточно такой конструкции

Что же касается получения данных из таблиц Квика, то вызов getItem необходимо свести к минимуму. Один вызов на индекс и запомнить в переменной. Иначе большой расход памяти.

А зачем изменять два раза параметр? Одного раза достаточно. Что касается видеть - то нет. Это либо ошибка, либо разработчики не предполагают изменение вне настроек.
Правда если Вы хотите изменять и в коде и в поле настроек, то это уже другая задача: необходимо как-то "сказать коду", что поле изменено в форме и не изменяй его.

Впрочем, Вы можете решить данную задачу используя две (три) переменные.

Одна - в структуре Settings. Вторая - прошлое используемое значение (чтобы понимать, что в форме его изменили). Ну и третья - рабочая, значение которой берется из прошлых двух.

Если это чисто внутренние данные, то может тогда и не хранить их в Settings.
А если необходимо именно в них, то можно перед выходом из функции Init установить необходимое значение и оно будет использоваться в расчетах.

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

Возможно, но чтобы понять проблему необходимо видеть код  функции inicfg.load.

Хотя, как правило, если нет уверенности, что данные корректны, то стоит проверять значения прежде чем их использовать. Как минимум убедиться что type(updateIni) == 'table'. Но это не решит проблемы загрузки(записи по указанному пути) файла через сеть.

Видимо, все же стоит обратиться на форум для того продукта, где этот скрипт используется. Поиск дает ответ, что это какая-то игра GTA.
Это форум посвящен совсем другому продукту.

Ну так это и есть хеш таблица - интерфейс ассоциативного массива

https://habr.com/ru/company/vk/blog/493642/

Таблицы lua - это хэш таблицы. Точнее весь lua - это операции над таблицами.
Поэтому банально
t[1] = что-то
t[2] = что-то
....

Или

t['что-то'] = вот-это
t['еще'] = другое

Можно даже в качестве индекса другую таблицу указать

tbl = {}
t[tbl] = 'что-то'

Так что как сохранить - это больше вопрос как лучше сохранить в данном случае.