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

Новая версия (от 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 это понимают).

   Как и предполагалось (смотри мой комментарий от 23.05.2020 14:30:59), поддержка ARQU до сих пор в данной теме себя не проявила. Претензий к поддержке и разработчикам QUIK нет (это подневольные люди, как и «записные» боты-энтузиасты новых версий 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), но в среде (памяти) пользователя.

  Что мы имеем на текущий момент (26.07.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 это понимают).

Увеличение номера заявки до 19 разрядов это, конечно, прорыв в будущее .

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

 А  если конкретно, то в данной теме обсуждается не перенос «фич» из новой версии 8.5 в старые, а всего навсего обеспечение очень старой функциональности работы с заявками.