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

Так он не продает готовое, а кодит что заказали. Закажут туфту - значит туфту и закодит. Обычно желающий что-нибудь закодить туфту и просит, и тут появляется такой момент: ты время потратил (и немалое часто) на переписку и изучение его хотелок и в итоге видишь, что его граальчик сольется, и видишь почему сольется. И что дальше делать? Объяснить, что это туфта? Во-первых, очень мало кто вот так возьмет и согласится, что туфту придумал, будет настаивать, предлагать "улучшения" всякие из разряда "костыли", т.е. отнимать время дальше с тем же результатом. Во-вторых, ты ж ему ничего не накодил еще, а договора оплачивать "консультации" не было, и выходит ты время потратил на чужую ненужную тебе туфту просто так из альтруизма. Поэтому да, правильно будет закодить что заказали, не влезая в дискуссию, и честно заранее говорить, что за результаты отвечает автор алгоритма, а не программист, и все "поправочки", не вызванные косяками в коде, - за счет заказчика. Что, собственно, у "чела по ссылке" на сайте прямо и написано.

В общем да, насколько это получится без танцев с бубном - от прямизны рук автора зависит.

Нельзя грузить 32-битную длл в 64-битный процесс, делайте 64-битную.

Задача программистов - закодить то, что им дали в техзадании. Некоторые думают нанять (желательно за копейки) биржевого аналитика + системного аналитика + программиста в одном лице, чтобы и робота сам придумал и еще объяснил, на какую кнопку жать и когда. Так действительно не бывает.

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

А еще в любой момент может внезапно дернуться OnDisconnected и начнется самое интересное. Мне вот очень трудно представить, как все эти возможные варианты можно отследить не в терминах конечных автоматов, а это все-таки определенного бэкграунда требует.

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

Потеря точности дабла https://www.binaryconvert.com/result_double.html?decimal=0490570510530490520480530500570500530480540...

Возможно, уточнение "какие именно одинаковые значения" прольет некоторый свет на эту таинственную историю.

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

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

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

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

Она может даже на вас в моменте подвинуться, если в стакан смотреть и ставить лимитник, куда мейкер покажет. А можно и наоборот попасть, это даже попроще будет ) В целом же тут ликвидные не для ликвидности выбираются, система такая (типа).

Официально из луа нельзя этого сделать. Через winapi можно схачить, сымитировав соответствующую команду меню, но хак он хак и есть, не факт, что в следующей версии квика что-то не поменяют и предъявлять за "перестало работать" будет некому. А вот это
всхачить будет сложнее, результат не гарантирован и версионная неустойчивость больше. Это только из спортивного интереса можно попробовать, я б не стал морочиться.

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

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

Надо ж в мейне цикл сделать, пока IsRun не сбросится, и OnStop добавить с удалением таблицы и сбросом IsRun.

в неявном предположении персистентности рядов ) тксть палю грааль )

Загуглите lua merge sort, все написано до нас.

В этом вся и суть. Если отбирать "тупо по обороту", на дистанции выдавливается максимум 8% без проскальзываний, комиссий и налогов, плюс просадочки нерадостные, лучше в банк отнести и не париться. Справедливости ради, на некоторые другие мысли система может навести. Хотя если в квике ковырять, то можно леса за деревьями не увидеть.

А в чем там мучение, ключ - код бумаги, значение - оборот, сортируете в порядке уменьшения оборота, первые 32 - наиболее ликвидные.

А зачем вы вообще в экранную таблицу это все пихаете? Сразу в массив, сортировка, потом выбираете свои 32 бумаги и уже их на экран.

PS. Ежли кодите чудодейственную систему со смартлабика с ежедневными скринами, держите спойлер: фигня эта система. Попробуйте выяснить у аффтара, как у него мосэнерго в наиболее ликвидные попало.

Вот тут вы делаете неверное предположение, выраженное в комментарии: На самом деле вы еще никаких данных не получили, вы их только заказали, если в ds не оказался nil (а вы ж не проверили). Сейчас квик будет посылать запрос на сервер, потом ждать ответа, потом распихивать приехавшие данные по файлам, а вы уже делаете следующее предположение, снова выраженное в комментарии:
Логично получаете 0 (ничего еще не получено) и потом, не проверяя, передаете этот 0 в вызов ds:C, и снова пишете в комментарии неверное предположение
На самом деле вы получили 0, так как индекса 0 в данном случае не бывает, они с 1 начинаются. Это развернутый ответ на вопрос "почему" с учетом
, а на вопрос "как" тут полфорума исписано.

RP как бы намекает на репо, но это не точно.

PS. А вот что supportedOS в манифесты добавили, фактически не проведя никаких работ по совместимости, это уже на билла не списать. Но тут уж кого премировать есть сугубо внутреннее дело арки.

трейдеры столько не живут )

Так-то ошибка 5 это ACCESS DENIED, что, по-видимому, случается при попытке открыть пайп (или другой объект), созданный от другого сида, когда квик и внешняя программа работают от разных юзеров. Для решения надо на стороне квика при создании этого объекта указывать список доступа, включающий SID "авторизованные пользователи" или даже "все", обычно же все просто NULL указывают, задавая тем самым список по умолчанию (и арка вряд ли исключение), а тут подкрадывается майкрософт и в десятке этот список меняет. И попробуйте найти в доках майкрософта, что именно они там поменяли, ежли есть неделька свободная. Так что по итогу вина все же скорей на майкрософте, для времени своей разработки длл была сделана нормально.

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

Накину вариант 1a: подменить ip.cfg и ключи и удалить все .dat и .log файлы. Последнее можно сделать, запустив 911.bat, лежащий в папке квика. Также, может быть, стоит прибить папку archive, там кэш графиков лежит, по-моему, лучше перекачать от того брокера, с которым квик будет работать.

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

Да, именно.

Лет 10 (или больше) назад такой коннектор разрабатывался и был зарелизен, а дожил ли он до сейчас не в курсе.

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

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

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

Вот тут корень, похоже. О каком текущем моменте речь, как его идентифицировать? Давайте нарисуем фейковый лог.

> 10:30:22.555 sell GAZP 1 ...
> 10:30:22.666 buy RIZ9 1 ...
> 10:30:22.777 sell SBER 1 ...
- 10:30:22:888 первый пакет достигает сервера, заявка передана на мамбу, получено подтверждение о постановке в стакан
< 10:30:22.888 ok GAZP accepted 1 filled 0 ...
- 10:30:22.999 второй пакет достигает сервера, заявка передана на фортс, ответа еще нет
- 10:30:23.111 третий пакет достигает сервера, заявка передана на мамбу, получено подтверждение о постановке в стакан
< 10:30:23.111 ok SBER accepted 1 filled 0 ...
- 10:30:23.222 получено подтверждение с фортса об исполнении
< 10:30:23.222 ok RIZ9 accepted 1 filled 1 ...
и т.д.

Фортс в примере подтормозил и прислал ответ на вторую заявку позже, чем мамба на третью. Что должен был сделать сервер? Сериализовать заявки и отвечать в порядке их поступления? Или он все правильно сделал?

Не поэтому только, а по самой природе распределенной системы. Ровно в ту микросекунду, когда рабочее место дернуло ваш код с докладом обо всех заявках, на сервер может подъехать еще одна ваша заявка и опа у нас опять неконсистентность. Запретить отправлять до получения ответа, как вы выше писали, нельзя, это равно синхронной отправке заявок по одной, то есть плюс два пинга на заявку минимум, многие такого "улучшения" не оценят. Правильным решением было бы добавление сущности "группа заявок" с атомарной обработкой, но чета я сомневаюсь, что в народный квик перетащат весь фикс. Даже если арка решит слить свой другой продукт, мамба такого альтруизма может не понять. Впрочем, мы по кругу уже пошли.

О факте успешного получения информации как раз и говорит дернутый колбек, невозможность получения информации - это по-хорошему нонсенс, крэш соединения. А вот что рабочее место не всегда колбек дергает, это тот самый косяк. Более того, из неофициальных, тксть, источников, ответ-то от сервера оно при этом получает. Тупо где-то ветка кода упущена.
А тут я согласен, и насчет костылей тоже, если говорить о работе чисто через апи. При наличии экспортируемых таблиц обойти можно, но в целом решение будет громоздким и неудобным для енд юзера, лучше сразу со стороны луа заходить. Там тоже не фонтан, только что возможностей для воркэраундов побольше.

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

Другой вопрос - о времени ответа на транзакцию, тут, с одной стороны, никто гарантий давать не будет, а с другой, если косяка, описанного выше, нет, то и дергаться незачем, когда-нибудь ответ придет (или будет разорвано соединение, что тоже своего рода ответ). То, что вы предлагаете, насколько я понял, - это "квик после отправки транзакции встает колом и висит до получения ответа сервера, но не дольше, чем (заданный) таймаут". Так себе решение.

Откуда появилась проверка? Кем она была инициирована?
Какие "все"? В каком месте вы начали атомарную транзакцию с группой заявок, чтобы требовать ее атомарного завершения?
У них QuikFIX есть, чет тут вопросов о нем не видать. А квик продумывать уже поздно, ему больше 20 лет, уже и биржи нет, для которой он писался, и вообще чудо, что он до сих пор в строю. Напишите свой, до мелочей продуманный, может вытесните его с рынка.
Тогда можно считать, что таймаут всегда является истекшим. Действительно, начните с этого предположения. Вы отправили что-то, таймаут истек. Ваши действия?

Вот смотрите, вы отправляете 10 заявок сразу, сервер их обрабатывает и посылает ответ "все заявки обработаны". Но пока этот ответ идет по сети, вы отправили еще одну. Тут вам приходит ответ "все заявки обработаны". Все 10 или все 11? Или наоборот, истек таймаут, квик дернул колбек "увы и ах" и тут начали сыпаться ответы. Куда их девать теперь, выбрасывать? Но заявки уже на бирже, часть уже может исполнилась, а ваш код думает, что таймаут истек. Простое решение только одно - сообщения о состоянии индивидуально по каждой транзакции, что квик и делает в меру сил.

В принципе, вы сами можете таймаут прикрутить. Отправляете заявку - ставите таймер, получаете ответ - сбрасываете таймер, если таймер таки сработал - вы не получили ответа за заданный интервал. Видите уже, что вам сделать придется? Ага, хранилище заявок с их состояниями. Более того, вам несколько сущностей понадобится, позиции, заявки, транзакции.

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

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

Закрыть T+2, не?

А зачем вайлдкард, да еще такой нетрадиционный, в конце путей?

Это можно сделать без как будто, вы ж скриптом сидите в процессе квика, только надо на уровень виндов спуститься. В частности, чтобы вызвать диалог настройки фильтров ТВС, достаточно послать главному окну квика WM_COMMAND с кодом 154, далее найти в этом диалоге нужную кнопку и послать ей BM_CLICK. Недостаток такого лобового решения - никто не гарантирует, что в следующей версии квика код будет именно 154, кнопка в диалоге будет иметь тот же идентификатор и т.д. и т.п. Резюмируя - для себя пойдет, в продуктах "не себе" я б поостерегся такие решения использовать.

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

Что на шарпе, что на сях даблы в IEEE754, так что тоже не пофиг. На возвращенное в бинарном виде не смотрели, там точно ноль или некий "битый дабл"? Вроде как у явы big endian, помнится, кто-то как-то попадал с необходимостью байты переворачивать, правда, не помню, в каком контексте.

Добавьте что-то к полю CLIENT_CODE через слэш и поймаете это что-то в поле "комментарий" таблицы, таким образом отделите свои заявки от несвоих, а уж у своих TRANS_ID вы знаете.

Это особенность винды, начиная с какой-то там версии. Квик раньше писался, когда этого поведения еще не было. Арке подскажу, куда копнуть.

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

Вам только майкрософт может помочь (новой виндой). Хрюша 32-битная, восьмой квик 64-битный.

А можно наоборот, сначала тики по стандартной формуле (с достаточно большим периодом), а потом из полученной линии дергать значения с определенным интервалом. Линия будет одна и та же на всех таймфреймах. Минус - представьте себе облигацию с тремя сделками в день и этот "достаточно большой" период емашки. Т.е. налицо дискретизация с переменным шагом и мы в такие математические дебри проваливаемся, что лучше сразу не начинать )