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

Увидел, спасибо.

В документации написано, что getItem возвращает таблицу.

Однако, вызов getItem("client_codes", 0) возвращает строку с номером счёта (индекс может быть и ненулевой -- ситуация не меняется). То есть, ошибка либо в документации, либо в реализации функции.

Yerlan, если Вам C++ по плечу, то с Lua не должно возникнуть трудностей. Насчёт оптимизаций (преждевременных и необдуманных) -- забудьте. Сделайте рабочий вариант, пусть и медленный. От него и будете плясать. Если C++ ближе, то делайте на нём -- всё равно в итоге с Lua пересядете рано или поздно на что-то другое. Но, имхо, мотивацией должно служить в первую очередь удобство и скорость разработки, а не мнимое быстродействие. В противном случае, рискуете уехать в дебри и, не увидев осязаемого результата, забросить.

Вторую функцию вызывайте через allwords()() (соответственно, к предыдущему посту: values(t)() -- так можно). Сама функция возвращает функцию-генератор. Функция-генератор -- это такая функция, которая сохраняет некое состояние между её вызовами.


Этот код будет выводить Вам все слова из введённой строки, пока Вы не введёте пустую строку. Если не проверять на ввод пустой строки, то программа сама не завершится, т.к. пустая строка -- это всё ещё строка (т.е. не nil).

Т.е., проще говоря, присваивание iter = values(t) записывает в iter ссылку на функцию-итератор (генератор), и присваивание element = values(t) делает то же самое. А вот уже вызов этой функции даст вам следующий элемент таблицы-массива.

У Вас values(t) возвращает функцию. Соответственно, Вы её и вызываете посредством iter().
Не помню, легален ли такой синтаксис, но попробуйте values(t)().

Функция _Window определена как


Функция Window определена как


Т.е., по сути, Window, в данном случае, -- это обёртка над _Window, предоставляющая более удобный API.

Виктор Столетов, в Lua нет встроенной функции математического округления.

Если по-английски понимаете, то ответ тут: https://stackoverflow.com/questions/18798044/how-to-avoid-popup-a-window-when-use-os-execute-in-lua

Принятый ответ гласит, что никак. Далее в ответах предлагается пара путей обхода: один с использованием WScript.Shell, другой -- с использованием библиотеки-обёртки над вызовом утилиты командной строки.

Спасибо, Михаил. По Вашей наводке наткнулся на обсуждение на stackoverflow: https://stackoverflow.com/a/945935/2031954

О. По ходу, я ошибаюсь. В том же файле есть:
Насчёт 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:

* Но это не точно. Просто здравый смысл    

В 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.

В общем, если не разберётесь с LDIR, то гуглите в сторону "lua package.path".

Добавьте директорию с модулями LuaRocks LDIR Вашего Lua-интерпретатора.
Точно не знаю, но вроде LDIR устанавливается во время компиляции Lua-машины (файл luaconf.h). Если говорить об уже собранном дистрибутиве, то либо нужно сказать LuaRocks, чтобы он хранил свои модули внутри дистрибутива Lua, либо вручную в каждом файле переопределять переменную package.path перед использованием директивы require:

Насчёт точного формата строки пути не уверен, но что-то похожее. Например, для QLua у меня есть следующие строка, и она работает:

Установите Visual Studio С++ (бесплатная версия -- Community Edition). LuaRocks запускайте из под "Developer Command Prompt" (ну, или добавьте cl.exe, поставляемый в Visual Studio C++, в PATH).

Блин, ну Вы бы хоть гуглили для начала...

pcall принимает функцию, значит, нужно передать ему функцию:

А зачем _G передавать первым аргументом?

Кстати, как насчёт обновить движок форума для поддержки редактирования собственных сообщений?

Я думаю, Вам об этом стоит задуматься лишь тогда, когда (если) Вы упрётесь в какой-нибудь боттлнек при реализации своих алгоритмов на Lua в QUIK.
Ну, или если просто владеете другим языком лучше , чем Lua :)

Я, конечно, не знаю, насколько крут LuaJIT, но если крут, то он r из ваш цикла



вычислит на этапе JIT-компиляции, а если ещё круче -- отбросит как dead code.


Но, увы, в QUIK не LuaJIT, так что спекулировать об этом здесь нет смысла.


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

Согласен с автором темы. Был удивлён подобному поведению библиотеки. Такие контр-интуитивные вещи нужно по крайней мере документировать.

А серверный поток, обрабатывающий запрос, где при это находится?

Почитайте на досуге про сборку мусора (garbage collection). В Lua этот механизм используется, как Вы уже смогли заметить.

Вынесите код проверки условия в функцию. Конкретно того, что хотите Вы, в Lua сделать нельзя.

Сначала гуглите, потом задавайте вопрос -- велика вероятность, что ответ уже содержится в Интернете. Например, тут: https://habr.com/company/pvs-studio/blog/227521/


TL;DR: для Ваших экспериментов Вам лучше будет отключить использование предкомпилированных заголовков.

CLion -- платная.

Студия -- де-факто стандарт IDE для разработки на плюсах под винду. Ставьте бесплатную Community Edition -- хватит за глаза.Ну, и Ваш скрин от Code::Blocks позволяет предположить, что собирать в ней можно любым из предложенных инструментов. Теперь разве что осталось посмотреть, как там в принципе настроить доп. директории для компилятора и линкера и всё -- можно собирать без замусоривания стандартной директории библиотечными файлами.

Это патч для LuaJIT (реализация Lua-машины с JIT-компилятором). Вам ничем не поможет, т.к. QUIK использует вшитую Lua 5.1, а не какую-либо внешнюю.

Полагаю, это потому, что в оригинальной библиотеке 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-машины у Вас лежат в .../Lua/5.1/include.

То, что нужно. Спасибо!

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


Например, в версии 7.16 (по сравнению с 7.14) добавили функцию "sysdate" (технически, она там была и до этого, но опустим этот момент) и выделили под неё отдельный пункт. В короткий срок я об этом узнать не могу -- только чтение мануала.

Вы какой-то фигнёй маетесь, честное слово. Сам факт использования QUIK для получения маркет-даты и совершения транзакций перечёркивает весь перфоманс. То, что Вы там свой массивчик обработаете не за 5 мс, а за 1, погоды особо не сделает.
Мой Вам совет -- оставьте мечты о перфомансе до тех пор, пока не напишите работающий неоптимизированный вариант.

В Lua-машине в QUIK, конечно, тесновато, поэтому что-либо сложнее торговли по скользящим средним проще написать в другом окружении. Из простого можете взять QuikSharp и делать обработку данных в шарпе.

А в каком языке программирования 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" исправно выдавал массив из трёх элементов. Но этот момент я ещё потестирую отдельно на досуге. Написать всё-таки хотел не об этом, но побудила на написание поста именно она.