sam063rus пишет: я просто пока не могу понять, как скрипт прерывается при приходе очередного колбека (без всяких майнов и прочего). вот и всё. если у вас нет ответа на мой - я постараюсь найти его сам. но это очень прискорбно, что я не могу найти ответа на такой, казалось бы простой вопрос тут.
прервать выполнение кода на луа можно: 1. Повесить хук на отладчик. 2. В определенных ситуация можно сказать yeld / resume 3. Сделать lua_lock/lua_unlock
sam063rus пишет: то есть, вопрос, по сути, можно развернуть так: есть петля в теле скрипта (без майн), есть коллбеки. на время коллбеков петля в скрипте прерывается и идёт обработка коллбека. как?
как у вас происходит/реализовано программно прерывание работы скрипта на время обработки кода из коллбека?
Ответил - никак. Это разные потоки операционной системы. Стеки существуют независимо друг от друга. Но доступ к глобальным данным синхронизован. Это значит что:
Код
x=1
function OnParam()
...
x=2
...
end
function main()
...
x=3
...
end
OnParam и main исполняются в разных потоках OC, но при обращении к x, произойдет блокировка, изменение данных и разблокировка.
sam063rus пишет: Михаил, я уже объяснил вполне доступно: есть стандартный message loop в библиотеке, есть код в коллбеках - и то и то вполне себе параллельно работают. как? напрашивается ответ, что на время прихода коллбеках идёт переключение работы кода на них, а потом возобновление работы кода из message loop библиотеки. и причём, без потоков и корутин.
в qlua.dll создается два отдельных стека Lua - для колбеков и для main(). Обращение к глобальным данным из этих функций синхронизировано средствами Lua.
Николай Камынин пишет: Может объясните, как эмуляцией с использованием OnTransReply можно получить результат транзакции без использования OnTransReply
Николай, фразу
Цитата
Только эмуляцией, с использованием sendTransaction и OnTransReply.
следует понимать так, что получить результат можно только используя эти две функции. Часть ошибок действительно можно получить непосредственно из sendTransaction, но это касается ситуаций когда транзакция еще не отправлена на сервер. То есть те ошибки, которые может диагностировать терминал - некорректная бумага, класс, транзакция и т.п. Все остальное приедет только в OnTransReply. Возможно я недостаточно подробно объяснил свою мысль, но сарказм и риторические вопросы только затягивают обсуждение.
Николай Камынин пишет: Добрый день, Михаил, Хорошо бы увидеть конкретный ответ. А то "эмуляция", хотя и короче двух слов и предлога между ними, но звучит почти также.
Николай Камынин пишет: А что такое "эмуляция"? ---------------------------------------------- ВИки: Эмуля́ция ( англ. emulation ) в вычислительной технике — комплекс программных, аппаратных средств или их сочетание, предназначенное для копирования (или эмулирования ) функций одной вычислительной системы ( гостя ) на другой, отличной от первой, вычислительной системе ( хосте ) таким образом, чтобы эмулированное поведение как можно ближе соответствовало поведению оригинальной системы ( гостя ). ------------------------------------------ Вы это рекомендуете?
Добрый день, Николай. Вопрос риторический или Вам нужен ответ?
Николай Камынин пишет: Если без особых выкрутасов, то можно упростить:
function DateFormat(date, input_fmt, output_fmt) local day = date:sub(input_fmt:find("([d|D]+)" ;) local month = date:sub(input_fmt:find("([m|M]+)" ;) local year = date:sub(input_fmt:find("([Y|y]+)" ;) local outstr = output_fmt:gsub("([d|D]+)", day) local outstr = outstr:gsub("([m|M]+)", month) local outstr = outstr:gsub("([y|Y]+)", year) return outstr end
примерно в 2 раза быстрее.
Добрый день. Только работает не так как в моем примере.
Я просто хочу показать, что сделать ОО интефейс к существующим функциям задача не хитрая. Причем нет разницы где это делать - в скрипте на Lua или в qlua.dll. API для этого используется одно и тоже. Вся проблема в том, что никто внятно не может рассказать какими объектами хочется оперировать, какими свойствами они должны обладать, какие интерфейсы предоставлять, как взаимодействовать друг с другом и т.п.
sam063rus пишет: ну тогда сделайте их доступными из QLUA сами. и сделайте уже нормальный бинд вашего qtable. пример того, как обходятся в CryEngine без метатаблиц Вам уже давали.
А что сейчас не устраивает в функциях работы с таблицами? Сразу повторюсь - завернуть эти функции в "класс" не сложно средствами самого Lua, тем более что пример как это можно сделать у нас есть. Тот пример что Вы прислали - это просто пример реализации наследования от базового класса. Для этого надо сначала определить сам базовый класс, о чем я и просил Вас. Напишите в свободной форме что вы хотите получить.
sam063rus пишет: В связи с тем, что секция экспорта в библиотеке пользовательских контролов имеет открытый интерфейс, могу ли я, сделав к ней QLUA-бинд использовать её в своих программах на qlua?
Если Вы про то, что Вам надо подробную иерархию классов - что ж, я могу её составить. В какой форме желаете? В формате сообщения в посте - тесно, в формате e-mail - тогда другие участники не смогут подключиться к обсуждению и редактированию.
sam063rus пишет: Да. Но стек в LUA - не резиновый, а сборщик мусора - невсегда предсказуемый. К тому же, если объектов - чуть меньше чем (ну Вы сами понимаете... ) то, мы очень сильно теряем в производительности. Насчёт простоты, гибкости и синтаксического "сахара". - Вот, как-раз за "сахар" и официально декларируемый подход к тому, что мол де, хорошие программы не нуждаются в комментариях я бы, как и многие,подвесил Роберто за ..
Давайте оставим в стороне Ваши оценочные суждения о языке, тем более если они не подтверждены фактами. Если у Вас примеры связанные с переполнением стека, сборщиком мусора или потерей производительности, то приведите пример кода и мы попробуем с ним разобраться.
С подобными хуками и эвентами более-менее понятно. По моему мнению, подобные конструкции как раз легче сделать на Lua - реализация получается более гибкой, простой и понятной. Остается вопрос про отдельные потоки для роботов. Вообще, если читать первоисточники по скриптовым языкам, не только Lua, то вопрос многопоточности для них очень не простой. Речь идет именно о "честной", вытесняющей многопоточности, а не о кооперативной. Практически везде рекомендуют использовать встроенный в язык механизм сопрограмм, либо запускать потоки с разными виртуальными машинами и обмен данными между ними через аналоги сообщений и очереди. как пример реализации - Lua lanes. В LuaJIT, насколько я помню, вообще отсутствуют функции lua_lock/lua_unlock, вместо этого пользователю самому предлагается заботится о синхронизации доступа к данным.
sam063rus пишет: Также Вы говорите, что это всё можно реализовать и средствами самого LUA. Чтож, как говорится "You are welcome!". Давайте, покажите нам, наконец на хотя бы на одном примере, как это делается.
Добрый день. "реализация классов" не самая сложная задача. Но, для того чтобы от них была польза, необходимо хотя бы в общих чертах представлять себе алгоритмы обработки данных и уровни абстракции, которые используют Ваши роботы. В начале ветки Вы декларируете желание иметь реализацию функций обратного вызова на все возможные события, в том числе и заданные по условию :
Цитата
К примеру, есть бумага, есть условие по ней, оформленное в виде функции. При срабатывании условия квик вызывает коллбек.
И при этом иметь около 30 роботов, каждый из которых работает в независимом потоке ОС, без очередей данных и сопрограмм. Пока я не очень представляю себе как это все будет выглядеть. Именно поэтому я и прошу хотя бы пример реализации в псевдокоде. Если у Вас нет готового примера, то можете привести ссылку на игровой движок, реализацию которого Вы считаете удачной.
sam063rus пишет: мне нет нужды запускать отдельно в каждом скрипте через меню робота. т.е. я хочу, чтобы, к примеру, нажав в меню - "запустить скрипт" - у меня одновременно начало торговать 30 роботов, не зависимо и на разных интсрументах. В идеале, распараллелено по разным потокам и процессорам (правда за параллелизм по процессорам отвечает уже операционная система)
можете привести пример такого "робота" в псевдокоде? Что бы было понятно о чем идет речь.
Michael Bulychev пишет: Добрый день. по пунктам: 1. К сожалению, этого сделать не получится по многим причинам. 2. Над этим вопросом мы работаем, подобные пожелания у нас уже зарегистрированы. Пункты 3, 5, 6, 7 - в пределах одного скрипта это можно и сейчас реализовать средствами Lua без доработок с нашей стороны. 8 - Профайлер для Lua . Над отладкой с помощью Decoda можно подумать, там тоже все не очень просто. Например, невозможно отлаживать скрипты оставаясь подключенным к серверу. Пункт 4 - поясните подробнее как бы Вы хотели видеть реализацию
1. Хотелось бы конкретики, если можно, по этим причинам. 3.5.6.7. Да, можно, с корутинами и очередями НО! Это будет тот ещё велосипед и пойди разберись потом в листинге. Даже одна метатаблица вызывает шок у неподготовленного скриптера, а что говорить о рядовых трейдеров? Ведь это софт не для программистов, а для трейдеров. 4. Интересует возможность иметь общий кеш памяти или там кеш переменных, чтоб ими обмениваться между двумя скриптами, (т.е. двумя виртуальными машинами со своими lua-state) и стало быть, двумя потоками ОС. тут народ кричит, что надо shared memory. Но мы то знаем, что это тоже не панацея, правда, в 3d-играх, активно используется, например при обращению к кешу ресурсов (скрипты, текстуры, меши, аудио, видео). Есть варианты реализации, направленные на разделение потоков по принципу read/write. Есть универсальные базовые методы: interlockedIncrement/decrement. Но, это всё (пункт 4.) - потребует от Вас создания внутреннего класса менеджера памяти с функциями арбитража потоков - т.к. в LUA это - явно выносить не нужно. есть ещё варианты. это, так сказать, что пришло/вспомнилось на ум.
пункт 1 - предлагаю просто поверить на слово. Дать такое API мы не можем.
Добрый день. по пунктам: 1. К сожалению, этого сделать не получится по многим причинам. 2. Над этим вопросом мы работаем, подобные пожелания у нас уже зарегистрированы. Пункты 3, 5, 6, 7 - в пределах одного скрипта это можно и сейчас реализовать средствами Lua без доработок с нашей стороны. 8 - Профайлер для Lua. Над отладкой с помощью Decoda можно подумать, там тоже все не очень просто. Например, невозможно отлаживать скрипты оставаясь подключенным к серверу. Пункт 4 - поясните подробнее как бы Вы хотели видеть реализацию
Повторюсь еще раз - такая ситуация невозможна без реконнекта терминала к серверу. Если говорить точнее, то без рестарта сервера, что приведет к реконнекту терминала. То есть в любом случае клиент это заметит и после установления связи получит бумагу с новыми параметрами.