On Tue, Jan 13, 2009 at 10:05 PM, Asko Kauppi
As a generic comment, I think it would finally be time for Lua
develop this kind of modules in an organized fashion.
There's so many of them. D-BUS. Cairo. SDL. Multiple incompatible and
partial modules instead of a One that would be co-managed by the
I think this is where we go wrong, and which keeps Lua back as a
When I have seen libraries become real language-community artifacts it
has been because those projects just got too much momentum. These
projects seem to happen in clusters, and tend to get momentum by
feeding off each other and interacting a lot. It has not been done by
saying "you three go do $foo, we'll do $bar" except in commercial
It is actually great to have 18 competing implementations, that would
be astounding. Usually you have 18 non-competing implementations, 17
half done, and 1 finished but solving a minor problem in the space.
In any open source community, don't think of developer time being a
finite resource, but of being an equilibrium against the difficulty of
actually contributing in the first place. Anything which makes it
easier to do the work leads to more being done pretty much without
If you take a recent example of an explosion of development
productivity, ruby's in the last four or five years, the things which
immediately preceded it were ruby gems (easy and standard way to
install and use modules), good english language documentation, an
extremely helpful community, and a window of opportunity from perl
dropping the ball. These aren't the only things, but they are key. Go
back a few years and look at what happened around Jakarta, back
further and the PHP community, back further and the emergence of CPAN
A similar thing, though less language-focused, is happening around
github now where a whole new dynamic in open source is emerging the
"please fork my project" thing is going to have even be fascinating to
watch play out. A barrier to contribution goes down, developer effort
flows in to fill the space.
What is preventing this effort from being applied in the space
- Lua is focused on embedding, not on being general purpose. It *is*
the dominant language there.
- Going to the Lua documentation page ( http://www.lua.org/docs.html )
is an Amazon advertisement (that said, PiL is (I am going to be struck
with lightning for saying this) even better than K&R as a language
tutorial). Compare this to PHP ( http://www.php.net/docs.php ), for
If you need an embedded language, the other alternatives (various
That said, some folks do aim for general purpose, in those cases:
- Compiling Lua is weird.
- Compiling every module is different.
- Many modules assume lua is in /usr/local and require significant
makefile surgery to convince otherwise.
- No standard packaging mechanism (rocks may take this, but no project
site I go to says to use rocks to install (except kepler which *just*
- Many of the most prominent projects use stone-age infrastructure
(*cough* CVS *cough*).
These are steep barriers.
Etan Reisner kirjoitti 14.1.2009 kello 6:01:
On Tue, Jan 13, 2009 at 05:03:15PM +0800, pan shizhu wrote:
Hello, I've searched google and found nothing about lua binding for
Before I'm writing my own, I think it is better to avoid
wheel, I'd like to ask if anyone has known about a lua binding
Thanks in advance.
This is where I get to throw my hat in the ring and say I started
on a libdbus binding a while back also. I got it far enough to
play around with controlling pidgin (then gaim) from ion but then
side-tracked and haven't gone back to it.
I'm not at all sure I like how I was doing it either so I kept
I'd start again more cleanly at some point but haven't done that
The code is available at http://unreliablesource.net/luadbus/
-0.0.1 tarballs were 'releases' and the -vcs tarball was a
snapshot of the
latest code I had (status unknown) for someone who was asking
about it in
#lua a while back.
I'd love to work on a dbus module for lua again so count me in if
wants to get started.