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

   Я бы не стал это комментировать, но ведь кто то может это воспринять как открытие  и руководство к действию.
 Попробую объяснить ваше заблуждение (очередное).
Я в своих скриптах не использую ни OnInit ни кода в body по следующим причинам:
1) Код OnInit и код body будут исполняться в основном служебном единственном потоке, который обслуживает:
  - запуск всех Lua-скриптов пользователя;
  - запуск коллбеков всех Lua-скриптов пользователя;
  - обработка всех коллбеков таблиц QUIK (это не таблицы Lua);
  - обработка всех индикаторов пользователя.
 Это значит, что пока он будет "возиться" с кодами OnInit и  body другого он ничего делать не будет.
  На всякий случай попробуйте в начале OnInit написать строку: sleep(30000) и посмотрите что получится .
2) Всю необходимую инициализацию (включая пакеты) можно разместить в начале main в виде функции, вызываемой сразу после ее определения и это будет выполняться в отдельном созданном потоке main, а основной служебный поток продолжит параллельно (если у ПК несколько ядер) выполнять свою перечисленную ранее работу.
3) в рассмотренном варианте при запуске нескольких скриптов сразу они начинают выполняться быстрее, чем с кодами в OnInit и  body.

1.    Подтверждаю. В выложенном экземпляре QUIK у меня ошибка проявляется.

2.   Согласен. Локализована типичная ошибка синхронизации. В моей песочнице эта ошибка не проявляется.

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

4. Вообще то, многие ошибки, обнаруженные в QUIK, по моему мнению, во многом, следствие существующей дефектной (сложной) его архитектуры , о чем я написал в своей ветке "Что стоило бы изменить в QUIK по-крупному" два года назад.

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

У меня было предложение, которое стоит повторить:
  Это может показаться неактуальным из-за снижения активности пишущих, но могло бы улучшить качество форумов в перспективе.

  Это хорошее ваше предложение можно сформулировать следующим образом:
    функциональность обработки событий QUIK расширить, добавив в API пользователя функцию задания свойств служебных очередей событий:
 1) длин очередей;
 2) функций фильтрации событий перед их записью в соответствующие очереди;
 3) приоритетов обработки очередей;
 4) может быть что то еще..
 Все свойства имеют значение по умолчанию.

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

  Вы, как дятел , про свое, не относящееся к обсуждаемому.
  Вы это читали ?:

   Вы опять только пишите не читая.
   Мы же с Йцукен обсуждаем не системный Sleep и даже sleep QLua, а предложенный мной запускающий коллбеки.
Вам опять надо проложиться между комментариев ?

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

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

  При "просыпании" sleep, функции чтения очередей (коллбеки) будут выполняться (последовательно, без пропусков) столько раз сколько необработанных записей в очередях. Если очереди не переполняются, а это можно контролировать и не допускать, то события не теряются, но возможны задержки в их отработке.
  Как было указано ранее, sleep "просыпается" либо по времени, либо по записи в очереди данных из QUIK. Но при этом в в sleep всегда анализируются и при необходимости обрабатываются непустые служебные очереди скрипта.

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

   Я так понимаю, в случае реализации предложенного.

У пользователя никаких изменений:

      1. Я исхожу из того, что среди пользователей QUIK могут быть квалифицированные IT-разработчики, которые могут улучшить мои предложения и поэтому выкладываю их в публичку.
      2. Сохранение существующего API QLua, с тем, чтобы обеспечить совместимость с существующими разработками пользователей, является основным ограничением на предлагаемое.
-------------------
I.  В текущей версии QUIK в одном основном потоке обслуживаются:
- запуск всех Lua-скриптов пользователя;
- запуск коллбеков всех Lua-скриптов пользователя;
- обработка всех коллбеков таблиц QUIK (это не таблицы Lua);
- обработка всех индикаторов пользователя.
  Притом, что в текущий момент у подавляющего количества ПК много ядер ЦП, написанное выше явный перебор. Наверное, нет проблем перечисленное выше обрабатывать в отдельных потоках, так как перечисленные выше функции, в моем представлении, не сильно связаны друг с другом и, на первый взгляд, между ними не требуется синхронизация.

II. Интерфейс  взаимодействия QUIK c Lua-скриптом пользователя, реализованный в виде коллбеков, предполагает многопоточный режим использования Lua, порождающий неприятные проблемы параллельного программирования (для решения которых сами же разработчики предлагают использовать потокобезопасную очередь между коллбеками и потоком main). Мне представляется, что имеет смысл вместо коллбеков использовать активную очередь событий, При этом не требуется использовать Lua в многопоточном, редко используемом и не очень стабильном режиме. При этом не будет проблем с подключением новых версий Lua. Более того, скрипты пользователя будут выполняться несколько быстрее из-за отсутствия синхронизации, требуемой в многопоточном варианте использования  Lua.
  Конкретные предложения:
 1) Lua подключать в однопоточном режиме, нативном варианте, без внесения изменений в исходники. Все необходимые коды QLua перенести в dll-пакет.
 2) Для взаимодействия со скриптами пользователя использовать общие для них служебные циклические очереди (в соответствии с существующими функциями обратного вызова). Длины очередей задавать по умолчанию с возможностью их изменения пользователем. Для каждого запускаемого скрипта пользователя создавать блоки доступа (с соответствующими указателями, обеспечивающими чтение очередей без блокировки) к общим циклически очередям.
 3) Функции чтения очередей регистрировать под теми же именами и так же, как это делается для существующих коллбеков.
 4) Выполнять функции чтения очередей в модифицированной следующим образом sleep:
     - sleep выполняется по истечению заданного в ней интервала времени или при получения сигнала поступления данных в одну из циклических очередей (в пропуске сигналов нет проблем, так есть запуск по времени);
     - выполнение функции начинается с анализа появления новых данных в циклических очередях скрипта (конкретного) и запуска зарегистрированных его функций с теми параметрами из очередей, как это делается в существующей версии QUIK;
     - в качестве результата в модифицированной sleep выдавать значения: количество считанных записей в очередях, признак отсутствия потерь данных в очередях из-за их переполнения (с указанием очередей, в которых это возникло), и, возможно, еще что-то.
 Предложенное:
 1) устраняет зависимость служебного потока от пользовательского, когда (служебный) в существующей версии QUIK может быть блокирован пользовательским, а пользовательский служебным;
 2) устраняет необходимость внесения правок в исходники Lua; при этом скрипты пользователя будут выполняться несколько быстрее из-за отсутствия синхронизации, требуемой в многопоточном варианте использования Lua;
 3) обеспечивает контроль потерь данных в очередях, а также возможность исключения этих потерь за счет увеличения длин очередей пользователем или уменьшения времени ожидания в sleep;
 4) убирает проблемы синхронизации внутри скрипта пользователя.

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

IV. Пожелание: сократить время восстановления взаимодействия QUIK с сервером при перезапуске хотя бы до 10 сек.

  Здравствуйте! Спасибо за ответ.
  У меня просьба к вам: донести до разработчиков мои комментарии 1, 51.

В песочнице QUIK 12.8.3.4 была создана заявка с номером 10256702148.
Она не удаляется ни вручную ни из скрипта.
 Выдается сообщение: "Не удалось снять заявку с номером 10256702148"
 Распечатка заявки из таблицы orders:
<code>
{--таблица: 18.02.26 13:04:52:795 - время создания.
  ['lseccode'] = [=[]=]
, ['qty'] = 7.0
, ['activation_time'] = 0
, ['accepted_uid'] = 0
, ['revision_number'] = 0
, ['sec_code'] = [=[YDEX]=]
, ['investment_decision_maker_short_code'] = 0
, ['visible_repo_value'] = 0.0
, ['accruedint'] = 0.0
, ['executing_trader_qualifier'] = 0
, ['trading_session'] = 0
, ['account'] = [=[NL0011100043]=]
, ['client_qualifier'] = 0
, ['operation_type'] = 0
, ['min_qty'] = 0.0
, ['ext_order_flags'] = 0
, ['client_code'] = [=[10379]=]
, ['price'] = 4917.0
, ['exchange_code'] = [=[]=]
, ['order_num'] = 10256702148
, ['passive_only_order'] = 0
, ['reject_reason'] = [=[]=]
, ['withdraw_datetime'] = { -- table: 00000171D1A2F9A0
 ['min'] = 0
, ['week_day'] = 1
, ['sec'] = 0
, ['ms'] = 0
, ['day'] = 1
, ['year'] = 1601
, ['mcs'] = 0
, ['month'] = 1
, ['hour'] = 0
 }
, ['visible'] = 0.0
, ['yield'] = 0.0
, ['settle_date2'] = 0
, ['price_currency'] = [=[]=]
, ['on_behalf_of_uid'] = 0
, ['awg_price'] = 0.0
, ['linkedorder'] = 0
, ['trans_id'] = 105007541
, ['start_date'] = 0
, ['firmid'] = [=[NC0011100000]=]
, ['value2'] = 0.0
, ['executing_trader_short_code'] = 0
, ['exec_type'] = 0
, ['extref'] = [=[]=]
, ['value'] = 34419.0
, ['repo_value_balance'] = 0.0
, ['repovalue'] = 0.0
, ['datetime'] = { -- table: 00000171D1A2FB20
 ['min'] = 36
, ['week_day'] = 3
, ['sec'] = 57
, ['ms'] = 0
, ['day'] = 18
, ['year'] = 2026
, ['mcs'] = 0
, ['month'] = 2
, ['hour'] = 6
 }
, ['class_code'] = [=[QJSIM]=]
, ['value_entry_type'] = 0
, ['settle_date'] = 0
, ['acnt_type'] = 0
, ['brokerref'] = [=[10379//1]=]
, ['start_discount'] = 0
, ['balance'] = 7.0
, ['side_qualifier'] = 0
, ['seccode'] = [=[YDEX]=]
, ['external_qty'] = 0.0
, ['benchmark'] = [=[]=]
, ['qty2'] = 0.0
, ['client_short_code'] = 0
, ['repoterm'] = 0
, ['price_entry_type'] = 0
, ['visibility_factor'] = 0.0
, ['ext_order_status'] = 0
, ['flags'] = 29
, ['settlecode'] = [=[]=]
, ['uid'] = 228221
, ['expiry'] = -1
, ['bank_acc_id'] = [=[]=]
, ['repo2value'] = 0.0
, ['capacity'] = 0
, ['ordernum'] = 10256702148
, ['price2'] = 0.0
, ['investment_decision_maker_qualifier'] = 0
, ['userid'] = [=[NC0011100000]=]
, ['expiry_time'] = -1
, ['canceled_uid'] = 0
, ['settle_currency'] = [=[]=]
, ['filled_value'] = 0.0
}--таблица: 18.02.26 13:04:52:795
<code>
----
Архив песочницы для анализа поддержкой: https://cloud.mail.ru/public/LTv3/NMDsG3SZD

   Если вы не понимаете то, что написано вами, то бесполезно вам что то объяснять. Все равно не поймете.

  Это ваше добровольное признание :
   На всякий случай ссылка: https://forum.quik.ru/messages/forum10/message78413/topic9090/#message78413

  Это заклинания .   Вы думаете, что они работают?

У вас много текста но нет простых вещей:

VPM
  Забыл добавить: где доказательство безопасности счета?

VPM
Понятно, вас с "толку" не сбить .
Но интересно, что вы напишите на следующее.
   Обрабатывая коллбеки и восстанавливая их результат, вы, по сути, повторяете (но в условиях неопределенности) работу которая выполняется в QUIK при формировании его таблиц.
  1. Зачем повторять функциональность которую реализовали разработчики и которая отлажена, скорее всего лучше чем "призрачные" коллбеки (зависящие от кода main), так как это было давно (до появления QLua) и проще контролируется?
  2. Полагаете, что вы квалифицированнее разработчиков?
  3. Вы же вроде согласны с принципом "меньше дергаешься - реже падаешь". Вам нечем заняться и хочется поразвлечься с коллбеками?

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

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

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

  1. Читайте:
  2. Вы проверяли задержку между коллбэком с заполненными параметрами и появлением записи в таблице? Если нет, то проверьте.

   1. Я OnQuote не пользуюсь. QUIK не предназначен для высокочастотной торговли. Из стакана вам приходит история с задержкой как минимум 2-3 сек. и ваша реакция, скорее всего, тоже > 2 сек. Хотелось увидеть реальные доходные стратегии в таких условиях.
   2. Если мне нужны какие то данные из текущей таблицы торгов, то я их читаю в цикле, с нужным мне периодом (у меня есть возможность создавать такие циклы, кроме основного) и фильтрую, чтобы не было повторов, по параметру VOLTODAY. Получается не хуже по результату и эффективности использования ПК, чем при использовании OnParam.

1.   Кто вас заставляет ждать 120 сек.? Ждите 1 млс.  И, вообще, возитесь с коллбеками сколько хотите . Для вас чем сложнее, тем лучше.

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

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

    В моих роботах единственный обрабатываемый коллбек это OnTransReply по той причине, что в нем есть информация о возможных причинах отказа в выставлении заявки. При этом я предполагаю, что он может теряться и отслеживаю в таймере выставление заявки по  времени, проверяя таблицу заявок (orders соответственно stop_orders). Если заявка не появилась в соответствующей таблице в течении 120 секунд, то это ошибка в выставлении и есть ветка отработки этой ошибки.
    Все остальное, включая случаи необходимости получения текущих данных таблиц текущих торгов и тд. я беру из таблиц QUIK, кешируя для быстрого доступа индексы используемых таблиц.
    Признаком изменения состояния таблиц (исключая orders, stop_orders) является изменение длины, которую можно получать функцией getNumberOf.  Признаком возможных изменений в существующих записях orders и stop_orders является изменение длины таблицы сделок.
    Вообще, для торговли надо знать состояние своего счета и какую то картину рынка. Все это можно получить из таблиц QUIK и я не вижу смысла возни с коллбеками.

    Вы опять не читаете или ничего не соображаете.  У меня же написано конкретно то, что давно известно:
   Выполните в main строку: for i = 0, 10000000000 do  end
  и вы заблокируете секунд на 30 не только коллбеки, но и диалог QUIK.
  -----
   Вы опять меня "передергиваете".  Где я это писал буквально?  Читайте мою приведенную выше цитату. Вы понимаете что означает слово буквально?
 Зачем вы меня "передергиваете" и пытаетесь приписать свои фантазии?
 Вы продолжаете работать прокладкой между комментариями ?

    Когда же вы научитесь читать ? Вы читаете тексты перед тем как писать?
  Ведь написано:
 Где вы видите у меня фразу: "для исполнения"?  
 У вас какое то недержание ваших текстов.

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

  В ветке "Что стоило бы изменить в QUIK по-крупному" (от 15.03.2024) предложены изменения схемы встраивания Lua в QUIK (с сохранением существующего API пользователя) устраняющие некоторые существующие его дефекты, но реакция разработчик QUIK нулевая. Нет даже возражений.

Вопрос задан User12501.

И все таки:

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

    Эта очередь разбиралась пользователем Старатель около 4-х лет назад. "Все украли до нас" .

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

   1. Всю обработку вы делаете в служебном потоке коллбека (отличным от потока main). Этот поток в QUIK один и он обслуживает все запущенные скрипты QUIK. Когда он занят вашей обработкой он перестает выполнять свои служебные функции, в том числе, обработку вновь возникающих данных по сделкам. Если нет служебной очереди внутри QUIK, то возможны потери возникающих данных. В вашем варианте желательно как можно быстрее выполнять коллбек, например, записывая trd в очередь между коллбеком и потоком main (со sleep(50) ), в котором выполнять остальную обработку таблицы trd. Вариант реализации очереди выложен мной в соседней ветке пользователя VPM.
   2. Если вам нужны данные по сделкам, то их можно получать готовыми из таблицы QUIK trade с помощью функции getItem. Зачем вы отрабатываете "сырые" коллбеки OnTrade?

   Не видя вашего кода, сложно что-то сказать, но попробуйте сделать  sleep(50)  и посмотрите что будет.
С задержкой 585000 ваш код в main практически отключен. Это так вами задумано?

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

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

   Кто вам сказал, что эта архитектура надежная? Зачем заниматься событиями QUIK, когда для торговли нужно знать состояние своего счета и какую то "картину" рынка? Зачем возиться с корутинами, если все можно сделать проще используя только функции?
   Вы легких путей не ищете .
   Как и любая готовая программа (в том числе наши собственные) QUIK несовершенен и у него есть недостатки и ошибки, но в нем, в текущей момент, можно создавать скрипты работающие месяцами без перезапусков до очередного обновления windows.

  У вас sleep(585000)???

    1.     2.     Для себя я не вижу необходимости "дергать" сборку мусора. В начале main выполняю:  collectgarbage ('setpause', 200)  -- сборка мусора после увеличения памяти скрипта на 100% после очередной сборки. И все.   У меня сборка мусора возникает с интервалом ~15 сек. и длится < 1 млс.

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

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

   Какие скоростные алгоритмы? Когда есть ограничение архитектуры QUIK. Факторами возможных задержек в нем являются <Реализация скрипта>  ->  <Реализация QUIK>  ->  <Используемая аппаратура ПК>  -> <Канал связи с брокером> -> <Сервер брокера> ->  -> <Канал связи брокера с биржей> -> <Биржа>.

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