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

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

Страницы: Пред. 1 ... 3 4 5 6 7 8 9 10 11 12 13 След.
getMoneyEx иногда выдает nil., Интересно почему?
 
Цитата
Владимир написал:
А как передаются параметры в Lua, мне АБСОЛЮТНО до лампады - я не разработчик языка, я просто пользователь. Просто ЕСЛИ они передаются не ссылкой, а самой таблицей значений, ТО это есть идиотизм.
  Мне кажется, что вы зря "наезжаете" на язык Lua. Переключесть на C++ и будет вам счастье (и это обеспечивает Lua). Все, что вы не можете реализовать в собственно Lua (а  это то очень мало), вы можете реализовать в C++.
LuaFileSystem
 
 lfs.dll:   https://cloud.mail.ru/public/LgVW/233iiYc7J
Изменения в работе с колбеками LUA в новой версии
 
Цитата
Александр написал:
А что не так с многопоточностью то QLua 5.3?
Ответ: https://forum.quik.ru/messages/forum10/message49002/topic5855/#message49002
Программисты на LUA, Требуются LUA программисты
 
Цитата
Владимир написал:
Мой алгоритм работает на исторических данных точно так же, как и на реальных. И работает (тьфу-тьфу!) хорошо!
 Ну и флаг вам в руки!
Изменения в работе с колбеками LUA в новой версии
 
Цитата
Nikolay написал:
Не думаю что пойдут на изменение синтаксиса. Я бы больше ожидал стабильности и предсказуемости в вызовах. Сейчас только несколько колбеков типа подключения-отключения-ответ транзакции можно использовать.Остальные не вызывают доверия и надежней баз них. А то когда у тебя колблек от событий прошедших часы назад прилетает после перезапуска терминала, то проще не смотреть на них.
  ARQA, имхо, придется, скорее всего, пойти на изменения API по следующе причине:
1) проблеме реализации многопоточности QLua 5.3, которую они не смогли решить до сих пор (с марта 2020 до ноября 2020г.).  
Программисты на LUA, Требуются LUA программисты
 
Цитата
Владимир написал:
nikolz , Исторические данные отличаются от реальных лишь тем, что берутся из файла (из БД), а не поступают в реальном времени от того же Квика, а потому алгоритм, который хорошо работает на исторических данных будет столь же хорошо работать и на данных реальных ....

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

1)    пирамидальная архитектура фондового рынка (растет – закупаются; падает – продаются);

2)    его виртуальность – это представления у участников рынка о том, что надо учитывать (иногда очень далекие от действительности);

3)    инсайдерская составляющая (знание того, что скорее всего произойдет, отдельными участниками фондового рынка с существенными ресурсами), особенно значимая для России;

4)    малипуляционная составляющая, присутствующая на всех рынках (в виде различных «вбросов» в СМИ и т.д.);

5)    полная зависимость фондового рынка от поведения его участников (в том числе от использования новых информационных технологий);

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

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

Lua-таблицы. Интерфейс. Управление свойствами lua-таблиц., Как тонко настроить lua-таблицу? Механизмы взаимодействия пользователя с lua-таблицами.
 
    За искажение названия компании я извиняюсь. Это действительно нехорошо, но злого умысла в этом не было.
Lua-таблицы. Интерфейс. Управление свойствами lua-таблиц., Как тонко настроить lua-таблицу? Механизмы взаимодействия пользователя с lua-таблицами.
 
Цитата
Александр М написал:
Есть продукт, за который мы платим. По данному продукту есть проблема. Я как клиент имею полное право завести проблему и получить по ней информацию. Причем полную информацию
 Наверное, если ARQU заинтересована в расширении своей клиентской базы и повышении ее лояльности, то в интересах разработчика QUIK как-то улучшать и упорядочивать работу с клиентами (пользователями). Александр М предлагает вариант таких изменений. Зачем от этого отмахиваться?
Lua-таблицы. Интерфейс. Управление свойствами lua-таблиц., Как тонко настроить lua-таблицу? Механизмы взаимодействия пользователя с lua-таблицами.
 
    В своем предыдущем комментарии я способа решения задачи не предлагал.
Я написал краткую спецификацию: :smile:
Цитата
TGB написал:
сделать так, чтобы этого не возникало, задача ARQU
Lua-таблицы. Интерфейс. Управление свойствами lua-таблиц., Как тонко настроить lua-таблицу? Механизмы взаимодействия пользователя с lua-таблицами.
 
Цитата
Anton написал:
Если окно никуда не прицеплять, будет просто отдельное от квика окно. Чтобы окно было внутри квика, надо SetParent ему сделать с
=============================================
Цитата
TGB написал:
Рассмотрим случай, когда при работе с таблицей, на неё "навешана" богатая функциональность, например, выполняемая 5 минут. Это значит, что все события, возникающие на рынке в интервале 5 минут недоступны для обработки в скрипте пользователя. Это хорошее поведение программы? Кто даст гарантии, что такая ситуация не возникнет.
   Вы согласны что описанная выше ситуация может возникнуть?   А если согласны, то сделать так, чтобы этого не возникало, задача ARQU. Если бы такая задача возникла у меня, я бы ее решил. Заниматься парным программированием здесь я не вижу смысла.
Lua-таблицы. Интерфейс. Управление свойствами lua-таблиц., Как тонко настроить lua-таблицу? Механизмы взаимодействия пользователя с lua-таблицами.
 
Цитата
Anton написал:
т.к. потоки будут синхронизироваться и ждать обработки сообщений друг друга;
 Зачем потоку, обрабатывающего коллбеки рынка, синхронизироваться с потоком обрабатывающим таблицы?
И вообще, для пользователя важно удобство при создании его скриптов, а как это сделать, это задача разработчиков QUIK.
Lua-таблицы. Интерфейс. Управление свойствами lua-таблиц., Как тонко настроить lua-таблицу? Механизмы взаимодействия пользователя с lua-таблицами.
 
Цитата
Anton написал:
https://devblogs.microsoft.com/oldnewthing/20130412-00/?p=4683
 Статья хорошая, но в ней особо предупреждается о проблемах реализации межпроцессорного  взаимодействия. Я же пишу о потоках и не вижу особых проблем взаимодействия между ними. И это не только мои теоретические представления, но моя практика.
Lua-таблицы. Интерфейс. Управление свойствами lua-таблиц., Как тонко настроить lua-таблицу? Механизмы взаимодействия пользователя с lua-таблицами.
 
Цитата
Владимир написал:
TGB , Да и колбеки не хило бы там же обрабатывать.    Что мы ловим? Скорость?
  Рассмотрим случай, когда при работе с таблицей, на неё "навешана" богатая функциональность, например, выполняемая 5 минут. Это значит, что все события, возникающие на рынке в интервале 5 минут недоступны для обработки в скрипте пользователя. Это хорошее поведение программы? Кто даст гарантии, что такая ситуация не возникнет. Есть же известный принцип (и не только в программировании): не сваливай все в одну кучу.
Lua-таблицы. Интерфейс. Управление свойствами lua-таблиц., Как тонко настроить lua-таблицу? Механизмы взаимодействия пользователя с lua-таблицами.
 
  В существующей реализации работы (из QLua с) таблицами QUIK есть существенный недостаток (а на самом деле, баг) состоящий в том, что такие
таблицы обслуживаются в том же основном потоке, в котором запускаются коллбеки. Давно надо было бы сделать обработку обсуждаемых таблиц в отдельном потоке.
Изменения в работе с колбеками LUA в новой версии
 
Цитата
swerg написал:
И вот на какой вопрос я при этом не нахожу ответа. Если бы не было main() - каким образом останавливать обработку колбеков, когда автор скрипта уже не хочет чтобы колбеки вызывались? ну вот в самом деле, нельзя же все время для всех скриптов вызывать колбеки. Или можно?
   Попробую ответить кратко, как, это, похоже, происходит сейчас в QUIKе.
 Основной поток запуска и обслуживания пользовательских скриптов (в том числе и его коллбеков) при запуске любого скрипта сканирует его в поисках его же коллбеков (по именам событий). По каждому скрипту ведется список найденных его меток (функций) колбеков в рамках его lua_State. При возникновении любого события, основной поток обходит последовательно lua_State всех запущенных скриптов и запускает (если находит) соответствующие коллбеки. При останове любого скрипта порождается событие <OnStop>, которое отрабатывает также основной поток. При этом список коллбеков остановленного скрипта обнуляется.
Изменения в работе с колбеками LUA в новой версии
 
Цитата
Александр написал:
В третьем варианте все будет выполняться в одном потоке и привет переписывание скриптов.
Вообще говоря, я сторонник первого варианта (щадящего пользователей), но он уже не реален.
Если разработчики что-то изменят в работе с коллбеками, то пользователям, скорее всего, все равно придется что-то править в своих скриптах. В третьем варианте, в отличие от второго, есть хоть какой-то смысл.
Изменения в работе с колбеками LUA в новой версии
 
Цитата
swerg написал:
Свежие мечтатели к нам подключились, похоже :))
    Это я к себя не отношу, но использую, как повод высказаться дополнительно.
У ARQU, существует три варианта, после перехода на Lua 5.3, порождающем множество проблем и не предоставляющем, по большому счету ни чего нового:
  1) отказаться от перехода на Lua 5.3 и у них для этого было железное алиби (Lua является фактически двухуровневым языком и все, что не реализуемо в собственно Lua 5.1, можно реализовать в C/C++, с которым Lua тесно интегрирован): причем,. фактором усиливающим озвученное алиби, могло быть соображение, состоящее в том, что они заботятся о стабильности среды разработки, предоставленной пользователям;
  2) "пробиться" через возникшие проблемы перехода на Lua 5.3, одной из которых является необходимость реализации, при сохранении существующей архитектуры обработки событий QUIK, многопоточности QLua 5.3 (по  сравнению с однопоточностью нативного Lua 5.3);
  3) изменить схему  обработки событий QUIK так, чтобы уйти от проблем многопоточности QLua.
 На первый вариант они не пошли (и, по-моему, зря), а теперь и не могут пойти (ведь кому-то, и не рядовым, за это пришлось бы отвечать).
 Со вторым вариантом, похоже, возникли проблемы, которые наблюдают многие пользователи.
 Третий вариант, описанный мною в этой ветке, действительно, качественно меняет архитектуру QUIK, при которой:
    1) исчезает требование многопоточности QLua (большой геморрой при переходе на новые версии Lua, в том числе на 5.3.5);
    2) обеспечивается независимость основного потока регистрация событий от пользовательского "произвола", возникающем при использовании коллбеков, в которых "непросвященный" пользователь может делать все, что угодно.
 Этот вариант был бы  достойным выходом для ARQU из сложившийся ситуации.
Грядущие изменения на срочном рынке МБ: поддержка работы с 19-значными номерами заявок и сделок
 
В ветке «Изменения в работе с колбеками LUA в новой версии» https://forum.quik.ru/messages/forum10/message49848/topic5930/#message49848
появилось интересное сообщение:

Александр написал:
  Разработчики написали в письме:

   

Цитата

 

В ближайшей версии мы изменим   работу с коллбэками Lua. Ожидаем, что изменения исключат возникающую ошибку.    

Могли бы разработчики более подробно описать грядущие изменения?

Поддержка:

Добрый день,
Пока подробностей нет. Как выйдет новая версия это будет указано в списках изменений.

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

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

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

  Я не знаю точно, какие изменения будут, но попытаюсь дать прогноз (интересно, насколько промахнусь). А если промахнулся, то это мои предложения.

   Видимо это будут изменения, которые надо было внести в схему обработки коллбеков QLua, как мне кажется, давно, а именно:

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

   2)    вместо sleep, служебная функция ожидания либо истечения интервала времени (как в sleep), либо появления данных в очередях событий (с выдачей списка непустых очередей);

   3)    добавление функции чтения очередей событий (их параметров).

   Эта схема реализует рекомендованную ARQU обработку параметров событий в main.  Кроме того, в такой схеме решается тяжелая задача подключения новых версий Lua в QUIK, так как не будет требоваться переработка в Qlua нативного управления автоматической ее памятью с целью реализации потокобезопасной уборки мусора, требуемой в старой схеме (из-за запуска функций коллбеков в потоке, отличном от потока main, но в контексте пользователя). Подключение новых версий Lua (в том числе и 5.3.5) станет в описанной выше схеме рутинной задачей.

При этом проблема сбоев автоматической памяти QLua 5.3, о которой я писал не раз в ветке «Грядущие
изменения на срочном рынке МБ: поддержка работы с 19-значными номерами заявок и
сделок
» должна исчезнуть.

----

Добавление.

   Если будет реализована описанная выше схема обработки коллбеков, то, так как реализация QLua станет однопотоковой, мой многопотоковый тест памяти QLua для этого случая не применим.

Изменения в работе с колбеками LUA в новой версии
 
Цитата
swerg написал:
Да не будет там изменений, что вы так переживаете. С чего вдруг?
  Я не знаю точно, какие изменения будут, но попытаюсь дать прогноз (интересно, насколько промахнусь). А если промахнулся, то это мои предложения.

    Видимо это будут изменения, которые надо было внести в схему обработки коллбеков QLua, как мне кажется, давно, а именно:

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

    2)    вместо sleep, служебная функция ожидания либо истечения интервала времени (как в sleep), либо появления данных в очередях событий (с выдачей списка непустых очередей);

    3)    добавление функции чтения очередей событий (их параметров).

    Эта схема реализует рекомендованную ARQU обработку параметров событий в main.  Кроме того, в такой схеме решается тяжелая задача подключения новых версий Lua в QUIK, так как не будет требоваться переработка в Qlua нативного управления автоматической ее памятью с целью реализации потокобезопасной уборки мусора, требуемой в старой схеме (из-за запуска функций коллбеков в потоке, отличном от потока main, но в контексте пользователя). Подключение новых версий Lua (в том числе и 5.3.5) станет в описанной выше схеме рутинной задачей.

При этом проблема сбоев автоматической памяти QLua 5.3, о которой я писал не раз в ветке «Грядущие изменения на срочном рынке МБ: поддержка работы с 19-значными номерами заявок и сделок» должна исчезнуть.
Предложение к разработчикам
 
Цитата
Владимир написал:
Ну... я бы тоже не отказался от С-подобного синтаксиса (например, JS)
   Эта достаточно легко решаемая задача.
Пишется простенький собственный препроцессор (на том же Lua), который в нужных местах заменяет "}" на "end" и убирает открывающие скобки "{"  блоков ( при этом, конечно, надо учесть синтаксис задания таблиц, а может быть и еще что-то, например, "do") и после этого можно писать Lua-программы на синтаксисе в чем-то похожем на синтаксис C, обрабатывая их таким препроцессором.
Предложение к разработчикам
 

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

1.    Фактически Lua является двухуровневым языком благодаря архитектурной (изначально) тесной его интеграции с C/C++. Это обеспечивает два уровня его использования:

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

   2)    расширенный с выходом в системный язык программирования C/C++ (и для этого в Lua есть C-API), на котором можно написать все что угодно.

  Все проблемы, не решаемые в собственно Lua, могут решаться в C/C++. Нужна высокая производительность, переходим в C/C++. Нужен типизированный язык переходим туда же. Не хватает каких-то функций, переходим туда же.

2.    Зачем вносить какие-то изменения в Lua с тем, чтобы из него сделать плохой C, когда и так можно писать на C?

3.    Интересно то, что Владимир и сам не хочет писать ни на каком языке, кроме Lua. :smile:

Грядущие изменения на срочном рынке МБ: поддержка работы с 19-значными номерами заявок и сделок
 
Цитата
s_mike@rambler.ru написал:
Прикрепленные файлы  
  Взглянул еще раз и увидел что смешно.

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

Предложение к разработчикам
 
Цитата
nikolz написал:
это все Вам бесплатно
 А от куда берутся деньги на зарплату сотрудникам ARQU и вознаграждения ее акционерам? Оплата пользователями QUIK входит (косвенно) в те комиссии, которые пользователи платят своим брокерам.
Грядущие изменения на срочном рынке МБ: поддержка работы с 19-значными номерами заявок и сделок
 
Цитата
s_mike@rambler.ru написал:
Прикрепленные файлы
Надо хотя бы уметь читать:

--------

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

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

Грядущие изменения на срочном рынке МБ: поддержка работы с 19-значными номерами заявок и сделок
 
Цитата
Anton написал:
им, возможно, все понятно
Похоже, им все понятно. И это главное. Они разработчики QUIK. От них я вопросов не получаю (даже после моих неоднократных назойливых сообщений: а нет ли ко мне каких-либо вопросов?). С ними я готов обсуждать любые проблемы и они знают адрес моей почты.
Грядущие изменения на срочном рынке МБ: поддержка работы с 19-значными номерами заявок и сделок
 
Цитата
Anton написал:
нужно показать, что либо а) коллектор собирает объекты, не помеченные мусорными, либо б) коллектор не собирает объекты, помеченные мусорными. Ничего такого пока показано не было. Все остальное это уже не вопрос управления автоматической памятью
  А может быть, вместо ARQU, мне написать и всю потокобезопасную Lua - машину, встроенную в QUIK?  Для тех, кто понимает, это очень большие деньги за выполнение такой работы (как минимум: 7 месяцев * <Среднее количество разработчиков> * <Среднюю зарплату>). Как это сделать я понимаю. Но в любом случае, это сложная работа (и не всеми реализуемая), и я сочувствую разработчикам QUIK, "парящимся" над тем, как реализовать потокобезопасную уборку мусора QLua.  Даже мой "хилый" тест (который, похоже, не был реализован  ARQU за десятилетия своего существования хоть в каком-то виде), позволяющий, в оперативном режиме тестировать автоматическое управление памятью QLua, при его заказе на стороне, стоил бы, наверное, больших денег. Я его выслал поддержке QUIK без предоплаты.
Грядущие изменения на срочном рынке МБ: поддержка работы с 19-значными номерами заявок и сделок
 
Цитата
Anton написал:
Я, я, я этот человек! (не аффилирован ежли кто не знал)
Зря вы это написали.
Грядущие изменения на срочном рынке МБ: поддержка работы с 19-значными номерами заявок и сделок
 
Цитата
Anton написал:
повреждение памяти это вторичное явление и ковырять коллектор суть пустая
Цитата
TGB написал:
Представьте, что вы купили ПК, в котором часто сбоит RAM (память). Это значит, что любые ваши программы могут «падать» в любом месте, в любое время и можно искать в них свои ошибки до «посинения». При этом, при работе на бирже, вы не можете отойти от ПК ни на минуту, так как ваша «автоматизация» может «упасть» в любой момент времени, возможно, с неприятными для вас последствиями.

P.S.Версиях QUIK < 8.5 мой тест управления автоматической памятью QLua ошибок не обнаруживает.
Все версии QUIK >=8,5 "падают" при запуске моего теста автоматической памяти QLua в интервале пяти минут.
Интересно, кому непонятно что это фундаментальная проблема нестабильности QLua (кроме аффилированных с ARQU лиц)?
Грядущие изменения на срочном рынке МБ: поддержка работы с 19-значными номерами заявок и сделок
 
Цитата
TGB написал:
Вопросы к поддержке QUIK:.    У вас "новичок" является внештатным сотрудником ARQU?    А если это не так, то зачем вы тут (на форумах ARQU) его держите?
Грядущие изменения на срочном рынке МБ: поддержка работы с 19-значными номерами заявок и сделок
 
Цитата
новичок написал:
ты не утомился бред нести?

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

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

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

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

Грядущие изменения на срочном рынке МБ: поддержка работы с 19-значными номерами заявок и сделок
 
Цитата
TGB написал:
тест управления автоматической памятью QLua диагностирует утечку памяти и некорректность ее функционирования
 Наверное, стоит пояснить, что означает приведенная выше цитата.

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

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

Представьте, что вы купили ПК, в котором часто сбоит RAM (память). Это значит, что любые ваши программы могут «падать» в любом месте, в любое время и можно искать в них свои ошибки до «посинения». При этом, при работе на бирже, вы не можете отойти от ПК ни на минуту, так как ваша «автоматизация» может «упасть» в любой момент времени, возможно, с неприятными для вас последствиями.

P.S.
Версиях QUIK < 8.5 мой тест управления автоматической памятью QLua ошибок не обнаруживает.
Грядущие изменения на срочном рынке МБ: поддержка работы с 19-значными номерами заявок и сделок
 
Цитата
Появился QUIK 8.9.0.107.   https://arqatech.com/ru/support/files/quik-workstation/ Мой тест управления автоматической памятью QLua диагностирует утечку памяти и некорректность ее функционирования.    Жду следующую версию.

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

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

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

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

---------

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

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

Функции onInit, onStop, onClose
 
Цитата
TGB написал:
Какуя версию QUIK Вы используете?  Если >= 8.5, то можете посмотреть мой комментари
Странно, конечно, не все ситуации в QUIK возникают из-за сбоев управления автоматической памятью QLua 5.3.5, однако, меня поражает, что многие, похоже, не понимают, что, если сбоит память QLua 5.3.3, то можно ожидать всего что угодно, в любых своих программах.
Функции onInit, onStop, onClose
 
Цитата
Anton написал:
Все же small это не более чем функция, выполняется в том потоке, в котором вызвана, в данном случае в потоке мейна.
  Я до сего момента не использовал таблицы QUIK и потому проверил то, что описывает Anton.  Похоже, он описывает то, что есть. То есть, некорректное  завершение скриптов по событию OnStop. Действительно, поддержка (обслуживание) таблиц QUIK выполняется в том же (основном потоке), что и обработка колбеков (по моему мнению плохое решение). Поэтому (как написал Anton), если нажатие кнопки "Остановить" произошло в тот момент, когда не завершилась отработка (в основном потоке) SetCell(...) , то возникает ситуация, которую Вы наблюдаете. Это относится и к версиям QUIK < 8.5. Наверное, стоит "выкатить", обнаруженное Вами, поддержке QUIK. Фиксацию ваших результатов, имеет смысл, перенести в OnStop до строки: f=false
Функции onInit, onStop, onClose
 
Цитата
Владимир написал:
Запустил через час - опять теряет управление. ВААПЩе НИЧЕГО НЕ ДЕЛАЛ СО СКРИПТОМ!    
  Какуя версию QUIK Вы используете?  Если >= 8.5, то можете посмотреть мой комментарий https://forum.quik.ru/messages/forum10/message48194/topic5527/#message48194 . Этот комментарий относится и к QUIK 8.9, который "падает" на моей тестовой программе автоматической памяти QLua (отосланной поддержке QUIK 15.08.20) в разные моменты, но в интервале пяти минут. В версиях QUIK < 8.5 эта тестовая программа без проблем работает неделями.
Функции onInit, onStop, onClose
 
Цитата
Владимир написал:
Что делать?
Здравствуйте!

В OnStop() добавьте  return <Интервал в млсек.>.

Смотрите комментарии ниже.

-------

function OnStop()
  ----------- Завершает цикл в функции main()   -----------
    IsRun = false;
    message(" Завершение работы моего интерфейса ===== ",1)
   return 10000   --  !!  По истечении этого интервала времени (в млсек.), данного скрипту на завершение работы, функция main() завершается принудительно.
                            -- При этом возможна потеря системных ресурсов.   ! Если функция не выдает значение, то по умолчанию оно 5000 (5 сек.)
end;
Отладка QUIK 8.9
 
Письмо посланное мною в поддержку QUIK:

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

Здравствуйте!  Посылаю вам дамп.  С помощью посланной 15.08.20 вам мною моей программы, вы можете получать этих дампов столько, сколько захочете.
Кроме того, наблюдается утечка памяти.
Работа main() при наличии 1 ядра
 
Цитата
Anton написал:
встали на локе, пока второй поток не соизволит вас пустить
  В нативном коде Lua лок пустая операция во всех функциях C-API.
  Откуда известно, что в QLua лок - синхронизирующая операция во всех функциях С-API QLua, порождающая то, что вы описали? Дело в том, что при выполнении функции (в своей отдельной области стека), в которой используются только общие, не изменяемые, глобальные переменные, синхронизация не требуется . Я думаю, что разработчики QUIK это, наверное, понимают и не подавляют параллелизм выполнения таких функций ( а они есть).  
Работа main() при наличии 1 ядра
 
Цитата
Anton написал:
в каждый момент времени с луа работает либо мейн, либо колбек.
    мейн и колбеки работают в разных потоках. Если ЦП имеет оно ядро, то процитированное выше верно, Если ядер несколько, то, может быть ситуация, когда мейн и колбеки работают параллельно.
Вопросы, не требующие ответов
 
Цитата
Anton написал:
Потому что перехватить их все вообще не вопрос
 В дополнение к комментарию, написанного Anton.
  Обработать фатальные исключения так, чтобы можно было продолжить работу скрипта в текущем процессе, в общем то, практически невозможно (на то они и фатальные).
Однако существует хорошо известная схема обработки таких исключений:
  1) выдача кода EXCEPTION_CONTINUE_SEARCH (для SEH - исключений) о последующем продолжении обработки перехваченного исключения, а также сообщения о возникновении такого исключения с выдачей локального дампа скрипта (распечатка состояния информационных структур скрипта после перехвата этого исключения для анализа возможных причин возникшего исключения):
  2)  перезапуск процесса, в котором возникло обсуждаемое фатальное исключение.
 Описанная выше схема, обычно, реализуется с использованием контрольных точек (состояний вычисления: значений внутренних переменных скрипта), зафиксированных, обычно, на энергонезависимых накопителях. Контрольные точки должны обеспечивать (после их считывания) продолжение вычислений в скрипте с последнего зафиксированного,  перед перезапуском его состояния.
Вопросы, не требующие ответов
 
Цитата
nikolz написал:
Что же касается перехвата всех исключений
И где-же в приведенном вами моем тексте, есть что-то написанное про исключение?
Вопросы, не требующие ответов
 
Цитата
Владимир написал:
я бы хотел иметь в виде интерпретатора аналог моего любимого С (или хотя бы JS)
 Я, наверное, Вас обрадую. В QLua (Lua) существует C-API и у Вас есть возможность, практически полностью вести свои разработки на C. Хорошее описание C-API представлено в книге одного из отцов-основоположников языка Lua http://texno.info/wp-content/uploads/2019/09/lua.pdf (можно посмотреть также https://lua.org.ru/contents_ru.html#4.7).  Вы можете создать dll-пакет на C и подключить в своем скрипте. Далее вызываете в скрипте свою функцию пакета, в которой делаете все что Вам нужно (например, запускаете потоки для обработки данных и так далее). Из такого пакета доступен весь интерфейс с QUIK. Есть хороший ресурс https://quikluacsharp.ru/, на котором представлены некоторые шаблоны решений для QLua, в том числе, шаблон создания dll-пакета для QLua.
Вопросы, не требующие ответов
 
1.
Цитата
Владимир написал:
Сам Lua ИДЕОЛОГИЧЕСКИ предназначен именно НЕ для программистов
Вы же пищите на нем?
И, наверное, часть пишущих скрипты на QLua являются профессиональными программистами.

2.
Цитата
TGB написал:
Такая реализация вашего предложения не затрагивает уже существующие скрипты
И пусть те, кто не собирается заниматься перезапусками QUIK  продолжают жить так, как жили до сих пор. Те кто не в теме, скорее всего, не используют даже pcall.

3.
Цитата
Владимир написал:
Именно они и есть место потенциальных и труднонаходимых ошибок
С этим я согласен.

4.
Цитата
Владимир написал:
вашей квалификацией практически любой за пару часов напишет
Как решать свои проблемы, я во многих случаях знаю, но в данном случае обсуждается не лично моя проблема.

5.
Цитата
Владимир написал:
Я вообще не понимаю, как в этом случае получать доступ к данным.
И с этим я тоже согласен.
Вопросы, не требующие ответов
 
Цитата
Anton написал:
пусть рушится, глядишь и дампы какие-то более содержательные будут получаться.
 И все-таки, ваше предложение дать возможность перехватывать все исключения в скрипте, мне представляется хорошим решением.
Оно может быть реализовано, например в следующем виде.
  В интерфейсные функции QUIK  добавляется функция ppcall - полный аналог pcall, но перехватывающий абсолютно все исключения. Туда же добавляется функция перезапуска QUIK с параметром, определяющим подробность распечатки содержательного дампа перед запуском, а так же необходимость самого перезапуска. Перехват всех исключений обеспечит:
  1) удобную локализацию места, возможно порождающего исключение;
  2) возможность анализа состояния скрипта (вывод своего локального дампа) сразу после возникновения исключения.
 Такая реализация вашего предложения не затрагивает уже существующие скрипты, но предоставляет дополнительные возможности тем, кто захочет воспользоваться этими функциями. Эти функции, например, могут быть использованы в скриптах для реализации контрольных точек, обеспечивающих продолжение работы, с прерванного перезапуском места.
 
Вопросы, не требующие ответов
 
Цитата
Anton написал:
У них могут быть какие-то свои дополнительные соображения
Может быть следующее возражение.
  Многие пишущие скрипты не являются профессиональными программистами и если в их скриптах будут перехвачены, но не обработаны фатальные исключения (сигнализирующие о разрушении контекста исполнения процесса QUIK), то последующее поведение QUIK будет неопределенным и это может (потенциально) привести, например, к выдачи искаженной заявки, порождающей клиенту убытки.
  Однако, если реализовать в QUIK дополнительно специальный режим запуска скриптов, в котором используется, предложенная вами схема обработки исключений, то это было бы хорошее решение, обеспечивающее больший контроль в разрабатываемых скриптах для тех, кто понимает как обрабатывать фатальные ошибки (например, перезапуская QUIK). При этом в сервисные функции стоило бы добавить функцию перезапуска QUIK.
Зависание QUIK
 
Цитата
Старатель написал:
Похоже, источник проблемы - функция с переменным числом аргументов.
Здравствуйте.

 Я в соседней ветке обсуждения как-то уже написал https://forum.quik.ru/messages/forum10/message48194/topic5527/#message48194 что, похоже, многие проблемы версий QUIK >= 8.5...  вызваны некорректной реализацией QLua-VM. Ситуации, когда при падении функций, написанных на "чистом" QLua, пользователю не выдаются диагностические сообщения из самого QLua - это ошибки разработчиков языка QLua (отличного от нативного Lua, в части реализации управления памятью). Причем, скорее всего, это ошибки синхронизации при реализации потокобезопасного управления автоматической памятью QLua.  Такого рода ошибки "плавающие" и внешне похожи на сбои аппаратуры. Но могут быть программы, которые создают нагрузку, при которой эти ошибки возникают чаще обычного. Это, наверное, делает и ваш срипт. Я 15.08.20 послал поддержке свою программу, которая "роняет" QUIKи в интервале 5 минут (в разные моменты времени). А до этого отправил кучу дампов. Наверное, имеет смысл и вам туда же отправить ваш скрипт.
Зависание QUIK
 
Цитата
Anton написал:
А и речи не было про параллельно.
Если речь шла об рекурсии, то в обработке Quik-ом колбеков ее тоже нет.
Зависание QUIK
 
Цитата
Anton написал:
смотреть, не получится ли в каком-то из вариантов уровень рекурсии больше единицы.
В QUIK существующая cхема обработки колбеков следующая:
  1.  Существует единственный служебный поток, из которого запускаются потоки скриптов пользователя (main).
  2.  При запуске пользовательских скриптов выполняется регистрация объявленных в них колбеков.
  3.  Колбеки всех запущенных пользователем скриптов обрабатываются в служебном потоке последовательно, так как поток один. Если в нескольких пользовательских скриптах объявлен некоторый колбек (с одинаковым названием), то при возникновении соответствующего ему события, для каждого скрипта в его state запускается свой (объявленный) колбек и выполняется это в служебном потоке последовательно.  Таким образом никакие существующие пользовательские колбеки не могут обрабатываться параллельно.
   С учетом выше изложенного  всегда max_recursion_level = 1 и это подтверждает предложенный вами тестовый скрипт.
Отладка QUIK 8.8
 
1.  
Цитата
Александр написал:
Почему то у меня ни одна программа, написанная на QLua не валится.
Тогда я не понимаю, зачем вам разбираться с чужими черными ящиками?

2.
 
Цитата
Александр написал:
вы просто сами себе выстрелили в ногу
Если вы сходили по ссылке https://forum.quik.ru/messages/forum10/message47772/topic5119/#message47772, то смогли, наверное, прочитать:
 TGB написал:
"Эта же программа (с dll оттранслированными для Lua 5.1) непрерывно (месяцами) без проблем работает во всех версиях QUIK < 8.5."

Цитата
Александр написал:
напишите простой тестовый пример с исходниками
Почему простой тест не получится объясняется в тексте также по приведенной выше ссылке.

3.
Цитата
Александр написал:
обвиняете разработчиков
 По ссылке https://forum.quik.ru/messages/forum10/message48046/topic5119/#message48046 вы можете прочитать, что пишет по этому поводу поддержка QUIK.
    Приведу  от туда лишь короткую цитату:
"По указанным номерам зафиксированных нами и указанных Вами инцидентов (CQ02750791, CQ02779753, CQ02787899. CQ02802279, CQ02809006) мы ведём активную работу и на момент данного ответа, вопрос о причинах утечки памяти и падения рабочего места остаётся открытым."

4,   А это с данной ветки обсуждения:
   
Alexey Ivannikov написал:

12.08.2020 18:42:22
Цитата
Юрий написал:
Ставим новые рекорды потребления памяти.
Уважаемая техподдержка, порадуйте чем-нибудь, я же вам все данные передал что вы просили.
Добрый день.

Мы разбираемся с проблемой. Как будут результаты - незамедлительно Вас известим.

5.
Цитата
Александр написал:
TGB ,Вам же ничто не мешает самостоятельно управлять сборкой мусора.
  Проблема не с запусом мусорщика.  
Отладка QUIK 8.8
 
Цитата
Александр написал:
Вероятно вам нужно упростить скрипт и выложить простой тестовый пример, избавившись от лишнего.Тогда станет более понятно.
Ответ можно посмотреть по ссылке https://forum.quik.ru/messages/forum10/message47772/topic5119/#message47772

Цитата
Nikolay написал:
А Ваше решение только под qlua?
 Да.  Нативный Lua однопоточный. QLua многопоточный. Так же можете посмотреть пояснения по выше приведенной ссылке.
Страницы: Пред. 1 ... 3 4 5 6 7 8 9 10 11 12 13 След.
Наверх