“Lua is a powerful, light-weight programming language designed for extending applications. Coupled with it being relatively fast and having a very lenient license, it has gained a following among game developers for providing a viable scripting interface. It has been used in games such as World of Warcraft and Far Cry, and in applications such as Adobe Photoshop Lightroom and Snort.”
There’s a project built on Lua called Electro that adds physics handling and some other nice features to Lua. It’s open source and runs on Linux/Mac/Windows.
It’s largely used at my school UIC and I’m using it for a VR class with stereoscopic polarized glasses, 3D head or other trackers and input devices, but can be used on a regular desktop as well. It might be worth checking out.
http://www.evl.uic.edu/rlk/electro/
Amazing. Is there a limited number of screens?
I’m curious to know what OS is running behind the NEC screen.
I’m fairly sure all the examples are running on Linux. UIC has a distributed rendering framework being used with Electro to run it across multiple screens (and also across computers running those screens). I think it’s even setup so that the rendering can take place at another location, even across continents. That part is separate from Electro.
The first public beta of LuaTeX has been released…
TeX was already very powerful but this integration with Lua brings a whole new world of possibilities…
I can’t wait for the Pgf/Tikz guys to implement their mathematical engine in Lua and to code 3D libraries…
Eventually, I’ll port my xml parser and my japanese library from TeX to Lua…to speed things up a bit…
This language appears to be much like Euphoria, except Euphoria is far more performance oriented.
Euphoria is FOSS under a public domain license.
performance oriented in what way compared to lua?
euphoria has two core data types, numbers + vectors, and vectors pale in comparision to luas tables. lua has functions as first class citizens with the full lambda calculus. euphoria is not functional at all.
euphoria is faster but the speed difference is minimal.
What I meant is that the syntax share a lot in common.
Euphoria is a general purpose language whereas Lua is designed to supplement flexible applications with scripting capabilities–like in-game scripting.
As for performance… the speed different is huge in some cases. For example an old version of interpreted Euphoria performed a sieve benchmark ~18.5 times faster than Lua. Todays Euphoria has even faster execution speed than before, plus execution speed can be further enhanced up to 5x simply by using the automatic Euphoria to C translator–now also FOSS.
“Euphoria is a general purpose language whereas Lua is designed to supplement flexible applications with scripting capabilities–like in-game scripting.”
This is a marketing difference, not a technical one. You can perfectly use lua as a general purpose language, but the fact that it’s also well suited for inclusion into other applications is a significant advantage.
Anyway, lack of associative containers in a language meant for high level programming = FAIL (not to mention the lack of functional programming which is also a tremendously useful tool to write concise and nice code, especially for GUIs)
If you want speed, use a compiled language, or a jitted one if you want some compromise between language flexibility and speed (incidentally, there is a lua JIT interpreter)
Or a mix between a compiled language and an interpeted one – which is something at which lua is very good.
Your comments about speed are anecdotic at best.
Ps. If the euphoria guys read that, please, pretty please: make a monochrom version of your site. I think I burnt half of my retinal cones while browsing it.
gui toolkits make it even more interesting.
Don’t forget, that there is this miracle tool for C++ programmers called tolua++ :
http://www.codenix.com/~tolua/
It parses your C++ headers and generates automatic bindings to lua, so basically you can use your C++ classes directly from lua, and effortlessly optimize application development times, as well as unit testing. Supports templates, namespaces, enums, unions, stl templates, std::string, operator overloading and is easily extensible to recognize special datatypes which must be treated specially. (like refptrs, etc).
Best of all, you can use it at compile time in your makefiles and simply add your headers as a dependence to tolua++, and the bindings get regenerated when you change them.
For any Lua users out there: I’m very interested in using Lua for configuration and small services on headless servers. I would love it if anyone could point me to their favorite implementations of the following:
1. Httpd server – some sort of small stateful httpd server, in the mode of Ruby’s Webrick or Mongrel, or Python’s TwistedWeb. The point is not for high-traffic web serving but for complex web-based config apps serving one person at a time. Thus, I am looking for something that allows me to keep state across HTTP requests, but for the most part let me craft my own MVC system (NOT looking for a complete Ruby-on-Rails style framework).
2. IPC framework – again something small and simple that allows me to send messages back and forth over TCP/IP, handling one-to-one, one-to-many, and many-to-many relationships.
3. Fast XML/HTML processing – Is there anything similar to Python’s ElementTree, or PHP’s DOM library? Specifically, I’m looking for something that will let me import ‘dirty’ documents such as HTML, manipulate and fix them (PHP includes an option to import badly-formed HTML into DOM, not sure about ElementTree).
-tia
well for servers there’s http://www.keplerproject.org/xavante/
not sure if it meets you’re needs
as for the other stuff the kepler project might have that stuff too, not sure.
I wrote this socket extension a while back, and using it could create a simple HTTP server:
http://www.steve.org.uk/Software/lua-httpd/
As for the other extensions I’m not sure, but if you’ve the patience it’s mostly trivial to bind C + lua together. I wrote this small introduction to the subject here:
http://www.debian-administration.org/articles/264
Thanks!
I find small implementations like this very helpful in grokking a language.
Isn’t squareroot supposed to be the opposite of this?
That’s why it’s called mySqrt:-P
Perfect retort
“””
That’s why it’s called mySqrt:-P
“””
What color is the sky in your universe? 😉
In last decade there is a rising interest in scripting languages like python, ruby, php or pearl. Basically these four languages are prominent because they successfully solve some real problems and have software stack to support them (apis, frameworks, tools, documentation, etc.)
So why LUA? What makes is more appealing than python for example (which seems similar enough)?
well 2 reasons
1. despite the fact that no one mentions it Lua is used everywhere. Lua also solves real problems and has the software stack to support it.
2. python, ruby, php, pearl are all big, really big, which makes them less than ideal for embedded scripting.
there aren’t a whole lot of apps built on lua sure, but theres a whole lot of apps (big important apps as well as small apps) that use it for various scripting an AI purposes
http://www.lua.org/uses.html for an extremely abbreviated list
Lua is designed for embedding and has a much cleaner C API than those other languages. Lua is also orders of magnitude smaller and faster. The core language is very powerful and easy to extend. For example, http://luajit.org/coco.html provides C-based coroutines and a Just In Time compiler.
lua isnt designed to compete with python + ruby. Yes lua can be stand alone but its really designed to be embedded into other apps.
it doesnt have the libraries that python and ruby have, because your app is supposed to provide the bridge from some other 3rd party api (like sqlite) into lua.
Perl
> So why LUA?
That’s a very good question. Picture this: you write a fairly large program in C. You like C. Compiled C code is *very* fast. Some friends advised you not to use C. They told you to just use Perl/Python/Ruby/Lisp/whatever. You said no. Now you find that it would actually be quite helpful if you could script your app…
So, you’ve got your pick of scripting languages you can embed. Really, you only have the most basic of needs. Nothing fancy.
Now, do you go with a tiny and simple scripting language, one that you can pick up quickly (and that you’re hoping your users can pick up quickly)? Or do you jam a full-blown general programming language, standard library and all, into your app? If you were a Perler/Pythoneer/Rubyist/Smug-Lisp-weenie, you would’ve just written your app in that language from the beginning, right?
So, it looks like there’s a market for Lua. As long as people keep writing fairly large apps in C and C++.
Edited 2007-09-08 03:19
Your point is well-taken, but I found this particular bit funny:
you write a fairly large program in C… They told you to just use Perl/Python/Ruby/Lisp/whatever. You said no. Now you find that it would actually be quite helpful if you could script your app…
It reminds me of the joke “A programmer has a problem. He decides to solve it with a program written in Perl. Now he has two problems.”
Lua *is* damn small.
Many examples (+55) of general Lua scripting and murgaLua GUIs in Damn Small Linux.
http://www.damnsmalllinux.org
I was delighted when I found Lua a few years ago. I had developed my own ad-hoc scripting language for manufacturing test, but I had to keep extending it in ways I hadn’t originally thought about. The syntax was getting ugly.
I searched for a general purpose scripting engine I could embed in my Windows executable and Lua turned out to be perfect. I put all the test logic in a Lua script that is compiled into the executable but can be replaced at runtime if need be. Custom functions interface to GPIB and serial ports.
I’ve released several versions that are in daily use testing different products at the factory
(aka Dano0) had window decor behaviours (clicking this button moves, …) coded in lua. That was likely because someone at Be wanted to play around with it I suppose… funny but weird semantics.
On a somewhat related note, a while ago I wrote the basics of a Lua theme engine for Gtk. It’s still missing some details, but it worked well enough to prove that it is a viable option. It’s in gtk-engines SVN if anyone wants to play with it, hopefully I’ll sit down and finish it some day.
I wanted a scripting engine because:
– Scripted themes are much easier to install than engines
– Less chance of theme engine bugs causing application crashes
– Much easier to create slightly modified versions of a theme (engine)
– Theme changes can be viewed without reloading
– Easier to work with for “programming designers”
And all that with the near-performance and flexibility of a theme engine.
I picked Lua over Python or similar because it seemed ridiculous to depend on such a huge scripting environment for something that every single widget would depend on. Lua is extremely lightweight, so it is quite suitable for tasks like this.
> a={1,2}
> print(type(a))
table
> print(a~=5)
true
Shouldn’t that be false if types are compared first? In the example above a `table` is not a `number`.
~= means “not equal to”
a table is not a number so ‘a’ is not equal to ‘5’.
thus a~=5 evaluates as a true statement.
ahh, the article made it seem like if the types were different, then any comparison would always return false… clearly that’s not true and the root of my misunderstanding. thanks.