Не то название настройки скопировал... Ну почему нельзя отредактировать сообщение? Правильно так:
Если в настройках получения данных стоит галка "С учетом настроек, выбранных пользователем вручную через пункт меню Система/Заказ данных/Поток котировок...", то ни ParamRequest ни CreateDataSource не могут заказать получение параметров Таблицы текущих торгов с сервера. При этом они радостно сигнализируют об успехе. Нужно изменить такое поведение.
Надо делать так, как надо. А как не надо - делать не надо.
Если в настройках получения данных стоит галка "Исходя из настроек открытых пользователем таблиц", то ни ParamRequest ни CreateDataSource не могут заказать получение параметров Таблицы текущих торгов с сервера. При этом они радостно сигнализируют об успехе. Нужно изменить такое поведение.
Надо делать так, как надо. А как не надо - делать не надо.
function table.transform(tab)
local ntab = {}
for k, v in pairs(tab) do ntab[v] = k end
return ntab
end
ticker = {}
ticker["SBER"]= 3
ticker["LKOH"]= 2
ticker["GAZP"]= 1
for k, v in ipairs(table.transform(ticker)) do
print(v, k)
end
Надо делать так, как надо. А как не надо - делать не надо.
Алексей написал: Не прослеживается единообразия в логике вызовов Init() со стороны Quik: при исходном добавлении индикатора на график, Init() вызывается до привязки к источнику данных, а при замене инструмента Init(), почему-то, вызывается уже после привязки к новому инструменту.
При добавлении индикатора сразу указывается Источник данных. Поэтому описанное поведение больше похоже на ошибку в логике.
Надо делать так, как надо. А как не надо - делать не надо.
Здесь нет задержки. По оси y отложена цена инструмента из пришедшего колбэка. Что касается задержки, то вы никакими супер-атомными часами не получите время задержки для OnParam в QUIK. Вы ведь не серьёзно про часы-то?
Цитата
Николай Камынин написал: Как Вы узнали что в OnParam нет лучшей цены?
На график в OnParam выведены только изменения по LAST.
Надо делать так, как надо. А как не надо - делать не надо.
Optimus1 Optimus1 написал: 1)Стиратель не нужно пожалуйста поспешных выводов, с моей стороны это не более чем ошибка при копировании из блокнота
Optimus1 Optimus1, ну так и приводите полный рабочий код того скрипта, на котором у вас возникает проблема, в удобочитаемом виде,
Скрытый текст
а не состряпаную из кусков разных программ портянку, где пустых строк больше, чем полезного кода. Вам самому-то удобно это читать? Но я думаю, что вы уже поняли, что инкремент работает, как надо.
Надо делать так, как надо. А как не надо - делать не надо.
Sergey Gorokhov, по-моему товарищ вас тролит, предлагая явно неработающий код (при этом утверждает, что чё-то там выводится) и отвлекая от РАБОТЫ. У вас ведь есть чем заняться? Ошибок-то в терминале полно! Надо исправлять.
Alexey Ivannikov написал: Если у Вас есть что посоветовать - пожалуйста.
1. Самый простой вариант:
Цитата
quikscalp написал: Значения индикаторов следует исключить из учёта при автоматическом масштабировании графиков, как это сделано для цен заявок и позиций.
2. Вариант посложнее: Масштабировать график таким образом, чтобы в видимую область попадало последнее значение индикатора. Т.е., автомасштабировать с учётом последней точки индикатора.
Надо делать так, как надо. А как не надо - делать не надо.
Чтобы узнать, кто пришёл раньше, атомные часы не нужны. Есть такое понятие, как точка отсчёта.
Скрытый текст
По оси х отложено время получения колбэка (в мс) с момента начала отсчёта. В OnParam - только параметр LAST, никаких стаканОв. Данные с боевого сервера - незадолго до окончания торгов.
Надо делать так, как надо. А как не надо - делать не надо.
Для максимальной производительности количество ядер должно быть не менее, <количества запущенных роботов + 1> (если QUIK один). Если это условие соблюдено и частоты процессоров в обоих случаях одинаковы, то потери в производительности быть не должно. Но есть технология Turbo Boost, которая может изменить расклад. Не знаю работает ли она на виртуалках.
Что касается памяти, то тут немного сложнее. Дело в том, что Windows часть данных выгружает в swap-файл на HDD или SSD (даже если памяти полно). Чем меньше ОЗУ, тем больше данных будет выгружено в swap, а операции чтения/записи на HDD во много раз более затратны, чем с ОЗУ. Поэтому оперативной памяти в Windows много не бывает )) Если же комп будет часто "свопиться", то потеря в производительности может быть очень существенной.
Надо делать так, как надо. А как не надо - делать не надо.
Космонавт, Никто не сможет дать вам точный ответ, какой вариант будет достаточным и необходимым конкретно в вашем случае. Поскольку вы и сами то толком не знаете, была ли необходимость что-то усложнять. А мы и подавно этого не знаем. Тов. swerg задаёт вам правильные вопросы, прислушайтесь к ним.
Цитата
Космонавт написал: 3 решение самое сложное (я сейчас им пользуюсь). Две виртуалки, в каждой из которой сидит свой КВИК со своим роботом. Но и тут Старатель опровергает преимущества, но толком не объясняет почему.
Старатель не опровергает, по той же причине: вы и сами не можете ответить, что вы хотите этим улучшить и за счёт чего. А я не могу знать, может, в вашем случае этот вариант даст какие-то преимущества.
Надо делать так, как надо. А как не надо - делать не надо.
Космонавт, Как я полагаю параллельного получения колбэков с одного сервера QUIK не добиться (разработчики меня поправят, если ошибаюсь) даже на нескольких терминалах. Значит, то что вы можете ускорить - это исполнение кода самого колбэка, если он у вас действительно медленно работает. Добиться этого можно либо увеличением частоты процессора либо распараллеливанием исполнения по разным потокам (при наличии ресурсов). Но не внутри одного квика, а в разных терминалах.
Надо делать так, как надо. А как не надо - делать не надо.
Николай Камынин написал: Чтобы колбеки исполнялись параллельно надо внутри колбеков открывать потоки. А луче (я делал именно так) колбеки выносить в отдельные скрипты. В резлутате будет вообще-то, для каждого колбека будет свой поток.
Только выполняться каждый из параллельных потоков будет дольше, чем при последовательном исполнении. Отсюда - выигрыш в скорости от параллельного исполнения колбэков под вопросом.
Надо делать так, как надо. А как не надо - делать не надо.
Космонавт написал: Уже арендовал вторую, теперь ммвб-шный робот на одной виртуалке, фортс-робот на второй. Процессора хватает, памяти хватает, скорость интернета немыслимо хороша. Как оценить скорость срабатывания колбеков и понять выиграл я в скорости или равнозначно?
Обе виртуалки стоят на одном физическом сервере с одним сетевым интерфейсом? Оба квика подключены к одному серверу QUIK? За счёт чего предполагается получить "выигрыш я в скорости"?
Надо делать так, как надо. А как не надо - делать не надо.
Я изначальный вопрос не понял. Функция mycallbackforallstocks может быть одна. Но CreateDataSource(class,sec,interval):SetUpdateCallback нужно задавать для каждого таймфрейма.
Надо делать так, как надо. А как не надо - делать не надо.
SDL написал: Качаем модуль LuaSec: Проект: https://github.com/brunoos/luasec Бинарники можно взять тут: http://love2d.org/forums/viewtopic.php?f=5&t=76728. Нужны 2 файла - ssl.dll и ssl.lua. Использует библиотеки OpenSSL libeay32.dll и ssleay32.dll. Скачать, если нет, и не забыть обеспечить к ним доступ - через окружение (PATH) или можно кинуть в папку с QUIK.
При отправке первого письма из скрипта с gmail.com приходит ответ "closed". Второе и последующие письма отправленные, из того же скрипта (причём, первым может быть и mail.ru) уходят нормально. Кто-нибудь сталкивался с таким? Как лечить?
Надо делать так, как надо. А как не надо - делать не надо.
Борис Гудылин написал: Затем пошел второй перерасчет индикатора (сейчас это, как бы, норма)
Когда два, а когда и три раза индикаторы пересчитываются. Вот код:
Скрытый текст
Код
Settings = {
Name = "Учимся считать",
Param = 0,
line = {{Name = 'Test'}}
}
message('[Body] Param=' .. Settings.Param )
function Init()
message('[Init] Param=' .. Settings.Param)
return 1
end
n = 0
function OnCalculate(index)
if index == 1 then
n = n + 1
message('[OnCalculate] ' .. tostring(index) .. ': Param=' .. Settings.Param .. '; расчёт ' .. n)
end
return nil
end
Чтобы задать сразу параметры индикатора, дабы избежать лишних пересчётов, делаю следующее: открываю "Редактирование настроек графика" -> Добавить -> Выбираю индикатор -> Добавить Далее в свойствах индикатора меняю значение параметра -> OK Не тут-то было. Вот результат:
Скрытый текст
Как видно, индикатор рассчитывается три раза (!), причём первый расчёт идёт со старым значением, но уже после нажатия на кнопку OK.
Предложения:
1. Исправьте ошибку с лишними пересчётами индикаторов при их добавлении или изменении.
2. Дайте доступ к чтению свойств линий из OnCalculate
Надо делать так, как надо. А как не надо - делать не надо.
Stanislav Tvorogov написал: реализация пожелания признана потенциально целесообразной
Как бы хуже не стало... Не знаю, что там признано целесообразным, но если вместо одного выпадающего списка на панели появятся 17 кнопок, то не вижу ничего хорошего.
Надо делать так, как надо. А как не надо - делать не надо.
Функция CreateDataSource никогда не возвращает ошибку, И это создаёт большие проблемы при разработке. В неё можно запихнуть любой мусор, и она скажет: "Всё отлично".
Антон Кыт. написал: Чтобы это определить, всем пользователям QuikLUA был бы полезен метод датасорса ds:ServerSize() Его смысл в том, чтобы сразу узнать сколько всего баров данного таймфрейма имеется на сервере истории?
s = setmetatable({}, { __index = function(t, i)
local result = print('Считаем...') or i * i
t = result
return result
end})
print(tostring(s[3]))
print(tostring(s[3]))
Результат:
Цитата
Считаем... 9 Считаем... 9
Надо делать так, как надо. А как не надо - делать не надо.
function func(v)
return v * v
end
s = {
f = function(v)
local r = s.r
if not r then
r = func(v)
s.r = r
end
return r
end
}
print(tostring(s.f(3)))
print(tostring(s.f(3)))
Функция s.f() запоминает вычисленное значение и при повторном обращении возвращает раннее вычисленное значение. Можно ли описать её через setmetatable? PS: возвращать она должна раннее сохранённое значение, независимо от переданного аргумента при повторном вызове.
Надо делать так, как надо. А как не надо - делать не надо.
В Квике все получаемые параметры из терминала надо проверять не только на nil, но и на ноль:
Код
local last_price = getParamEx(classcode, seccode, "LAST").param_value
if last_price == nil then
-- Ошибка получения цены последней сделки
elseif last_price == 0 then
-- отправляем гневное сообщение в адрес разработчиков
else
-- работаем дальше
end
Уверен, что такая же беда при вычислении
Код
exit_price = price + stop_level_2000 + sl
Надо делать так, как надо. А как не надо - делать не надо.
Andrei2016 написал: почему срабатывание функции SetSelectedRow() не приводит к каким-либо визуальным изменениям в указываемой таблице?
Возможно, потому, что при нажатии на левую клавишу мыши срабатывают сразу три события: QTABLE_LBUTTONDOWN, QTABLE_SELCHANGED, QTABLE_LBUTTONUP Т.е., событие QTABLE_SELCHANGED возвращает выделение на нажатую строку после вашей функции funcCallback. Попробуйте так:
Код
if (msg == QTABLE_LBUTTONUP) then
local r = SetSelectedRow(t_id, 12)
Надо делать так, как надо. А как не надо - делать не надо.