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

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

Да, об этом не подумал. Тогда остается что, а остается ничего, сам факт приезда (первого) пакета на клиент только. Даже и функции много, флажок в датасорце, "ответ сервера получен". В сухом остатке что тогда от арки требуется: 1) убедиться, что сервер всегда что-нибудь отвечает на подписку, есть ли данные или нет; 2) на клиенте по получении первого ответа поставить флажок в датасорце.

Вытащите из Program Files в корень диска или еще куда, где на запись доступно.

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

Скорее всего да, но в данном случае не должен был делать ничего, кроме возврата ошибки, поскольку уже инициирован дисконнект. Тут опять дело в синхронизации, видимо. Квик мог бы все запросы от скриптов и нижнего уровня пропускать через SendMessage главному потоку, так что при обработке любого сообщения состояние было бы всегда консистентным без всякой дополнительной синхронизации. Но это было бы узкое место во всей системе. Судя по всему, часть операций скрипт выполняет, непосредственно дергая апи нижнего уровня, мимо главного окна (и его потока), равно как и нижний уровень сначала меняет состояние, а потом уведомляет главный поток сообщением. И в результате получается рассинхрон, как в этом примере, главное окно считает, что оно инициировало дисконнект, а скрипт и нижний уровень еще вовсю транзакции пуляют.

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

Тут как раз логично выглядит. Для клиента отправленная транзакция закончилась дисконнектом, а в новом подключении клиент обнаружил неизвестно откуда взявшийся ордер, может его руками поставили с другого клиента. Скорей вопрос, почему квик после команды дисконнекта позволяет еще что-то отправить. Очевидно, дело в том, что мейн успевает пропихнуть транзакцию, пока основной поток в неопределенном состоянии. На досуге поковыряю тему, может что не так понял чисто по коду. Я про другое говорил, когда на некоторые транзакции вообще колбека нет (без потери соединения).

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

Так-то мы и без специального уведомления знаем, что данные может когда-нибудь появятся, ну может через неделю, а может и нет. У меня созрела схема получше, давайте попробуем на нее посмотреть. В датасорец добавляем функцию ds:ExpectedSize. Сразу после подписки там nil. Когда сервер что-то посылает по подписке, он также добавляет поле с количеством свечей у него в данный момент. То есть в каждом пакете отправляемом. Как только первый пакет с сервера приехал, это поле становится доступным через ds:ExpectedSize(), далее с каждым пакетом это поле обновляется. Старая ds:Size() продолжает работать как работала, это количество свечей в хранилище у клиента. Что мы получаем в итоге. После подписки, пока ds:ExpectedSize() возвращает nil, мы знаем, что подписка отправлена, но ничего еще не приехало. Потом что-то приехало, пусть одна свечка, ds:Size() дает 1, но ds:ExpectedSize() дает больше, ок, мы знаем, что надо еще подождать. Либо на сервере нет свечей, тогда ds:ExpectedSize() возвращает 0 и мы знаем, что ждать в данный момент больше нечего. Либо мы получили все что есть и ds:ExpectedSize() == ds:Size(), дальше, если хотим реалтайму, никто не запрещает поллить периодически или настроить колбек. В чем-то перекликается с предложениями от Nikolay выше. Правда, не очень представляю, как это будет с тиками работать, они ж по каналу ТВС едут, там свои погремушки.

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

можно бы предложить возвращать из ds:Size nil вместо нуля, пока с сервера что-нибудь не приехало (хоть бы и ноль). Но сколько народу на это наступит и сколько будет воплей.

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

По-моему знание "там ничо нет" не дает ровным счетом ничего, оно изоморфно знанию "там ничо нового нет" = "там миллион свечек, но мы их все уже обработали", все равно единственное, что можно сделать дальше, - это вертеться в цикле до второго пришествия (до дисконнекта на самом деле). Ну и надо вертеться значит, раз такой подход выбран, ноль там - ну ок, ноль, continue; одна там свечка - ну ок, одна, сунули ее куда хотели, continue; тысяча их - ну сунули тысячу, continue. Пусть есть функция "чо там у сервера", получили "нет ничо", пошли по своим делам, вернулись, ага, теперь "есть чо", обработали, пошли по своим делам, вернулись... чем отличается от первого варианта? То же самое будет, кстати, если читать файл, в который пишет другой процесс, и это безо всяких квиков и серверов.

Видимо да.

Еще б написали, в какой именно восьмой. Луа 53 начиная с 8.5, в более ранних луа 51, видимо в более ранней запускаете.

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

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

Такие вещи надо арке на мыло посылать, а то вот идет прохожий вроде мну, раз и скачивает ваш дамп и глядит, что там у вас... а у вас там квик стоит в C:\Program Files (x86)\Info\info.exe. Собсна вот и ответ. Стоял, видать, 32-битный, обновили сразу на 8.6 и опаньки. Не будет 64-битный в Program Files работать.

Спасибо. Главно дело чтобы мейн опять не сломался при этом )

Да, я об этом )

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

Да, конечно. Проверил еще раз на 8.6.0.97 только что, все как было, запускаем - получаем просто ошибку, запускаем повторно - получаем сначала все финализаторы, потом ошибку.

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

Пусть есть сколько-то потоков в системе. Для ядра они все одинаковые, оно не смотрит, это поток из квика или из браузера или еще откуда-то. Часть потоков спит или ждет какого-то события (спит это на самом деле тоже ждет события - таймера), они за процессор в данный момент не соревнуются. Другая часть готова к исполнению, и их (всегда) куда больше, чем ядер. У каждого потока есть некий приоритет, назначаемый при его старте. В ядре винды 32 очереди готовых потоков, по одной на каждый приоритет (которых тоже 32 всего). Каждые 16 мс происходит прерывание таймера, через каждые 2 прерывания очередной поток с ядра снимается и выбирается следующий поток на выполнение. Это будет первый поток из очереди с наивысшим приоритетом. Если высокоприоритетные очереди пусты, проверяются очереди с более низким приоритетом и т.д. С самым низким приоритетом выполняется поток idle, если дело до него дошло, он всякую там приборку фоновую выполняет и, если по-прежнему делать нечего, вырубает ядро, на котором работает. Потом оно запускается следующим прерыванием таймера, опять проверяются очереди, выполняются самые приоритетные потоки, потом потоки похуже, потом готовые потоки кончились, выполнился idle и ядро опять в спячку ушло. Кстати говоря, та "загрузка процессора", что вы видите в диспетчере задач, это по сути сколько процентов времени ядро работало (остальное время оно было выключено).

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

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

В свете сказанного, как может быть, что поток будет ожидать дольше, чем требуется? Придет его очередь - попадет на ядро, сделает сколько успеет и встанет ждать следующего раза. Чем больше потоков, тем длиннее очередь, тем реже поток будет на ядро попадать, с какого-то момента это станет и визуально заметно в виде подлагивания (но не раньше, чем все ядра загрузятся на 100% и заревет вентилятор). Как писал выше, при 1000 потоков на процесс вы этого еще не очень-то заметите, если код написан нормально.

Вы диспетчер задач откройте и посчитайте, сколько там потоков выполняется по всей системе. Сразу увидите, что не совсем логично такие выводы делать. Гуглите вытесняющая многозадачность. Если хотите циферок, то в лохматые годы на хрюше с селероном 1000 потоков в процессе жили припеваючи, с тех пор хуже точно не стало. А так-то можно и один поток так написать, что вся винда колом встанет.

Походу это GDI объекты, там жесткий лимит около 16к штук на всю систему. Интересно, где текут, в квике или в какой-то другой программе.

Интересно, откуда вы эту информацию взяли. Это последний фолбек, если ничто другое не помогло:
Т.е. как раз случай, что база будет установлена равной курсу ЦБ, крайне маловероятен, это надо чтобы ни на мамбе не торговалось, ни рейтерс данных не дал.

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

Поправлюсь по поводу Si. Биржа таки транслирует уже рассчитанное значение под названием USDFIX в классе RTSIDX (класс может отличаться).

Конкретно для RI читаем
Соответственно код инструмента RTSI, класс может у брокеров разниться (раньше по крайней мере встречал разные), у меня сейчас это INDX. Опять же он нигде не торгуется как таковой, это расчетное значение, как именно рассчитывается смотреть на бирже. С акциями да, проще, но все равно поглядеть в спецификацию крайне желательно, прежде чем. А то может выйти как с теми любителями wti с планки подбирать.

Эмм, это я накосячил на автомате, код конечно USD000UTS_TOM, он же USDRUB_TOM. Тем не менее лучше нагуглить и почитать упомянутый документ, поскольку этот инструмент и база фьючерса это вещи различные.

Надо в спецификацию контракта смотреть.

Конкретно по примеру с SiM0. Базовый актив в данном случае действительно Si, ткнуть пальцем во что-то торгуемое и сказать "вот он базовый актив" не представляется возможным. По факту это индикативная котировка, рассчитываемая согласно документу "методика расчета индикативных валютных курсов", этот документ меняется периодически. Там в торговое время берется RU000UTSTOM, в неторговое курс с reuters, убираются выбросы, тики сглаживаются мувингом, в моменты переключения с одного источника на другой тоже сглаживается гэп, короче это синтетика чистой воды.

Да, такое было от 8.2 (если не ошибаюсь) и до 8.5 включительно, в 8.6 поправили и из мейна выходит с очисткой. Колбеки надо заворачивать в pcall и при ошибке прибиваться самостоятельно, квик даже теоретически не имеет возможности прибить мейн кроме как через TerminateThread, а это еще хуже, чем игнорировать ошибки в колбеках. Чтобы это дело четко отработать на всех этапах, надо:
1) создать глобальную табличку с метаметодом __gc.
2) ошибку в OnInit ловим pcall'ом и откладываем до мейна (сохраняем хоть в ту же глобальную табличку).
3) все колбеки заворачиваем в pcall, ошибку из любого колбека редиректим в мейн и либо ставим глобальный флаг "игнорировать колбеки", либо заменяем их все на заглушки.
4) в мейне первым делом проверяем, не было ли ошибки в OnInit (сохранена в п.2), если была - бросаем ее же снова уже из мейна.
5) далее у меня почти всегда цикл сообщений, иногда ожидание на объектах, так что как редиректить ошибку из колбека проблемы нет; по получении ошибки опять же просто кидаем ее снова уже из мейна.
6) ну и зачистка в __gc из п.1 всегда одна и та же, хоть там ошибка, хоть там нормальное завершение.

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

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

В справке qlua.chm, в разделе индикаторы, внизу там где-то.

Не вызывать ее. См. список поддерживаемых индикаторами функций.

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

Можно поинтересоваться, почему вы поставили тейк-профит, а не лимитную продажу на 88.6?

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

будет, видимо, прочтение правил торговли на ммвб. Особенно в части поиска там таких сущностей, как стоп и тейк-профит.

Такое же ощущение, ядро решили закопать. Думается, связано это с распространением AArch64. Если 32-битные армы были, скажем так, хороши местами, в контроллерах им самое место, то 64-битный вариант уже вполне себе конкурент интелу, при этом без кучи интеловских исторических болячек. Из телефончиков они полезли уже повсюду и надо на них ориентироваться в будущем. А ядро виндовое все же во многом ориентировано на интел, или, лучше сказать, на интелоподобную архитектуру, с фиксированными страницами и вот этим всем. То есть в своем виде оно не жилец в перспективе (вместе с интелом). Поскольку винду уже на арм портировали, они там увидели в процессе все неудобства и, видимо, решили, что проще с нуля переделать. Как будут переделывать тут уже вопрос, по нынешним временам взять окаменевшую кучку динозавра, завернуть в цветную обертку и продать как новую технологию - вполне себе в тренде, могут и так.

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

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

Поставил, кстати, шляпу с вейландом, поиграл малость, заодно и вейланд сам пощупал. Линус вспомнился, "я не щитаю, что ядро должно пересылать сообщения" (он это, конечно, не Биллу говорил, а Таненбауму), ну ок, будет надстройка над ядром пересылать, иначе никак.

Жаль. У меня тоже есть дллки без прилинкованного луа и даже без сишного рантайма. Я их всех тут перепробовал по тридцать раз в 8.6 после вашего сообщения и ничего такого не обнаружил. Поэтому хотелось понять, как вы такого эффекта добились.

https://www.lua.org/manual/5.3/manual.html#lua_tolstring

If the value is a number, then lua_tolstring also changes the actual value in the stack to a string. (This change confuses lua_next when lua_tolstring is applied to keys during a table traversal.)

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

Обычно после квеста "чистка реестра" начинается квест "переустановка винды", так что я б не советовал.

Это сколько адресного пространства резервируется, тут экономить незачем, пусть будет максимум. Там у вас еще есть GTT size - это сколько на таблицы страниц резервируется, по прикидке в уме должно хватать, на гиг апертуры где-то 2 мега таблиц будет. Реально выделяемой памятью заведуют DVMT Total Gfx Mem - это сколько встроенной карте максимально выдается (при динамическом выделении), и DVMT Pre-Allocated - это сколько ей выделяется фиксированно прямо со старта. Вот этих двух я б поувеличивал. Интел сейчас не рекомендует, мол десятка сама умеет это настроить, но семерка-то не умеет. В любом случае попробовать можно.

Он ловит этот акцесс виолейшен, останавливает скрипт и показывает эту ошибку, так что в этом смысле все ок. А вот что этот акцесс виолейшен там есть (а он есть, проверил), это косячок-с. Случается на доступе к ds:T(i) непосредственно после подключения. Очевидно, после подключения датасорец очищается и начинает заполняться заново, в итоге скрипт лезет дальше его конца, поскольку уже сохранил размер до подключения.

Ну еще SetEmptyCallback надо дернуть. Ежли будет таки падать, арке карты в руки.

Как вы это сделали? Если заинклюдить lua.h и потом вызвать хоть одну функцию из него, не линкуясь с lua53.lib, линкер скажет unresolved external. Значит, вы объявляете указатели на луа-функции и потом их инициализируете ручками через GetProcAddress, верно? И откуда берете хэндл lua53.dll? Через GetModuleHandle("lua53.dll"), так? И на этом этапе получаете периодически NULL, так? Или иначе как-то?

Наглядное пособие "как прострелить себе ногу". Вы в цикле каждые 10мс создаете новый датасорец и потом внутри в еще одном цикле весь его просматриваете. Удивительно не то, что в 8.5.2 и далее крэшится, удивительно, что раньше не крэшилось.

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

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