Comments 120
Да, LUA — классная вещь. Когда-то в своём проекте мы использовали собственный небольшой язык. Но когда система комманд разраслась до десятков + добавилась необходимость хорошей математики и работы с внешней файловой системой решили перейти на что-то серьезное. Выбирали между Python и LUA. Выбрали LUA. Стыдно, правда, признаться почему — в комманде было несколько людей, активно игравших в WoW и писавших к нему плагины (как раз на LUA), а вот знатоков питона не было :)
А почему во внимание Angelscript не брали… имхо, гораздо лучше LUA
Не стоит писать Lua большими буквами — это не акроним.
Для пользователей языка программирования D есть интерфейс с более человеческим лицом — LuaD
Вот пример использования:
Запускаем и видим «Hello, Terror!»
Вот пример использования:
import LuaD;
import tango.io.Stdout;
void main(char[][] args) {
auto lua = new LuaState;
lua["greet"] = (string name) {
Stdout.format("Hello, {}!", name);
};
lua.doString(`greet("Terror")`);
}Запускаем и видим «Hello, Terror!»
Я буду краток, но меток.
Автор — не мучай себя и других.
открой для себя luabind
быть может за те 4 года что я уже не работаю с луа придумали что-то иное, но…
… но я бы забил на луа и пересел на питон.
Автор — не мучай себя и других.
открой для себя luabind
быть может за те 4 года что я уже не работаю с луа придумали что-то иное, но…
… но я бы забил на луа и пересел на питон.
кстати — луа может выглядеть и так
а вот и мой опыт работы с луа
а так
void luaE2Console(int SYS,LPCSTR Str)
…
lua::function_def(«Error2Console» ,luaE2Console);
и все, только компилиться долго :)
а вот и мой опыт работы с луа
а так
void luaE2Console(int SYS,LPCSTR Str)
…
lua::function_def(«Error2Console» ,luaE2Console);
и все, только компилиться долго :)
Статья обзорная, ознакомительная. Если будет интерес расскажу и про luabind и другие методы, упрощающие взаимодействие с Lua
Тут на вкус и цвет, конечно, но я использую LuaPlus. На мой неприхотливый взгляд он несколько удобнее по получаемому коду, чем luabind. Да и пришел я к нему после того как собственную обертку написал по всем заветам Саттера и Александреску.
Но, в любом случае, C++ и LUA вместе — это здорово!
Но, в любом случае, C++ и LUA вместе — это здорово!
Luabind, ИМХО, зло.
Если пишешь биндинги под себя, используй стандартный Lua C API. Если им проникнуться, лучшего средства нет.
Если нужны биндинги для какой-нибудь монструозной сторонней библиотеки, используй генератор биндингов (например tolua).
Если пишешь биндинги под себя, используй стандартный Lua C API. Если им проникнуться, лучшего средства нет.
Если нужны биндинги для какой-нибудь монструозной сторонней библиотеки, используй генератор биндингов (например tolua).
UFO just landed and posted this here
Прям до стека дошли?
Почему не понравилось?
Почему не понравилось?
UFO just landed and posted this here
Зато какой шустрый :)
1/13 от скорости сишника для JIT варианта lua.
Это я просто цифры привел. Это впечатляет.
Кстати питон + psyco дал 1/14. Вплотную приблизился.
Это я просто цифры привел. Это впечатляет.
Кстати питон + psyco дал 1/14. Вплотную приблизился.
на достижения трассирующего Lua JIT 2 смотрели? там местами ноздря в ноздрю идут =)
shootout.alioth.debian.org/u32/benchmark.php?test=all&lang=luajit&lang2=gpp&box=1
Mike Pall даёт стране угля, компиляторный-идол просто
shootout.alioth.debian.org/u32/benchmark.php?test=all&lang=luajit&lang2=gpp&box=1
Mike Pall даёт стране угля, компиляторный-идол просто
А примеры поглядеть можно?
Это Ваше личное мнение. Такое ощущение, что речь всё ещё про Луа 4.х. :-)
Моё личное мнение — более изящного, «некорявого», а, главное, сбалансированного языка чем Луа 5.1 я не встречал.
Ошибки скриптинга отлавливаются шикарно. Нужно просто уметь их ловить. Могу ответить на конкретные вопросы.
Бридж к ObjectiveC к Луа как к языку не имеет никакого отношения вообще. Чистый Луа предоставляет механизм для биндинга в plain C (и, на правах бедного родственника, в C++).
Всё, что сверх этого — надстройки, которые часто пишутся обычно для удовлетворения частных нужд разработчика.
Да, есть приличные бриджи (либо альтернативные реализации VM) в .Net, в Java, в Perl. Кое-какой бридж в Active script.
Если бридж ObjectiveC тёк, это — проблема бриджа а не языка. Можно написать свой.
Моё личное мнение — более изящного, «некорявого», а, главное, сбалансированного языка чем Луа 5.1 я не встречал.
Ошибки скриптинга отлавливаются шикарно. Нужно просто уметь их ловить. Могу ответить на конкретные вопросы.
Бридж к ObjectiveC к Луа как к языку не имеет никакого отношения вообще. Чистый Луа предоставляет механизм для биндинга в plain C (и, на правах бедного родственника, в C++).
Всё, что сверх этого — надстройки, которые часто пишутся обычно для удовлетворения частных нужд разработчика.
Да, есть приличные бриджи (либо альтернативные реализации VM) в .Net, в Java, в Perl. Кое-какой бридж в Active script.
Если бридж ObjectiveC тёк, это — проблема бриджа а не языка. Можно написать свой.
с какими такими счетчиками ссылок?
UFO just landed and posted this here
а… весьма ожидаемый результат…
UFO just landed and posted this here
а что так?
UFO just landed and posted this here
мутная = отсутствующая?
можно о мелочах?
начало с единички?
можно о мелочах?
начало с единички?
UFO just landed and posted this here
Пункты 1 и 2 — вкусовщина ИМХО. У меня лично никогда серьёзных проблем ни с тем ни с другим не было, всё шикарно обходится.
Пункт 3 — неправда. Луашные таблицы и есть массивы (и, одновременно, хеш-таблицы). Даже на низком уровне — то есть без пенальти по скорости. Наличие выделенного типа «массив» никаких бенефитов не даёт.
Пункт 3 — неправда. Луашные таблицы и есть массивы (и, одновременно, хеш-таблицы). Даже на низком уровне — то есть без пенальти по скорости. Наличие выделенного типа «массив» никаких бенефитов не даёт.
UFO just landed and posted this here
1 — В своей практике серьёзных проблем не встречал. Вопрос в том, чтобы писать на Луа как на Луа, а не пытаться привнести собственные идиомы.
2 — Определение «левости» синтаксиса в студию. Либо конкретные примеры.
3 — Мы всё ещё про 5.x говорим? Если да, идём учить матчасть (в данном случае раздел 4).
2 — Определение «левости» синтаксиса в студию. Либо конкретные примеры.
3 — Мы всё ещё про 5.x говорим? Если да, идём учить матчасть (в данном случае раздел 4).
Чувствую, что нужно уточнить про 1 и 2.
1. Современный Луа очень гибкий и поддерживает кучу разных подходов к написанию программ. В том числе и честный ООП. Если очень хочется его получить, welcome. Но, как с любым другим языком, на Луа лучше всего писать программы в его собственной, «луашной» стилистике.
В моей практике мне не хватало честного наследования всего пару раз. Утиная типизация вместе с метатаблицами решают.
2. Если смотреть с точки зрения mainstream-языков, таких как C++, C#, Java… в синтаксисе Луа действительно есть свои «странности». Нужно просто помнить, что Луа — другой язык, и всего лишь к ним привыкнуть.
Большинству «странностей» имеется серьёзное объяснение почему сделано именно так а не иначе. Объяснение с позиций сбалансированности всех аспектов языка, включая удобство пользователя, однозначность синтаксиса и максимальную простоту и скорость работы его реализации.
Много чего по теме можно почерпнуть из http://www.lua.org/doc/hopl.pdf и The implementation of Lua 5.0.
1. Современный Луа очень гибкий и поддерживает кучу разных подходов к написанию программ. В том числе и честный ООП. Если очень хочется его получить, welcome. Но, как с любым другим языком, на Луа лучше всего писать программы в его собственной, «луашной» стилистике.
В моей практике мне не хватало честного наследования всего пару раз. Утиная типизация вместе с метатаблицами решают.
2. Если смотреть с точки зрения mainstream-языков, таких как C++, C#, Java… в синтаксисе Луа действительно есть свои «странности». Нужно просто помнить, что Луа — другой язык, и всего лишь к ним привыкнуть.
Большинству «странностей» имеется серьёзное объяснение почему сделано именно так а не иначе. Объяснение с позиций сбалансированности всех аспектов языка, включая удобство пользователя, однозначность синтаксиса и максимальную простоту и скорость работы его реализации.
Много чего по теме можно почерпнуть из http://www.lua.org/doc/hopl.pdf и The implementation of Lua 5.0.
И ещё добавлю. Если не нравится синтаксис, его всегда можно исправить при помощи Metalua. ;-)
UFO just landed and posted this here
1. Ну, может быть 100 KLOC C++ и 160 KLOC Луа и недостаточно сложно. Бывают программы намного больше и сложнее, согласен.
2. Читал, но конструктивной критики не увидел. Слово «дурацкий» в конструктив записать не могу, увы.
3. :-) Может быть Вы просто не умеете их готовить?
2. Читал, но конструктивной критики не увидел. Слово «дурацкий» в конструктив записать не могу, увы.
3. :-) Может быть Вы просто не умеете их готовить?
UFO just landed and posted this here
Открывал. Вполне допускаю, что и пропустил в них что-то. О чём _конкретно_ речь?
UFO just landed and posted this here
у вас не совсем правильные представления о реализации массивов в Lua.
та часть массива, которая не слишком разрежена[1], будет хранится именно как массив, а не как хэштаблица (т.е. чтение-запись будет бытрое)
конечно, при наличии дырок оператор # начнёт вести себя маразматически, но се ля ви.
справедливости ради стоит заметить: что можно было легко подкрутить в сорцах и добиться ровно того поведения, какое нужно было вам.
[1] www.google.com/codesearch/p?hl=en&sa=N&cd=1&ct=rc#zXQJ5rQZsRM/lua-5.1.2/src/ltable.c&q=luaH_set&exact_package=ftp://ftp.sunfreeware.com/pub/freeware/SOURCES/lua-5.1.2.tar.gz&l=189
та часть массива, которая не слишком разрежена[1], будет хранится именно как массив, а не как хэштаблица (т.е. чтение-запись будет бытрое)
конечно, при наличии дырок оператор # начнёт вести себя маразматически, но се ля ви.
справедливости ради стоит заметить: что можно было легко подкрутить в сорцах и добиться ровно того поведения, какое нужно было вам.
[1] www.google.com/codesearch/p?hl=en&sa=N&cd=1&ct=rc#zXQJ5rQZsRM/lua-5.1.2/src/ltable.c&q=luaH_set&exact_package=ftp://ftp.sunfreeware.com/pub/freeware/SOURCES/lua-5.1.2.tar.gz&l=189
Утверждение некорректно как с точки зрения Луа как языка, так и с точки зрения конкретной реализации.
Если говорить о Луа как о языке, в Луа нет ни массивов ни хеш-таблиц. Есть один, универсальный тип данных — table (таблица). Его можно использовать как array, dictionary, set, list, queue, record и т.п. (прошу прощения, неуверен в русскоязычной терминологии). Table может быть как чем-то одним из этого списка, так и несколькими вещами сразу (например, в моём коде достаточно часто встречается комбинация array и record). Луашные таблицы — мощнейшее выразительное средство, один из краеугольных камней всего языка.
Если же говорить о конкретной реализации, то каждая луашная таблица одновременно содержит в себе как хеш-таблицу, так и массив. Виртуальная машина прозрачно и по достаточно чётко описанным правилам выбирает, куда класть данные. Если лень копаться в коде, всё написано доступным языком в двух абзацах четвёртого раздела The implementation of Lua 5.0, на который я уже давал ссылку.
Да, индексация с единицы и неоднозначность размера у массивов с дырками действительно по началу сбивают с толку.
Но оно того стоит, и с этим можно жить, и жить счастливо.
Смертельных проблем с JSON-ом я не вижу. Главное не пытаться использовать ipairs/table.concat/unpack/# и т.п. там, где этого не стоит делать. Если есть какой-то конкретный вопрос, готов помочь.
А, вообще, мне попадалось достаточно много готовых луашных библиотек для работы с JSON-ом. Вот, например: http://github.com/harningt/luajson
Если говорить о Луа как о языке, в Луа нет ни массивов ни хеш-таблиц. Есть один, универсальный тип данных — table (таблица). Его можно использовать как array, dictionary, set, list, queue, record и т.п. (прошу прощения, неуверен в русскоязычной терминологии). Table может быть как чем-то одним из этого списка, так и несколькими вещами сразу (например, в моём коде достаточно часто встречается комбинация array и record). Луашные таблицы — мощнейшее выразительное средство, один из краеугольных камней всего языка.
Если же говорить о конкретной реализации, то каждая луашная таблица одновременно содержит в себе как хеш-таблицу, так и массив. Виртуальная машина прозрачно и по достаточно чётко описанным правилам выбирает, куда класть данные. Если лень копаться в коде, всё написано доступным языком в двух абзацах четвёртого раздела The implementation of Lua 5.0, на который я уже давал ссылку.
Да, индексация с единицы и неоднозначность размера у массивов с дырками действительно по началу сбивают с толку.
Но оно того стоит, и с этим можно жить, и жить счастливо.
Смертельных проблем с JSON-ом я не вижу. Главное не пытаться использовать ipairs/table.concat/unpack/# и т.п. там, где этого не стоит делать. Если есть какой-то конкретный вопрос, готов помочь.
А, вообще, мне попадалось достаточно много готовых луашных библиотек для работы с JSON-ом. Вот, например: http://github.com/harningt/luajson
UFO just landed and posted this here
1. Это зависит не от наличия или отсутствия ООП, а от программистов.
Копи-пейст (раз уж мы говорим об объёмах кода), например, у нас присутствовал в проекте в обычных (небольших) масштабах. И не из-за особенностей Луа, а из-за обычной программистской лени (либо авральности выполнения конкретной задачи). На плюсах или Яве было бы то же самое.
Другое дело, что, если бы, например, в Луа был ООП, но не было бы, скажем, замыканий и функций — значения первого класса, то было бы не 160 KLOC, а все 500.
Копи-пейст (раз уж мы говорим об объёмах кода), например, у нас присутствовал в проекте в обычных (небольших) масштабах. И не из-за особенностей Луа, а из-за обычной программистской лени (либо авральности выполнения конкретной задачи). На плюсах или Яве было бы то же самое.
Другое дело, что, если бы, например, в Луа был ООП, но не было бы, скажем, замыканий и функций — значения первого класса, то было бы не 160 KLOC, а все 500.
2. Это индивидуально.
Во-первых, кривая обучения языку и простота работы с ним, всё-таки, разные вещи. И синтаксис здесь далеко не первый вопрос.
Например, вне зависимости от синтаксиса, первые программы опытного PHP-шника на Луа не будут эффективными (обратное тоже верно) — языки слишком по-разному работают со строками.
У любого языка есть свои особенности. Пока человек не изучил их в достаточной степени, нельзя говорить, что он эффективно использует этот язык.
Во-вторых, мне, лично, разница в синтаксисе серьёзно помогает.
Когда я пишу одновременно на плюсах и на Луа, я регулярно пытаюсь написать в Луа фигурную скобку (или пропустить двоеточие) а в плюсах написать then. Я натыкаюсь на эту ошибку (часто даже до компиляции), и у меня сразу в голове происходит переключение на нужный контекст (которое почему-то не произошло раньше).
Можно попробовать писать в одном стиле, например, на плюсах и на Яве и не думать про переключение между языками. Только вот результат будет весьма посредственным.
Если уж так часто лезут эти ошибки — соответствующий статический валидатор кода на Металуа пишется достаточно тривиально.
Можно обойтись и рантайм-валидацией (я так делаю) — просто всегда проверять ассертом что self — это таблица. 80% опечаток это вылавливает.
Вот мой велосипед:
Во-первых, кривая обучения языку и простота работы с ним, всё-таки, разные вещи. И синтаксис здесь далеко не первый вопрос.
Например, вне зависимости от синтаксиса, первые программы опытного PHP-шника на Луа не будут эффективными (обратное тоже верно) — языки слишком по-разному работают со строками.
У любого языка есть свои особенности. Пока человек не изучил их в достаточной степени, нельзя говорить, что он эффективно использует этот язык.
Во-вторых, мне, лично, разница в синтаксисе серьёзно помогает.
Когда я пишу одновременно на плюсах и на Луа, я регулярно пытаюсь написать в Луа фигурную скобку (или пропустить двоеточие) а в плюсах написать then. Я натыкаюсь на эту ошибку (часто даже до компиляции), и у меня сразу в голове происходит переключение на нужный контекст (которое почему-то не произошло раньше).
Можно попробовать писать в одном стиле, например, на плюсах и на Яве и не думать про переключение между языками. Только вот результат будет весьма посредственным.
Если уж так часто лезут эти ошибки — соответствующий статический валидатор кода на Металуа пишется достаточно тривиально.
Можно обойтись и рантайм-валидацией (я так делаю) — просто всегда проверять ассертом что self — это таблица. 80% опечаток это вылавливает.
Вот мой велосипед:
function foo:method(bar)
method_arguments(
self,
"number", bar
)
end
1 — я могу назвать (гипотетическую) проблему: в теории отсутствие единого ООП должно рано или позно привести к трудностя со стыковкой библиотек использующих разные способы эмуляции ООП.
но на деле библиотеки чаще всего никакого явного ООП не используют (биндинги вообще пишутся в стиле «вот вам userdata с методами — делайте с ней, что хотите»), поэтому трудностей не возникает.
но на деле библиотеки чаще всего никакого явного ООП не используют (биндинги вообще пишутся в стиле «вот вам userdata с методами — делайте с ней, что хотите»), поэтому трудностей не возникает.
UFO just landed and posted this here
насколько я слышал (сам не пользовался) существующий brige между objective-c и lua является куском гудрона. ну что ж поделать, просто его так написали… язык Lua тут не виноват.
UFO just landed and posted this here
если честно, то я несовсем понимаю что значит «доверить». Lua ничего не знает и не может знать о ваших объектах, только вы знаете как и в каком порядке можно что-то удалять (или уменьшать счетчик ссылок) — надо строить очень аккуратную прослойку писать с учетом всех тонкостей семантики.
Никто и не обещал, что будет легко. Проблема скрещивания двух разных GC вообще вещь нетривиальная (хотя вот, например, нам, вроде бы, удалось скрестить луашку с AS3 без особых проблем).
В любом случае это не значит, что Луа вообще нельзя пользоваться :-)
Вот, кстати, недавно появился новый биндинг Lua-ObjectiveC (правда для айфона): Wax. Может быть там найдёте что-то полезное.
В любом случае это не значит, что Луа вообще нельзя пользоваться :-)
Вот, кстати, недавно появился новый биндинг Lua-ObjectiveC (правда для айфона): Wax. Может быть там найдёте что-то полезное.
UFO just landed and posted this here
Три причины:
1. (Главная и прагматическая) Реюз имеющегося специализированного луашного кода во флеше, чтобы не решать дважды одни и те же проблемы на клиенте (Флеш) и на сервере (Луа). (Довольно медленно, но для этих задач скорость не настолько важна.)
2. Некоторые флешеры (в частности, мой коллега по проекту) считают, что для части задач Actionscript слишком статичен. Луа — более динамический язык, на нём проще писать. Я — не флешер и люблю Луа, так что мне тяжело быть объективным в этом вопросе.
3. Пользовательский скриптинг (конструкторы игр; скриптуемые приложения на Air, в природе уже есть несколько на нашей технологии). Весь мой опыт говорит о том, что Луа более доступен неопытному пользователю чем язык типа Actionscript.
1. (Главная и прагматическая) Реюз имеющегося специализированного луашного кода во флеше, чтобы не решать дважды одни и те же проблемы на клиенте (Флеш) и на сервере (Луа). (Довольно медленно, но для этих задач скорость не настолько важна.)
2. Некоторые флешеры (в частности, мой коллега по проекту) считают, что для части задач Actionscript слишком статичен. Луа — более динамический язык, на нём проще писать. Я — не флешер и люблю Луа, так что мне тяжело быть объективным в этом вопросе.
3. Пользовательский скриптинг (конструкторы игр; скриптуемые приложения на Air, в природе уже есть несколько на нашей технологии). Весь мой опыт говорит о том, что Луа более доступен неопытному пользователю чем язык типа Actionscript.
(Хочу заметить в скобках, что, ИМХО, всё-таки не эмуляции ООП, а его реализации.)
Если уж вдруг во внешнем интерфейсе луашного модуля так сильно нужен ООП… (Для чего? Высунуть «класс», чтобы можно было от него наследоваться? Зачем?)… И стоит задача сделать это максимально «стандартно» — пожалуйста, есть LOOP — «полуофициальная» реализация объектной модели на Луа.
Если уж вдруг во внешнем интерфейсе луашного модуля так сильно нужен ООП… (Для чего? Высунуть «класс», чтобы можно было от него наследоваться? Зачем?)… И стоит задача сделать это максимально «стандартно» — пожалуйста, есть LOOP — «полуофициальная» реализация объектной модели на Луа.
я всё-таки склонен называть это эмуляцией… реализация с моей точки зрения должна быть встроена в язык, навязываться и её детали должны быть отгорожены «заслонкой» от внешнего мира… это исключительно моя точка зрения.
да я думал именно про интерфейсы, но как правило вместо интерфейсов используются обычные callback'и и потому всё хорошо.
спасибо, конечно, за предложение, но к тому времени когда LOOP появился, я уже к своей библиотечке привык, не переписывать же =)
да я думал именно про интерфейсы, но как правило вместо интерфейсов используются обычные callback'и и потому всё хорошо.
спасибо, конечно, за предложение, но к тому времени когда LOOP появился, я уже к своей библиотечке привык, не переписывать же =)
Я вот не уверен, что интерфейсы в Луа имеют много смысла. Интересно обсудить юз-кейсы.
Всё-таки, мне кажется, утиная типизация должна снимать вопрос с интерфейсами.
Всё-таки, мне кажется, утиная типизация должна снимать вопрос с интерфейсами.
интерфейсы исключительно имеют смысл как средство проверки «контракта» на месте создания объекта, а не в месте его использования… но я что-то затрудняюсь вообразить себе библиотеку, в которой я сам бы стал навязывать такую проверку…
Вот именно, это не библиотека получится, а фреймворк. А со фреймворками как раз обычно так и получается — нельзя использовать одновременно две штуки. :-)
Проверка контракта — да, полезно. Только в нашем случае к ООП не имеет особого отношения. Проверка должна быть не «наследуется от интерфейса», а «реализует указанный протокол».
Проверка контракта — да, полезно. Только в нашем случае к ООП не имеет особого отношения. Проверка должна быть не «наследуется от интерфейса», а «реализует указанный протокол».
UFO just landed and posted this here
Зато средств для их реализации достаточно.
Луа предоставляет не решения, но механизмы для их реализации.
Если нужно иметь всё из коробки — что ж, возможно Луа не для Вас. ;-)
Луа предоставляет не решения, но механизмы для их реализации.
Если нужно иметь всё из коробки — что ж, возможно Луа не для Вас. ;-)
UFO just landed and posted this here
Каждому своё.
Я с Луа уже лет пять, написал приличное количество сложного кода — и мне вполне достаточно тех механизмов, что она мне даёт.
Да, кое-что (не так уж много, на самом деле) приходится писать самому, но механизмы для этого в большинстве случаев весьма удобны, и позволяют достаточно быстро получить нужную функциональность в таком виде, как это нужно мне для решения данной конкретной задачи.
Опять же, нет желания писать самому — возьми у коллег. Для Луа сейчас доступно огромное количество открытого кода.
Для некоторых этот подход неприемлем, хочется прийти и сразу заниматься постройкой бизнес-логики под задачу, а не наворачивать фреймворк — ну что ж, это зависит от задачи и от подхода к работе.
Я вполне признаю валидность такого подхода и, действительно, тогда уж лучше взять, например, Питон или Руби или, скажем, Яву и Шарп.
Но для себя, на данный момент, я вижу именно в Луа наилучшее сочетание качества (фичей) и цены (скорости написания кода и скорости работы этого кода) для написания бизнес-логики.
Я с Луа уже лет пять, написал приличное количество сложного кода — и мне вполне достаточно тех механизмов, что она мне даёт.
Да, кое-что (не так уж много, на самом деле) приходится писать самому, но механизмы для этого в большинстве случаев весьма удобны, и позволяют достаточно быстро получить нужную функциональность в таком виде, как это нужно мне для решения данной конкретной задачи.
Опять же, нет желания писать самому — возьми у коллег. Для Луа сейчас доступно огромное количество открытого кода.
Для некоторых этот подход неприемлем, хочется прийти и сразу заниматься постройкой бизнес-логики под задачу, а не наворачивать фреймворк — ну что ж, это зависит от задачи и от подхода к работе.
Я вполне признаю валидность такого подхода и, действительно, тогда уж лучше взять, например, Питон или Руби или, скажем, Яву и Шарп.
Но для себя, на данный момент, я вижу именно в Луа наилучшее сочетание качества (фичей) и цены (скорости написания кода и скорости работы этого кода) для написания бизнес-логики.
UFO just landed and posted this here
Открытый код вообще не часто радует.
Мне кажется, что обычно, в режиме когда нет времени на изучение новой технологии, лучше эту технологию отложить на потом, и пользоваться «дедовскими методами». Потом обычно меньше негативных эмоций остаётся. ;-)
Мне кажется, что обычно, в режиме когда нет времени на изучение новой технологии, лучше эту технологию отложить на потом, и пользоваться «дедовскими методами». Потом обычно меньше негативных эмоций остаётся. ;-)
UFO just landed and posted this here
Согласен по обоим пунктам.
Но Руби слишком медленный для моих задач, а для эрланга слишком тяжело найти программистов. Спасает то, что Луа — где-то между ними. :-)
Но Руби слишком медленный для моих задач, а для эрланга слишком тяжело найти программистов. Спасает то, что Луа — где-то между ними. :-)
UFO just landed and posted this here
По поводу Erlang vs. Lua вот интересная статейка.
Конечно, всё очень и очень сыро, но работы ведутся. :)
Конечно, всё очень и очень сыро, но работы ведутся. :)
удобство? вот уж действительно на вкус и цвет товарищей нет…
UFO just landed and posted this here
А что там с многопоточностью? Нет такой ахинеи с global interpreter lock как питоне?
С многопоточностью проблем не встречал. Пару лет назад, ради эксперемента, писал IVR приложение, где логика работы была вынесена в Lua. Среднее количество одновременных звонков было порядка 25, проблем не наблюдалось.
Если создать несколько luaVM и запустить исполнение в разных нитях — точно никаких проблем не будет.
Подход TCL.
Также см. http://lua-users.org/wiki/MultiTasking
И, наоборот, несколько нитей, использующий один lua_State * — плохая идея.
BOOL, TRUE, FALSE
Вы по MSDN учились программировать?)
Вы по MSDN учились программировать?)
Это вызвано тем, что соглашения о вызовах в C отличаются от соглашений в C++.
Если быть точным: это вызвано разными соглашениями о манглировании имён, calling convention не отличается.
Если быть ещё чуточку более точным, это вызвано тем, что в C++ есть манглирование имён, в отличие от C.
это не совсем точно, например на виндах:
en.wikipedia.org/wiki/Name_mangling#C_name_decoration_in_Microsoft_Windows
en.wikipedia.org/wiki/Name_mangling#C_name_decoration_in_Microsoft_Windows
Я вот все думаю написать про добавление к виндовым приложениям скриптинга на Javascript (ну и VBscript до кучи). Если кому-то это интересно будет, отпишитесь )
интересно будет
Сказано — сделано )
burivuh.habrahabr.ru/blog/74548/
burivuh.habrahabr.ru/blog/74548/
кстати lua отлично можно использовать и как standalone язык, а не только как скриптовый язык для встраивания. я сам большой фанат =)
А можете подсказать, какой-нибудь материал, как Python в проект добавить? Ссылочку на материал там, ну или что-нибудь в этом роде, пожалуйста :)
Если в C++, то берите boost::python и не мучайтесь.
Ну вообще то в родной документации есть раздел Extending and Embedding the Python Interpreter
Как раз хотел изучать эту тему а тут и пост подоспел. Огромное спасибо.
Никто не замечал такую тенденцию: думаешь над какой-нибудь задачей, а тут раз и на следующий день топик или статья в журнале с примером реализации?
Никто не замечал такую тенденцию: думаешь над какой-нибудь задачей, а тут раз и на следующий день топик или статья в журнале с примером реализации?
А я использую для скриптинга C# — в .Net есть вся необходимая инфраструктура, ничего самому писать не нужно. Пользователь может писать скрипты на C#, при этом его код выполняется прямо в среде классов моей системы. Если кому-нибудь интересно, могу написать статью об этом.
А как с кроссплатформенностью в этом случае?
Было бы интересно почитать.
Кто является пользователем в данном случае?
В моей практике писать скрипты на языке со статической типизацией можно заставить только достаточно ограниченный круг лиц. (Если пользователи — программисты на C#, тогда да, конечно, решение идеальное.)
В моей практике писать скрипты на языке со статической типизацией можно заставить только достаточно ограниченный круг лиц. (Если пользователи — программисты на C#, тогда да, конечно, решение идеальное.)
В моём случае обычные пользователи (даже не программисты) легко могут скорректировать имеющийся скрипт — там часто нужно просто немного подправить.
Если что-нибудь более серьёзное — конечно, нужно немного знать программирование, и желательно чуть-чуть знать C#. Мои сотрудники из отдела поддержки прекрасно с этим справляются.
А так согласен — конечно, идеальных решений не бывает. Но это и хорошо — всегда есть куда совершенствоваться.
Если что-нибудь более серьёзное — конечно, нужно немного знать программирование, и желательно чуть-чуть знать C#. Мои сотрудники из отдела поддержки прекрасно с этим справляются.
А так согласен — конечно, идеальных решений не бывает. Но это и хорошо — всегда есть куда совершенствоваться.
Для более удобной интеграции Lua в С++ программу, советую попользоваться luawrapper.
Это часть проекта Lua Server Pages.
Вот простейший пример применения:
Это часть проекта Lua Server Pages.
Вот простейший пример применения:
#include "luawrapper.h"
#include <stdio.h>
int sum(lua_State* L)
{
lua::stack st(L);
double a=0,b=0;
st.at(1,a); // begin from 1
st.at(2,b);
st.push(a+b);
return 1; // number of return values (st.push)
}
int main(void)
{
try
{
lua::vm vm;
// initialize
vm.initialize();
// register CFunction
vm.reg("sum",sum);
// register package 'lib'
static const luaL_Reg lib[]=
{
{"sum",sum},
{0,0}
};
vm.reg("lib",lib);
// execute Lua statements
vm.eval("print(\"5+6=\"..sum(5,6))");
vm.eval("print(\"3+4=\"..lib.sum(3,4))");
}
catch(const std::exception& e)
{
fprintf(stderr,"%s\n",e.what());
}
catch(...)
{
fprintf(stderr,"exception\n");
}
return 0;
}
Sign up to leave a comment.
Добавление скриптинга в программу с помощью Lua