Обмен сообщениями приложений , скриптов на Lua, Python ,С

Старые песни о главном. Чуть ли не с самых первых своих сообщений я говорил: несмотря на то, что Lua есть препоганейший язык, а С мой наилюбимейший язык на протяжении десятилеий, писать нужно только на чистом Lua. А уж привлекать сюда ещё какое-нибудь говно вроде Python и вообще есть мазохизм в чистом виде. И что задача организации торговли настолько тривиальна в техническом плане, что работать должен один-единственный скрипт написанный на одном-единственном языке Lua и, по возможности, работающий в одном-единственном потоке main. Блин, она ещё и платная?! Как говорил незабвенный Пётр Павлович Ершов: "Пусть полюбится кому, я и даром не возьму".    

Столько же , сколько Вам платят разработчики QUIK за тестирование их новых версий QIUK

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

Лапуль, открою Вам страшную тайну: любой интерпретируемый язык сначала интерпретируется, а уж потом исполняется. И носом торкал: VM - это ТОЖЕ интерпретатор! Года два уж прошло, лапуль - пора бы и усвоить!

Чистый СИ, лапуль, это тоже всего лишь язык (его также называют машинно-независимым ассемблером), но компилируемый. Компилятор - это такой интерпретатор, который только интерпретирует код, но не выполняет его, а вместо этого записывает его на другом языке. Шурупен зи? В частности, компилятор с Си для Интеловского процессора даст радикально другой код нежели, скажем, для процессора PDP.

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

Все арифметические операции и обработку строк на луа исполняют программы на чистом Луа, лапуль - СИ здесь вообще никаким боком не стоит. Разве что библиотечные утилиты интерпретатора могут иметь сишный интерфейс - ну так а какой же ещё? Этот язык написан абсолютными гениями, зачем же пользоваться каким-то другим говном?

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

Учите матчасть, лапуль, который уж раз говорю.  

TGB, Я тоже "вынужден согласиться" с небольшим уточнением: как можно заработать на фондовом рынке, более-менее понятно (во всяком случае, мой скрипт давным-давно торгует намного лучше меня), а вот срочный рынок я пока плохо чувствую, а попробовать бы не мешало. Но я ни разу не видел здесь даже намёков на обсуждение именно торговых алгоритмов - только техника, да и та в очень усечённом виде.

Кстати, свой первый код (для работы по историческим данным) я написал именно на C - пощупал его, потестировал, а потом уже перенёс на Lua.

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

 

Не соглашусь с Владимиром.
Мне вот написание робота на Lua совершенно не нужно. Но я здесь, чтобы написать коннектор на С++ и выдрать данные из квика с базу данных, где скрипт на T-SQL (это SQL Server) сам посчитает, а потом выдаст нужное в веб-интерфейсе через совсем уж редкий язык в Европе для web-а под названием ColdFusion (или CFML)/ Удобен он для написания веб-страниц.

Не верю я в роботов!
Вы на рынке деривативов не работали (на срочном) и не видели, как ГО поднимают и сделать ничего нельзя. Робот тупо встанет в сложный момент.
Только ручная торговля.


У меня задача только получить  данные из Квика. Через общую память, например. Хоть в файл для начала записать на C++ (потому что STL использую).
И получить данные самым быстрым, кошерным способом, то есть создавать технических нагромождений, я пока не могу. Не разобрался. Только вызывать код C из Lua, "приветы передавать", а надо наоборот, брать из Квика и писать в файл или общую память по конкретным тикерам.



И да. Не надо мешать в кучу все свои старомодные представление.
Есть интерпретируемые языки (типа javaScript и Python, Perl, PHP), а есть компилируемые.

Компилируемые в свою очередь подразделяются на настоящие, формирующие машинный код через компилятор, напрямую работающие в железом и процессором (по сути только C/C++ и Pascal/Delphi) и компилируемые в байт-код и выполняемые оберточной машиной, бинарным интерпертатором, по сути (Java, .NET, или вон Lua).

Вот и вся классификация. В 21 веке это так. И будет так. PDP можно и почти все ранее 1990-х можно выкинуть.


На последок надо бы различать язык Ассемблера (по сути это именно язык для человека) и собственно машинный код. Писать и править программы можно прямо в машинном коде, потому что есть двоякие ситуации, когда ассемблер можно по разному транслировать в машинный код.
И сам машинный код на самом деле тоже интерпретируется процессором, почти как обычный текст, на конверее, байт за байтом. Но это уже детали железной реализации. Это уже сделано на заводе, так сказать.

Коротко, для новичков, так сказать.

Да, кстати, в американских платформах, подобных Квику, на C++ написана, весьма хороша (была такая, еще с 90-х, точно такая же модель, когда брокеры подписываются на платформу, а платформу держит независимый разработчик. Её потом выкупил Bank of America и в итоге практически уничтожил, индусские аутсорсные программисты и менеджент, которому ничего не надо, творят чудеса).

Очень старая, подозреваю, что модель Квика и даже бизнес-процесса с нее когда-то срисовывалась.
Называлась InstaQuote.
Тоже с Q логотипом :)

Это было еще до появления Инстаграмма. Так что название не слизано. Точнее, когда инстаграмм появился, платформа была почти убита.

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

По моему через локальный TCP-port  это делалось... Да!
Торговая платформа открывала и всегда слушала 3201 порт, как сейчас помню.
И на порту висело самописное API, очень простое. Никакого Луа.

Опционная доска там была, но она сама была реализована как как бы отдельное приложение, в отдельном потоке. Было видно даже по интерфейсу, что писалось отдельно.
И опционы на Америке совсем по другому устроены. Нет централизованной волатильности от биржи, и многое не так. И опционы на акции. Это не CME было.

То есть задачи и подходы в принципе одинаковы. Что в Америке, что на Квике в России.

Проблема в том, что DDE слишком громоздок. И слишком стар. И ничего лучше не придумали.

В Квике надо несколько манипуляций мышью сделать, чтобы запускать это всё, в Excel.
По сути пишется самописный Excel, берется компонент на C++ и получается DDE-клиент.

А хотелось бы лаконичную DLL повесить и обращаться отдельным запросом внешним С++ или Java "экзешником" через общую память (это лучшее!) или через такой же localhost TCP-port, через WinSock.

Потому что как устроен ColdFusion (или аналогичный слизанный, ксати, позднее с него модный ASP.NET -- это доподлино известно).
Можно написать программу на Java или С++, которая как обычный HTML-тег с нужными переаметрами по мере надобности может вызываться прямо с веб-страницы.
Всю эту обертку и взаимодействие уже делает сам ColdFusion.


То есть можно вызвать расчет ГО, данные из Квика прямо с веб-страницы и тут же отобразить или записать в БД.
Практически не напрягаясь.

Единственное, это сам Lua и переход в С++.

Вот какая-то такая задумка. Обвязку такую сделать.

А опционную доску потом доделают под Qlua. На худой конец, никто не запрещает обращаться напрямую по коду опциона.