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

     К "новичку" вопросов и возражений нет. Это явление природы. Но, природа, к сожалению, часто ошибается.

Вопросы к поддержке QUIK:

1.    У вас "новичок" является внештатным сотрудником ARQU?

2.    А если это не так, то зачем вы тут (на форумах ARQU) его держите?

1.    Это общая проблема для всех тех, кто использует скрипты QLua (возможно??, за исключением тех, кто вообще не использует служебные функции QLua).

2.    Это порождает «плавающие», случайно возникающие ошибки в QLua-скриптах.

------------------------------------------------------------------------------------

Письмо, посланное мною в поддержку QUIK 05.10.20.

   Новая версия (от 05.10.20 ) QUIK 8.9.0.107 продолжает «падать» ( CQ02750791, CQ02779753, CQ02787899. CQ02802279) (CQ02809006)

Здравствуйте!  Посылаю вам дамп.  С помощью посланной 15.08.20 вам мною моей программы, вы можете получать этих дампов столько, сколько захочете.
Кроме того, наблюдается утечка памяти.

---------

Ответ поддержки.

Добрый день.
   
    Проблемой занимаемся, если будут дополнительно вопросы, то мы     сообщим.
    Извиняемся за долгий разбор, постараемся ответить, как можно скорее.

Андрей написал:
Воспроизводится в 8.5.2 и 8.6. До версии 8.5 данной проблемы не было.

----

Андрей написал:
тоже падает (Critical error ACCESS_VIOLATION).  

----

Евгений Петров написал:
на версии 8.6.097, проблема с general protection fault с версии 8.5 никуда не исчезла! Продолжает валиться квик на рабочих lua скриптах с версии 7.27.1. Произвольно, иногда при запуске сразу, иногда через небольшое время.

--------------------------------------
    Не буду утверждать стопудово, но многие ситуации в версиях QUIK >= 8.5, скорее всего, связаны с тем, что в этих версиях возникают ошибки реализации АРКОй QLua-машины 5.3.5 (отличной от нативной Lua-машины 5.3.5). Это отличие связано с тем, что QLua-машина 5.3.5 должна быть потокобезопасной, по сравнению с однопоточной Lua-машиной 5.3.5 (о причинах этого можно почитать мой комментарий № 142 по ссылке: https://forum.quik.ru/forum10/topic5119/?PAGEN_1=3).
   Более определенно, могу утверждать, что мой тест (многопоточный) автоматического управления памятью QLua-машины 5.3.5, для всех существующих (на дату 07.09.20) версий QUIK >= 8.5 диагностирует, в интервале 5 минут (в произвольные моменты), ее сбои (похоже, вызванные ошибками в синхронизации) и утечку памяти. Поддержке QUIK мною, начиная с 25.05.20, выслано более 40 дампов, а 15.08.20 выслан и сам тест для возможности оперативной отладки разработчиками новых версий QUIK. Для версий QUIK < 8.5 этот тест, ошибок не обнаруживает.
   Представьте себе, что на вашем ПК очень часто сбоит RAM (память). При этом любые ваши программы могут падать в любом месте, и можно искать в них свои ошибки до «посинения» (сам я этим не занимаюсь, до тех пор, пока не будут устранены сбои автоматического управления памятью QLua-машины 5.3.5).

1. Пользователи являются ценнейшим ресурсом любого проекта, правильное управление которым существенно определяет успех проекта. Фактически это внештатные бесплатные отладчики проекта. Поэтому к ним следует относиться очень внимательно и доброжелательно. За найденные ими ошибки в проекте, их следует благодарить. К ошибкам, совершаемые ими, относиться спокойно и давать четкие разъяснения таким образом, чтобы не отбивать желания повторного обращения.

2. При работе с пользователями, как правило (через некоторое время), можно выделить следующие группы пользователей:

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

  2) ключевые пользователи; это следующая, по ценности для проекта, группа пользователей, на работу с которой следует уделять повышенное внимание со стороны поддержки проекта;

  3) пользователи;

  4) боты и хамы; эта группа, кроме того, что засоряет каналы коммуникации, наносит имиджевый урон проекту; поэтому ее следует блокировать.

Новая версия (от 06.08.20) QUIK 8.8.1.5 продолжает «падать» (CQ02750791, CQ02779753, CQ02787899). Тестовая программа, вызывающая падение (с инструкцией по установке и ее запуску).

Здравствуйте!

 QUIK 8.8.1.5 «падает» похожим образом, как это было в предыдущих версиях (начиная с 8.5….). Кроме того, в QUIK в мониторе ресурсов, наблюдается утечка памяти.

   Для того, чтобы у вас была оперативная возможность отладки очередной версии, я высылаю не дамп, а мою тестовую программу (с кодами и инструкцией по ее запуску), в которой дампы возникают быстро (у меня в течении 5 минут), но в произвольные моменты. Эта же программа (с dll оттранслированными для Lua 5.1) непрерывно (месяцами) без проблем работает во всех версиях QUIK < 8.5. Одна из функций данной программы, которая включена сейчас по умолчанию, это тестирование автоматического управления памятью в QLua. Особенностью теста является высокая нагрузка (1500 обращений в секунду) на управление автоматической памятью QLua в условиях многопоточности.

   Если потребуется, я пришлю коды этой же тестовой программы (с dll оттранслированными для Lua 5.1), нормально работающей в версиях 8… < 8.5.

------

Инструкция по установке и запуску тестовой программы.

Для установки и запуска программы надо выполнить следующее:

1) распаковать архив OS_Quesha 8_5.zip;

  ! После распаковки исполняемые файлы в папке «… OS_Quesha\packages» и «…OS_Quesha\packages\Файлы папки QUIK» могут оказаться заблокированными;

     их необходимо разблокировать;

     Файлы можно разблокировать в их свойствах.

     Для быстрой разблокировки всех файлов папки:

      - откройте консоль PowerShell (под Админом) и выполните в ней команду get-childitem "полный путь папки" | unblock-file, предварительно заменив содержимое кавычек полным адресом к папке с заблокированными файлами.

2) получившуюся папку OS_Quesha переслать на диск C (в корень);

3) переслать все файлы (их два) из папки C:\OS_Quesha\packages\Файлы папки QUIK в папку хранения info.exe ( на диске установки QUIK);

4) в меню QUIK <Сервисы> ->   <Lua скрипты ...>   добавить скрипт-шаблон "TS_QUIK.lua" из папки C:\OS_Quesha;

5) запустить добавленный скрипт (это можно делать в QUIKе без подключения к серверу);   при этом появится окно диалога OS_Quesha.

-------------------------

При нормальной работе теста в поле Сообщения диалога с интервалом 5 секунд выдаются сообщения:

<@> <Дата | Время> <6.0> Тест управления памятью QLua. Количество синхронизаций = Количество

  Пока значение Количество меняется (с интервалом в 5 секунд) тест выполняется без ошибок.

Ошибки теста проявляются следующим образом:

1)       QUIK  «падает» (иногда очень быстро) с сохранением дампа, а иногда и без сохранения;

2)      Прграмма OS_Quesha зависает и Количество синхронизаций перестает меняется. Тогда про попытке завершения скрипта зависает или падает QUIK.

-----------

  Если скрипт "TS_QUIK.lua" запускать многократно то, в какой-то (произвольный) момент возникает дамп QUIK.   В версиях QUIK < 8.5 дампов не возникает.

     Для завершения работы с OS_Quesha достаточно закрыть окно ее диалога или остановить крипт в меню QUIK.                

------

Внимание!     Для того чтобы нормально работали пакеты dll,   в W10(64р), в папке C:\Windows\System32 и   в C:\Windows\SysWOW64 должны быть (в каждой из них) файлы:   msvcp140d.dll, msvcr120d.dll,   ucrtbased.dll, vcruntime140d.dll

Иначе QLua   может выдавать сообщение: Не существует модуль…….

  По моему скромному мнению, перевод QUIK на Lua 5.3… является стратегической ошибкой ARQU, если ориентироваться на пользователя, а не на хайп.    

   Во-первых, функционально, с учетом архитектурно тесной интеграции Lua c языком C/C++, это, мягко говоря, сомнительный шаг, так как все, что не реализовано в Lua 5,1,  по сравнению с Lua 5.3 (а это мало кому нужно), можно реализовать в языке C++. В том числе и длину номеров заявок (>= 19).

  Во-второых, при переходе на Lua 5.3 для  пользователя заметно меняется среда разработки в части используемых dll-библиотек. Надо ли это нормальным пользователям?

  Во-третьих, для самих разработчиков QUIK возникает большой геморрой в связи с необходимостью переработки управление автоматической памятью  Lua 5.3…  (оно существенно отличается от того, что было в Lua 5.1) так, чтобы оно было в QLua 5.3... потокобезопасным (задача, конечно, интересная, но нетривиальная задача параллельного программирования, требующая высокой квалификации). Необходимость потокобезопасности управления автоматической памятью QLua обусловлена тем, что все служебные функции обратного вызова QLua запускаются в потоке отличном от пользовательского (с именем main), но в среде (памяти) пользователя.

   Что мы имеем на текущий момент (12.08.20). Пользователи отлаживают, начиная с марта 2020г.все новые и новые версии (8.5…, 8.6…, 8.7…, 8.8…). Прошло уже 5 месяцев как нас кормят обещаниями стабильной новой версии QUIK. При запусках моего теста управления автоматической памятью во всех QLua версиях >= 8.5  в произвольные моменты времени, но в интервале 10 минут,  возникают дампы ( все они пересланы мной в поддержку ARQU). Причем в QUIK версий < 8.5 проблем с управлением автоматической памятью QLua мной не обнаружено.

    Пока в версии >= 8.5 не будет реализовано корректное потокобезопастное управление автоматической памятью версий QLua >= 8.5, QUIK будет нестабильным (надеюсь что разработчики QUIK это понимают).

-------

   Я понимаю, что отказаться от перевода QUIK на Lua 5.3… для ARQU практически невозможно, но, если ориентироваться на результат, то имело бы смысл «заморозить» перевод QUIK на Lua 5.3… и перенести накопленные нормально работающие фичи версий >=8.5… (в том числе длину номеров заявок = 19   ) в последнюю версию 8.4…… В противном случае, скорее всего, нас ждет длительное шоу новых версий QUIK.

   К сожалению, приходится наблюдать, как катастрофически падает профессионализм управленческих кадров в России, определяющих, что надо делать. ARQU вместо того, чтобы устранять ошибки версий 8.4…, улучшать функциональность, надежность и эффективность QUIK (и тут имеется широкие возможности), решила сделать маркетинговый ход и «поразить» пользователей переходом с Lua 5.1 на 5.3. Тут надо понимать, что функционально, с учетом архитектурно тесной интеграции Lua c языком C/C++, это, мягко говоря, сомнительный шаг, так как все, что не реализовано в Lua 5,1,  по сравнению с Lua 5.3 (а это мало кому нужно), можно реализовать в языке C++.

   Кроме того, история с многочисленными проблемами реализации собственного, потокобезопасного управления автоматической памятью QLua 5.1, была, похоже, была проигнорирована. Вместо элементарной реализации в версии 8.4…. произвольной длины номеров заявок (> 19 знаков) был выбран нелегкий путь («нормальные» герои всегда идут в обход).перехода на Lua 5.3… (в котором существенно изменилось управление автоматической памятью и  которое в QLua 5.3…, в отличие от Lua 5.3…, необходимо переработать так, чтобы оно было потокобезопасным). Необходимость потокобезопасности управления автоматической памятью QLua обусловлена тем, что все служебные функции обратного вызова QLua запускаются в потоке отличном от пользовательского (с именем main), но в среде (памяти) пользователя.

  Что мы имеем на текущий момент (12.08.20). Пользователи отлаживают, начиная с марта 2020г.все новые и новые версии (8.5…, 8.6…, 8.7…, 8.8…). Прошло уже 5 месяцев как нас кормят обещаниями стабильной новой версии QUIK. При запусках моего теста управления автоматической памятью во всех QLua версиях >= 8.5  в произвольные моменты времени, но в интервале 10 минут,  возникают дампы ( все они пересланы мной в поддержку ARQU). Причем в QUIK версий < 8.5 проблем с управлением автоматической памятью QLua мной не обнаружено.

 Пока в версии >= 8.5 не будет реализовано корректное (пусть и не самое эффективное) потокобезопастное управление автоматической памятью версий QLua >= 8.5, QUIK будет нестабильным (надеюсь что разработчики QUIK это понимают).