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

   Я еще раз посмотрел addalias ( item, path, deep, seen ) и не увидел контроля уникальности path (с выдачей сообщения об ошибке в каком-то виде). Делать это надо отдельно  от уже реализованного контроля уникальности item.

 Это мне известно.

Похоже, мы обсуждаем:
   Здесь рассмотрен вариант когда результатом выполнения функции tbl_to_str (аналога dumpstr) является строка-скрипт вида:
local TBL = {}  
TBL.table00000263878C31B0 =  {}  --- создание таблицы --
TBL.table00000263878C31B0 [ [[expansion]] ] = [[txt]]
TBL.table00000263878C31B0 [ [[INTERVAL_W1]] ] = 10080
TBL.table00000263878C31B0 [ [[QTABLE_DOUBLE_TYPE]] ] = 2
TBL.table00000263878C31B0 [ [[INTERVAL_M5]] ] = 5
---- и так далее.
return TBL.table00000263878C31B0
-------
Функцию str_to_tbl я приведу полностью:
--- Рузультат функции: таблица полученная из строки s или текст описания ошибки ---
local function str_to_tbl (s )
   do local tt= { }     for k, v in pairs ( alias ) do tt[ v ] = k end alias = tt end --- alias: переворот: alias = { [ <Имя> ] = <Значение (> }
   local fun , err = load ( s )  
   if  err ~= nil  then return  err  else   return  fun()   end
end
--------------------

  С этим согласен.
Тоже нормальный (и более простой) вариант.
Это я не понял.

 После этого комментария, когда у меня появилось время, мне (сразу, без переобувания в тапочки ) захотелось поучиться у вас, и посмотреть тот код, который вы тут выложили.
  Выложенный вами модуль, в целом, написан в хорошем стиле. Если вы это сделали сами, то, похоже на то, что Lua вы знаете. Однако, несколько настораживает то, что в модуле нет ни одного комментария и много операторов одной строкой. Такое ощущение, что это написано сразу начисто (и без отладки). Я бы так не смог .
  При более детальном просмотре я увидел, что в представленном вами модуле есть ошибки (я сделал правки в 8-ми местах). Чего я не ожидал    так это то, что в нем не учтено существование в Lua типа boolean (смотрите правки в коде модуля). Этот тип хорошо описан в любезно предложенной вами инструкции на сайте https://www.lua.org/manual/5.3/  в разделе 2.1  (в 1.3 этого описания не ищите).
  Я поправил в модуле те ошибки, которые, как мне кажется, увидел (но возможно и добавил свои ). Понятно, что какие-то ошибки могли и остаться. Свои правки я как-то прокомментировал, выделив существенные изменения символами ###.  
  Модифицированный код модуля выложен в конце данного комментария.
  Кстати, я проверил быстродействие dumpstr модуля  на своем ПК и моем _G  (понятно, что у нас с вами в этом могут быть большие различия). Мой dump_str  (написанный два года назад, в тренировочных целях, когда мне пришлось перейти на  QUIK) выполняется (на таблице _G)  в 3 раза быстрее, чем dumpstr модуля, но это мелочи. У представленного вами модуля назначение другое (в том виде как он есть, это точно не визуализация) и его функциональность богаче.
----
    То, что делается в исходном, обсуждаемом модуле, можно сделать, как мне кажется, элегантнее, формируя в качестве строки образа таблицы, текст исполняемого скрипта. Результат такого подхода:
1) tbl_to_str на ~20% - длиннее, чем dumpstr;
2) str_to_tbl  - короче аналогичной  loadstr в ~10 раз. .
--------------------------------
P.S.
 Все мы, время от времени, в чем-то ошибаемся. Существенная разница состоит только в том, что одни больше усилий предпринимают для устранения своих ошибок, а другие на их оправдание и надувание щёк.
-------
Измененный код обсуждаемого модуля:

  Я думаю что вы мне здесь все расскажите

 Ну и ладно

   Длины разные, но "a" .. "a\0b" = "aa". Проверено в Lua 5.3.5 и 5.4.1. Непорядок. Разработчикам Lua это надо бы довести до сведенья.

   Я при описании dump_tbl ни разу не упоминал про сериализацию и в этой функции ключи типа table, userdata и function не раскрываются. Для них выдается их служебный код (ссылка).

   Так как символ \0 в Lua это признак завершения строки, то для Lua "a" и "a\0b" - эквивалентные строки.

   Результат 1.#inf выдает Lua и я не собираюсь переделывать его.

 Согласен. Пользоваться не стесняюсь. Сайт хороший.

 Спасибо за нетривиальные примеры для тестирования.

local str = ""    
for k,v in next, dump_tbl ({ [ {"xx","yy"} ] =5}, " ", 0) do str = str .. v end РЕЗУЛЬТАТЫ теста (в квадратных скобках индексы таблиц)
MessageDlg ( 1, 1, "Скрипт", " Результат: \n" .. str)                                             Результат: [table: 0F4ED2F0] (number) = 5
-------
str = ""    
for k,v in next, dump_tbl ({"a\0b"}, " ", 0) do   str = str .. v  end
MessageDlg ( 1, 1, "Скрипт", " Результат: \n" .. str)                                             Результат: [1] (string) = a
MessageDlg ( 1, 1, "Скрипт", " Результат: \n" .. "a\0b")                                        Результат:  a   ---
message ("a\0b")                                                                                                Результат:  a
-------
str = ""    
for k,v in next, dump_tbl ({math.huge}, " ", 0) do   str = str .. v  end
MessageDlg ( 1, 1, "Скрипт", " Результат: \n" .. str)                                             Результат: [1] (number) = 1.#INF
message (tostring(math.huge))                                                                            Результат: 1.#INF
-----------------------------------------------------------------------------------------
 Я ошибок не нашел. Где они?

  В том как я предложил вам собирать строку профита нет. Профит есть при использовании специальной быстрой C-функции сборки строки из массива строк (тоже из API, но С-пакета, который пришлось бы устанавливать).
  Если собирать без профита, то при выполнении операции  <строка1> = <строка1> .. <добавляемая строка>  в Lua всякий раз выполняется отказ от предыдущей памяти <строка1> и запрашивается новая память под новое значение <строка1>.  В быстрой C-функции сборки строки на C++ реализована эффективная динамическая строка, в которую последовательно добавляются <добавляемые строки> вообще без описанной мною в предыдущем предложении нагрузки на автоматическое управление памятью.

  Покажите пример. Можете распечатать контекст Lua: dump_tbl (_G, " ", 0)

  Согласен.  Но я не предлагаю что-то ставить. Я привел оглавление описания API и одну из простых, но полезных, по моему мнению, для разработчиков функций.
  У меня используется специальная быстрая функция сборки строки из массива строк и я это делаю в dump_str используя dump_tbl.  Дело в том, что цикл вида:  <строка1> = <строка1> .. <добавляемая строка> при большом количестве повторений (а я предполагаю что это может быть) в Lua заметно нагружает управление памятью.  Вы же можете получать свою строку следующим образом: local str = ""     for k,v in next, dump_tbl (<Параметры>) do   str = str .. v  end  или модифицировать код функции dump_tbl.                              
Функция dump_tbl   рекурсивная и в ней раскручиваются все ссылки.

Комментариев обсуждения функции cоздания последовательности ключей я насчитал более двадцати. Это одна из самых простых функций из списка API  OS_Quesha, оглавление описания которого в документации приводится ниже.
1. Вывод сообщений.
2. Работа со временем.
3. Создание последовательностей ключей.
4. Создание среды функционирования разрабатываемого робота.
5. Взаимодействие потоков.
6. Обеспечение явной синхронизации потоков.
7. Работа с таймерными событиями.
8. Работа с контрольными точками.
9. Работа с фоновыми заданиями.
10. Обеспечение отладки функций и взаимодействия потоков.
11. Разное.
   Примером простой (классическая задача на рекурсию), но, наверное, полезной функции из раздела 10 является универсальная функция печати переменных dump_str. Она может быть использована в тексте программ для вывода любых переменных (и таблиц произвольной вложенности) Lua.
  Ниже приводится код функции, которую можно использовать автономно (может быть кому то окажется полезной):


 В диалоге OS_Quesha, в процессе ее работы, функцию dump_str можно вызвать в любой момент для любой глобальной переменной скрипта с тем,  чтобы распечатать ее с выдачей в журнал отладки. Например, у меня контекст Lua (переменная _G) выводится (это ~5000 строк) за 20 млсек (по поводу скорости вывода жду комментария Владимира ).

И по теме (описание интерфейсных функций OS_Quesha):
 5.3 Создание последовательности ключей
Последовательность ключей это функция, при обращении к которой выдаются значения некото-
рого типа, уникальные в некотором контексте их использования. Дополнительным требованием
(кроме уникальности значений), в некоторых случаях использования таких функций, может быть
необходимость формирования их значений по определенным правилам.
В качестве примера использования последовательности можно привести создание идентифи-
каторов заявок при их выставлении в QUIKе с помощью функции sendTransaction.
1. Запрос последовательности ключей (number):
Cl_LuaGL ()
Результат функции: number - глобальный ключ системы формата: <Номер запус-
ка/перезапуска системы >(старшие, оставшиеся разряды, начиная с 6-го )<Счетчик запросов
ключей после запуска/перезапуска системы>(6 десятичных разрядов)
Эта функция при обращении из любого потока (функции скрипта), выдает значение отличное от всех ранее ее вы-
данных (независимо того, были запуски или перезапуски системы).

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

  Робота вы можете создать и использовать его сами для зарабатывания денег, но не можете зарабатывать на торговле самими роботами.

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

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

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

     Я согласен с тем, что подавляющее большинства пользователей QLua эффективность вычислений (параллелизм т.д.) мало волнует, но это в перечислении основных функций OS_Quesha всего лишь первый пункт. У меня самого возникла потребность в потоках не из-за проблем с вычислительными ресурсами, а из-за того, что появилась группа взаимодействующих задач, и в рамках одного потока надо было реализовывать некоторый диспетчер, занимающийся распределением процессорного времени одного потока между этими задачами. Вместо реализации такого диспетчера (а это была бы реализация в корявом виде функций потоков) были реализованы функции первого пункта, которые не только решали проблемы диспетчирования задач, но и при необходимости могли решать проблемы обеспечения эффективности вычислений. Возможность создания потока внутри скрипта обеспечила также беспроблемное использование любых доступных отлаженных графических пакетов, из которых я выбрал IUP.

Когда обсуждаются любые средства, облегчающие разработку программ, возражение типа: «Это можно сделать существующими средствами», «не катит», так как, в конце концов, все можно сделать и на ассемблере. По существу же, обсуждать имеет смысл то, насколько быстро и качественно можно разрабатывать приложения, использую предлагаемые средства по сравнению с тем, что  обеспечивают существующие средства их разработки. Конечно, только практика использования любого средства разработки программ может определить его реальную полезность для разработчиков. Такая возможность разработчикам роботов в QUiK предоставлена в виде кодов и документации OS_Quesha.

 Мне непонятно в чем состоит специфичность использования OS_Quesha, если вместо одной функции main в QLua, в OS_Quesha, при использовании исходника TS_QUIK_RT.lua, предоставляется четыре (количество определяется в исходнике, в описании схемы обработки в табличном виде), аналогичные функции, в которых доступен весь API QLua. Эти функции могут, при наличии нескольких ядер в ЦП компьютера, выполняться параллельно (с учетом особенностей версий QUIK  > 8.4, описанных в моем начальном комментарии). Дополнительно они могут взаимодействовать между собой через готовые очереди. Кроме того, в них  доступны все возможности, описанные в моем начальном комментарии. Причем, расход ресурсов ПК на функционирование OS_Quesha ничтожен и в этом можно убедиться, запустив немодифицированный исходник TS_QUIK_RT.lua. Все дополнительное использовать не обязательно, но это может потребоваться при последующем расширении возможностей робота.

 Это вы отметили правильно.
 Спасибо за пожелание.

 В документацию я добавил исходник TS_QUIK_RT.lua (это TS_QUIK.lua без тестовых функций) полностью готовый для практического использования пользователем. В нем определены четыре циклические функции-шаблоны: main, main_user1, main_user2, main_user3, в которые пользователь может вставить свои фрагменты программ, обрабатываемые в циклах этих функций. Эти функции запускаются в разных потоках. У всех перечисленных циклических функций есть входные очереди, обеспечивающие (при необходимости) их взаимодействие (чтение/запись). Любая функция активируется либо по истечении интервала ожидания (как в sleep), либо в момент записи данных в любую ее входную очередь. Во всех четырех функциях вместо известной  функции sleep используется функция WaitEventOCLua, реализующая описанную схему обработки циклов.
   В функции main реализована схема обработки колбеков, в которой основной поток QUIK записывает параметры колбеков в очереди, обрабатываемые в main. Операция записи в очередь быстрая и поэтому основной поток, при обработке колбеков, не блокируется.
   Количество циклических функций, их очереди и другие параметры определяются в TS_QUIK_RT.lua  схемой описания обработки данных, которую пользователь может модифицировать под свои задачи. Кроме того, пользователь может использовать следующие, уже подключен-ные, пакеты:
1) iup (графический пакет);
2) sqlite (пакет работы с встроенными базами данных);
3) lfs (файловый пакет).
 Дополнительные возможности (настраиваемый диалог, ведение журналов диалога и отладки, средства отладка скриптов и т.д.) при использовании OS_Quesha были описаны в моем начальном комментарии.
---
P.S.  Текущая версия OS_Quesha работоспособна и для QUIK (Lua 5.4).

Возможно, это для вас окажется интересным: https://forum.quik.ru/messages/forum10/message52233/topic6198/#message52233
   Но это трудно отнести к небольшому примеру.

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

  Не точно, но возможно, вы взяли статическую библиотеку  lua54.lib (~300 кб.). Надо использовать библиотеку импорта dll    lua54.lib (~30 кб.) с тем, чтобы использовались функции QUIK из его lua54.dll. Либо надо самому создать библиотеку импорта lua54.lib, используя lua54.dll из QUIK.

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

  Вы счастливый человек и я не очень понимаю, зачем вам так много писать в этой теме

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

  Я сам работаю в этой программе

  Те, кто могут полностью обойтись тем, что предоставляет QLua. не являются целевой аудиторией.

  Достойный ответ, который я не смог сформулировать так четко.

  Я согласен с выше написанным, но вы ломитесь в открытую дверь

  Я же написал, что диалог можно сделать на таблицах, некстати, обслуживаемых основным потоком QUIK. У вас все хорошо.  Ну и замечательно! Кстати, какой-то диалог можно реализовать и на обычном Блокноте
-----
 Дополнительно, для пользователя доступны все возможности графического пакета iup (это, по поводу комментария Nikolay о простом диалоге).
----
 Вообще, мне кажется, что у нас спор ни о чем. Я же не предлагаю заменить диалог Nikolay или запретить использование таблиц QUIK. Я даже уговариваю пользователей не лезть без нужды ни в какие дебри, а решать свои задачи наиболее простыми и понятными для себя средствами.

 1. Допустим, что в вашем скрипте нужен диалог. В данном продукте реализация диалога пользователя  это модификация в TS_QUIK.lua  готовой таблицы «меню пользователя» с  заданием функций-обработчиков команд  и определение этих функций. И это все, что при этом требуется.

Образец таблицы меню пользователя, который надо будет модифицировать под конкретное приложение:
--   Таблица описания  диалога приложения (образец) ---
local mmenu =
{
   "Меню 1 (образец)",
{
       "Команда 1", default,       --   default -  функция-реакция    ----
       "Команда 2", default,
       "Команда 3",default,
       "-", nil,
       "...........",  default        
   }
   ,"Меню 2 (образец)",
{
       "Команда 4",default,
       "Команда 5", default,
       "-------------",nil,
       "Подменю ",
{
           "Команда 6", default,
           "Команда 7", default
       }
   }
}
В образце default это функция-обработчик команды (их надо заменить на свои после изменения таблицы под свои нужды).
  Кроме того, для пользователя предусмотрена возможность настройки обработки собственных сложных команд, задаваемых в командной строке формы диалога.
  Можно сделать диалог другим способом? Конечно, можно (на таблице QUIK, используя VCLua, вообще написать на ассемблере). Вопрос состоит только в том, насколько удобным, расширяемым будет этот диалог и как это сделать быстрее.

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

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

Приведенный список можно продолжить, но, кому это интересно, может прочесть в файле  OS_Quesha.pdf.

   При работе с iup в отдельном потоке (как это сделано у меня) я проблем не встретил.

  Спасибо за ценный совет.

  Шаблон TS_QUIK.lua учебный. Наверное, его можно было «причесать», но я не видел в этом большого смысла.

 В нормативно-правовых актах определено некоммерческое использование:
"Допускается без согласия автора или иного правообладателя воспроизведение, осуществляемое только гражданином и только в личных целях, под которыми по смыслу статьи 1273 Кодекса понимается последующее некоммерческое использование соответствующего экземпляра для удовлетворения собственных потребностей или потребностей обычного круга семьи этого гражданина (который определяется судом с учетом конкретных обстоятельств рассматриваемого дела)." (Постановление от 26 марта 2009 г. № 5/29 Пленума Верховного Суда Российской Федерации и Пленума Высшего Арбитражного Суда Российской Федерации)

  Список операций, поддерживаемых Lua алгоритмически полный. То есть, на этом языке можно реализовать любой алгоритм. Но точно также, можно задать похожий вопрос: почему бы вместо Lua не использовать ассемблер?
  Назначение данного продукта не в том чтобы заменить Lua. Это в каком-то смысле «станок» с готовой инфраструктурой, которая в том или ином виде требуется  для разработки сложных программных систем. Как было сразу отмечено в моем начальном комментарии,  для простых случаев не надо ничем заморачиваться, а использовать обычные QLua-скрипты.

Читаем:

  Где вы прочитали, что OS_Quesha разработана под одну конкретную прикладную задачу?

  Эта хрень работает, начиная с апреля 2019г.  Чтобы убедиться в этом, установите ее у себя (это делается просто) и запустите.

  То есть, в восторге

Ссылка на коды и документацию OS_Quesha (на текущий момент для версий 7<= QUIK < 8.5  и  >= 8.11  Lua 5.3.5): https://cloud.mail.ru/public/2zn2/2tZgedUu4
---------------------------------------
 Программа представляет собой специализированную операционную систему реального времени, работающую в среде программного комплекса QUIK. Она предназначена для разработки многопоточных роботов торговли ценными бумагами в QUIK. Программа реализует в скриптовом языке программирования QLua параллелизм выполнения его функций, взаимодействующих между собой, в рамках одной его инсталляции, обеспечивая использование многопроцессорности вычислительных систем. Из программы доступен весь программный интерфейс QUIK, существующий для скриптов QLua.
---------------------
   Общая схема обработки данных в OS_Quesha следуюшая. Циклические функции, запускаемые в отдельных потоках (аналогичные функции main в QLua) входят в свой основной цикл обработки. Но вместо sleep используется API-функция OS_Quesha ожидания либо истечения интервала времени (паузы циклической функции), либо появления данных во входных очередях таких функций. Взаимодействие циклических функций между собой после запуска на выполнение в потоках, сводится к чтению своих очередей и записи своих данных в чужие очереди. Вся необходимая синхронизация параллелизма выполнения происходит внутри специальных функций чтения/записи очередей. Эти очереди, при записи в них данных, выдают сигналы, активирующие те потоки, для которых они являются входными. Дополнительно, предоставляются средства синхронизации, которые могут потребоваться при использовании модифицируемых общих данных потоков, но, по возможности, этого лучше избегать.
   В этой схеме активация потоков (их динамика) определяется движением данных в их очередях, а <паузы циклических функций> * <коэффициент, заданный в настройках> являются параметрами контроля блокировок и зацикливания этих циклических функций.
   Описанная выше схема обработки данных, характерная для многих систем реального времени, к которым относятся и роботы фондового рынка, обеспечивает, наряду с распараллеливанием вычислений, реализацию удобной (для разработчиков) модели  таких вычислений. Причем, удобство этой модели вычислений, во многих случаях конкретных применений, является более существенным фактором, чем, собственно, параллелизм вычислений.
-----
   В скрипте-шаблоне создания роботов с использованием OS_Quesha, в виде исходника "TS_QUIK.lua", входящего в состав документации OS_Quesha, запускается 16 потоков, часть из которых являются служебными (реализация диалога с пользователем, генерация таймерных событий, ведение логов, контроль состояния системы, обработка фоновых заданий и т.д.). Остальные потоки пользовательские (их количество определяется схемой обработки данных пользователя, заданной в шаблоне, в табличной форме).
   Шаблон демонстрирует использование средств OS_Quesha при создании робота.
   Конкретно, в шаблоне реализовано (в отдельных потоках):
1) схема обработки колбеков в виде очередей событий QUIK, минимизирующих влияние последующей обработки событий на основной поток запуска скриптов и генерации событий QUIK;
2) сохранение истории одноминутных и пятиминутных котировок ценных бумаг в базах sqlite;
3) оперативное сохранение текущих котировок 22-ух (по 18 параметрам) торгуемых бумаг в циклических буферах с задержкой < 1 млсек относительно момента возникновения событий OnParam;
4) выполнение заданий по расписанию;
5) тестовое взаимодействие OS_Quesha с внешним процессом (Robot_KIT.exe) по дуплексному каналу передачи/получения сообщений с интенсивностью 1500 сообщений в секунду с задержкой между их приемом и передачей менее 5 млсек;
6) несколько тестовых циклических функций - примеров реализации таких функций.

Дополнительные ресурсы ЦП, потребляемые в QUIK при запуске шаблона, менее 1 % (более детальное описание потребляемых при этом вычислительных ресурсов приведено в инструкции OS_Quesha.pdf, входящей в состав документации).
-------------------------------------------------------------------------


  Основные функции OS_Quesha.
1. Организация настраиваемой многопоточной обработки данных:
   - создание потоков для выполнения QLua-функций на основе описания схемы обработки данных в табличной форме;
   - реализация таймерных событий (с разрешением в 2 млсек);
   - контроль блокировок и зацикливания в потоках, утечки оперативной памяти, а также состояния очередей взаимодействия потоков/псевдопотоков.
2. Создание настраиваемого диалога с пользователем. Пользователь имеет возможность добавлять в форму диалога свои меню.
3. Ведения журналов OS_Quesha (диалога и отладки) с милисекундным разрешением.
4. Запуск на выполнения Lua-функций в фоновом режиме в отдельных потоках.
5. Работа с контрольными точками (для продолжения работы с прерванного, по любой причине, места).
6. Обеспечение интерфейса ( в виде шаблона исходников на C++) с dll для подключения к системе функций, реализуемых в среде C++.
7. Ведение истории котировок (одноминутных и пятиминутных) в базах SQLite.
8. Ведение текущих дневных котировок в векторах оперативной памяти.
9. Эффективная схема обработки событий QUIK в виде циклических потокобезопасных очередей получения данных колбеков (реализованных без синхронизации).
10. Обеспечение интерфейса реализации торговых индикаторов на основе текущих котировок.
11. Обеспечение виртуальной торговли ценными бумагами.
12. Описание и реализация плана торгов.
13. Обеспечение отладки разрабатываемых параллельных программ и их функций.
14. Обеспечение интерфейса взаимодействия ( в виде шаблонов исходников) с приложениями разрабатываемыми средствами C#, vb и запускаемыми (с целью изоляции от QUIK) в отдельных процессах.
15. Обеспечение парсинга сайтов для информационной поддержки торговли.
   Документация.
 Основная документация представлена в виде исходника скрипта-шаблона "TS_QUIK.lua", в котором имеются подробные комментарии по использованию средств OS_Quesha при реализации, представленной в этом шаблоне некоторой обобщенной схемы обработки (в том числе колбеков).  Этот шаблон может служить основой для создания конкретных торговых роботов. Кроме того существует инструкция OS_Quesha.pdf, которая может быть вызвана и из диалога системы: <Система> -> <Справка> либо просмотрена в папке C:\OS_Quesha\OS_Quesha_files.
-----
  Коды.
 Исполняемые коды представлены в виде исходника TS_QUIK.lua (общего для всех поддерживаемых версий QUIK) и  оттранслированных кодов, соответствующих версиям QUIK.
  Общий объем исполняемых кодов OS_Quesha для любой, поддерживаемой версии QUIK менее 5 мб.  
-----
  Установка программы сводится к распаковке ее файлов, копированию полученной папки на диск C, а также добавлению скрипта  TS_QUIK.lua  в меню QUIK «Доступные скрипты».  После установки можно запускать скрипт TS_QUIK.lua. Появится диалоговая форма программы с разнообразными меню.  При первом запуске TS_QUIK.lua в папку с info.exe копируются пакеты из папки ….\Файлы папки QUIK, соответствующии используемой версии QUIK.  Все это описано в прилагаемой инструкции по установке и запуску OS_Quesha.
-----
Настройки программы.
  Настройки OS_Quesha на конкретное использование представлены в виде:
1) глобальных переменных, хранящихся в sqlite-базе;
2) локальных определений объектов системы, описанных в тексте скрипта, в основном, в виде таблиц.

===============================================

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

1. О каком параллелизме можно говорить, если в QLua версий QUIK > 8.4 (! в отличие от младших, по номеру, версий) VM-Lua не реентерабельна, а является разделяемым, синхронизируемым ресурсом?
 Ответ (относится к QLua 5.3.5 версии QUIK >= 8.5).
 Если в коде скрипта полностью исключить обращение к C-функциям (в том числе к sleep), то о параллелизме можно было бы забыть. Но так как C-функции в любом скрипте есть (хотя бы из-за присутствия sleep) и реентерабельны, то они могут выполняться в отдельных потоках параллельно между собой и с VM-Lua, обслуживающими (в режиме разделения) Lua-коды скрипта.  С учетом выше сказанного «тяжелые» вычисления могут быть, если это требуется, без особых проблем реализованы на C/C++, и они могут выполняться параллельно. При этом надо учитывать, что все C-API функции Lua при своем вызове переходят (с последующим возвратом в предыдущий режим), всегда в режим VM-Lua, в том числе, и при использовании их в C-функциях.
   По сути, в OS_Quesha  обеспечивает следующую схему обработки данных. В нескольких потоках исполняются функции, в которых могут быть чередующиеся фрагменты C-кодов и Luа-кодов. И только при исполнении  фрагментов Luа-кодов идет обращение к VM-Lua с блокировкой, как к разделяемому ресурсу. В остальных случаях коды могут выполняться параллельно.
   Для удобства реализации функций на C/C++ в составе OS_Quesha  есть С- пакет QluaUser.dll, c его исходниками.
  Исходя из всего вышесказанного, общая стратегия построения многопоточного скрипта при использовании OS_Quesha  следующая.  Функция main оперативно поддерживает интерфейс c QUIK, раздавая тяжелые вычисления в другие потоки, и это демонстрируется в шаблоне TS_QUIK.lua.
---------------
2. Кому может пригодиться эта программа? И какие ее особенности, которые могут быть полезны разработчикам роботов в первую очередь?  
      Ответ.
2.1 OS_Quesha является набором инструментов для разработки роботов в QUIK и одновременно средой их функционирования. Для ее использования, как и любого инструмента, требуется ознакомиться с инструкцией по ее применению. Исходник шаблона, сильно упрощает ее применение, но все равно требуется какое-то время на ее изучение. Поэтому, если ваш робот простой и не требует возможности, предоставляемых OS_Quesha, то, скорее всего, его проще создать в виде обычного QLua-скрипта.
2.2 Основные особенности программы, которые могут быть интересны разработчикам роботов, следующие:
1) полная инкапсуляция параллелизма функционирования потоков в API OS_Quesha, обеспечивающих эффективность (реализована специально разработанная схема синхронизации), корректность синхронизации и безопасность взаимодействия функций, выполняемых в разных потоках;
2) настаиваемый диалог пользователя с роботом;
3) встроенный контроль времени выполнения функций роботов, блокировок, зацикливаний в потоках, утечки оперативной памяти, а также состояния очередей взаимодействия потоков.
4) встроенные средства отладки межпотокового взаимодействия, а также разрабатываемых функций;
при этом обеспечивается возможности:
 -  оперативного настраиваемого фильтрующего вывода данных из любых очередей взаимодействия потоков в журнал отладки;
 - оперативной печати любых глобальных переменных работающего робота (в том числе таблиц произвольной вложенности);
 - оперативного запуска скриптов, в работающей системе с доступом из них к ее среде исполнения, обеспечивающего удобство отладки фрагментов разрабатываемого робота;
 - централизованной обработки возникающих ошибок;
5) наличие средств реализации контрольных точек, с которых может быть продолжено функционирование робота  после его перезапуска по любой причине;
6) раздельное ведение журнала диалога и журнала отладки с записью сообщений с миллисекундным разрешением;
7) реализация схемы обработки колбеков, в которой после записи параметров колбека во входную очередь функции main, ей сразу выдается сигнал на обработку колбека;
8) низкое потребление ресурсов на собственное функционирование OS_Quesha (подробности в  статье, на которую есть ссылка в начале комментария).
---------------  
3. Насколько стабильна OS_Quesha?
Ответ.
  Одним из объективных показателей стабильности (надежности) любой программы является длительность ее эксплуатации без проявления ошибок, после устранения очередной, обнаруженной в ней ошибки.
   Для версий QUIK < 8.5 в ядре программы (реализованном на C++), работающем круглые сутки в различных режимах, и являющимся самой сложной частью OS_Quesha, исправление, устраняющее последнюю по времени, обнаруженную в нем ошибку, было выполнено в мае 2019 года. Кроме того в QUIK версии 8.4 проведены тестовые, стрессовые прогоны программы, в которых она без перезапуска работала месяцами. Технические подробности проведения тестовых прогонов описаны в инструкции OS_Quesha.pdf.
   Для версии QUIK 8.11  Lua 5.3.5 (ядро OS_Quesha не менялось, а только перетранслировалось из-за изменения версии Lua), на текущий момент времени, выполнены 3-х суточные тестовые прогоны OS_Quesha (аналогичные тем, которые были выполнены для младших версий QUIK). Проблем не  обнаружено.

В ТТТ есть следующие поля:
 "TRADE_DATE_CODE" - дата торгов
"TIME"  -  время последней сделки (с точностью до секунды)

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

Мой модифицированный тест управления автоматической памятью QLua  в версии QUIK 8.11  Lua 5.3.5, на текущий момент времени, проблем не обнаруживает.
---  
     1. Есть вопрос к поддержке QUIK:
   из Lua53.dll, кроме стандартных функций C-API Lua, экспортирует около 100 дополнительных функций. Зачем это делается?
Что не могут сделать разработчики QUIK, оставаясь в рамках стандартных функций C-API Lua?
-----
     2. Есть предложение:
   выкладывать библиотеки импорта (.lib) функций Lua53.dll (Lua54.dll и т.д.), например, в папке хранения файла info.exe. Понятно, что такие библиотеки можно создать на основе файлов dll, но, наверное, не все пользователи знают, как это сделать. Эти библиотеки нужны при перетрансляции C-пакетов QLua при переходе на новые версии Lua.

  Дополнительно, насчет минуса?:
 5) так как, по появлению нового события, в предложенном решении выдается сигнал, по которому (если есть ожидание потока main  на операции sleep_q)  запускаются колбеки скрипта, то мы имеем более оперативную  реакция пользовательского потока main по сравнению с существующим решением, и описанный вами фактор, в предложенном решении менее значим;
 6) в этом решении на пользовательские колбеки нет никаких ограничений (связанных с нагрузкой основного потока обслуживания скриптов), кроме понимания, того, что выполнение колбеков делается в пользовательском потоке;
 7) и еще раз: любая синхронизация (для того, кто понимает) - это геморрой, порождающий трудно исправляемые ошибки (совершенно неожиданные), от которого, если есть возможность, следует избавляться.

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

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

 Да.

 Правда.  При выполнении таких тестов (анализ выполнения потоков) необходимо для вывода сообщений вместо  message  использовать  PrintDbgStr. Сделайте такую замену и прогоните ваш тест заново. Для просмотра результатов используйте Dbgview.
     Я прогонял ваш тест (с предложенной вам заменой). Между сообщениями 'Before loop' и 'After loop' ни одно сообщение 'OnAllTrade' не вклинилось.

В QUIK 8.11 (QLua 5.3.5) обработка колбеков выглядит следующим образом.
1. QLua 5.3.5 однопоточный и тем самым снимаются вопросы по моему тесту управления памятью в многопоточном QLua.
2. В скрипте пользователя могут существовать два потока одновременно: поток main и основной поток, в котором запускаются колбеки скрипта. Причем выполнение любого из перечисленных потоков блокирует выполнение другого. Таким образом предполагается обеспечивать корректность работы двух потоков в однопоточном QLua 5.3.5.
   Переключение потоков реализовано следующим образом. Колбеки могут запускаться только тогда, когда поток main «висит» в операции sleep(<интервал ожидания>). Пока запущенный колбек выполняется, поток main не может продолжить свою работу, даже если истек его <интервал ожидания>.  Если, вдруг, в колбеке используется операция sleep(<интервал ожидания>), то она выполняется точно также, как это описано для потока main. То есть, зависание колбека на операции sleep допускает выполнение потока main, но при этом поток колбека «отвиснет» только тогда, когда поток main попадет на свою операцию sleep.
  Реализованную схему обработки событий элегантной назвать трудно, но она позволяет сохранить существующий пользовательский интерфейс.

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

 Мне, кажется, что Anton, действительно, сделал большую и качественную работу по улучшению обработки исключений в QLua. Наверное, можно бы было как то использовать и его исходники по обработке исключений, с каким-то реальным вознаграждением. Почему бы нет?