Обеспечение возможности использования 19-разрядных № заявок для версий QUIK < 8.5
Пользователь
Сообщений: Регистрация: 12.05.2020
26.07.2020 20:19:57
Как и предполагалось (смотри мой комментарий от 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 это понимают).
Дополнение к выше приведенному ответу. QUIK не управляет потоками. Ими управляет ОС. Но в реализации QLua есть отличие от "чистого" Lua, состоящее в том,что виртуальная машина QLua реализует собственное, потокобезопасное управление автоматической памятью QLua (запрос памяти под объекты QLua, возврат памяти, сборка мусора). Это правильно, и обусловлено тем, что все служебные функции обратного вызова QLua запускаются в потоке отличном от пользовательского (с именем main), но в среде (памяти) пользователя. Тут возникает только один вопрос: насколько эффективно в QLua реализовано это управление автоматической памятью? Но главным является то, что до версии QUIK 8.5, похоже это было реализовано достаточно корректно.Начиная же с версии QUIK 8.5 (а это переход c Lua 5.1 на 5.3, в котором существенно изменилось управление автоматической памятью) и вплоть до версии 8.8.0.55 при запусках моего теста управления автоматической памятью QLua в произвольные моменты времени возникают дампы ( все они пересланы мной в поддержку ARQU). Пока в версии >= 8.5 не будет реализовано корректное (пусть и не самое эффективное) потокобезопастное управление автоматической памятью версий QLua >= 8.5, QUIK будет нестабильным (надеюсь что разработчики QUIK это понимают).
Обеспечение возможности использования 19-разрядных № заявок для версий QUIK < 8.5
Пользователь
Сообщений: Регистрация: 12.05.2020
24.05.2020 10:40:12
Цитата
Anton написал: как она похорошела при в 8.5.2. Еще пара штрихов и будет не хуже по крайней мере старых 32-битных версий, а если обещанное выкатят в ближайшем релизе, то кое-в-чем уже лучше будет.
Я бы, на месте АРКИ, платил вам зарплату .
Обеспечение возможности использования 19-разрядных № заявок для версий QUIK < 8.5
Пользователь
Сообщений: Регистрация: 12.05.2020
24.05.2020 10:19:07
Цитата
Anton написал: Куда этот 32-битный квик ставить-то.
32-битный квик легко ставится в W10 64р. И Microsoft будет продолжать поддерживать 32 р. приложения в 64р. Windows (у нее самой немало 32р. приложений). У меня в W10 (64р.) на одном ПК установлены QUIK 7..., 8.. и 8.5... Все работает, но только 8.5.... часто "падает" и не надо мне рассказывать как нужно искать мои ошибки (которые, конечно же случаются).
Обеспечение возможности использования 19-разрядных № заявок для версий QUIK < 8.5
Пользователь
Сообщений: Регистрация: 12.05.2020
24.05.2020 09:01:21
Цитата
Anton написал: Чет вспомнил про луддитов. Флешмоб за процессоры, которые 15 лет как сняты с производства, и оси, поддержка которых закончилась полгода назад. Это надо было на интеле и майкрософте устраивать и сильно раньше, теперь поезд ушел уже. Что интересно, вышеименованный продукт создан в студии 2015, которая не то что на хрюшу, на семерку-то не встает. Внезапно.
Увеличение номера заявки до 19 разрядов это, конечно, прорыв в будущее .
Вообще, приходится постоянно наблюдать как производители, особенно монополисты, нередко специально «понуждают» потребителей переходить на новые продукты и это часто связано не с заботой о «прогрессе», а для «бабло срубить». Ни на что не намекаю.
А если конкретно, то в данной теме обсуждается не перенос «фич» из новой версии 8.5 в старые, а всего навсего обеспечение очень старой функциональности работы с заявками.
Обеспечение возможности использования 19-разрядных № заявок для версий QUIK < 8.5
Похоже, поддержка QUIK в данной теме не появится. Но я на это особо и не рассчитывал. Им это все по барабану. Надо понимать, что музыку заказывает тот, кто платит, а деньги АРКА за QUIK, как правило, получает непосредственно от наших брокеров (у которых наша плата за QUIК входит в оплату за предоставляемые ими услуги). Поэтому, если кому-то хочется быть услышанным АРКОй, это надо делать, скорее всего, через своего брокера. Так будет для АРКИ доходчивее.
Обеспечение возможности использования 19-разрядных № заявок для версий QUIK < 8.5
Пользователь
Сообщений: Регистрация: 12.05.2020
22.05.2020 17:50:14
Цитата
Anton написал: Вообще риторика "да там делов на два часа" очень знакома. Обычно такой заказчик приходит с копеечным бюджетом и потом пытается еще и с оплатой прокинуть, либо, в лучшем случае, попросить "ыщо малость доработать" (ну то есть вообще с нуля и по-другому) за тот же прайс. Ни на что не намекаю, просто наблюдение.
Вы намекаете на разработчика ОПЕРАЦИОННАЯ СИСТЕМА РАЗРАБОТКИ МНОГОПОТОЧНЫХ РОБОТОВ ТОРГОВЛИ ЦЕННЫМИ БУМАГАМИ В QUIK «OS_QUESHA», выложившего (в комментариях статьи) ссылки на нее для бесплатного использования в некоммерческих целях
Обеспечение возможности использования 19-разрядных № заявок для версий QUIK < 8.5
Пользователь
Сообщений: Регистрация: 12.05.2020
22.05.2020 13:04:44
Цитата
написал: Вы поддержите фининсово, оплатите необходимую вам работу - и разработчики с удовольствием все сделают. У вас есть лишние деньги , изменяющиеся сотнями тысяч рублей или все проще поставить версию 8?
Интеллектуальная поддержка: ---- Номер заявки можно оставить строковым. В С++: Перевод строки в INT64: INT64 value = _atoi64(input); Обратный перевод: _i64toa_s(value, input, 20, 10); Дополнительные пояснения. Наверное, почти все знают, что из QLua можно обращаться к функциям, написанным на C++. И за 2-3 :) дня можно было разработчику QUIK, используя приведенные выше две строки, написать две функции, каждая из которых была бы длиной не более 6-ти строк.
Обеспечение возможности использования 19-разрядных № заявок для версий QUIK < 8.5
Пользователь
Сообщений: Регистрация: 12.05.2020
22.05.2020 12:14:03
Переход на QUIK 8.5..... для многих пользователей порождает проблемы связанные как с нестабильностью новой версии, так и с необходимостью перевода своих прикладных программ c Lua 5.1 на Lua 5.3. Пусть бы энтузиасты "покувыркались" бы с новыми версиями, а консерваторы занимались бы своими делами. 19-ти разрядные № заявок в старых версиях реализовать не сложно и это хорошо бы сделать. Разработчику QUIK это было бы только в плюс.
Грядущие изменения на срочном рынке МБ: поддержка работы с 19-значными номерами заявок и сделок
Пользователь
Сообщений: Регистрация: 12.05.2020
19.05.2020 16:07:21
Цитата
Цитата Sergey Gorokhov написал:Ничего кроме того что нужно написать функцию которая будет его дергать. ----------------------------------
TGB В С++ Перевод строки в INT64: INT64 value = _atoi64(input); Обратный перевод: _i64toa_s(value, input, 20, 10);
Дополнительные пояснения. Наверное, почти все знают, что из QLua можно обращаться к функциям, написанным на C++. И за 2-3 :) дня можно было разработчику QUIK, используя приведенные выше две строки, написать две функции, каждая из которых былабы длиной не более 6-ти строк.
Грядущие изменения на срочном рынке МБ: поддержка работы с 19-значными номерами заявок и сделок
Пользователь
Сообщений: Регистрация: 12.05.2020
19.05.2020 15:11:00
Цитата
Sergey Gorokhov написал: Ничего кроме того что нужно написать функцию которая будет его дергать.
В С++
Перевод строки в INT64: INT64 value = _atoi64(input); Обратный перевод: _i64toa_s(value, input, 20, 10);
Уведомление о необходимости обновления торговых терминалов в связи с изменениями на срочном рынке Московской биржи, Список проблем при работе устаревших версий QUIK после обновления торговой системы срочного рынка МБ
Пользователь
Сообщений: Регистрация: 12.05.2020
14.05.2020 19:58:30
Цитата
Цитата
Anton написал: По каждому тику квику пришлось бы:1) искать строку с номером заявки в хранилище луа2) не находить ее, выделять память, пихать новую строку в хранилище луа3) дергать колбек4) убивать ссылку на строку5) через каждые несколько тиков луа придется собирать мусор.Это было бы не просто медленно, это убило бы вообще все, квик бы плелся как черепаха и зависал от каждого движения мышки.
А выше написано о чем? В самих значениях строки (таблицы) есть и строки и числа. Ну что из этого? Все это находится в управляемой памяти и под уборку мусора. Вообще, я думаю, что каждый из нас может остаться при своем мнении.
Уведомление о необходимости обновления торговых терминалов в связи с изменениями на срочном рынке Московской биржи, Список проблем при работе устаревших версий QUIK после обновления торговой системы срочного рынка МБ
Пользователь
Сообщений: Регистрация: 12.05.2020
14.05.2020 19:24:04
Цитата
Anton написал: Как и где вы посмотрели? Луа возвращает тип number для номера сделки, в alltrades.dat они лежат в виде 64-битных целых (просто поверьте). Так где вы строки увидели?
После заказа данных создайте "Таблицу обезличенных сделок". И далее запустите скрипт:
local all_trades = getItem("all_trades", 10)
message( "------------------------------"); for i, v in next, all_trades do message(type( i) .. " " .. i); end
Уведомление о необходимости обновления торговых терминалов в связи с изменениями на срочном рынке Московской биржи, Список проблем при работе устаревших версий QUIK после обновления торговой системы срочного рынка МБ
Пользователь
Сообщений: Регистрация: 12.05.2020
14.05.2020 18:46:58
Цитата
Anton написал: TGB написал:Почему нельзя сделать. чтобы номер заявки был текстовой переменной?
Так и думал, что это будет приведено. Потому что есть например OnAllTrade. По каждому тику квику пришлось бы:1) искать строку с номером заявки в хранилище луа2) не находить ее, выделять память, пихать новую строку в хранилище луа3) дергать колбек4) убивать ссылку на строку5) через каждые несколько тиков луа придется собирать мусор.Это было бы не просто медленно, это убило бы вообще все, квик бы плелся как черепаха и зависал от каждого движения мышки. И это только одно.
Я специально посмотрел записи таблицы "all_trades" в QUIK 8.5.1.18. Все поля ее записей строковые. Поэтому я не понял что вы написали в вашем сообщении. Вообще, если же спуститься на "землю", а именно, посмотреть реальную работу QUIK версий 7.27.2.1., 8.3.2.4 и 8.5.1.18, то никаких чудес быстроты функционирования последних двух относительно первой я не заметил (понятное увеличение размера кода это конечно же мелочь).
Уведомление о необходимости обновления торговых терминалов в связи с изменениями на срочном рынке Московской биржи, Список проблем при работе устаревших версий QUIK после обновления торговой системы срочного рынка МБ
написал: эффективное использование ресурсов ПК (низкая нагрузка).
ай-ай, а как же тогда с этим? - пускать софтину чуть ли не в сэнд-боксе ?
неувязочка :)
хотя действительно ... зачем делать 64-битный софт в 64-битной ОС на 64-битном ЦПУ ... глупость какая-то
давай, поясни как это полностью неправильно :)
и вот это тоже до кучи
Цитата
Цитата
По 1-му пункту: мне долго вам объяснять, что 32-ух разррядные приложения в 64р. Windows 10 могут выполняться часто даже быстрее, чем 64 разрядные. Погуглите.
По 2-му пункту есть нормальное решение
Цитата
Sergey Denegin написал: А что никак нельзя обойтись без луа 5.3 чтобы отправлять номера заявок 19и разрядные? например из двух частей. Почему нельзя сделать. чтобы номер заявки был текствой переменной? Мне не совсем понятно, почему ради каких -то 19и значных номеров пользователи должны ставить себе новую винду? Это сверх НЕ клиентоориентированный подход, неужели руководство квика считает, что они не потеряют клиентуру?
Уведомление о необходимости обновления торговых терминалов в связи с изменениями на срочном рынке Московской биржи, Список проблем при работе устаревших версий QUIK после обновления торговой системы срочного рынка МБ
Ну, наверное, всем известно, что 64р. Windows 10 поддерживает 32р. приложения.
Уведомление о необходимости обновления торговых терминалов в связи с изменениями на срочном рынке Московской биржи, Список проблем при работе устаревших версий QUIK после обновления торговой системы срочного рынка МБ
Пользователь
Сообщений: Регистрация: 12.05.2020
14.05.2020 10:26:59
новичок и есть новичок
Уведомление о необходимости обновления торговых терминалов в связи с изменениями на срочном рынке Московской биржи, Список проблем при работе устаревших версий QUIK после обновления торговой системы срочного рынка МБ
Пользователь
Сообщений: Регистрация: 12.05.2020
14.05.2020 10:09:43
Вопросы к поддержке QUIK: 1) чем вызвана необходимость перевода рабочего места клиента QUIK на 64р. архитектуру (что нельзя было делать клиентам на 32р)? 2) чем вызвана необходимость перевода рабочего места клиента QUIK на Lua 5.3 (соображения, что это модно не интересны)? 3) была ли какая-то оценка проблем, которые могут возникнуть у клиентов, да и у самого разработчика?
Что мне, как пользователю рабочего места клиента QUIK, нужно: надежность, удобство, оперативность выполнения функций, наглядность, эффективное использование ресурсов ПК (низкая нагрузка). Все остальное мне, как я думаю и большинству клиентов, не интересно. Кроме того, важнейшим показателем рабочего места клиента QUIK является стабильность его архитектуры, обеспечивающая стабильность среды разработки моих прикладных программ. Нам, непосредственно работающим на фондовом рынке, за постоянное перестраивание своих программ под постоянно меняющуюся архитектуру денег не платят. Какие из перечисленных выше требований к рабочему месту трейдера нельзя было реализовать в архитектуре QUIK 7? Поддержку 19-разрядных номеров можно было реализовать в архитектуре QUIK 7. Если, у кого-то в этом есть сомнения, то я готов изложить как это можно было сделать.
.