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

Ну как бы есть или нет на срочном рынке заявки по рынку это вопрос отдельный, потому как например фьючерсы на юань у меня спокойно скрипт покупал и продавал по рынку по 1 шт(от шёлка мышкой, так просто для ускорения исполнения писал, чтобы не вводить вручную). Я так же склонялся и склоняюсь к тому, что ГО разное на разных ценах и по границам Min/Max оно скорее всего превысило - об этом подумал сразу. Но, что интересно, раньше вроде бы, если мне память не изменяет было такое, да - вручную ввод заявки по фьючерсу на одной цене - ГО показывает одно, на другой цене дальше к границе стакана - ГО другое. Но сейчас хоть на какой цене ни щёлкай - ГО одно и то же показывает в окне ввода заявки, оно точно соответствует тому ГО, что в ТТТ для инструмента. Поэтому и решил здесь спросить.

Вот ещё хочу тут спросить старожилов по такому поводу. Скрипт на Lua сначала делает продажу акций Лукойл по рынку в шорт 10 шт через sendTransaction() при этом естественно ставлю TYPE="M", PRICE="0".
Транзакция проходит, заявка исполнилась нормально. Следующая транзакция на покупку фьючерса "LKZ2", т.е. LKOH-12.22 в количестве 1шт так же по рынку, где в sendTransaction() установлено так же TYPE="M", PRICE="0". Но при этом транзакция с ошибкой: Ошибка создания заявки. [GW][332] "Нехватка средств по лимитам клиента." Пытаюсь купить данный фьючерс вручную в квике, установив галочку в окне ввода заявки "Рыночная" - результат опять та же самая ошибка!
В результате фьючерс купил таки вручную, указав цену на покупку из стакана равную лучшей цене продажи. Транзакция прошла без ошибок и заявка тут же исполнилась. Да мог бы поставить цену покупки и выше чем лучшая цена продажи на несколько пунктов, это я знаю, и заявка ушла бы так по лучшей рыночной цене.
Но вопрос: почему sendTransaction() работает на покупку/продажу акций по рынку с значениями TYPE="M", PRICE="0", а на  покупку/продажу фьючерса с значениями TYPE="M", PRICE="0" выдаёт ошибку: "Нехватка средств по лимитам клиента." и я вынужден ставить цену хуже рынка, чтобы заявка ушла по рынку? Заявка то в конечном итоге прошла, значит средств достаточно!

Владимир, а может быть nikolz специально ставит в стакан заявки и потом их снимает не для того, чтобы исполнить, а может быть для того, чтобы сбить с толку других роботов, заставить их сработать, или нет, мало ли?

Ну я собственно использую большинство колбэков, и для контроля исполнения использую и OnOrder() и OnTrade() впаре чисто для повышения надёжности. Хотя уверен, что и OnTrade() было бы вполне достаточно. Работает и ладно.

О как! Интересно. Даже не знал, что есть такая возможность. Учтём.

А я вот решил почему-то ещё и ждать прихода самой сделки, использую OnTrade(). Может это и не надо. Что скажут разработчики? Нужен ли двойной контроль?

Ваш алгоритм в принцине понял. В конечном итоге полное исполнение всё равно идёт по балансу в OnOrder().

У меня сейчас для заявки в 1 лот алгоритм такой. OnOrder(): если для моей заявки balance == 0 - ставлю один флаг. Пришёл OnTrade()[сделка прошла значит] с моей заявкой - ставлю другой флаг и беру цену из него и в переменную. Функция контроля иcполнения ждёт появления обоих флагов, если пришли, то цену беру из переменной. Так же внутри OnOrder()  и OnTrade() использую ещё свои флаги для того чтобы отбрасывать ненужные их вызовы - по сути OnOrder() как только пришёл в балансе ноль - ставлю флаг, следующий вызов проверяет этот флаг и если он есть, то игнорирую вызов, так же и в OnTrade(), как пришла моя сделка - ставлю флаг, чтобы отсекать другие возможные её вызовы. Вот и думаю, может просто достаточно только OnOrder() и брать из неё цену исполнения и достаточно?

Контроль исполнения заявки, которая например в вашем стеке у которой 1 лот контролируется по balanse == 0?

Короче, ещё спрошу так. Отправил заявку например на покупку 1 лота. В OnTrade() проверил, что  order.trans_id == моему TRANS_ID и order.order_num == TRANSACTION_COMPLETED[tostring(order.trans_id)], короче отфильтровал по своей заявке и проверил что order.balance == 0. Этого достаточно для контроля исполнения заявки?

Если оно так, то получается что просто нет возможности в квике сделать контроль исполнения заявки. А раз так, то получается, что всё остальное просто не имеет никакого смысла. Какой смысл писать робота или ещё чего, если нельзя осуществить контроль исполнения заявки? Нет уверенности в исполнении - дальше ничего делать нельзя!!! Либо есть возможность со 100%-ной уверенностью программно определить, что заявка исполнена, либо вообще тогда надо закрывать все обсуждения, да и вообще тогда теряет смысл программирования на этом самом Lua.

Хорошо. По пункту 8 вы не советуете конкретный алгоритм. Но это в общем случае не советуете, поскольку вариантов может быть много. Но я спрашиваю конкретно для своего наипростейшего случая, что описал выше. Например - покупка 1 лота. Нужен контроль того, что покупка 1-го лота 100% прошла и только тогда подавать на продажу того же 1-го лота. Какой алгоритм контроля применить посоветует техподдержка? Уж куда проще то? Мой алгоритм подойдёт? Или можно его упростить, например - вообще не использовать OnTrade()? Достаточно проверить OnOrder() где баланс = 0? Сейчас использую и то и то. А надо ли? Вроде работает.

Владимир, привет. Вот и в этой ветке встретились. Мне бы весь этот сыр-бор с колбеками свести к решению моей простой задачи. Мне собственно(во всяком случае пока) надо реализовать элементарный алгоритм. Покупка лота - 1 шт, т.е. автоматом отпадает возможность срабатывания только части заявки потому как 1 лот это 1 лот и его частично исполнить нельзя. Это намного упрощает задачу. Далее всё, что мне нужно это контроль исполнения этой заявки на покупку. Всё. Я должен быть на 100% быть уверен, что моя заявка исполнилась. И если исполнилась, то только тогда подаю следующую уже на продажу, так что тут такой же принцип блокировки - пока не сработает покупка - никакой продажи. На QPILE я это делал так - в цикле пробегал по таблице заявок в поиске своей заявки с номером который мне возвратила send_transaction() в своём результате, смотрел значения поля баланса когда станет равно нулю, как только оно стало равно нулю, то потом в цикле пробегал по таблице сделок и как только в ней появлялась запись с номером моей заявки, я считал что сделка исполнена. Не знаю насколько хорош такой алгоритм, но он работал всегда. Возможно, что достаточно было просто увидеть ноль на балансе в таблице заявок и плюнуть на таблицу сделок, не знаю. Или наоборот, может достаточно было бы и того что сделка появилась в таблице сделок. Но я для надёжности решил использовать и то и то. Перейдя на Lua сначала обрадовался, что есть колбэки и не надо бегать в цикле по таблицам в поиске нужного номера заявки, но не тут то было. С одной стороны всё просто. С другой стороны - куча вопросов. А есть ли гарантия? На данный момент меня интересует пока только одно, могу ли я использовать самый первый вызов OnOrder(), в котором на балансе появился ноль вместо единицы и отбросить все остальные вызовы? Могу ли я использовать только самый первый вызов OnTrade(), который мне показал, что в нём появился номер моей заявки, взять из него цену и быть уверенным, что эта цена не меняется в следующих вызовах, и что вообще есть ли гарантия, что эта цена будет в самом первом этом вызове, т.е. надо ли проверять что цена не ноль, а остальные вызовы отбросить?
Если так можно, то суть контроля исполнения оставляю ту же - приход нуля в балансе заявки и(AND) появление сделки. Открытым в принципе остаётся вопрос, а надо ли вообще делать 2 проверки или может быть достаточно только какой-то одной из них? Если вызовы колбэков идут вразнобой, может заменить AND на OR? Может вообще как-то изменить сам алгоритм контроля исполнения? Как? Как лучше?

PS. Разработчики накуралесили конечно знатно, оставив пользователям самим разбираться во всём, потому как много непоняток и нет однозначности. Не мешало бы самим этим разработчикам в документации привести хотя бы элементарный пример контроля исполнения заявки использую колбэки!

Ну на меня собственно пока только загрузка долгая давит и тормоза по ходу работы с вкладками и окнами. По самим скриптам пока больших глюков самого квика я не заметил, потому как не так давно начал их писать. А начал я сдуру с QPILE, уж больно хотелось мне видеть разную информацию по опционам в виде отличном от доски опционов, да спреды разные между фьючерсами и базовыми активами в реальном времени с расчётом всяких вариантов купи-продай их и расчётом гарантированной прибыли в процентах годовых. То есть задачи довольно простые. Ах, да ещё надо было скрипт такой чтобы быстро например щёлк мышкой - купил, щёлк - продал, без всяких там окон ввода заявок, чтобы быстро. Вот пришлось по быстрому это накатать на QPILE. Понял, что это такое и что коряво на нём всё, хотя для простых задач пойдёт и это. Но его ограничения в 1 сек на перезапуск скрипта, и даже через какой-то изврат делать замкнутый цикл в отсутствие простого while как-то мне это совсем не в тему. И вот пришлось опять же по быстрому этот Lua познать и переписать скрипты на него. Но по мере написания на этом самом Lua начали появляться свои заморочки, о чём приходится спрашивать опять же на этом форуме. Так что пока в принципе по скорости всё нормально и зависаний как таковых много не было. А простой алгоритм робота у меня и на QPILE нормально и быстро работал. Но раз уж взялся за Lua, то и его переписал, всяких там зависаний тоже пока не замечено.

 Отправляю заявку через скрипт Lua - 1 лот, использую свой TRANS_ID на транзакцию. Задача - если сделка произошла, значит надо отправить другую заявку. Т.е. мне нужен контроль исполнения заявки(сделка). Логи показывают, что сначала первой всегда откликается OnTransReply(), потом могут идти 3 вызова OnTrade() и 2 вызова OnOrder() в разной очерёдности. Логика контроля исполнения заявки(по сути приход сделки) была такая:
1) В OnOrder() если пришло изменение заявки, т.е. order.balance == 0 , то -> флаг is_nul = true.
2) В OnTrade() если trade.order_num == номеру моей заявки(получаю его через OnTransReply(), или в OnOrder() если пришла моя TRANS_ID если этот OnOrder() вызвался раньше OnTransReply()[мало ли?] , то -> флаг  is_trade = true.
3) Далее если if is_nul and is_trade then -> выставляем нужную заявку.

Я не рассчитывал на то, что колбэки могут отправляться по нескольку раз. Прочитал эту тему, понял, что могут и причём неограниченное число раз. Я не заморачивался и не тестил чем конкретно отличаются пришедшие в колбэках таблицы, но вижу, что OnOrder() где order.balance == 0 - 2 раза, и OnTrade() 3 раза и слава богу цена в нём одна и та же.

Вопросы:
1) Возможен ли вызов OnTransReply() на мою поданную заявку с моим TRANS_ID, с trans_reply.trans_id == 0, nil, "0", "" или же trans_reply.trans_id всегда содержит номер заявки? Этот номер заявки измениться не может?
2) OnTransReply() вызывается только один раз?
3) Возможен ли случай, когда сначала первой будет вызов OnOrder(), а потом уже вызов OnTransReply()? Вроде бы как-то один раз такое проскочило, когда скрипт вылетел с ошибкой исполнения. Но точно не помню, возможно было и так, даже скорее всего так, что был вызов только OnTrade(), а  OnTransReply() не вызвался, хотя по факту заявка выставилась. Из-за этого дублирую сохранение номера заявки не только в OnTransReply(), но и в OnOrder().
4) Могу ли я быть уверен, что имея самый первый OnOrder() c order.balance == 0, последующие OnOrder() не изменят значение  order.balance?
5) Могут ли приходить сначала OnTrade() без  trade.price, а потом с  trade.price? От этого зависит какие именно я могу использовать вызовы OnTrade(), т.е. нужно ли вообще проверять установлено ли в них поле  trade.price, или это поле заполнено ценой всегда и не меняется в следующих вызовах?
6) Могу ли я быть уверен, что имея самый первый OnTrade() с ценой исполнения trade.price, последующие OnOrder() не изменят значение trade.price?
7) Могу ли я с учётом своего алгоритма контроля исполнения использовать только самые первые вызовы OnOrder(), OnTrade(), OnTransReply(), отфильтровывая все последующие, где я фактически смотрю только на изменение баланса в заявке и жду появления сделки с номером заявки?
8) Может быть вообще как-то по другому изменить алгоритм контроля исполнения заявки(приход сделки)? Какой алгоритм контроля посоветуют разработчики с учётом всех этих многочисленных вызовов?

Все эти 0, nil, "0", "", которые могут прийти в trans_id в разных частных случаях в OnTrade() или в OnOrder() как я понял для меня не критичны, так как во всех колбэках я проверяю поля таблиц trans_id со своим номером транзакции TRANS_ID.

Вот, грузится точно так же оооочень долго. Умный способ думаю убирать нет смысла, так как он видимо и так лишнего сам загружать не будет. Его как поставил, так и стоит. Обезличенные сделки оставлено только неторговые поручения. Из-за этого вряд ли будет сильно тормозить. А вот что ещё можно изменить? Может быть можно вручную откорректировать какие-нибудь конфигурационные файлы квика? Как я понимаю квик при загрузке тянет с сервера дофига ненужной информации, например возможно данные для графиков или ещё что. Вот это если убрать, то может и ускорится загрузка?

Хорошо. Будет время покопаюсь, может найду сообщения этого Антона. По настройка там так - либо умным способом(там он квик сам смотрит по таблицам} либо по выбранным классам(классы сам выбираешь). Вот поэтому и думаю, что может из-за того, что много вкладок открыто (17 шт.) и на каждой вкладке несколько окон(где-то и 11 шт. есть), то поэтому и подтормаживает. Бывает даже так - сначала например окна двигаешь, мышкой нажимаешь  - всё нормально работает , потом бывает просто паузу делаешь - не нажимаешь ничего и потом просто например окно двинуть надо или закрыть его, крестик нажимаешь например на окно сообщения, а оно не закрывается сразу, а закрывается через паузу. Иногда сразу закрывается, а иногда через паузу. И при начальной загрузке у меня квик долго загружается. Не засекал время, но минуты точно. Это нормально?

И вообще квик как-то приторможенно работает. Это интересно у всех так? То вроде шустро, то после переключения окон или ещё чего делаешь действие, например двинуть окно или закрыть окно, а оно тупит-висит, квик думает-думает и только после какой-то задержки срабтывает. Вроде и проц толком не загружет, а тормоза есть. Всё остальное - куча открытых программ всё работает шустро. Память 8 Гб, AMD Athlon™ X4 860K Quad Core Processor 3.70 GHz. Может настройки какие поменять? У мненя загрузка потоков данных в настройках стоит умным способом по существующим таблицам. Неужели из-за того, что много данных приходится онлайн подтягивать с сервера и обрабатывать? Стояло 10 сек, потом ставил на 1 сек время обновления данных.

Согласен. Этим и занимаемся. Просто столкнулся с такой ситуацией, которой как бы быть не должно, но она есть. Пытался понять почему такое у них вообще есть. Для себя просто поставил sleep(50) - всё работает. Но понять хотелось логику работы QUIK что они там замутилитакое  и почему, что без задержки ну никак.

В своё время сталкивался и с потоками на C и всякими там атомарными функциями и прочее. Но это было давно. Сейчас задача простая - написать скрипт и чтобы он не вис. Я просто пытаюсь понять какого хрена если main() это реально отдельный поток в OC, то почему он не виснет если есть sleep() и виснет если его нет? Ну нет sleep() и что? Ну циклится быстро и что? Время выполнения от захода в цикл до повторного захода в него минимально и что? И даже не факт что этот поток будет на 100% грузить одно из ядер процессора. Даже если разрабы API функцией(сейчас даже названий не помню и искать не хочу) вешают main() на отдельное ядро проца и что? OS сама решает какие ещё потоки будут последовательно работать на этом же ядре. И только OS может используя свои привилегии сделать так, что бы какой-то отдельный поток мог один занять ресурсы одного ядра, т.е. чтобы только он один выполнялся на этом ядре а не пользовательский поток QUIK это решает. Так что и без sleep() ничего виснуть не должно по идее и main() должен спокойно работать наравне с другими потоками, которые сочтёт нужным OS. Могу только предположить что есть какие-то прерывания от самого квика, которые во время своего выполнения что-то там делают, не пойми что и мешают main() нормально работать, просто main() по какой-то причине просто не получает управлении из-за того, что-то там у них в прерываниях циклится и не выходит из прерывания.

Да я тоже начал склоняться к такому, что потоки квика - это явно не потоки ОС.

Т.е. по поводу поста выше если как говорят разрабы main() работает в отдельном потоке, то вообще ничего виснуть не должно. Хоть есть задержка, хоть нет. На то он и отдельный поток. Зачем разрабы рекомендуют ставить sleep(100)? Что не так с потоком?

У меня из main() вызывается простая функция в которой в цикле while жду появления 2-х флагов. Флаги устанавливаются по событиям из 2-х разных коллбэков, один флаг из одного, другой из другого. Скрипт наглухо виснет если в функции while чисто цикл без задержки. Если поставить в цикл sleep(), то не виснет. По этому поводу даже есть пример в файле "Использование Lua в Рабочем месте QUIK.pdf" от разработчиков квика с подобным циклом while и там написано, что: "Если убрать вызов функции sleep() внутри цикла, то скрипт будет загружать на 100% одно из ядер процессора, что позволит увеличить скорость обработки сценариев внутри цикла, но приведёт к более интенсивному использованию ресурсов компьютера."
Дело в том, что у меня срабатывает коллбэк OnTransReply(trans_reply) и он выводит message и это окно с message виснет не отвечает, а скрипт работает в цикле. Так почему  виснет, а не грузит проц на сто процентов ядро? Вообще почему должно виснуть или грузить проц на 100% одно ядро если main() работает в отдельном потоке? main() вызывает простые функции и они значит тоже работают в одном потоке с ним. Или не так? какая разница вообще не пойму есть задержка в цикле или нет?
Моя функция c  циклом:
function order_done()
   while is_run do
        if is_nul and is_trade then
             is_nul = false
             is_trade = false
            return OrderPrice
        end
   end
end
А вот пример из файла про который пишут разрабы квика из их файла, который находится в каталоге Квик\Doc\Lua\Использование Lua в Рабочем месте QUIK.pdf:
is_run = true

function OnStop()
  is_run = false
end

function main()
  while is_run do
     sleep(100)
  end
end