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

конкретно, "SourceMod" и его скрипты на SourcePawn - не многопоточны, а исполняются последовательно в цикле, в порядке регистрации при старте сервера (игры). автор мотивирует это тем, что слишком много геморроя для опенсорс проекта это всё дело распараллеливать. Но, также говорит, что работа в этом направлении ведётся.
по другим движкам/системам, - везде свои подходы.

Да. Но стек в LUA - не резиновый, а сборщик мусора - невсегда предсказуемый. К тому же, если объектов - чуть меньше чем (ну Вы сами понимаете... :) ) то, мы очень сильно теряем в производительности. Насчёт простоты, гибкости и синтаксического "сахара". - Вот, как-раз за "сахар" и официально декларируемый подход к тому, что мол де, хорошие программы не нуждаются в комментариях я бы, как и многие,  подвесил Роберто за ...

и это лишь малая часть того, что можно взять из "сорса", а ещё есть CryEngine, UnrealEngine и др. Если Вы собираетесь это всё в дальнейшем реализовывать и считаете это направление конструктивным - я могу давать более конкретную информацию к размышлению. В другом случае, мне просто проще не терять время, а продолжать разрабатывать свой торговый терминал.

Lua lanes - читал про неё. Пока разбираюсь. Основная мысль темы:

• оградить трейдера от создания классов в самом LUA
• сделать программирование на QLUA - полностью callback-style, как говорится
• сделать так, чтоб трейдеру не было нужды писать библиотки на C++ для LUA
  

в вышеописанном движке, также присутствует удобный механизм доступа к глобальным переменным: "convar"-s. Глобальные переменные там представлены, как объекты. Для того, чтоб прочитать/зарегистрировать/изменить/перехватить переменную - используются соответствующие методы. Это крайне удобный и потокобезопасный механизм обмена ими в масштабах даже не одного скрипта, а всей системы. Такая бы вещь, определённо сняла бы кучу проблем в QLUA.

Пока приходит на ум лишь то, что:

• представить бумагу (инструмент), как компонент, а точнее, объект.
  

• у этого объекта есть ряд событий:
  

• OnPriceChange
  

• OnVolumeChange
  

• OnTime
  

Если бы бумага обладала "оконной функцией" - можно смело бы называть её компонентом и работать с ней соответственно. Но, т.к. это не так то, существует другой механизм, принятый в том же javascript (если не изменяет память) - механизм подписчика и подписанта. таким образом, есть бумага, как объект. хотелось бы, чтоб объект квика, а не LUA. и есть ряд подписчиков на её события. Раз этот объект не обладает оконной функцией и не имеет соответственно петли обработки сообщений то, пусть сам квик (а не трейдер на LUA) в цикле обходит всех подписчиков по всем событиям и бумагам, вызывая те же скрипты на LUA но? уже более абстрагированно. Пусть сам квик заботится о потоках, распараллеливает по процессорам в зависимости от нагрузки ряд объектов (бумаг например). То есть, наконец, станет полноценным торговым движком!!! В самом скрипте LUA - оставить всё, как есть но, предусмотреть вышеописанную возможность.

Сложно ли это сделать? Думаю, ДА. Потому что придётся переписать квик.
Сложно ли это сделать на LUA? - раз в 100 точно, даже имея на руках корутины и замыкания.
Будет ли выигрыш от скорости если сделать это на LUA? - вопрос, - риторический.... :)



как работать со всем этим из скрипта, как управлять?


нечто подобное реализовано в игровом движке "Source" и его "SourceMod".
по "сорсу" - там используется в основном, неблокирующая работа с потоками.

http://forum.quik.ru/user/21/ ,

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

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

Также Вы говорите, что это всё можно реализовать и средствами самого LUA. Чтож, как говорится "You are welcome!". Давайте,  покажите нам, наконец на хотя бы на одном примере, как это делается.

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

Вопрос к разработчикам (это значит, что мнение других - меня не интересует): какой смысл был создавать отдельный класс в квике под это дело и свою "песочницу" (sandbox)? Почему когда даже если индикатор не наложен ни на один график НО!!! присутствует в папке "Luaindicators" - он может угробить всю систему, если в нём есть неявные ошибки? Почему бы просто не объединить класс индикаторов и его виртуальную машину с классом скриптов? Вы бы тем самым значительно расширили бы их функциональность и не плодили бы не нужных промежуточных функций, которые работают в одном классе и не работают в другом. Или, вы так сильно боитесь/переживаете за стабильность своего плагина qchart.dll, который отвечает за рисование графиков в квике? Ответ, мол то, что это скажется на общей стабильности самого квика - не принимается - т.к. у вас используются и более опасные конструкции и в большем количестве.

Михаил, я конечно, извиняюсь но, куда уж развёрнутей? Как уже писал: я сторонник такого подхода - при котором:

• мне нет нужды запускать отдельно в каждом скрипте через меню робота. т.е. я хочу, чтобы, к примеру, нажав в меню - "запустить скрипт" - у меня одновременно начало торговать 30 роботов, не зависимо и на разных интсрументах. В идеале, распараллелено по разным потокам и процессорам (правда за параллелизм по процессорам отвечает уже операционная система)
• также я хочу, чтоб GUI всеми этими 30-ю ботами мог управлять без лишних багов. Как это сделать отдельно от квика и LUA - я знаю. Но не знаю, как это сделать в квике - т.к. я являюсь противником всяких связок: QUIK-LUA-"что-то там ещё".
• Я хочу, чтоб квиковский движок предоставлял в LUA больше классов - чтоб не было нужды их ваять на LUA, а только обрабатывать колбеки.
  

1. Есть ли смысл мне всего этого ждать или, как и многие другие использовать многочисленные костыли и связки?
2. Хотелось бы от Вас хотя бы одного упрощённого примера на LUA в котором 2 робота запускаются из одного скрипта, одновременно (без корутин и очередей) торгуют и выводят визуализацию в квике. Был бы очень рад, если бы он был без багов - пока мне такие увы не попадались.

а мне на почту спам шлёт, хотя галочки все на месте в профиле. как отписаться от уведомлений о сообщениях?

и ещё вопрос, а можно поинтересоваться: кто написал qchart.dll?
чувствуется школа Мастера Feng Yuan.

а в личных целях разрешаете ковыряться/использовать?

а может им, этот форум, просто подарили за демосчёт? в квике? :)))))

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

мда уж...

вот и строй тут с ними HFT. Боюсь даже представить, чтоб было... :)))
И, главное, никто ни за что не отвечает: брокеры говорят, что вы должны учитывать риски, разработчики - это всё биржа, биржа - ну тут понятно...

Мне уже вас всех жалко стало. даю вам подсказку:)  

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



А теперь, заглянем в штатную докумментацию по QPILE

то, что нам не интересно, - зачёркнуто крестиком)))


Полагаю, этого достаточно:))))))

тут такой момент еще: если доступны данные с сервера - то в график скорей всего выведутся эти данные, а не кешированные в .dat-файлах и, параллельно обновится кеш. поэтому, если, что-то шаманить с графиками и .dat-файлами - то, только OFFLINE. Честно говоря, специально этот вопрос не прорабатывал но, судя по наблюдениям - выходит, что0то такое.

А сложностей никаких нет. Это терминал должен ОБЯЗАН быть в первую очередь для трейдеров, а не программистов. Если же расценивать его с позиции программиста и программирования - то, скриптовый язык вообще можно было выбросить, а писать модули/плагины напрямую, зная API терминала.

Ваше мнение о том, кто кому, что должен - я, как-то даже и не спрашивал. Будьте добры свалите с этой темы и не засоряйте её. Умничать мы все можем.

к тому же в нём нам опять придётся подцепить C-библиотеку, а хотелось бы вариант от разработчиков - встроенный в квик механизм. Зачем мне, как трейдеру заниматься писательством на С++ или Delphi этих костылей-библиотек, если я, как скриптер и трейдер должен это всё иметь уже встроенным? моя задача торговать, а не писать программы на С++сах.

да. я видел этот вариант. Он основан на критических секциях

DDE, SQL, TCP - не интересуют. Какие ещё варианты?
Вот, есть 2 скрипта - 2 луа-машины, выполняющиеся, как минимум, в двух разных потоках ОС. Задача, обеспечить совместный доступ, скажем, к пяти увесистым таблицам. Как быть? Платные услуги/варианты - не интересуют.

а это мысль, надо бы допилить свой костыль под это дело:))) заодно и фьючерс склеивать можно будет:)))

ОК. тогда, предлагаю удалить все вышестоящие  сообщения в этом топике, начиная с моего #15-го. полагаю, теперь всем всё ясно и не будем засорять форум.

хорошо, другой вопрос, а vclua можно?

не. я у них хлеб отнимаю с их позволения:))

1. Хотелось бы конкретики, если можно, по этим причинам.
3.5.6.7. Да, можно, с корутинами и очередями НО! Это будет тот ещё велосипед и пойди разберись потом в листинге. Даже одна метатаблица вызывает шок у неподготовленного скриптера, а что говорить о рядовых трейдеров? Ведь это софт не для программистов, а для трейдеров.
4. Интересует возможность иметь общий кеш памяти или там кеш переменных, чтоб ими обмениваться между двумя скриптами, (т.е. двумя виртуальными машинами со своими lua-state) и стало быть, двумя потоками ОС. тут народ кричит, что надо shared memory. Но мы то знаем, что это тоже не панацея, правда, в 3d-играх, активно используется, например при обращению к кешу ресурсов (скрипты, текстуры, меши, аудио, видео). Есть варианты реализации, направленные на разделение потоков по принципу read/write. Есть универсальные базовые методы: interlockedIncrement/decrement. Но, это всё (пункт 4.) - потребует от Вас создания внутреннего класса менеджера памяти с функциями арбитража потоков - т.к. в LUA это - явно выносить не нужно. есть ещё варианты. это, так сказать, что пришло/вспомнилось на ум.

Почему? Где это написано?
(я, конечно, не спорю но, хотелось бы конкретики)

Полностью солидарен. :)))

Покупайте у меня тогда описание формата за 4000руб. В нём нет ни непонятных dll, ни exe, никаких вирусов. Просто описание структуры с полями и типами данных. Всё открыто. Если Вы умеете немного программировать - то, можете сами написать экспортёр. Оплата через Сбербанк-Онлайн. Получение на любой удобный для Вас адрес. Переписка через вконтакте, чтоб не засорять форум.

Последний раз проверял формат на актуальность - сегодня. Если Вы хотите протестировать - можете мне коротенький файл отправить - я вам его расшифрую.

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

1. qchart.dll. Прошу раскрыть API этого контрола.

Это облегчит участь многим и облегчит задачу поддержки визуализации в скриптах.

2. Также, прошу сделать доступ к нативным контролам квика из LUA. Это решит сразу 2 проблемы: использование нестабильных сторонних библиотек для визуализации, наманер, vclua и отчасти, проблему с многопоточностью, т.к. основная писанина её поддержки ляжет на Ваши плечи, а не на наши.

Всё это можно достичь созданием классов-обёрток в квике, а из LUA дёргать уже готовые объекты и методы. То есть LUA должен быть абстрагирован от "классо-писательства. Это реально облегчит многим жизнь. Думаю многим интересна будет такая схема абстракции:


3. Также нужна поддержка хуков событий (Events):
Я не прошу создания и регистрацию нативных событий, т.к. это далеко нетривиальная задача для квика и LUA. Поэтому прошу лишь на развитой поддержки событий в квике. Те, что есть - этого мало. Смысл в том, чтоб в LUA пользоваться уже готовыми зарегистрированными квиком и в квике колбеками, а не писать это всё дело через псевдомногопоточность на LUA.
4. Должна быть модель общей разделяемой памяти для всех скриптов для обмена общими данными. Это надо для систем где одновременно работают разные роботы на разных инструментах. То есть для корректного обмена данными между скриптами-роботами

5. Нужен системно-реализованный класс алертов (алармов или триггеров) и чтоб, его можно было отслеживать вызывать из LUA.
К примеру, есть бумага, есть условие по ней, оформленное в виде функции. При срабатывании условия квик вызывает коллбек.
На самом деле, это всё относится к п.3. Но, если это невозможно для Вас сделать - чтож, придётся писать далеко нетривиальные "велосипеды" на LUA.

6. Нужен класс TaskManager - для создания и управления параллельными задачами.
Можете не реализовывать но, выполните хотя бы остальные пункты.
7. Неплохо было бы иметь такой коллбек, как OnFrame. Скажем, 20-ти миллисекундный интервал устроил бы многих. Что можно делать и для чего он нужен - зависит от того. какие функции из этого списка Вы собираетесь исполнить. Вариантов много, равно, как и реализаций.
8. Неплохо было бы иметь профайлер скриптов и QLUA-дебаггер (исходники Decoda есть в общем доступе, что мешает заточить их, под QUIK как многие разработчики делают для своих программ)
----------------------------------------------------------------------------------------------------------------


Одним словом, нужно много нативных классов, всяких и разных, чтоб не изобретать их в LUA и не думать об их синхронизации. То есть, в идеале, программирование на LUA - должно и ОБЯЗАНО превратиться в callbacks-программирование. В противном случае, у него просто нет шансов. В индустрии 3d-игр - есть 2 основных направления или стиля работы 3d-движков с поддержкой скриптов на LUA:

• движки, которые имеют развитую классовую структуру и тем самым, не заставляют скриптописателей писать многочисленные велосипеды. А дают им лишь возможность создавать, удалять, изменять свойства шаблонных классов, которых тьма. В результате,  с созданием скриптов может справится даже школьник, а игра - засчёт массовости имеет весьма приличный оборот.
  
• и движки, которые имеют минимум классов, оставляя всё на откуп скриптописателей. Бесспорно, это даёт большую свободу в реализации возможностей и даже некоторые известные игры это используют НО!!! это требует неимоверной квалификации скриптописателя. И как показывает практика или жизнь - такие игры долго не живут. Так вот, QLUA - сейчас на этом уровне.
  

и я хочу фокус! Софья, покажи мне фокус! м? ну паззялуйста

я думаю, что самым оптимальным вариантом было бы не заморачиваться со своим движком форума, а взять готовый и если я правильно понимаю, бесплатный - punBB. Лёгкий, быстрый, удобный да и функционала по-больше чем у этого.

ну вот. а я думал 5.1.4

Либо, если разработчики непротив - выложу хоть здесь их формат .dat-файлов :)))))))))))

Другой вариант: не заморачиваться со всей этой ерундой, а качать/копить данные с биржи.

ну в общем, готовый "костыль" с экспортом в "популярные форматы": mySQL, XML, TXT, CSV, "да всё, что угодно" => 5000руб (за какой-нибудь на выбор). Всё вместе - 10тыр. За меньшее не работаю.

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

не в одном файле, а водной папке.

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

с минутками годовалой давности ещё как получится, если, как вы правильно заметили их до этого стабильно копить. они у меня накоплены с 2012 года и проблем с их выводом никаких нет.


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

to разработчикам, давно бы уже открыли бы API к нему в общий доступ, а также сделали бы доступ к API нативных контролов, глядишь у народа бы с визуализацией и с многопоточностью проблем поубавилось, а то кругом - одни "велосипеды": vclua и т. п.

средствами LUA вы не получите доступ ко всем архивным значениям, например, к минутным графикам годовалой давности. вы получите доступ лишь к тому объёму информации, которая умещается в размер кеша графиков. также средствами LUA вы не получите доступ к значениям фьючерсов и опционов прошлой экспирации.
Однако, всё это может быть доступно из папки "Archive" в квике, зная формат хранения .dat-файлов. На самом деле, формат - не сложный. Имея hex workshop - можно его распотрошить "на раз" за неделю. Поэтому, если будет стабильный спрос - готов выложить свой "велосипед"

если будет спрос - могу написать свой "костыль" :))

мне показалось или он сам с обой разговаривает? :)))

Они их не раскрывают. Но есть "костыль" от разработчиков: http://www.quik.ru/depot/QMinEditor.rar :)