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

Вот, вспомнил про это решение. Не пробовал сам, но в основе там socket

https://github.com/cia76/QuikPy.git

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

Так поэтому в Квике так и транслируется. Не нравится - считай сам.

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

Что же касается стоимости, то вот купили Вы 5 штук по цене X, потом еще 3 по цене Y, потом продали 2 по цене Z. Какая стоимость приобретения?
Т.к. торгуете не только Вы, то приняты соглашения о методике расчета.

В таблицах и хранится уже рассчитанное значение.

Вы может узнать цену, рассчитанную брокером методом ФИФО. Будут ли она близка к той, что Вы хотите получить - это вопрос.

Но получить можете, сделав запрос к таблицам

futures_client_holding для FORTS
depo_limits для фондовой секции.

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

Правильно. Lua умеет писать (читать) в существующий "именованый файл". Поэтому на другой стороне его надо создать. Т.е. нужен сервер (служба), обслуживающий каналы. Вот его и надо на стороне питона делать

named pipes Lua поддерживает "прямо из коробки"

А python - это же такая "помойка". Неужели нет готовой библиотеки сервера named pipes? Поиск выдает тонны вариантов.

named pipes, socket

методика print debug вам в помощь.

Для тестирования кода, лучше его тестировать, а не отлаживать.

При срабатывании стоп ордера происходит отправка транзакции сервером брокера. В случае успеха отправки (может не пройти), в стоп ордере, точнее в таблице stop_orders для записи вашего ордера, будет заполнено поле linked_order. Это и есть тот номер лимитного ордера, который отправлен по факту активации стоп ордера. По нему и ищите, фильтруйте. Правда, как и всегда при клиент-серверном взаимодействии, событие смены статуса стоп ордера и событие заполнения linked_order, и появление его в таблице orders, не мгновенные. И необходимо организовать методы ожидания.

Подниму..

Вроде работало, не следил. Но теперь в 9-ой версии не работает.

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

Да, никто не мешает самому организовать счетчик при добавлении и удалении элемента.

В Lua массивы начинают свою нумерацию от 1. Если будет дырка, то оператор # не вернет корректно значение.

Победить - создать метатаблицу, с переопределенным метаметодом  __len

Так она и так выводится если код индикатора открыт.
Впрочем, можно обернуть текст функции OnCalculate (или исполняемой функции) в pcall. И выводить в лог или сообщения текст ошибки. Только стоит сделать кеш ошибок, чтобы не выводить одну и ту же на каждом баре, а то терминал "умирает" на длинных графиках, выводя в три прохода все эти сообщения.

Это при летной погоде. Надеяться на такие времена всегда - плохая затея. Мой наблюдаемый рекорд от отправки транзакции до появления ордера - 10 минут.

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

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

Советую последовательно анализировать.

Для начала уберите обработку очереди и просто в каждом колбеке выводите сообщение, что пришел такой колбек. Функция main будет cодержать только sleep(10), например.



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

И, главное, измените в функции ProcessingCallbakc sleep(3000) на sleep(10). А лучше вообще убрать. Я не представляю что необходимо выполнять три секунды на каждый колбек.

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

И очень странная работа с временем. Если необходимо получить разницу времени, то у Вас есть unix-time, простое арифметическое действие даст разницу в секундах.
Также время есть и в параметре alltrade - время прошедшей сделки. И да, в этом колбеке выполнять что-то сложное - очень плохо.

Если это именно массив, то помогут функции table.insert и table.remove

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

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

То что время серверной части не связано с временем биржи - это понятно. А вот если есть сильная рассинхронизация, то это повод что-то сделать.

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

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

Ищите сериализация данных lua и сразу найдете. На этом форуме была не одна тема с таким вопросом и даже примеры кода.

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

Я  могу понять, что это проблема брокера (Сбербанк), но с какой стати  время сделки в будущем относительно времени сервера брокера и времени  пакета?
Т.е. я понимаю, что время сделки просто транслирует биржа, но  серверная часть должна же не просто транслировать, но и как-то  контролировать, что она транслирует.

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

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

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

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

Это почему она не выполнима...

Решается она в виде очереди обработки, раз скорость не так важна. Оставим в стороне вопрос самого этого анализа.

Создаете очередь задач. Очередь - массив. Задача - объект, содержащий методы подписки, анализа отписки.
Далее в цикле начинаете обрабатывать, например по 10 за раз. Если в какой-то момент не происходит подписка, то просто переключаетесь на следующую еще не выполненную задачу. И так пока очередь не опустеет.
Можете обрабатывать простым циклом, можете корутинами - как угодно.

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

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

Предположу, что Вы хотите получить данные из Таблицы текущих торгов, т.к. не описываете какую задачу решаете.
Если так, то это не стоит делать через CreateDataSource.
Проще и быстрее это сделать через функцию getParamEx  http://luaq.ru/getParamEx.html

А CreateDataSource используйте если необходимо "упаковать" данные в свечи, бары.

Для срочного рынка и для фондового рынка используются разные счета.
Если Вы указываете класс фондовой секции TQBR, то и ACCOUNT укажите для нее.Он вряд ли будет начинаться с SPBFUT, т.к. это явно срочный рынок.

Нет, математики их не заменят. Но когда программист не знает элементарную математику, это гораздо хуже, если он не знает Git. Тем более, что сейчас Git, Docker, Cuber. А через несколько лет скажут что так не модно. Одно то, что сейчас почему-то все решили, что приложение - это браузер и больше ничего не надо, уже вызывает отторжение.

Сюр. Потому как есть алгоритмист, который пишет код, выполняющий то, что могу понять несколько людей на планете. Кто проверять то будет?

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

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