Since my latest announcement of the Lua workshop, I received a couple of
emails asking why I discourage the use of Lua.
Actually, I already wrote out many of the things I dislike about Lua. I
won't come back on this technical issues here, but since Lua 5.2 is not yet
released (it's still at alpha stage), they are still relevant nowadays.
Stack based API is harder
The ease of integration of Lua into a C program is one of the point of Lua.
They claim it's very easy to integrate Lua into your C application, because
it does not use pointer, nor reference counting, nor anything that requires
a minimum amount of skills to be used.
It uses a virtual stack based approach. You push or pop things on a stack,
and refers to them using a relative or absolute index.
In order to people who never wrote Lua code to understand, here's a quick
example on how this work. The L pointer is a Lua environment.
/* Create a table on the stack: index 1 */
lua_newtable(L);
/* Push a string on the stack: index 2 */
lua_pushstring(L, "hello");
/* Push a number on the stack: index 3 */
lua_pushnumber(L, 123);
/* Set newtable["hello"] = 123 */
lua_settable(L, -3);
You first push a table (in Lua, a table is almost equivalent to what you'd
call a hash table in other language), then push the key, the value, and do
the assignment operation. In the settable, we use -3 as index, meaning the
"3rd item on the stack counting from top". We could also have written
lua_settable(L, 1), since the table is also the first item on the stack from
the bottom.
So far, so good.
Problems arise when you do more complicated stuff. My previous example is
what you would typically find in a tutorial, but of course, real life is
different, and usually more complex. If you cut the things in different
parts, it can start to be more complicated.
Let's take a look at the following:
/* Create a table on the stack: index 1 */
lua_newtable(L);
/* Push a string on the stack: index 2 */
lua_pushstring(L, "hello");
/* Push a number on the stack: index 3 */
lua_pushnumbe(L, mycomputingfunction());
/* Set newtable["hello"] = 123 */
lua_settable(L, -3);
Here, we do exactly the same thing, but we do not push
123 directly: we
compute it.
And here's the trick: if your computing function is also using the Lua
stack, things can become
very messy. As long as your computing function use
the stack cleanly by pushing and poping all its item, and returning the
stack in the same state it was before, you're safe. The problem is that in a
complex program, you also write bugs. You do not chose to, but you do. And
sometimes, you forget to pop one of the item you fetched from a table.
Imagine that
mycomputingfunction is:
int
mycomputingfunctiong(void)
/* Just push the table we want to fetch
the number from on the stack */
pushatableonstack(L);
lua_pushstring(L, "mykey");
lua_gettable(L, -2);
return lua_tonumber(L, -1);
This function works perfectly. It pushes a table, then a key (
"mykey"), then
fetches mytable["mykey"] and pops the key (lua_gettable does push value/pop
key itself), and then returns the numeric value of the last item (the
fetched one) of the stack.
However, this function has a bug: it does not pop the table! This does not
prevent the function to work. It does not raise a segmentation fault. It
does not show any problem under
gdb. It does not show any leak under
Valgrind. It does now show any problem under any standard C debugging tool.
But when you'll start using it, your program will start to do weird things,
and you'll have to spend a huge amount of time debugging it manually,
dumping the stack content at each step of your program to watch out what's
wrong.
Another bad thing, that can happen, is some code poping accidentally an item
from the stack, or worst, from an empty stack. This does not raise any error
on the Lua side, but will break your program in very unfunny way.
Even if I've been very meticulous writing
awesome, but we hit that problem
regularly.
The easiest workaround is to use
lua_settop(L, 0) to reset the stack to 0
element. Doing this regularly (like after each program event or treatment)
can remove left-over items and avoid the never ending stack grow you may
experience if your left-over items continue to pile up. Did I tell you I
dislike work-around?
You could also use
lua_call(), which would avoid such an error, but this
would require a huge amount of indirection, and would make write more
(useless) code.
This kind of problem does not exists with pointer based API. If you screw
things up, the problem will cause a segmentation fault or leak memory, or
cause things you can (easily) debug with standard tools like gdb or
Valgrind.
No reference counting is a pain in the ass
Userdata objects are variable Lua size objects embedding a C struct you
define. It's the equivalent of an object in object oriented language.
Lua does not provide any reference counting for the userdata objects. That
means you can push this objects on the stack, use them, but they cannot
directly reference each others. If you have a "car" userdata and a "wheel"
one, the car cannot hold directly a reference to the wheel. This is not
possible because userdata are allocated and garbage collected by Lua, and
there's no way to increase the reference counting yourself.
So the common hack is to store the wheel into a table as a value, and store
the table index as an integer into the car data structure.
This obviously makes memory leaks tracking harder, add huge level of
reference indirection in usage (still more code), and does not make the
whole process less error prone (at least in my opinion).
No paradigm makes you lose time
Lua is proud to come with no paradigm and to provide metatables.
I already showed 3 years ago that it has big flaws.
To me, this ain't no good. Lua is not functional, nor it is object oriented.
Most people, including me, want one of this paradigm, or any else. Plain old
imperative is not enough.
So you'll start to build more, or to use something like LOOP, which
implements an object model. You'll implement your paradigm. I say life is
too short to (re)write a paradigm.
In awesome we wanted to have an object oriented approach (this is kind of
typical in such a graphical application context), so we tried to build one.
To me, this started to be a show stopper when I realized that I've ended
writing Python object model into Lua while developing awesome (which aims to
be a window manager, not a language). This is one of the reason I stopped
hacking on Lua things.
I liked Python object model and wanted to have it in Lua, and spending time
rewriting Python is just not worth it. I probably should have chose Python,
not Lua. YMMV.
Embedding may not be a good choice
This is not Lua related, but I want to mention it. Googling for
"embedding vs extending" will probably tell you more about why you should
double check that you really need to embed Lua rather than to extend it.
Being small is not an excuse
One common argument to choose Lua is that it has a small footprint. Yeah,
that's true, but that's useless. Bummer! When I program, I don't have any
resource usage pressure. People who have such pressure are either paranoids
or playing in the world of embedded computers. This is also a no more
existing conception since quad core processors equiped phones are coming
into the market. I'm rather confident that what we used to call embedded
devices are just dead and are now plain computers. But as usual, YMMV.
So start to forget about it, run in your underpants and yelling "yay we
killed that shit!", and then use real computers stuff. :-)
Even if benchmarks show how Lua is damn fast, remember what a benchmark
proves: that you can do useless things very fast.
Too few extension modules
This is not directly Lua's fault, but there's too few extension modules for
Lua. The community is quite small compared to other big languages' ones.
So think twice
before you choose Lua (or any other language). My recommendations these days
would be not to embed, but to extend. If you really have no choice and need
to embed a language into your application, GNU Guile is probably worth
considering, because it's a Scheme and therefore a functional language :-),
and because it can provides also different languages.
Including Lua.
A few days ago I did an interview
for the People Behind Debian series that, among other things, covered
my Debian press work and asked what it's like to do that kind of work for
Debian. Here's a little addendum:
Sometimes Debian Press Work is great: All these people do all this
amazing stuff and it's a pure pleasure to talk about it. Our last release
was such an experience for example. I was clamped to my laptop for almost
20 hours straight and I had a great time! There was this great common
feeling of community, achievement and pride in our work and I was proud and
happy to be a part of it.
And then there are times like the last few days, where Alex and I went
South for 4.5 precious and long-awaited days of vacation and ended up
spending the first two of them working on an obituary for a dear and
much valued member of our community and once this was done spent the
remaining days of our holidays nervously watching the net and drafting and
re-drafting press announcements because some <bleep> thought
it might be oh-so-hilarous to send out faked cease and desist
orders to a Debian user, ostensibly as a 
The 
My responses to the objections
Those are the two major objections that we ll have to respond to. Let s try to analyze them a bit more.
It s not testing vs rolling
On the first objection I would like to respond that we must not put testing and rolling/unstable in opposition. The fact that a contributor can t do its work as usual in unstable does not mean that he will instead choose to work on fixing RC bugs in testing. Probably that some do, but in my experience we simply spend our time differently, either working more on non-Debian stuff or doing mostly hidden work that is then released in big batches at the start of the next cycle (which tends to create problems of its own).
I would also like to argue that by giving more exposure to rolling and encouraging developers to properly support their packages in rolling, it probably means that the overall state of rolling should become gradually better compared to what we re currently used to with testing.
The objection that rolling would divert resources from getting testing in a releasable shape is difficult to prove and/or disprove. The best way to have some objective data would be to setup a questionnaire and to ask all maintainers. Any volunteer for that?
Unstable as a test-bed for RC bugfixes?
It s true that unstable will quickly diverge from testing and that it will be more difficult to cherry-pick updates from unstable into testing. This cannot be refuted, it s a downside given the current workflow of the release team.
But I wonder if the importance of this workflow is not overdone. The reason why they like to cherry-pick from unstable is because it gives them some confidence that the update has not caused other regressions and ensures that testing is improving.
But if they re considering to cherry-pick an update, it s because the current package in testing is plagued by an RC bug. Supposing that the updated package has introduced a regression, is it really better to keep the current RC bug compared to trading it for a new regression? It sure depends on the precise bugs involved so that s why they prefer to know up-front about the regression instead of making a blind bet.
Given this, I think we should use testing-proposed-updates (tpu) as a test-bed for RC bug fixes. We should ask beta-testers to activate this repository and to file RC bugs for any regression. And instead of requiring a full review by a release manager for all uploads to testing-proposed-updates, uploads should be auto-accepted provided that they do not change the upstream version and that they do not add/remove binary packages. Other uploads would still need manual approval by the release managers.
On top of this, we can also add an infrastructure to encourage peer-reviews of t-p-u uploads so that reviews become more opportunistic instead of systematic. Positive reviews would help reduce the aging required in t-p-u before being accepted into testing.
This changes the balance by giving a bit more freedom to maintainers but still keeps the safety net that release managers need to have. It should also reduce the overall amount of work that the release team has to do.
Comments welcome
Do you see other important objections beside the two that I mentioned?
Do you have other ideas to overcome those objections?
What do you think of my responses? Does your experience infirm or confirm my point of view?
It s the time of the year again. 
I use 
Donald Trump you magnificent bastard, 
The Linux kernel attempts to protect portions of its memory from unexpected modification (through potential future exploits) by setting areas read-only where the compiler has allowed it (
At some stage the seminal KDE vs Gnome paper vanished from its 
Testing without freezes = rolling
The first one is that testing is no longer testing during freezes. The regular flow of new upstream versions that makes testing so interesting for many users is stalled because we re using testing to finalize the next stable version. That s why I d like to introduce a new suite called rolling that would work like the current testing except that it never freezes. Testing would no longer be a permanent suite, it would only exist during the freeze and it would be branched off from rolling.
Rolling should be a supported distribution
The second obstacle is not really technical. We must advertise rolling as a distribution that ordinary people can use but we should make it clear that it s never going to have the same level of polish that a stable release can have. And to back up this assertion, we must empower Debian developers to be able to provide good support of their software in rolling, this probably means using rolling-proposed-updates more often to push fixes and security updates when the natural flow of updates is blocked by transitions or other problems. Some maintainers won t have the time required to provide the same level of support as they currently do for a stable release and that s okay, it s not worse than the current testing. The goal is to treat it on a best-effort basis and to try to gradually improve the situation.
My goal for wheezy
This is the the minimal implementation of CUT that I would like to target in the wheezy timeframe. Having testing as a temporary branch of rolling is not a strict requirement, although I d argue that it s important to not waste resources towards maintaining two separate yet very similar distributions.
Should Debian embrace those goals?
Ignoring all possible problems that will surface while trying to implement those goals, can we agree that Debian should embrace those goals because it means providing a better service to a class of users that is not satisfied by the current stable release?
I will come back to the expected problems in a subsequent post and we will have the opportunity to discuss them. Here I just want to see whether we can have broad buy-in on the principles behind Debian rolling and CUT.
i can haz understanding?I m trying to rebuild a package with gcc-4.6 instead of (default) gcc-4.5. Sounds easy, huh?Not today, not with qmake :(Setting 
I was trying to build the 
As Evgeni Golov 
This year we will have two more projects is GSoC comparing to last year, the chosen ones being: