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

Выбрать дату в календареВыбрать дату в календаре

Страницы: 1 2 3 4 5 6 7 8 9 10 11 ... 16 След.
Работа функций OnStop() и SetCell(), Подвисает скрипт
 
Roman Azarov,
Цитата
Как уже было сказано ранее, такова реализация работы OnStop() на текущий момент, это не является ошибкой.
А вот КТО, простите, решает, что является ошибкой, а что нет? Вам уже ГОДАМИ на все лады твердят, что это именно ошибка - и что толку? Я бы даже сказал, НЕПРИЛИЧНАЯ ошибка. Эту ветку цитировать не буду, а фрагменты своих разговоров приведу "в дополнение":

03.07.2021 16:31:47
Andrey Bezrukov, Андрей, Ваша рекомендация "вынести SetCell в OnStop" есть фактически признание того, что такой поведение ЯВЛЯЕТСЯ ошибкой в работе lua-скриптов.
Это была, кажется, первая ошибка, на которую я напоролся, придя сюда. Давал соответствующее предложение, которое, кажется, даже было зарегистрировано. Сейчас я сформулировал бы это так: "НЕЛЬЗЯ выносить в обработчик любые действия, которые не могли бы быть выполнены в основном потоке". Или лучше заменить "нельзя" на "категорически не рекомендуется". OnStop должен сбрасывать флаг бесконечного цикла в main - И ВСЁ! Более того: всё это дело УЖЕ прекрасно работает, если флаг останова сбрасывается в любом другом месте, кроме OnStop.

19.06.2021 19:08:23
1. Почти мгновенно после того, как я появился здесь и попробовал написать свой первый скрипт, я столкнулся с ситуацией потери управления по OnStop. Антон тогда подробно расписал мне, что происходит и почему, и с тех пор у меня в самом этом обработчике сидит запись результатов, закрытие лога, убийство таблиц и прочее, но ведь это же ненормально! Согласитесь, весьма неприятно потерять результаты всего дня только потому, что мы имели неосторожность "не вовремя" обратиться к функциям основного потока вроде SetCell.
Пожелание: после остановки бесконечного цикла передавать управление следующему за циклом оператору в main - так, как это и происходит, если флаг isRun сбрасывается не в OnStop, а в любом другом месте.

Andrey Bezrukov
23.06.2021 14:11:56
1. Ваше пожелание зарегистрировано. Мы постараемся рассмотреть его и сообщить Вам результаты анализа.

Ну и?
Работа функций OnStop() и SetCell(), Подвисает скрипт
 
Andrey Bezrukov, Андрей, Ваша рекомендация "вынести SetCell в OnStop" есть фактически признание того, что такой поведение ЯВЛЯЕТСЯ ошибкой в работе lua-скриптов.

Это была, кажется, первая ошибка, на которую я напоролся, придя сюда. Давал соответствующее предложение, которое, кажется, даже было зарегистрировано. Сейчас я сформулировал бы это так: "НЕЛЬЗЯ выносить в обработчик любые действия, которые не могли бы быть выполнены в основном потоке". Или лучше заменить "нельзя" на "категорически не рекомендуется". OnStop должен сбрасывать флаг бесконечного цикла в main - И ВСЁ! Более того: всё это дело УЖЕ прекрасно работает, если флаг останова сбрасывается в любом другом месте, кроме OnStop.
Получение признака "Субординированный инструмент" в lua
 
Andrey Bezrukov, Хорошо, всё считаю согласованным, кроме пункта 3. Юзеру-то какое дело, что там "есть также и служебные, технические параметры недоступные для обработки"? Ладно, у меня за плечами 40 лет программирования, причём, в основном, системщиком - я уже давно научился "доставать левой ногой правое ухо" и проблему с многократными вызовами на одно событие фактически решил. А новичкам что делать, которые в подавляющем большинстве либо получайники либо полные? Конечно, регистрируем!

Anton, Я тоже боюсь любых модификаций, но я по натуре перфекционист: НУЖНО хотя бы пытаться!  :smile:  
Получение признака "Субординированный инструмент" в lua
 
Andrey Bezrukov, Отвечаю тоже по пунктам:

1. Вот ссылка на тему, начиная с моего сообщения и вниз, до ответов Антона:
https://forum.quik.ru/messages/forum10/message49164/topic5872/#message49164

3. Да, подразумеваются  именно вызов callback-функций (одна из причин, почему я стал пользоваться только OnTrade, как минимально необходимой для торговли). Они тоже приходят пачками по три штуки, совершенно одинаковых. Приходится запоминать её ID и отбрасывать дубли. Если учесть, что заявки могут быть в несколько лотов, а также "левые" (сделанные юзером в обход скрипта), приходится изворачиваться глистом на сковородке. У меня это сейчас выглядит так:
Код
s=0;         -- ID найденной сделки или 0
for j=1,a[i][12][0][0] do    -- цикл по сделкам (поиск уже обработанной)
 if tostring(a[i][12][j][0])==tostring(n.order_num) then 
  if tostring(a[i][12][j][1])==tostring(n.trade_num) then goto Q;end;
  k=a[i][12][j][2];      -- остаток лотов по этой заявке
 end;         -- конец условия "найдена сделка этой заявки"
 if tostring(a[i][12][j][0])==tostring(n.trans_id) and a[i][12][j][1]==0 then 
  s=j;goto qq;end;end;      -- первая сделка по заявке
if k==0 then       -- сделка по "левой" заявке (в обход скрипта)
...
Мало того, они приходят вразнобой! Вот я матерился по этому поводу 09.12.2020 15:09:04:
Как оказалось, я страдал чрезмерным оптимизмом: мало того, что прерывания OnOrder и OnTrade приходят пачками (что, конечно, есть форменное свинство и должно быть исправлено), так они ещё приходят и вразнобой! По крайней мере, когда одна заявка реализуется через нескольких сделок: сначала приходит OnTrade с ID заявки и ID сделки, затем с ID заявки и ID ВТОРОЙ сделки, а затем с ID заявки и снова, падла. с ID ПЕРВОЙ сделки! В результате мой алгоритм думает, что сделок совершено больше, чем в действительности.

4. Почему же "очень общим образом"? Совершенно конкретно: SetColor (iTable, iRow, iCol, BCol, TCol, SelBCol, SelTCol, -1, -1) красит ячейку, а без двух последних аргументов - нет. При этом даже не ругается, а "просто не работает". А кому они нужны, эти SelBCol и SelTCol? Разве что для каких-то экзотических применений. А какие ещё аргументы должны быть необязательными - не знаю. Напоролся - сказал.

5. Нет, я ни на чём не настаиваю - это проявлялось давно, и я почти сразу стал в случае необходимости изменения набора строк перебивать заново всю таблицу - глюки тут же пропали.
Код
Clear(T);         -- обнуляем таблицу
for i=0,N-1 do       -- цикл по тикерам (вставка строк и анализ)
 if a[i][0][9]~=-1 then       -- тикер должен быть
  a[i][0][9]=InsertRow(T,-1);end;end;
6. Ясно, Неприятность эту мы переживём!(с) :smile:

7. Насколько я помню, Старатель подробнейшим образом разбирал это дело. А я даже не разбирался - просто повесил в обработчике:
if (n==QTABLE_CHAR and l==13) then DestroyTable(T);D();J();end;
После чего пропавший текст восстанавливается. В общем, помогло. И, поскольку я скрипт пишу для себя, разбираться с подобными вещами не буду - других дел выше крыши.
Получение признака "Субординированный инструмент" в lua
 
Andrey Bezrukov, УХ ТЫ! Даже не читая - я охренел. Меняю своё мнение о сотрудниках техподдержки на прямо противоположное, приношу свои извинения за домыслы нехорошие о вас. Почитаем...
Получение признака "Субординированный инструмент" в lua
 
Andrey Bezrukov, Ну вот, всё по старой схеме, один в один! Хоть бы отклонили что-нибудь, хоть бы какая реакция была! Так что ответьте САМИ: стоит ли давать вам "ясно сформулированные предложения с озвученной аргументацией" или нет. А я с местной техподдержкой разговаривать больше не хочу.
Получение признака "Субординированный инструмент" в lua
 
Andrey Bezrukov, Я же говорю: я УСТАЛ "сообщать вам об этом, сопроводив сообщение информацией, полезной для анализа" - всё это уходит, как в песок. Я всё могу понять, кроме глухого молчания.

Да, в моих пожеланиях речь нередко идёт о задачах, которые я могу уже сейчас решить штатными средствами, но они мне кажутся неудобными. При этом я прекрасно понимаю, что абсолютным приоритетом является обеспечение надёжной торговли через терминал QUIK - всё остальное вторично (включая весь Lua с потрохами или наиболее одиозные его моменты вроде динамической типизации или кражи типа integer). Я тоже старался "расставлять соответствующие приоритеты, выделяя из них в первую очередь безусловно приоритетные задачи" - так, как я это вижу. Ладно, пробегусь ещё разок по своим сообщениям... мамочки, да их 777 - более полуметра! Итак, высказанные уже давно пожелания:

1. Почти мгновенно после того, как я появился здесь и попробовал написать свой первый скрипт, я столкнулся с ситуацией потери управления по OnStop. Антон тогда подробно расписал мне, что происходит и почему, и с тех пор у меня в самом этом обработчике сидит запись результатов, закрытие лога, убийство таблиц и прочее, но ведь это же ненормально! Согласитесь, весьма неприятно потерять результаты всего дня только потому, что мы имели неосторожность "не вовремя" обратиться к функциям основного потока вроде SetCell.
Пожелание: после остановки бесконечного цикла передавать управление следующему за циклом оператору в main - так, как это и происходит, если флаг isRun сбрасывается не в OnStop, а в любом другом месте.

2. Я не понимаю (и не хочу понимать!) почему "для того, чтобы строки отображались, необходимо, чтобы вызов CreateWindow() производился ДО процедуры добавления строк в таблицу". Здесь участники дискуссии, на мой взгляд, очень убедительно показывали, что такого быть не должно.
Пожелание: хотя бы внесите в описание языка эту "особенность"! Ведь многие (особенно новички) даже не подозревают о таких "нюансах" и тратят многие часы на отладку того, что в принципе не может быть отлажено.

3. Я считаю, что более одного коллбека на одно событие есть грубейшая ошибка в программном обеспечении, которая, к сожалению, не исправляется годами.
Пожелание: исправить.

4. Некоторые функции допускают необязательные аргументы (например, основание системы счисления в tonumber), а другие - нет. Так, SetColor (iTable, iRow, iCol, BCol, TCol) НЕ работает, а если подставить туда два дополнительных аргумента , SelBCol, SelTCol, равные QTABLE_NO_INDEX (-1) - начинает работать! Поскольку мне совершенно не были нужны выделенные ячейки, до необходимости переделать вызов в SetColor (iTable, iRow, iCol, BCol, TCol, SelBCol, SelTCol, -1, -1) без подсказки от службы техподдержки я бы просто не додумался НИКОГДА!
Пожелание: разрешить не вводить необязательные аргументы функций везде, где это возможно (подставляя при необходимости значения по умолчанию).

5. При удалении строк с помощью DeleteRow и/или вставке (InsertRow) могут проявляться разные неприятные эффекты (данные пропадают или записываются не в те строки). Похоже, здесь путаются понятия ключа и индекса (кстати, этот эффект проявляется в таблице заявок в Квике даже при ручной торговле: после обрыва связи часть строк могут оказаться пустыми, и помогает только перезапуск Квика).
Пожелание: исправить.

6. В циклах имеется break, а вот continue почему-то нет (эмулирую его при помощи  goto).
Пожелание: исправить.

7. Время от времени пропадает текст в таблицах (последний раз это проявилось вчера на версии, обновлённой позавчера). Приходится выносить создание таблицы в отдельную функцию, а в обработчик событий вешать (на Enter) DestroyTable+CreateWindow+SetWindowPos.
Пожелание: исправить.

8. Почему обеспечение уникальности идентификаторов транзакций ложится на юзера?
Пожелание: переделать вызов как ID=sendTransaction(), а в случае неудачи возвращать 0. А лучше дать вместо неё более простой интерфейс sendOrder (или даже Buy и Sell), и уж, конечно, не заполнять таблицы, а передавать необходимые данные аргументами.

9. Часто обсуждаемой проблемой являются свечи, доступ к которым в существующей реализации весьма затруднён.
Пожелание: дать утилиту типа GetLastCandles (class, sec, interval, numberof). По умолчанию одна последняя свеча. Возможно, даже с коллбеком. Или хранить (хотя бы в той же ТТТ) последние свечи по всем таймфреймам.

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

Ну, а за динамическую типизацию и за тип integer... далее нецензурно.
Получение признака "Субординированный инструмент" в lua
 
Andrey Bezrukov, Так Вы предлагаете, чтобы сами юзеры мордовали запросами своих брокеров или, прости, Господи, биржи? Господа, мы работаем в Квике! В самой популярной торговой системе (по крайней мере, в России)! Кому, как не вам интегрировать "необходимые настройки от разных ТС", унифицировать их "огромное количество разных параметров"?. Брокеры сами предлагают использовать именно ваш софт - вот буквально сегодня один из них предложил мне обновить очередное "шило на мыло". Я, как всегда, покорно обновил. И чего?

И какой у вас, простите, "крайне большой объём неоправданной работы"? Чем вы, собственно, там занимаетесь? Четверть, если не треть кода моего скрипта написана исключительно для компенсации глюков вашего софта, и код этот пестрит комментариями типа "это костыль от дебилизма с goto" или "прорисовка таблицы визуализации выведена из main в самостоятельную функцию для возможности исправления ошибки программного обеспечения QUIK (исчезновение текста в ячейках таблицы)". К кому прикажете обращаться? К Биллу Гейтсу?

А я перестал давать вам "пожелания на добавление какой-либо дополнительной функции" - вы же на них просто не реагируете ВААПЩЕ НИКАК! А давал я их когда-то именно "содержательно, без излишней лирики" - например, 13.03.2021 11:47:57:
И самое главное - почему обеспечение уникальности идентификаторов транзакций ложится на юзера? Ведь для Квика это просто порядковый номер строки в его таблице - даже искать ничего не надо! Так не проще ли сделать ID=sendTransaction, а в случае неудачи возвращать 0? И волки целы, и овцы сыты.

Или чуть позже, 27.04.2021 20:35:04, уже "с лирикой":
Ну зачем рядовому юзеру знать, например, о существовании sendTransaction? Не говоря уже о том, что обеспечивать уникальность их айдишек он должен сам - во радость! А набивать значениями таблицы с фиксированными именами полей - это как?

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

И даже:
Работоспособность системы является наиболее приоритетной задачей для всех - разработчиков, тестеров и технической поддержки.

Ну и как там с "работоспособностью"? Лично я просто БОЮСЬ новых версий - функциональности они наверняка не добавят (да она уже почти и не нужна), а новых глюков - сколько угодно! У меня вот никак руки не доходят убрать в main подачу заявки из обработчика прерываний (кнопки "купить" и "продать" в моём меню): 99 раз она работает нормально, а на сотый подвешивает Квик! Как вообще может ИНТЕРПРЕТИРУЕМЫЙ код подвесить систему, да так, что её можно убить только из диспетчера задач - это выше моего понимания! А потеря управления по OnStop? А сколько раз вам писали пожелание, чтобы на одно событие приходило ОДНО, БЛИН, прерывание, а не целая колода? А дамп состояния моего портфеля я теперь сбрасываю на диск каждые 5 минут - это просто мне заняться больше нечем?Так что НЕ ХОЧЕТСЯ давать вам "ясно сформулированные предложения, тем более с озвученной аргументацией", даже если они "всячески приветствуются" (перед тем, как бросить в корзину).
Получение признака "Субординированный инструмент" в lua
 
Roman Azarov, Ну и что, если "параметры таблицы текущих торгов транслируются биржей (не только их значение, но и сам набор)"? ТТТ в Квике - это ТТТ В КВИКЕ! Можно сделать свои имена параметров, можно даже с синонимами - это же как два пальца об асфальт! Что значит "не представляется возможным"? И при чём тут вообще экспорт, DDE, ODBC или там CSV? Нужен доступ к данным, то бишь МЕТОД! Не описания структур данных (которые, к тому же, могут измениться в любой момент), а методы для их получения. Точно такая же хрень во всей этой катавасии со свечами - алгоритмически вопрос выеденного яйца не стоит, а обсуждение идёт годами. Методы нужны, методы!
Вызов индикатора в скрипте, Использование значений индикаторов при работе со свечками
 
Да будут свечи!

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

Проблемы здесь следующие: во-первых, термины "свечи" и "японские свечи" давно уже воспринимаются как синонимы, и с этим явно ничего не поделаешь - приходится смириться. Во-вторых, здесь идут некоторые наводки от разных систем счисления: двоичной, десятичной и 60-ричной. Десятичная здесь выглядит явно инородным телом (таймфреймы в 5 или 10 минут), а 60-ричная вполне терпимо эмулирует двоичную, что отчётливо видно по набору стандартных интервалов: M15, M30, H1, H2, H4. У меня "не сговариваясь" получилось абсолютно то же самое: самые малые свечи четвертьминутные, затем полуминутные, 1 минута, 2, 4. Ну и три "выродка": D1 (1 день), W1 (1 неделя) и MN1 (1 месяц).

И самое главное: практически полностью отсутствует сервис для получения этих свечей: какие-то графики, какие-то индикаторы, какие-то CreateDataSource... кошмар! Почему бы не дать утилиту что-то типа GetLastCandles (class, sec, interval, numberof)? По умолчанию одна последняя свеча. Возможно, даже с коллбеком. Такое вот у меня пожелание к разработчикам...
Функция Sleep(), Эффективно ли применять фунцкию Sleep() для понижения нагрузки процессора
 
Артем, Лапуль, я уже говорил, что включён в соавторы одной из операционок - не надо тут мне лапшу с умным видом вешать. Прерывание - это когда обработчик САМОЙ ЗАДАЧИ получает управление, всё остальное - это НЕ прерывание. Операционка может вернуть управление через час, через год - и программа ровным счётом ничего не заметит. Разве что окружение изменилось, вроде значения системных часов.
Функция Sleep(), Эффективно ли применять фунцкию Sleep() для понижения нагрузки процессора
 
Артем, Это чушь свинячья, а не "прерывание по таймеру". Прерывание прерывает работающую программу, а не возвращает управление в приостановленную.
Средства разработки многопоточных скриптов в QUIK., OS_Quesha, свидетельство регистрации в Роспатенте № RU 2020612905. Бесплатная для некоммерческого использования.
 
TGB, Это не диалог - это два монолога - Вы же не отвечаете на вопросы. Так что мне НИЧЕГО не известно о Ваших вариантах представления графов. А соревноваться мне с Вами не в чем.
Средства разработки многопоточных скриптов в QUIK., OS_Quesha, свидетельство регистрации в Роспатенте № RU 2020612905. Бесплатная для некоммерческого использования.
 
TGB, Я очень редко читаю невнимательно - Вы НЕ ответили на мой вопрос, Вы всего лишь сказали, что Вы ДУМАЕТЕ. А вопрос этот принципиальный: либо Вы ЗНАЕТЕ другой способ представления графа, либо Вы его НЕ знаете (вариант "знаете, но используете этот" я отбрасываю, как абсолютно нереальный).

Это не "свое (особое) мнение" - это ТЕХНОЛОГИЯ! Причём не только представления графа, но и его МОДИФИКАЦИИ - а это "две большие разницы"!

Я почему схему транспорта Москвы упомянул? Однажды мой друг попросил её сделать на базе схем движения пассажирского транспорта, представленных на каком-то сайте администрации Москвы (там было десятка два мелких баз, доступных для скачивания). Я всё это дело объединил, определил "станции пересадок" (по координатной близости остановок) трёх видов: до 10 метров (фактически та же остановка, где можно пересесть на другой автобус или трамвай), до 50 метров (чуть отнесённая) и до 200 метров (это обычно выходы из метро). навесил на это дело территориальные деревья (улицы, районы, округа) и тематические (по названиям остановок) - школы, больницы, университеты, кафе, рестораны, магазины (продовольственные, винные, мебельные и прочие), парки, бассейны, музеи, кинотеатры, и прочая, и прочая, и прочая Не сделал только схему движения автомобилей или пешеходов (перекрёстки ведь тоже "станции пересадок" с улицы на улицу!) - исходных данных в тех базах было маловато, тут уже нужна карта вроде OpenStreetMap, Сделал, и говорю: "В каком формате тебе всю эту кухню выдать? JSON? Какой, нафиг, JSON? У меня нет никаких таблиц, у меня многомерный граф! Формат давай!" А вот формата он так и не сумел придумать - и это только для чтения и представления ПОДГОТОВЛЕННОЙ базы, а не для её модификации! А что может Ваша несчастная "сереализованная таблица Lua"? ДА НИЧЕГО!
Средства разработки многопоточных скриптов в QUIK., OS_Quesha, свидетельство регистрации в Роспатенте № RU 2020612905. Бесплатная для некоммерческого использования.
 
TGB, Что "это" Вы "делали не один раз"? Вы можете это сделать - нет, не для схемы транспорта Москвы, а хотя бы вот для этой, достаточно примитивной задачи торговли? Хотя бы в усечённом виде, хотя бы в том, который я описал: счета-валюты-тикеры-заявки-сделки-свечи? Как доступ к элементам получать будете? Как будете, скажем, определять текущее состояние рынка в евровой зоне? Какая вообще будет структура данных - та самая, которую Вы собрались упаковывать-распаковывать?

Это я сказал (профессионализм - это шоры) много лет назад. Цитата точная. :smile:

:evil: Меня не интересует, что Вы думаете, и я не собираюсь гадать на кофейной гуще. Я задал вопрос: "Насчёт таблицы смежности я прав"? Вы способны на него ответить [Y/N]?
Средства разработки многопоточных скриптов в QUIK., OS_Quesha, свидетельство регистрации в Роспатенте № RU 2020612905. Бесплатная для некоммерческого использования.
 
TGB, Опыт.  :smile:  ОГРОМНЫЙ опыт! Насчёт таблицы смежности я прав?
Средства разработки многопоточных скриптов в QUIK., OS_Quesha, свидетельство регистрации в Роспатенте № RU 2020612905. Бесплатная для некоммерческого использования.
 
TGB, А Вы это пробовали когда-нибудь РЕАЛЬНО это сделать? Я практически всю жизнь занимался сложными базами данных, у меня есть две утилитки, которые так и называются: RelToTree и TreeToRel, и я прекрасно знаю, что такое "упаковывать в строку (распаковывать) таблицу (!!!) Lua произвольной структуры" - в частности, на терабайтных базах и, в особенности, на сильно перевязанных базах (иногда с миллионами рёбер на узел графа, да ещё и разных измерений). То, что у Вас "граф" и "таблица" чуть ли не синонимы, говорит о том, что рёбра Вы представляете в виде примитивной таблицы смежности, с которой работать практически невозможно. Я уже не говорю про ошибки, которые имеют пакостную тенденцию накапливаться и плодить ошибки наведённые. Но даже без этого Ваша схема не будет работать НИКОГДА!
Средства разработки многопоточных скриптов в QUIK., OS_Quesha, свидетельство регистрации в Роспатенте № RU 2020612905. Бесплатная для некоммерческого использования.
 
TGB, Во-первых, дерево-то можно, а вот граф произвольного вида - уже нельзя. У меня там на уровне хранения дерево, но на логическом уровне уже граф. Во-вторых, ЗАЧЕМ? НА КОЙ мне эта "серализованная таблица Lua", что я с ней делать-то буду? Мои данные сложнее, они в таблицу просто не лезут.

Да я-то свои проблемы давно решил - диалог меня давно уже устраивает. То, что ещё хотелось бы иметь, относится уже скорее к области выпендрёжа. :smile:  
Средства разработки многопоточных скриптов в QUIK., OS_Quesha, свидетельство регистрации в Роспатенте № RU 2020612905. Бесплатная для некоммерческого использования.
 
TGB, Каких ещё "строк"? У меня же там деревья! :smile:

Имеем N тикеров... нет, даже не так: имеем N валют, M тикеров по каждой валюте, К сделок по каждому тикеру с указанием цены и объёма каждой из них, текущий выигрыш (проигрыш) по каждой валюте и каждому тикеру, заявки на покупку (продажу), стоп-лоссы, свечи по 9 таймфреймам  (надо бы по 16), таймер когда снимать неисполненные заявки, код тикера/код класса/размер лота, код качества тикера (плохой/нормальный/хороший/отличный), код его статуса (можно/нельзя его роботу покупать/продавать), цена последней сделки/спроса/предложения, количество наличной валюты (на которую скрипту разрешено торговать), количество заблокированной валюты, статус кошелька по валютам (избыток/нехватка наличности) плюс всякая мелочь (код клиента, торговый счёт, обработчики событий от юзера и прочая хрень). Кроме того, данные там меняются со страшной силой - даже головное меню раз в 15 секунд может серьёзно поменять количество своих элементов! И вот это всё Вы предлагаете запихивать В СТРОКУ? Побойтесь Бога! :smile:  
Дневные свечи SPBXM, В какую свечку попадают вечерние данные
 
Dr Wed, Но ведь "день" тоже понятие плавающее! К тому же, у ВТБ "концов сессии" минимум три.
Дневные свечи SPBXM, В какую свечку попадают вечерние данные
 
Разные брокеры и должны выдавать разные данные. А что такое "кривые" и "нормальные"?.
Функция Sleep(), Эффективно ли применять фунцкию Sleep() для понижения нагрузки процессора
 
Айдар, Толк от неё совсем в другом: это эмулятор прерывания по таймеру.
Средства разработки многопоточных скриптов в QUIK., OS_Quesha, свидетельство регистрации в Роспатенте № RU 2020612905. Бесплатная для некоммерческого использования.
 
TGB, Именно описывать! Не "пакет IUP", конечно, а возможности прикладника при программировании в событиях.

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

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

Честно говоря, мне жаль выбрасывать средства организации диалога в SINT – за долгие годы там накопилось немало интересных решений: горизонтальные, вертикальные, двумерные, трёхмерные, виртуальные (невидимые), неоднородные, редактируемые меню, управление курсором, горячие клавиши, виртуальные клавиши, клавиши «внутрь» и «наружу» для каскадных (Z-меню), трёхмерных или двумерных меню специального вида (XZ или YZ), организация контекстной помощи и диагностики на ошибки, автоопределение координат или палитры, работа мыши в активных и неактивных координатах меню, локальные меню блоков, синхронизация изменения данных в параллельных окнах, плавающий размер паспорта меню, возможность задания собственного «бланка» меню с указанием на нём координат элементов, переопределение объектов до прорисовки меню, до цикла ожидания события, во время ожидания, после обработки события, перед выходом из меню (одно это расширяет возможности программиста со страшной силой – можно, например, организовать меню из элементов базы данных с их подкачкой и редактированием), разгон при листании некоторых видов меню… да разве всё перечислишь! Я даже немного баловался с «очеловечиванием» диалога: выдавал диагностики системы не статическими строками, а генератором фраз (техника вариантных списков) – склейкой фразы из компонентов-синонимов случайным образом. Получалось довольно эффектно: компьютер уже казался не тупой железякой, а живым собеседником. Или, по крайней мере, полуживым. Но больше всего жалко, конечно, применяемую в SINT технологию программирования диалога в объектах и событиях, которую при использовании веб-браузера практически невозможно сохранить. Частично её удаётся эмулировать путём использования фреймовой структуры, чудом сохранившейся функции eval «и какой-то матери», хотя это просто слёзы по сравнению с организацией диалога в SINT. Тем более, что каждый браузер (а нередко даже и разные версии одного и того же браузера!) работают, мягко говоря, по-разному. Этот раздел и посвящён браузеру как клиентской части СУБД. Второе его название – «Хождение по мукам». Или даже «Mein Kampf».
Средства разработки многопоточных скриптов в QUIK., OS_Quesha, свидетельство регистрации в Роспатенте № RU 2020612905. Бесплатная для некоммерческого использования.
 
TGB, Да очень просто: таблица по тикерам и есть меню. :smile: А дочерние уже содержат информацию по выбранному тикеру. Но, поскольку она бывает довольно объёмная, неплохо было бы иметь и дочерние уже от него (например, по сделкам, по свечам. И редактировать в них кое-что не мешало бы.
Средства разработки многопоточных скриптов в QUIK., OS_Quesha, свидетельство регистрации в Роспатенте № RU 2020612905. Бесплатная для некоммерческого использования.
 
TGB, Ну, я "рискнул использовать таблицу QUIK для создания диалога", и при этом именно "искал лёгких путей". :smile:

Я свято убеждён: "нормальные средства создания диалога" предполагают возможность программирования в событиях - все остальные способы ненормальные. А здесь даже и слова такого нет.

Многопоточность для задач торговли тоже вряд ли нужна - во всяком случае, в Квике это лишь неиссякаемый источник глюков.

Структура меню также не выдерживает критики: у меня это «дерево» меню содержит несколько сотен веток от корня (думаю, вскоре дойдёт до пары тысяч) и время от времени хочется нарастить его до 3-го уровня, причём с редактируемыми элементами. Но потом вспомнишь, как Квик отвисает от команд, пришедших даже из первого уровня иерархии - и всё проходит. :smile:  
Вызов индикатора в скрипте, Использование значений индикаторов при работе со свечками
 
Anton, Какой, блин, "наброс"? Какой "дзен"? Арифметика, школьный курс! Я предлагаю отделить свечи от графиков, дать удобный сервис для их получения, и считать сами свечи по-нормальному, как сумму всех сделок за период, делённая на количество лотов в них. Без этого "японского" идиотизма. Оно, к тому же, и короче будет: одно значение вместо четырёх.
Вызов индикатора в скрипте, Использование значений индикаторов при работе со свечками
 
Господа, я написал как считается среднее арифметическое! Это известно тыщу лет назад, и именно так я считаю свои свечи (попроще, без объёмов, по которым у меня нет данных - да и фиг с ними). А если это кто-то назвал "SMA индикатором" (или там LWMA), то не следует эту глупость бездумно повторять.
Вызов индикатора в скрипте, Использование значений индикаторов при работе со свечками
 
BlaZed, Серьёзно? Оказывается, я всю жизнь разговаривал прозой? Тогда я тоже не перестаю с меня удивляться. :smile:

Какой это, в задницу, "индикатор"? Я эту формулу знаю со школьных лет, а школу я закончил в 1975 году, когда никаких индикаторов и в помине не было!
Опять ошибка получения кол-ва ордеров скриптом
 
Сирануш, Одуреть! Кто лучше знает состояние Вашего портфеля: брокер или Вы сами?  :smile:  
Вызов индикатора в скрипте, Использование значений индикаторов при работе со свечками
 
BlaZed, Ссылочку? Ну разве что на какой-нить учебник по арифметике.  :smile: Тупое мат. ожидание, то бишь среднее арифметическое. Ну, можно ещё и дисперсию дать - есть там какая-то мышиная возня вокруг него или нет. Заодно и гонки курса малыми объёмами будут затруднены. Короче, примерно так:
M=(n1*p1+n2*p2+n3*p3+...)/(n1+n2+n3+...)
Вызов индикатора в скрипте, Использование значений индикаторов при работе со свечками
 
BlaZed, Лучше бы она выкладывала нормальные свечки и простой доступ к ним. И не надо никаких индикаторов! Кстати, и свечки желательно без этих дурацких "японских" штучек, а нормальные, куда более информативные.
Опять ошибка получения кол-ва ордеров скриптом
 
BlaZed, Вообще-то, был и такой случай (у моего друга): именно сделка по нулевой цене. Мы, ессно, охренели, но потом брокер разъяснил, что всё было правильно. :smile:

Я-то понимаю, что если на каком-либо инструменте вдруг видим цену 0, то это либо торгов нет, либо косяк какой с данными. А вот скрипт мой НЕ понимает, и я не очень понимаю, как ему это втолковать. Я также понимаю, что если там не 0, это всё равно ещё ничего не значит. Я когда-то поймал (писал здесь об этом) хороший индикатор: если не цена, а BID/OFFER в нуле, но оказалось, что и это не всегда так.

А мне пофиг, нулевая там цена или нет - у меня все заявки лимитированные.Так что по нулевой цене не продаст, а если купит - не обижусь. :smile:  
Опять ошибка получения кол-ва ордеров скриптом
 
BlaZed,  Прям уж "такого значения быть не может". У меня "вот прям ща" у одного брокера два таких значения и у другого ещё одно. А перед началом торгов на Мосбирже там и ваще одни нули. А в СПб все данные с виду нормальные, но торгов-то всё равно нет. :smile:  
CreateDataSource в цикле по большому списку, Анализ свечей по большому количеству инструментов
 
BlaZed, Именно "степени двоек"! Там просто НЕМЕРЯНОЕ количество информации для принятия решений! Представьте: имеем по две свечи, зато сразу по 16 таймфреймам (к меня сейчас по 9). Из них: две месячные, две недельные и далее со всеми остановками. То есть мы видим движение курса сразу на всех уровнях, да ещё и имеем возможность оценить, как каждый таймфрейм ведёт себя относительно родительского (стоит, растёт или падает) и как ведёт себя по отношению к нему дочерний таймфрейм! Ну разве может какой-то сраный график, да ещё и по заранее выбранному таймфрейму, дать столько информации? Да ни в жисть!

Да, я как раз считаю из ТТТ по LAST.
CreateDataSource в цикле по большому списку, Анализ свечей по большому количеству инструментов
 
BlaZed, Вот и плохо, что "не при созревании". Надо бы дать пожелание разработчикам на доработку софта.

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

Да я уже когда-то заводил ветку с предложениями. Потом осмотрелся немного и перестал. :smile:  
CreateDataSource в цикле по большому списку, Анализ свечей по большому количеству инструментов
 
BlaZed, А как я ещё должен писать? Мне и в голову не приходило, что они могут давать незакрытые свечи! А так всё просто: свеча созрела, пришла - прерывание.

Нет, мы и говорим о разном: у меня незакрытая (накапливаемая) свеча существует лишь потому, что я сам её считаю, как сервер. А вот отдаю её "клиенту" лишь тогда, когда она будет закрыта. Фактически в прерывании и отдаю (15-секундном). А накапливается она в полуторасекундном, то есть обработчик свечей и знать не знает о её существовании: раз он вообще получил управления, значит, пришла новая свеча.

А зачем тогда этот форум, если "разработчики менять все равно ничего не будут"?  :smile: Это же бесплатный набор тестирующих их софт, причём крайне заинтересованных в его качестве!
Выгрузить в файл / вычитать из файла, Выгрузить в файл / вычитать из файла
 
Dr Wed, В ТТТ затолкать ничего нельзя - она только для чтения.
CreateDataSource в цикле по большому списку, Анализ свечей по большому количеству инструментов
 
BlaZed, А какие же ещё могут поступать новые данные в источник, если не свечи? :smile:

Ещё как не пофиг! Мне и в страшном сне не могло присниться искать свечи в функциях для графиков! Тем более, что понятия "скрипт" и "индикатор" здесь с какого-то бодуна разные - тоже не понимаю, какая разница: и то, и другое есть программируемый код, интерпретируемый исполнительным механизмом. И свечи нужны именно моему скрипту - индикаторов у меня нет и не будет.

А у меня логика другая: мало ли, что юзеру в голову придёт? Может, он по десятку таймфреймов захочет свечи получить. И что, мне на каждый чих у сервера данные заказывать? Получил один раз на все случаи жизни - и пусть канает! Тем более, что я при этом могу обеспечить его свечами по всем его "нестандартным интервалам". А вычисления тут вообще ничего не стоят - куда сложнее с сервером связываться, память под каждый таймфрейм выделять/освобождать...

Не понимаю, как такое решение может не подходить другим. если сделок нет - объём нулевой, а все эти H/L/O/C равны цене последней реальной сделки. Абсолютна вся информация здесь имеется для любой стратегии.

ЧАВО???!!! Они что, НЕЗАКРЫТЫЕ свечи присылают?! Совсем шизанулись... Я, как уже говорил, считаю свечи сам, так у меня только три свечи на каждый таймфрейм: две рабочие и одна накапливаемая. И только когда она накопится, последняя свеча становится предпоследней, предпоследняя выбрасывается (меня не интересуют "преданья старины глубокой"), а накапливаемая обнуляется. И пока она снова не накопится и не станет последней, её данные не используются вообще никак. Чего и всем остальным желаю. Это ж ДОДУМАТЬСЯ надо! Я в ауте! :shock:  
CreateDataSource в цикле по большому списку, Анализ свечей по большому количеству инструментов
 
BlaZed, Ну и замечательно! Квик загружает исторические данные, скрипт их читает, если хочет по прерыванию - заказывает коллбек на событие "пришла новая свеча". В любом случае, данные с сервера получает Квик,а не юзер - в том виде, в каком удобнее именно ему.

График-то построить можно, но это РАЗНЫЕ процессы - зачем же их смешивать? Мне вот графики нафиг не нужны, а свечи на что-то и пригодились бы.

Да, конечно, можно и сразу получить часы - я имел в виду, что даже для минутных свечей при нынешних каналах связи объёмы никакие. И потом: откуда Квику знать, что нужно Вам? Он вполне может отдавать Вам то, что нужно Вам, а получать от сервера то, что нужно ему. Может, ему выгоднее получить один массив на все таймфреймы и формировать данные для юзера "на лету"? А нам какое дело, как именно он готовит для нас данные? Это проблемы Квика, а не наши. Кстати, и на низколиквидных инструментах свечи могут идти обычным порядком - мои так и считаются: вот включил я комп в 7 часов, так у меня все рублёвые и евровые активы и большинство долларовых не торгуются, а свечки тикают - просто у них цена не меняется. Я именно по ним и определяю, торгуется данный инструмент в данный момент или нет.

Так ведь актуальные данные это ТОЖЕ исторические данные! Прилетать новые свечки могут, изменяться - нет.
CreateDataSource в цикле по большому списку, Анализ свечей по большому количеству инструментов
 
Никогда раньше не интересовался этим вопросом, поскольку свечи считаю сам, но тема популярная - решил посмотреть и опупел. Всё как-то жутко сложно и непонятно. Во-первых, почему CreateDataSource? Ведь алгоритмически задача проста до безобразия: получить с сервера некий массив данных, причём исторических данных! Что здесь вообще можно "Create"? Во-вторых, какого хрена она в разделе "Функции для работы с графиками"? При чём тут вообще графики? У меня никаких графиков нет, не было и не будет, а со свечами я активно работаю. В-третьих, данные нужно получать фактически по одному интервалу (минутному), поскольку все остальные интервалы (даже полюбившиеся кому-то нестандартные) при необходимости прекрасно считаются из него прямо на клиенте (тики здесь явно инородное тело и должны быть выброшены нафиг). В-четвёртых, объём этих данных для одного тикера даже при круглосуточной работе: 60 минут * 24 часа * 30 дней * 12 месяцев * sizeof одной свечи = курам на смех даже за год, при этом более-менее востребованным является интервал размером в сутки, а время можно даже не указывать: порядковый номер свечи в массиве однозначно его идентифицирует. В-пятых, какого хрена здесь делает SetUpdateCallback?! Какая может быть "обработка изменившихся свечек"?! Повторяю: это ИСТОРИЧЕСКИЕ данные! Всё, поезд ушёл, ничего уже не меняется! Какой-то тихий ужас, господа! Неужели вся эта кухня вообще хоть как-то работает? :shock:  
CreateDataSource в цикле по большому списку, Анализ свечей по большому количеству инструментов
 
Dr Wed, Все?! У меня не все, но их больше, даже если отбросить евровые. Похоже, глючит этот GetClassSecurities.

По поводу свечей - без понятия: лично я их считаю сам, от 15-секундных до часовых, и это никаких проблем с "нагрузкой на quik" не создаёт, так что, тем более, не должно создавать и работа со стандартными - там ведь минимум минутные, а то и реже...
Список инструментов из табл. текущих торгов, Список инструментов из табл. текущих торгов
 
Dr Wed, Рассказывал уже создаёте таблицу, кидаете туда хоть все возможные инструменты, добавляете столбцы "код инструмента" и "код класса", забираете оттуда копипастом всё содержимое и делаете с ним всё, что душе угодно. Работы на пару минут.
Поиск по таблицам
 
Сирануш, Во дела!  :smile: А я как раз наоборот, почти мгновенно ушёл от Excel, как только заработал мой самый первый скрипт (который даже не умел ещё торговать). По актуальности данных и наглядности представления Excel и близко не стоял рядом со скриптом!
Поиск по таблицам
 
Сирануш,  А я что, не торгую роботами?  :smile: Но меня, например, абсолютно не интересуют фьючерсы, а для других это может быть основной (или даже единственный) класс, с которым они работают. В любом случае, зачем заставлять Квик гонять данные от брокера, если они Вам не нужны? Только плодить тормоза или потенциальные глюки. Поэтому МОИ "Текущие торги" содержат данные только о тех инструментах, которые В ПРИНЦИПЕ могут появиться В МОЁМ портфеле, а "Состояние счета" - что и сколько там УЖЕ лежит в данный момент. А что они там "входят и выходят" - да, состояние "Торгов" иногда корректируется. Например, меня "разочаровали" акции AAXN, ACIA, BEAT, BMCH, CBPO, CHA, CHL, CXO, EV, GSH, GTX, HDS, IMMU, IPHI, LVGO, MNK, MTSC, MYL, MYOK, PRSC, PS, RP, SINA, TIF, VAR, VIE, VRTU, WYND - их я выкинул не только из портфеля, но и из ТТТ. А вместо них залил туда несколько десятков новых тикеров. Скрипту-то какое дело? Он работает с теми инструментами, которые я ему укажу - я ведь главнее "железяки х..во й"! :smile:  
Поиск по таблицам
 
Сирануш, Тут два нюанса: как таблица себя ведёт НА САМОМ ДЕЛЕ и как она должна себя вести СОГЛАСНО ОПИСАНИЮ. Что значит "нет инструмента"? А вдруг он через секунду там появится? Или, наоборот, исчезнет? И с какой радости данные "Текущие торги" и "Состояние счета" должны совпадать? В первой из них данные обо всех инструментах, которые отслеживает сам Квик, во второй - содержимое Вашего конкретного портфеля, причём если Вы сегодня продали какой-то инструмент, в таблице он всё равно ещё есть, только его количество (столбец "позиция") равно нулю.

Моему скрипту таблица "Состояние счета" по барабану - он и не знает о её существовании - это я сам иногда сверяю данные этой таблицы с данными скрипта, то есть то, что думает по поводу состояния моего портфеля сам скрипт и мой брокер. Как правило, эти данные совпадают до последней запятой. А вот "Текущие торги" - основная таблица для скрипта - именно от неё он получает данные для принятия решений о покупке или продаже. И чтобы получить доступ к элементам таблицы "Текущие торги", нужно знать код инструмента и код класса, т.е. Вам НЕ НУЖНО "организовывать цикл по всем элементам" - только по тем, которые интересуют лично Вас. А для этого вообще не нужно лезть в таблицу - эти данные меняются раз в сто лет.
Вопрос от новичка, Как вывести в окно остаток баланс счета?
 
Maksimus, Lua - это просто антипод C! Близко ничего похожего! Гениальный язык и бездарная поделка с этой долбаной "динамической типизацией". Один goto чего стоит! В Си это обычный JMP (в отличие от ассемблера, без возможности межпрограммного перехода), а здесь это кастрированное убожество, нафиг никому не нужное. Про сборщик мусора я ваще молчу. И вершина идиотизма: тип integer вообще уничтожен!

Насчёт таблицы: вот здесь это обсуждалось: https://forum.quik.ru/messages/forum10/message55233/topic6454/#message55233
Вопрос от новичка, Как вывести в окно остаток баланс счета?
 
Maksimus, Язык, конечно, полный отстой, но написать рабочую программу можно и на нём. Главное, на мой взгляд, избегать здешних глюков (вплоть до подвешивания Квика), иногда очень глубоко сидящих и редко проявляющихся, а потому пользоваться таблицами Квика и/или прерываниями лучше только в случае крайней необходимости. Я, например, таблицей "Лимиты по денежным средствам" не пользуюсь вообще (как, впрочем, и всеми остальными, кроме Orders, да и та привлекается только в "экзотических" случаях). Вот "создать таблицу и туда эти данные затолкать" - разумное предложение, только не "графическую", а свою Lua-таблицу, держать и обрабатывать данные именно там (в "графической" собственный набор глюков имеется - в частности, уже указанная необходимость соблюдения порядка вызова команд, с непривычки повергающая в шок).
Средства разработки многопоточных скриптов в QUIK., OS_Quesha, свидетельство регистрации в Роспатенте № RU 2020612905. Бесплатная для некоммерческого использования.
 
Артем, Я где-то сказал, что это трудно? Моему алгоритму шорты нафиг не нужны. Фрагмент из его описания: "Мы не играем на медвежьих курсах вообще - так и проще, и надёжнее, и даже честнее".
Средства разработки многопоточных скриптов в QUIK., OS_Quesha, свидетельство регистрации в Роспатенте № RU 2020612905. Бесплатная для некоммерческого использования.
 
BlaZed, Да уж, сколько людей, столько и мнений. А у меня шортов вообще нет. :smile:  
Средства разработки многопоточных скриптов в QUIK., OS_Quesha, свидетельство регистрации в Роспатенте № RU 2020612905. Бесплатная для некоммерческого использования.
 
Артем, А мой робот - реалтаймовый (в моём определении).  :smile: Экономист из меня тоже никакой, но алгоритмист я очень даже неплохой. Я уж и не помню, когда последний раз код правил: месяца полтора, я думаю.

Насколько я понял, BlaZed, говорил про подачу заявки по рыночной цене. Меня это не устраивает - хрен знает, что там с рынком может произойти, так что я предпочитаю совершать сделки именно по той цене, которая указана. Или, по крайней мере, не худшей, так что заявки у меня всегда лимитированные.
Страницы: 1 2 3 4 5 6 7 8 9 10 11 ... 16 След.
Наверх