Средства разработки многопоточных скриптов в QUIK., OS_Quesha, свидетельство регистрации в Роспатенте № RU 2020612905. Бесплатная для некоммерческого использования.
После того как в QUIK 8.13.0.106 (с последними его исправлениями) синхронизация в QLua стала работать корректно (историю исправления можно посмотреть в ветке "Отладка QUIK 8.13" ), стабильность OS_Quesha, при работе в этой версии QUIK, стала такой же, как в старых версиях (до версии 8.5).
Обработка колбеков в OS_Quesha. Реализована эта обработка в соответствии с рекомендациями разработчика QUIK по использованию очереди параметров колбеков, которые обрабатываются в пользовательском потоке main. Особенности обработки колбеков в OS_Quesha следующие: 1) очередь реализована таким образом, что запись (из основного потока QUIK) и чтение (из потока main) в ней выполняется без синхронизации (никаких лишних переключений возможных при синхронизации), но корректно; 2) поток main активируется сразу после записи в очередь (не дожидаясь истечения интервала времени его ожидания в функции аналогичной sleep). Понятно, что основной поток при этом не блокируется, а реакция в main на колбеки реализована с минимальными задержками (в существующей архитектуре QUIK).
TGB написал: очередь реализована таким образом, что запись (из основного потока QUIK) и чтение (из потока main) в ней выполняется без синхронизации (никаких лишних переключений возможных при синхронизации)
Что имеется ввиду? Пока объект помещается в очередь (буквально - записывается значение в таблицу Lua) или читается из очереди, другой поток стоит. От переключений не ушли ))
Незнайка написал: Что имеется ввиду?Пока объект помещается в очередь (буквально - записывается значение в таблицу Lua) или читается из очереди, другой поток стоит. От переключений не ушли ))
В потоках чтение и запись в упомянутую очередь выполняются независимо. потоки не стоят и не ожидают.
Цитата
Артем написал: TGB , предлагаю вам реализовать библиотеку QLuaJIT вместо Qesha. Это будет действительно полезно.
И сколько вы готовы заплатить за это полезное ? Если меня нанимать, то я запрошу большие деньги.
TGB, мой друг из индии сделает качественнее, так что за деньги я лучше к нему обращусь. А вы тут работаете за идею как я вижу, значит можно вместо костылей спорных делать костыли полезные.
Артем написал: TGB , мой друг из индии сделает качественнее, так что за деньги я лучше к нему обращусь.
Ну! Пронесло Хорошо, что есть достойный конкурент. А то уже я стал бояться, что вы выкатите такую сумму, что мне придется забросить все свои дела и заняться этим полезным
После более 28000 прочтений данной ветки, мне показалось странным, что не был задан вопрос: почему OS_Quesha декларируется как операционная система реального времени?
Ответ. 1. Разработка любых роботов, в том числе роботов для фондового рынка это разработка программ (систем) реального времени, в которых обрабатываются внешние сигналы (информационные потоки) с минимальным участием человека. 2. Существуют различные определения ОС. Одно из них (например, на сай-те http://osys.ru/os/1/ponyatie_operatsionnoy_sistemy.shtml) следующее: «Операционная система (ОС) - комплекс системных и управляющих программ, предназначенных для наиболее эффективного использования всех ресурсов вычислительной системы (ВС) (Вычислительная система - взаимосвязанная совокупность аппаратных средств вычислительной техники и программного обеспечения, предназначенная для обработки информации)». Это определение краткое, емкое и, если под ВС понимать Windows, а также установленный в нем QUIK, то оно полностью определяет описанное в начальном комментарии ветки. 3. Реальное время в операционных системах — это способность операционной системы обеспечить, в заявленной сфере ее использования, требуемый уровень сервиса в определённый промежуток времени. При создании OS_Quesha были учтены следующие известные, основные требования к системам реального времени: 1) обеспечение предсказуемого времени обработки непредсказуемо возникающих внешних событий (обеспечен контроль ограничений на время выполнения циклических функций OS_Quesha; причем, для каждой функции может быть свое такое ограничение); это требование самое существенное, классифицирующее систему как СРВ; 2) надежность (последнее по времени изменение ядра OS_Quesha было внесено в мае 2019г.); 3) устойчивость функционирования при сбоях аппаратуры и программ (реализованы средства создания и использования контрольных точек при многопоточной обработки данных); 4) обеспечение обработки большого количества входных и выходных потоков данных, на обработку каждого из которых в отдельности, может требоваться незначительные вычислительные ресурсы (реализован режим псевдопотоков); 5) обеспечение непрерывности функционирования систем (OS_Quesha, при ее эксплуатации, работает без перезапусков в течение месяцев, до очередного обновления Windows); 6) учет динамичности таких систем (в OS_Quesha обеспечена возможность изменения схемы обработки данных в процессе ее функционирования); 7) контролируемость состояния систем (в OS_Quesha обеспечен контроль утечки памяти, блокировок и зацикливаний потоков, а также состояния очередей взаимодействия П/П).
Артем написал: По этому определению кстати веб-браузеры это тоже ОС.
Почему бы нет. Есть и такое мнение. Пошарьте в сети. -----
Цитата
Артем написал: Сборщик мусора луа и системный планировщик задач с этим несогласны. 😂
1. То есть, вы утверждаете: 1) программа торгового робота не является программой реального времени); 2) что торгового робота в Windows, в QUIKе написать невозможно. Читайте (обращая внимание на фразу "в заявленной сфере ее использования"):
Цитата
TGB написал: Реальное время в операционных системах — это способность операционной системы обеспечить, в заявленной сфере ее использования, требуемый уровень сервиса в определённый промежуток времени.
TGB, Я ещё не приводил своего давнего определения: "Операционная система реального времени - это задача, которая мешает моей задаче работать в реальном времени"? Хотя пункт третий Вашего определения мне нравится.
По этому определению, кстати веб-браузеры это вовсе не ОС, а, как им и положено, обычное прикладное говно: они не обеспечивают ни "наиболее эффективного использования всех ресурсов вычислительной системы" (а ГРОБЯТ эти ресурсы), ни "требуемый уровень сервиса в определённый промежуток времени" (а виснут почём зря на любом говне), ни "предсказуемого времени обработки непредсказуемо возникающих внешних событий" (иногда даже за клавой не успевают!), ни надёжности (версии меняются как перчатки - примерно с такой же скоростью, как и версии Квика - вот прям сегодня с утра поменял у одного из брокеров (по его предложению) очередное шило на мыло), ни "устойчивости функционирования при сбоях аппаратуры и программ" (они и без сбоев-то неустойчивы!), ни "обработки большого количества входных и выходных потоков данных" - НИ ХРЕНА! Впрочем, как и Windows, которую по какому-то недоразумению до сих пор называют "ОС".
TGB написал: 1) программа торгового робота не является программой реального времени); 2) что торгового робота в Windows, в QUIKе написать невозможно.
Программа, работающая на железке без RTOS и/или написанная на языке со сборщиком мусора - не работает в реальном времени. Написать робота в таких условиях можно, но говорить что он риалтаймовый - нельзя, в определение риалтаймовости не вписывается.
Я считаю реалтаймовость для торговых роботов вещью спорной полезности. Способность отреагировать в строго определенный (и короткий) промежуток времени и совершить транзакцию по цене максимум на 1-2 пункта лучше чем нериалтаймовый робот это ничтожный прирост эффективности на фоне общей турбулентности рынка и вариативности результатов торговли в зависимости от прочих параметров. Занимаясь целенаправленной разработкой таких вещей вы скорее всего потратите больше денег чем заработаете на этой разнице за всё последующее время торговли, исключая уровень оборота миллионами долларов в сутки и выше.
Артем, Кто Вам сказал эти глупости? Каким образом сборщик мусора может помешать работе в реальном времени? Разве что написан криворукими бездарями. Тем более, что диспетчер памяти идеологически как раз функция ОС.
Не знаю, что там у Вас "в определение риалтаймовости вписывается", но я когда-то был включён в соавторы бортовой операционки, которая так и называлась: "ОСРВ" (или RTOS, если угодно). А свой "фон общей турбулентности рынка и вариативность результатов торговли" засуньте лучше куда-нить подальше - Вы в этом абсолютно нихрена не понимаете. Реальное время не имеет никакого отношения к придурочной технологии HFT.
Владимир, все сборщики мусора работают в фоне и активируются с некоторой, в целом хаотичной, периодичностью, и во время работы полностью тормозят выполнение основной программы. Это создаёт неприемлимый джиттер даже в системах с низкими требованиями к реалтаймовости - выполнение цикла ГЦ может занимать несколько десятков миллисекунд за раз. Кто помнит перевернувшийся раллийный автомобиль под управлениям робота на джаве? ГЦ завесил программу на долю секунды, именно столько и потребовалось чтобы прошляпить критический момент. А по поводу чего я там не понимаю - давайте не будем отрицать что способность робота вести торговлю в плюс (и размер этого плюса) целиком зависит от настройки гиперпараметров алгоритма.
TGB, робот который торгует в реалтаймовом режиме. Определение реалтаймовости сами найдете я думаю.
Артем, Вот именно, В ФОНЕ! Чтобы не мешать выполнению основных задач. Ну, а если они "во время работы полностью тормозят выполнение основной программы", то это ТОЛЬКО криворукость программеров! Я вот на днях решил довести до ума точный алгоритм решения задачи коммивояжёра, так напоролся как раз на отсутствие там диспетчера памяти. А этой задаче (в отличие от несчастного торгового робота) ОГО-ГО как требуются ресурсы! Мало того: это ФАЙЛОВАЯ память (чтобы иметь возможность в любой момент отложить задачу вместе с дампом её состояния). Мало того: блоки этой памяти ничтожно маленькие, т.е. это по определению не задача ОС, а именно моего "Комми". Мало того: эта память используется для хранения дерева вариантов (думаю, здесь, как и в шахматах, невыгодно приводить дерево к графу общего вида), а потому объём мусора меняется с чудовищной скоростью и куски его разбросаны по этому файлу со страшной силой! И что, полагаете, что этот мой диспетчер будет "во время работы полностью тормозить выполнение основной программы"? Да ни капельки! Я вот с утра сделал какое-то описание (набросок ТЗ). Фрагменты оттуда:
Блоки всегда по 24 байта, если этого недостаточно для размещения необходимой информации, используется несколько блоков.
Блоки связаны в дерево, то есть у них есть два служебных поля: AR (адрес вправо) и AD (адрес вниз). В некоторых случаях поле AR может отсутствовать. При освобождении блоков они передаются в дерево свободных блоков для повторного использования. Блоки хранятся в файле мультиузлов, адрес (точнее, индекс) входа в первый блок данных (как и в первый блок дерева свободных блоков) хранится в паспорте этого файла. Сами блоки располагаются сразу после паспорта.
И далее описание содержимого блоков различного функционального назначения. И вся эта кухня будет прекрасно работать - гарантирую! Как аналогичная техника динамического освобождения памяти (только не в файле, а в ОЗУ) прекрасно работала в нашей шахматной программе.
ЧИВО-ЧИВО-ЧИВО?! Это что там за зверь такой "настройки гиперпараметров алгоритма"? Лично у меня робот, главным образом, спит, и это ничуть не снижает способность робота вести торговлю в плюс (и размер этого плюса меня более, чем устраивает - он заметно выше моих первоначальных ожиданий).
Владимир, длина среза торговых данных, с которыми работает робот - один из гиперпараметров. По аналогии можете представить какие другие переменные являются гиперпараметрами.
Вы видимо плохо себе представляете что такое сборщик мусора. Работать не останавливая основной тред они не могут принципиально, так как нужно подсчитать сколько референсов имеется на каждый объект и это невозможно сделать когда соседний тред меняет эти референсы.
Артем, А что такое "длина среза торговых данных, с которыми работает робот"? Мой ни с чем таким не работает. И огласите весь список, пжалста - чо там за гиперпараметры? Нет у меня никакой аналогии! Ах, да - есть одна. Как я когда-то писал про браузеры: Ещё одной важнейшей составляющей политики тупорылых стала безудержная реклама их эпохальных достижений - какие невероятно сложные проблемы они решают, как дорого это стоит, какое счастье для пользователя, что именно они взялись за это архисложное дело. Маленький пример: в реальности на компьютер клиента передаётся обычный текстовый файл, разбавленный там и сям тегами форматирования, а также тегами, позволяющими осуществлять переход между веб-страницами. Просто и скучно - не правда ли? Но только не для тупорылых: разве можно такое сказануть пользователю? Нет, они сразу увидели здесь не просто текст, а супер-пупер-гипер-текст! Остановились, разумеется, на "гипер".
Это Вы плохо себе представляете что такое сборщик мусора! Если "работать не останавливая основной тред они не могут принципиально", то это ГОВНО, а не сборщик мусора! А вот если это составная часть диспетчера памяти, то он же эту память и выделяет. И "референсы" эти несчастные может держать в своих служебных полях и считать их сразу по мере возникновения - это практически НИЧЕГО не стоит! А вот если рыскать по данным и заниматься всей этой хернёй - тогда да, базара нет!
Чо там у нас Вики-то говорит?.. О, ещё Джон Маккарти этим занимался! Маккарти - это Голова! И я уверен, что у него-то был прекрасный сборщик мусора!
В промышленных процедурных и объектных языках сборка мусора долго не использовалась. Предпочтение отдавалось ручному управлению памятью, как более эффективному и предсказуемому. Но со второй половины 1980-х годов...
Ну, всё понятно: тогда-то вместо нормальных диспетчеров памяти и полезло подобное говно. Памяти ведь сейчас хоть жопой жуй, так надо срочно присобачить какую-нить хрень, которая бы с этой памятью игралась, чтобы опирающиеся на неё программы периодически глючили. Другой причины использования сборщика мусора я что-то не вижу.
Владимир, вот такие как вы профессиАналы делают сборщик мусора простым инкрементом, а потом недоумевают почему память течёт. Интересно что вы создателя Лиспа сюда упомянули, при том что в Лиспе сферический в вакууме сборщик мусора, и который тормозит исполнение скрипта, и сканирует все переменые на предмет референсов, и не может поймать острова памяти, и вручную не выключается.
То что ручная работа с памятью быстрее работает это ни у кого сомнений не возникает. Равно как и то, что теперь стоимость лишних серваков из-за медленных языков и в частности сборки мусора гораздо меньше стоимости человекочасов разработчиков, которые могут в таком объеме вручную памятью управлять. С ростом аппаратных мощностей снизился и входной порог в области программирования. Платить больше там где можно получить тот же результат дешево или вообще бесплатно - логически нецелесообразно и экономически неэффективно для всей системы.
Артем, Так, про "гиперпараметры" мы более ничего сказать не можем? Поквакали - и в тину?
Лапуль, программист я средненький, хоть и системщик, но я много раз видел работу Настоящих Профессионалов, Виртуозов программирования, уровня которых мне не достичь НИКОГДА! Алгоритмист я действительно высокой квалификации: много раз видел равных мне, качественно выше - ни одного не попадалось. Но когда такие полуграмотные шавки, как Вы, чего-то вякают про "Аналы", даже моей квалификации как программиста более, чем достаточно, чтобы "заткнуть им пасть".
Маккарти - Великий Программист! Идеолог целого направления в программировании, кроме операторного. Это не какой-нибудь сраный Страуструп! И даже если он (как и все, кто хоть что-то делает) где-то в чём-то ошибался (уж идею сборщика мусора никак нельзя было быдлу от программирования подкидывать!), то всё равно он неизмеримо выше любой тявкающей на него шавки. Я помню, Володя Волков сделал когда-то компилятор Лиспа - и это уже ЕГО компилятор, а не Маккарти! Ну так это Володя! Что же могут сотворить нынешние головожопые, у которых "в Лиспе сферический в вакууме сборщик мусора, и который тормозит исполнение скрипта, и сканирует все переменные на предмет референсов, и не может поймать острова памяти, и вручную не выключается" - я даже не могу себе представить. Одно знаю точно: Джон Маккарти не имеет к этому НИ МАЛЕЙШЕГО отношения!
Вот скажите мне, сударь: НАКОЙХЕР вообще нужен этот грёбаный "сборщик мусора"? ВОТ ЧТО ЕМУ ДЕЛАТЬ, например, в моём скрипте? Гадить висячими ссылками? Мешать ему работать в реальном времени? ОТЛЕЗЬ, ГНИДА! Это МОИ объекты, и не твоё свинячье дело, когда их удалять! Нет ссылки? А может, она через пять минут появится! * ты лезешь своими грязными лапами туда, куда тебя не просят?
Владимир, мне не платят чтобы вам лекции по информатике читать. Направление я показал - дальше сами, гугол в помощь. Сделать свой компилятор лиспа это кстати типовая часть обучения в области компиляторов, ничего особого тут нет.
Артем написал: Я считаю реалтаймовость для торговых роботов вещью спорной полезности. Способность отреагировать в строго определенный (и короткий) промежуток времени и совершить транзакцию по цене максимум на 1-2 пункта лучше чем нериалтаймовый робот это ничтожный прирост эффективности на фоне общей турбулентности рынка и вариативности результатов торговли в зависимости от прочих параметров. Занимаясь целенаправленной разработкой таких вещей вы скорее всего потратите больше денег чем заработаете на этой разнице за всё последующее время торговли
Если заменить в выше написанном «реалтаймовость» на высокочастотность (смотрите ее описание в сети) , то, с написанным, я, в основном, согласен. Однако, если обсуждать не стратегии торговли, а средства их реализации, то такие средства должны обеспечивать достаточно быструю реакцию на события, происходящие на фондовом рынке. Конкретно, в экспериментах (с включенным мусорщиком QLua) проверено то, что, в OS_Quesha интервал времени между событиями OnParam (это самые частые события в QUIK) и записью 18 параметров по 24 бумагам в их циклические буфера, менее 1 млсек. c вероятностью более 0,99. При этом, в колбеках OnParam выполняется только неблокирующая короткая запись параметров бумаг в очередь, а все остальное выполняется в main. Наверное, для большинства пользователей QUIK, такая скорость реакции вполне приемлема. Таким образом, как было мною ранее написано: «в заявленной сфере использования OS_Quesha, обеспечивается требуемый уровень сервиса в определённый промежуток времени». То есть OS_Quesha является системой реального времени для реализации торговли на фондовом рынке, исключая высокочастотную торговлю. Другое дело, что общие задержки на события фондового рынка при обычном использовании QUIK определяются следующими формулами: 1) <Общая задержка получения данных> = <Подготовка данных на бирже> + <Передача брокеру> + <Обработка брокером> + <Передача данных пользователю> + <Обработка данных в QUIUK и запуск колбенов> + <Реакция в пользовательской программе на колбеки>; 2) < Общая задержка выдачи пользовательских команд > = < Обработка в пользовательской программе полученных данных >+ <Передача команд в QUIUK > + <Обработка команд в QUIUK > + <Передача брокеру> + <Обработка брокером> + <Передача команд пользователя брокером на биржу> + <Выполнение команд пользователя биржей>. Понятно, что задержка <Реакции в пользовательской программе на колбеки> на фоне остальных составляющих <Общей задержки получения данных> может быть для многих пользователей не сильно критической, но все равно лучше, если эта задержка будет маленькой.
Владимир написал: Сами же участники, как правило, легко затыкают подобным шавкам пасть.
На примере вас двоих тут скорее ситуация вида игры в шахматы с голубем - после нескольких попыток даже самые отбитые аутисты перестанут пытаться, а голубь все равно будет считать себя безсомненным победителем всегда и везде в любом случае.
TGB написал: Если заменить в выше написанном «реалтаймовость» на высокочастотность (смотрите ее описание в сети) , то, с написанным, я, в основном, согласен.
HFT требует реалтаймовость, одно без другого не работает. Я говорил про обычного робота который использует вместо обычной среды - реалтаймовую. В отсутствие джиттера это позволило бы не прозевать пару лишних тиков и получить чуть лучшую сделку по сравнению с роботом, у которого система может вызвать случайные задержки по несколько миллисекунд.
Владимир,Эх помню как тоже сначала пытался ловить тики, чтобы не прозевать самую лучшую цену, вместо одной заявки скрипт только и делал, что ставил, снимал заявки пока не поймает цену, дрочилово то еще было. Потом как вы начал выставлять заявки по ценам спроса/предложения, но после нескольких раз "гонок" с рынком, эту идею тоже отбросил. Сейчас при наличии сигнала просто бью по рынку, всего одна заявка которая тут же превращается в сделку, и наступило счастье..
BlaZed, Именно! А от "дрочилова" у меня такое средство: если заявка по данному тикеру подана, выставляется тайм-аут в 5 минут (или 4, не помню), и пока он не истечёт, никаких новых заявок. При этом гарантированно все прерывания по сделкам (они же приходят пачками) уже пройдут. А каждое такое прерывание (если заявка в несколько лотов, и не все они реализуются за одну сделку) продлевает этот тайм-аут: время начинает отсчитываться уже с неё. Правда, эта скотина оказалась изобретательная: она честно выдерживает эти 5 минут, после чего снимает несработавшую заявку (или её остаток), и в ту же секунду выставляет новую - эту подлянку я до конца ещё не поборол.
Владимир написал: BlaZed, Именно! А от "дрочилова" у меня такое средство: если заявка по данному тикеру подана, выставляется тайм-аут в 5 минут (или 4, не помню), и пока он не истечёт, никаких новых заявок. При этом гарантированно все прерывания по сделкам (они же приходят пачками) уже пройдут. А каждое такое прерывание (если заявка в несколько лотов, и не все они реализуются за одну сделку) продлевает этот тайм-аут: время начинает отсчитываться уже с неё. Правда, эта скотина оказалась изобретательная: она честно выдерживает эти 5 минут, после чего снимает несработавшую заявку (или её остаток), и в ту же секунду выставляет новую - эту подлянку я до конца ещё не поборол. ::
Предположу, когда таймаут заявки вышел, алгоритм должен снять заявку и обнулить сигнал, после чего заново оценить рынок, чтобы дать или не дать новый сигнал на покупку/продажу. Если сигнал по какой-либо причине не обнуляется, то как раз вышеописанное поведение и будет наблюдаться.
Владимир, мой робот не реалтаймовый, и я как раз говорил что гораздо важнее иметь получше алгоритм чем побыстрее торговый аппарат. Экономический алгоритмист из меня примерно никакой так что я задействую машинное обучение - результаты пока так себе, но прогресс есть.
BlaZed, сделки будут совершаться по рыночной цене в любом случае, устанавливая цену регулируется в целом только то, в какой момент (или вообще) будет совершена сделка. Лучшая цена сделки обычно движется в одном и том же направлении и после принятия решения совершить сделку можно просто ждать, пока это направление не поменяется. В зависимости от настройки гистерезиса можно и прозевать несколько делений от лучшей цены, но можно и не застрять на локальном минимуме.
BlaZed, Он так и делает, но даёт новый сигнал. Я же говорю, что эта сволочь изобретательная! Причём там довольно хитрые зависимости: иногда по истечении таймаута нужно просто не снимать заявку, а иногда не пускать новую. Да и процесс формирования сигнала довольно сложный. С продажей проще - там алгоритм тиковый, а вот на покупку, как правило, свечной, да ещё и хрен знает от какого таймфрейма прилетевший. Обычно со второй или с третьей попытки сделка всё равно происходит (чуть дороже или чуть дешевле), да и не так часто это происходит (2-3 раза в день), так что пока таке поведение не очень раздражает, но уже начинает надоедать.
Артем, А мой робот - реалтаймовый (в моём определении). Экономист из меня тоже никакой, но алгоритмист я очень даже неплохой. Я уж и не помню, когда последний раз код правил: месяца полтора, я думаю.
Насколько я понял, BlaZed, говорил про подачу заявки по рыночной цене. Меня это не устраивает - хрен знает, что там с рынком может произойти, так что я предпочитаю совершать сделки именно по той цене, которая указана. Или, по крайней мере, не худшей, так что заявки у меня всегда лимитированные.
Владимир написал: Насколько я понял, BlaZed, говорил про подачу заявки по рыночной цене. Меня это не устраивает - хрен знает, что там с рынком может произойти, так что я предпочитаю совершать сделки именно по той цене, которая указана. Или, по крайней мере, не худшей, так что заявки у меня всегда лимитированные.
У меня алгоритм такой, что я всегда либо в продаже либо в покупке сижу, потому мне важнее не конкретная цена сделки, а сам факт войти в шорт либо лонг при определенных условиях рынка.
Владимир, если не стесняетесь добавить в логику ценовой политики рассчет стоимости плеча и сделок репо, то шорты нетрудно добавить - они просто инверсия лонгов. Не считая ситуаций когда прибыль съедается комиссией, где по лонгам потери там по шортам прибыли.
Артем, Я где-то сказал, что это трудно? Моему алгоритму шорты нафиг не нужны. Фрагмент из его описания: "Мы не играем на медвежьих курсах вообще - так и проще, и надёжнее, и даже честнее".
Уважаемые участники дискуссии, призываем Вас сохранять корректный тон своих высказываний!
Если не внемлете просьбе - простым удалением сообщений (как сейчас) отделаться не получится. Хотите продолжать общаться на нашем форуме - будьте любезны прислушаться. Заранее спасибо за Ваше понимание.
Alexey Ivannikov написал: Уважаемые участники дискуссии, призываем Вас сохранять корректный тон своих высказываний!Если не внемлете просьбе - простым удалением сообщений (как сейчас) отделаться не получится.
У поддержки есть все возможности быстро навести порядок на форуме и мы это увидели.
Одной (но не единственной) причиной реализации многопоточности OS_Quesha было: отсутствие в QUIK нормальных средств создания диалога. Тот, кто рискнет использовать таблицу QUIK для создания диалога, точно, легких путей не ищет и это подтверждается многочисленными, многогодовыми обсуждениями на разных форумах тех многих проблем, которые при этом возникают. Когда мне пришлось перейти на QUIK (в 2019г.), для меня быстро стало понятно, что, то время, которое уйдет на «кувыркание» с таблицами QUIK, лучше потратить на разработку многопоточности, обеспечивающей, наряду с простой реализацией диалога, решение и других задач перевода моего робота на QUIK. Возможность порождения в OS_Quesha отдельного потока, обслуживающего диалог, обеспечивает простоту использования существующих бесплатных графических пакетов. В OS_Quesha был выбран «легкий» (код менее 2Мб) пакет IUP. Этот пакет в текущий момент стабилен и в нем есть версия для работы в Lua. При использовании данного пакета в отдельном потоке, никаких проблем я не обнаружил. Те графические возможности, которые он обеспечивает, для меня, оказались более чем достаточными. Форма диалога OS_Quesha запускается в отдельном потоке (никак не связан-ном с основным потоком QUIK, обслуживающим все колбеки и таблицы QUIK), отдельно от окна QUIK и имеет следующий вид: В ней есть следующие элементы: 1) меню системы состоящее из двух частей: - служебной: Рынок ЦБ, Отладка, Система - прикладной (пользовательской): Меню1(образец), Меню2(образец) 2) поле вывода сообщений диалога; в это поле выдаются сообщения-ответы на вводимые команды, а также сообщения о критических ситуациях в системе; 3) поле ввода команд; это поле является командной строкой и используется для ввода сложных команд; строки, не являющиеся служебными командами OS_Quesha, считаются командами приложения и передаются в функцию cmd_OS_Quesha разбора и выполнения команд приложения, описанную в шаблоне TS_QUIK.lua; 4) поле вывода сообщений системы; в это поле выдаются сообщения о ситуациях, возникающих в системе, не связанных с диалогом.
Всё вводимое и выводимое полей рабочего места пользователя сохраняется в потокобезопасном журнале диалога OS_Quesha с фиксацией времени возникновения с точностью до 1 миллисекунды. Диалог создается на основании его описания (в табличном виде), представленном в шаблоне TS_QUIK.lua, в котором определяются следующие характеристики: 1) структура меню системы («дерево» меню) и реакции на вызовы его команд; 2) размеры всех полей диалога; свойства окон вывода сообщений (очередь/стек и т.д.); 3) пользовательские меню (примеры Меню1(образец), Меню2(образец)) с заданием пользовательских функций, обрабатывающих команды этих меню (в том числе с заданием любых объектов пакета IUP); 4) пользовательская функция разбора сообщений поля ввода команд, отлич-ных от служебных. ---- При необходимости, OS_Quesha может быть запущена без формы диалога (это задается в глобальных настройках системы) и тогда все сообщения системы выдаются непосредственно в QUIKе функцией message, но журнал системы при этом ведется как обычно.
TGB, Ну, я "рискнул использовать таблицу QUIK для создания диалога", и при этом именно "искал лёгких путей".
Я свято убеждён: "нормальные средства создания диалога" предполагают возможность программирования в событиях - все остальные способы ненормальные. А здесь даже и слова такого нет.
Многопоточность для задач торговли тоже вряд ли нужна - во всяком случае, в Квике это лишь неиссякаемый источник глюков.
Структура меню также не выдерживает критики: у меня это «дерево» меню содержит несколько сотен веток от корня (думаю, вскоре дойдёт до пары тысяч) и время от времени хочется нарастить его до 3-го уровня, причём с редактируемыми элементами. Но потом вспомнишь, как Квик отвисает от команд, пришедших даже из первого уровня иерархии - и всё проходит.
Владимир написал: Я свято убеждён: "нормальные средства создания диалога" предполагают возможность программирования в событиях - все остальные способы ненормальные. А здесь даже и слова такого нет.
Ну, не буду же я здесь описывать пакет IUP. В его описании есть события.
Цитата
Владимир написал: Многопоточность для задач торговли тоже вряд ли нужна - во всяком случае, в Квике это лишь неиссякаемый источник глюков.
Многопоточность удобна для меня. И для меня глюки многопоточности давно исчезли на старых версиях QUIK, а сейчас и на новых версиях QUIK.
Цитата
Владимир написал: Структура меню также не выдерживает критики: у меня это «дерево» меню содержит несколько сотен веток от корня (думаю, вскоре дойдёт до пары тысяч) и время от времени хочется нарастить его до 3-го уровня, причём с редактируемыми элементами. Но потом вспомнишь, как Квик отвисает от команд, пришедших даже из первого уровня иерархии - и всё проходит.
Владимир написал: у меня это «дерево» меню содержит несколько сотен веток от корня (думаю, вскоре дойдёт до пары тысяч) и время от времени хочется нарастить его до 3-го уровня, причём с редактируемыми элементами.
Интересно, что вы делаете с тысячами командами. Вы что, тетрикс реализовали
TGB, Да очень просто: таблица по тикерам и есть меню. А дочерние уже содержат информацию по выбранному тикеру. Но, поскольку она бывает довольно объёмная, неплохо было бы иметь и дочерние уже от него (например, по сделкам, по свечам. И редактировать в них кое-что не мешало бы.
TGB, Именно описывать! Не "пакет IUP", конечно, а возможности прикладника при программировании в событиях.
Ваще-то, согласен: многопоточность - штука полезная, но в нынешней реализации я побаиваюсь любых нововведений. Особенно алгоритмически сложных, вроде многопоточности.
Я за свою жизнь немало диалоговых программ написал, так что у меня собственное представление, что такое "классическая структура". Фрагмент из моей книги:
Честно говоря, мне жаль выбрасывать средства организации диалога в SINT – за долгие годы там накопилось немало интересных решений: горизонтальные, вертикальные, двумерные, трёхмерные, виртуальные (невидимые), неоднородные, редактируемые меню, управление курсором, горячие клавиши, виртуальные клавиши, клавиши «внутрь» и «наружу» для каскадных (Z-меню), трёхмерных или двумерных меню специального вида (XZ или YZ), организация контекстной помощи и диагностики на ошибки, автоопределение координат или палитры, работа мыши в активных и неактивных координатах меню, локальные меню блоков, синхронизация изменения данных в параллельных окнах, плавающий размер паспорта меню, возможность задания собственного «бланка» меню с указанием на нём координат элементов, переопределение объектов до прорисовки меню, до цикла ожидания события, во время ожидания, после обработки события, перед выходом из меню (одно это расширяет возможности программиста со страшной силой – можно, например, организовать меню из элементов базы данных с их подкачкой и редактированием), разгон при листании некоторых видов меню… да разве всё перечислишь! Я даже немного баловался с «очеловечиванием» диалога: выдавал диагностики системы не статическими строками, а генератором фраз (техника вариантных списков) – склейкой фразы из компонентов-синонимов случайным образом. Получалось довольно эффектно: компьютер уже казался не тупой железякой, а живым собеседником. Или, по крайней мере, полуживым. Но больше всего жалко, конечно, применяемую в SINT технологию программирования диалога в объектах и событиях, которую при использовании веб-браузера практически невозможно сохранить. Частично её удаётся эмулировать путём использования фреймовой структуры, чудом сохранившейся функции eval «и какой-то матери», хотя это просто слёзы по сравнению с организацией диалога в SINT. Тем более, что каждый браузер (а нередко даже и разные версии одного и того же браузера!) работают, мягко говоря, по-разному. Этот раздел и посвящён браузеру как клиентской части СУБД. Второе его название – «Хождение по мукам». Или даже «Mein Kampf».
Владимир написал: таблица по тикерам и есть меню. А дочерние уже содержат информацию по выбранному тикеру. Но, поскольку она бывает довольно объёмная, неплохо было бы иметь и дочерние уже от него (например, по сделкам, по свечам
А пусть дочерние (в виде строк) содержат всю необходимую вам информацию по выбранному тикеру в виде сереализованной таблицы Lua. При этом нет никаких ограничений и без использования дочерних уже от него.
Имеем N тикеров... нет, даже не так: имеем N валют, M тикеров по каждой валюте, К сделок по каждому тикеру с указанием цены и объёма каждой из них, текущий выигрыш (проигрыш) по каждой валюте и каждому тикеру, заявки на покупку (продажу), стоп-лоссы, свечи по 9 таймфреймам (надо бы по 16), таймер когда снимать неисполненные заявки, код тикера/код класса/размер лота, код качества тикера (плохой/нормальный/хороший/отличный), код его статуса (можно/нельзя его роботу покупать/продавать), цена последней сделки/спроса/предложения, количество наличной валюты (на которую скрипту разрешено торговать), количество заблокированной валюты, статус кошелька по валютам (избыток/нехватка наличности) плюс всякая мелочь (код клиента, торговый счёт, обработчики событий от юзера и прочая хрень). Кроме того, данные там меняются со страшной силой - даже головное меню раз в 15 секунд может серьёзно поменять количество своих элементов! И вот это всё Вы предлагаете запихивать В СТРОКУ? Побойтесь Бога!
TGB, Во-первых, дерево-то можно, а вот граф произвольного вида - уже нельзя. У меня там на уровне хранения дерево, но на логическом уровне уже граф. Во-вторых, ЗАЧЕМ? НА КОЙ мне эта "серализованная таблица Lua", что я с ней делать-то буду? Мои данные сложнее, они в таблицу просто не лезут.
Да я-то свои проблемы давно решил - диалог меня давно уже устраивает. То, что ещё хотелось бы иметь, относится уже скорее к области выпендрёжа.