Nikolay написал: Раз уж эта тема стала такой абстрактной, могу сказать, что в российском сегменте общаться конструктивно сложно - практически всегда происходит переход на личности. Впрочем, это часто происходит и в реальности. Но на всяких интернет ресурсах - это просто данность. Лично мне это малопонятная данность.
Вполне понятная данность. Это следствие отсутствия нормальной модерации.
Цитата
Nikolay написал: Для меня как раз наоборот. dofile живет в глобальном контексте, что неудобно. По сути это предкомпилированная блок кода. При этом вместо require можно использовать конструкцию типа:
Код
local lib = load(file_path)()
что, по сути, равносильно dofile, но имеет преимущества. Как минимум, можно получить код ошибки при загрузке модуля, если таковая есть. Например, переопределив dofile так
Код
function dofile (filename) local f = assert(loadfile(filename)) return f() end
От себя добавлю, если интересно: Согласен с Антоном, сам всегда использую dofile для загрузки кусков кода или модулей на луа. require также использует loadfile, но сложнее. Зачем вам все эти пути и искатели в простой задаче, когда вы знаете где и что у вас лежит?
Код
inSecList = dofile(inFileName)
inSecList = assert(loadfile(inFileName)) () -- или так, если нужно
Roffild написал: 10. isConnected() == nil возможно! Тут явно "гонка потоков". Этот баг отловить непросто. Чтоб 100% избежать бага нужно стартовать скрипты когда все загрузилось. "Окно подключения" появляется после отрисовки графиков на старых данных - вот на этом этапе нужно стартовать скрипты, но не раньше. А может причина проще: забыли переменную в isConnected() инициализировать 0 и она периодически попадает на "грязную память".
У меня много скриптов, где есть isConnected(). Ни разу подобной проблемы не было. Если вы таки сталкивались с подобным, то порекомендую условие в цикле модифицировать так или наоборот и всё:
проблема была нами проверена - она не воспроизвелась. Поэтому просьба открыть график инструмента и таблицу обезличенных сделок и после этого закрыть терминал. Потом нужно создать архив директории терминала без *txk ключей, выложить его на какой-либо файлообменный сервер и на почту quiksupport@arqatech.com прислать письмо с ссылкой для скачивания.
Дополнительная просьба, в письме укажите, пожалуйста, ссылку на данную ветвь форума.
Видимо, это только на старых версиях бывает. Смысла что-то отсылать поэтому нет, обновлюсь как-нибудь и проверю. Спасибо.
Сейчас проверил - все стало нормально, значения на свечах соответствуют ТОС. Не знаю, что это было, но у меня это дело скрипт определил, который сравнивает, а потом я руками все перепроверил. У двух брокеров, с перезаказом данных. Если ещё раз вылезет, отскриню свечю графика.
Могли бы Вы прислать скриншоты, на которых различия будут отчётливо видны. Также уточните, пожалуйста, версию Вашего терминала.
Терминалы: 8.8.0.55 и 8.7.1.3. Скриншоты чего? На графике на индикаторе объема и на самой свече значение: 3650. Через скрипт, который обрабатывает ТОС или если просто выгрузить сделки из ТОС в эксель и просуммировать: 1825.
Здравствуйте. Наблюдаю расхождение значений объема последней свечи вечерней сессии полученной из графика и из ТОС. На графике в 2 раза больше, чем в ТОС. На примере RIZ1, 2021-10-05, 5 мин: график - 3650, ТОС - 1825; 1 мин: график - 996, ТОС - 498. Другие инструменты не проверял. Позавчера тоже было расхождение в 2 раза, раньше не проверял. Данные перезаказывал вместе с архивом.
Андрей написал: Сделать вторую версию ф-ции sendTransaction, которая пропускает "проверку достаточности средств на сервере", идет сразу на биржу. Таким образом отправленные 2 транзакции обработаются без проблем, если прийдут на биржу в таком же порядке. Это уже достаточный уровень функционала. В худшем случае биржа просто не обработает вторую транзакцию, Ведь ваша проверка на сервере Quik - это как пре(дварительный)фильтр. Без него ничего страшного тоже не произойдет - получим отказ от биржи в реплае.
С этим предложением, Андрей, вы погорячились. А, вообще, вам нужен прямой доступ на биржу без всякого этого, уж если вам скорость так критична.
s_mike@rambler.ru написал: Если вы хотите установить "невидимую" метку, просто не указывайте image_path. И потом посредством setlabel делайте с ней все что необходимо.
Если image_path указан, он должен быть обработан. Либо метка нарисована, либо должна возникнуть ошибка исполнения.
Проблем у меня ни в том, ни в другом случае не возникнет. Я писал истины ради. Если IMAGE_PATH указан некорректно, то его игнорирование - не ошибка. Метка добавляется как-будто его не указывали или указали IMAGE_PATH= "". Это просто неуказанный параметр или указанный неверно (его некорректность игнорируется). Также, как если вы укажете FONT_FACE_NAME = "нет такого", то будет добавлена метка со значением по умолчанию "Arial".
Я бы не стал это исправлять. Данный пример на мой взгляд работает корректно. Метка выставляется, её не видно, но она есть. Если её изменить с помощью SetLabelParams - всё нормально работает и возвращает true. У меня в скриптах есть такое: невидимые метки добавляются (Add), а затем устанавливаются/меняются (Set) - все нормально работает. Если в вышеуказанном примере вместо IMAGE_PATH="нет такого файла", написать: IMAGE_PATH="", то метка не добавится, nil вернет, так что оставьте как есть.
Средства разработки многопоточных скриптов в QUIK., OS_Quesha, свидетельство регистрации в Роспатенте № RU 2020612905. Бесплатная для некоммерческого использования.
Владимир написал: А как "нормальные люди" задают ID транзакции? В принципе, можно бы присобачить системное время или просто нумеровать их у себя как 1, 2, 3, 4,... А "уникальность между скриптами" меня не волнует - у меня один скрипт - есть, был и будет. Точнее, две его копии на двух Квиках.
Так и используйте время, как многие делают, зачем этот огород с рандомом? При запуске скрипта задаете начальное значение, типа:
Код
local trans_id = os.time () - 1546290000 -- идентификатор транзакции (количество секунд с начала 2019 года для UTC+3)
или просто os.time (), а дальше в скрипте: trans_id = trans_id+1
Игорь М написал: Да, 2-ой. И у меня 2-ой. Можно с префиксом "0x" поставить для наглядности: bit.band(trade.flags, 0x4). И bit.band в отличие от bit.test число возвращает. Почему bit.test лучше, чем bit.band - готов узнать.
Кроме быстродействия и наглядности никаких.
Какого быстродействия? Что быстрее bit.test или bit.band?
Николай, я предполагаю, что это вы мне написали, поэтому давайте объясню:
Цитата
А вот то, что функция аггрегирования вызывается несколько раз - это не очень. Почему не произвести расчет разово, перебрав сделки в одном цикле.
Если вы про вызовы в message, то это просто для демонстрации, чтобы человеку нагляднее было. Задачи что-то несколько раз перебирать и не стояло. Ему, вообще, только для лонга нужно было и, возможно, он один раз в конце дня этот скрипт запускает. Понятно, что одно и тоже несколько раз не нужно пересчитывать. Я также надеюсь, что он догадается при частом подсчете не обсчитывать строки таблицы каждый раз от 0 по новой при поступлении новой записи в таблицу.
Цитата
Что касается направления сделки, то если это обычная таблица trades (а не обезличенные сделки), то направление это 2-ой бит флага. И проверять его лучше логически через функцию bit.test, а не сравнивать с десятичным числом.
Да, 2-ой. И у меня 2-ой. Можно с префиксом "0x" поставить для наглядности: bit.band(trade.flags, 0x4). И bit.band в отличие от bit.test число возвращает. Почему bit.test лучше, чем bit.band - готов узнать.
local SecCode = "RIH1"
function aggrF(direction)
local value=0 -- здесь рассчитываю кумулятивное значение из столбца объем таблицы сделок
for i = 0, getNumberOf("trades") - 1 do
local trade = getItem ("trades", i) -- получение таблицы данных из i-ой строки ТС
if bit.band(trade.flags, 4) == direction and trade.sec_code == SecCode and trade.datetime.hour >= 12 then -- сделка на продажу по конкр. инструменту
value = trade.value+value
end
end
return value
end
message ("Buy: " .. tostring (aggrF(0)))
message ("Sell: " .. tostring (aggrF(4)))
message ("Total: " .. tostring (aggrF(0)+aggrF(4)))
Антон написал: Есть такая приложуха GHUB для мышек фирмы логитеч и хотелось бы привязать к клавиши как то это Там есть возможность без скрипта но тогда не будет работать клавиша как то иначе как кроме ввода значений
Александр Волфовиц написал: На малоликвидных инструментах OnQuote может и по 10 секунд не срабатывать - а время желательно чтоб было актуальное. Вроде бы проблема решилась с помощью локальных переменных перед проверкой, спасибо всем за советы!
Я, когда вам отвечал, торопился и поэтому что-то невнятное написал. Хорошо, что есть Антон, который все верно порекомендовал. В вашей ситуации проблема не только со строками/числами, но и со временем. Если вы хотите получать актуальное время, то делайте, как Антон написал, чтобы не было последовательных присвоений, а только разом. Очень маловероятна, но реальна ситуация, что в момент присвоения local hour, min, sec = hcc, mcc, scc вы получите час из старого определения времени в main, а минуту из нового. Подзавис основной поток в начале часа и у вас в OnQuote смещение на 59 минут.
Лучше перед if объявит локальную hcc, а в конце поставить hcc = hcc или что-то типа этого. Тогда для аварийной строки в OnQuote () hcc всегда будет number.
Предположение: В строке if type(hcc) == 'number' and type(mcc) == 'number' then значение глобальной hcc ещё number, а дальше при сравнении в строке "if hcc <= 10 and hcc >= 9 and mcc < 5 then" оно уже string. Попробуйте перед первым if поставить что-то типа local hcc = hcc (или как вам по коду лучше будет)
Незнайка написал: В Lua 5.1 можно было заглянуть в package.loaded[modname]. Если там userdata, то скрипт загружен через require, иначе - запущен сам. А теперь как?
Незнайка, вы в скрипте, который может запускать рассматриваемый модуль, поставьте флаг и проверяйте его в модуле. Если модуль флаг не видит, значит он сам запущен, а если видит, то снаружи.
Виталий написал: Вопрос к знающим и к поддержке: почему происходит утечка памяти? Версия Quik 8.10.1.1
Для информации: Проверил первый скрипт у себя на 8.7 и 8.8 - всё в порядке. Растет незначительными темпами, а затем сбрасывается. Если вставить collectgarbage ("step"), то совсем незначительные колебания (отклонение в 10% от 40КБ до 44КБ), а если collectgarbage () - не изменяется вообще.
Максим написал: Добрый день! Столкнулся с проблемой: на lua 5.3 пользовался такой конструкцией в модулях: module(..., package.seeall) на lua 5.4.1 - убрали module и package.seeall как проще выйти из ситуации?
module(..., package.seeall) - это старый способ. Ссылка.
Вы поменьше выкладывайте персональных данных. По поводу выведется что-то или нет проверяйте на практике самостоятельно, вопросов у вас и без мелочей ещё ворох останется. В "Интерпретаторе языка Lua" описаны функции, таблицы и пр. - пользуйтесь, и поиском по форуму тоже, здесь уже многие вещи обмусолены.
Павел написал: Коллеги, прошу подскажите, что я не так делаю? Не возвращает прочитанные количества лотов:
-- функция возвращает количество лотов в клиентском портфеле по заданному инструменту function get_lots(arg_Sec_Code) local lots = 0 for i = 0, getNumberOf("FUTURES_CLIENT_HOLDING") - 1 do if getItem("FUTURES_CLIENT_HOLDING",i).sec_code == arg_Sec_Code then lots = getItem("FUTURES_CLIENT_HOLDING",i).totalnet end end return lots end
Буквы высокие.
Код
local function get_lots (arg_Sec_Code)
for i = 0, getNumberOf ("FUTURES_CLIENT_HOLDING") - 1 do
local fch = getItem ("futures_client_holding", i)
if fch and fch.sec_code == arg_Sec_Code then
return fch.totalnet -- or 0
end
end
return 0
end
Александр Кашников написал: Склейка инструментов на срочке - подтверждаю - это бред, который никому не нужен. Свечки это совсем не актуальная информация, их перерисовывают при каждом клиринге - скрывают сделки крупных ММ. А тут еще вы со своей склейкой и главное выбора никакого нет , а я не просил склейку и никто не просил, даже Вася не просил, я у него спрашивал.
Склейка по умолчанию стоит включенной (было бы правильнее сделать её выключенной по умолчанию), но она отключается. Я при замене инструмента с истекающем сроком обращения отключаю склейку вручную.
Игорь М написал: Я хочу привести данную таблицу к состоянию, которое изображено на первом скрине этой темы. Да, вы правильно понимаете: ячейки цены должны быть выделены жирным и быть такого же цвета, что и остальные ячейки соответствующей строки. Раньше все было как и должно быть (этот первый скрин был сделан специально в 7-й версии предварительно перед обновлением на 8-ю, так как на другом терминале при обновлении я заметил это нововведение). Сейчас же ячейки цены выделяются серым цветом.
Как можем видеть на Вашем скриншоте, для параметра "Цена" у Вас установлено форматирование - стоит галочка для "Форматирование включено" в левом верхнем углу. Отключите форматирование, сняв галочку с этой опции.
Хорошая шутка! Еще можно посоветовать выключить Квик и компьютер. Евгений, вы спрашивали: "Уточните, пожалуйста, к какому состоянию Вы хотите привести данную таблицу?" Я ответил, что хочу привести данную таблицу к состоянию, которое изображено на первом скрине этой темы". Думал, что ответил понятно, но попробую объяснить еще раз: Я сам включил это форматирование, а не оно само как-то включилось. Включил я его для того, чтобы значение цены всегда выделялось жирным шрифтом. Одновременно с этим надо, чтобы строки таблицы форматировались целиком по цвету, включая ячейки со значениями цены. Это работало. Раньше. Что я и продемонстрировал в первом скрине. Вы можете сделать также, как у меня на первом скрине, какими-то пользовательскими настройками или это баг?
Roman Azarov написал: Старатель, добрый день! если в терминале используется таблица обезличенных сделок, экспорт тиков во внешние системы или же построение тикового графика, то с сервера QUIK будут заказаны все сделки по всем инструментам, на получение информации по которым у терминала (пользователя) есть права независимо от того, какие фильтры настроены в таблице обезличенных сделок или по какому конкретному инструменту открыт тиковый график.
Как-то это нерационально. Зачем получать то, что не нужно? У МБ 80-90% мало кому интересный неликвид. Зачем его транслировать, если человек работает только с RI и Si? Где в такой логике минимизация трафика и улучшение производительности?
Evgeniy Karnaukhov написал: Игорь М, уточните, пожалуйста, к какому состоянию Вы хотите привести данную таблицу? Правильно понимаем, что Вы хотите, чтобы ячейки Цены НЕ подсвечивались отдельным синим цветом? Если так, то нужно проверить именно настройки форматирования по Цене. Пришлите, пожалуйста, скриншот окна форматирования по параметру "Цена".
Я хочу привести данную таблицу к состоянию, которое изображено на первом скрине этой темы. Да, вы правильно понимаете: ячейки цены должны быть выделены жирным и быть такого же цвета, что и остальные ячейки соответствующей строки. Раньше все было как и должно быть (этот первый скрин был сделан специально в 7-й версии предварительно перед обновлением на 8-ю, так как на другом терминале при обновлении я заметил это нововведение). Сейчас же ячейки цены выделяются серым цветом. пс. Сделайте ограничение по размеру для уменьшения картинки, чтобы скрины меньше определенного размера уже не уменьшались (87 КБ уменьшает до 29, а потом не ясно, что изображено)
Вероятно, нужно проверить форматирование таблицы сделок по Цене. Для этого правой кнопкой мыши щелкните по столбцу "Цена" и выберите "Форматирование "Цена"". В открывшемся окне должны быть заданы условия и цветовые настройки. Вы можете их как изменить, так и вовсе убрать, нажав на значок крестика справа от условий или сняв галочку с "Форматирование включено" в левом верхнем углу окна (так форматирование не удаляется, а просто отключается).
Евгений, так не получается что-то, потыкал я как раньше, но так, чтобы выделялся жирным столбец и при этом менялись по цветам строки без появления серого фона, не выходит. Может у вас получится? Спасибо.
Алексей написал: Допустим получаю значение цены через OnAllTrade. Далее пишу это значение в файл или таблицу - получается 77934.0 Как сделать, что бы была обычная запись 77934, без .0 ? Только недавно перешел с 32б QUIK, в 64b. В старом такого не было.
Старатель написал: Сравнение в скорости линейного поиска с SearchItems:
Цитата
Искомый элемент в начале таблицы: linSearch: 0.660 SearchItems: 0.495
Цитата
Искомый элемент в конце таблицы: linSearch: 18.437 SearchItems: 4.919
Да, у меня такие же пропорции по результатам. То, что линейный быстрее SearchItems, я писал для случая вызова SearchItems без параметров, а с параметром он быстрее, да. И сжирается всё вызовом getItem. Арковцы писали, что в 8-й версии была исправлена "Медленная работа функции getItem в QLUA", я сравнил, но что-то разницы с 7-й не заметил.
Старатель написал: не лазить в таблицу "all_trades" в поисках нужной сделки - очень сильно затормаживает расчёт: сам только вызов SearchItems увеличивает время расчёта в 10 и более раз.
Старатель, здравствуйте. Увидел это ваше сообщение по поводу использования SearchItems в ТОС, а так как я раньше об этой функции не знал (как-то ускользнула от моего внимания, другие использовал), то решил её проверить и написать, что получил. Может кому-то ещё эта инфа пригодится. Сравнил её только с двумя методами поиска: линейным и бинарным. Если искать по идентификатору сделки порядковый номер в таблице, то даже линейный поиск быстрее на 30%. Бинарный быстрее в 7000 раз. Если вызывать SearchItems с параметром "trade_num", то он быстрее вызова без параметра в 10 раз (в 700 раз медленнее, чем бинарный). Не понял я замысла сей функции и области её применения. Может что-то ускользнуло от моего внимания, какой-то смысл в неё заложенный, поэтому вы у себя проверьте, вот функции, которыми проверял:
Код
local function linSearch (t, id, num_1, num_2) -- функция линейного поиска
while num_1 <= num_2 do
local t_trade_num = getItem (t, num_1).trade_num -- номер сделки в таблице
if id == t_trade_num then -- сравнение идентификационных номеров
return num_1
else
num_1 = num_1 + 1
end
end
end
local function binSearch (t, id, num_1, num_2) -- функция бинарного поиска
while num_1 <= num_2 do
local middle = num_1 + math.floor ((num_2 - num_1) * 0.5) -- середина диапазона
local t_trade_num = getItem (t, middle).trade_num -- номер сделки в таблице
if id < t_trade_num then -- сравнение идентификационных номеров
num_2 = middle
elseif id > t_trade_num then
num_1 = middle
else
return middle
end
end
end
local res = linSearch ("all_trades", 26139171939000, 0, getNumberOf ("all_trades") - 1) -- вызов
Здравствуйте, Андрей. Да, я знаю и пользуюсь выводом DDE и ещё у меня скрипт написан на вывод определенной информации в файл, так что с возможностями вывода я знаком. Мне хотелось бы, чтобы те вещи, которые в программе были изначально и очень давно сделаны нормально и удобно, не переделывались в угоду непонятно кому. Вот кому вдруг понадобился вывод объемов, цен, маржи и пр. в строковом формате при копировании правой кнопкой? Такие вещи для любителей лишних движений нужно делать опционально. А многие люди, вообще, не врубаются в эти выводы всякие разные, а просто копируют таблицу ctrl+C и вставляют в Excel. Таких людей много, о них не нужно забывать. Регистрировать ли пожелание на восстановление функционала? Зачем его регистрировать, его просто восстановить нужно. Кому он мешал и чем руководствовались люди, которые его ломали? Вы почаще спрашивайте практикующих трейдеров что им нужно, что менять, а что нет. Мне пришлось вернуться к старой версии из старой сохранённой перед обновлением папки (да, опыт сын ошибок трудных, научили). Чего ради такие "улучшения"? Появляется одна нормальная вещь: увеличение количества условий в пользовательском фильтре и одновременно - на, получай косячину в довесок. По поводу приоритета копирования ячейки сочетанием ctrl+C, а не всей таблицы - тоже вопрос. Неужели люди чаще ячейками копируют? Пользователи много лет при копировании таблицы целиком нажимали ctrl+C, а теперь, вводя возможность копирования ячейки, вы перекидываете комбинацию клавиш, которая уже у всех на автомате наработана, на другой функционал. Новый функционал нужно вешать на новые комбинации клавиш, старый оставлять на старых.
Обновил Квик до указанной версии. Копирую содержание таблиц (сделки, клиентский портфель, таблица ограничений по клиентским счетам) в Excel и вижу, что что-то имеет строковый формат, а что-то числовой (например: "Премия по опционам" - строка, а следующий столбец "Биржевые сборы" - число). Нельзя ли этот ужас исправить и сделать как было раньше на старых версиях (в числах). Зачем такое было сделано? Или если существуют какие-то люди, которым такое понадобилось, то сделайте опцию: вывод строк. Всё было просто и удобно: взял и скопировал без всяких бубнов. По уму и Ctrl + C в таблице на ячейку тоже на выбор опционально лучше сделать, приоритет на ячейку вместо таблицы целиком непонятен, я, например, ячейки по отдельности не копирую.
Egor Zaytsev написал: Игорь, не понимаем, что в итоге нужно править? График строится исключительно выставленным обезличенным сделкам.
Егор, здесь не нужно ничего править, классический тиковый график нормальный. Это раздел пожеланий и у меня пожелание. Можно сделать ещё один тип отображения сделок на тиковом графике, где сделки будут отображаться более наглядно для восприятия трейдером. По отображению будет напоминать профиль рынка.
Сделки №228000001-228000031 произошли в один момент времени, например в 16:10:23 785462 мкс. Порядок возрастания их биржевых номеров слева направо и сверху вниз. Сделка №228000032 уже имеет другое время. Мы понимаем, что сделка 1 произошла раньше сделки 31, но время у них одно и по идее они все должны лежать на одной вертикальной линии. Так отобразить можно только на трехмерном графике (цена, время, номер), но это сложно и не нужно. Приведенный мною пример отображения сделок более компактен и более нагляден для анализа, сразу видно в какие моменты кто сколько по рынку рубанул. Объемы можно отображать как у свечей, то есть в данный момент времени (левая вертикальная линия) кто-то 500 контрактов продал разом. пс Вещь некритичная, сам я на более крупных таймах торгую, но такая мысль появилась. Можно, конечно, скрипт написать, который таблицу всех сделок будет обрабатывать и куда-нибудь выводить, но раз уж терминал классический тиковый график способен нарисовать, то может и такой осилит.
s_mike@rambler.ru написал: Человек ошибочно считает, что сделки, прошедшие одним временем на тиковом графике должны быть расположены в одном и том же времени, на одной и той же вертикали графика. Без сдвига по горизонтали.
Egor Zaytsev написал: Добрый день. Не совсем понятна описанная проблема. На скриншоте сделок не видно. Можете сделать четкий скриншот, чтобы была видна сделка и что именно с ней не так.
Это не моя сделка. Кто-то по рынку продал 1250 контрактов в один момент времени (нисходящая большая линия). Продажи в верхней и нижней точках произошли одновременно, на графике же и них разные координаты по оси абсцисс.