попроще можно сказать что и main и OnStop исполняются (вызываются) под единым мьютексом. который снимается всего двумя способами а) выходом из функции б) обращением к С-function и sleep - это вариант б)
при б) мьютекс снимается на входе в С-функцию и возвращается при возвращении из неё. при этом если С-функция в свою очередь обратится в Lua, то мьютекс тоже будет выставлен на время такого обращения и снимется при возврате в С функцию отличие между Lua и С-функцией определяется через lua_iscfunction
в Quik Lua почти всё C-функции. поэтому sleep(0) можно заменить, например, tostring, да и pcall тоже С-функция, так что наверно в main сработало бы pcall(run) без флагов
Уф, после долгого отдыха доделал таки тест кейс, который доказывает что действительно в Quik есть мьютекс на lua_lock/lua_unlock. Моя ошибка в прошлый раз было предположение что sleep в Quik Lua - это функция на lua. Вот и нет, это cfunction. Поэтому вызов её с любым большим значением из нескольких потоков к блокировке не приводит. Если я поменял тест: сделал два потока в C++, которые обращались в CustomSleep на Quik Lua, одновременно. А в CustomSleep я просто сделал очень большой цикл. В итоге поток Б ждал возврата потока А из lua CustomSleep. Блокировка налицо, хотя в моем C и моем Lua её нет.
Итак схема работы как я её сейчас вижу, ещё раз: Quik Lua обычный работает в однопоточном режиме (+ колбэки), под единой блокировкой. При обращении из lua в C функцию (любая ваша собственная библиотека dll), блокировка снимается, при возвращении оттуда - снова возвращается блокировка. Если же из C функции идет вызов другой функции по pcall например, то при обращении в Lua блокировка тоже навешивается, а при возврате - снимается. всё просходит попарно. Так же блокировки вешаются при обращении к любым функциям которые меняют стек, типа lua_pop. Но не к tonumber (о чем тут начался пост), потому что он стек не меняет.
Почему это было важно мне? Хотел понимать, где могут блокироваться потоки из C, которые конкуретно, но под моей собственной критической секцией обращаются в Lua. Возможно, в моем случае эта самая дополнительная критическая секция не очень-то и нужна, или надо очень аккуратно выстраивать работу, чтобы не пересекать блокировки в Quik Lua и мои собственные.
TGB, ну у меня не было запроса к вам на изменение или оценку логики моей программы (вроде бы?). соответственно к чему бы мне реагировать на предложение что-то менять? да, к lua_State я обращаюсь из разных потоков, используя синхронизацию, всё верно. не вижу проблем сделать и очередь, решение не плохое. ирония в том, что я с очередями работаю порядка 20 лет, этот шаблон мне мягко говоря знаком.
большой вопрос, насколько велика моя степень "вмешательства в логику quik/lua", и что и как может портиться здесь, возможно я недооценил этот момент. и да, технология у меня используется пока не в полную силу, по факту там лишь 1 дополнительный к main поток чаще всего, я планировал сделать 2-3-4, на каждый счёт отдельно, то есть они и сейчас могут запускаться в ответ на приход нового "клиента"-робота, но у правительства оказались другие планы и торговля на америке и нашей фонде стала в феврале на долгое время неактуальной. некоторое время я гонял два дополнительных потока, один из которых был просто для получения отдельной информации, но потом для надёжности реальных денежных торгов оставил только 1. информация из второго мне пока не нужна, тк фонда хоть и торгуется, но это пока не интересно. возможно если бы я стал расширять потоки, я бы сталкивался с ошибками и стал бы их решать, а так - работает и не падает, хоть main и клиент крутятся в двух разных потоках.
swerg, да, линкуюсь с квиком, конечно. речь о lua_lock/lua_unlock, это просто макросы в заголовочных файлах, которые доступны нам только из чистого, не квикового lua и в dll наружу не торчат.
TGB, мне тоже понравилось как и что он писал, ретроспективно. в то время я, видимо, редко посещал форум, не заинтересовался особо этим разговором или не понял. вот я ещё полазил по исходникам, если интересно. нашел, что если из c-функции вызывать что-то через p_call, блокировка сначала вешается, как я и говорил выше, но потом всё снова приходит в метод luaD_precall, где она снова снимается. так уж реализовано странненько. другими словами, из lua_pcallK путь всё равно ведёт к luaD_precall. и из c-функции похоже нереально увидеть блокировку. можно ещё как-то попробовать поискать-поотделять C-функции QLua от Lua функций в qlua.dll. потому что для lua функций блокировка сниматься не будет в luaD_precall. не знаю правда сколько в этом пользы, но любопытно. скорее всего там всё сделано через C-функции, я бы делал так.
TGB, как-нибудь потихоньку разберусь. понял о чём вы начинали говорить с Anton еще тут https://forum.quik.ru/messages/forum10/message49035/topic5852/#message49035 вся Lua работает под одной критической секцией, которая разблокируется на время вызова C function. мой тест был задуман не верно, - мои вызовы идут в обратную сторону, через C function в Lua. я так сделал, потому что у меня и робот так работает.
то есть мне надо смотреть не на luaD_precall, а на lua_pcallk. и что характерно, в ней таки есть lua_lock на входе, а на выходе - lua_unlock. то есть c function, которая идёт по pcall (вообще не важно в lua или тоже в с функцию), на время вызова должна бы блокироваться со слов Антона, там под lock сделан mutex (я ничего такого не проверял). а у меня как раз два O.S. thread конкурентно вызывают lua sleep на 10 секунд. и конкурентно возвращаются из него. опять непонятно..
Владимир написал: Господа, объясните мне, дураку, на кой вам всё это надо? Торговля на бирже - процесс медленный, вдумчивый, процессы длятся месяцами, даже годами, и потому задержка на минуту, час, день, неделю существенно на результат не влияет. Вы что, делаете сотни и тысячи сделок в час? Но ведь даже в этом случае времени просто ВАГОН! Одно ядро, два, десять, тысяча, C или Lua - ну какая разница?! Не понимаю...
в посте где было объяснение, зачем собственно нужен sleep
Цитата
Владимир написал: Поставил туда sleep(1) и - О, ЧУДО! ... ЧО ВАЩЕ ЗДЕСЬ ТВАРИЦЦА?!
но прошло ещё пару дней, и снова на ту же тему
Цитата
Владимир написал: Нафига вам всё это нужно, господа? Я потратил недели две, чтобы вынести всё, что можно, в поток main и уже практически забыл про вылеты скрипта или отвисания Квика. Не говоря уже о том, что я буквально с первого же дня постулировал: никаких библиотек, никаких других языков - скрипт должен работать на любой версии Квика и любой версии языка. И никаких стаканов, никаких свечей, никаких графиков, никаких сокетов. А все вопросы синхронизации/блокировки выполняются самим скриптом, у которого для этого заведены соответствующие стеки и флаги. Ведь наша задача - получить рабочую версию торговой программы, а не вести бесконечную борьбу с глюками всех мастей и размеров.
то есть понимание за два года и явное столкновение с проблемой так и не пришло.
Павел Bosco написал: вопрос, как увидеть существование блокировки при вызове quik lua api для меня остался открытым.
У меня встречный вопрос: Если вам нужно просто реализовать своего робота, а не выполнять научно-исследовательскую работу :: , то зачем вам нужны потоки и прочая "лабуда"? Пишите своего робота на QLua, как советует Владимир, стараясь обходиться даже без внешних библиотек. Это хороший совет для всех и, особенно, для начинающих.
а вы всё-таки любите опираться на свои гипотезы и делать по ним выводы, интересный вы тип в этом плане :) нет, интерес не праздный. робот реализован, но в нём есть и проблема, которую я не понимал, связанная "возможно" (да) с блокировками природа которых мне была не ясна.
я предполагаю, что мой тест провалился, потому что обрамление в lock/unlock происходит только для вызовов из lua байткода. а я вызывал sleep через pcall в своей c функции. в этом случае обрамления не происходит. тогда я попробовал даже дополнительный способ: вставил вызов функции sleep внутрь новой lua функции m_sleep, чтобы получить задействовать VM, но и тут ожидаемого "обрамления" не произошло. возможно там где-то есть и хитрые проверки, чтобы не получалось так, что мы из C функции вызываем из неё другую C функцию, та вызывает lua функцию и мы получаем блокировку.
TGB написал: Реальным фактом является то, что ошибка синхронизации в QLua существовавшая, по крайней мере, с мая 2020г., была исправлена через три дня после того как я выложил код, который, по моему мнению (опять расплывчато :: ), мог ее исправить. Реальным фактом является, что после исправления этой ошибки разработчиком QUIK был изменен номер версии.
я собрал тест, который в двух потоках вызывает quik lua функцию sleep на 10 секунд, два потока работают с одним и тем же lua_State, и в этом конкретном случае, потоки отрабатывают параллельно. одновременно вызывают sleep, одновременно возвращаются из неё. нет никакой синхронизации/блокировки.
дальше я понял, что сделать тест с lua_lock невозможно, тк lua_lock - просто макрос, и из своей библиотеки "родной" quik lua lua_lock я вызвать никак не смогу. и другие разработчики - тоже.
вопрос, как увидеть существование блокировки при вызове quik lua api для меня остался открытым.
1) опытные программисты изолируют проблему и предоставляют тесткейс 2) это ваш код "исправления проблемы", я говорил о коде "демонстрирующем проблему" 3) я прочёл ветку, там не было сообщений от поддержки, что ваши пожелания внедрены и версия сменилась, только ваша догадка об этом. есть реальный факт что ваши пожелания заставили разработчиков что-то сделать и сменить версию?
возможно всё-таки я не о том пишу, для этого хотелось бы понять, c-closure и c функция это одно и тоже или нет. или другими словами, что имеется в виду под с функцией.
написал себе заметочку, повторю тут, как можно проверить блокировку (а она сейчас с нами, в этой комнате?) 1) первый тест, который в мейн будет порождать два потока, писать "я в потоке а", делать lua_lock, windows Sleep на 10 секунд, "я вышел из паузы в потоке а", lua_unlock и тоже самое в потоке б. 2) второй тест - сделать тоже самое, но без lua_lock сделать qlua sleep, декларируется что там используется блокировка? 3) если я правильно понимаю, то блокировка будет в обоих случаях, то есть два потока отработают последовательно, а не параллельно
если моё понимание в 3) верно, то все Sleep и WaitForSingleObject для main надо обрамлять lua_unlock перед и lua_lock после.
почитал пару листов, у вас там очень обобщающие рассуждения "похоже, что" "скорее всего", основанные на ваших собственных наблюдениях и тестах.
Тем не менее спрошу, нашлось ли подтверждение (из кода или от поддержки), что lua_lock/unlock реально что-то делает в QLua? Если да, то получается что если у меня есть в c closure "main" обычный windows Sleep, мне его лучше обрамить qlua_unlock / qlua_lock? А соответственно вместо моей собственной CriticalSection лучше использовать встроенный qlua_lock/qlua_unlock? Поясню - у меня в main крутится диспетчер входящих клиентских соединений, создающий дополнительные потоки для каждого клиента. Все клиенты работают через единый lua_State, обрамлённый CriticalSection. Всё работает, не падает, но в целях стабильности и скорости, мне приходится держать Quik свёрнутым. Потому что время сервера начинает дико отставать при отрисовке графики. И я подозреваю (да, обобщение, увы) что дело в каких-то блокировках, которые, возможно создаёт мой скрипт, делая что-тоо не так. У меня нет доказательств что что-то не так делает quik, а просто рассуждать обобщающе на эту тему неохота. Самый быстрый способ что-то исправить - это дать разработчику короткий, но 100% действенный тесткейс повторения ошибки.
TGB написал: Но все участки кода Lua (за исключением кодов C-функций Lua) используются в режиме разделения, то есть под синхронизацией, при которой только один может исполнять такой код. Таким образом в QLua параллелизм может возникать (если так сложится) только на кодах C-функций Lua (хоть в main, хоть в колбеках).
вы как-то анализировали устройство Qlua? Или это догадки? Тема мне интересна, есть ли какие-то ссылки почитать? В моем решении есть небольшие болячки. У меня колбэки и main - это c closure, вызовы lua через pcall, при этом я синхронизирую все обращения к main lua_State (к ней обращение во много потоков) через критическую секцию Болячки выражаются в замедлении квика (отставании времени от сервера), если открыт GUI, а если он минимизирован - всё шустро очень - но так его держать неудобно. Тоже думал что есть какие-то проблемы с блокировками, но на видимом мне слое "реальности" ничего не нашел.
TGB написал: ... 1. При открытии библиотеки base_funcs (Lua 5.4.1), в которой находится tonumber, все ее функции помечаются как С-функции. Это означает, что в программе Lua они выполняются в скобках: lua_unlock(L); Запуск C-функции; lua_lock(L); Такие функции могут выполняться параллельно с исполнением QLua-кода. Однако любые операции с использованием в них L, должны выполняться в синхронизирующих скобках: lua_lock(L); Выполнение операций в L; lua_unlock(L); При просмотре исходника функции tonumber (с учетом вызываемых в ней функций), я обнаружил, что в этой функции есть как минимум один фрагмент с использованием операций в L без синхронизирующих скобок (мои комментарии помечены в исходнике символами #####):
Код
// # # # # lua_stringtonumber вызывается в tonumber (luaB_tonumber)
LUA_API size_t lua_stringtonumber (lua_State * L, const char * s) {
size_t sz = luaO_str2num(s, s2v(L - > top)); // # # # # # ? используется L без синхрони - зирующих скобок
if (sz ! = 0 )
api_incr_top(L); // # # # # # ? используется L без синхронизирующих скобок
return sz;
}
Возможно, что-то я упустил, но пусть это проверит разработчик QUIK. ...
я немного влезу от скуки, без полного понимания обсуждения, извините, но о каких исходниках идёт речь? в 5.4.2 Lua есть такой код
то есть эти "скобки" ничего не делают на самом деле.
и еще вы пишете что колбеки в текущей реализации не исполняются параллельно main. это действительно как-то так? main где-то приостанавливается? каким образом?
swerg написал: Проблема не в библиотеках, а в том, судя по сообщению ликёра, что проект 32 битный собираетеМенять в свойствах проектаИ не понятно как именно вы былдитк, вы это упорно не пишете
Ну как же не пишу. В пятом сообщении даже жирным выделил. А в первом сообщении, второе предложение: написал что мучаюсь с luarocks. Тема про то, как настроить luarocks. Он так на любые пакеты реагирует. Я понимаю, что luarocks пытается собрать под х32, но как ему сказать иначе - я не знаю.
разные версии компиляторов есть, всё зависит от того из какого окружения он запускается, для 64bit заголовок окна будет а-ля x64 Native Tools в MSVC это называется "Платформа" д.б. x64 вопрос имеет мало отношения к quik
возможно такая проблема только у меня, если нет, прошу присоединяться с вашими отзывами к теме, но у меня Quik грузит GPU (старенькая GeForce GT 730) на 60-70%, в результате чего, судя по всему начинает отставать получение данных, за минуту набегает отставание данных в несколько секунд.
не уверен насколько это было на прошлых версиях, кажется это появилось где-то в районе 9.6, но я не уверен. Может ли разработчик посоветовать что-то настроить в операционной системе (Windows 10), либо в самом квике для ускорения процесса?
Так же я подключаюсь к этому компьютеру по Remote Desktop, возможно это тоже даёт дополнительную нагрузку на видео-карту. Кроме того, я использую тёмную тему. И у меня есть самописные индикаторы на Lua, но они сами не рисуют, тут GPU видно не при чём.
Иначе приходится разрываться: для стабильной и быстрой работы робота, приходится держать квик свёрнутым - тогда он мгновенно перестаёт нагружать GPU, но хочется видеть графики, сделки и изменение баланса здесь и сейчас.
CPU нагружен слабо, пропускной способности сети тоже более чем достаточно (500 mb/s), блокировок в скрипте _вроде_ бы нет, да если бы и были, они бы не давали высокую нагрузку GPU. Так же я обновил недавно windows, может и в этом дело, сборка 19044.1766
Nikolay написал: Если данные транслируются в ТТТ, то и getParamEx вернет их. Укажите корректный код класса и код инструмента. Можете увидеть их в информационном окне: правая клавиша в строке ТТТ - информация об инструменте.
вопрос снимается. код инструмента нужно указывать "US88160R1014" Николай, спасибо за совет
Пытаюсь попробовать получить что-то в Открытии-брокер с ИТП, но в ответ одни нули, хотя в таблице текущих торгов цифра предыдущего закрытия есть. Я делаю что-то не так?
Код
function main()
message("getParamEx: " .. getParamEx("NA_ALL_50_C", "TSLA", "PREVPRICE").param_value, 1)
end
я хотел понять, что будет быстрее - поллить или получать свечку из колбека. пока не написал чёткий тест, но по наблюдениям получается что поллить гораздо быстрее. и скорее всего событие изменения свечи происходит реже и с запаздыванием по отношению к самому обновлению. запаздывание скорее всего технологически вставлено специально чтобы иметь возможность реже обновляться. ещё один нюанс. опять же не проводил чётких измерений, но при задании SetEmptyCallback свеча обновляется медленнее чем при задании SetUpdataCallback.
буду рад узнать о других результатх измерений, если кому-то эта тема тоже была или есть интересна
Артем написал: Колбек указывает только на порядковый номер обновлённой свечки в источнике данных, но не указывает к какому источнику данных она принадлежит. Проблематично при открытии нескольких источников данных с колбеками.
Ещё один вариант как можно сделать, здесь упор на то, что мы вольны добавлять столько функций к Датасорсу, сколько нам надо.
Код
stopped = false;
function OnStop()
stopped = true;
end;
function member_callback(dataSource, index)
message("member_callback\n dataSource.size() = " .. tostring(dataSource:Size()) .. ",\n index = " .. tostring(index), 1)
stopped = true
end
function main()
local ds = CreateDataSource ("QJSIM", "SBER", INTERVAL_M1)
ds.member_callback = member_callback
ds:SetUpdateCallback(function(index)
ds:member_callback(index)
end)
while not stopped do
sleep(1)
end
ds:Close()
end
На выходе получается
Код
member_callback
dataSource.size() = 722,
index = 722
s_mike@rambler.ru написал: Есть мнение, что их ровно столько и было....
глянул по сайту ММВБ, сегодня сделок было 1/2 от предыдущих дней ну даже 300 изменений свечек в минуту маловато. тот же ММВБ говорит что было 448 267 сделок по Si. с 7 до 24 часов это 17 часов, по 60 минут = 1020 минут, то есть по 400 сделок в минуту в среднем сегодня должно было быть. а в другие дни по 800. в минуту. действительно, не так уж и много. но квик транслирует примерно в два раза меньше.
s_mike@rambler.ru написал: Вы проверяли по таблице обезличенных сделок или по тиковому графику, сколько на самом деле было ИЗМЕНЕНИЙ цены? Есть мнение, что их ровно столько и было....
надо будет проверить в другой день, отчасти затем и сделал пост - чтобы люди писали цифры у других брокеров, мб это зависит от настроек брокера/канала. идея такая, что изменение свечи - происходит не по каждой сделке (зачем это делать по каждой сделке?), а лишь агрегатами, для экономии трафика. и наверняка цифра настраивается. меня удивило просто, насколько это редко происходит.
Nikolay написал: Более информативным был бы скрипт где есть три потока: Получение данных LAST для цены последней сделки Данные таблицы обезличенных сделок Данные от CreateDataSource
Последний самый медленный. Между его обновлениями десятки сделок могут пройти. Исключение Тиковый график, он равносилен обезличенным сделкам.
Спасибо, пока для тестов и строительства хватает "свечек", а обезличенные сделки, я думаю требуют выделенки и гораздо больших финансовых успехов и вложений.
Даже немного стыдно такое говорить, но после многих лет поллинга информации о свечках из Quik, с высокой скоростью, решил наконец проверить, как же часто реально в квике обновляются эти самые свечки. Простейший вопрос, простейший скрипт, но должны пройти годы (у некоторый вроде меня) чтобы об этом начать думать. Итого - скрипт показывает что свечка Si обновляется не сильно чаще 100 раз в минуту. Возможно сегодня просто неактивный день. Подскажите, а как у вас? Скрипт выдает сколько раз обновилась свеча за 1 минуту, с помощью сообщения в квике
Код
stopped = false;
function OnStop()
stopped = true;
end;
current_time = os.clock()
num = 0
function main()
function cb( index )
local time = os.clock()
if time - current_time > 60 then
current_time = time
message("Запросов в минуту: " .. num, 1)
num = 0
end
num = num + 1
end
ds = CreateDataSource ("SPBFUT", "SiZ1", INTERVAL_M1)
ds:SetUpdateCallback (cb)
while not stopped do
sleep(1)
end
ds:Close()
end
PS: пока писал, квик осилил выдать один раз аж 174
Но в целом получается опрашивать / долбить бедный квик 1000 раз в _секунду_ с вопросом "че, как, изменилась ли свеча" вообще никакого смысла нет. Достаточно 3-5 раз.
Будет только NUMCONTRACTS, в будущем не исчезнет. Изменилось лишь имя в таблице текущих торгов, было "количество открытых позиций" стало "открытых интерес" DB name остается прежний NUMCONTRACTS
Передумали менять на openintr? Вы ранее писали, что надо использовать его?
Sergey Gorokhov написал: По данному обращению мы определили, что причиной множественных отправок сделок (более двух) на клиентские места является неоптимальность в серверном ПО QUIK. После ее устранения сделки могут быть отправлены на клиентское место максимум 2 раза - по получению сделки из торговой системы и по факту ее обновления.
Stanislav Tvorogov написал: По данному обращению мы диагностируем что заявки, отправляются пользователям столько раз, сколько раз они менялись на сервере (под изменением понимается, как изменение статуса, остатка, так и установка UID, trans_id). При этом по факту заявки могут быть отправлены сразу в последнем, актуальном, состоянии. Поэтому клиенты видят многократный апдэйт одной и той же заявки без ее видимых изменений. В одной из следующих версий серверного ПО QUIK мы постараемся исправить эту ситуацию, чтобы не дублировать отправку заявки в одном и том же состоянии несколько раз.
ясно, спасибо! проблема известна значит. ок. как обойти у себя в коде понятно. а можно вопрос, точнее два? какие-то ещё способы общения по программной отправке в квик заявок кроме trans2quik и lua::sendTransaction имеются? решил перетащить свою реализацию с trans2quik на lua::sendTransaction, и всё вроде ничего, но вдруг есть чего-нибудь лучше, и чтобы сообщения в терминал не выводились (знаю, что можно отключить)
Nikolay написал: Это не пример, а факт, наблюдаемый каждый день. Первый вызов - появление записи, второй - присвоение номера транзакции, третий - флаг.
факты - это флаги в сообщениях которые я привёл. они одинаковы.
Если вы выведите в лог все значения из входящего аргумента order, то будет видно, что при каждом вызове изменяется одно или несколько значений.
Для примера, первый вызов - появилась запись в таблице orders. Второй - присвоился номе транзакции. Третий - ордер сменил флаг состояния на "исполненный".
я понимаю что статус может меняться. например тот же "balance". по изменяющемуся объекту Order вопросов нет, но у меня совершенно конкретный пример, где ничего не менялось. повторюсь - заявка исполнялась сразу же, что видно и по TransactionReply. флаги тоже приведены. нет смысла ничего придумывать "для примера"
Простенький скрипт, который отправляет заявку на 1 лот в Quik_Junior по сберу так, чтобы она заведомо исполнилась. В нём определены два колбэка, OnTransReply и OnOrder
В результате вижу, что OnOrder вызывается по-моей заявке два раза (она имеет 1 лот и исполняется сразу). Причём, очевидно, так бывает не всегда. Но заметил что такое получается чаще, если делать перед этим реконнект с сервером. Код:
Вопрос, это разве нормально? Чем обусловлено? Кто сталкивался? Как боретесь? Номер транзакции - не статический, для теста генерится рандомом от 1 до 1000
Ранее получал число открытых позиций через getParamEx...NUMCONTRACTS Теперь вижу появился другой параметр "Открытый интерес", в интерфейсе квика, для которого нет имени в справки а по старому имени возвращается 0. Как получить открытый интерес?
Обновился утром до 9.2.1.4, сейчас после 10-00 в таблице Состояние счёта у Сбербанка цена висит 333р и вообще не обновляется. До обновления такой проблемы не наблюдал При этом прибыль/убыток дня рассчитывается и меняется динамически
Насколько я могу судить, если в таблице Текущие торги есть старый и новый фьючерс, то при появлении окна Замена инструментов, если согласиться заменить старый фьючерс на новый (так что их становится как бы два), квик падает. Проверял и на 9.1 и на 9.2 - одинаково. dmp не создаётся. Если согласиться заменить все инструменты кроме "старого" на "новый" который уже есть - то не падает. В моём случае это было SBRF-9.21 и SBRF-12.21
если не секрет, что именно помогло снять тормоза при работе с окном заявки? у меня не на 5 секунд, а на все 5 минут окно зависает, при том что памяти свободно, процессор core i7 и сеть 1Gb и диск SSD со скоростью 3Gb/s но Квику всё равно
BlaZed написал: Предлагаю разработчикам добавить в Информационное окно, ну и соответственно в функцию getInfoParam возможность получения информации о версии сервера.
спасибо. и предложение напрашивается, да. но может в протоколе оно не транслируется.
спасибо. жаль конечно. но вижу есть другие интересные исправления всё же. версия 9.1.3 будет обратно совместима с сервером на 8 Quik? у меня Открытие Брокер, не знаю точно какая у них сейчас версия на сервере, программа этой информации не выдает
я правильно понимаю, что последняя версия на текущий момент 8.13.1, и в ней всё ещё есть ошибки синхронизации по работе с таблицами лимитов https://forum.quik.ru/forum10/topic6526/ ?
Часто бывает что если запускаешь квик в конце сессии торговой, а они ведь стали большие, то квик подвисает непонятно над чем на минут 5. Графики не двигаются, котировки не обновляются. Хотелось бы понимать что он там делает и сколько еще осталось. Нельзя ли сделать какую-нибудь статусную строку, (она уже есть внизу вообще-то), в которой бы писать что мол квик читает данные с сервера, или читает данные с диска, осталось 20% или там 5 минут. "управление ожиданиями"
Заметил такую странность. Продиагностировал не до конца, может быть на форуме меня кто-то дополнит и кто-то такое наблюдал: у меня открыто много графиков. На старших таймфреймах, типа час, день, месяц. Если я переключаюсь на минутный, для примера вот сейчас, в 11:xx, сравнительное начало торгов, то всё происходит быстро. Но если я делаю так с графиком, по которому открыт CreateDataSource, то весь квик сильно подвисает. И чем дальше к вечеру, тем больше. Это из-за какой-то блокировки на таблице данных, по которой я в Lua скрипте делаю браузинг? Нельзя ли оптимизировать эту блокировку? Например создавать копию DataSource для нужд квика, делать в ней модификации, а потом через короткую блокировку подменять содержимое датасорса открытого в скрипте целиком, а не построчно?
В скрипте я делаю перебор последних нескольких свечек из датасорса, но делаю это часто. Так что если блокировка ставится-снимается в квике построчно, то просмотр из скрипта такого датасорса будет сильно замедлять весь квик, что я и наблюдаю.
Дополню, что даже повторное открытие того же таймфрейма, на котором работает скрипт в окне квика снова приводит к подвисанию на минуту. А если в том же окне открывать другие таймфреймы никакого замедления нет. Прошу программистов Арка оценить возможность оптимизации блокировок при смене таймфрейма в окне квика и одновременной работе скрипта с этим таймфрейом через DataSource.
Павел Bosco написал: при переключении на минутный график Si шки терминал каждый раз "клюёт носом" секунд на 5-10
Добрый день.
Павел, поясните, что это значит.
происходит задержка вывода изображения, всё окно замирает и почему-то немного смещается вниз ("клюёт"), как бывает например, при большом потоке данных и недостаточном процессорном времени. у вас/у других на работающем сервере при переключении на минутки всё отрабатывает нормально? возможно тогда опять у меня какие-то издержки на работу через remote desktop
как выглядит сам клевок я уже записывал ранее, на прошлых версиях https://www.youtube.com/watch?v=uJ_mA_oJ00g&feature=youtu.be см где-то на 30+ секунде сейчас он у меня стабильно возникает при переключении на минутки, и длится заметно долго, если надо, могу записать еще раз
_sk_ написал: У меня 8.5.2 упал с дампом. Послал его разработчикам для анализа. Не всё пока хорошо.
у вас была возможность потестировать срабатываение колбэков на заявки? визуально если вручную заявки ставить, ответы довольно медленно приходят ну и вообще как-то кажется что иной раз терминал замирает, "чаще обычного"
s_mike@rambler.ru написал: Сеорее всего компилируете неподходящей версией luac
я собрал 5.3.5, а какую надо использовать?
отбой, разобрался. я случайно собрал lua 5.3.5 в x86 версии. а компилятор luac должен был быть x64, формат прекомиленных lua файлов разный для разных платформ, оказывается.