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

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

Страницы: 1 2 3 4 5 6 7 8 9 След.
Медленный вывод в таблицы QLua через SetCell
 
Ясно. Спасибо за попытку.
Медленный вывод в таблицы QLua через SetCell
 
Выскажу гипотезу, почему так получается с низкой скоростью отрисовки, и немного порассуждаю. Возможно, что я не прав.

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

Можно как-то снижать затраты на синхронизацию. Например, если бы была удобная возможность дать из потока main задачу для исполнения в потоке коллбэков, можно было бы реализовать отрисовку таблицы большим блоком, который выполнился бы быстрее, чем куча мелких задач. Что-то типа executeAsCallback на этом форуме уже обсуждали (https://forum.quik.ru/messages/forum10/message50396/topic5983/#message50396)

Но если просто починят SetCell, чтобы эта и, возможно, аналогичные функции стали существенно быстрее, тоже будет хорошо.
Медленный вывод в таблицы QLua через SetCell
 
Спасибо за ответ.

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

Когда я писал про повышенную нагрузку на CPU, то имел в виду, что процесс терминала QUIK загружает ПО МАКСИМУМУ одно ядро процессора, хотя современное железо должно справляться с такой интенсивностью вывода на экран с меньшей нагрузкой. Я не знаю, сколько ядер в машине, на которой сделаны прилагаемые скриншоты, но 11.2% уже близко к границе для 8-ядерного компьютера (100% / 8 ядер = 12.5%).

Предлагаю считать, что если разобраться с медленной отрисовкой, то и проблема, которую я обозначил как повышенная нагрузка на CPU, будет решена.
[BUG] Повышенная загрузка CPU при большом количестве функций в скрипте
 
Просьба к разработчикам терминала написать адекватные ответы на вопросы, поднятые по существу этой темы.
Медленный вывод в таблицы QLua через SetCell
 
Я видел, что как минимум 2 представителя "Арки" читали эту тему. Хотелось бы увидеть ответ на заданный вопрос.
Откуда лучше взять тиковые данные в Lua?
 
Первый ответ на Ваш вопрос в теме был корректным.

ТТТ -- это аббревиатура от "Таблица текущих торгов".
Обезличенные сделки в квике
 
Вам была продемонстрирована наглядная иллюстрация качества работы техподдержки.
Медленный вывод в таблицы QLua через SetCell
 
При использовании приведённых ниже демонстрационных скриптов наблюдается повышенная нагрузка на CPU и медленный вывод содержимого в таблицы QLua. При этом вывод в заголовки окон этих таблиц производится нормально. Просьба проверить оптимальность реализации отрисовки содержимого таблиц. Используется светлая тема терминала 9.3.3.3, на тёмной не проверялось, наверное, ещё хуже будет.

В течение 7 дней можно скачать нужные демо-файлы по ссылке: https://dropmefiles.com/cNAAw  Описание приводится ниже.

Файлы RunDemo1.lua, ...m RunDemo9.lua каждый имеет свои настройки и запускают общий файл Demo.lua. Каждый скрипт выводит окно и периодически с некоторым таймаутом, заданным в Demo.lua, обновляет свою таблицу на экране. Скрипты надо запускать одновременно.

Просьба к разработчикам ответить на вопрос: считается ли такая скорость отрисовки нормальной или её стоит оптимизировать?

Файл Demo.lua:
Код
---
--- Настройки заданы в переменной config, которая к моменту запуска уже определена.
---

local interrupted = false
local tableId
local timeout = 20 -- можно уменьшать, чтобы проблема стала более явной
local nRow = 30 -- количество строк в таблице, можно увеличивать, чтобы проблема стала более явной
local nCol = 10 -- количество столбцов в таблице, можно увеличивать, чтобы проблема стала более явной

function OnInit(scriptPath)
    tableId = AllocTable()
    for colId = 1, nCol do
        AddColumn(tableId, colId, "#" .. colId, true, QTABLE_STRING_TYPE, 20)
    end
end

function OnStop()
    interrupted = true
    local tId = tableId
    tableId = nil
    if tId then
        DestroyTable(tId)
    end
end

function updateTable()
    if tableId == nil then
        return
    end
    if IsWindowClosed(tableId) then
        CreateWindow(tableId)
        SetWindowPos(tableId, config.x, config.y, config.dx, config.dy)
        for rowId = 1, nRow do
            InsertRow(tableId, rowId)
        end
    end
    local dt = os.date(" %Y-%m-%d %X", os.time())
    SetWindowCaption(tableId, config.name .. dt)
    for rowId = 1, nRow do
        for colId = 1, nCol do
            SetCell(tableId, rowId, colId, dt)
        end
    end
end

function main()
    while not interrupted do
        updateTable()
        sleep(timeout)
    end
end



Файл RunDemo1.lua:
Код
---
--- Этот скрипт нужно запустить.
---

config = {
    name = "RunDemo1",
    x = 0,
    y = 0,
    dx = 1400,
    dy = 100,
}
dofile(getScriptPath() .. "/Demo.lua")

Файл RunDemo2.lua:
Код
---
--- Этот скрипт нужно запустить.
---

config = {
    name = "RunDemo2",
    x = 0,
    y = 100,
    dx = 1400,
    dy = 100,
}
dofile(getScriptPath() .. "/Demo.lua")

Содержимое файлов 3-9 аналогично, отличаются только y-координаты окна.
[BUG] Повышенная загрузка CPU при большом количестве функций в скрипте
 
Цитата
Упомянутый код демонстрирует проблему в QUIK 9.3.1.11. В QUIK 9.3.3.3 QLua 5.4 эта конкретная проблема устранена.
Это хорошо. Полагаю, что разработчики это тоже подтвердили бы, если бы провели разбор проблемы качественно.

Цитата
...  если в колбеках, есть обращение к функциям API QLua, то все запущенные  скрипты рабочего места QUIK, могут выстраиваться в очередь к  синхронизуемым ресурсам QUIK (по которым в ранних версиях QUIK, возможно  синхронизации вообще не было), что эквивалентно их работе в одном  потоке.

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

Цитата
Правильно я понимаю, что у Вас три терминала КВИК работают и каждый сделал по 12 потоков, а у Вас всего 8 ядер ?

Нет. В процессоре всего имеется 8 ядер. Каждый из 3-х терминалов грузит полностью одно ядро процессора (архитектура терминала такая). Дополнительная нагрузка собственно от Lua минимальна. Основная беда, похоже, с тем, как отрабатывают функции QLua, заставляющие терминал что-то отрисовывать. Что-то там внутри терминала с синхронизациями при доступе к общим ресурсам не так. Пока неясно, как бы это в явном виде продемонстрировать.
[BUG] Повышенная загрузка CPU при большом количестве функций в скрипте
 
Для снижения нагрузки на терминал пришлось позакрывать все свечные графики (порядка 8 штук), собрать все инструменты в одну ТТТ, выключить там цветовые настройки, а также закрыть стаканы. Кажется, что несколько легче стало. Выходит, что отрисовка графики дополнительно сильно замедляет работу (похоже, что есть там какое бутылочное горлышко в виде одной общей очереди на всё). Трудно обеспечивать тысячи сделок в течение торгового дня.
[BUG] Повышенная загрузка CPU при большом количестве функций в скрипте
 
Дополню, что при этом нагрузка на ядро процессора (i7-9700K) максимальная (100% / 8 ядер = 12.5%).
[BUG] Повышенная загрузка CPU при большом количестве функций в скрипте
 
Daniil Pozdnyakov, плохо, что не нашли причину. Конкретно в последние 2 дня из-за большой активности торгов на рынке у нас терминалы 9.3.3.3, где запущено много скриптов, тормозят: время сервера внизу в статус строке отстаёт от реального времени на несколько секунд. Ненормально это.

Вам же даже код привели, который демонстрирует проблему.
https://forum.quik.ru/messages/forum10/message60158/topic6953/#message60158

Настоятельная просьба провести изучение более внимательно с использованием реалистичных нагрузок.
Установка QUIK на Linux под Wine, Проблемы с актуальными на сегодняшний день версиями
 
Цитата
отсутствие linux версии Quik говорит лишь об адекватности кодеров в ARQA, ну или менеджмента хотя бы :)

Отсутствие линукс-версии терминала говорит о том, что не хватает ресурсов у разработчиков на это. Выбрали бы в самом начале разработки терминала язык Java -- имели бы кроссплатформенный вариант сегодня, правда непонятно с каким качеством.
Цитата
- сам Линус сотрудник Intel
Дезинформация. Вот инфомация из Википедии.

С 1997 по 2003 год Линус работал в известной компании Transmeta. После этого организовал Open Source Development Labs. В данный момент работает в The Linux Foundation (с 2007), где занимается разработкой ядра Linux.
Установка QUIK на Linux под Wine, Проблемы с актуальными на сегодняшний день версиями
 
На мой взгляд, актуальный терминал и под Windows работает так себе в смысле производительности для конкретно моих задач, связанных с алготрейдингом через lua-скрипты.

Под Wine 6.0.2 терминал как-то работает (с некоторыми глюками) и ещё более заметным падением производительности, из-за которого мне не удалось перейти на Linux с Windows в трейдинге. Может, Wine 7 как-то улучшит ситуацию (ещё не пробовал под ним запускать).

Антон выше прав, что наиболее реально -- это (попробовать) собрать терминал под ARM-версию Windows. Остальное нереально, у "Арки" нет на это ресурсов.

Жаль, что достойный конкурентов терминала нет на российском рынке, может от этого повысилось бы качество.
Как из скрипта открыть окно на нужной вкладке?
 
Никак, но пожелание такое уже регистрировали, скорее всего.
[BUG] Повышенная загрузка CPU при большом количестве функций в скрипте
 
Очень хочется увидеть ответ от разработчиков по поводу изучения данной проблемы, хотя бы после новогодних праздников. Ниже описывается пример, как большое количество таблиц может появляться в реальной программе.

Предположим, что скрипту нужно хранить в памяти для работы 3000 свечей (сколько отдаёт сервер при запросе данных по ликвидным инструментам) по 10 инструментам и 5 таймфреймам. Время свечи QLua отдаёт в виде таблицы

Код
datetime = { year = 2021, month = 12, day = 30, hour = 11, min = 0, sec = 0, ms = 0, mcs = 0, ... }

Соответственно, сразу же имеем 3000 * 10 * 5 = 150 000 таблиц. А если скриптов несколько, то можно ещё на порядок увеличить количество таблиц в памяти.

Конечно, конкретно здесь можно закодировать дату в виде строки "2021-12-30T11:00:00.000" или вообще числом 20211230110000000 для эффективности, но придётся писать код для выделения из этого числа отдельных полей, и арифметика даты/времени станет неудобной.

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

Если уже сейчас имеется способ запуска терминала под какого-то рода отладчиком с профилированием, тогда дайте знать, как это сделать. Для java есть, к примеру visualvm с мониторингом кучи, тредов, сборщика мусора и профилированием.
Таблица сделок, номер заявки превращается в число e+
 
Вместо string.format() используйте tostring(), чтобы не портилось 19-значное целое число.
Отладка QUIK 9.3
 
Сделал такой тест на Windows и под эмулятором Wine:

Код
function main()
    message("Started at " .. os.date(), 1)
    local count = 0
    for i = 0, getNumberOf("all_trades") - 1 do
        local item = getItem("all_trades", i)
        if item then
            count = count + 1
        end
    end
    message("Ended at " .. os.date(), 1)
    message("Count = " .. tostring(count))
end

Получились такие результаты: при 1.55 млн. обезличенных сделок Windows отрабатывает за 9 секунд, а Linux за 22 секунды, что приемлемо для вызова getItem(). А вот почему в 10 раз медленнее исполняется полный скрипт -- пока непонятно.
Квик выдает не правильное направление сделки в таблице всех сделок на срочном рынке
 
Цитата
Старатель написал:
Цитата
Александр написал:
я уже пытаюсь 7 недель выяснить
Это легко сделать самостоятельно, отправив рыночную заявку и проверив направление вашей сделки в ТОС.
Я вчера тоже хотел эту мысль в качестве ответа написать, а потом по предоставленным автором темы файлам понял, что расхождения весьма нечастые. Дорого будет так проверять.
Отладка QUIK 9.3
 
Ради интереса запустил QUIK 9.3.3.3 под эмулятором Wine (winehq stable 6.0.2) в виртуалке Ubuntu 21.10. Увидел, что медленно работает скрипт экспорта биржевых данных, причём та его часть, которая из тиков, накопленных за несколько часов с начала торговой сессии, в оперативной памяти формирует свечные данные. Ввода-вывода в этом фрагменте кода вообще никакого нет. Скорость в одном из замеров примерно в 10 раз медленнее, чем в случае Windows на аналогичном по скорости процессоре. Как мне кажется, это указывает на какое-то совсем тормозное место внутри терминала, которое в эмуляторе совсем проседает.

В коде в цикле по всем обезличенным сделкам есть обращение к функции getItem:
Код
for i = 0, getNumberOf("all_trades") - 1 do
     local item = getItem("all_trades", i)

редкое обращение к getSecurityInfo(classCode, secCode).lot_size, результаты которого кэшируются, а в остальном идёт работа с оперативной памятью (много таблиц, представляющих собой свечные данные 1-минутного таймфрейма по всем тикерам из классов акций (Т+2) и фьючерсов (без опционов)).

Код функции, которая работает медленно, ниже.
Скрытый текст
[BUG] Повышенная загрузка CPU при большом количестве функций в скрипте
 
Цитата
Daniil Pozdnyakov написал:
Цитата
Старатель написал:
Демонстрационный скрипт:
    Скрытый текст        
Код
      local   n   =     50000  
  for   i   =     1  , n   do  
  _G[  "f"    ..  i]   =     function   ()   end  
  end  

  local   class   =     "SPBFUT"  
  local   sec   =     "SiZ1"  
  local   param   =   {"BIDDEPTHT",  "OFFERDEPTHT" }

  local   run   =     true  
  function    OnStop ()
  run   =     nil  
  end  

  function    main ()
  assert(  Subscribe_Level_II_Quotes  (class, sec))
    for   i   =     1  ,   #  param   do  
    ParamRequest(class, sec, param[i])
    end  
    while   run   do     sleep  (  500  )   end  
    Unsubscribe_Level_II_Quotes  (class, sec)
    for   i   =     1  ,   #  param   do  
    CancelParamRequest(class, sec, param[i])
    end  
  end  

  function    OnQuote (class_code, sec_code)   end  
  function    OnParam (class_code, sec_code)   end  
  function    OnAllTrade (alltrade)   end      
 
QUIK 9.3.1.11, Lua 5.4
Открыто, как минимум одно окно: стакан ликвидного инструмента.
Конечно, никто не запускает скрипты с тысячами функций, но при нескольких запущенных скриптах с десятками функций при высокой активности на бирже получаем нихилую загрузку CPU.

ЗЫ: У кого "один скрипт на все случаи жизни" с парой функций, может игнорировать эту тему.
Без флуда!

Здравствуйте!
Ваше письмо получено, проблема изучается. Постараемся в ближайшее время дать ответ.

Подскажите, занимаются ли разработчики терминала сейчас этой проблемой или пока есть более приоритетные задачи? Интересует, по крайней мере, диагноз: удалось ли уже увидеть проблему производительности в этом нагрузочном тесте?
[BUG] Повышенная загрузка CPU при большом количестве функций в скрипте
 
Цитата
TGB написал:
Цитата
Старатель написал:
Имеет ли этот пункт отношение к обсуждаемой здесь теме?
   Тест комментария 55 в QUIK 9.3.3.3 (QLua 5.4) выполняется столько же как и в QUIK 8.13.1.16 (QLua 5.4)
Если производительность вернулась, то это хорошо. Значит представители "Арки" в курсе проблемы, но не сознались.

Вспоминается шутка про проприетарные форматы файлов. Их спецификации не раскрывают не потому, что там есть какие-то секретные ноу-хау, а потому, что стыдно.
[BUG] Повышенная загрузка CPU при большом количестве функций в скрипте
 
Уважаемая техподдержка, с вашей стороны уже очень некрасиво выглядит долгая реакция на адекватные сообщения в этой теме.
Отладка QUIK 9.3
 
Новая версия вышла.

ftp://ftp.quik.ru/public/updates/9.3/quik_9.3.3_upd.zip

Изменения:

Медленная работа Рабочего места QUIK в некоторых случаях при запуске или во время работы.
Некорректное построение таблицы котировок в некоторых случаях.
[BUG] Повышенная загрузка CPU при большом количестве функций в скрипте
 
Интересно, почему до сих пор техподдержка никак себя не проявила в этой теме? В заголовке ведь явно указано [BUG]. Похоже, придётся специальную тему в "Пожеланиях..." создать для ускорения реакции.
[BUG] Повышенная загрузка CPU при большом количестве функций в скрипте
 
Деградация производительности мешает утром, когда происходит подключение к срочному рынку и заново приходят все обезличенные сделки с вечерней сессии. Если скрипты реагируют на соответствующие коллбэки и скриптов много, то происходят жуткие тормоза даже на современном железе. Конкретно у меня, несмотря на то, что реакция на обезличенные сделки минимальная, обезличенные сделки прогружаются минут десять с включенными скриптами и раз в 10 быстрее с выключенными. Судя по загрузке процессора (Core i7 9700K), упираемся именно в него. Уверенность в том, что в терминале есть какая-то жуткая неэффективность в этом месте, почти стопроцентная.

Убедительная просьба к техподдержке донести до разработчиков информацию по данной проблеме. Старатель предоставил описание тестового стенда, который даже на QUIK Junior демонстрирует деградацию производительности терминала в 2 раза по сравнению в более ранними версиями.
[BUG] Повышенная загрузка CPU при большом количестве функций в скрипте
 
Проверил у себя на компьютере. Вот 3 картинки: до запуска скрипта, после запуска скрипта и после запуска скрипта, где размер массива ещё увеличен в 10 раз. Видно, что загрузка процессора вырастает до максимума.

Просьба к техподдержке передать информацию разработчикам и написать соответствующее сообщение в этой теме.



 
[BUG] Повышенная загрузка CPU при большом количестве функций в скрипте
 
Думаю, что очень актуальный вопрос поднят. Спасибо топик-стартеру за демонстрацию проблемы. От разработчиков терминала ждём пояснений.
Основные библиотеки для QLua 5.4.1
 
Перевыложил: https://dropmefiles.com/Xxi8c
Баг - объём на последней минутке задваивается.
 
У меня есть вот такое объяснение, почему описанная проблема возникает.

У терминала есть свечной график за прошлый день. При подключении к серверу с утра в терминал приходят данные по обезличенным сделкам вчерашней вечерней сессии на срочном рынке. При этом терминал начинает обновлять свечи, но делает это "интеллектуально": при поступлении очередной обезличенной сделки, если она не относится к последней свече, он пропускает её (считает, что уже не надо использовать эту информацию), а вот про последнюю свечу терминал не может сказать, учтены данные или нет. По этой причине последняя свеча, всё-таки, обновляется. На ценовой рейндж H - L это не влияет, значение C станет опять правильным, когда все обезличенные сделки пройдут. Страдает только объём, который, понятное дело, удваивается.

Если такое объяснение корректно, то долгие разборки разработчиков с данной проблемой означают, что в текущей архитектуре приложения нельзя устранить такую неполадку.
Как запретить брокеру изменять настройки quik?, Обезличенные сделки
 
Как будто у вас файл, куда записываются настройки -- это не тот файл, откуда они потом читаются. Проверьте, что у вас прописано в Настройках клиентского места: Программа - Файлы настроек. Либо файл с настройками read only. Брокер ни при чём, поверьте.
Отладка QUIK 9.3
 
Вот пример загрузки CPU, которую process explorer выводит. При этом процессор Intel Core i7-9700K слабым не назовёшь, а загрузка ядра близка к максимуму 12.5%
 
Отладка QUIK 9.3
 
Ещё вижу повышенное использование процессора в QUIK 9.3. Не подскажет ли кто, как можно при работающем терминале понять, что именно забирает на себя ресурсы CPU? Типа какого-то профилировщика запустить?

Я могу, конечно, пытаться наугад действовать: закрыть наименее нужные окна (стаканы, ТТТ), снизить интенсивность вывода скриптами данных в таблицы, созданные QLua, но хотелось бы "не блуждать в потьмах".

Со своей стороны заметил, что есть "узкое место" с выводом данных в таблицы, созданные QLua. Как будто внутри терминала избыточная синхронизация в этом месте. Причём заголовок окна обновляется быстро, а содержимое таблиц -- медленно (при специальном нагрузочном тесте). Я уже снизил количество строк в таблицах и интенсивность вывода, но, похоже, что всё равно затык в этом месте. Для ориентира по нагрузке: в терминале открыто 45 окон (обычные и созданные QLua).
Основные библиотеки для QLua 5.4.1
 
Согласен с написанным выше. Не жду ничего особенно ни от lua, ни от разработчиков терминала. Антон правильно сказал в другой теме:
https://forum.quik.ru/messages/forum10/message59543/topic6791/#message59543
Основные библиотеки для QLua 5.4.1
 
Всё-таки, хотелось бы и ssl добавить в эту сборку, т.к. он много для чего нужен (почта, телеграм, зашифрованная передача по сети). Если кто уже собрал или может собрать luasec для 5.4, поделитесь результатом.
Как часто у вас вызывается DataSource:Callback?
 
Обновление свечей происходит с некоторой частотой, которая зависит от многих факторов. Если активность на рынке повышенная, то отдельные сделки "слипаются" в одно обновление свечи.
Отладка QUIK 9.3
 
При большом количестве открытых окон и запущенных скриптов терминал через несколько дней после запуска потребляет много памяти и тормозит при прокачивании данных после смены даты торговой сессии. Сравниваю с 8.13, где были те же самые настройки и условия эксплуатации.
Основные библиотеки для QLua 5.4.1
 
Попробовал скомпоновать всё, что было выше, в одну кучу. Добавил dkjson.lua для работы с JSON. Добавил исполняемые файлы из LuaBinaries версии 5.4.2 (считаем, что с квиковской 5.4.1 есть совместимость).

К сожалению, SSL пока нет.

Архив с файлами можно в течение 14 дней скачать по ссылке: https://dropmefiles.com/3gLxR

Предполагается такой способ установки на компьютер:
1) Распаковать содержимое архива в папку D:\LuaForQuik
2) Прописать в своих скриптах пути package.path и package.cpath (более подробно ближе к концу процесса напишу).

Использовать можно как из терминала, так и запуская lua54.exe.

Тестов для проверки пока никаких не проводил.
Основные библиотеки для QLua 5.4.1
 
Спасибо за информацию.

Судя по конфигу https://github.com/brunoos/luasec/blob/master/luasec.vcxproj там, тоже версия 5.1 и 32-битный вариант.
Основные библиотеки для QLua 5.4.1
 
Nikolay , у Вас в репозитории есть вот такой архив: https://github.com/nick-nh/qlua/blob/master/lua_socket_ssl/lua_socket_ssl.zip

Есть ли там файлы, из которых можно работающий SSL получить для QLua 5.4? Если можно, то какие файлы нужно брать? Для версии 5.3 у меня были файлы: ssl/https.lua, ssl.lua, ssl.dll, ssl.lib.

В идеале, лучше бы вот отсюда https://github.com/brunoos/luasec сборку сделать. Жаль не умею.
Основные библиотеки для QLua 5.4.1
 
Цитата
swerg написал:
https://quik2dde.ru/viewtopic.php?id=293
Что-то выложено, что-то по запросу.

Цитата
Тем более, что особых усилий прилагать не надо, просто в одном месте собрать и "причесать".

Когда усилия прилагает другой - да, особых не требуется.
Спасибо, что выложили у себя на сайте. Думаю, что многие будут благодарны Вам за это. Да и реклама разработчика неплохая.
Основные библиотеки для QLua 5.4.1
 
Цитата
Anton написал:
Цитата
_sk_ написал:
возможность сделать нормально
появится в обозримом будущем, надеюсь. Так-то проект где-то валяется, но надо же куда-то залить, чтобы не исчезло через неделю.
Логично было бы на GitHub какой-нибудь.
Основные библиотеки для QLua 5.4.1
 
Цитата
Anton написал:
Цитата
Nikolay написал:
luasocket сборка есть здесь
Посмотрел, она как-то собрана странно, вместе со всем луа. Работать-то должна, но я б так не сделал.
Если есть возможность сделать нормально, сделайте, пожалуйста.
Основные библиотеки для QLua 5.4.1
 
Спасибо!
Основные библиотеки для QLua 5.4.1
 
Судя по ответу разработчиков QUIK
https://forum.quik.ru/messages/forum10/message59594/topic5823/#message59594
пользователям QLua имеет смысл перейти на версию 5.4.1, которая более корректно работает по сравнению с версией 5.3.5. При этом пользователи, использующие популярные внешние библиотеки, будут вынуждены как-то подправить код и найти новые версии этих библиотек (на языке Lua или скомпилированные под 64-битную версию Windows 10/11).

У меня есть просьба к тем представителям сообщества, кто уже успешно осуществил такой переход: давайте сделаем что-то типа небольшого дистрибутива, который будет в открытом доступе (GitHub ???), и откуда можно будет скачать эти библиотеки и относительно просто подключить для использования в терминале QUIK (скажем, положив внутрь папки с терминалом в подпапку типа lua54libs).

Судя по вопросам, обсуждавшимся на форуме, в состав такого дистрибутива имеет смысл включить:
socket для работы с сокетами;
luasec для ssl;
какие-то библиотеки для работы с SQL;
какие-то библиотеки для реализации графического интерфейса типа iup.

Если есть ещё какие-то полезные библиотеки, напишите в этой теме.

Ещё раз подчеркну, что этот дистрибутив был бы полезным не только для программистов, но и для рядовых пользователей, которые не владеют навыками сборки в Visual C++ из исходников.

Конкретно про себя скажу, что мне в своё время нужна была только библиотека socket и файл core.dll, который у меня есть для версий 5.3 и 5.4. Версию для 5.3 я брал отсюда:
https://github.com/finsight/QUIKSharp/tree/master/src/QuikSharp/lua/clibs64­
а версию для 5.4 мне скомпилировал Anton
https://forum.quik.ru/user/1222/
спасибо ему!

Кто что думает? Реально ли такое сделать для всеобщего блага? Тем более, что особых усилий прилагать не надо, просто в одном месте собрать и "причесать".
Кривые шибки в QLua
 
С точки зрения пользователя, наверное, проще перейти на Lua 5.4 и успокоиться.  Возможно, что ошибка не устраняется или устраняется очень трудоёмко в  рамках того, что было сделано для встраивания Lua 5.3 в терминал. Надо  только используемые внешние библиотеки под версию Lua 5.4 найти.
Отладка QUIK 9.3
 
Новая версия QUIK для отладки:
ftp://ftp.quik.ru/public/updates/9.3/quik_9.3.1_upd.zip

Некоторые из доработок:

После первичной установки QUIK из дистрибутива и запуске LUA скриптов по умолчанию теперь используется версия LUA 5.4.1.

Ошибка в работе функции SetUpdateCallback QLUA, приводящая к чрезмерному потреблению памяти.

Некорректное отображение значений в подсказке параметров свечи в левом верхнем углу графика.

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

При замене заявки снимался признак «Заявка маркет-мейкера».

Аварийное завершение работы терминала при добавлении двух криптопровайдеров.

Некорректный расчет значения поля «max» на форме ввода заявки для маржинальных инструментов при установленном признаке «Исходя только из собственных средств»

В некоторых случаях в таблице «Клиентский портфель» некорректно рассчитывался параметр «Стоимость портфеля».

В таблице «Купить/Продать» некорректно отображались дисконты по фьючерсным контрактам.
Кривые шибки в QLua
 
https://forum.quik.ru/messages/forum10/message8885/topic962/#message8885
Кривые шибки в QLua
 
Цитата
TGB написал:
Цитата
Старатель написал:
Абсолютно беспочвенное утверждение, говорящее об отсутствии понимания работы обсуждаемого кода.
  Вы имеете ввиду, что для записи и чтения в очередь используются свои указатели и, я бы с вами согласился, если бы не существовал общий объект, в котором это происходит (таблица хранения очереди в которую вставляются и из которой вычеркиваются элементы очереди). Вы уверены, что работа с таблицей при изменении ее структуры в Lua реализована потокобезопасно? Где это написано?
Разработчики ARQA, как я помню, утверждали с самого начала, что примитивные переменные и таблицы Lua не портятся при параллельном их изменении из разных потоков с помощью атомарных операций присваивания. Другое дело, что для таблиц это на самом деле может быть не так. Функции типа table.sinsert, table.sremove и т.п. пришлось вводить, т.к. они не атомарные и занимаются сдвигом внутренних элементов. Все ли подобные неатомарные штуки были "выловлены" разработчиками ARQA -- неизвестно. Если не все, то единственный адекватный вариант -- это создавать структуру в потоке коллбэков, потом table.sinsert, а в main-потоке делать table.sremove.

Теперь про "пропажу" функции pop(). Не исключаю, что время от времени терминал QUIK или операционная система занимаются неким "переносом данных внутри своей памяти" (например, при сборке мусора) во время которого оказывается, что функция pop ещё не определена (не успели её перенести) в новом месте, а её вызывают из другого потока. Но это уже мои домыслы.
Страницы: 1 2 3 4 5 6 7 8 9 След.
Наверх