Пожелания по квику и LUA

Страницы: 1 2 След.
RSS
Пожелания по квику и LUA
 
1. qchart.dll. Прошу раскрыть API этого контрола.

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

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

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

Код
myButton = CreateControlByName("QButton");
myButton.Caption = "Кнопка";

MyButton.OnClick()
do smth work
end

CreateTimer(10, "timerEvent");

OntimerEvent
do smth work;
end 

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

OnConnectPre

do smth work

return 0; //если мы хотим, чтобы этот эвент обрабатывался другими скриптами;
return 1;//если мы хотим, чтоб после обработки этого эвента другие скрипты его не обрабатывали
return 2;//если мы хотим, чтоб скрипт остановил свою работу
end;


4. Должна быть модель общей разделяемой памяти для всех скриптов для обмена общими данными. Это надо для систем где одновременно работают разные роботы на разных инструментах. То есть для корректного обмена данными между скриптами-роботами

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

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


Одним словом, нужно много нативных классов, всяких и разных, чтоб не изобретать их в LUA и не думать об их синхронизации. То есть, в идеале, программирование на LUA - должно и ОБЯЗАНО превратиться в callbacks-программирование. В противном случае, у него просто нет шансов. В индустрии 3d-игр - есть 2 основных направления или стиля работы 3d-движков с поддержкой скриптов на LUA:
  • движки, которые имеют развитую классовую структуру и тем самым, не заставляют скриптописателей писать многочисленные велосипеды. А дают им лишь возможность создавать, удалять, изменять свойства шаблонных классов, которых тьма. В результате,  с созданием скриптов может справится даже школьник, а игра - засчёт массовости имеет весьма приличный оборот.
  • и движки, которые имеют минимум классов, оставляя всё на откуп скриптописателей. Бесспорно, это даёт большую свободу в реализации возможностей и даже некоторые известные игры это используют НО!!! это требует неимоверной квалификации скриптописателя. И как показывает практика или жизнь - такие игры долго не живут. Так вот, QLUA - сейчас на этом уровне.
 
Добрый день.
по пунктам:
1. К сожалению, этого сделать не получится по многим причинам.
2. Над этим вопросом мы работаем, подобные пожелания у нас уже зарегистрированы.
Пункты 3, 5, 6, 7 - в пределах одного скрипта это можно и сейчас реализовать средствами Lua без доработок с нашей стороны.
8 - Профайлер для Lua. Над отладкой с помощью Decoda можно подумать, там тоже все не очень просто. Например, невозможно отлаживать скрипты оставаясь подключенным к серверу.
Пункт 4 - поясните подробнее как бы Вы хотели видеть реализацию
 
Цитата
Michael Bulychev пишет:
Добрый день.
по пунктам:
1. К сожалению, этого сделать не получится по многим причинам.
2. Над этим вопросом мы работаем, подобные пожелания у нас уже зарегистрированы.
Пункты 3, 5, 6, 7 - в пределах одного скрипта это можно и сейчас реализовать средствами Lua без доработок с нашей стороны.
8 - Профайлер для Lua . Над отладкой с помощью Decoda можно подумать, там тоже все не очень просто. Например, невозможно отлаживать скрипты оставаясь подключенным к серверу.
Пункт 4 - поясните подробнее как бы Вы хотели видеть реализацию
1. Хотелось бы конкретики, если можно, по этим причинам.
3.5.6.7. Да, можно, с корутинами и очередями НО! Это будет тот ещё велосипед и пойди разберись потом в листинге. Даже одна метатаблица вызывает шок у неподготовленного скриптера, а что говорить о рядовых трейдеров? Ведь это софт не для программистов, а для трейдеров.
4. Интересует возможность иметь общий кеш памяти или там кеш переменных, чтоб ими обмениваться между двумя скриптами, (т.е. двумя виртуальными машинами со своими lua-state) и стало быть, двумя потоками ОС. тут народ кричит, что надо shared memory. Но мы то знаем, что это тоже не панацея, правда, в 3d-играх, активно используется, например при обращению к кешу ресурсов (скрипты, текстуры, меши, аудио, видео). Есть варианты реализации, направленные на разделение потоков по принципу read/write. Есть универсальные базовые методы: interlockedIncrement/decrement. Но, это всё (пункт 4.) - потребует от Вас создания внутреннего класса менеджера памяти с функциями арбитража потоков - т.к. в LUA это - явно выносить не нужно. есть ещё варианты. это, так сказать, что пришло/вспомнилось на ум.
 
Цитата
sam063rus пишет:

4. Интересует возможность иметь общий кеш памяти или там кеш переменных, чтоб ими обмениваться между двумя скриптами, (т.е. двумя виртуальными машинами со своими lua-state) и стало быть, двумя потоками ОС. тут народ кричит, что надо shared memory
Спокойней будьте. Для обмена данными между скриптами внутри одного терминала уже все придумано и имеется.
Для обмена между терминалами существуют стандартные средства ОС.

Спокойней будьте.
 
Цитата
s_mike@rambler.ru пишет:
Для обмена данными между скриптами внутри одного терминала уже все придумано и имеется.
DDE, SQL, TCP - не интересуют. Какие ещё варианты?
Вот, есть 2 скрипта - 2 луа-машины, выполняющиеся, как минимум, в двух разных потоках ОС. Задача, обеспечить совместный доступ, скажем, к пяти увесистым таблицам. Как быть? Платные услуги/варианты - не интересуют.
 
Цитата
sam063rus пишет:
Цитата
s_mike@rambler.ru пишет:
Для обмена данными между скриптами внутри одного терминала уже все придумано и имеется.
DDE, SQL, TCP - не интересуют. Какие ещё варианты?
Вот, есть 2 скрипта - 2 луа-машины, выполняющиеся, как минимум, в двух разных потоках ОС. Задача, обеспечить совместный доступ, скажем, к пяти увесистым таблицам. Как быть?
Вот вам самый простой вариант: http://quik2dde.ru/viewtopic.php?id=61

Вы тут столько всего умного понаписали - и не можете сами написать такую относительно несложную dll.
 
Для обмена между разными терминалами тоже есть библиотеки. Я использую свою - http://www.bot4sale.ru/blog-menu/ami/amibroker-list/142-amisharp.html, другие используют иные средства.
 
да. я видел этот вариант. Он основан на критических секциях
 
к тому же в нём нам опять придётся подцепить C-библиотеку, а хотелось бы вариант от разработчиков - встроенный в квик механизм. Зачем мне, как трейдеру заниматься писательством на С++ или Delphi этих костылей-библиотек, если я, как скриптер и трейдер должен это всё иметь уже встроенным? моя задача торговать, а не писать программы на С++сах.
 
Цитата
sam063rus пишет:
к тому же в нём нам опять придётся подцепить C-библиотеку, а хотелось бы вариант от разработчиков - встроенный в квик механизм. Зачем мне, как трейдеру заниматься писательством на С++ или Delphi этих костылей-библиотек, если я, как скриптер и трейдер должен это всё иметь уже встроенным? моя задача торговать, а не писать программы на С++сах.
Если вы трейдер - то берите и торгуйте тем, что вам дали. Если этого вам недостаточно - ищите другие терминалы либо платите за локализацию уже имеющегося под ваши нужды. Компания-разработчик вам ничего не должна.

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

Ваше мнение о том, кто кому, что должен - я, как-то даже и не спрашивал. Будьте добры свалите с этой темы и не засоряйте её. Умничать мы все можем.
 
Цитата
sam063rus пишет:
Цитата
Michael Bulychev пишет:
Добрый день.
по пунктам:
1. К сожалению, этого сделать не получится по многим причинам.
2. Над этим вопросом мы работаем, подобные пожелания у нас уже зарегистрированы.
Пункты 3, 5, 6, 7 - в пределах одного скрипта это можно и сейчас реализовать средствами Lua без доработок с нашей стороны.
8 - Профайлер для Lua . Над отладкой с помощью Decoda можно подумать, там тоже все не очень просто. Например, невозможно отлаживать скрипты оставаясь подключенным к серверу.
Пункт 4 - поясните подробнее как бы Вы хотели видеть реализацию
1. Хотелось бы конкретики, если можно, по этим причинам.
3.5.6.7. Да, можно, с корутинами и очередями НО! Это будет тот ещё велосипед и пойди разберись потом в листинге. Даже одна метатаблица вызывает шок у неподготовленного скриптера, а что говорить о рядовых трейдеров? Ведь это софт не для программистов, а для трейдеров.
4. Интересует возможность иметь общий кеш памяти или там кеш переменных, чтоб ими обмениваться между двумя скриптами, (т.е. двумя виртуальными машинами со своими lua-state) и стало быть, двумя потоками ОС. тут народ кричит, что надо shared memory. Но мы то знаем, что это тоже не панацея, правда, в 3d-играх, активно используется, например при обращению к кешу ресурсов (скрипты, текстуры, меши, аудио, видео). Есть варианты реализации, направленные на разделение потоков по принципу read/write. Есть универсальные базовые методы: interlockedIncrement/decrement. Но, это всё (пункт 4.) - потребует от Вас создания внутреннего класса менеджера памяти с функциями арбитража потоков - т.к. в LUA это - явно выносить не нужно. есть ещё варианты. это, так сказать, что пришло/вспомнилось на ум.
пункт 1 - предлагаю просто поверить на слово. Дать такое API мы не можем.
 
а в личных целях разрешаете ковыряться/использовать?
 
и ещё вопрос, а можно поинтересоваться: кто написал qchart.dll?
чувствуется школа Мастера Feng Yuan.
 
Цитата
sam063rus пишет:
и ещё вопрос, а можно поинтересоваться: кто написал qchart.dll?
чувствуется школа Мастера Feng Yuan.
Его фамилия слишком известна....чтобы даже произносить её вслух )
 
Цитата
sam063rus пишет:
и ещё вопрос, а можно поинтересоваться: кто написал qchart.dll?
чувствуется школа Мастера Feng Yuan.
Если есть что спросить по делу - задайте вопрос более развернуто.
 
Михаил, я конечно, извиняюсь но, куда уж развёрнутей? Как уже писал: я сторонник такого подхода - при котором:
  • мне нет нужды запускать отдельно в каждом скрипте через меню робота. т.е. я хочу, чтобы, к примеру, нажав в меню - "запустить скрипт" - у меня одновременно начало торговать 30 роботов, не зависимо и на разных интсрументах. В идеале, распараллелено по разным потокам и процессорам (правда за параллелизм по процессорам отвечает уже операционная система)
  • также я хочу, чтоб GUI всеми этими 30-ю ботами мог управлять без лишних багов. Как это сделать отдельно от квика и LUA - я знаю. Но не знаю, как это сделать в квике - т.к. я являюсь противником всяких связок: QUIK-LUA-"что-то там ещё".
  • Я хочу, чтоб квиковский движок предоставлял в LUA больше классов - чтоб не было нужды их ваять на LUA, а только обрабатывать колбеки.
1. Есть ли смысл мне всего этого ждать или, как и многие другие использовать многочисленные костыли и связки?
2. Хотелось бы от Вас хотя бы одного упрощённого примера на LUA в котором 2 робота запускаются из одного скрипта, одновременно (без корутин и очередей) торгуют и выводят визуализацию в квике. Был бы очень рад, если бы он был без багов - пока мне такие увы не попадались.
 
Цитата
sam063rus пишет:
а в личных целях разрешаете ковыряться/использовать?
Нет.
 
Цитата
sam063rus пишет:
мне нет нужды запускать отдельно в каждом скрипте через меню робота. т.е. я хочу, чтобы, к примеру, нажав в меню - "запустить скрипт" - у меня одновременно начало торговать 30 роботов, не зависимо и на разных интсрументах. В идеале, распараллелено по разным потокам и процессорам (правда за параллелизм по процессорам отвечает уже операционная система)
можете привести пример такого "робота" в псевдокоде? Что бы было понятно о чем идет речь.
 
Это Вы мне скажите. Вам задали конкретные вопросы и Вы хотите, чтоб я сам на них ответил? Такое ощущение, что в "Арке" просто прошла в какое-то время волна увольнений и все толковые - просто разбежались. Вам уже не раз говорили, что LUA в том виде в котором она реализована в квике - далеко не жизнеспособна. мало просто добавить дистрибутив LUA в свой проект и наплевать на биндинг, отдав всё на откуп трейдерам, сделав из них матёрых "сидваплюсников". Надо бы, в обще-то, и реализовать базис, и чем он расширеней и стабильней будет - тем меньше будет к вам вопросов. Предложения на эту тему с конкретными рекомендациями были но, что мы видим? Вы говорите нам, чтоб мы сами всё это реализовали не зная ядра квика.
 
Также Вы говорите, что это всё можно реализовать и средствами самого LUA. Чтож, как говорится "You are welcome!". Давайте,  покажите нам, наконец на хотя бы на одном примере, как это делается.
 
Добрый день Всем,
более пяти лет назад я возмущался,
почему нельзя вместо допотопного QPILE сделать нормальный скриптовый язык например LUA.
Когда появился ЛУА, я очень удивился решению в виде main потока и говорил , что будут проблемы с многопоточностью.
Потому что мне было уже тогда понятно, что родилась вещь в себе (некий монстр, повадки которого даже создатели не знают).
И в этом случае создание  нормального API было бы более проcтым решением, чем  такая модель встроенного языка.
----------------------------------------------
Мне объяснили, что так задумал автор данного творения и все проблемы синхронизации
потоков уже решены (но очевидно автору и самому не все проблемы были понятны).
-------------------------------
Увы, Пришлось все то, о чем правильно отмечено автором данной ветки писать самому.
--------------------------------------------
Полагаю, что причина такого тусклого развития средств разработки торговых роботов в том,
что терминал квик изначально это условно бесплатная программа для подачи поручений брокеру.
И ВСЕ
Остальное - это бесплатное приложение.
------------------------------------------------
Игры - это совершенно другая область бизнеса.
Там игра - это массовый продукт(товар).
-----------------------------------------------
А торговые роботы - это либо дорогие разработки проф участников,
либо игрушечные поделки для малограмотных частных инвесторов.
Луа в КВИК - это песочница для детского сада.
Вот желающие могут строить дома и возить песочек на игрушечных машинах.
Умеющие стряпать игрушечных роботов впаривают им свои поделки.
--------------------------------------------------------------------
Здесь пока нет бизнеса, поэтому и нет нормальных решений среды разработки.
Но это не только недостаток КВИК,
это уровень данного вопроса на российском фондовом рынке.
На российском рынке бабло делают без роботов.
----------------------------------------------------------------------
Но я рад , что в нашем полку недовольных прибыло.
-----------------------------------------------------------------------
Порою смелое движение вперед есть результат пинка под зад.
 
Я не знаю что Николай Камынин знает за рынок, но, по-моему, проблема в тех, кто пользуется инструментом.
В самом деле, желающий чего-то пишет: "хочу, чтобы было так!"
Ну отлично, делай, в чем проблема? Сделай хоть что-то (хоть псевдо-код) и опиши в каком конкретном месте возникли проблемы, тгда будет что предметно обсуждать.
Но на такое логичное предложение идёт удивительный ответ "нет, это вы сделайте как я хочу и покажите мне!"
И где песочница?
 
Цитата
swerg
с вами мне предметно или беспредметно - обсуждать нечего. в следующий раз - за оскорбления будете отвечать по закону. Полагаю, мы поняли друг друга...
 
просьба добавить возможности:
1 менять цвет у линии в индикаторе
2 Также добавьте отображение индикатора в виде баров, свечей, гистограммы.
3 Будет супер если появится возможность рисовать индикаторы, графики без привязки ко времени.
 
Цитата
sam063rus пишет:
Также Вы говорите, что это всё можно реализовать и средствами самого LUA. Чтож, как говорится "You are welcome!". Давайте, покажите нам, наконец на хотя бы на одном примере, как это делается.
Добрый день.
"реализация классов" не самая сложная задача. Но, для того чтобы от них была польза, необходимо хотя бы в общих чертах представлять себе алгоритмы обработки данных и уровни абстракции, которые используют Ваши роботы. В начале ветки Вы декларируете желание иметь реализацию функций обратного вызова на все возможные события, в том числе и заданные по условию :
Цитата

К примеру, есть бумага, есть условие по ней, оформленное в виде функции. При срабатывании условия квик вызывает коллбек.
И при этом иметь около 30 роботов, каждый из которых работает в независимом потоке ОС, без очередей данных и сопрограмм. Пока я не очень представляю себе как это все будет выглядеть. Именно поэтому я и прошу хотя бы пример реализации в псевдокоде. Если у Вас нет готового примера, то можете привести ссылку на игровой движок, реализацию которого Вы считаете удачной.
 
http://forum.quik.ru/user/21/ ,

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

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



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


Код
HookEvent("LKOH", "OnPriceChange", "OnPriceChange.LKOH") --тут думаю, всё понятно: обращаемся к абстрактному LKOH и перехватываем его событие

OnPriceChange.LKOH

   do something work;//лучше делать какую-то маленькую работу, чтоб не задерживать других подписчиков. Или, например, создать здесь эхо-таймер и уже в нём обрабатывать, что-либо
return 0; //если мы хотим, чтобы этот эвент обрабатывался другими скриптами;
return 1;//если мы хотим, чтоб после обработки этого эвента другие скрипты его не обрабатывали
return 2;//если мы хотим, чтоб скрипт остановил свою работу 

end

и т. д.
 
нечто подобное реализовано в игровом движке "Source" и его "SourceMod".
по "сорсу" - там используется в основном, неблокирующая работа с потоками.
 
С подобными хуками и эвентами более-менее понятно. По моему мнению, подобные конструкции как раз легче сделать на Lua - реализация получается более гибкой, простой и понятной. Остается вопрос про отдельные потоки для роботов.
Вообще, если читать первоисточники по скриптовым языкам, не только Lua, то вопрос многопоточности для них очень не простой. Речь идет именно о "честной", вытесняющей многопоточности, а не о кооперативной. Практически везде рекомендуют использовать встроенный в язык механизм сопрограмм, либо запускать потоки с разными виртуальными машинами и обмен данными между ними через аналоги сообщений и очереди. как пример реализации - Lua lanes. В LuaJIT, насколько я помню, вообще отсутствуют функции lua_lock/lua_unlock, вместо этого пользователю самому предлагается заботится о синхронизации доступа к данным.
 
Lua lanes - читал про неё. Пока разбираюсь. Основная мысль темы:
  • оградить трейдера от создания классов в самом LUA
  • сделать программирование на QLUA - полностью callback-style, как говорится
  • сделать так, чтоб трейдеру не было нужды писать библиотки на C++ для LUA
в вышеописанном движке, также присутствует удобный механизм доступа к глобальным переменным: "convar"-s. Глобальные переменные там представлены, как объекты. Для того, чтоб прочитать/зарегистрировать/изменить/перехватить переменную - используются соответствующие методы. Это крайне удобный и потокобезопасный механизм обмена ими в масштабах даже не одного скрипта, а всей системы. Такая бы вещь, определённо сняла бы кучу проблем в QLUA.
 
и это лишь малая часть того, что можно взять из "сорса", а ещё есть CryEngine, UnrealEngine и др. Если Вы собираетесь это всё в дальнейшем реализовывать и считаете это направление конструктивным - я могу давать более конкретную информацию к размышлению. В другом случае, мне просто проще не терять время, а продолжать разрабатывать свой торговый терминал.
 
Цитата
Michael Bulychev пишет:
По моему мнению, подобные конструкции как раз легче сделать на Lua - реализация получается более гибкой, простой и понятной.
Да. Но стек в LUA - не резиновый, а сборщик мусора - невсегда предсказуемый. К тому же, если объектов - чуть меньше чем (ну Вы сами понимаете... :) ) то, мы очень сильно теряем в производительности. Насчёт простоты, гибкости и синтаксического "сахара". - Вот, как-раз за "сахар" и официально декларируемый подход к тому, что мол де, хорошие программы не нуждаются в комментариях я бы, как и многие,  подвесил Роберто за ...
 
Цитата
Michael Bulychev пишет:
Остается вопрос про отдельные потоки для роботов.
конкретно, "SourceMod" и его скрипты на SourcePawn - не многопоточны, а исполняются последовательно в цикле, в порядке регистрации при старте сервера (игры). автор мотивирует это тем, что слишком много геморроя для опенсорс проекта это всё дело распараллеливать. Но, также говорит, что работа в этом направлении ведётся.
по другим движкам/системам, - везде свои подходы.
 
Цитата
sam063rus пишет:
Да. Но стек в LUA - не резиновый, а сборщик мусора - невсегда предсказуемый. К тому же, если объектов - чуть меньше чем (ну Вы сами понимаете... ) то, мы очень сильно теряем в производительности. Насчёт простоты, гибкости и синтаксического "сахара". - Вот, как-раз за "сахар" и официально декларируемый подход к тому, что мол де, хорошие программы не нуждаются в комментариях я бы, как и многие,подвесил Роберто за ..
Давайте оставим в стороне Ваши оценочные суждения о языке, тем более если они не подтверждены фактами.
Если у Вас примеры связанные с переполнением стека, сборщиком мусора или потерей производительности, то приведите пример кода и мы попробуем с ним разобраться.
 
Михаил, я конечно извиняюсь но, я здесь не свои примеры обсуждать ветку создал, а хотел бы услышать от Вас насчёт озвученных мной предложений. Меня интересуют конкретные ответы -  будут ли следующие пожелания зарегистрированы или нет:
  • Развитая поддержка классов с коллбеками в квике. Класс скрипта, класс для бумаги. Класс для работы с глобальными переменными.Класс индикатора. Про остальные не прошу. Хотя бы это.
  • Добавление HookEvent etc. Полагаю уже не надо объяснять.
  • Про доступ к нативным контролам в квике из LUA - я так понял, что уже было до этого предложение и оно за регистрировано.
Хотя бы это. даже если ответ "Нет" будет без аргументации - я это приму
Если Вы опять начнёте утверждать, что всё это можно сделать и в LUA - тогда, предлагаю на этом закончить обсуждение. оно-то, конечно, для разработчиков и легче так но, нам, как трейдерам, от реализации классов и коллбеков в LUA - далеко нет.
 
Цитата
sam063rus пишет:
Класс скрипта, класс для бумаги. Класс для работы с глобальными переменными.
Добрый день.
Можете подробнее описать что требуется?
 
Михаил,

см. #35

Если Вы про то, что Вам надо подробную иерархию классов - что ж, я могу её составить. В какой форме желаете? В формате сообщения в посте - тесно, в формате e-mail - тогда другие участники не смогут подключиться к обсуждению и редактированию.
 
Цитата
sam063rus пишет:
Михаил,

см. #35

Если Вы про то, что Вам надо подробную иерархию классов - что ж, я могу её составить. В какой форме желаете? В формате сообщения в посте - тесно, в формате e-mail - тогда другие участники не смогут подключиться к обсуждению и редактированию.
Давайте уже в любой форме.
 
насчёт "бумаги" - уже писал в общих чертах.
Глобальные переменные:

HookGvarChang("MyGvar", "MyGvarChangeEvent" )
MyGvarChangeEvent
do smth work
end

getGvar("MyGvar")
setGvar("MyGvar")

Под словом "глобальные переменные" - следует понимать глобальные в масштабах всех скриптов, т.е. по сути, нативные на уровне квика.

Класс скрипта: В зачатке уже реализован, дело за большим количеством коллбеков, совмещение его функциональности с классом индикаторов (т.е. в идеале не должно быть такого, что в индикаторах не доступны очень полезные функции квиковского ядра - это сильно ограничивает функционал) возможности из скрипта "хуков", полный переход на полностью коллбек-style программирование. Уход от main() (боюсь уже говорить...)
 
Предоставлю здесь, за основу - можно взять тот же wealth-lab
 
http://docs.cryengine.com/display/SDKDOC4/EntityUtils+Lua
тут неплохо показано: в скриптах на LUA - мы не создаём через какие-то там метатаблицы, и не редактируем объекты в самом LUA , а используем уже готовые функции: "MakeDerivedEntity( _DerivedClass, _Parent )", "broadcastEvent", "MakeUsable( entity )" и т. п.
 
Michael Bulychev

мне кажется или Вы удалили часть своих сообщений?
 
Добрый день.
Вам кажется.
 
Цитата
Сергей Радченко пишет:
просьба добавить возможности:
1 менять цвет у линии в индикаторе
2 Также добавьте отображение индикатора в виде баров, свечей, гистограммы.
3 Будет супер если появится возможность рисовать индикаторы, графики без привязки ко времени.
1. Менять цвет уже сейчас можно. или имеется в виду динамическое изменение цвета?
2. мы уже работаем над этим
3. в этом пункте не совсем понятно. уточните пожалуйста на примере.
 
Цитата
Sergey Gorokhov пишет:
3. в этом пункте не совсем понятно. уточните пожалуйста на примере.
пример: ваш плагин stratvolat.dll. т.е. когда ось абсцисс привязана не ко времени, а к совершенно независимому источнику.
 
Цитата
Sergey Gorokhov пишет:
Цитата
Сергей Радченко пишет:
просьба добавить возможности:
1 менять цвет у линии в индикаторе
2 Также добавьте отображение индикатора в виде баров, свечей, гистограммы.
3 Будет супер если появится возможность рисовать индикаторы, графики без привязки ко времени.
1. Менять цвет уже сейчас можно. или имеется в виду динамическое изменение цвета?
2. мы уже работаем над этим
3. в этом пункте не совсем понятно. уточните пожалуйста на примере.
хотелось бы увидеть возможность у одной линии менять цвет(менять динамически). Как пример http://strategforexhome.ru/wp-content/uploads/2013/05/supertrend.jpg
Просьба реализовать возможности реализовать цветовые зоны по типу: залить цветом между линий индикатора пример http://strategforexhome.ru/wp-content/uploads/2013/05/i-sessions.jpg
также просьба реализовать не временную шкалу для реализации нестандартных свечей по типу: формировать свечу при достижении объема(все свечи на графике с одинаковым объемом наторговки), хейкинаши и т.д. http://www.ratingsforex.ru/uploads/heiken-ashi.png
дайте возможность формировать индикаторы в виде свечей и гистограмм.


Спасибо за то ,что стараетесь улучшать платформу.
 
Ваше пожелание зарегистрировано. Мы постараемся рассмотреть его и сообщить Вам результаты анализа. Впоследствии, по результатам анализа, будет приниматься решение о реализации пожелания в будущих версиях ПО.
 
Добрый день.

Информация по пожеланиям:

1.  возможность менять цвет индикатора динамически.
2. отображение индикатора в виде баров, свечей, гистограммы.
3.  возможность рисовать прямоугольники

Мы рассмотрели пожелания. По итогам их анализа сообщаем Вам, что мы также считаем целесообразным их реализации и постараемся включить в план доработок при выпуске одной из следующих версий нашего ПО.
 
Цитата
Сергей Радченко пишет:
3 Будет супер если появится возможность рисовать индикаторы, графики без привязки ко времени.
а где этот пунктик???
или он для вас недостаточно целесообразен????!!!
 
Цитата
sam063rus пишет:
Цитата
Сергей Радченко пишет:
3 Будет супер если появится возможность рисовать индикаторы, графики без привязки ко времени.
а где этот пунктик???
или он для вас недостаточно целесообразен????!!!
Добрый день.

Данное пожелание рассматривается.
Страницы: 1 2 След.
Читают тему (гостей: 1)
Наверх