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

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

Страницы: 1 2 3 4 След.
Luasocket сервер - останавливает выполнение кода, Возможен ли асинхронный запуск нескольких функций в Quik lua ?
 
Цитата
Boris написал:

 client   =   server:accept()
 client:settimeout(  2  ) [/CODE]

таймаут надо ставить на сервер
[QUOTE]
server:settimeout(2)
даже в гугле есть ответ
https://stackoverflow.com/questions/42445423/luasocket-serveraccept-timeout-tcp
Кривые шибки в QLua
 
TGB, ну у меня не было запроса к вам на изменение или оценку логики моей программы (вроде бы?). соответственно к чему бы мне реагировать на предложение что-то менять?
да, к lua_State я обращаюсь из разных потоков, используя синхронизацию, всё верно.
не вижу проблем сделать и очередь, решение не плохое. ирония в том, что я с очередями работаю порядка 20 лет, этот шаблон мне мягко говоря знаком.

большой вопрос, насколько велика моя степень "вмешательства в логику quik/lua", и что и как может портиться здесь, возможно я недооценил этот момент.
и да, технология у меня используется пока не в полную силу, по факту там лишь 1 дополнительный к main поток чаще всего, я планировал сделать 2-3-4, на каждый счёт отдельно, то есть они и сейчас могут запускаться в ответ на приход нового "клиента"-робота, но у правительства оказались другие планы и торговля на америке и нашей фонде стала в феврале на долгое время неактуальной.
некоторое время я гонял два дополнительных потока, один из которых был просто для получения отдельной информации, но потом для надёжности реальных денежных торгов оставил только 1.
информация из второго мне пока не нужна, тк фонда хоть и торгуется, но это пока не интересно.
возможно если бы я стал расширять потоки, я бы сталкивался с ошибками и стал бы их решать, а так - работает и не падает, хоть main и клиент крутятся в двух разных потоках.
Кривые шибки в QLua
 
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-функции, я бы делал так.
Кривые шибки в QLua
 
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 секунд.
и конкурентно возвращаются из него.
опять непонятно..
7 часов, кто больше?
 
чтоб не искать -
2 года назад
https://forum.quik.ru/messages/forum10/message49035/topic5852/#message49035
(ответ - в примере прямо над вопросом!)

в этом году
https://forum.quik.ru/messages/forum10/message64731/topic5823/#message64731
7 часов, кто больше?
 
два года назад вы спрашивали
Цитата
Владимир написал:
Господа, объясните мне, дураку, на кой вам всё это надо? Торговля на бирже - процесс медленный, вдумчивый, процессы длятся месяцами, даже годами, и потому задержка на минуту, час, день, неделю существенно на результат не влияет. Вы что, делаете сотни и тысячи сделок в час? Но ведь даже в этом случае времени просто ВАГОН! Одно ядро, два, десять, тысяча, C или Lua - ну какая разница?! Не понимаю...

в посте где было объяснение, зачем собственно нужен sleep
Цитата
Владимир написал:
Поставил туда sleep(1) и - О, ЧУДО!
...
ЧО ВАЩЕ ЗДЕСЬ ТВАРИЦЦА?!

но прошло ещё пару дней, и снова на ту же тему
Цитата
Владимир написал:
Нафига вам всё это нужно, господа? Я потратил недели две, чтобы вынести всё, что можно, в поток main и уже практически забыл про вылеты скрипта или отвисания Квика. Не говоря уже о том, что я буквально с первого же дня постулировал: никаких библиотек, никаких других языков - скрипт должен работать на любой версии Квика и любой версии языка. И никаких стаканов, никаких свечей, никаких графиков, никаких сокетов. А все вопросы синхронизации/блокировки выполняются самим скриптом, у которого для этого заведены соответствующие стеки и флаги. Ведь наша задача - получить рабочую версию торговой программы, а не вести бесконечную борьбу с глюками всех мастей и размеров.

то есть понимание за два года и явное столкновение с проблемой так и не пришло.
Кривые шибки в QLua
 
Цитата
TGB написал
2.  
Цитата
Павел Bosco написал:
вопрос, как увидеть существование блокировки при вызове quik lua api для меня остался открытым.
У меня встречный вопрос: Если вам нужно просто реализовать своего робота, а не выполнять научно-исследовательскую работу  :: , то зачем вам нужны потоки и прочая "лабуда"? Пишите своего робота на QLua, как советует Владимир, стараясь обходиться даже без внешних библиотек. Это хороший совет для всех и, особенно, для начинающих.

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

я предполагаю, что мой тест провалился, потому что обрамление в lock/unlock происходит только для вызовов из lua байткода. а я вызывал sleep через pcall в своей c функции. в этом случае обрамления не происходит. тогда я попробовал даже дополнительный способ: вставил вызов функции sleep внутрь новой lua функции m_sleep, чтобы получить задействовать VM, но и тут ожидаемого "обрамления" не произошло.
возможно там где-то есть и хитрые проверки, чтобы не получалось так, что мы из C функции вызываем из неё другую C функцию, та вызывает lua функцию и мы получаем блокировку.

потом я переделал main на Lua, тест стал выглядеть так
main (lua) -> _main© [создание двух потоков] -> thread © -> m_sleep (lua) -> sleep(10000) (lua)
но оба потока завершаются через 10 секунд одновременно.
Кривые шибки в QLua
 
Цитата
TGB написал:
Реальным фактом является то, что ошибка синхронизации в QLua существовавшая, по крайней мере, с мая 2020г., была исправлена через три дня после того как я выложил код, который, по моему мнению (опять расплывчато  :: ), мог ее исправить.  Реальным фактом является, что после исправления этой ошибки разработчиком QUIK был изменен номер версии.

я собрал тест, который в двух потоках вызывает quik lua функцию sleep на 10 секунд, два потока работают с одним и тем же lua_State, и в этом конкретном случае, потоки отрабатывают параллельно.
одновременно вызывают sleep, одновременно возвращаются из неё.
нет никакой синхронизации/блокировки.

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

вопрос, как увидеть существование блокировки при вызове quik lua api для меня остался открытым.
Кривые шибки в QLua
 
1) опытные программисты изолируют проблему и предоставляют тесткейс
2) это ваш код "исправления проблемы", я говорил о коде "демонстрирующем проблему"
3) я прочёл ветку, там не было сообщений от поддержки, что ваши пожелания внедрены и версия сменилась, только ваша догадка об этом. есть реальный факт что ваши пожелания заставили разработчиков что-то сделать и сменить версию?

возможно всё-таки я не о том пишу, для этого хотелось бы понять, c-closure и c функция это одно и тоже или нет. или другими словами, что имеется в виду под с функцией.
Кривые шибки в QLua
 
написал себе заметочку, повторю тут, как можно проверить блокировку (а она сейчас с нами, в этой комнате?)
1) первый тест, который в мейн будет порождать два потока, писать "я в потоке а", делать  lua_lock, windows Sleep на 10 секунд,  "я вышел из паузы в потоке а", lua_unlock
и тоже самое в потоке б.
2) второй тест - сделать тоже самое, но без lua_lock сделать qlua sleep, декларируется что там используется блокировка?
3) если я правильно понимаю, то блокировка будет в обоих случаях, то есть два потока отработают последовательно, а не параллельно

если моё понимание в 3) верно, то все Sleep и WaitForSingleObject для main надо обрамлять lua_unlock перед и lua_lock после.
Кривые шибки в QLua
 
еще у меня глупый вопрос - с функция и c closure - это одно и тоже?
Кривые шибки в QLua
 
Цитата
TGB написал:
Цитата
Павел Bosco написал:
вы как-то анализировали устройство Qlua? Или это догадки?
Почитайте комментарии начиная с  https://forum.quik.ru/messages/forum10/message54696/topic6356/#message54696
почитал пару листов, у вас там очень обобщающие рассуждения "похоже, что" "скорее всего", основанные на ваших собственных наблюдениях и тестах.



Тем не менее спрошу, нашлось ли подтверждение (из кода или от поддержки), что 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% действенный тесткейс повторения ошибки.
Кривые шибки в QLua
 
Цитата
TGB написал:
Но все участки кода Lua (за исключением кодов C-функций Lua) используются в режиме разделения, то есть под синхронизацией, при которой только один может исполнять такой код. Таким образом в QLua параллелизм может возникать (если так сложится) только на кодах C-функций Lua (хоть в main, хоть в колбеках).

вы как-то анализировали устройство Qlua? Или это догадки?
Тема мне интересна, есть ли какие-то ссылки почитать? В моем решении есть небольшие болячки. У меня колбэки и main - это c closure, вызовы lua через pcall, при этом я синхронизирую все обращения к main lua_State (к ней обращение во много потоков) через критическую секцию
Болячки выражаются в замедлении квика (отставании времени от сервера), если открыт GUI, а если он минимизирован - всё шустро очень - но так его держать неудобно.
Тоже думал что есть какие-то проблемы с блокировками, но на видимом мне слое "реальности" ничего не нашел.
Кривые шибки в QLua
 
Цитата
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 есть такой код
Код
#if !defined(lua_lock)
#define lua_lock(L)   ((void) 0)
#define lua_unlock(L)   ((void) 0)
#endif

то есть эти "скобки" ничего не делают на самом деле.

и еще вы пишете что колбеки в текущей реализации не исполняются параллельно main. это действительно как-то так? main где-то приостанавливается? каким образом?
lua-mysql не компилируется под x64
 
Цитата
Александр написал:
Цитата
swerg написал:
Проблема не в библиотеках, а в том, судя по сообщению ликёра, что проект 32 битный собираетеМенять в свойствах проектаИ не понятно как именно вы былдитк, вы это упорно не пишете
Ну как же не пишу. В пятом сообщении даже жирным выделил. А в первом сообщении, второе предложение: написал что мучаюсь с luarocks.
Тема про то, как настроить luarocks. Он так на любые пакеты реагирует.
Я понимаю, что luarocks пытается собрать под х32, но как ему сказать иначе - я не знаю.

разные версии компиляторов есть, всё зависит от того из какого окружения он запускается,
для 64bit заголовок окна будет а-ля x64 Native Tools
в MSVC это называется "Платформа" д.б. x64
вопрос имеет мало отношения к quik
Оптимизация грфики в Quik, Quik v9.7.0.14 грузит GPU на 60-70%
 
Добрый день,

возможно такая проблема только у меня, если нет, прошу присоединяться с вашими отзывами к теме, но у меня Quik грузит GPU (старенькая GeForce GT 730) на 60-70%,
в результате чего, судя по всему начинает отставать получение данных, за минуту набегает отставание данных в несколько секунд.

не уверен насколько это было на прошлых версиях, кажется это появилось где-то в районе 9.6, но я не уверен.
Может ли разработчик посоветовать что-то настроить в операционной системе (Windows 10), либо в самом квике для ускорения процесса?

Так же я подключаюсь к этому компьютеру по Remote Desktop, возможно это тоже даёт дополнительную нагрузку на видео-карту.
Кроме того, я использую тёмную тему.
И у меня есть самописные индикаторы на Lua, но они сами не рисуют, тут GPU видно не при чём.

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

CPU нагружен слабо, пропускной способности сети тоже более чем достаточно (500 mb/s), блокировок в скрипте _вроде_ бы нет, да если бы и были, они бы не давали высокую нагрузку GPU.
Так же я обновил недавно windows, может и в этом дело, сборка 19044.1766
Работает ли Lua с ИТП (Иностранной Торговой Площадкой)?
 
Цитата
Nikolay написал:
Если данные транслируются в ТТТ, то и getParamEx вернет их. Укажите корректный код класса и код инструмента. Можете увидеть их в информационном окне: правая клавиша в строке ТТТ - информация об инструменте.

вопрос снимается. код инструмента нужно указывать "US88160R1014"
Николай, спасибо за совет
Работает ли Lua с ИТП (Иностранной Торговой Площадкой)?
 
Пытаюсь попробовать получить что-то в Открытии-брокер с ИТП, но в ответ одни нули, хотя в таблице текущих торгов цифра предыдущего закрытия есть.
Я делаю что-то не так?
Код
function main()
  message("getParamEx: " .. getParamEx("NA_ALL_50_C", "TSLA", "PREVPRICE").param_value, 1)
end
Как часто у вас вызывается DataSource:Callback?
 
Цитата
Владимир написал:
....
я хотел понять, что будет быстрее - поллить или получать свечку из колбека. пока не написал чёткий тест, но по наблюдениям получается что поллить гораздо быстрее.
и скорее всего событие изменения свечи происходит реже и с запаздыванием по отношению к самому обновлению. запаздывание скорее всего технологически вставлено специально чтобы иметь возможность реже обновляться.
ещё один нюанс. опять же не проводил чётких измерений, но при задании SetEmptyCallback свеча обновляется медленнее чем при задании SetUpdataCallback.

буду рад узнать о других результатх измерений, если кому-то эта тема тоже была или есть интересна
Добавить в CreateDataSource():SetUpdateCallback() аргумент, указывающий на DataSource
 
Цитата
Артем написал:
Колбек указывает только на порядковый номер обновлённой свечки в источнике данных, но не указывает к какому источнику данных она принадлежит. Проблематично при открытии нескольких источников данных с колбеками.
Ещё один вариант как можно сделать, здесь упор на то, что мы вольны добавлять столько функций к Датасорсу, сколько нам надо.

Код
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
Как часто у вас вызывается DataSource:Callback?
 
Цитата
s_mike@rambler.ru написал:
Есть мнение, что их ровно столько и было....
глянул по сайту ММВБ, сегодня сделок было 1/2 от предыдущих дней
ну даже 300 изменений свечек в минуту маловато.
тот же ММВБ говорит что было 448 267 сделок по Si.
с 7 до 24 часов это 17 часов, по 60 минут = 1020 минут, то есть по 400 сделок в минуту в среднем сегодня должно было быть.
а в другие дни по 800. в минуту.
действительно, не так уж и много. но квик транслирует примерно в два раза меньше.
Как часто у вас вызывается DataSource:Callback?
 
Цитата
s_mike@rambler.ru написал:
Вы проверяли по таблице обезличенных сделок или по тиковому графику, сколько на самом деле было ИЗМЕНЕНИЙ цены?  Есть мнение, что их ровно столько и было....

надо будет проверить в другой день, отчасти затем и сделал пост - чтобы люди писали цифры у других брокеров, мб это зависит от настроек брокера/канала.
идея такая, что изменение свечи - происходит не по каждой сделке (зачем это делать по каждой сделке?), а лишь агрегатами, для экономии трафика.
и наверняка цифра настраивается. меня удивило просто, насколько это редко происходит.
Как часто у вас вызывается DataSource:Callback?
 
Цитата
Nikolay написал:
Более информативным был бы скрипт где есть три потока:
Получение данных LAST для цены последней сделки
Данные таблицы обезличенных сделок
Данные от CreateDataSource

Последний самый медленный. Между его обновлениями десятки сделок могут пройти. Исключение Тиковый график, он равносилен обезличенным сделкам.
Спасибо, пока для тестов и строительства хватает "свечек", а обезличенные сделки, я думаю требуют выделенки и гораздо больших финансовых успехов и вложений.
Как часто у вас вызывается DataSource:Callback?
 
Цитата
s_mike@rambler.ru написал:
А что удивляет?

у вас есть уверенность, что в секунду на si происходит более 174 изменений цены?

что не так?
речь шла о минутах
Как часто у вас вызывается DataSource:Callback?
 
Даже немного стыдно такое говорить, но после многих лет поллинга информации о свечках из 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 раз.
Кривые шибки в QLua
 
Цитата
TGB написал:
Цитата
Alexey Ivannikov написал:
Информация получена, проблема изучается. Постараемся в ближайшее время дать ответ.
Появилась очередная версия QUIK 9.3.1.11. В этой версии проблема существует.
что-то кажется долго эта версия не протянет - памяти уж больно много жрёт: до 6гб на старте
Что с параметром NUMCONTRACTS в 9.2.1.4?
 
Цитата
Egor Zaytsev написал:
Добрый день.

Будет только NUMCONTRACTS, в будущем не исчезнет.
Изменилось лишь имя в таблице текущих торгов, было "количество открытых позиций" стало "открытых интерес"
DB name остается прежний NUMCONTRACTS
Передумали менять на openintr? Вы ранее писали, что надо использовать его?
Дубликаты уведомлений onOrder v9.2.2.11
 
Цитата
Старатель написал:
Есть другие факты:

https://forum.quik.ru/messages/forum10/message12868/topic1082/#message12868
Цитата
Sergey Gorokhov написал:
По данному обращению мы определили, что причиной множественных     отправок сделок (более двух) на клиентские места является неоптимальность в     серверном ПО QUIK. После ее устранения сделки могут быть отправлены на клиентское место максимум 2 раза - по     получению сделки из торговой системы и по факту ее обновления.
https://forum.quik.ru/messages/forum10/message13524/topic1082/#message13524
Цитата
Stanislav Tvorogov написал:
По данному обращению мы диагностируем что заявки, отправляются     пользователям столько раз, сколько раз они менялись на сервере (под     изменением понимается, как изменение статуса, остатка, так и     установка UID, trans_id). При этом по факту заявки могут быть     отправлены сразу в последнем, актуальном, состоянии. Поэтому клиенты     видят многократный апдэйт одной и той же заявки без ее видимых     изменений. В одной из следующих версий серверного ПО QUIK мы     постараемся исправить эту ситуацию, чтобы не дублировать отправку     заявки в одном и том же состоянии несколько раз.
ясно, спасибо! проблема известна значит. ок.
как обойти у себя в коде понятно.
а можно вопрос, точнее два? какие-то ещё способы общения по программной отправке в квик заявок кроме trans2quik и lua::sendTransaction  имеются?
решил перетащить свою реализацию с trans2quik на lua::sendTransaction, и всё вроде ничего, но вдруг есть чего-нибудь лучше, и чтобы сообщения в терминал не выводились (знаю, что можно отключить)
Дубликаты уведомлений onOrder v9.2.2.11
 
Цитата
Nikolay написал:
Это не пример, а факт, наблюдаемый каждый день.
Первый вызов - появление записи, второй - присвоение номера транзакции, третий - флаг.
факты - это флаги в сообщениях которые я привёл. они одинаковы.
Дубликаты уведомлений onOrder v9.2.2.11
 
Цитата
Nikolay написал:
Может и три раза, и больше.

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

Для примера, первый вызов - появилась запись в таблице orders. Второй - присвоился номе транзакции. Третий - ордер сменил флаг состояния на "исполненный".
я понимаю что статус может меняться. например тот же "balance". по изменяющемуся объекту Order вопросов нет,
но у меня совершенно конкретный пример, где ничего не менялось.
повторюсь - заявка исполнялась сразу же, что видно и по TransactionReply. флаги тоже приведены.
нет смысла ничего придумывать "для примера"
Дубликаты уведомлений onOrder v9.2.2.11
 
Простенький скрипт, который отправляет заявку на 1 лот в Quik_Junior по сберу так, чтобы она заведомо исполнилась.
В нём определены два колбэка, OnTransReply и OnOrder

В результате вижу, что OnOrder вызывается по-моей заявке два раза (она имеет 1 лот и исполняется сразу).
Причём, очевидно, так бывает не всегда. Но заметил что такое получается чаще, если делать перед этим реконнект с сервером.
Код:
Код
function OnTransReply(trans)
 -- Если поступила информация по текущей транзакции 
 message("TransReply:\n" .. --trans.date_time .. '\n' .. 
   tostring(trans.trans_id) .. '\n' .. 
   trans.sec_code .. '\n' .. tostring(trans.status) .. '\n' .. 
   tostring(tobin(trans.flags)) .. '\n' .. 
    tostring(trans.order_num) .. '\n' .. 
   tostring(trans.quantity) .. '\n' .. 
   tostring(trans.price) .. '\n' .. 
   trans.result_msg);
end;

function OnOrder(order) 
 -- Если поступила информация по сделке
 message("OnOrder {\n" .. --trade.datetime .. '\n' .. 
   " trans_id: " .. tostring(order.trans_id) .. '\n' .. 
    " order_num: " .. tostring(order.order_num) .. '\n' .. 
   " flags: " .. tostring(tobin(order.flags)) .. '\n' ..
        " brokerref: " .. tostring(order.brokerref)  .. '\n' ..
   " balance: " .. tostring(order.balance) .."\n" .. 
   " qty: " .. tostring(order.qty) .. '\n' ..
   " value: " .. tostring(order.value) .. '\n' ..
   " account: " .. tostring(order.account) .. '\n' ..
   " activation_time: " .. tostring(order.activation_time) .. '\n' ..
   " ext_order_status: " .. tostring(order.ext_order_status) .. '\n' ..
   " trading_session: " .. tostring(order.trading_session) .. "\n}");
end;


Результат работы (копирую из сообщений)
Код
TransReply:
236
SBER
3
1001000000000000000001
6307340506
1.0
369.5
(161) Заявка N 6307340506 зарегистрирована. Удовлетворено 1

OnOrder {
 trans_id: 236
 order_num: 6307340506
 flags: 11000
 brokerref: 10112//
 balance: 0.0
 qty: 1.0
 value: 3695.0
 account: NL0011100043
 activation_time: 0
 ext_order_status: 0
 trading_session: 0
}

OnOrder {
 trans_id: 236
 order_num: 6307340506
 flags: 11000
 brokerref: 10112//
 balance: 0.0
 qty: 1.0
 value: 3695.0
 account: NL0011100043
 activation_time: 0
 ext_order_status: 0
 trading_session: 0
}


Вопрос, это разве нормально? Чем обусловлено? Кто сталкивался? Как боретесь?
Номер транзакции - не статический, для теста генерится рандомом от 1 до 1000
Что с параметром NUMCONTRACTS в 9.2.1.4?
 
Никто не сталкивался? У всех нормально работает?
Что с параметром NUMCONTRACTS в 9.2.1.4?
 
Ранее получал число открытых позиций через getParamEx...NUMCONTRACTS
Теперь вижу появился другой параметр "Открытый интерес", в интерфейсе квика, для которого нет имени в справки а по старому имени возвращается 0.
Как получить открытый интерес?
9.2.1.4 не обновляется цена в таблице Состояние счёта
 
Обновился утром до 9.2.1.4, сейчас после 10-00 в таблице Состояние счёта у Сбербанка цена висит 333р и вообще не обновляется.
До обновления такой проблемы не наблюдал
При этом прибыль/убыток дня рассчитывается и меняется динамически
Падает при замене инструментов
 
Насколько я могу судить, если в таблице Текущие торги есть старый и новый фьючерс, то при появлении окна Замена инструментов, если согласиться заменить старый фьючерс на новый (так что их становится как бы два), квик падает.
Проверял и на 9.1 и на 9.2 - одинаково.
dmp не создаётся.
Если согласиться заменить все инструменты кроме "старого" на "новый" который уже есть - то не падает.
В моём случае это было SBRF-9.21 и SBRF-12.21
Тормозит Квик при выставлении заявки, Проблема с Квик
 
Цитата
Сергей написал:
https://forum.quik.ru/forum1/topic1539/
если не секрет, что именно помогло снять тормоза при работе с окном заявки?
у меня не на 5 секунд, а на все 5 минут окно зависает, при том что памяти свободно, процессор core i7 и сеть 1Gb и диск SSD со скоростью 3Gb/s
но Квику всё равно
Отладка QUIK 8.13
 
Цитата
BlaZed написал:
Предлагаю разработчикам добавить в Информационное окно, ну и соответственно в функцию getInfoParam возможность получения информации о версии сервера.
спасибо. и предложение напрашивается, да. но может в протоколе оно не транслируется.
Отладка QUIK 8.13
 
Цитата
Roman Azarov написал:
Павел Bosco, добрый день!

Актуальная версия рабочего места QUIK - 9.1.3

Описанные в теме  https://forum.quik.ru/forum10/topic6526/  ошибки в ней исправлены не были.

спасибо. жаль конечно. но вижу есть другие интересные исправления всё же. версия 9.1.3 будет обратно совместима с сервером на 8 Quik?
у меня Открытие Брокер, не знаю точно какая у них сейчас версия на сервере, программа этой информации не выдает
Отладка QUIK 8.13
 
я правильно понимаю, что последняя версия на текущий момент 8.13.1, и в ней всё ещё есть ошибки синхронизации по работе с таблицами лимитов
https://forum.quik.ru/forum10/topic6526/
?
Отладка QUIK 9.1
 
не нашел в таблице изменений каких-то кардинальных отличий от версии 8
или надо смотреть изменения для версии 9.0? но где их смотреть?

почему версия 9.1, а не 8.14?
Статус на время долгой паузы
 
Часто бывает что если запускаешь квик в конце сессии торговой, а они ведь стали большие, то квик подвисает непонятно над чем на минут 5.
Графики не двигаются, котировки не обновляются.
Хотелось бы понимать что он там делает и сколько еще осталось.
Нельзя ли сделать какую-нибудь статусную строку, (она уже есть внизу вообще-то), в которой бы писать что мол квик читает данные с сервера, или читает данные с диска, осталось 20% или там 5 минут.
"управление ожиданиями"
Медленное переключение на минутки при созданном CreateDataSource, Может занимать больше минуты
 
Заметил такую странность. Продиагностировал не до конца, может быть на форуме меня кто-то дополнит и кто-то такое наблюдал:
у меня открыто много графиков. На старших таймфреймах, типа час, день, месяц. Если я переключаюсь на минутный, для примера вот сейчас, в 11:xx, сравнительное начало торгов,
то всё происходит быстро.
Но если я делаю так с графиком, по которому открыт CreateDataSource, то весь квик сильно подвисает. И чем дальше к вечеру, тем больше.
Это из-за какой-то блокировки на таблице данных, по которой я в Lua скрипте делаю браузинг?
Нельзя ли оптимизировать эту блокировку? Например создавать копию DataSource для нужд квика, делать в ней модификации, а потом через короткую блокировку подменять содержимое датасорса открытого в скрипте целиком, а не построчно?

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

Дополню, что даже повторное открытие того же таймфрейма, на котором работает скрипт в окне квика снова приводит к подвисанию на минуту. А если в том же окне открывать другие таймфреймы никакого замедления нет.
Прошу программистов Арка оценить возможность оптимизации блокировок при смене таймфрейма в окне квика и одновременной работе скрипта с этим таймфрейом через DataSource.
Отладка QUIK 8.5
 
https://www.youtube.com/watch?v=soM1M032KPQ
Отладка QUIK 8.5
 
Цитата
Павел Bosco написал:
сейчас он у меня стабильно возникает при переключении на минутки, и длится заметно долго, если надо, могу записать еще раз

вот ещё одно видео, где видно масштабы тормозов, переключение с 5 мин на 1 мин, если судить по таймингу самого видео, заняло примерно 14 секунд
Отладка QUIK 8.5
 
Цитата
Egor Zaytsev написал:
Цитата
Павел Bosco написал:
при переключении на минутный график Si шки терминал каждый раз "клюёт носом" секунд на 5-10
Добрый день.

Павел, поясните, что это значит.

происходит задержка вывода изображения, всё окно замирает и почему-то немного смещается вниз ("клюёт"), как бывает например, при большом потоке данных и недостаточном процессорном времени.
у вас/у других на работающем сервере при переключении на минутки всё отрабатывает нормально? возможно тогда опять у меня какие-то издержки на работу через remote desktop

как выглядит сам клевок я уже записывал ранее, на прошлых версиях
https://www.youtube.com/watch?v=uJ_mA_oJ00g&feature=youtu.be
см где-то на 30+ секунде
сейчас он у меня стабильно возникает при переключении на минутки, и длится заметно долго, если надо, могу записать еще раз
Отладка QUIK 8.5
 
при переключении на минутный график Si шки терминал каждый раз "клюёт носом" секунд на 5-10
Отладка QUIK 8.5
 
Цитата
_sk_ написал:
У меня 8.5.2 упал с дампом. Послал его разработчикам для анализа. Не всё пока хорошо.
у вас была возможность потестировать срабатываение колбэков на заявки? визуально если вручную заявки ставить, ответы довольно медленно приходят
ну и вообще как-то кажется что иной раз терминал замирает, "чаще обычного"
Грядущие изменения на срочном рынке МБ: поддержка работы с 19-значными номерами заявок и сделок
 
Цитата
Павел Bosco написал:
Цитата
s_mike@rambler.ru написал:
Сеорее всего компилируете неподходящей версией luac
я собрал 5.3.5, а какую надо использовать?
отбой, разобрался. я случайно собрал lua 5.3.5 в x86 версии.
а компилятор luac должен был быть x64, формат прекомиленных lua файлов разный для разных платформ, оказывается.
Грядущие изменения на срочном рынке МБ: поддержка работы с 19-значными номерами заявок и сделок
 
Цитата
s_mike@rambler.ru написал:
Сеорее всего компилируете неподходящей версией luac
я собрал 5.3.5, а какую надо использовать?
Грядущие изменения на срочном рынке МБ: поддержка работы с 19-значными номерами заявок и сделок
 
почему новый квик 8.5.2.11 может не видеть скомпилированный индикатор?
если не компилировать то его видно и нормально работает
а если скомпилировать - то его уже не видно в списке, что может быть не так?
Страницы: 1 2 3 4 След.
Наверх