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

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

Страницы: Пред. 1 2
Как из Lua узнать сумму денежных средств на начало торгов?
 
У брокера Открытие после подключения услуги Единый счет "единым" становится счет который раньше был счетом фонды. На остальных отображаются в основном нули. Это откровенно корявое пояснение но мне не удалось получить лучшего ни от брокера ни от коллег в интернете. Для обычной торговли впрочем работает. Как с этим работать из луа я пока не дошел, вероятно обычным порядком.
Как это выглядит у других брокеров предлагающих "единый счет" не знаю, у меня их нет.
Тайминг функциональности QUIK из луа, как правильно замерить
 
Цитата
Николай Камынин написал:
Попробуйте еще измерить для сравнения время пустого цикла на луа
В моих условиях ничего познавательного. Флуктуации вокруг нуля если можно так позволить себе выразиться. Придумал другой замер:
Код
size_t iResult;
lua_settop(L, 0);
lua_getfield(L, LUA_GLOBALSINDEX, "getQuoteLevel2");
lua_pushstring(L, pcClassCode);
lua_pushstring(L, pcSecCode);
iResult = lua_pcall(L, 2, 1, NULL);  // Здесь все накладные расходы
if (iResult)
{
   // Сюда я ни разу не попадал
}
else
{
  // А здесь я имитирую полезную деятельность
}
lua_settop(L, 0);
Итого, lua_pcall - порядка 99.1 - 99.3% всего времени, остальные луа - вызовы порядка 0.4%, моя деятельность 0.25-0.5%
Собственно подтверждает все те же мысли.

Цитата
Николай Камынин написал:
Но эти замеры мало что дают для оценки быстродействия робота.Проблема в том что данные с сервера QUIK приходят блоками в которых собирается инфа за некоторое время.Возникает вопрос на сколько реально полученные данные запаздывают от их появления на бирже.Собственно успешность HFT робота и зависит от этого запаздывания.Попробуйте оценить это время и сравнить его со скоростью обработки полученных данных.
Дык понятно что крутым высокочастотником я при использовании квика не стану. Смысл замера в другом, если связываться работать со стаканами вообще - буду иметь представление о пропускной способности. И не создам сам себе узких мест. Постараюсь во всяком случае )))
dofile в защищённом режиме
 
Мне "болванка" кода использующего обертку в pcall представляется примерно так:
Код
is_run = true
TimeOut = 500

function ErrorFunction()
    -- имитируем код генерирующий ошибку
    s=a
end

function main()
local CallSuccess
    while is_run do
        -- Безопасно вызываем функцию которая может выдать ошибку
        [список возможных результатов] CallSuccess = pcall(ErrorFunction[, другие возможные аргументы])
        if CallSuccess then
            -- Вызов успешен, анализируем результаты (если предусмотрено)
        else
            -- Здесь какая-то работа над ошибками
        end
        sleep(TimeOut)
    end
end
В квадратных скобках как обычно параметры которые могут быть или не быть.
Тайминг функциональности QUIK из луа, как правильно замерить
 
Цитата
s_mike@rambler.ru написал:
ваш запрос к терминалу на получение стакана ставится в терминале в очередь на обработку. И наверняка с низким приоритетом.
Кстати. Я на самом деле не могу ничего возразить ибо понятия не имею что в недрах терминала происходит.
Но вот тот факт что время отклика почти прямо пропорционально размеру стакана наводит на мысль что основные накладные расходы таки при его формировании.
Мысль неконструктивная, способа послиять на формирование стакана не видно. Просто любопытно.
Тайминг функциональности QUIK из луа, как правильно замерить
 
Ситуация более-менее понятна, благодарю за ответы!
Буду думать дальше )))
Тайминг функциональности QUIK из луа, как правильно замерить
 
Цитата
Sergey Gorokhov написал:
Боюсь что на этот вопрос нет ответа. Т.к. нет такого эталонного образца "то что должно быть"
Чисто любопытства ради попробую сформулировать вопрос по другому.
В стакане NxN очевидно 4N содержательных цифр. Мой тестовый код имитирующий работу со стаканом получает каждую, умножает на какое-то число с плавающей точкой (сишный double), далее складывает с каким-то числом с плавающей точкой и потом сравнивает с еще каким-то числом с плавающей точкой. По результатам сравнения инкрементируется один из двух счетчиков.
Так вот, вся эта активность занимает примерно в 400 раз меньше времени чем получение стакана. Такое соотношение выглядит нормально?

И еще вопрос по близкой теме. Глубину получения стаканов можно менять в настройках квик. А из скрипта луа есть аналогичная функциональность? И если нет можно ли выразить пожелание ее добавить?
Тайминг функциональности QUIK из луа, как правильно замерить
 
Апдейт, поэкспериментировал разворачивать цикл чтобы было меньше итераций самого цикла.

Лучший результат для стакана 10х10 где-то 55-65 микросекунд. Когда внутри цикла больше 100 строк кода похоже растут накладные расходы самого луа-движка, дальнейшее разворачивание уже ухудшает результат.
Вопрос тот же, цифры уже похожи на то из чего можно исходить?
Тайминг функциональности QUIK из луа, как правильно замерить
 
Цитата
Sergey Gorokhov написал:
"дерганье" миллион раз не должно вызывать никаких аномалий.Другой вопрос в том что каждая итерация цикла может выполняться раз в 15.625 мс, почитать можно например тут:  https://habrahabr.ru/company/intel/blog/186998/
Во-первых спасибо за консультации.

Далее, закрыл Visual Studio. ))) Убедился что таймер на умолчательных 15.6, повторил тесты. Результат лучше на ~17%
Стакан 10х10 в диапазоне 65-73 микросекунды, стакан 20х20 125-135 микросекунд. Вопрос, похожи ли эти цифры на то что быть должно или следует искать еще узкие места?
Тайминг функциональности QUIK из луа, как правильно замерить
 
Попробовал гонять кое - какие тесты скорости своего скрипта.
Один из тестов пытался отределить время затрачиваемое непосредственно на системный вызов getQuoteLevel2
Код
local TheClassCode = "QJSIM"
local TheSecCode = "SBER"
local NumIteractions2 = 100000
local NumRepeats2 = 10
local StartTime = 0
local RunTime = 0
local SumRunTime = 0
local MaxRunTime = 0
local MinRunTime = 100500
local QuoteL2 = {}

function TestQuoteL2_2()
    for TheRepeat =1, NumRepeats2, 1    do
        StartTime = os.clock()

        for TheIteraction =1, NumIteractions, 1 do
            QuoteL2 = getQuoteLevel2(TheClassCode, TheSecCode)
        end

        RunTime = os.clock() - StartTime
        SumRunTime = SumRunTime + RunTime
        if RunTime < MinRunTime then
            MinRunTime = RunTime
        end
        if RunTime > MaxRunTime then
            MaxRunTime = RunTime
        end
        TheMessage = "Attempt # "..tostring(TheRepeat).." RunTime = "..tostring(RunTime)
        message(TheMessage)
    end
    local AvgRunTime = SumRunTime / NumRepeats2
    TheMessage = "Tested "..tostring(NumRepeats2).." times, "..tostring(NumIteractions2).." iteractions each"
    message(TheMessage)
    TheMessage = "Average run time = "..tostring(AvgRunTime).." for "..tostring(NumIteractions2).." iteractions"
    message(TheMessage)
    TheMessage = "Maximum run time = "..tostring(MaxRunTime)
    message(TheMessage)
    TheMessage = "Minimum run time = "..tostring(MinRunTime)
    message(TheMessage)
end

function main()
    TestQuoteL2_2()
end
Это фрагмент разумеется, полный текст там слишком много букв для цитирования да и к вопросу отношения не имеет, еще ряд тестов уже моего кода. Так вот, результат работы этого конкретно теста:
Код
08.10.2018    0:15:42    Tested 10 times, 100000 iteractions each
08.10.2018    0:15:42    Average run time = 8.3163 for 100000 iteractions
08.10.2018    0:15:42    Maximum run time = 8.3400000000001
08.10.2018    0:15:42    Minimum run time = 8.2939999999999
В связи с тем что время вызова самой функции getQuoteLevel2 у меня получилось чуть ли не на порядок больше времени которое требуется моему скрипту на парсинг полученой таблицы (речь идет о стакане 10х10, для имитации деятельности осуществлялся двукратный доступ ко всем содержательнм полям) возник у меня вопрос.
Подскажите пожалуйста, порректно ли вообще измерять время на вызов функций квик подобным способом. Или "дерганье" их миллион раз подряд вызывает какие-то аномалии в работе квик?
QLUA, вопросы начинающих.
 
Еще дилетантский вопросик.
Перечитывал в очередной раз "Руководство пользователя QLua", сложилось такое впечатление что в талицах которые возвращает API QUIK ключи (названия параметров) всегда имеют строковый тип. Подскажите пожалуйста так ли это или я где-то что-то пропустил?
Речь только про таблицы которые возвращает (или присылает в коллбэк) сам терминал, не про вообще обьекты луа которые можно раскопать внутри луа-машинки.
QLUA, вопросы начинающих.
 
Цитата
Michael Bulychev написал:
В Lua все числа хранятся как double, соответственно целые числа до 2^53 хранятся без потери точности.
Спасибо.
Сплетни из гугла как обычно оказались сплетнями )))
Ну зато теперь точно уверен.
QLUA, вопросы начинающих.
 
Цитата
Enfernuz написал:
Надо понимать, что в Lua 5.1 нет понятия целого числа (Integer). Есть только Number, который маппится нативно на что-нибудь типа ptrdiff_t или double.
Это я как раз прекрасно понимаю. Тут нюанс в том что исходники QLua в отличие от исходников луа не раскрываются и прямой вопрос об их содержимом скорее всего будет проигнорирован поэтому я задал вопрос "вообще".
Что касается исходников Lua 5.1.5.
Код
// luaconf.h
#define LUA_NUMBER    double
typedef LUA_NUMBER lua_Number;

// lobject.h
/*
** Union of all Lua values
*/
typedef union {  
  GCObject *gc;
  void *p;
  lua_Number n;
  int b;
} Value;
Далее цитировать не буду, из того что я там накопал и наэкспериментировал сам вроде бы следует что лушный Number всегда хранится как Value.n
Value.b как ни странно равно 0 даже в том случае когда я в луа явно запихнул в этот Number число без плавающей точки и достаточно маленькое чтобы поместиться даже в byte.

Но я до конца в правильности своих выводов не уверен поэтому и задаю тут всякие дурацкие вопросы ))
QLUA, вопросы начинающих.
 
Цитата
BlackBoar написал:
сишный 8-битовый double
Очередная ачипятка, 8-байтовый разумеется.
Суть вопроса прежняя ))
QLUA, вопросы начинающих.
 
Возник очередной нубский вопрос. Какие максимальные значения может принимать тип Number?
Из документации и гугла однозначно понятно что для чисел с плавающей точкой используется сишный 8-битовый double.

По целочисленным наткнулся на ряд комментариев типа "может зависить от реализации луа".

Поэтому уточненный вопрос звучит так, какое максимальное допустимое целое число в луа-машинке QUIK?
Если такого рода вещи есть где-то в документации по QLua подскажите пожалуйста где именно, я не нахожу. А документация по луа "вообще" в свете комментариев "может зависеть от реализации" как-то не вызывает доверия ))
динамический заказ тиковых данных
 
Цитата
Антон (band) написал:
значит ds:close может нарушить работу других скриптов. и нет функции чтобы проверять закрыты ли подписки(после того как мы их открыли, другими скриптами)не плохо было бы проверять, а не закрыл ли другой скрипт мою подписку(или я его). но это реально ерунда тк такого в нормальных программах происходить не должно. (1 скрипт нарушает работу другого, закрывая получение данных)
Я бы очень хотел увидеть комментарий разработчиков по этому утверждению.
Допустим моделируемая ситуация такая. Сам я вручную фьючем (например) Si не торгую, в настройках у меня получения каких-либо данных по нему нет. Загрружается Скрипт1, "подписывается" на Si, работает. Загружается Скрипт2, "подписывается" на Si, что-то делает, закрывает подписку, завершается. И что в результате, Скрипт1 окажется тоже с закрытой подпиской или нет??
QLUA, вопросы начинающих.
 
Цитата
Ирина написал:
И зачем тогда этот OnStop()
1. Наш IsRun=false срабатывает хотя вы этого возможно не замечаете и поток мэйн останавливается "честно", квику не приходится его убивать.
2. Выше писал уже, можете сохранить все свои данные, освободить обьекты, сбросить логи, тд, тп. А при старте квика на следующее утро подгрузить все обратно. Для того и события же в общем то придумали  :smile:  
QLUA, вопросы начинающих.
 
В догонку, то что "Даже после перезагрузки компьютера при повторном включении QUIK у скрипта горит зеленая стрелочка" - так и быть должно. Ссылку уже потерял но тоже в одной из соседних тем есть ответ разработчиков, если закрыть квик с запущеным скриптом он перезапустится при запуске квика.
QLUA, вопросы начинающих.
 
Цитата
Ирина написал:
OnStop() не срабатывает при выключении QUIK. Даже после перезагрузки компьютера при повторном включении QUIK у скрипта горит зеленая стрелочка. В чем может быть дело?На кнопку "Остановить" реагирует правильно.
OnStop срабатывает. Но не срабатывает message если OnStop случился при закрытии квика. Почему не выяснял, это к разработчикам. То же самое и с OnClose. Если запустите логирование, увидите что события случаются и из них можно например данные по файлам сохранить. Я на днях приводил пример скрипта и лога в соседней теме.
https://forum.quik.ru/messages/forum10/message34120/topic3979/#message34120

Предполагаю что message уже просто в "никуда" уходит хотя и вызывается.
Воспроизведение ситуации с заменой инструментов в QUIK, как удобнее реализовать
 
Цитата
Sergey Gorokhov написал:
Можно приблизить момент замены инструмента.Это управляется настройкой в "Программа" - "Замена инструментов", параметр "За... дней о погашения"
Благодарю за подсказку, для воспроизведения то что надо.
Воспроизведение ситуации с заменой инструментов в QUIK, как удобнее реализовать
 
В процессе тестирования скрипта пару раз установил / разорвал соединение с сервером. Поскольку были устаревшие инструменты, квик при первом подключении предложил их заменить что и было сделано. Скрипт отработал (судя по логам) ожидаемым образом. Замену инструментов (да и вообще получениее каких либо торговых данных из квика) он никак не отрабатывал. Отрабатывалась как раз сторонняя система логирования (Р7) плюс создание интерфейса WinForms. Когда закрывал квик (при уже отключеном скрипте) квик завис, пришлось убить штатными средствами винды.

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

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

Каких-то еще способов есть/нет?
Синхронизация завершения main и OnStop, требуется ли
 
Цитата
Sergey Gorokhov написал:
Окно Версии компонентов, находятся в меню Система - О программе - Компоненты
Еще раз спасибо, нашел блудное окно ))
QLua.dll загружен хотя в терминале в котором я посмотрел точно нет луа скриптов и нет индикаторов. Насколько я понимаю этот модуль следовательно нужен чему-то еще в терминале и событие связанное с его выгрузкой без закрытия терминала и не наступит, так как-то?
Синхронизация завершения main и OnStop, требуется ли
 
Sergey Gorokhov, благодарю за разьяснения!
Sergey Gorokhov написал:

Цитата
А как Вам нужно?Если хотите чтобы OnStop был последний, верните из него таймер
Мне оно не нужно. Хотел убедиться что терминал ничего себе определенного в этом месте не подразумевает. Если терминалу все равно, просто "беру это себе на карандаш" и продолжаю заниматься своими делами ))
Синхронизация завершения main и OnStop, требуется ли
 
Дополнительный вопрос по OnClose. У меня по результатам прогона нескольких сценариев OnClose если случается то всегда до OnStop. Следует ли считать такую последовательность гарантированой? Исходя из общей логики того что они в одном потоке вроде должно быть именно так.
Lua и dll на C
 
Цитата
новичок написал:
позвольте Вам напомнить, что суть форума - обмен информацией. полезность и результативность сего процесса исключительно персонифицированы.
Никак не возражаю, наоборот вполне согласен. И позвольте в ответ отметить что я вполне конструктивно подкинул ссылку на русский вариант текста который многим может быть удобнее.


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

Все это исключительно мое личное мнение которое не отражает ничьей официальной позиции )))
Синхронизация завершения main и OnStop, требуется ли
 
И еще вопрос вдогонку. Есть событие OnClose, которое согласно описанию наступает

Цитата
Функция вызывается перед закрытием терминала QUIK и при выгрузке файла qlua.dll
Под выгрузкой файла qlua.dll подразумевается отключение плагина QLua в окне  «Версии компонентов и плагинов» (см. п. 1.9. Раздела 1 Руководства пользователя  QUIK).
У меня оно наступает только при закрытии терминала, при остановке сценария кнопкой не наступает. Окна которое бы называлось  «Версии компонентов и плагинов» я в квик 7.19.0.51 попросту не вижу, а Раздел 1 руководства пользователя квик это "подготовка к работе" и там нет никакой нумерации пунктов.
Скрипт которым тестировал (самый простой вариант):
Код
file = io.open("D:\\EventTest.log", "a+t")
IsRun = true

function WriteLog(s, ...)
    if file ~=nil then
        file:write(tostring(os.date()) .. " " .. string.format(s, unpack(arg)) .. "\n")
        file:flush()
    end
end

function OnClose()
    WriteLog("Entered OnClose")
end


function OnInit()
    WriteLog("Entered OnInit")
end

function OnStop()
    WriteLog("Entered OnStop")
    IsRun = false
end


function main()
    WriteLog("Entered Main")

    while IsRun do
        sleep(500)
    end;

    WriteLog("Leaving Main")
end
Фрагменты лога, если закрыть квик:
Код
09/30/18 07:03:50 Entered OnInit
09/30/18 07:03:50 Entered Main
09/30/18 07:03:53 Entered OnClose
09/30/18 07:03:53 Entered OnStop
09/30/18 07:03:54 Leaving Main
Если остановить скрипт кнопкой:
Код
09/30/18 07:04:00 Entered OnInit
09/30/18 07:04:00 Entered Main
09/30/18 07:04:14 Entered OnStop
09/30/18 07:04:14 Leaving Main
Для чистоты эксперимента все остальные скрипты были из квика удалены.

Итого вопрос, следует ли из этого что OnClose на самом то деле случается только при закрытии терминала, или я столкнулся с неизвестным ранее глюком, или я что-то не так понимаю в описании?
Lua и dll на C
 
Цитата
новичок написал:
https://eliasdaler.wordpress.com/2013/10/11/lua_cpp_binder/
https://habr.com/post/197300/
То же самое по-русски. Насколько я понимаю авторский перевод.

Для себя ничего особо полезного не увидел, очередное пособие как делать обертки, таких в инете на любой вкус. К ускорению взаимодействия с луа-движком этот путь не ведет.
Синхронизация завершения main и OnStop, требуется ли
 
Возник вопрос. Вполне вероятно он достаточно нубский, но однозначный ответ я не нагуглил и хочу для себя прояснить.
Допустим OnStop в моем сценарии выглядит как-то так:
Код
function OnStop(flag) 
  IsRun = false
  -- далее следуют какие то относительно продолжительные действия
  -- сохранение нажитого непосильным трудом по файлам например
  -- имитация таковых:
  sleep(50) 
end 
В результате main может прочитать что IsRun = false и завершиться до завершения OnStop.
Вопрос, следует ли мне всегда размещать IsRun = false в конце OnStop или можно не забивать себе такими нюансами голову?
проблема LuaRocks
 
Цитата
Enfernuz написал:
2) поместить все искомые модули в папки /lua (*.lua) и /Include (*.dll -- ещё можно в корень Quik'а кидать их, а для некоторых .dll не можно, а нужно) в дистрибутиве Quik.
Когда речь идет про квик а не какой-то движок луа вообще, это как мне кажется единственно правильная рекомендация )))
проблема LuaRocks
 
Цитата
Let_it_go написал:
Код
** In Windows, any exclamation mark ('!') in the path is replaced by the
** path of the directory of the executable file of the current process.
*/
#define LUA_LDIR   "!\\lua\\"
Если я правильно воспринимаю этот комментарий то при пути к интерпретатору луа например C:\Tools\Lua, LUA_LDIR будет развернуто в C:\Tools\Lua\lua. Причем уже во время исполнения а не компиляции.

Это если оставить
Код
#define LUA_LDIR   "!\\lua\\"
как есть.

Если будете все равно перекомпилировать исправьте на что вам удобно.
А то что в вашем посте выделено красным, #define LUA_LDIR   LUA_ROOT "share/lua/5.1/" - отноится к линух-системам. Вы же виндой пользуетесь?
dll против Луа. Странности
 
Цитата
BlackBoar написал:
видимо далее дорога купить исходники
Ачипятка, имелось в виду "курить исходники"

И Борис Гудылин, благодарю за коммент, подтвердили ход моих мыслей :)
dll против Луа. Странности
 
Цитата
Борис Гудылин написал:
А зачем Вам копировать в Сишный массив? Не возникало мысли работать с данными прямо по месту их нахождения?Есть, правда, некоторые трудности и даже опасности. Как минимум придется разобраться с устройством памяти в LUA, с ее динамикой и инфрастуктурой.Но оно стоит того. На моих таблицах и алгоритмах заработало примерно в 30 раз быстрее. Для меня это было жизненно необходимо.
1. Неудачно выразился, в рамках примера из этой темы разумеется ничего никуда копировать не надо. Надо именно найти прямое местонахождение данных для быстрейшего к ним доступа. В других каких-то случаях наверняка придется копировать для дальнейшей обработки / изучения и тд, но абсолютно согласен с тем что все равно первоочередная задача будет получить для начала прямой доступ к этим данным.
2. Мысль такая после обдумывания пришла. Как получить указатель на начало этих данных из документации накурил. Ничего кроме этого полезного там не нашлось, видимо далее дорога купить исходники. Развлекаюсь пока что чтением файла lobject.h.
В 30 раз быстрее даже больше чем я думал, есть за что побороться ))
dll против Луа. Странности
 
Еще вопрос вдогонку, допустим про таблицу Lua заранее известно что она представляет из себя аналог Сишного массива базового типа. В примере этой конкретно темы фактически int Array[20]. Так вот как ее бычтрее всего закопировать в Сишный массив чтобы дальше с ним уже работать традиционным образом?
Получать каждый отдельный элемент вызывая в цикле
Код
lua_rawgeti(L, 1, i);       
sum += lua_tonumber(L, -1);       
lua_pop(L, 1);
выглядит откровенно расточительно. Какие-то более эффективные способы есть? Сам не нашел пока...
dll против Луа. Странности
 
Цитата
Let_it_go написал:
Вот функция на Си++ внутри dll. Она принимает таблицу и выдаёт обратно в Луа сумму элементов этой таблицы
Код
static int forLua_SumArray(lua_State* L) {
   // Get the length of the table (same as # operator in Lua)
   int n = lua_objlen(L, 1);
   double sum = 0.0;
   // For each index from 1 to n, get the table value as a number and add to sum
   for (int i = 1; i <= n; ++i) {
      lua_rawgeti(L, 1, i);
      sum += lua_tonumber(L, -1);
      lua_pop(L, 1);
   }

   lua_pushnumber(L, sum);
   return 1;
}
Я ожидаю, что чем больше элементов будет в таблице, тем сильнее dll должна опережать аналогичные подсчёты в Луа.
Вот такого плана код на С++. Здесь каждая содержательная строчка производит ту или иную манипуляцию со стеком Lua. То есть, в моем представлении, такой код фактически будет исполняться на том же самом интерпретаторе Lua как если бы он был написан непосредственно на Lua. И его быстродействие должно всегда оказываться по порядку величины сравнимым с Lua. Если он вообще на сколько-то быстрее уже хорошо.
Я прав? (в луа мало что понимаю поэтому спрашиваю)
Поведение QUIK при ошибке "ключ не найден", Можно ли изменить.
 
Цитата
Zoya Skvorcova написал:
Система / Соединения у Вас отключено «Восстанавливать связь автоматически через ... секунд с ... до ...».
Точно, совсем вылетело из головы что настройки соединения не в одном месте собраны )))
Благодарю за подсказку, все именно так как вы написали.
Поведение QUIK при ошибке "ключ не найден", Можно ли изменить.
 
Сегодня в очередной раз столкнулся с "ключ не найден". Сам виноват, флэшку с ключем снова в другой разьем воткнул )))
Суть вопроса вот в чем. Квик от ВТБ при этом выдает сообщение один раз а потом просто бездействует. А квик от Открытия начинает выводить это сообщение каждые 2-3 секунды и чтобы поменять настройки приходится его перезапускать, иначе заматывает.

Можно ли как-то изменить его поведение чтобы один раз высказался и заткнулся или так уж брокер вбил и я ничего не могу сделать? В настройках ничего подходящего сам не нашел.
Установка QUIK на Linux под Wine, Проблемы с актуальными на сегодняшний день версиями
 
Цитата
Imersio Arrigo написал:
Использую арч, и текущий вайн. Не заморачиваюсь с понижением версии вайна. Вижу что глюков стало больше, но пока терпимо.
Больше всего раздражает пустой список торговых счетов на форме ввода заявки. Приходится при подаче заявки заполнять вручную. Раньше лечилось подменой commctl32.dll из winetricks. С недавних пор перестало.
Сейчас в ходе экспериментов обнаружил, с вайн 3.15 снова лечится. Тоже арч. Но, появляется новый еще худший глюк при подмене библиотеки. Когда пытаешься сохранить конфигурацию квик он выдает сообщение об ошибке и намертво виснет, приходится убивать  :lol:  :lol:  :lol:


А вообще в плане разгона производительности попробовал все способы какие нагуглил. В том числе запускал на отдельном Х сервере. Принципиальной разницы не заметил. Итого или я что-то упускаю или для иксов это предел.
Установка QUIK на Linux под Wine, Проблемы с актуальными на сегодняшний день версиями
 
Промежуточный результат.
1. Сравнивал 64 бит Арч и 32 бит Деб
2. Дрова в обоих случаях nvidia 390
3. Окружения Mate / Cinnamon / KDE Plasma
KDE и Cinnamon поотключал все эффекты / анимации / тд, Mate согласно рекомендации новичок, еще поставил Window manager = Marco (Compton GPU Compositor)


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


От смены DE на своем компе вообще не смог заметить разницы. Она наверняка где-то есть но я ее (применительно к квик) не смог увидеть ни визуально ни по показаниям системных мониторов.



Самое "узкое" место оказалась отрисовка графиков. Тех которые видны и действительно рисуются. Сколько при этом вообще окон в квике похоже не важно (у меня как было около 250 так с ними и экспериментировал). Картина примерно такая:
Нет видимых графиков - все летает как в винде и загрузка проца 1-2%
1 график - достаточно хорошо, загрузка проца раза в 3 больше чем в винде но не зашкаливает.

2 графика - тормоза
3 и больше - невозможные тормоза
При этом с одним графиком быстрее шевелиась 32 бит система, было почти как в винде.
С 2 и более графиками быстрее шевелилась 64 бит система.


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


И еще раз благодарю новичок за подсказки куда копать  :smile:
Установка QUIK на Linux под Wine, Проблемы с актуальными на сегодняшний день версиями
 
новичок,

еще раз спасибо за расширеные консультации, буду разбираться дальше. Направление понял.
Установка QUIK на Linux под Wine, Проблемы с актуальными на сегодняшний день версиями
 
Попробовал под вайном "настоящий" квик во время реальных торгов. Брокер если это как-то важно Открытие, "внутри" квик 35 вкладок с порядка 250 (процентов 40 графики остальное таблицы) окон, из них порядка 50 свернуты. Индикаторов всяких несущественное количество. Прогружается это все ненамного дольше чем в винде как выяснилось. Далее картина такая, при переключении вкладок отрисовка "тормозит" секунд до двух. Открыл вкладку на которой 2 графика + стакан + 2 таблицы текущих торгов. И еще 4 таблички вынесеные из основного окна на виду. Загрузка процессора оказалась 25%, фактически процесс info.exe полностью грузил одно из процессорных ядер. При попытке открывать контекстное меню в таблице текущих торгов задержка порядка секунды а вот в стакане какая-то нереально большая, до 10 секунд,

Для сравнения под виндой тоже самое проц грузит 5-10% (в среднем думаю можно сказать втрое меньше) и каких-либо задержек которые мог бы различить человек никогда не наблюдалось. Запускалось все с одного и того же SSD разумеется для чистоты эксперимента.

Использовались ядро 4.18, kde 5.13, драйвер nouveau. С драйвером nvidia 396 версии почему-то еще хуже все было. Видюха 970. Вайн 3.0.2 32 битный.



Я тут должен признать что еще ничего толком не настраивал потому что пока плохо представляю в каком направлении начинать. В связи с чем прошу консультацию тех кто квиком под линукс реально пользуется. Вижу пока такие направления:
Может стоит заменить kde на что-нибудь полегковеснее. Или перейти на что-то использующее gtk а не qt, на тот же гном?
Nouveau / nvidia, на каком лучше остановиться для именно квик?
И почему вообще так много процессорного времени жрет, с этим можно что-то сделать?
Установка QUIK на Linux под Wine, Проблемы с актуальными на сегодняшний день версиями
 
Цитата
Imersio Arrigo написал:
Похоже это в квике, и от вайна не зависит.
Мне пока не хватает квалификации понять что от чего именно зависит, тем не менее методом тыка нашел несколько конфигураций в которых ни один из глюков не проявляется вообще. В частности арч (все пакеты те какие pacman сейчас по умолчанию ставит) + отдельно поставленый вайн 3.0.2 (и ряд других версий тоже прокатывает).
Цитата
новичок написал:
https://gentoo.org/
Вспомнил этот дистрибутив  :lol: Он наверное очень хорош для тех кто уже знает чего хочет добиться. Но для тренировки имхо неудобный вариант, там при работе в виртуалке только ядро больше часа компилировать. Непродуктивно получится, слишком большие паузы при установке / переустановке чего бы то ни было.
Установка QUIK на Linux под Wine, Проблемы с актуальными на сегодняшний день версиями
 
Цитата
новичок написал:
http://www.linuxfromscratch.org/lfs/

https://gentoo.org/
В очередной раз спасибо, буду изучать.


Цитата
новичок написал:
на демьяне 9 32бит с вайн 3.0.2
1. норм
2. норм
3. не норм, но и на винде у людей оно не фунциклирует судя по форуму
У меня статистика по глюку 3 получается такая:
Windows 7 Enterprise SP1 x64 - Квики от ВТБ и здешний демо - глюков нет, квик от Открытия - есть глюк с кнопкой при вводе количества, ничего не делает.  Квики все одной версии.

Windows 10 (Enterprise LTSB 1607 х64) аналогично семерке
Под арчем с вайнами 3.1 и ниже глюков нет, квик пробовал только демо (вчера с десяток версий вайна между делом попробовал, в том числе заявляемую "стабильной" 3.0.2, вплоть до 2.10 картина в плане глюков одинаковая а более древние на текущей сборке арча уже сами по себе не запускаются)
На минт с вайном 3.0.1 глюк 3 наблюдался в полный рост (глючили все кнопки именно так как я в начальном посте описал). Но тут я должен признать что просто воткнул установку минта со всеми опциями по умолчанию в виртуалку и запустил посмотреть, не настраивал вообще ничего. Какая это сборка минт сейчас уже сходу не помню, самая свежая из тех что на дистровотче представлены.
В общем есть поле для изучения )))
Но лично меня пока устраивает найденое решение. Прямо сейчас вообще другими делами занимаюсь, буду изучать по мере наличия времени )))
Установка QUIK на Linux под Wine, Проблемы с актуальными на сегодняшний день версиями
 
Цитата
новичок написал:
попробуйте
debian 9 32bit
mate с отключенным композитором > apt install mate-tweak
для нвидиа > apt install nvidia-xconfig; nvidia-xconfig
wine 1.8.7 > apt install wine
ram disk
Спасибо за рекомендации.
Экспериментирую сейчас с арчем, не потому что считаю его чем-то лучше других а потому что идеология арча "собери сам все что тебе надо" для моих мозгов самое то чтобы разобраться что и как собирать.
Для работы обязательно попробую дебиан.
Установка QUIK на Linux под Wine, Проблемы с актуальными на сегодняшний день версиями
 
новичок,

спасибо за разьяснения, принято к сведению.

Цитата
новичок написал:
итого: играешь в комп - мучай комп, играешь в рынок - мучай рынок :)
Вообще согласен. Комп мучаю по остаточному принципу, ибо интересно но не срочно. Рабочая пока что Windows7 а там видно будет.
Установка QUIK на Linux под Wine, Проблемы с актуальными на сегодняшний день версиями
 
Цитата
BlackBoar написал:
Появился правда новый глюк, при выходе квик не сохраняет конфигурацию, приходится вручную сохранять если что изменил.
После непродолжительной медитации разобрался и с этим. Наиболее простым и к тому же предпочтительным с моей точки зрения решением оказалось запустить квик под альтернативным вайном без PlаyOnLinux'а. На всякий случай создал новый префикс, итого все работает, пока глюков не замечено.



Осталось исследовать вопрос скорости отклика программы. У тренировочного квика с ~30 окнами внутри отклик ничем не хуже винды. С тяжеловесными конфигурациями буду разбираться как время будет )))
Установка QUIK на Linux под Wine, Проблемы с актуальными на сегодняшний день версиями
 
Цитата
Imersio Arrigo написал:
Использую арч, и текущий вайн. Не заморачиваюсь с понижением версии вайна. Вижу что глюков стало больше, но пока терпимо.
Использую (точнее пока настраиваю) тоже арч. Но вот поведение квика в текущем вайне меня откровенно выбесило. Покрутил по вашему совету версии вайна под PlayOnLinux. С версиями 3.1 и ниже все глюки пропали, с 3.2 и выше присутствуют в полном обьеме. Появился правда новый глюк, при выходе квик не сохраняет конфигурацию, приходится вручную сохранять если что изменил. Врядли это глюк квика, похоже у меня не все что нужно установлено. Буду разбираться.

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


Цитата
Imersio Arrigo написал:
Если важна скорость и стабильность рекомендую поставить виртуалку с ХР. Летает в разы быстрее.
Изначально была и такая мысль. Но хотелось бы обойтись совсем без винды. Как будет время посравниваю скорости, до этого этапа еще не дошел.
Установка QUIK на Linux под Wine, Проблемы с актуальными на сегодняшний день версиями
 
Цитата
Imersio Arrigo написал:
По моим наблюдениям наиболее стабильно и шустро работает с версиями wine 1.6 - 1.9.
Можно использовать PlayOnLinux, и переключать вино там.
У меня с версиями вайн 1.7.52 и 1.8.4 продолжал наблюдаться глюк № 3 (косяки с работой кнопки ввода цены). Впрочем должен признать что экспериментировал "на скорую руку" почти ничего не настраивая. Другие версии из указаного Вами диапазона еще не пробовал.

В связи с чем поделитесь пожалуйста чуть конкретнее, какие версии пробовали Вы а также какой используете дистрибутив (и версии важных пакетов). Вопрос может несколько дурацкий но я пока не великий знаток линуха. Если не очень затруднит :)
Общую идею понял, спасибо за наводку.
Установка QUIK на Linux под Wine, Проблемы с актуальными на сегодняшний день версиями
 
Постановка задачи - чтобы QUIK работал полностью адекватно и без косяков.
Квик в экспериментах использовался только что скачаный отсюда, версия 7.19.0.51, для контрольных поппыток использовались завалявшиеся на диске старые дистры 7.5 и 6.17
Актуальной версией вайн видимо условно придется считать 3.1.4, во всяком случае в моем дистрибутиве так. Впрочем описаные ниже глюки абсолютно одинаково проявляются еще в нескольких версиях вайн новее 3.0.1


Получилось:
Поставил, запускается, в принципе работает. Шрифты и ключи вправились согласно нагугленым инструкциям, с этим нет затруднений.
Наблюдаемые глюки:
1. Не отображаются пиктограмки на кнопках информационного окна. Вообще, кнопки тупо пустые квадратики. С текстом в окне при этом все в порядке и нажимать на кнопки можно, работают.
2. Полностью пустые выпадающие списки в которых выбирать код клиента и торговый счет при постановке заявок и тп. Торговые счета в настройках актины (в правом стакане, это проверть не забыл). Таблички всякие со сделками, состоянием счета и тп при этом торговые счета и код клиента отображают штатным образом. А в окошке "новая заявка" и аналогичных если ввести счет и код вручную то заявка благополучно принимается. Но код в выпадающем списке даже так не сохраняется, только каждый раз вручную.
3. Не работает парная кнопка UpDown связаная с "количеством" в окошках ввода заявки и тп. Вообще ничего не делает. Это кстати и под Windows7 Enterprise также, да и судя по форуму не у меня одного. А кнопки UpDown связаные с вводом цены / стоп-цены / отступа и тп увеличивают значение в соответствующем поле не на шаг цены как должны а на какю-то странную цифру похожую на (max unsigned __int16) * (шаг цены).
При этом если нужное значение ввести в поле вручную опять же все работает.
Скрины выложу если требуется.

Описаные глюки выглядят одинаково в сборках "актуальный" Archlinux + wine 3.1.4 и "актуальный" Suse + wine 3.0.7 (Suse почему-то пишет что версия вайна 3.7, поскольку такой еще пока не существует думаю что 3.0.7 на самом деле.
DE пробовал KDE, GNOM, LXDE - все одинаково

Дальнейшие эксперименты показали следующее:
Если поставить квик 7.5 или 6.17 (других старых у меня нет) то глюк 2 и судя по всему глюк 3 пропадают, но глюк 1 все равно присутствует. Полностью проверить не знаю как, к серверу то эти версии без обновления подключаться не хотят.

С актуальной (7.19) версией квик и предыдущими версиями вайна:
"актуальный" Mint + вайн 3.0.1 - глюк №2 исчезает, глюк №3 остается.
разные сборки с вайн 2.х/1.8/1.7 - то же самое, глюк №3 присутствует

сборка OpenSuse 12.3 / wine 1.5.23 / qt4 / kde4 = сюрприз, не проявляется ни один из описаных глюков! В том числе корректно работает кнопка выбора количества (которая у меня даже под виндой сейчас косячит).

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

И дополнительный вопрос. Скорость отклика и вообще шевеления под вайном конкретно хуже чем под виндой. Это разумеется вопрос больше для других форумов, но может кто сталкивался настраивать вайн и прочее именно для квик, на что обратить внимание.
Страницы: Пред. 1 2
Наверх