В документации написано, что getItem возвращает таблицу.
Однако, вызов getItem("client_codes", 0) возвращает строку с номером счёта (индекс может быть и ненулевой -- ситуация не меняется). То есть, ошибка либо в документации, либо в реализации функции.
Yerlan, если Вам C++ по плечу, то с Lua не должно возникнуть трудностей. Насчёт оптимизаций (преждевременных и необдуманных) -- забудьте. Сделайте рабочий вариант, пусть и медленный. От него и будете плясать. Если C++ ближе, то делайте на нём -- всё равно в итоге с Lua пересядете рано или поздно на что-то другое. Но, имхо, мотивацией должно служить в первую очередь удобство и скорость разработки, а не мнимое быстродействие. В противном случае, рискуете уехать в дебри и, не увидев осязаемого результата, забросить.
Вторую функцию вызывайте через allwords()() (соответственно, к предыдущему посту: values(t)() -- так можно). Сама функция возвращает функцию-генератор. Функция-генератор -- это такая функция, которая сохраняет некое состояние между её вызовами.
Код
function allwords ()
local line = io.read() -- текущая строка
local pos = 1 -- текущая позиция в строке
return function () -- итерирующая функция
while line do -- повторяет, пока есть строки
local s, e = string.find(line, "%w+", pos)
if s then -- слово найдено?
pos = e + 1 -- следующая позиция после этого слова
print(string.sub(line, s, e))
return string.sub(line, s, e) -- возвращает это слово
else
line = io.read() -- слово не найдено; пробуетследующую строку
if string.len(line) == 0 then
line = nil
end
pos = 1 -- перезапуск с первой позиции
end
end
return nil -- строк больше нет; конец обхода
end
end
local fetch_next_word = allwords()
while fetch_next_word() do end
Этот код будет выводить Вам все слова из введённой строки, пока Вы не введёте пустую строку. Если не проверять на ввод пустой строки, то программа сама не завершится, т.к. пустая строка -- это всё ещё строка (т.е. не nil).
Т.е., проще говоря, присваивание iter = values(t) записывает в iter ссылку на функцию-итератор (генератор), и присваивание element = values(t) делает то же самое. А вот уже вызов этой функции даст вам следующий элемент таблицы-массива.
У Вас values(t) возвращает функцию. Соответственно, Вы её и вызываете посредством iter(). Не помню, легален ли такой синтаксис, но попробуйте values(t)().
function _Window (title, x, y, width, height, background_color, border)...end
Функция Window определена как
Код
function Window (options)
--проверка валидности options
...
--вызов _Window
_Window( options.title,
options.x or 0, -- значение по умолчанию
options.y or 0, -- значение по умолчанию
options.width,
options.height,
options.background or "white", -- по умолчанию
options.border -- по умолчанию false (nil))
end
Т.е., по сути, Window, в данном случае, -- это обёртка над _Window, предоставляющая более удобный API.
Let_it_go написал: Скрипт работает и делает то что нужно, но на каждой итерации вызывается раздражающее окошко cmd.exe:
Код
for i = 2000 , 2018 do
--подготовка настроек для скрипта питона
os.execute ( "C:\\InstallPython\\python.exe C:\\py+lua\\parser.py" )
--работа с данными, полученными питоном
end
os.execute("C:\\py+lua\\parser.pyw") ИЛИ os.execute("C:\\InstallPython\\pythonw.exe C:\\py+lua\\parser.pyw") не решили проблему. Видимо, окошко вызывается не питоном, а командой Луа os.execute Подскажите, что ещё можно сделать, чтобы ИЛИ избавиться от окошка ИЛИ заставить его вызываться единожды, а не каждую итерацию как сейчас.
Принятый ответ гласит, что никак. Далее в ответах предлагается пара путей обхода: один с использованием WScript.Shell, другой -- с использованием библиотеки-обёртки над вызовом утилиты командной строки.
Enfernuz написал: Надо понимать, что в Lua 5.1 нет понятия целого числа (Integer). Есть только Number, который маппится нативно на что-нибудь типа ptrdiff_t или double. Например, в исходниках LuaForWindows 5.1.5-52 в luaconf.h:
Код
# define LUA_NUMBER double
О. По ходу, я ошибаюсь. В том же файле есть:
Код
/*
@@ LUA_INTEGER is the integral type used by lua_pushinteger/lua_tointeger.
** CHANGE that if ptrdiff_t is not adequate on your machine. (On most
** machines, ptrdiff_t gives a good choice between int or long.)
*/
#define LUA_INTEGER ptrdiff_t
Насчёт ptrdiff_t есть хорошая статья: https://www.viva64.com/ru/a/0050/#ID0EUGAC На 32-битной сборке размер LUA_INTEGER, по сему, будет 32 бита. Опять же, с учётом знаковости, максимально можно представить 2^31-1.
Надо понимать, что в Lua 5.1 нет понятия целого числа (Integer). Есть только Number, который маппится нативно на что-нибудь типа ptrdiff_t или double. Например, в исходниках LuaForWindows 5.1.5-52 в luaconf.h:
BlackBoar написал: Возник очередной нубский вопрос. Какие максимальные значения может принимать тип Number? Из документации и гугла однозначно понятно что для чисел с плавающей точкой используется сишный 8-битовый double.
По целочисленным наткнулся на ряд комментариев типа "может зависить от реализации луа".
Поэтому уточненный вопрос звучит так, какое максимальное допустимое целое число в луа-машинке QUIK? Если такого рода вещи есть где-то в документации по QLua подскажите пожалуйста где именно, я не нахожу. А документация по луа "вообще" в свете комментариев "может зависеть от реализации" как-то не вызывает доверия ))
В QUIK 32-битная Lua 5.1. Максимальное целое знаковое число, соответственно, 2^31 - 1
.rockspec -- это не модули, а его метаданные для менеджера пакетов (как скачать модуль, как собрать модуль). Модули -- это обычные наборы .lua и *.dll (*.so) файлов (или их исходные коды). Можете взять и перекопировать модуль из LuaRocks в QUIK, конечно. Я, если честно, так и делал.
По умолчанию LuaRocks внутри себя создаёт директорию systree, где в lib хранятся библиотечные файлы модулей, а в share -- *.lua.
Про LDIR -- либо он намертво прикручивается к дистрибутиву Lua при его компиляции, либо где-то есть конфигурационный файл, в котором можно добавить директорию в пути поиска (по аналогии с переменной окружения PATH в Windows). Но я такого конфигурационного файла не нашёл. Если говорить о Lua-машине в Quik, то точно ничего подобного нет, так что там для решения проблемы мне известны два варианта: 1) вариант с package.path; 2) поместить все искомые модули в папки /lua (*.lua) и /Include (*.dll -- ещё можно в корень Quik'а кидать их, а для некоторых .dll не можно, а нужно) в дистрибутиве Quik.
Добавьте директорию с модулями LuaRocks LDIR Вашего Lua-интерпретатора. Точно не знаю, но вроде LDIR устанавливается во время компиляции Lua-машины (файл luaconf.h). Если говорить об уже собранном дистрибутиве, то либо нужно сказать LuaRocks, чтобы он хранил свои модули внутри дистрибутива Lua, либо вручную в каждом файле переопределять переменную package.path перед использованием директивы require:
Установите Visual Studio С++ (бесплатная версия -- Community Edition). LuaRocks запускайте из под "Developer Command Prompt" (ну, или добавьте cl.exe, поставляемый в Visual Studio C++, в PATH).
s_mike@rambler.ru написал: Ну да, типа такого. Можно ещё посмотреть на возвращаемое значение pcall
хм... а как мне в функцию foo передать параметр?
Код
function main ()
while is_run do
pcall(foo( "privet" ))
mm(t) --печать в виде message таблицы из файла.
sleep ( 1000 )
end
end
function foo (slovo)
a = slovo
dofile ( "C:\\1.lua" ) --здесь сидит таблица t
end
выдаёт ошибку bad argument #1 to 'pcall' (value expected)
Блин, ну Вы бы хоть гуглили для начала...
pcall принимает функцию, значит, нужно передать ему функцию:
Я думаю, Вам об этом стоит задуматься лишь тогда, когда (если) Вы упрётесь в какой-нибудь боттлнек при реализации своих алгоритмов на Lua в QUIK. Ну, или если просто владеете другим языком лучше , чем Lua :)
Let_it_go написал: Suntor пытаюсь запусить ваш код dll в Visual Studio 2017 Community Такая ошибка возникает при нажатии на "собрать решение". Спасибо за помощь.
Let_it_go написал: Visual Studio C++ очень тяжёлый. JetBrains CLIon подойдёт? --- В Code Blocks можно выбирать разные компиляторы. Разве это не то что нужно?
CLion -- платная.
Студия -- де-факто стандарт IDE для разработки на плюсах под винду. Ставьте бесплатную Community Edition -- хватит за глаза.Ну, и Ваш скрин от Code::Blocks позволяет предположить, что собирать в ней можно любым из предложенных инструментов. Теперь разве что осталось посмотреть, как там в принципе настроить доп. директории для компилятора и линкера и всё -- можно собирать без замусоривания стандартной директории библиотечными файлами.
Полагаю, это потому, что в оригинальной библиотеке bitop функция bit.test отсутствует и добавлена ARQA для удобства новичков, в то время как bit.band -- олдскульный способ проверки флагов, покрывающий все случаи.
Да, с помощью указания соответствующей опции компилятору. Вижу у Вас MinGW, так что, полагаю, сборка производится с помощью gcc. Для gcc указать дополнительные директории для поиска заголовочных файлов можно с помощью опции -I gcc ... -I "C:\Program Files (x86)\Lua\5.1\include" ...
Code::Blocks уже давно не пользовался, но наверняка там можно найти отвечающий за это пункт меню. Что-нибудь типа "Include Directories". Забегая вперёд: дополнительные директории для поиска библиотечных файлов для линковки можно задать и линкеру (т.е. компоновщику).
Я, быть может, плохо искал, но в документации нигде не вижу списка изменений, внесённых в каждой следующей версии.Беглый взгляд по файлу "Интерпретатор языка Lua.pdf" в поисках новых функций или дополнения информации к существующим -- не слишком надёжный способ.
Например, в версии 7.16 (по сравнению с 7.14) добавили функцию "sysdate" (технически, она там была и до этого, но опустим этот момент) и выделили под неё отдельный пункт. В короткий срок я об этом узнать не могу -- только чтение мануала.
Let_it_go написал: Спасибо за ответ. Я скорее всего так и поступлю. Какой язык лучше использовать? В моём случае это равносильно вопросу "какой язык учить". Чистый Си или Си++? Задача будет такая: получение данных из квика и перебор их брутфорсом. Скорость обработки должна быть максимальной.
Вы какой-то фигнёй маетесь, честное слово. Сам факт использования QUIK для получения маркет-даты и совершения транзакций перечёркивает весь перфоманс. То, что Вы там свой массивчик обработаете не за 5 мс, а за 1, погоды особо не сделает. Мой Вам совет -- оставьте мечты о перфомансе до тех пор, пока не напишите работающий неоптимизированный вариант.
В Lua-машине в QUIK, конечно, тесновато, поэтому что-либо сложнее торговли по скользящим средним проще написать в другом окружении. Из простого можете взять QuikSharp и делать обработку данных в шарпе.
1pyxa1 написал: на lua програмирую ноль дней, но что-то мне подсказывает, что lua - case sensitive, и if statement нужно писать с маленькой буквы. строка 34.
А в каком языке программирования if statement -- не case sensitive?
Хотелось бы, чтобы в документации помимо перечисления полей для возвращаемых библиотекой объектов (из обычных функций API и из коллбэков On*) было также указано, может ли значение отсутствовать или нет. Сейчас приходится делать практически наугад, что заметно осложняет создание схемы объектов, например, в тех же Protocol Buffers: например, в том же trans_reply от OnTransReply не указано, может ли отсутствовать order_num. Я так понимаю, что может отсутствовать, в случае если это невалидная тразакция. С сериализацией null в бинарных протоколах, скажем так, не очень, поэтому мне приходится делать это поле не примитивом, а строкой, и на стороне десериализации трактовать пустую строку как null. И таких полей великое множество. Если бы в документации было указано, что nillable, а что -- нет, то это существенно облегчило бы задачу и бонусом добавило бы производительности в конечное решение.
При посыле транзакции с завышенным числом лотов в терминале выскакивает сообщение "Превышен лимит по бумаге", но в возврате от sendTransaction -- пустая строка. Это баг или фича?
Многие функции библиотеки в результате своей работы возвращают nil. Но есть такие, которые возвращают nil и в случае "нормального" (в логическом смысле) режима работы. Например, функция SearchItems. Если передать ей коллбэк "function(t) return false end", то ожидая получить пустую таблицу на выходе (= пустой массив в Lua, "индексов, удовлетворяющих условию, не найдено"), на самом деле мы получаем nil. Тот же самый nil мы получим, если произошла ошибка в коллбэке. Тем самым, получив nil, сложно понять, не нашлось ли индексов по условию или это в коллбэке ошибка.
Ещё функции, где возникают подобные вопросы: getMoneyEx -- что в случае ошибки во входных параметрах (например, передал nil в качестве всех параметров), что в случае просто отсутствия информации (допустим, указали валюту, которой нет на лимитах -- это ведь не ошибка?) возвращается nil. Т.е. непонятно, то ли в аргументах ошибка, то ли просто информация не найдена. getDepoEx -- аналогично; getFuturesLimit - аналогично; getFuturesLHolding -- аналогично; getSecurityInfo -- тут спорно, т.к. nil можно трактовать как отсутствие информации по переданной паре аргументов. Т.е. что nil, что {} в данном случае -- в принципе, одинаково можно понять. nil даже получше будет, наверное.
Например, есть функции, где отсутствие информации трактуется как "не nil", и где ошибочные ситуации не задокументированы: getClassSecurities -- возвращает пустую строку; getMoney -- возвращает параметризованную таблицу со значениями по умолчанию (нули); getDepo - см.getMoney; getCandlesByIndex -- возвращает ({}, 0, ""), если запросили несуществующих тег; CalcBuySell - возвращает (0, 0), если передать nil'ы в качестве аргументов; getParamEx -- возвращает таблицу, если намеренно передать "испорченные" аргументы; getParamEx2 -- см. getParamEx; getPortfolioInfo -- возвращает {}; getPortfolioInfoEx -- см. getPortfolioInfo; getBuySellInfo -- см. getPortfolioInfo; getBuySellInfoEx -- см. getPortfolioInfo.
Отдельно: IsWindowClosed -- функция задокументирована так, что по сути ожидать приходится возврата либо nil, либо true. Чем провинился false? Имхо, false можно было возвращать, если окно есть, но не закрылось (по каким угодно причинам); true -- окно закрылось; nil -- окно не найдено или ещё какая напасть.
Подводя итог, по факту имеем: 1) часть функций, где не задокументирован формат возвращаемых значений в случае ошибки, но всё-таки возвращающих не-nil (пустые таблицы, строки, ...); 2) часть функций, где формат возвращаемых значений задокументирован ("возвращает nil"), но его трудно отличить от ситуации, когда аргументы семантически верные, но по ним нет данных; 3) остальные функции, где формат возвращаемого значения в случае ошибки задокументирован и не nil (true/false, -1, ...).
Т.е. на лицо некоторая непоследовательность в подходе к возвращаемым значениям-ошибкам. По науке, в Lua есть механизм error() для сигнализирования ошибок, но я осознаю, что могут быть разные причины его не применять. И если уж так, то пихать nil только в случае ошибок -- другие ситуации не должны возвращать nil. Как-то так. Возможно, где-то что-то упустил, т.к. функций много, и не везде я при тестировании делал пометки, но что есть, то написал. Нужно либо эти моменты получше задокументировать, либо переделать "по-феншую" (хотя тут, скорее всего, малой кровью не обойтись, т.к. уже написано немало кода с использованием существущего механизма).
P.S. Функция SearchItems, по моим впечатлениям, страдает ещё от неверной работы фичи "если в коллбэке вернёте nil, то поиск индексов остановится и вернёт все подходящие индексы до этого момента + тот, на котором остановились": у меня почему-то SearchItems упорно возвращал nil, а коллбэк был что-то типа "function(t) if t.sec_code == 'AFKS' then return nil else return false end", при том, что этот же слегка изменённый коллбэк "function(t) if t.sec_code == 'AFKS' then return true else return false end" исправно выдавал массив из трёх элементов. Но этот момент я ещё потестирую отдельно на досуге. Написать всё-таки хотел не об этом, но побудила на написание поста именно она.