Средства разработки многопоточных скриптов в QUIK., OS_Quesha, свидетельство регистрации в Роспатенте № RU 2020612905. Бесплатная для некоммерческого использования.
Ссылка на коды и документацию 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). Проблем не обнаружено.
Дожили! Уже и операционку под каждую сраную прикладную задачу разрабатывать будем! Бегло пролистал пост - УЖАС!!! На досуге почитаю внимательнее.
Когда-то давно мен включили в соавторы одной операционки, которая так и называлась: ОСРВ - операционная система реального времени. Примерно тогда же я давал определение: "Операционная система реального времени - это задача, которая мешает моей задаче работать в реальном времени". Но мне и в страшном сне не могло привидеться, что ОС будет разрабатываться под одну задачу - тем более, смехотворно нетребовательную к ресурсам.
Пока пролистывал текст, глаз зацепился за: "В скрипте-шаблоне создания роботов с использованием OS_Quesha запускается 16 потоков". Слов нет. Даже матерных. Вернее, есть одно, на "п" начинается, на "ц" заканчивается. И, слегка кося под Нострадамуса, предрекаю: эта хрень не будет работать НИКОГДА!
Программа реализует в скриптовом языке программирования QLua параллелизм выполнения его функций, обеспечивая использование многопроцессорности вычислительных систем. Здесь и одному процессору нечего делать - тем более, что основной язык вообще интерпретируемый.
Но вместо sleep используется API-функция OS_Quesha ожидания либо истечения интервала времени (паузы циклической функции), либо появления данных во входных очередях таких функций. Что ещё за "либо"? Sleep и есть функция ожидания. А появление чего-то там в очередях иногда (очень редко) есть основание для передачи управления по прерыванию - те самые коллбеки, и они никого отношения не имеют к циклу в main. По-нормальному, как раз main должна бы входить в режим "вечного" ожидания, если сделать коллбек и по таймеру, и получать управление взад только по OnStop чего она, кстати, и не получает вообще (точнее, получение управления не гарантировано), так что приходится выполнять завершающие действия прямо в OnStop.
Взаимодействие циклических функций между собой после запуска на выполнение в потоках, сводится к чтению своих очередей и записи своих данных в чужие очереди. То есть на обслуживании данных вне очереди поставлен большой и жирный крест? Похвально!
Дополнительно, предоставляются средства синхронизации, которые могут потребоваться при использовании модифицируемых общих данных потоков, но, по возможности, этого лучше избегать. СТОЯТЬ! НЕ ДЫШАТЬ! НИЧЕГО НЕ МОДИФИЦИРОВАТЬ! ОПЕРАЦИОНКА РАБОТАЕТ! Подобная ситуация была гениально описана много лет назад: Контpоллеp пpеpываний - обpаботчику пpеpываний: Тут это... юзеp кнопку нажал... Главная пpогpамма - обpаботчику пpеpываний: Hе деpгайся! Подеpжит и отпустит. ... Контpоллеp пpеpываний - обpаботчику пpеpываний: Тут это... юзеp опять кнопку давит... Обpаботчик пpеpываний - PC speaker'у: Hу скажи ему что-нибудь, пусть отвяжется! PC speaker - юзеpу: Биип! ... Контpоллеp пpеpываний - обpаботчику пpеpываний: Тут юзеp Ctrl-Alt-Del жмет! Главная пpогpамма - обpаботчику пpеpываний: Да отpуби ты этому зануде клавиатуpу! Мы тут делом заняты...
1) схема обработки колбеков в виде очередей событий QUIK, минимизирующих влияние последующей обработки событий на основной поток запуска скриптов и генерации событий QUIK; Вы там сделали, наконец, чтобы одно событие вызывало только ОДНО прерывание или "как всегда"?
2) сохранение истории одноминутных и пятиминутных котировок ценных бумаг в базах sqlite; О, Господи! Это ещё на кой? Чтобы процессор чем-то занять?
3) оперативное сохранение текущих котировок 22-ух (по 18 параметрам) торгуемых бумаг в циклических буферах с задержкой < 1 млсек относительно момента возникновения событий OnParam; И эти миллисекунды ловят... не лечится.
2. Создание настраиваемого диалога с пользователем. Пользователь имеет возможность добавлять в форму диалога свои меню. А чего же ему не иметь? Я вот создал себе диалог с контекстными меню на чистейшем Lua, и горя не знаю.
3. Ведения журналов OS_Quesha (диалога и отладки) с милисекундным разрешением. Постоянный вопрос за всё время чтения этого опуса: НА КОЙ это всё?
4. Запуск на выполнения Lua-функций в фоновом режиме в отдельных потоках. Тот же вопрос.
5. Работа с контрольными точками (для продолжения работы с прерванного, по любой причине, места). УПАСИ, ГОСПОДИ! Только корректный перезапуск скрипта! Опять ищем на свою задницу приключений?
7. Ведение истории котировок (одноминутных и пятиминутных) в базах SQLite. Лично я считаю свечи сам. Тупо, по цене закрытия, как среднее арифметическое (все эти "японские премудрости" я давным-давно послал на), "зато" сразу по нескольким интервалам: 15-секундные, полуминутные, минутные, двухминутные и далее со всеми остановками. Сначала считал по 16 интервалам, потом сократил до 9, поскольку более тяжёлые свечи мне оказались нафиг не нужны. В любом случае, затраты времени на эту арифметику ничтожны, несмотря на то, что считается это всё также на чистейшем Lua.
8. Ведение текущих дневных котировок в векторах оперативной памяти. ПАЦТАЛОМ!
9. Эффективная схема обработки событий QUIK в виде циклических потокобезопасных очередей получения данных колбеков (реализованных без синхронизации). Да хрен бы с вашими "циклическими потокобезопасными очередями"! Сделали ОДИН коллбек на ОДНО прерывание? За это (и ТОЛЬКО за это!) юзеры вам скажут спасибо.
10. Обеспечение интерфейса реализации торговых индикаторов на основе текущих котировок. Никогда не понимал, на кой вообще нужны индикаторы. Есть же скрипт! И этого более, чем достаточно.
11. Обеспечение виртуальной торговли ценными бумагами. ЧАВО?! А это что за зверюга такая?
TGB, Дык в самом начале написано, чёрным по белому: "Программа представляет собой специализированную операционную систему реального времени, работающую в среде программного комплекса QUIK". То есть она предназначена именно для сраной прикладной задачи организации торговли ценными бумагами в QUIK. У меня сейчас аж две такие задачи крутятся на этом компе.
НА КОЙ, простите, мне эту хрень устанавливать у себя? У меня торговля прекрасно организована - зачем мне её гробить? Зачем искать на свою задницу приключений? Какое мне дело до того, что она "без перезапуска работала месяцами"? КАК ИМЕННО она работала? Квик, вон, тоже работает месяцами, а глюков в нём просто НЕМЕРЯНО!
Владимир написал: НА КОЙ, простите, мне эту хрень устанавливать у себя?
Читаем:
Цитата
Владимир написал: если ваш робот простой и не требует возможности, предоставляемых OS_Quesha, то, скорее всего, его проще создать в виде обычного QLua-скрипта.
TGB, Мой робот простой, ибо задача организации торговли достаточно примитивна. Именно поэтому я и создал его в виде обычного QLua-скрипта. НИКАКИХ дополнительных возможностей никакая OS_Quesha мне предоставить не может.
Я уже видел изделие в прошлый раз, на другом ресурсе. Кажется, что кота в мешке лучше не здесь показывать. Тем более с ссылкой на архив непонятного содержания на mail.ru. Код библиотек не проверить, луа код - ... Вы бы хоть абсолютные пути и отладочные выражения убрали из поставки, если это продукт. Лицензия не ясна. Я такое только в виртуалках распаковываю. А уж про запуск на рабочем сервере - даже не обсуждается. Интерфейс на iup уже вызывает вопрос о необходимости даже пробовать.
Что касается простой/сложный робот, то как-то не увидел проблем в написании скрипта с сложным интерфейсом и псевдоасинхронной обработкой очередей событий.
Раз уж Вы разместили это здесь, то хотелось бы увидеть пример применения, где средств lua будет явно недостаточно и необходимо использовать данный продукт.
В нормативно-правовых актах определено некоммерческое использование: "Допускается без согласия автора или иного правообладателя воспроизведение, осуществляемое только гражданином и только в личных целях, под которыми по смыслу статьи 1273 Кодекса понимается последующее некоммерческое использование соответствующего экземпляра для удовлетворения собственных потребностей или потребностей обычного круга семьи этого гражданина (который определяется судом с учетом конкретных обстоятельств рассматриваемого дела)." (Постановление от 26 марта 2009 г. № 5/29 Пленума Верховного Суда Российской Федерации и Пленума Высшего Арбитражного Суда Российской Федерации)
Цитата
Nikolay написал: Раз уж Вы разместили это здесь, то хотелось бы увидеть пример применения, где средств lua будет явно недостаточно и необходимо использовать данный продукт.
Список операций, поддерживаемых Lua алгоритмически полный. То есть, на этом языке можно реализовать любой алгоритм. Но точно также, можно задать похожий вопрос: почему бы вместо Lua не использовать ассемблер? Назначение данного продукта не в том чтобы заменить Lua. Это в каком-то смысле «станок» с готовой инфраструктурой, которая в том или ином виде требуется для разработки сложных программных систем. Как было сразу отмечено в моем начальном комментарии, для простых случаев не надо ничем заморачиваться, а использовать обычные QLua-скрипты.
TGB написал: Назначение данного продукта не в том чтобы заменить Lua. Это в каком-то смысле «станок» с готовой инфраструктурой, которая в том или ином виде требуется для разработки сложных программных систем.
Попробуйте все тоже самое, что в первом посте, изложить в виде рекламного текста в формате "применив это комбайн для решения такой вот задачи получаем вот такие плюсы относительно просто Луа". Важно чтобы задача просто и кратко формулировалась при этом.
PS Посмотрите иностранные рекламные ролики сельхоз. техники. Это крайне залипательно! И, главное, там много что можно почерпнуть в плане формата подачи рекламного материала.
О существовании lup я узнал только из этой ветки. Прошёл по ссылке и сразу напоролся на: Проблемы начинаются при показе модальных окон и popup-меню. Пока их не закроешь, поток main дальше не выполняется (видно по необновляющемуся заголовку окна и прерыванию записи в файл log.txt).
Следовательно, нужно выбросить нафиг эту библиотеку и написать диалог на чистом Lua: поток main спокойно выполняется, заголовок окна обновляются, запись в файл log.txt ведётся, и пилювать скрипту на все эти "модальные окна". Не первый уж месяц работаю с этими контекстными "всплывающими" меню, реализованные как Lua-таблицы - ни единого нарекания!
При работе с iup в отдельном потоке (как это сделано у меня) я проблем не встретил.
Цитата
swerg написал: Посмотрите иностранные рекламные ролики сельхоз. техники. Это крайне залипательно! И, главное, там много что можно почерпнуть в плане формата подачи рекламного материала.
Nikolay написал: Так я и спрашиваю какой такой случай требует использование этого продукта. Просто для примера.
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.
TGB, Ну да, в моём скрипте нужен диалог. И он прекрасно реализован с помощью парочки lua-таблиц: одна основная, другая - контекстное меню, всплывающее по клику на строчку первой. И там реализованы абсолютно все возможности, которые мне требуются. Я даже и не знаю, что ещё пожелать!
Я много написал диалоговых программ в своей жизни, и я утверждаю, что ЛЮБОЙ диалог, основанный НЕ на событиях будет убогим по функциональным возможностям. Вы тут описали некое средство, как рисовать картинки - и только. А в диалоге (НОРМАЛЬНОМ диалоге) должны быть и горячие клавиши, и контекстно-зависимые реакции (хелп или локальные меню блоков), то бишь не только примитивно-деревянная организация "подменю", и неоднородные, редактируемые, настраиваемые, горизонтальные, вертикальные, трёхмерные меню и прочая, и прочая, и прочая. НА КОЙ нужны эти Ваши "весёлые картинки"?
Приведенный список можно продолжить, но, кому это интересно, может прочесть в файле OS_Quesha.pdf.
Дело в том, что Вы привели пример простого диалога, который очень просто пишется на lua. При этом у меня уже давно написан dsl, где я даже проще чем у вас создаю формы и реакции.
Хотелось бы понять, зачем это для реальной работы. Ведь диалог - это вообще последняя вещь, хоть и важная если пишешь не для себя.
Владимир написал: И он прекрасно реализован с помощью парочки lua-таблиц: одна основная, другая - контекстное меню, всплывающее по клику на строчку первой.
Я же написал, что диалог можно сделать на таблицах, некстати, обслуживаемых основным потоком QUIK. У вас все хорошо. Ну и замечательно! Кстати, какой-то диалог можно реализовать и на обычном Блокноте -----
Цитата
TGB написал: Кроме того, для пользователя предусмотрена возможность настройки обработки собственных сложных команд, задаваемых в командной строке формы диалога.
Дополнительно, для пользователя доступны все возможности графического пакета iup (это, по поводу комментария Nikolay о простом диалоге). ---- Вообще, мне кажется, что у нас спор ни о чем. Я же не предлагаю заменить диалог Nikolay или запретить использование таблиц QUIK. Я даже уговариваю пользователей не лезть без нужды ни в какие дебри, а решать свои задачи наиболее простыми и понятными для себя средствами.
TGB, И я много раз писал: язык - дерьмо, Квик - набор глюков, не исчезающих, а скорее пополняющихся от версии к версии, но АБСОЛЮТНО ВСЮ требуемую юзеру функциональность "на этом на всём" написать МОЖНО! И любые примочки доморощенных "сторонних исполнителей" - библиотеки, внешние модули, не говоря уже про "специализированную ОС" - только добавляют глюков в этот винегрет. Организация диалога - в миллион раз более сложная штука, чем вся эта несчастная организация торговли с потрохами! Ну какой может быть диалог при торговле, ну какой? Что там вообще юзеру делать? Какие там могут быть "собственные сложные команды, задаваемые в командной строке формы диалога"? Скрипт может быть написан вообще без диалога! Утром включил, вечером выключил. Или даже зимой включил, летом выключил! Я как-то раз даже склепал такую версию своего скрипта, за 5 минут (ломать - не строить), в результате объём когда полегчал вдвое, скрипт заработал с первой же попытки. Только на него скучно смотреть - основная версия гораздо более информативна, можно развлечься самостоятельной торговлей с её помощью. Да и то это не диалог, а всего лишь индикация. Самим же диалогом я пользуюсь вообще не каждый день. Возможно, даже не каждую неделю. И у меня просто фантазии не хватает, что же ещё туда можно впендюрить такое, что бы хоть когда-нибудь понадобилось пользователю.
Владимир написал: И любые примочки доморощенных "сторонних исполнителей" - библиотеки, внешние модули, не говоря уже про "специализированную ОС" - только добавляют глюков в этот винегрет.
Я согласен с выше написанным, но вы ломитесь в открытую дверь
Цитата
TGB написал: уговариваю пользователей не лезть без нужды ни в какие дебри, а решать свои задачи наиболее простыми и понятными для себя средствами.
Ни к чему не призываю, сам эту штуку не ставил. Но кому-то может, и пригодятся реализованные автором средства, которых нет изначально в qlua. Вы ведь не думаете, что автор предложил исключительно вам двоим опробовать свой продукт? С таким же успехом можно, пойти, например на форум TSLaba и возмущаться там, зачем мне ваша хрень, я и сам могу тестер написать.
Незнайка написал: Но кому-то может, и пригодятся реализованные автором средства, которых нет изначально в qlua.Вы ведь не думаете, что автор предложил исключительно вам двоим опробовать свой продукт?С таким же успехом можно, пойти, например на форум TSLaba и возмущаться там, зачем мне ваша хрень, я и сам могу тестер написать.
Достойный ответ, который я не смог сформулировать так четко.
TGB, Ответ, может, и достойный, но не на мой вопрос: кому В ПРИНЦИПЕ могут пригодиться "реализованные автором средства, которых нет изначально в qlua"? НА КОЙ они хоть кому-нибудь нужны? ЧТО это может кому-то дать в самом идеальном случае, помимо головной боли от потенциальных новых глюков? Должно же быть какое-то представление о целевой аудитории! У меня лично фантазии не хватает.
Незнайка, Продукт, написанный для себя резко отличается от продукта, написанного для других. По крайней мере, должен отличаться, как минимум, на порядок более мощной отладкой и наличием развёрнутой документации. Код же вообще может не поставляться никому и никогда - интеллектуальная собственность, ноу-хау и прочая хрень.
Владимир написал: АКИЕ возможности для торговли она предоставила лично Вам?
1. У меня автоматически парсятся некоторые сайты с аналитикой фондовых рынков. На основе полученных данных автоматически выбираются бумаги и стратегия для внутридневных торгов. 2. На основе базовой (выбранной) стратегии автоматически выставляются заявки и отслеживаются сделки, 3. Паралльльно, по трем альтернативным стратегиям торговли ведется виртуальная торговля. При значительной разнице результатов происходит переход на более прибыльную стратегию. Все я не буду описавать. Думаю, что этого доствточно.
1. Так Ваш скрипт сам ничего не умеет? У Вас парсятся (!!!) какие-то там "сайты с аналитикой"? И Вы ещё там ловите какие-то сраные миллисекунды?! 2. Мой скрипт ТОЖЕ "на основе базовой (выбранной) стратегии автоматически выставляет заявки и отслеживает сделки" - для этого ему вполне достаточно голого Lua. 3. О, Господи! У Вас даже стратегии нет? У моего так ГИБКАЯ стратегия, алгоритм меняет поведение в зависимости от поведения рынка здесь и сейчас (причём как рынка вообще, так и поведение по каждому конкретному тикеру в частности), от настроек, заданных юзером (именно они и меняются в диалоге при необходимости) и торговлю ведёт именно по ней, а не по каким-то там "альтернативным стратегиям", причём торговля ведётся именно реальная - за каким хреном нам виртуальная торговля? К тому же, по закону Мэрфи, как только "происходит переход на более прибыльную стратегию", немедленно становится эффективной та самая стратегия, с которой Вы только что ушли.
Владимир написал: У моего так ГИБКАЯ стратегия, алгоритм меняет поведение в зависимости от поведения рынка здесь и сейчас (причём как рынка вообще, так и поведение по каждому конкретному тикеру в частности), от настроек, заданных юзером (именно они и меняются в диалоге при необходимости)
Вы счастливый человек и я не очень понимаю, зачем вам так много писать в этой теме
TGB, Да я во всех темах пишу, которые меня как-то заинтересовали. Но вот специализированную ОС под задачи торговли - такого я ещё не видывал ни разу за всю свою (не очень-то и короткую) жизнь.
Владимир написал: Но вот специализированную ОС под задачи торговли - такого я ещё не видывал ни разу за всю свою (не очень-то и короткую) жизнь.
Ну! Это уже реклама. Я бы так не смог А если серьезно Ведь было доброе время, когда программы набирались на тумблерах. Все ошибки в них, кроме ошибок железа, были свои и ведь они как-то работали. Потом появились операционные системы, трансляторы языков программирования и т.д. и теперь нам приходиться иметь дело со всей этой огромной лабудой, искать не только свои ошибки но и чужие глюки.
TGB, Дык в то время на планете Земля ещё водились программисты! А нынешний козёл, который за полвека никак не может нормальную операционку написать, так до сих пор и дрочит своими "версиями"! Именно поэтому он и стал самым богатым человеком в мире.
TGB, вроде много пишите, а вот не цепляет и все. Просто вот читаю и понимаю, что вроде что-то может быть даже и нужное, но вот зачем оно мне и какие преимущества даст совершенно не понятно.
Вы хоть как-то заинтересуйте аудиторию то. Видео с обзором своей разработки снимите что ли, да на какой нибудь ютуб залейте. И покажите, мол с помощью данной разработки можно делать то-то и то-то чего на квике не реализовать, и чтобы это был не сферический конь в вакууме, а что-либо реально нужное людям.
Короче, грамотный рекламщик вам нужен, если хотите в массы свой софт пустить.
BlaZed написал: Короче, грамотный рекламщик вам нужен, если хотите в массы свой софт пустить.
В том виде как он есть, софт не массовый, а потому о рекламе речь не идет. Те, кому он может показаться интересным практически (а таких, я думаю, окажется мало), наверное, и без рекламы поставят его в тестовую конфигурацию QUIK и быстро разберутся, нужен ли он им и зачем.
BlaZed написал: читаю и понимаю, что вроде что-то может быть даже и нужное, но вот зачем оно мне и какие преимущества даст совершенно не понятно.
В документацию я добавил исходник 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).
1. Решение явно сделано программистом для программиста. Простой пользователь ее не осилит в принципе 2. Большинство перечисленных пунктов в "Основные функции OS_Quesha." решаются в виде простого lua скрипта, включая и графические интерфейсы 3. Очень специфическое возможное использование, я даже не смог придумать сходу, где бы мне это решение понадобилось с учетом всех реализованных мною проектов, включая заказные
Понятно, что Вы это сделали в первую очередь для себя, а потом уже как-то решили выдать в массы, но чужой код всегда труден для понимания. у всех свои стандарты написания кода.
Александр М написал: Большинство перечисленных пунктов в "Основные функции OS_Quesha." решаются в виде простого lua скрипта, включая и графические интерфейсы
Когда обсуждаются любые средства, облегчающие разработку программ, возражение типа: «Это можно сделать существующими средствами», «не катит», так как, в конце концов, все можно сделать и на ассемблере. По существу же, обсуждать имеет смысл то, насколько быстро и качественно можно разрабатывать приложения, использую предлагаемые средства по сравнению с тем, что обеспечивают существующие средства их разработки. Конечно, только практика использования любого средства разработки программ может определить его реальную полезность для разработчиков. Такая возможность разработчикам роботов в QUiK предоставлена в виде кодов и документации OS_Quesha.
Цитата
Александр М написал: Очень специфическое возможное использование, я даже не смог придумать сходу, где бы мне это решение понадобилось с учетом всех реализованных мною проектов, включая заказные
Мне непонятно в чем состоит специфичность использования OS_Quesha, если вместо одной функции main в QLua, в OS_Quesha, при использовании исходника TS_QUIK_RT.lua, предоставляется четыре (количество определяется в исходнике, в описании схемы обработки в табличном виде), аналогичные функции, в которых доступен весь API QLua. Эти функции могут, при наличии нескольких ядер в ЦП компьютера, выполняться параллельно (с учетом особенностей версий QUIK > 8.4, описанных в моем начальном комментарии). Дополнительно они могут взаимодействовать между собой через готовые очереди. Кроме того, в них доступны все возможности, описанные в моем начальном комментарии. Причем, расход ресурсов ПК на функционирование OS_Quesha ничтожен и в этом можно убедиться, запустив немодифицированный исходник TS_QUIK_RT.lua. Все дополнительное использовать не обязательно, но это может потребоваться при последующем расширении возможностей робота.
TGB, Совершенно верно: "все можно сделать и на ассемблере". А кое-что можно сделать ТОЛЬКО на ассемблере. А потому именно на нём и можно предельно быстро и качественно разрабатывать любые приложения. В общем случае, быстрее, чем на любом другом языке.
Специфичность использования OS_Quesha состоит в том, что она изначально предполагает "работу в среде программного комплекса QUIK". А задачи. которые решаются в Квике по определению не требуют ни "нескольких ядер в ЦП компьютера", ни параллельных вычислений, ни какого-либо "расхода ресурсов ПК".
Владимир написал: кое-что можно сделать ТОЛЬКО на ассемблере. А потому именно на нём и можно предельно быстро и качественно разрабатывать любые приложения. В общем случае, быстрее, чем на любом другом языке.
Ваше утверждение слишком сильное, но оно же сильно расходится с вашей практикой. Вы же своего робота сделали на QLua и мало того, что не используете в нем ассемблер, но даже отказываетесь использовать C.
Цитата
Владимир написал: задачи. которые решаются в Квике по определению не требуют ни "нескольких ядер в ЦП компьютера", ни параллельных вычислений, ни какого-либо "расхода ресурсов ПК"
Я согласен с тем, что подавляющее большинства пользователей QLua эффективность вычислений (параллелизм т.д.) мало волнует, но это в перечислении основных функций OS_Quesha всего лишь первый пункт. У меня самого возникла потребность в потоках не из-за проблем с вычислительными ресурсами, а из-за того, что появилась группа взаимодействующих задач, и в рамках одного потока надо было реализовывать некоторый диспетчер, занимающийся распределением процессорного времени одного потока между этими задачами. Вместо реализации такого диспетчера (а это была бы реализация в корявом виде функций потоков) были реализованы функции первого пункта, которые не только решали проблемы диспетчирования задач, но и при необходимости могли решать проблемы обеспечения эффективности вычислений. Возможность создания потока внутри скрипта обеспечила также беспроблемное использование любых доступных отлаженных графических пакетов, из которых я выбрал IUP.
TGB, Ни в одной букве! Наша шахматная программа, например, была написана на чистейшем ассемблере. Точнее, последовательно на трёх ассемблерах: БЭСМ, PDP и Интел - переписать её на С у нас так руки и не дошли. А робот слишком примитивная задача, которую можно реализовать даже на Lua. А вот в действительно СЛОЖНЫХ случаях не хватает даже возможностей С (там нет меток в массивах, инициализации неоднородных массивов и ещё кое-чего). Все остальные языки слабее С (который называют даже машинно-независимым ассемблером), и реализация сложных вещей на них чрезвычайно трудоёмка, если вообще возможна.
Владимир написал: TGB, Совершенно верно: "все можно сделать и на ассемблере". А кое-что можно сделать ТОЛЬКО на ассемблере. А потому именно на нём и можно предельно быстро и качественно разрабатывать любые приложения. В общем случае, быстрее, чем на любом другом языке. ::
Я как-то одному знакомому веб-программисту, в ответ на высказывание что "использовать ассемблер ничуть не тяжелее пхп", предложил написать на ассемблере программу прыгающего логотипа DVD на любой платформе, например Денди (процессор 6502). В ответ на что он конечно не засунул язык в задницу как подобает джентльмену, а начал кривляться что это ниже его достоинства и вообще он слишком занят. Его друг мне в ответ предложил написать определённого Telegram-бота за два дня (судя по его выпалке это должно было быть коротким сроком), с чем я справился за три часа т.к. у Telegram специально для этого был веб-интерфейс. Программировать графику на Денди конечно тоже было очень просто - там специальный графический процессор есть, достаточно просто скопировать часть ROM в VRAM и записать байтики в несколько регистров - но этот брошенный вызов остался неотвеченным. Предлагаю и вам "предельно быстро и качественно" написать такую программу.
Артем, Я согласен: "использовать ассемблер ничуть не тяжелее пхп", Что до остального - вы не пишете программу, а собираете её из кубиков, написанных дядей Васей. Ассемблер тоже позволяет вызывать библиотечные утилиты.
Наш "Мираж" был и в графическом варианте (тогда это было EGA 640*350*16. Мышка, выпадающие менюшки, плавное движение фигур, хелп... 35 килобайт всё удовольствие. Ну и рейтинг гроссмейстерский (максимально 2436, в Гааге получили).
Владимир, написание велосипедов - так себе достижение. При желании конечно что-то вроде TempleOS можно навелосипедить, но это надо иметь терминальную стадию шизофрении, а в противном случае попросту не представляется возможным на современной аппаратуре. Не говоря о том что это по сути пустая трата времени. Я раньше увлекался деланием видеоигр, и там целое движение "движкописателей" существует, которые до написания собственно игр не доходят. В кружке художников тоже существуют идейные элитисты которые цифровые инструменты не признают, хотя по итогу визуальное качество оказывается гораздо выше при тех же трудозатратах.
Артем, Так эта Ваша прыгающая хрень... как её... прыгающий логотип - это не только не велосипед - это даже не программирование! И в моё время "веб-программисты" вообще программистами не считались. Равно как и HTML языком. А плодящиеся как тараканы языки, браузеры, СУБД или те же ОС - это, простите, ЧТО? Велосипед на велосипеде! Скажу больше: "на современной аппаратуре" вообще ничем другим и не занимаются! А эти ваши "видеоигры" - это простите, ЧТО? Игры по пальцам можно пересчитать: от Тетриса Алексе Пажитнова до Цивилизации Сида Мейера. Всё остальное - велосипеды, велосипеды, велосипеды... в глазах рябит! Причём качество всё время катастрофически падает: помню, когда-то на несчастных 80486 по сети в Doom рубились - никаких проблем! А современное говно вообще отказывается работать без туевой хучи гигабайт и гигагерц. Так что велосипеды нынешние и самокатами-то назвать трудно.