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

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

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

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

Свою позицию Вы знаете. Размер лота и цену последней сделки получите из потока данных (условно Таблицы текущих торгов) через метод getParamEx.
В документации все методы qlua описаны.

Формализуйте термин "Реальная цена контракта". Есть цена в момент времени в валюте цены контракта. Если речь про это. В чем проблема ее получить?

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

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

Я предпочитаю их задавать для целей контроля.

Думаю что просто опечатка, возможно здесь
CLASSCODE = ord.cllas_code

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

Это обычный вариант, если использовать колбеки. Только я писал о проблеме, если колбек пропущен по любой причине.

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

Так что как модель, пример - ок. Но оставлять его без присмотра - это надо быть смелым.

У нас так мало инструментов, что самое простое - это сделать файл с данными и просто прочитать его при старте. Лучше даже сделать его в формате таблицы, чтобы загружать одной командой loadfile.

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

Впрочем, видимо, не нравится поле Класс. В пишется код класса, а не имя.

Есть закон - появление ошибок в коде в несколько раз быстрее, чем их исправление.

Это, судя по всему, ошибки последних релизов 10.* https://forum.quik.ru/forum10/topic8157/

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

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

Наверно, имеет смысл перенести обсуждение на другую площадку - Smart-Lab, MFD. Вы там найдете много участников по столь животрепещущей теме. Здесь, все же, форум по разработке, коду. Поиск Граалей - это о другом.

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

Впрочем, это правило применимо и для любой области знаний. Хотя теперь у нас все сами себе режиссеры.

Просто к слову: у рынка нет таких свойств как перекупленность и перепроданность. Ну и волатильность - это более сложное понятие.

Возможно lua 5.3. На версиях терминала 8.*, под lua5.3 вылетала часто. Хотя это может быть и ошибка работы с объектами, нарушения синхронизации доступа в потоках.

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


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

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

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

score - таблица, а не примитивный тип. Сортируется таблица по полям примитивных типов.

Если задача склеить их в строку и если их очень много, то лучше это делать через промежуточную таблицу, записав в нее ключи. А потом вызвать table.concat

Значение не просили, только ключи. Зачем тратить память на локальные переменные.

for key in pairs(T) do
end

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

Ну мой первый терминал 1842... У меня выложено много, т.к. я тоже знакомился с qlua в терминале. И когда я начинал было мало информации. Т.к. особой ценности все это не несет, то и скрывать нечего. Много кривого кода - тоже думал "все просто же". А потом разные брокеры заставили усвоить, что все не так очевидно. И первое что было "выкинуто" - это колбеки.

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

Здесь проблема в том, что достаточно одного сбоя, чтобы привести к существенным потерям, многократно перекрывающим все прошлые успехи.
Собственно все это обсуждение об этом, на самом деле. Я придерживаюсь принципа, что если есть шанс получить критическую проблему даже 0.1%, то значит этим надо заниматься. Это как в авионике, софте медицинского оборудования - нет места для проблем. Поэтому и выбираются подходы, может не самые красивые, удобные, модные, но снижающие риски.

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

Что значит не запущен.

Напишите скрипт из одной строки

message(getScriptPath())

и выполните его в терминале. Никакого OnInit нет.

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

Кстати по по поводу пути. У меня путь определяется так:
local path      = (_G.getScriptPath and _G.getScriptPath() or (arg[0]:gsub('[^\\/]*$', '', 1):gsub('\\', '/'))) or ''
if path == '' then path = './' end

И это не в какой-то функции, а в самом начале скрипта. И как-то не вижу я проблем, чтобы getScriptPath не работал. Так что да, особого смысла в OnInit не вижу. Хотя, когда разбирался с окружением qlua, тоже использовал.

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

Да, dll для обмена данных. Можно выкинуть.

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

И если хотите обсудить конкретное решение, то лучше для этого использовать ветку Discussions GitHub (правда если есть профиль).

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

Вот, я когда-то давно писал макет такого скрипта по просьбе - https://github.com/nick-nh/qlua/tree/master/quantScript

А что смущает? При старте внутри торговой сессии уже есть накопленные данные. Их надо перебрать (если надо). Для этого будет написан код.
Далее появляются новые записи. Например, через интервал 1 сек., появилось 10-100 записей. Берем и читаем их сразу за один проход, используя тот же, уже написанный, код И это без всяких колбеков.

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

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

Поэтому - читаете таблицу, хоть всю подряд (но это в момент расход памяти), либо через специальную функцию SearchItems интерфейса qlua. И делайте это в потоке main, тогда это не будет нагружать поток терминала.Например, простой скрипт записи всех сделок в файл, читая первоначальную порцию накопленных данных, делает это очень быстро: 100 тыс. записей пишется за секунду - две.

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

Body скрипта выполняется в потоке терминала. Так что служебные переменные вполне себе инициализируются там.

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

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

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

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

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

Это же сигнатура функции. Т.е. надо передать код класса (строка), код бумаги (строка), имя получаемого параметра (строка). Возвращается таблица с данными или nil, в случае неудачи.

Читайте документацию по методам. Можно онлайн - https://luaq.ru/getParamEx.html

Посмотрите внимательно на формат вызова функций
TABLE getPortfolioInfo (STRING firm_id, STRING client_code)                        
TABLE getParamEx (STRING class_code, STRING sec_code, STRING param_name)                        

Нет варианта с строковым параметром "all"

Lua 5.3 introduces the integer subtype, which uses 64-bit integer by default.

From Lua 5.3 reference manual

The type number uses two internal representations, one called  integer and the other called float. Lua has explicit rules about when  each representation is used, but it also converts between them  automatically as needed (see §3.4.3). Therefore, the programmer may  choose to mostly ignore the difference between integers and floats or to  assume complete control over the representation of each number.  Standard Lua uses 64-bit integers and double-precision (64-bit) floats, but you can also compile Lua so that it uses 32-bit integers and/or  single-precision (32-bit) floats. The option with 32 bits for both  integers and floats is particularly attractive for small machines and  embedded systems. (See macro LUA_32BITS in file luaconf.h.)

Раз введен новый подтип, то возвращаемые данные будут integer, для примера:

print(math.type(1)) -- integer
print(math.type(1.0)) -- float

А раз так, то нет необходимости преобразовывать данные. Впрочем, наверно, Вы все это знаете.

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

Что касается покупок, не делайте предположений. Весь софт куплен. Пресловутый Photoshop покупать нет нужды - есть подписка. Когда он мне был нужен на месяц - оплатил месяц и все. Офис не нужен в отдельной поставке, поэтому не покупается. Вполне достаточно бесплатного онлайн варианта. Да и на MacOS файлы прекрасно открываются и редактируются без продукции Microsoft.
Что касается окружения, то DebugView не нужен. Отладка производится прекрасно и без него. Впрочем, на linux много своих утилит. А вот тот же офис как данность для компаний, тот же терминал, много проприетарного софта - это и есть окружение, которое тормозит многие компании от перехода и развития окружения на linux.

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

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

Что касается ARM, то на данном этапе более логичным и важным был бы релиз для linux. По крайней мере ушла бы необходимость покупать Windows, что для многих является существенной статьей расхода, особенно если рабочих мест очень много.

Да, можете зарегистрировать. Хотя не очень понятно почему это надо делать. Впрочем, причины очевидны - место размещения рекламы.

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

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