Грядущие изменения на срочном рынке МБ: поддержка работы с 19-значными номерами заявок и сделок

Страницы: Пред. 1 2 3 4 5 След.
RSS
Грядущие изменения на срочном рынке МБ: поддержка работы с 19-значными номерами заявок и сделок
 
    Извините, упустил:
Цитата
Anton написал:
Попытался найти, где у вас этот тестовый код зарыт, не нашел. В чем смысл такого теста остается неясным.
 Общее описание.
   function OS_Quesha_TS (NC)    - запускается циклически (в отдельном потоке) по таймерным событиям, запрашиваемым в функции set_evnt_lua ({1, CyclichkLine_evnt_TS}) с частотой ~300 гц.  В этой функции запрашиваются строки в цикле (5 раз) и передаются функции  function SendTS_CQ(NC) работающей в другом отдельном потоке и что-то делающей с этими строками (смотрите текст).   Все это происходит в одной lua_State.
   При такой работе достаточно интенсивно ( как минимум 1500 обращений в секунду) нагружается система управления автоматической памятью QLua. И это происходит в разных потоках. Если потокобезопасное управлению автоматической памятью  реализовано корректно, то тест выполняется до тех пор пока запущенный скрипт не будет остановлен. Иначе возникают различные ошибки, не перехватываемые в QLua.
 
Цитата
TGB написал:
В этой функции запрашиваются строки в цикле (5 раз) и передаются функции  function SendTS_CQ(NC) работающей в другом отдельном потоке и что-то делающей с этими строками (смотрите текст).   Все это происходит в одной lua_State.
Вы работаете с одним lua_State из двух разных потоков, верно я понял?
 
Цитата
Anton написал:
Вы работаете с одним lua_State из двух разных потоков, верно я понял?
  Да.
 
Цитата
Anton написал:
Вы работаете с одним lua_State из двух разных потоков, верно я понял?
 Уточнение: на самом деле из нескольких потоков. Это тест выполняется в двух.
 
Цитата
TGB написал:
Да.
Теперь вопрос, как вы синхронизируете доступ к этому стейту из разных потоков?
 
Цитата
Anton написал:
Вы работаете с одним lua_State из двух разных потоков, верно я понял?
 Дополнение.
  Кроме запускаемого шаблона-исходника TS_QUIK.lua есть документация OS_Quesha.pdf (в папке C:\OS_Quesha\OS_Quesha_files), из которой можно узнать что-то об архитектуре  OS_Quesha, в том числе о том, что количество потоков, работающих в одном lua_State задается параметрически в описании схемы потоков (с указанием запускаемых в них функций и связями между ними), а также многое другое.  
  Если вы посмотрите документацию, то возможно, найдете ответы на возникающие у вас вопросы.  
 
Цитата
Anton написал:
Теперь вопрос, как вы синхронизируете доступ к этому стейту из разных потоков?
  Ответ из документа:
5. Полная инкапсуляция параллелизма функционирования потоков/псевдопотоков в средствах
OS_Quesha, обеспечивающих эффективность (реализована специально разработанная схема
синхронизации), корректность синхронизации и безопасность взаимодействия функций, вы-
полняемых в разных П/П.
В OS_Quesha существуют два вида, параметрически задаваемой в глобальных настойках, син-
хронизации П/П: обычная, с использованием критической секции ОС, и быстрая (специально
разработанная) на "защелках", без переключения потоков в случаях возникновении конфликтов
синхронизации. При необходимости разработчик может использовать все средства синхрониза-
ции явным образом.

 При этом всегда помним, что OS_Quesha (с dll оттранслированными для Lua 5.1) непрерывно (месяцами) без проблем работает во всех
версиях QUIK <  8.5.  
 
Цитата
TGB написал:
найдете ответы на возникающие у вас вопросы
Падает-то у вас. При этом вы шарите стейт между потоками. Этого вообще-то делать нельзя, если вы не знали. Для каждого своего потока вы должны создать новый стейт через lua_newthread и работать только с ним, тогда основную часть синхронизации за вас будет делать луа (но не всю). Если вы лезете в общий стейт из разных потоков, вы просто рано или поздно ломаете стек и получаете крэш. Именно это и подтверждает ваш тест.
 
Цитата
TGB написал:
с использованием критической секции ОС
Цитата
TGB написал:
на "защелках", без переключения потоков
Это все прекрасно, к стейту-то вы как доступ синхронизируете? Это можно сделать только той же критической секцией, которую внутренне использует квик, как вы до нее добрались?
 
Цитата
Anton написал:
вы просто рано или поздно ломаете стек и получаете крэш. Именно это и подтверждает ваш тест
что в версиях QUIK >= 8.5... есть проблемы с управлением автоматической памятью QLua.

Вы постоянно забываете, что
Цитата
TGB написал:
При этом всегда помним, что OS_Quesha (с dll оттранслированными для Lua 5.1) непрерывно (месяцами) без проблем работает во всех версиях QUIK <  8.5.
   Если желаете проверить сами выше приведенное утверждение, то могу выложить соответствующие коды для версий 8.4...

   При запуске функций QLua в потоках OS_Quesha, стеки таких функций разворачиваются в отдельных, не пересекающихся между собой областях памяти. Поэтому синхронизации доступа к локальным переменным функций в различных потоках не требуется (единственное что при этом требуется - это потокобезопасность управления памятью QLua). Если по какой-то необходимости в потоках требуется синхронизация для общих модифицируемых переменных, то это делается внутри моей dll-библиотеки.
Цитата
Anton написал:
Это все прекрасно, к стейту-то вы как доступ синхронизируете? Это можно сделать только той же критической секцией, которую внутренне использует квик, как вы до нее добрались?
  Во внутренние структуры квик я напрямую нигде не обращаюсь. Использую исключительно то, что предоставляет QLua и его C-API.
------
  Наконец, еще раз вспомним, что OS_Quesha (с dll оттранслированными для Lua 5.1) непрерывно (месяцами) без проблем работает во всех версиях QUIK <  8.5. и не будем забывать, что  начиная с марта 2020г..(уже 6 месяцев) появляются все новые и новые версии QUIK(8.5…, 8.6…, 8.7…, 8.8…), а их стабильности как не было так и нет. При этом, возникло много инцидентов именно с памятью этих версий.
 
Цитата
TGB написал:
единственное что при этом требуется
это создавать свой стейт для каждого своего потока и пользоваться только им в этом потоке. Ваш подход с разделяемым стейтом - это грязный хак, по случайности в 5.1 он у вас работал, а в 5.3 перестал, и это не проблема арки и не проблема луа, это чисто ваша проблема.
 
Мы имеем на на сегодня
Цитата
TGB написал:
начиная с марта 2020г..(уже 6 месяцев) появляются все новые и новые версии QUIK(8.5…, 8.6…, 8.7…, 8.8…), а их стабильности как не было так и нет. При этом, возникло много инцидентов именно с памятью этих версий.
а оказывается это
Цитата
Anton написал:
чисто ваша проблема
?????
 
Цитата
TGB написал:
?????
Конкретно ваша проблема создана конкретно вашими руками.
 
Цитата
Anton написал:
Цитата
TGB написал:
?????
Конкретно ваша проблема создана конкретно вашими руками.
Антон-брат, очевидно же, что у чувака чердак протёк конкретно ... это не словами, а это электричеством лечится ... :)
 
Цитата
TGB написал:
 Есть предложение от
12.08.2020 18:36:39
Цитата
TGB написал:
Я понимаю, что отказаться от перевода QUIK на Lua 5.3… для ARQU практически невозможно, но, если ориентироваться на результат, то имело бы смысл «заморозить» перевод QUIK на Lua 5.3… и перенести накопленные нормально работающие фичи версий >=8.5… (в том числе длину номеров заявок = 19   ) в последнюю версию 8.4…… В противном случае, скорее всего, нас ждет длительное шоу новых версий QUIK.
Хотелось бы увидеть реакцию от поддержки ARQU.

данное предложение не будет реализовано
 
Цитата
Sergey Gorokhov написал:
данное предложение не будет реализовано
Ожидаемо.
 
Добрый день.

Уважаемые пользователи, первое сообщение данной темы модифицировано: стала известна дата внедрения 19-значной нумерации заявок и сделок на срочной секции Московской Биржи. Это 14 сентября 2020 года. https://www.moex.com/n29676
 
   Появился QUIK 8.8.4.3   https://arqatech.com/ru/support/files/quik-workstation/
Мой тест управления автоматической памятью QLua диагностирует утечку памяти и некорректность ее функционирования.
   Жду следующую версию.
 
Здравствуйте, TGB.

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

В противном случае - просьба связаться с нами по почте quiksupport@arqatech.com и предоставить *.dmp-файл, получаемый в результате некорректной работы терминала для анализа.
 
Цитата
Andrey Bezrukov написал:
Правильно понимаем, что Вы уже обратились к нам по почте с данной проблемой, предоставили файл дампа и Вашему обращению был присвоен номер CQ, в рамках которого выполняется разбор?Если так - просьба ожидать резолюции по данному вопросу с нашей сторону в рамках обозначенной переписки по почте.
  Я ожидаю резолюции по данному вопросу с вашей стороны в рамках обозначенной переписки по почте.с 25.05.20.

  Вы правильно понимаете, что первое письмо по ситуации с управлением памятью в Qlua я написал 25.05.20. С тех пор мною написано по данной теме более 22 писем (с отсылкой большого количества возникших дампов). В том числе была послана поддержке (15.08.20) моя программа тестирования (со всеми необходимыми инструкциями) автоматической памяти QLua для возможности ее оперативного использования разработчиками для отладки новых версий.
-------------------------
   Заголовок моего последнего письма вы можете посмотреть в почте по адресу quiksupport@arqatech.com: RE: "Новая версия (от 24.08.20 ) QUIK 8.8.4. 3 продолжает «падать» ( CQ02750791, CQ02779753, CQ02787899. CQ02802279) (CQ02809006)."
-------------------------
  Я считаю, что надо соблюдать определенные профессиональные этические нормы, и не поднимать лишний хайп, мешающий разработчикам, которые и так испытывают большой стресс. Но когда я получаю, после уже посланных мною более 22-х писем, многократную отписку (сильно похожую от робота) типа (текст приводится в том виде, как получен в письме):
------
  Ваше письмо получено, проблема изучается. Постараемся в ближайшее время сообщить о причинах проблемы.
Если после возникновения проблемы Рабочее место QUIK не запускается, или после запуска проблема воспроизводится вновь - в качестве временного решения рекомендуется выполнить следующие действия:

1. В директории, где установлен Quik, удалите все файлы с расширениями *.log и *.dat, кроме файлов:

metastock.dat
alerts.dat
portfolio.dat
scripts.dat
После чего попробуйте запустить Рабочее место QUIK.

2. Проверьте, что Вы используете актуальную версию Рабочего места Quik - она указана вверху окна на синей полосе. У Вашего брокера можно уточнить, номер актуальной версии и/или получить обновление.

Если вышеприведенные рекомендации не помогут, то это означает, что файл с настройками окон поврежден. Перенесите файл настроек окон (по умолчанию это файл info.wnd) в другую директорию и запустите программу. Если у Вас есть ранее сохранённый файл конфигураций окон - можно попробовать загрузить его. Загрузить файлы настроек можно через меню "Настройки/Загрузить настройки из файла". Если Вы не сохраняли такой файл самостоятельно - файл настройки мог быть сохранен автоматически в папке WNDSAV.
---
то считаю, что я имею дело с непрофессионалами и поэтому могу  выдавать комментарии во вне.
   Я допускаю, что в моем тесте могут быть ошибки, но сильно настораживает то, что
Цитата
TGB написал:
OS_Quesha (с dll оттранслированными для Lua 5.1) непрерывно (месяцами) без проблем работает во всех версиях QUIK <  8.5. и не будем забывать, что  начиная с марта 2020г..(уже 6 месяцев) появляются все новые и новые версии QUIK(8.5…, 8.6…, 8.7…, 8.8…), а их стабильности как не было так и нет. При этом, возникло много инцидентов именно с памятью этих версий.
P.S.   OS_Quesha - это моя программа, в которой тестируется автоматическое управление памятью QLua.
 
     В продолжение своего предыдущего комментария.
   На своих проектах я использую следующую инструкцию по работе с пользователями (вдруг кому-то окажется полезной).

Памятка по работе с пользователями на проектах

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

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

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

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

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

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

 
Здравствуйте, TGB.

Да, ответ, который Вы получаете на Ваши *.dmp-файлы, с предложением удалить временные файлы программы (*.dat, *.log, *.wnd) - это автоматическая стандартная отбивка на присылаемые *.dmp-файлы.

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

По указанным номерам зафиксированных нами и указанных Вами инцидентов (CQ02750791, CQ02779753, CQ02787899. CQ02802279, CQ02809006) мы ведём активную работу и на момент данного ответа, вопрос о причинах утечки памяти и падения рабочего места остаётся открытым. По результатам разбора мы дадим ответ в рамках переписки по почте с соответствующим номером обращения в теме письма.

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

В противном случае - просьба ожидать ответ по уже зафиксированным обращениям.
 
   Здравствуйте,  Andrey Bezrukov

Цитата
TGB написал:
была послана поддержке (15.08.20) моя программа тестирования (со всеми необходимыми инструкциями) автоматической памяти QLua для возможности ее оперативного использования разработчиками для отладки новых версий.
  Вопросов по установке и использование этой программы по почте я не получил. Значит все понятно. В этой программе создается очень большая тестовая нагрузка на управление автоматической памятью QLua и обсуждаемые ситуации возникают (на моем рабочем месте) в интервале 5 минут. Притом, что в QUIK версий < 8.5 эта же программа работает непрерывно месяцами.  Я считаю, что для разработчиков эта программа могла бы быть полезным инструментом для разбора обсуждаемых ситуаций и мне не понятно почему до сих пор разработчики QUIK не используют его.  Зачем ждать от меня новых дампов после публикации очередной версии QUIK, когда можно их получать на текущих дорабатываемых версиях и разбираться оперативно на месте?
  Если есть какие-то вопросы к моей программе я готов к общению, но этих вопросов от разработчиков я по почте не получаю.
 
Вопрос к разработчикам: когда будет очередной релиз терминала или нам придётся торговать 14 сентября с помощью 8.8.4.3, про который ТОЧНО известно, что там РЕГУЛЯРНО происходят аварийные завершения работы из-за QLua?
 
Цитата
_sk_ написал:
Вопрос к разработчикам: когда будет очередной релиз терминала или нам придётся торговать 14 сентября с помощью 8.8.4.3, про который ТОЧНО известно, что там РЕГУЛЯРНО происходят аварийные завершения работы из-за QLua?
Версии с исправленными ошибками выходят регулярно.
Ответить на Ваш вопрос затруднимся, так как нужно как минимум номера обращений CQ, чтобы понимать о каких именно проблемах идет речь.
 
Сегодня не будет релиза? Надо знать, чтобы принимать решение о дальнейшей эксплуатации.
 
Интересует, исправлены ли ошибки, упомянутые тут:
https://forum.quik.ru/messages/forum10/message48049/topic5119/#message48049
Хоть это и не мои ошибки, внимательное чтение сообщений на форумах подсказывает, что основные причины проблем именно там. Потом эти проблемы могут по-разному проявляться у разных пользователей.
 
Цитата
_sk_ написал:
Интересует, исправлены ли ошибки, упомянутые тут:
https://forum.quik.ru/messages/forum10/message48049/topic5119/#message48049
Хоть это и не мои ошибки, внимательное чтение сообщений на форумах подсказывает, что основные причины проблем именно там. Потом эти проблемы могут по-разному проявляться у разных пользователей.
Из перечисленных проблем: CQ02750791, CQ02779753, CQ02787899. CQ02802279, CQ02809006
открытыми остаются CQ02802279, CQ02809006,
по остальным не найдены ошибки на стороне рабочего места QUIK.
 
Уважаемые разработчики, в версии QUIK 7.27.2.1 при исполнении скрипта LUA; при направлении заявки в терминал <sendTransaction(Transaction)> в ответ ничего не приходит. Хотя заявка на терминале сформирована и исполнена.
В ответ OnTransReply(order) все значения выдает как nil, и отследить исполнение заявки через <while StatusOrder == nil and Err_Order == "" do> теперь не представляется возможным. До недавнего времени все работало. Это может быть как-то связано с переходом на версию 8.5.
 
Добрый день.

Заявки по срочному рынку? Если да, то обновитесь до версии 8.5 или выше.
 
А где можно скачать последнюю версию?
Тут https://arqatech.com/ru/support/files/quik-workstation/ только документация.
 
Цитата
Sergey Denegin написал:
А где можно скачать последнюю версию?
Тут  https://arqatech.com/ru/support/files/quik-workstation/  только документация.
Добрый день.

Тут: ftp://ftp.quik.ru/public/updates/8.8/quik_8.8.4_upd.zip
 
Добрый день.
В одном из сообщений было сказано, что ваш тестовый контур срочной секции транслируется биржей.
Когда на нем появятся 19 знаков? А то как-то странно получается.
 
Цитата
Nikolay написал:
Добрый день.
В одном из сообщений было сказано, что ваш тестовый контур срочной секции транслируется биржей.
Когда на нем появятся 19 знаков? А то как-то странно получается.
Добрый день.

Это, к сожалению, зависит не от нас, а от игровой секции Московской Биржи.
 
Интересно, а как же тогда демо счет брокера Финам получает 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 вам мною моей программы, вы можете получать этих дампов столько, сколько захочете.
Кроме того, наблюдается утечка памяти.

---------

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

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

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

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

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

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

P.S.
Версиях QUIK < 8.5 мой тест управления автоматической памятью QLua ошибок не обнаруживает.
 
ты не утомился бред нести? ( это риторический вопрос - отвечать не нужно и  особенно в реальном времени г...г )

( далее тебе не обращено, это по случаю к пытливому читателю )

ПК это бытовой электроприбор - ключевое слово бытовой, ни о какой надежности и предсказуемости
и уж тем более гарантиях  тут речи  быть не может ни по железу, ни по софту
на 40-летней давности железе ( по базовому конструктиву )
на ломаной венде ( часто )
на бесплатном терминале ( всегда )
на брокерском договоре, где клиент всегда во всем виноват, все должен и на всё согласен ( всегда )

ПК это бытовой и в основном развлекательный девайс, а участие в рынка сидя за ПК - глупое, но веселое занятие
 
Цитата
новичок написал:
ты не утомился бред нести?

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

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

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

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

 
Цитата
новичок написал:


ПК это бытовой электроприбор - ключевое слово бытовой, ни о какой надежности и предсказуемости
"Бытовой" электроприбор, если это, скажем, древняя кофемолка, может служить десятилетиями. А "промышленное" оборудование, зачастую ломается чуть не еженедельно. Так что ваши ярлыки ничего не объясняют. Жить вообще смертельно опасно (смертность 100%).

Но это все не оправдание делать некачественно свою работу.
 
Цитата
TGB написал:
Вопросы к поддержке QUIK:.    У вас "новичок" является внештатным сотрудником ARQU?    А если это не так, то зачем вы тут (на форумах ARQU) его держите?
 
Цитата
Futurum написал:
А "промышленное" оборудование, зачастую ломается чуть не еженедельно.
ваши выводы исходят из фактического отсутствия  в РФ ИТ-индустрии как таковой, иначе бы вы знали разницу между промышленнм вычислятором с внутренним контролем исправности цепей со спец софтом, где С++ это оскорбление и бытовой балалайкой, на которой у вас квик  :)

Цитата
Futurum написал:
Но это все не оправдание делать некачественно свою работу.
к сожалению, но то, что глючит квик не значит, что там прям много косяков ... начинать нужно с уровния ОС ... хотя ошибки есть конечно, но они не только в АРКА - это уж точно
по-сему и предлагаю задуматься об итоговой солянке  и претензиях к ней стать фуа-гра: из горбыля будет всегда кривой забор, даже если его строят академики с титановыми молотками
 
Цитата
новичок написал:
Цитата
У плохого программиста всегда Windows виновата. А "спецсофт" - это для тех, кто не может/не хочет программировать так, чтобы программа работала всегда, везде и у любого дурака.

QUIK работает в целом на пятерку, и переход на 19-значные заявки прошел, по-видимому, гладко. Если уважаемый TGB вместе с разработчиками добьется лучшей работы с памятью, это будет только лучше для всех. Я не думаю, что нашим флудом стоит им мешать.
 
Цитата
Futurum написал:
Если уважаемый TGB вместе с разработчиками добьется лучшей работы с памятью
Проблема в том, что особо не видно драматических изменений в устройстве коллектора по сравнению с оригинальным луа, так что имеются основания полагать, что повреждение памяти это вторичное явление и ковырять коллектор суть пустая трата времени и сил, надо искать причины в более других местах. Вот обещали косячок с резервированием вечно одного слота стека поправить вскоре, там посмотрим, все ли было от него или еще что-то есть. Если же косяк на стороне самого луа, тут с арки какой спрос может быть, я б на их месте в принципе ни буквы не правил, иначе нельзя будет посылать в Рио пользователей с вопросами "а почему в луа так, а я хотел вот эдак".

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

P.S.Версиях QUIK < 8.5 мой тест управления автоматической памятью QLua ошибок не обнаруживает.
Все версии QUIK >=8,5 "падают" при запуске моего теста автоматической памяти QLua в интервале пяти минут.
Интересно, кому непонятно что это фундаментальная проблема нестабильности QLua (кроме аффилированных с ARQU лиц)?
 
Цитата
TGB написал:
Интересно, кому непонятно что это фундаментальная проблема нестабильности QLua
Я, я, я этот человек! (не аффилирован ежли кто не знал)
 
Цитата
Anton написал:
Я, я, я этот человек! (не аффилирован ежли кто не знал)
Зря вы это написали.
 
Цитата
TGB написал:
Зря вы это написали.
Ничего нового не написал. С наличием в qlua косяков никто (включая арку) не спорит. Чтобы сказать, что есть косяк управления автоматической памятью, нужно показать, что либо а) коллектор собирает объекты, не помеченные мусорными, либо б) коллектор не собирает объекты, помеченные мусорными. Ничего такого пока показано не было. Все остальное это уже не вопрос управления автоматической памятью.

 
Цитата
Anton написал:
нужно показать, что либо а) коллектор собирает объекты, не помеченные мусорными, либо б) коллектор не собирает объекты, помеченные мусорными. Ничего такого пока показано не было. Все остальное это уже не вопрос управления автоматической памятью
  А может быть, вместо ARQU, мне написать и всю потокобезопасную Lua - машину, встроенную в QUIK?  Для тех, кто понимает, это очень большие деньги за выполнение такой работы (как минимум: 7 месяцев * <Среднее количество разработчиков> * <Среднюю зарплату>). Как это сделать я понимаю. Но в любом случае, это сложная работа (и не всеми реализуемая), и я сочувствую разработчикам QUIK, "парящимся" над тем, как реализовать потокобезопасную уборку мусора QLua.  Даже мой "хилый" тест (который, похоже, не был реализован  ARQU за десятилетия своего существования хоть в каком-то виде), позволяющий, в оперативном режиме тестировать автоматическое управление памятью QLua, при его заказе на стороне, стоил бы, наверное, больших денег. Я его выслал поддержке QUIK без предоплаты.
 
Цитата
TGB написал:
Я его выслал поддержке QUIK без предоплаты.
Если речь о том тесте, что предлагался неоднократно всем и каждому, то лично мне (не арке; им, возможно, все понятно) непонятно, что он тестирует. Скажем, у мну есть длл, которая вместе с квиком уронит и винду с вероятностью 100%. Причем только в квике, в консольном луа той же версии ничего такого не случится. Можно ли подогнать под нее какое-нибудь обоснование и обвинить арку в чем-нибудь? Желательно, конечно, с предоплатой, но и с оплатой постфактум я тоже согласный.
Страницы: Пред. 1 2 3 4 5 След.
Читают тему
Наверх