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

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

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

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

nikolz, Спасибо, родной - советы ОТ ВАС поистине бесценны!

1. Плевать мне на индикаторы - у меня их нет, не было, и не будет.

2. У меня нет выбранных интервалов - я считаю ПО ВСЕМ интервалам сразу. Минимальный интервал у меня 15 секунд, и недельные, скажем, свечи оттуда не получить никак, не говоря уже про "пару-тройку арифметических операций".

3. Многопоточность действительно "реализуется сравнительно просто" - я много раз это делал. А вот "каждый скрипт - это отдельный поток" - это кретинизм. У меня был, есть и будет ОДИН скрипт на все случаи жизни.

4. Я писал и буду писать только на Lua - токо вот питонов здесь не хватало!

spy, Без понятия. Я - не умею. Хотя очень хочется.

TGB, Да как же не жаловаться? Для меня в своё время было просто шоком узнать, что интерпретируемый код способен подвесить Квик! "Как системщик я должен понимать", что этого не может быть потому, что не может быть никогда! И мне противно писать свои "компенсаторы" на системные глюки. Я знаю некоторые места: например, при ручной торговле через скрипт Квик иногда подвисает, потому как я подаю заявку прямо из обработчика событий меню - всё никак руки не доходят перенести это дело в мейн. У меня на OnStop стыдно смотреть - у меня там и лог, и дамп состояния, и закрытие таблиц, и чёрта лысого только нет. А что делать? Я не знаю, и знать не хочу, почему в таблицах иногда пропадает текст - слава богу, научился лечить. Но это всё НЕ МОИ ПРОБЛЕМЫ, блин! Кроме того, есть вещи, которые я в принципе не могу сделать сам - не могу вот достучаться программно до своего портфеля. Техподдержка говорила, что таблица "клиентский портфель" недоступна вообще никак - во радость! Осталась надежда, что смогу прочитать хотя бы "позиции по инструментам", да и то слабая. А свечи? Это же уму непостижимо! Мне нужно порядка 20 тысяч свечей - и что делать? Ладно, "мелочь" я считаю сам, но более тяжёлые (от 15 минут и выше) хочу получать с сервера. И что, прикажете 7-8 тысяч графиков заказывать? На каждую сраную свечу свой график? Да здесь не то что "не обеспечена более-менее надежная среда разработки и исполнения скриптов" - здесь вообще ничего не обеспечено. Но торговать (с ужимками и прыжками) всё-таки можно - и на том спасибо!

TGB, Ну, во-первых, на код я вообще не смотрел - алгоритмист я.   А алгоритмически понятия "синхронизация" или "очередь", "поток", "процесс" именно системные. Во-вторых,  чуть не все Ваши посты идут с упоминанием OS_Quesha, а это, как ни крути, операционная СИСТЕМА.

Я и сам системщик - подавляющее большинство написанного мною кода именно такое. Но здесь я прикладник, и знать не знаю ни о каких потоках, очередях и прочей лабуде. Мне нет никакого дела до "проблем параллелизма в QLua" - мой скрипт считает, что он один такой работает, и про потоки и прочее знать ничего не знает - для него есть только прерывания от таймера, клавы или мыши.

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

TGB, Что такое "предельно допустимый размер" и на кой он нужен? Лично у меня все очереди всегда были "безразмерные". Стек очередей - да, контролировался, и размер его задавался при компиляции - ну так это же стек! Он элементарно может переполниться, например, при неправильном рекурсивном вызове. А очереди-то чего сделается?

Про построение очереди на таблицах тоже ни разу не слышал. У меня были очереди событий, объектов, структур, неоднородных элементов, но таблицы-то здесь каким боком? Таблица по определению имеет два измерения, а очередь - одно. Не этим ли вызвана "«заморозка»?

Ситуации, когда один поток в нее пишет, а другой читает  (в моём случае это были не просто потоки, а отдельные процессоры, причём любой из них мог как читать, так и писать) разрешается (по крайней мере, у нас было именно так) через ОЗУ двойного доступа. При этом каждый процесс[ор] должен соблюдать некий протокол взаимодействия, и в этом случае все проблемы с синхронизацией уйдут в небытие. К тому же, у нас все эти процессоры сидели на общей шине - там требуется примерно то же самое, только намного сложнее организованное.

Ну и, наконец, вся задача организации торговли прикладная с головы до пят, и любые попытки привнести сюда системные штучки-дрючки - тем более, глубоко системные, как в данном случае, ни к чему хорошему не приведут.

BlaZed, Только этого не хватало! Запретил бы нафиг! Какой только херни сюда ещё не воткнули? А потом ещё удивляются, что глючит. Беда, коль пироги начнет печи сапожник, а сапоги тачать пирожник.(с)

ОСТАВЬТЕ ЯЗЫК В ПОКОЕ, ГОСПОДА! Он и без вас полное говно!

Али, О, сколько нам открытий чудных!..   И чо это за хрень?О, Господи! Писать ещё на одном дерьме и подключать написанное через ещё одно дерьмо?! В любом случае, при чём тут код клиента?НУ?! Вот  же он, код клиента! В какой-то ракообразной конструкции.Ха-ха-ха! Огласите весь список, пжалста!(с)Это потому, что ты ДЕБИЛ! У меня вот ОДИН робот запущен, да и тот почти всё время спит!Это песня! У меня вот ПОЛТОРЫ ТЫСЯЧИ тикеров "одновременно крутятся в реальном времени, и при этом я не испытываю НИКАКИХ проблем с производительностью"! Ибо скрипт по-прежнему ОДИН! И написан на голом Lua, без всей этой "шарповой" херни в нагрузку.

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

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

spy, Блин, да хотя бы с профитом! Доступа к таблице "Состояния счета" через Qlua нет и чо делать? А хотя бы к "Позиции по инструментам" - есть? Как мне вообще программно узнать, что брокер думает про содержимое моего портфеля?

Али, Да у Вас недюжинные таланты, как я погляжу!   Как это Вы умудряетесь обойтись без кода клиента? У меня так любая заявка проходит через это:

Али, Убей, не помню - ИИС я почти сразу закрыл. По-моему, счёт тот же самый, а вот код клиента отличается первым символом.

Roman Azarov, Да только я уже и указывал, и ссылку давал по чуть ли не дословно заданному такому же запросу. Надоело!

Nikolay, Кстати, о птичках: никогда никому ничего не навязывал - ни на этом форуме, ни где бы то ни было.

Nikolay, При чём тут люди? Какими бы разными они ни были, хранить данные в таблицах Квика, если под рукой есть таблицы Lua - безумие.

Roman Azarov, Этот вопрос уже ставился, и подробно говорилось, какие нельзя и почему.

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

Роман, Нужно ПОЛНОСТЬЮ перезабивать таблицу. Столбцы я не меняю, а вот набор строк может изменяться каждые 15 секунд или по событиям от юзера. То же самое я делаю при пропадании текста в таблицах.

Andrey Bezrukov, Во как! Функционалом! Нет, я и сам давал предложение, чтобы значения необязательных аргументов подставлялись по умолчанию (в частности, два последних аргумента SetColor), но подменять заданные аргументы на свои, да ещё в транзакции... а чо, деньги клиента - это его проблемы!

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

Полностью согласен со Старателем: это косяк!

Юрий, У меня этот кусок выглядит так:

Юрий, OnOrder не просто функция - это прерывание. Лично я её вообще не использую - пользуюсь только OnTrade. А в тех редких случаях, когда мне нужен order_num (некоторые варианты снятия заявок), то лезу в таблицу orders и вытаскиваю его оттуда через getItem по trans_id.

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

Насчёт "второго" вообще не в курсе - по рыночное не продаю никогда. Впрочем, "если цена упадет до 490 то продать по рыночной" тривально программируется тоже в своём скрипте. Так будет и намного надёжнее.

Роман, Да, я имел в виду порядок, а также взгляд зацепился за
TradePlans={
         ["TRANS_ID"]=1,
         ["NAME"]=2,
         ["OPERATION"]=3,
         ["QUANTITY"]=4,
         ["PRICE"]=5,
         }
TradePlans=AllocTable()
Таблицы Квика и таблицы Lua - разные вещи, причём глючные до невозможности, и обращаться с ними нужно предельно аккуратно. Об остальном сказал Николай - это мне даже в голову не приходило.

А нафига Вам текстовые ключи? Чисто "спортивный интерес". Фрагмент из моей книги:

Предположим, мы имеем РБД, состоящую всего лишь из одного отношения. Заведём дополнительный столбец, значениями которого будут порядковые номера кортежей (с единицы). Именами столбцов также установим их порядковые номера (с нуля). Определим нулевой столбец как первичный ключ (или «суррогатный», или «системно-генерируемый», как «весьма настоятельно» рекомендуют авторы «Третьего Манифеста»). Теперь мы можем получать доступ к столбцам и кортежам по их номеру (как и в SQL), но в строгом соответствии с РМД. Что же изменилось? Мы всего лишь утратили возможность прямого доступа к полям и кортежам (т.к. РМ-предписания запрещают упорядочение атрибутов или кортежей), и автоматически перестали бояться дубликатов кортежей и неопределенных значений. А где же преимущества того, что наше отношение теперь идеально соответствует требованиям «Третьего Манифеста»? Их нет! Вне РМД мы можем точно так же ссылаться на кортежи этого отношения из других (или из него самого), можем вычислять физический адрес кортежа по значению суррогатного ключа (и контролировать его при желании по значению нулевого столбца), т.е. внешний ключ реально становится указателем. Таким образом, концепции, воплощённые в SQL, как минимум, не хуже РМД. Так почему же «безнадёжно следовать извращению РДМ, воплощенному в SQL», как писали Дейт с Дарвеном? С какой стати «чтобы выдержать испытание временем, следует недвусмысленно отвергнуть SQL»? Профессор, снимите очки-велосипед!©

BlaZed, Фраза-то верна - именно поэтому я поступаю так, как сказал. Мне лень ловить и исправлять глюки, которые НЕИЗБЕЖНО возникнут при такой "автоматизации". Что прекрасно доказывает сам факт существования этой ветки. И туевой хучи аналогичных.

BlaZed, Я же сказал, как: "Деньги ваши - развлекайтесь".
О, Господи! Ну, про поиск приключений я тоже написал. Мне не влом утром включить комп, Квик, авторизоваться, запустить скрипт. И никаких обновлений винды!

Роман,
А всё не так!   Посмотрите, например, сюда:
https://forum.quik.ru/messages/forum10/message55233/topic6454/#message55233

Nikolay, Я не понимаю, что такое "быть постоянно привязанным к терминалу". Я купил ноут специально для торговли - все мои задачи 32-разрядные, и работаю я на двух других компах, а на этом, кроме двух Квиков для двух брокеров, ничего и нет. Ну, браузер ещё "на всякий пожарный". Утром я его включаю, запускаю свой скрипт на двух Квиках, вечером выключаю. Ну, иногда, под настроение, могу и сам поторговать, хотя практика показывает, что мне лучше не путаться у скрипта под ногами. И никаких оповещений скрипт мне не шлёт - он САМ торгует.

Он и работает корректно, если "терминал не выключается вовсе". Но смысл?

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

Олег, Да, у меня сестра такая. У неё денег вложено раза в три больше, чем у меня, но тикеров тоже около 30, и она носится с ними, как с писаной торбой, проводит какие-то "фундаментальные анализы" и прочую хрень. А я так, погулять вышел: единственный критерий - частота сделок. Раз народ там ковыряется, значит, и мне можно.  

Олег, У-у-у! У меня только в портфеле более 50 тикеров у каждого брокера, а следит он за... у одного брокера чуть больше сотни, но у другого-то больше тысячи! И таймфреймы начинаются от 15-секундных и дальше по степени двойки. Графиков не напасёшься!  Не, как говорил незабвенный Владимир Ильич: "Мы пойдём другим путём"!  

Олег, О! Коллега! Я когда-то спрашивал здесь: "Есть ли на форуме хоть один, кроме меня, кто программирует на чистом Lua"? Никто не отозвался. Оказывается - есть!

Как это "ничего ужасного"? Ужаснее не придумаешь! Мне нужна пара последних свечей по каждому таймфрейму. Или хотя бы одна, последняя. И таймфреймы-то начинаются аж с 15-минутных. И где взять?

По вопросу ветки: новостями никогда не интересовался, а в этой ветке мне очень понравилось начало:
- Друзья, подскажите пожалуйста можно ли как-то прочитать таблицу новостей QUIK через LUA ?
- Никак.

Nikolay, ЩАЗ! А файл я зачем открываю? Чтобы получить его идентификатор (handle) и в дальнейшем работать с ним по этому идентификатору. А глазами-то мне зачем на неё смотреть? Что я там увижу? Это в таблице моего скрипта, в миллион раз более наглядной, можно что-то увидеть - вот она именно ДЛЯ ВИЗУАЛИЗАЦИИ, для юзера - скрипту она нафиг не нужна. Да и мне она уже не нужна - только захочешь что-нибудь купить или продать, потянешься за мышкой - БАБАХ! А она уже всё сделала.

Какой ещё "доступ к данным параметров корректный"? Вот я буквально вчера писал в другой ветке:

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

2. Я не умею программно прочесть состояние своего портфеля (та табличка, которая зелёненьким цвет текста выводит). Портфель я, ессно, веду у себя, но время от времени случаются сбои и рассогласование содержимого портфеля с точки зрения брокера и самого скрипта. Примерно раз в неделю я это дело проверяю (вручную) и убираю нестыковки. А хотелось бы делать это программно, примерно раз в полчаса. Никто не знает, как это сделать?

nikolz, Что, сегодня в Кащенко день открытых дверей?

Лапуль, ЛЮБОЙ тип данных (в т.ч. и тип float) существует тогда и ТОЛЬКО тогда, если к нему имеются а) общие правила целостности, ограничивающие набор экземпляров этого типа и б) коллекции операций, применимых к таким экземплярам. Не соблаговолите ли привести эти данные для типа float, который "в ассемблере существует всегда и не зависит от наличия сопроцессора"?

И кто Вам сказал, что "float - это способ хранить числа в большем диапазоне значений с экономией памяти, но с допустимой погрешностью"? Да только я только на этом форуме несколько раз тыкал носом таких умников, показывая, что UI64 позволяет хранить все 19-значные числа и даже часть 20-значных, и что на это Ваш сраный float в принципе не способен. А эта грёбаная "динамическая типизация" есть именно БРЕДЯТИНА! Говно, способное испохабить любой язык.

s_mike@rambler.ru,  Лапуль, про ассемблер я не только слышал, но и писал аж на ТРЁХ ассемблерах (БЭСМ, PDP и Intel). И на Васике тоже доводилось писать. Для справки: тип integer в любом ассемблере был, есть и будет ВСЕГДА! Это как раз наоборот, типа float нам когда-то не было - он появился позже, [тогда ещё] отдельным сопроцессором и со своей системой команд. Вот sql действительно не использовал никогда - я чуть не всю свою сознательную жизнь занимался сложными базами данных, и моя давняя фраза на эту тему звучит так: "Базы данных могут быть либо сложными либо реляционными, но не тем и другим одновременно". И тыщу раз говорил, что за "слабую типитзацию" руки-ноги бы повыдёргивал тем умникам, которые выродили эту бредятину.

Nikolay, ЧАВО?! Во-первых, В МОИХ базах данных, как правило, ОДНА таблица (неоднородных кортежей).   Во-вторых, какое отношение имеет открытие таблицы к визуализации? ТТТ - это ХРАНЕНИЕ данных в терминале, а никакая не "визуализация". И доступ к ней как раз "ракообразный", через getParamEx, а не getItem, скажем. Разумного объяснения сему факту лично я найти не могу. Привязка же доступа к графикам - это КРЕТИНИЗМ! АДНАЗНАЧНА!

swerg, Вообще-то, любое высказывание следует аргументировать - даже самые очевидные вещи. Ибо то, что очевидно для Вас, может быть совершенно не очевидно для собеседника. Тем более, что это не личка, а форум. Для меня вот совершенно очевидно, что тип integer обязан быть в языке - это первый язык, который я встретил за долгие годы программирования, в котором его нет! И что? Его нет и не будет - как ни аргументируй.

Для меня вот Ваше высказывание "не должно быть никакой привязки к визуальной таблице" не только не очевидно, но я вообще считаю его бредом сивой кобылы. Равно как и "должен быть чисто программный интерфейс на манер CreateDataSouce c последующим вызовом call-back функции на каждую новость". Худшего интерфейса, чем CreateDataSouce ещё поискать! Тем более, что все "свечные" утилиты лежат в разделе "функции для работы с графиками". ПРИ ЧЁМ ТУТ ВАЩЕ ГРАФИКИ?!

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

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

TGB, Да мне вообще плевать на потоки, блокировки и прочую лабуду! Я считаю, что работает мой, и только мой скрипт, и знать не знаю никаких потоков. То, что в цикле со sleep я рассматриваю как прерывание по таймеру, то, что по OnTrade - по сделкам, а то, что по SetTableNotificationCallback - как прерывания от клавы или мыши. И нет проблем!(с)

По моим оценкам, вы двое и есть самые продвинутые программеры на этом форуме. Хотите выяснить, у кого длиннее?  

nikolz, Лапуль, у меня именно ВСЁ хорошо. Неплохо бы, конечно, иметь тот сервис, про который я написал, но и без него "всё хорошо, всё хорошо".  

spy, Вот и ориентируйтесь на цену последней сделки - это, по крайней мере, реальная сделка (даже если она фиктивная), а в стаканах частенько творится что-то невообразимое. Лично я смотрю только на LAST, и лишь в момент подачи заявки могу скорректировать цену на BID или OFFER - чисто для скорости исполнения (если эта цена отстоит от LAST не более, чем на 0.1%). И рыночную цену, кстати, тоже не использую никогда. Что и другим советую.

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

ЧТО ИМЕННО "можно сделать самому"? Всё, что можно - я сделал: и свечи считаю сам, и портфель веду сам. Но тяжёлые свечи я хотел бы получать именно от сервера, и состояние моего портфеля именно от брокера. Что здесь "можно сделать самому"?

Системный-то я системный, но здесь же полностью прикладная задача.  

Что вы фигнёй маетесь, господа? Я вот тоже "разработал свою систему создания торговых роботов в QUIK", хотя появился здесь (и написал свою первую строчку на Lua) в сентябре прошлого года. Скрипт свой я уже и не помню, когда правил в последний раз. В ём сейчас 16 функций, включая main и прочие OnStop, объём кода менее 20 кило, и на все "версии компилятора, ключи компиляции и режимы линковки" мне давно пилювать с высокой колокольни. Кажется, при запуске скрипта Квик чо-то там компилирует - ну и пусть себе компилирует, а я скармливаю ему чистейший Lua как интерпретатору. Всё прекрасно работает! Сейчас я пишу совсем уж сумасшедший скрипт, уже не с трёхмерными, а с четырёхмерными массивами, с разветвлённым диалогом, и я уже совершенно точно знаю, что и он будет прекрасно работать - я просто не вижу, откуда могут появиться проблемы. Вернее, я пока пишу описание, то бишь набросок ТЗ, и пишу уже не первую неделю - задача АЛГОРИТМИЧЕСКИ сложная, а вот ТЕХНИЧЕСКИЕ вопросы решены уже сейчас. Ну, может, вылезет количество функций и/или объём кода за тридцатник - и чего? А может даже и не вылезет. Нафига вам это надо - не понимаю...

Нет, соврал - парочка нерешённых технических проблем ещё осталась:

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

2. Я не умею программно прочесть состояние своего портфеля (та табличка, которая зелёненьким цвет текста выводит). Портфель я, ессно, веду у себя, но время от времени случаются сбои и рассогласование содержимого портфеля с точки зрения брокера и самого скрипта. Примерно раз в неделю я это дело проверяю (вручную) и убираю нестыковки. А хотелось бы делать это программно, примерно раз в полчаса. Никто не знает, как это сделать?

Roman Azarov, А вот КТО, простите, решает, что является ошибкой, а что нет? Вам уже ГОДАМИ на все лады твердят, что это именно ошибка - и что толку? Я бы даже сказал, НЕПРИЛИЧНАЯ ошибка. Эту ветку цитировать не буду, а фрагменты своих разговоров приведу "в дополнение":

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. Ваше пожелание зарегистрировано. Мы постараемся рассмотреть его и сообщить Вам результаты анализа.

Ну и?

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

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

Andrey Bezrukov, Хорошо, всё считаю согласованным, кроме пункта 3. Юзеру-то какое дело, что там "есть также и служебные, технические параметры недоступные для обработки"? Ладно, у меня за плечами 40 лет программирования, причём, в основном, системщиком - я уже давно научился "доставать левой ногой правое ухо" и проблему с многократными вызовами на одно событие фактически решил. А новичкам что делать, которые в подавляющем большинстве либо получайники либо полные? Конечно, регистрируем!

Anton, Я тоже боюсь любых модификаций, но я по натуре перфекционист: НУЖНО хотя бы пытаться!    

Andrey Bezrukov, Отвечаю тоже по пунктам:

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

3. Да, подразумеваются  именно вызов callback-функций (одна из причин, почему я стал пользоваться только OnTrade, как минимально необходимой для торговли). Они тоже приходят пачками по три штуки, совершенно одинаковых. Приходится запоминать её ID и отбрасывать дубли. Если учесть, что заявки могут быть в несколько лотов, а также "левые" (сделанные юзером в обход скрипта), приходится изворачиваться глистом на сковородке. У меня это сейчас выглядит так:Мало того, они приходят вразнобой! Вот я матерился по этому поводу 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. Нет, я ни на чём не настаиваю - это проявлялось давно, и я почти сразу стал в случае необходимости изменения набора строк перебивать заново всю таблицу - глюки тут же пропали.6. Ясно, Неприятность эту мы переживём!(с)

7. Насколько я помню, Старатель подробнейшим образом разбирал это дело. А я даже не разбирался - просто повесил в обработчике:
if (n==QTABLE_CHAR and l==13) then DestroyTable(T);D();J();end;
После чего пропавший текст восстанавливается. В общем, помогло. И, поскольку я скрипт пишу для себя, разбираться с подобными вещами не буду - других дел выше крыши.

Andrey Bezrukov, УХ ТЫ! Даже не читая - я охренел. Меняю своё мнение о сотрудниках техподдержки на прямо противоположное, приношу свои извинения за домыслы нехорошие о вас. Почитаем...

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

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... далее нецензурно.

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 минут - это просто мне заняться больше нечем?Так что НЕ ХОЧЕТСЯ давать вам "ясно сформулированные предложения, тем более с озвученной аргументацией", даже если они "всячески приветствуются" (перед тем, как бросить в корзину).

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)? По умолчанию одна последняя свеча. Возможно, даже с коллбеком. Такое вот у меня пожелание к разработчикам...

Артем, Лапуль, я уже говорил, что включён в соавторы одной из операционок - не надо тут мне лапшу с умным видом вешать. Прерывание - это когда обработчик САМОЙ ЗАДАЧИ получает управление, всё остальное - это НЕ прерывание. Операционка может вернуть управление через час, через год - и программа ровным счётом ничего не заметит. Разве что окружение изменилось, вроде значения системных часов.