QUIK (версия 7.0.1.5)

Страницы: Пред. 1 2 3 4 5 След.
RSS
QUIK (версия 7.0.1.5), function OnTrade(trade), трехкратный вызов на одно событие.
 
Звучит заманичво, но ничего не понял. Какой движок? Если есть желание подсказать, то разъясните, пожалуйста. Очень уж интересно что имеется ввиду.
А так да, здорово звучит!
 
для начала,

https://forum.quik.ru/messages/forum10/message5490/topic151/#message5490
 
смысл в том, что - использование стандартных коллбеков квика - не панацея, если вы хотите, чтоб ваши роботы "паслись" на разных бумагах/параметрах. если вам надо динамически отключать/подключать ботов к параметрам/бумагам - то, вам по-любому придётся мыслить (начинать по кр. мере) в масштабах своего торгового движка. и один их подходов, как и результатов  - вам был (мельком) озвучен.

"хай-энд"-ом для вас станет добавление в стандартное меню квика своих вкладок, а также, - создание своей ленты новостей - НО!! Разработчики вам этого - не простят. Поэтому - это останется для вас - на ваше, сугубо личное усмотрение (без разрешения к свободному распространению).
 
Эх, чувствую, тема интересная, но пока для меня не подъемная.
Спасибо!
 
Сегодня тема множественных колл-бэков в моём скрипте раскрылась с новой стороны.

Напомню,    выше я публиковал, что в обработчике OnTradeDo(trade) делаю проверку, чтобы исключить повторную обработку одной и той же сделки.
Т.е. в ответ на сделку происходит выставление гарантированно только одной ответной заявки.
Сегодня этот уже 10 дней стабильно работающий в версии 7 скрипт в ответ на отсылку одной транзакции sendTransaction(trans_params)
получает в ответ выставленными ДВЕ одинаковые заявки, с незначительными отличиями: номер заявки, выставлена (мкс) и id. Причём в одной из них поле id заполнено, а в другой нет.

Задваивание происходит иногда.
Когда задваивания не происходит, то единственная новая заявка имеет пустое поле id.


См. рис:   Парные заявки по одной транзакции
На рисунке показаны 2 пары задвоенных заявок в ответ на один в каждом случае вызов sendTransaction(trans_params)

По своим логам я уверен, что был один и только один вызов sendTransaction(trans_params)

До 7-й версии Квика ничего подобного со скриптом не случалось.
Что делать и как с этим бороться?
 
Пишу в догонку: вопрос снимается.
Оказалось, к одному и тому же счёту было подключено 2 скрипта с квиков разных версий, расположенных на разных серверах и действия скриптов дублировались.
Сорри!
 
А в этом моём нештатном случае, когда к одному счёту оказались по ошибке подключены 2 разных квика разных версий, существует способ из анализа таблиц узнать скриптом Квика1, что та или иная заявка выставлена не этим, а другим Квиком2?
В заявках виден UID и UID снявшего заявку. Но они одинаковы у Квика1 и Квика2.
Отличия косвенные я заметил только в том, что Квик1 (версия 7) проставляет id, а Квик2 версии 6 оставляет это поле пустым.
Может быть, ещё какие-то признаки есть?
Хотелось бы сделать в скрипте дополнительную "защиту от дурака".
 
Цитата
XXM пишет:
Цитата
Sergey Gorokhov пишет:
Как уже было сказано и еще раз повторю, трансляция нескольких OnTrade есть, будет и от этого избавляться не планируется, по уже озвученным причинам.
Это значит что если данная реализация приводит к неудобству, предложите способ его избежать и мы зарегистрируем пожелание. Варианты типа "сделайте как было" не принимаются.
На вскидку, например можно подумать над добавлением порядкового номера обновления для каждой сущности.
1, 2, 3 и т.д. Тогда, в коде можно будет фильтровать по номеру обновления if num=1 then.

Если возражений нет, предлагаю зарегистрировать такое пожелание.
Это отличный способ.
Возражений нет, зарегистрируйте, пожалуйста!
Добрый день,
Мы рассмотрели Ваше пожелание. По итогам его анализа сообщаем Вам, что реализация пожелания признана потенциально целесообразной. Если по результатам дальнейшего анализа, включающего юридические аспекты, анализ на непротиворечивость с общей политикой компании, никаких возражений не возникнет, мы постараемся включить Ваше пожелание в план доработок при выпуске одной из следующих версий нашего ПО.
 
Это не проблема LUA а общая "особенность" Квика. На Tran2Quik.dll то же самое. Лучше конечно было бы вынести обсуждение из-под ветки LUA чтобы прочие юзеры всех API это могли найти. Но это уж на усмотрение модераторов.
Пока наилучшим решением считаю держать множество всех пришедших номеров сделок и повторные приходы не обрабатывать. По крайней мере для тех кому не нужна новая инфа типа trans_id, uid.
Список ограничить по размеру и закольцевать чтобы самые свежие номера затирали самые старые.
 
Цитата
Sergey Gorokhov пишет:
Можно использовать комментарий.
Является ли параметр brokerref в колбэке OnTrade необновляемым, т.е. проставляется ли он в первом же колбэке в обязательном порядке?
Надо делать так, как надо. А как не надо - делать не надо.
 
Цитата
Старатель пишет:
Цитата
Sergey Gorokhov пишет:
Можно использовать комментарий.
Является ли параметр brokerref в колбэке OnTrade необновляемым, т.е. проставляется ли он в первом же колбэке в обязательном порядке?
Параметр brokerref приезжает с биржи вместе с телом сделки. иными словами да он не обновляемый
 
Цитата
Цитата
Sergey Gorokhov пишет:
Здравствуйте,
Начиная с последнего обновления сервера, таблица сделок стала обновляемой.
Поэтому событие OnTrade может срабатывать по нескольку раз
Это не ошибка, так и должно быть
Цитата
Sergey Gorokhov пишет:
На сделке, которая является сущностью торговой системы нет некоторых полей, которые есть в QUIK
В частности это UID, TRANS_ID а также набор флагов и ряд других специфичных параметров
Серверу чтобы проставить эти обновленные параметры приходится отправлять сделку несколько раз.
Иначе, отправка сделки задерживалась бы до установки всех параметров, что гораздо хуже чем получить подряд несколько обновлений.
Сергей, поясните, пожалуйста, что в таком случае произойдёт, если я, например, выставил заявку на покупку 2 лотов. Она частично исполнилась и я получил несколько срабатываний OnTrade с qty=1. Затем исполнилась вторая часть этой заявки и я снова получу несколько срабатываний OnTrade с qty=1? А как в таком случае понять, что исполнилась ВСЯ заявка полностью?
 
Цитата
Илья Грачёв пишет:
А как в таком случае понять, что исполнилась ВСЯ заявка полностью?
Важно чтобы Вы понимали что приход нескольких OnTrade совершенно не означает что это разные сделки.
Таким образом Вы можете настроить фильтр дублей, например по номеру сделки.
Также можно решить задачу проверяя OnOrder
 
Нас
Цитата
Sergey Gorokhov пишет:
Цитата
Илья Грачёв пишет:
А как в таком случае понять, что исполнилась ВСЯ заявка полностью?
Важно чтобы Вы понимали что приход нескольких OnTrade совершенно не означает что это разные сделки.
Таким образом Вы можете настроить фильтр дублей, например по номеру сделки.
Также можно решить задачу проверяя OnOrder
Цитата
Sergey Gorokhov пишет:
Цитата
Вячеслав пишет:
Сразу добавили, и пусть хоть "Почтой России" доставляют. Куда спешить?
Лично Вам некуда спешить, а для других пользователей скорость появления сделки может быть критичной
Насколько я могу судить, проблема возникла из-за того, что в связи с вводом понятия обновляемых параметров, в интерфейсе callback-функций была изменена логика их работы. Если первоначально методы обратного вызова сообщали о свершившемся факте изменения объекта (заявка снята, транзакция исполнена и т.п. - т.е. об ОКОНЧАНИИ такого изменения), то теперь функции обратного вызова сообщают о НАЧАЛЕ изменения объекта, когда объект ещё находится в промежуточном, переходном состоянии и его внутренняя структура ещё не перешла в устойчивое состояние, а поля объекта ещё не успели принять свои непротиворечивые значения, свойственные его новому состоянию. Естественно, что такая логика требует дополнительных уведомлений в процессе перехода объекта из одного состояния в другое.

Мне кажется, что было бы неплохо, если бы сотрудники ARQA перешли к общепринятой практике не менять уже опубликованные интерфейсы, а лишь наращивать их функциональность по мере необходимости. В данном случае достаточно было вместо изменения логики работы методов старого интерфейса добавить туда новые (что-нибудь вроде OnTrade2, OnTransReplay2 и т.п.), которые реализовали бы идею предварительного уведомления пользователя о начале изменения объектов. И тогда все были бы довольны: как пользователи прежнего интерфейса (т.к. им не пришлось бы вносить никаких изменений в свои программы), так и те, кому потребовалось получать уведомления об изменении как можно раньше (они получали бы серию срабатываний callback по новому интерфейсу и одно окончательное - по старому). Кстати, заметьте, что в этом случае, раз уж им так важна скорость, то можно было бы сэкономить и на размере передаваемых данных, т.к. всё равно значительная часть полей в предварительном сообщении ещё не получила своих значений (равна nil).

Повторюсь, это устроило бы всех, в том числе и самих сотрудников AQRA, попавших после доработки софта в дурацкое положение и вынужденных десятками раз отвечать на одни те же вопросы.
 
Ну да уж, что сделано, то сделано. Скажите, а вы могли бы зарегистрировать следующее пожелание?
Добавить к уже имеющимся callback-методам такие, которые вызывались бы один раз в конце перехода объекта из одного состояния в другое (что-нибудь типа OnOrderChanged, OnTransCompleted и т.п.).  
 
В версии 7.0.4.10 есть такой прикол.
-------------------------------------
Если происходит обращение к функции, которой нет, т е по адресу nil,
то вместо сообщения типа "отсутствует функция XXX" ,
происходит аварийное завершение квика с предложением послать дамп разработчикам.
--------------------------------
В версиях 6 такая ситуация обходилась молчанием и без аварии.
Тоже было прикольно.
------------------------------
Предложение:
Реализовать нормальное обработки такой ошибки,
с сообщением об отсутствии функции
и без аварийного завершения КВИКА.
Спасибо
 
Добрый день.

Николай, можете выложить скрипт на котором воспроизводится проблема.
У себя воспроизвести не удалось.
 
дело в том, что раньше в версии 6 я вообще последние полгода не получал аварийных сообщений
поставил 7.0.4.10 и за 2 дня 30 штук дампов.
просто уже задолбало.
--------------------------------
Уж лучше бы оставили как было. Нет функции скрипт молча ничего не сообщает и не вылетает.
Долго приходтся соображать почему ничего не рисует. Но найти ошибку все же проще, не надо каждый раз снова грузить КВИК.
-----------------------------------
При этом размещаю индикатор на графике.
все нормально. снимаю индикатор. ставлю его же снова - получаю дамп. снова загружаюсь. Ставлю тот же индикатор - все нормально.
Потом может и не вылететь при повторной установке а может и слететь.
все дампы отослал Вам как и просили в сообщении на почту support.
 
Запустил 2 демо-счета.
На одном QUIK версии 6.17.1.17, на другом - 7.0.4.10.
Сервер подключения - один и тот же.
Проверил OnTrade(). Результаты:

QUIK версии 6.17.1.17
Скрытый текст



QUIK версии 7.0.4.10
Скрытый текст

Итак, QUIK 7 как получал три абсолютно идентичных отклика, так и продолжает получать. Обещанный порядковый номер отклика так и не реализован.
Но при всем при этом, QUIK версии 6.17.1.17 все же получает один ответ OnTrade. Он их как-то отличает и выдает только один из трех?
Тут не совсем ясно, пользовательский терминал генерирует три вызова OnTrade на 7-ом и один на ранних версиях, или серверная часть их шлет?
Lbot3D
 
Прошу разработчиков зарегистрировать пожелание:
Ни в коем случае не делать никаких trans_id=nil !!

В руководстве четко прописано что поле trans_id имеет тип NUMBER. Соответственно программисты (в частности я) в своих скриптах считают что в этом поле может быть только число. В Lua значение nil это отдельный тип переменной, и например выражение t.trans_id>0 приведет к ошибке и вылету скрипта. Почему я должен перелопачивать десятки тысяч строк кода в десятках своих скриптов и вводить множество ненужных проверок, из-за того, что кому-то вдруг приспичило получать nil?

2 Старатель.
Вы упорно не хотите принять положение, что теперь некоторые параметры сделки могут измениться. Нет никакой разницы, что присылать по-умолчанию, 0 или nil. Надо просто понимать, что теперь теоретически возможна ситуация что сначала пришло t.trans_id=12345 а через минуту придет t.trans_id=67890. Разработчики наверное потому и не хотят выкладывать список "неизменяемых" параметров, что теоретически может поменяться любой параметр. Они сделали систему для общего случая для произвольной биржевой площадки. Как с этим общим случаем работать - это уже геморрой программистов.
 
Цитата
Нет никакой разницы, что присылать по-умолчанию, 0 или nil.
Есть большая разница в том получили ли мы значение параметра и оно равно нулю или значение параметра ещё не получено.
Аргументы я уже приводил в этой теме: ситуации, когда значение параметра может читаться двояко.
Нельзя при получении trans_id=0 выполнить сначала одно действие, а потом, когда через минуту придёт trans_id=67890 переиграть всё обратно.
Тоже касается и других таблиц: QUIK вам показывает ноль, когда в действительности с биржи ничего не пришло, что зачастую вносит путаницу.

Цитата
например выражение t.trans_id>0 приведет к ошибке и вылету скрипта.
Замените на t.trans_id ~= nil and t.trans_id>0, и скрипт вылетать не будет  :wink:
Надо делать так, как надо. А как не надо - делать не надо.
 
Цитата
Вы упорно не хотите принять положение, что теперь некоторые параметры сделки могут измениться.
В этом мнении я полностью солидарен со Старателем.
Не апеллирую к nil или 0, однако в коде программисту нужно всегда иметь
* возможность идентифицировать, какие поля пришли в OnTrade, а какие нет;
* также желательно знать, какие поля ещё придут.
* и обязательно знать, какие поля больше не будут меняться.

Иначе программирование сводится к гаданию на кофейной гуще (что же нам пришло и ещё придёт...?),
и писать надёжный код, которых не перестанет работать после обновления терминала Quik
(про обратную совместимость я вообще молчу).

Организации Arqatech я могу только посоветовать найти нового архитектора ПО (или учредить такую должность, если она отсутствует).

В качестве решения (и пожелания), я бы мог предложить в OnTrade() передавать ещё таблицу со списком имён, которые ещё могут поменяться.
Код
function OnTrade(order)
    local pf = order.pending_fields;
    -- пример:
    -- order.pending_fields = {
    --     ["qty"] = true,
    --     ["price"] = true
    -- };
    -- вместо true можно использовать любое другое значение отличное от false, чтобы было удобно проверять наличие поля в хеше:
    -- if order.pending_fields["order_num"] then 
    --     -- .....
    -- end
    local msg = "Поля: "
    for k,_ in pairs(pf) do
        msg = msg..tostring(k).." ";
    end
    msg = msg .. " ожидают изменения".
    message(msg);
end


 
 
P.S. или со списком имён, которые больше не будут меняться - это не принципиально.

Главное - дать программисту возможность сконструировать для каждого из пунктов (*) в сообщении выше выражение, которое бы возвращало тип boolean.

(Не важно, как оно будет выглядеть на Lua - важно, чтобы его можно было использовать, а также желательно, чтобы его использование было немного очевидно.)
 
Здравствуйте,
Мы не можем зарегистрировать пожелание не делать другое пожелание.
Если есть четкие аргументы его не делать, то мы просто добавим их к уже имеющемуся пожеланию и при рассмотрении пожелания они будут либо учтены либо нет. и далее поступит ответ в ветке форума где было пожелание зарегистрировано (то есть в этой).
Собственно Ваш комментарий был добавлен к пожеланию
 
Цитата
Обещанный порядковый номер отклика так и не реализован.
Никто не говорил что его уже реализовали. Пожелание да зарегистрировано, но это не значит что оно прям в следующей же версии будет реализовано. Следите за новостями.

Цитата
Но при всем при этом, QUIK версии 6.17.1.17 все же получает один ответ OnTrade. Он их как-то отличает и выдает только один из трех?
Сервер знает какой терминал к нему подключается и в зависимости от версии отправляет данные по разному.
Во времена версии 6.17 таблица сделок еще не была обновляемой. Поэтому старые терминалы не приспособлены для обновления параметров.
Туда приходит только первый колбэк.
Цитата
Тут не совсем ясно, пользовательский терминал генерирует три вызова OnTrade на 7-ом и один на ранних версиях, или серверная часть их шлет?
Пользовательский терминал ничего не генерирует. Терминал показывает то что ему шлет сервер. И столько раз сколько пришлет ему сервер.
 
Цитата
Пожелание да зарегистрировано, но это не значит что оно прям в следующей же версии будет реализовано. Следите за новостями.
Понятие "разумные сроки" не вписывается в вашу философию.
Все пункты теста Джоэла (12 шагов к лучшему коду) вам не пройти.

Цитата
Сервер знает какой терминал к нему подключается и в зависимости от версии отправляет данные по разному.
Ясно.

Цитата
Туда приходит только первый колбэк.
Значит он (сервер) отличает ее от следующих!
Так внесите этот отличительный признак в отправляемую OnTrade!
Большего от вас я не прошу. Сделайте же хоть что-то.
Lbot3D
 
Цитата
Понятие "разумные сроки" не вписывается в вашу философию.
ознакомьтесь с регламентом
https://forum.quik.ru/forum8/topic13/

Цитата
Значит он (сервер) отличает ее от следующих!
Вы в коде тоже можете проверять только первый колбек, например сравнивая номер сделки.
 
Цитата
ознакомьтесь с регламентом
Там ни слова про "разумные сроки" : )
quod erat demonstrandum
Цитата
Вы в коде тоже можете проверять только первый колбек, например сравнивая номер сделки.
Вопрос не стоит "как отличать колбэк одной сделки от колбэка другой сделки"!

Я хотел бы отличать первый колбэк OnTrade от сделки от второго и прочих колбэков OnTrade этой же сделки.
Lbot3D
 
чтобы "отличить" надо дождаться реализации пожелания.
когда оно будет реализовано определяется при рассмотрении.
Следите за новостями.
 
В моем сообщении от 08.02.2016 №119  приведен протокол OnTrade() QUIK версии 7.0.4.10.
Время всех трех колбэков (АБСОЛЮТНО ИДЕНТИЧНЫХ) одно и то же, с точностью до миллисекунд: 14:27:54,046
Вы говорите: "Начиная с последнего обновления сервера, таблица сделок стала обновляемой."
Но факты говорят, что OnTrade() шлет тройной отклик. Повторяю: шлет тройной отклик!
Ваша "обновляемая таблица сделок" была обновляемой, если бы:
а) Время колбэков отличались бы друг от друга;
б) Они несли бы отличающиеся друг от друга в чем-то данные.
Ни того ни другого не наблюдается.
Да, вы писали:
Цитата
Серьезно, обновляются те поля которые пока еще не доступны в LUA
"...пока..." С прошлого года! Все еще недоступны!
Дайте хоть бит дополнительный: первый - "1", не первый - "0"!
Скрытый текст
Lbot3D
 
Здравствуйте,
Как уже было сказано и повторяем еще раз и будем повторять и дальше, мы уже зарегистрировали пожелание и оно на данный момент еще не реализовано.
Другого ответа мы дать увы не можем.
 
Целых 381 обновлений в QUIK версии 7.1.0 !
OnTrade() научился отсылать АБСОЛЮТНО ИДЕНТИЧНЫЕ отклики в разное время:

QUIK версии 7.1.0.381
Скрытый текст

  1. 21:07:40,537
  2. 21:07:40,541
  3. 21:07:40,563
Lbot3D
 
Здравствуйте!

Информация получена, проблема изучается. Постараемся в ближайшее время дать ответ.
 
Я пользуюсь таким алгоритмом для отличия первого колбека от последующих
Создаем таблицу событий по которым следим за колбеками (активным событиям)
при поступлении колбека по событию изменяем его состояние в таблице событий.
Если событие стало неактивным, то удаляем его из таблицы состояний.
Проблем с кучей колбеков на одно и тоже событие у меня нет.
 
Цитата
Sergey Gorokhov написал:
Сервер знает какой терминал к нему подключается и в зависимости от версии отправляет данные по разному.
Во времена версии 6.17 таблица сделок еще не была обновляемой. Поэтому старые терминалы не приспособлены для обновления параметров.
Туда приходит только первый колбэк.
Сергей, Вы так и не ответили зарегистрировано ли моё пожелание расширить имеющийся интерфейс коллбэков, путём добавления новых (типа OnOrderChanged, OnTradeChanged, OnTransCompleted и т.п.), которые вызывались бы только один раз и всегда приносили бы окончательное значение объекта. Судя по Вашему ответу, сервер уже сейчас отличает первый вызов коллбэка ото всех остальных, поэтому моё предложение не потребует от Вас внесения серьёзных изменений в код. Зато, как я понимаю, это устроило бы всех.
P.S. Конечно, это предполагает, что в дальнейшем ARQA не будет вносить изменения в логику работы уже опубликованных интерфейсов.
 
Sergey Gorokhov
Цитата
Интерпретатор языка Lua, Руководство пользователя, Версия 2.3

2.2.3 OnTrade Функция вызывается терминалом QUIK при получении сделки.
Так быть должно: получили сделку, получили колбэк.
Эта функция отличается от соседней:
Цитата
2.2.4 OnOrder Функция вызывается терминалом QUIK при получении новой заявки или при изменении
параметров существующей заявки.
Есть заявка, и ее параметры могут меняться: регистрация, частичные исполнения, отмена или исполнение.
Логично.

Но так себя вести сделка не должна: Это явление по своей природе разовое: это сделка!
Пошли в магазин за хлебом, дали денег, получили хлеб и чек на этот товар.
Один чек, не два! И после нашего ухода из магазина никто нам вдогонку не кричит - возьмите еще, он такой же, но третий!
Логично: один товар - один чек.
Если бы было не так - значит что-то происходит неладное: аппарат кассовый неисправен, кассир не обучен или еще что.
И с этим OnTrade что-то неладное:
Если до 7-ой версии несколько лет она работала исправно, согласно документации: вызывалась при получении сделки, то сейчас работает так:
Цитата
2.2.3 OnTrade Функция вызывается терминалом QUIK при получении сделки или при изменении параметров прошедшей сделки.
Прошу вас, вчитайтесь. Ужаснитесь!

Цитата
Николай Камынин написал:
Я пользуюсь таким алгоритмом для отличия первого колбека от последующих
Придется и мне, наверное, такой костыль , приделать.

Цитата
Илья Грачёв написал:
Сергей, Вы так и не ответили зарегистрировано ли моё пожелание расширить имеющийся интерфейс коллбэков, путём добавления новых (типа OnOrderChanged, OnTradeChanged, OnTransCompleted и т.п.), которые вызывались бы только один раз и всегда приносили бы окончательное значение объекта. Судя по Вашему ответу, сервер уже сейчас отличает первый вызов коллбэка ото всех остальных, поэтому моё предложение не потребует от Вас внесения серьёзных изменений в код. Зато, как я понимаю, это устроило бы всех.
P.S. Конечно, это предполагает, что в дальнейшем ARQA не будет вносить изменения в логику работы уже опубликованных интерфейсов.
Да, особенно в части P.S. : ))
Lbot3D
 
Цитата
Илья Грачёв написал:
Цитата
Sergey Gorokhov   написал:
Сервер знает какой терминал к нему подключается и в зависимости от версии отправляет данные по разному.
Во времена версии 6.17 таблица сделок еще не была обновляемой. Поэтому старые терминалы не приспособлены для обновления параметров.
Туда приходит только первый колбэк.
Сергей, Вы так и не ответили зарегистрировано ли моё пожелание расширить имеющийся интерфейс коллбэков, путём добавления новых (типа OnOrderChanged, OnTradeChanged, OnTransCompleted и т.п.), которые вызывались бы только один раз и всегда приносили бы окончательное значение объекта. Судя по Вашему ответу, сервер уже сейчас отличает первый вызов коллбэка ото всех остальных, поэтому моё предложение не потребует от Вас внесения серьёзных изменений в код. Зато, как я понимаю, это устроило бы всех.
P.S. Конечно, это предполагает, что в дальнейшем ARQA не будет вносить изменения в логику работы уже опубликованных интерфейсов.
Отдельных колбеков не будет и это не обсуждается.
Было зарегистрировано пожелание на нумерацию колбеков.
 
Костыль выглядит пока так:
Код
local trades = {} -- таблица наших сделок
local tmp_tr = {} -- временная таблица наших сделок для отсева дублей OnTrade

function OnTrade(trade)
   -- <...>
   if not tmp_tr[trade.trade_num] then
      -- добавим в таблицу первый колбэк.
      tmp_tr[trade.trade_num] = true  
      -- добавим в очередь на обработку.
      table.insert(trades,trade)
   end
end

function OnTradeDo(trade)
   -- <...обработать сделку>
end

function main()
   -- <...>
   if #trades~=0 then
      while #trades>0 do
         local t=table.remove(trades,1)
         -- сделку отправим на обработку, таблицу чистим.
         if t~=nil then OnTradeDo(t) end
      end   
   end
   -- <...>
end
Сильно не хотел добавлять лишние временные таблицы. :-|
Lbot3D
 
XXM,
вот эта проверка лишняя:
Код
if t~=nil then OnTradeDo(t) end
Надо делать так, как надо. А как не надо - делать не надо.
 
Цитата

Старатель: вот эта проверка лишняя:

if t~=nil then OnTradeDo(t) end
Согласен, тянется давно. Уберу.
Lbot3D
 
Хотя нет, я вас обманул  :oops:
Надо было написать так:
Если уж вы решили передавать обработку колбэка в другой поток (а это не во всех случаях целесообразно), то желательно для этого использовать потокобезопасные функции (table.insert и table.remove). Тогда проверка "if t~=nil then" будет лишней.
Но в вашем примере эта проверка необходима.  :smile:
Надо делать так, как надо. А как не надо - делать не надо.
 
* потокобезопасные функции (table.sinsert и table.sremove)
Надо делать так, как надо. А как не надо - делать не надо.
 
Старатель, так-то у меня стоит это:
Код
local  v = '6.17'
if versionLess(Terminal_Version,v ) then
   table_insert=table.insert
   table_remove=table.remove
   table_concat=table.concat
else   
   table_insert=table.sinsert
   table_remove=table.sremove
   table_concat=table.sconcat
end

Можно ли сделать так, чтобы всем было одинаково хорошо: и тем, кто применяет QUIK 6.0, и тем, у кого 6.17 и тем, кто юзает модный Dark Metro style QUIK 7.1?
Наверно нет. Только QUIK 7.1, только хардкор!
Lbot3D
 
Цитата
XXM написал:
Целых 381 обновлений в QUIK версии 7.1.0 !
OnTrade() научился отсылать АБСОЛЮТНО ИДЕНТИЧНЫЕ отклики в разное время:

    Добрый день,
   
    По данному обращению мы определили, что причиной множественных     отправок сделок (более двух) на клиентские места является неоптимальность в     серверном ПО QUIK. После ее устранения сделки могут быть отправлены на клиентское место максимум 2 раза - по     получению сделки из торговой системы и по факту ее обновления.
   
    Приносим Вам свои извинения за доставленные неудобства.
 
Неоптимальнось, очевидно, присутствует и в отправке колбэков по заявкам и стоп-заявкам: там тоже приходят по 2-3 одинаковых колбэка.
Советую обратить на это внимание.
Надо делать так, как надо. А как не надо - делать не надо.
 
Здравствуйте,
Приведите пример
 
Пример чего? Кода, лога или обсуждения данной проблемы?
Полистайте архив старого форума: там это обсуждалось на протяжении нескольких лет, в т.ч. с вами.
Надо делать так, как надо. А как не надо - делать не надо.
 
Цитата
Старатель написал:
Пример чего? Кода, лога или обсуждения данной проблемы?
Пример лога. И также уточните версию терминала.
Цитата
Старатель написал:
Полистайте архив старого форума: там это обсуждалось на протяжении нескольких лет, в т.ч. с вами.
Я это прекрасно помню, и также прекрасно помню что это уже чинилось.
Раз проблема повторяется значит это повод для нового разбора.
 
QUIK v.7.1.0.381
Скрытый текст
Надо делать так, как надо. А как не надо - делать не надо.
 
Старатель,
Вы проверяете на нашем игровом сервере, как сказал Булычев Михаил:
 
Цитата
Такое случается на нашем игровом сервере. Мы считаем это скорее  особенностью чем ошибкой. Если ситуация регулярно воспроизводится в  боевых условиях, то просьба предоставить более подробную информацию.  
Страницы: Пред. 1 2 3 4 5 След.
Читают тему
Наверх