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

Не совсем так.
Это же индикатор, а не просто данные.

Нужно иметь такую возможность:

1. получили, например, вызов OnCalculate для индекса 5 от основного источника данных (т.е. от источника, по которому построен индикатор, как сейчас). Отлично, что-то посчитали и нарисовали.
2. теперь получили данные по свече с индексом 4 по дополнительную DataSource. Значит что надо:
а) получить вызов OnCalculate для индекса 4, где мы получили данные по основному и дополнительному источникам и тут же иметь возможность выставить новое значение индикатора в точке для свечи 4.
б) дополнительно получить вызов OnCalculate для индекса 5, т.к. этот индекс, очевидно, надо заново пересчитать, ведь в свече 4 у нас получены новые значения, а от значения в точке 4 у нас зависит и значение индикатора в точке 5; после иметь возможность обновить значение индикатора в точке 5, т.к. оно изменилось

Так понятно?

Чета я забыл, что getMoney возвращает таблицу.
Не в строчку выступил, извиняюсь.  ;)

Мне просто любопытно: а вы также наугад составляли буквы в программах mql ? вот просто любопытно.


Приведу тут тоже ссылку, потому как найти её на этой сайте в самом деле крайне затруднительно; я просто помню по каким словам ее гуглить, просто так фик найдёшь.
https://arqatech.com/ru/support/files/
Внизу страницы "Документация по языку LUA в QUIK и примеры.zip"

Если запрашиваемой возможности инет - просьба зарегистрировать пожелание.

Сейчас после построения LUA-индикатора при наведении мыши на линию индикатора отображается дата/время соотв. места и значение индикатора в точке указателя мыши.
Требуется: добавить возможность для каждой вычисляемой точки (свечки) индикатора задавать значение (и наименование) пользовательского параметра (-ов), которые будут отображаться в легенде при наведении мыши.
Это необходимо, чтобы отображать дополнительную информацию на индикаторе (можно отладочную - какие были промежуточные параметры вычисления, можно смысловую - дополнительные параметры состояния рынка в той или иной точке индикатора)

Не поможет, т.к. нет средств заставить индикатор перерисоваться в этот момент.
В пункте а) списка проблем в некущем API я в самом деле не то написал.

Требуется: иметь возможность строить Lua-индикаторы на основании нескольких источников данных.
Легально и корректно.

Сейчас скрипт строится только по одному источнику данных.

Можно получать второй (трений и т.д.) источник
- через метку другого графика читать с него значения вызовами getCandlesByIndex;
- либо использовать data source,
но каждый из этих путей неполноценный, т.к.
а) нет уведомлений о приходе данных из "второго" источника, а значит нет возможности строить скрипт с учетом изменившихся данных второго источника;
б) сложности в настройке / использовании.
Основное это а), конечно.

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

Вопрос: когда будет такая возможность в QUIK?

В справке написано:


Вопрос: если AddLabel вызывается из скрипта-индикатора - всё равно надо обязательно указывать chart_tag ?
Индикатор же явно к графику и так привязан, если на этом же графике и хочу метку вывести. Да и  индикатор - сам по себе график. По умолчанию (если chart_tag не задать) метка не привяжется к индикатору или графику, по которому он построен что ли?

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

На срочном рынке ММВБ т.н. "планки" - это ограничения самой биржи, и биржа их транслирует. Квик тут ни при чем.

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

https://forum.quik.ru/forum1/topic6410/

Но самое грустное - это вот этот ответ:


Т.е. создавал ты таблицу, настраивал - а теперь из-за явной ошибки версии должен обязательно её заново пересоздать
Толково, чё

Напомню, ветка начиналась с "Добавить функции вида pauseCallbacks и resumeCallbacks, где первая приостанавливает вызовы многопоточных колбеков". И мы долго выясняли про какие многопоточности идёт речь.
Вроде как выяснили (хотя явно вы это не писали, но я вас понял так), что pauseCallbacks и resumeCallbacks вызываются в main(). Ну иначе бы и проблемы не было, очевидно.
Теперь внезапно все это в одном потоке, как так??

Так где вызываются pauseCallbacks и resumeCallbacks? и если не вmain(), то о какой многопоточности речь и как эти функции помогут, будучи вызванными не в main() ?


Давайте не менять условия задачи на ходу. Это совсем уже другая история, она здесь не обсуждается.


В самом деле: вы d каждом сообщении не договариваете половину важных деталей под девизом "и так очевидно", а когда совершенно не очевидные детали кое-как клещами из вас вытянешь - вы же других обвиняете в том, что кого-то там держат за идиотов.
Самому-то не стыдно не уметь корректно и внятно общаться?

Python тогда здесь при чем?

Напишите, как бы вы в Python отправляли информацию в телеграмм-бот. Приведите пример кода, попробуем переложить на Lua и библиотеки для Lua.

Однако мне всё же интересно было бы тут услышать ответ тех. поддержки
Неужели при указании нестандартного интервала в предыдущих версия QUIK корректно формировал и отдавал нестандартные свечи?

Почему?? Хочу такую кнопку!!

Я тоже хочу отменять сделки!!
Запишите моё пожелание!

Скрипты - они про автоматическую работу. Полностью. Без наблюдения человеком.
При этом очень важно, чтобы скрипт работал. Да, в нём могут быть какие-то ошибки. Может быть ошибки при экзотических сценариях, приводящие к остановке скрипта.
Но важно, чтобы скрипт все же работал, даже если наткнулся на какую-то непредвиденную ситуацию.
Пусть и методом повторного перезапуска (фактически "с нуля"). Понятно, что стартовать скрипт "с места падения дальше" - невозможно.
Как скрипт будет взлетать с нуля после аварии и восстанавливать своё состояние - уже проблема разработчика скрипта. Хотя можно и передать какой-то признак в OnInit, например, "рестартовано автоматически после ошибки", пригодится.

Если вы беспокоитесь, что скрипт "задолбает" терминал перезапусками - можно предусмотреть вариант: прекратить перезапуски, если скрипт упал 10 раз за какое-то время (за минуту, например). Хоть я и не уверен, что это нужно.

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

Однако пожелание для QUIK есть: штатные средства межпоточной синхронизации в QLua таки нужны.

Еще лучше, конечно, пересмотреть модель выполнения скриптов. Никакие конкурирующие потоки в рамках одного скрипта там явно не нужны.

Считаю это ошибкой, которую разработчики QUIK должны исправить.
Интерфейс у терминала русский, по умолчанию для русских букв штатные upper / lower должны корректно работать.

Скрипты Lua используете?

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


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


Вообще-то это нормальное, обычное и ожидаемое многопоточное выполнения кода.

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


Я согласен с тем, что многопоточность в скриптах была сделана напрасно; от нее оказалось больше проблем, чем пользы. Было ли это очевидно в момент проектирования - не уверен.
Однако пользователи страдают по другим причинам, считаю:
а) не умеют в многопоточность;
б) сделав многопоточность в скриптах, ARQA не добавила функций для межпоточной синхронизации.

Пункт а) решается чтением книжек.

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

Ну и еще в QLua есть "Потокобезопасные функции для работы с таблицами Lua". В отдельных случаях они спасают, но в очень узком круге случаев, да.

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

Артем,
я таки напомню мой вопрос, адресованный вам, на который вы упорно стесняетесь дать ответ:


Ответ от вас хотелось бы услышать.

На мой взгляд вы куда-то не туда роете. Ну т.е. там, где нет практической пользы.
Для практической пользы достаточно считать, что все main() работают параллельно, и параллельно с ними работают callback'и.
Параллельно - значит любая часть кода этих main() и callback'ов может быть выполнена в произвольном порядке.
Нужен точный порядок - надо придумывать синхронизацию, да. Иначе просто считать, что любой кусок кода может быть выполнен в любой момент.

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

Нет, не в произвольный.
В терминале возникает какое-то событие.
1) Терминал доделывает все свои дела, в том числе полностью завершается выполнение Lua-кода колбеков, отрисовывает интерфейс если надо и т.д.
2) Выбирает событие из своей очереди
3) Вызывает Lua-колбек произошедшего события (если таковой имеется), этот колбек до конца выполняется (т.е. до выхода из колбека), ведь так?
4) Если есть еще активные скрипты с таким же колбеком - все такие колбеки последовательно вызываются и завершаются (выходом из них)
Всё это в рамках одного основного потока терминала
5) После этого терминал обрабатывает свой код, связанный с данным событием (никакие колбеки не вызываются в этот момент)
6) Терминал переходит к следующему пришедшему событию и далее на пункт 2)

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


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

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


При этом в справке есть уточнение:


Наверное было бы логично, если бы при неправильном значении interval тоже возвращалось nil

А как надо починить?
Должно возвращать ошибку? или nil?
Или должно возвращать данные?
А может в предыдущей версии работало как-то иначе, а теперь поведение изменилось?

Параллельно с чем? Хорошо бы уточнять, а то каша получается в понимании разными людьми.

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


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

Вот тут нарисована картинка, которую даже стырили в документацию ARQA.
https://quik2dde.ru/viewtopic.php?id=16

Может она что-то для вас прояснит?

Callback-функции вызываются в основном потоке работы терминала.
В "другом потоке" работает main().

Так что что там вызывается "посреди выполнения другого кода" - мне не понять.


Callback-функции работают строго последовательно, т.к. выполняются все в одном потоке. Уберите код из main() (ну кроме заглушки про is_run) - и никакого "параллельного кода" у вас не останется, будет ровно то, что вы хотите - полностью однопоточный код без каких-либо проблем.

Так определение "многопоточных колбеков" будет уже или нет?

стр. 112

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

https://arqatech.com/ru/support/files/
Документация по языку LUA в QUIK и примерыzip, 4.3 МБ
https://arqatech.com/upload/iblock/194/quik_lua.zip
"Интерпретатор языка Lua.pdf"

Если бы знал - я бы вас не переспрашивал.
В QLua есть понятие callback-функций, которые вызываются терминалом при определённых событиях. Вызов этот происходит в основном потоке работы терминала QUIK.

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

https://forum.quik.ru/forum10/topic5408/

Обещанного 3 года ждут. Ну или 33, в случае в QUIK
Хотя, даже и не обещали.

Там намучено не пойми чего.


Что такое "многопоточный колбек"?


Так вы предполагаете, что после возобновления все "пропущенные" колбеки будут вызваны?? из вашего первого сообщения такое желание совершенно не очевидно.

TGB, Артем,
прикольные вы чуваки, с интересом за вами наблюдаю. Я, видимо, не понимаю кайфа мазаться об говно.
Но вы не останавливайтесь, очень вас прошу! Наблюдать всё это крайне интересно.

Как другие пользователи генерируют этот trans_id легко нагуглить по форуму
https://www.google.com/search?q=site%3Aforum.quik.ru%2Fforum10%2F+trans_id

Где вы вычитали про такую странную функцию?

math.random(100000)

Не смог найти ветку на форуме, но точно помню, что писал в поддержку предложение запускать из папки LuaIndicators только файлы  *.lua
Они отписались, что в 8.13 это реализовали... Явно отсюда ноги растут.

Простите меня, люди!  

А еще обнаружил поиском такую ветку форума с запросом 2-х летней давности: https://forum.quik.ru/forum10/topic3758/ (это не моё!!)

Эти поля элементарно вычисляются. Как - указано в справке info.chm, раздел "Позиции по деньгам":

«Всего» = «Текущий остаток» + «Текущий лимит»
«Доступно» = «Всего» - «Заблокировано»

Так что добавлять их в коллбек OnMoneyLimit смысла нет.

Что не так с кодами клиентов?

Нет, ненормально.
Это не дота и не танчики.
Это игра на реальные деньги. На ваши реальные деньги.
Договора с банками тоже не читаете?

Почитайте материалы в сети или сходите на курсы к брокеру.

http://www.h2t.ru/blog/7620.html
https://smart-lab.ru/blog/297231.php
короче гугл штука мощная

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

Нет передёргивания.
Сервер данными может и располагает, но до клиента они будут ехать еще какое-то время.
И? какие ваши предложения?
Пример см. в предыдущем сообщении.


Для ТТТ достаточно поставить настройку "Очищать в новый день" или "в новую сессию", что-то такое, забыл название. Тогда недоехавшие данные будут или отсутствовать или равны 0.

Супер.
Я подключился к серверу в 10:00. "Заказал данные". Сервер лил мне их 1 минуту (да, я оптимист). В 10:01 до меня доедет маркер "на момент заказа данные загружены".
Т.е. я имею данные на момент 10:00, и начинаю на их основании отправлять заявки. Хотя сейчас 10:01 и рынок уже совсем другой.

Я ведь всё описал по вашему алгоритму? ничего не упустил?

О! Локализовал проблему!
Парень, реально ты крут  

Книжку твою никому неизвестную ты для доктора пишешь. Ему, быть может, будет любопытно к истории болезни приобщить.
Более никому этот бред не интересен.

Именно про этот код тебе, идиоту со стажем, и говорилось: с таким написанием - огребёшься. Огрёбся. Но продолжаешь изворачиваться, т.к. говно иначе не умеет.

s_mike@rambler.ru, вы всерьез пытаетесь разговаривать с говном как с человеком??
Удивительные люди :)