s_mike@rambler.ru (Все сообщения пользователя)

В общем случае это неверно. В большинстве случаев так прикинуть можно, но далеко не всегда.

Поэтому утвердительно ответить на первоначальный вопрос нельзя.

Угу...

Да, Сергей, так и приходится. Но при этом в настройках лишний мусор.

C использованием

сегодняшний RI

Никак

Кто хочет потестировать индикатор - пожалуйста, обращайтесь

mikemsk
s_mike@rambler.ru

Мне потребовалось сделать индикатор с нулевым количеством линий. Иначе говоря, в нем не должно быть никаких настроек линий.

Однако мне это не удалось: "Ошибка создания индикатора"

Нехорошо это...

a = {4,7,8}

b = {}

for k,v in pairs(a) do b[k] = v end

Вот же... 317 строк.

Что мешает создать несколько таблиц, в каждой из которых эмитенты из одного сектора?

А что, собственно, удивляет? scale -    это разрядность цены. Для рим она = 0


Шаг цены это мин присе степ

"в хранилище данных терминала порядок будет отличаться от того что представлен в визуальной таблице"


Таким образом, подыживаем:


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

Правильный ли я делаю из всего этого вывод?

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

Нет. Это не единственный выход. Данные по инструментам или их параметрам можно собирать в реальном времени обычным скриптом lua и сохранять их в своей базе данных. Простейшая база - это csv файл. И уже из этой базы использовать необходимые значения для расчета вашего индикатора.

Пример скрипта, сохраняющего котировки в csv.

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

Ок. Пишем тестик


last = datetime(0)
function OnAllTrade(trade)
-- Заменяем время в сделке на объект datetime
trade.datetime = datetime(trade.datetime)

log.write(trade)
if trade.datetime < last then
log.write("********  Опоздашка")
else
last = trade.datetime
end
end      

Получаем:

12:23:38 {repoterm=0,price=153.81,trade_num=1281821722,yield=0,value=66138.3,qty=43,reporate=0,class_code="QJSIM",repovalue=0,accruedint=0,tradenum=1281821722,flags=0,datetime={week_day=6,hour=8,ms=0,mcs=0,year=2015,month=5,sec=15,min=56,day=9},sec_code="GAZP",seccode="GAZP",period=1,repo2value=0,settlecode=""}
12:23:38 {repoterm=0,price=75.39,trade_num=1281821759,yield=0,value=6031.2,qty=8,reporate=0,class_code="QJSIM",repovalue=0,accruedint=0,tradenum=1281821759,flags=0,datetime={week_day=6,hour=8,ms=0,mcs=0,year=2015,month=5,sec=19,min=56,day=9},sec_code="SBER",seccode="SBER",period=1,repo2value=0,settlecode=""}
12:23:38 {repoterm=0,price=75.39,trade_num=1281821760,yield=0,value=2261.7,qty=3,reporate=0,class_code="QJSIM",repovalue=0,accruedint=0,tradenum=1281821760,flags=0,datetime={week_day=6,hour=8,ms=0,mcs=0,year=2015,month=5,sec=19,min=56,day=9},sec_code="SBER",seccode="SBER",period=1,repo2value=0,settlecode=""}
12:23:38 {repoterm=0,price=75.41,trade_num=1281821769,yield=0,value=25639.4,qty=34,reporate=0,class_code="QJSIM",repovalue=0,accruedint=0,tradenum=1281821769,flags=0,datetime={week_day=6,hour=8,ms=0,mcs=0,year=2015,month=5,sec=21,min=56,day=9},sec_code="SBER",seccode="SBER",period=1,repo2value=0,settlecode=""}
12:23:38 {repoterm=0,price=104440,trade_num=139255273,yield=0,value=318909.63,qty=3,reporate=0,class_code="SPBFUT",repovalue=0,accruedint=0,tradenum=139255273,flags=1025,datetime={week_day=5,hour=16,ms=221,mcs=221000,year=2015,month=5,sec=0,min=0,day=8},sec_code="RIM5",seccode="RIM5",period=1,repo2value=0,settlecode="T1"}
12:23:38 ********  Опоздашка


При этом в ТВС все по порядку идет.

А не проще в качестве уникального идентификатора взять номер потока, исполняющего main?

Да, Сергей, это понятно. Вопрос звучал про "по разным инструментам".

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

Добрый день, вопрос к разработчикам.

Колбеки оналлтраде приходят по разным инструментам не обязательно в порядке возрастания времени. Таблица всех сделок терминала на взгляд формируется сразу в хронологическом.

Какой подход использует терминал для упорядочивания?

Спасибо.

Колбек OnInit вам это расскажет

В паре с GetColumnWidth, очевидно

SetColumnWidth(id,column,width) очень нужен, Сергей

Main - это  поток ТЕКУЩЕГО скрипта. У каждого скрипта свой поток main.

Поэтому ТЕКУЩИЙ скрипт будет остановлен до получения ответа (это и хочется), остальные - нет.

Конечно, имеет смысл ждать не бесконечно, а какое-то время. Вдруг ответ не придет никогда.

Ну будет вам... Берите готовое и экспортируйте историю параметров

http://www.bot4sale.ru/download-categories/2012-06-13-15-10-36/item/kotirovki-s-servera-brokera.html?category_id=70

Демо-контур от арка.  6 17 1 17


Не заполняется столбец Операция

Виктор.

Цикл ожидания вида


будучи запущенным в функции main или любой другой вызванной в конечном итоге из main, остановит только эту функцию.

Всем остальным скриптам от этого не холодно и не жарко.

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

Поэтому если вам нужно именно синхронное исполнение транзакции - смело используйте цикл с ожиданием внутри него.

В колбеках так писать нельзя - это подвесит терминал.

Например, арбитражная синтетика, где важны не только цены, но и порядок следования сделок. alltrade даёт последовательность, а datasource - готовые таймсерии по ногам.

Михаил, Здравствуйте.

Возможно, я чего-то не понимаю, но мне кажется странной такая ситуация.

Получая таймсерию инструмента по подписке, я вижу в результатах поле count, что позволяет корректно работать со сделками, имеющими одиаковое время.  Тут все хорошо.

Теперь я подписываюсь на onalltrade и смотрю, что мне дают.  Поля count в таймштампе здесь нет. Синхронизации результатов подписки и колбека невозможна, хотя напрашивается.

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

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


Пользуясь случаем. В вашем даташтампе фигурирует поле week_day, в стандарном datetime формате lua 5.1 -  wday

В колбеках типа onalltrade изменений не было?

Есть колбек, срабатывающий при изменении выделенной строки. В колбек отдается номер новой выделенной строки.

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

Вопрос к разработчикам.


Были ли изменения в последних версиях в поле count структуры datetime?


Спасибо.

Такого нет.

Извращенный вариант - отслеживать появление окна сообщения и читать его содержимое

Notepad++    -  Lua уже встроен

Устроит такое?

Ой, простите. Не обратил внимание на название форума и написал ответ на lua

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

Прямого пути нет

Можно сделать так (очень условно):

text = {}
f=io.open(file,"r")
for line in f:lines() do
table.insert(text,line)
end
f:close()

table.insert(text,3,"Вставляемая строка")

f=io.open(file,"w")
for _,line in ipairs(text) do
f:write(line .. "\n")
end
f:close()

Да что тут сложного-то?

Завели флаг. Для простоты пусть это будет файл.

далее натравливаете на этот файл корутину , которая сопровождает этот файл. (крутится в цикле и на каждой итерации проверяет существование файла или его содержимое и делает yield).

С нужной периодичность эту корутину оживляете.
Ну просто же.

Если хочется покрасивше - возможностей миллион, включайте фантазию.


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

Не нравится файл - проблем нет - С++ в руки и обмен в резидентной программе ддл-ки. Нет С++ - через сом-объект.

Все это не нравится - поднимите именованные пайпы
Пайпы - не устраивают - сокеты вам в руки.

dofile, loadstring  и аналогичные просто выполняют код на языке lua, который вы ему подсовываете (с использованием upvalues или без них).

require - это более сложный механизм, предназначенный для подключения универсальных модулей (написанных на lua или С++ и соответствующим образом оформленных)

loadstring()
dofile()

os.time() выдает время не локальное, а UTC. То есть по гринвичу. Соответственно, оно отличается т вашего локального на смещение часового пояса. В момент написания примера на моем компьютере был часовой пояс +4, на вашем сейчас +3

Вычтите из 1379097615 - 1379094015. Получится 3600 - это 60*60 или 1 час

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

Читать описания бесполезно, нужно анализировать сам скрипт на вопрос что происходит в нем при отказе в исполнении транзакции.

Ну вы даёте.

a,b,c,d,e,f = string.match(xxx,yyy)

([%d%.]+)  - нет ошибки. Что мешает попробовать и убедиться?

Вот вам примерчик.

Продолжайте искать ошибку в скрипте. Других вариантов нет.

И это тоже невозможно принципиально. Немного поразмыслив, Вы тоже придете к этому заключению.

Серж.

Представьте модель.

Склад А (биржа). Склад В (сервер) Склад С (терминал)

Со склада А на склад В везут помидоры. Склад В не имеет понятия, когда помидоры к нему прибудут и прибудут ли вообще. Они имеют информацию о прибытии только в момент, когда оприходована приходная накладная.

Со склада В на склад С ИМЕЮЩИЕСЯ помидоры отправляются на склад  С.


Надо иметь ввиду, что дорога между складами тоже занимает время.


Поэтому. Склад В НИКАК не может сообщить складу С  (курьером, который тоже едет не мгновенно), что ВСЕ помидоры, отгруженные со склада А, достигли склада С.  Он просто этого не знает. И никакие технические ухищрения этому не помогут.  Помидоры могут быть в пути между А и В. Более того, за время, когда курьер едет с соообщением об окончании помидоров, новая партия может быть уже отправлена.


Поэтому любые поиски технического решения задачи бессмысленны. Такого решения нет. Именно поэтому разработчики и не в состоянии установить в складе С (терминале) никакие флаги "об окончательной загрузке" или "об актуальности данных"

Неправильное предположение. Память дополнительнл расходоваться не будет

Возможно, Вам это поможет

Попробуйте вот это: http://www.bot4sale.ru/download-categories/2012-06-13-15-10-36/item/kotirovki-s-servera-brokera.html?category_id=70

Там не должно быть никаких дублирований