hisham hm

🔗 Lua string concatenation considered not harmful

A user in the Lua mailing list recently asked the following question:

yield( splits[i-1][1]..word[i+1]..word[i]..splits[i+2][2] )

I tried table.concat and string.format, but both perform worst. This was
counter-intuitive to me, because Lua string concat generates copies of
intermediate strings. However, seems that for short strings and small number
of concatenated strings, string __concat performs better than string.format
or table.concat. Does anyone know if my observation is true?

The “folk wisdom” about copies of intermediate strings in Lua is often mis-stated, I think.

("aa"):upper() .. ("bb"):upper() .. ("cc"):upper() .. ("dd"):upper()

It translates to a single concatenation bytecode in both Lua and LuaJIT, so it produces the following strings in memory over the course of its execution:


This, on the other hand, does generate intermediate strings:

local s = ""
for _, w in ipairs({"aa", "bb", "cc", "dd"})
   s = s .. w:upper()

It produces


Notice the little pyramid at the end. This pattern is the one that people tell to avoid when they talk about “intermediate strings”. For a loop like that, one should do instead:

local t = {}
for _, w in ipairs({"aa", "bb", "cc", "dd"})
   table.insert(s, w:upper())
local s = table.concat(t)

That will produce:


plus an extra table. Of course this is an oversimplified example for illustration purposes, but often the loop is long and the naive approach above can produce a huge pyramid of intermediate strings.

Over the years, the sensible advice was somehow distorted into some “all string concatenation is evil” cargo-cult, but that is not true, especially for short sequences of concatenations in an expression. Using a..b..c will usually be cheaper and produce less garbage than either string.format(”%s%s%s”, a, b, c) or table.concat({a, b, c}).

🔗 LuaRocks 3.0.0beta1

I am extremely happy to announce LuaRocks 3.0.0beta1, the almost-finished package for the new major release of LuaRocks, the Lua package manager.

First of all: “Why beta1?” — the code itself is release-candidate
quality, but I decided to call this one beta1 and not rc1 because the
Windows package is not ready yet, and I wanted to get some early
feedback on the Unix build while I complete the final touches of the
Windows package.

This is NOT going to be a long-or-endless beta cycle: if no major
showstoppers are reported, the final 3.0.0 release, including Unix and
Windows packages, is expected to arrive in one week. But please, if
you want to help out with LuaRocks, give this beta1 a try and report
any findings!

Yes, it’s finally here! After a way-too-long gestation period, LuaRocks 3 is about ready to see the light of day. And it includes a lot of new stuff:

All of the above are detailed here:


I’ll try to write up more documentation between now and the final release. Feedback is wanted regarding what needs to be documented/explained! And help updating the wiki is especially welcome.

And without further ado, the tarball for Unix is here:


This release contains new code by Thijs Schreijer, George Roman, Peter Melnichenko, Kim Alvefur, Alec Larson, Evgeny Shulgin, Michal Cichra, Daniel Hahler, and myself.

Very special thanks to my employer Kong, for sponsoring my work on LuaRocks over the last year and making this release possible. Thanks also to my colleagues Aapo Talvensaari and Enrique García Cota for helping out with some last-minute testing.

In the name of everyone in the LuaRocks development team, thank you for the continued amazing support that Lua community has been giving LuaRocks over the years: keep on rockin’!


🔗 Receita de frango ao curry


* 400g de peito de frango
* 1 caixinha de creme de leite (200 ml)
* 3 colheres de sopa de curry
* 1 colher de sopa de açafrão
* 2 colheres de sopa de açúcar mascavo
* 2 colheres de sopa de shoyu
* 1 copo de água filtrada
* 2 colheres de sopa de manteiga
* 1 pitada de pimenta-do-reino
* cebola e alho a gosto (a receita original listava 2 cebolas pequenas e 3 dentes de alho)

Modo de Preparo:

* Corte o frango em cubinhos.
* Coloque a cebola e o alho para fritar na manteiga (quando a cebola começar a amolecer, acrescente o alho)
* Quando o alho começar a cheirar, acrescente o curry, a pimenta, o açafrão e o frango.
* Refogar mexendo por cerca de 3 minutos.
* Acrescentar o açúcar mascavo e mexer novamente.
* Acrescente a água, aos poucos, sempre mexendo.
* Acrescente o shoyu (a receita original não dizia em que passo acrescentar o shoyu)
* Deixar cozinhar em fogo médio, até reduzir a água e formar um molho um pouco mais grosso (cerca de 15 minutos, depende do fogão).
* Experimente o frango para ver se ficou bem cozido (o frango, quando cozido, reduz bastante seu tamanho original).
* Acrescente o creme de leite, mexendo sempre e baixe o fogo.
* Cozinhe por cerca de 2 minutos, ou até o creme aquecer.
* Sirva com arroz.

Fonte: https://cozinhadaraquel.blogspot.com/2006/08/frango-ao-curry-com-creme-de-leite.html

🔗 When listing repeated things, make pyramids

Often, in code, we have to write lists of repeated things. For example, attribute initialization in Java constructors:

this.foo = foo;

or required modules in Lua:

local foo = require("foo")

There are a few different ways people stack these when they need to list a number of them: randomly, alphabetic, aligned… working on a codebase that has all these approaches in different modules, I realized that “pyramid” is best. Let’s compare a few examples:


This is what you end up doing if you don’t really think about it:

this.medium = medium;
this.aLongOne = aLongOne;
this.foo = foo;
this.veryLongOne = veryLongOne;
this.short = short;

⊖ ⊖ very bad to read - your eyes move back and forth horizontally and need to scan the whole thing vertically
easy to maintain - just add or remove entries arbitrarily


This is what you end up doing if you get annoyed about the order when writing. I did this for a while.

this.aLongOne = aLongOne;
this.foo = foo;
this.medium = medium;
this.short = short;
this.veryLongOne = veryLongOne;

bad to read - your eyes move back and forth horizontally, but it’s easy to scan vertically
easy to maintain - no question where a new entry should go


This is what you end up doing if you start to get annoyed when reading. Readability is more important than writability, after all!

this.aLongOne    = aLongOne;
this.foo         = foo;
this.medium      = medium;
this.short       = short;
this.veryLongOne = veryLongOne;

⊕ ⊕ very easy to read easy on the eyes horizontally, and if alphabetical it’s easy vertically as well
⊖ ⊖ very bad to maintain terrible for diffs, changes mess up `git blame` for unrelated lines


Finally, we get to the pyramid, which seems an ideal compromise keeping the advantages of an aligned list while avoiding its drawbacks:

this.veryLongOne = veryLongOne;
this.aLongOne = aLongOne;
this.medium = medium;
this.short = short;
this.foo = foo;

easy to read - easy on the eyes horizontally as the eyes follow the diagonal, and easy vertically as well as you usually know if you’re looking for a long or short word
easy to maintain - no question where entries go; you can use alphabetical order as a tie breaker for entries of same length

You can of course do the pyramid “ascending” or “descending”. I don’t really have a preference (and I couldn’t find any practical advantages to either yet).

In conclusion, it’s a silly little thing, but something that improves the ergonomics of the code and which I’ll try to adopt in my code more consistently from now on.

(PS: Of course, all of this applies to lists where the entries are not semantically related: when listing color components one would always do “red, green, blue”, and not “green, blue, red” :) )

🔗 A nice summary of Git commits with files when rebasing

When you’re making a large interactive rebase, it’s useful to see what files each commit touches.

Here’s a nice trick. Take the list of commits from `git rebase -i` and save it into a text file, `commits.txt`, which should look something like this:

pick aef18c84 fix something
pick efa1d6pd add a feature
pick 74417d1d something else

then run this:

(cat commits.txt | while read x commit rest; do echo; echo "#" $commit $rest; git show $commit --pretty=format:'## %an' --name-only; done ) > commits.md

This will generate a file called `commits.md`, with contents like this:

# aef18c84 fix something
## Hisham Muhammad

# efa1d6pd add a feature
## John Doe

# 74417d1d something else
## Hisham Muhammad

Keeping this `commit.md` open side-by-side to an interactive rebase session makes it a lot easier to quickly glance which commits touch the same files, which greatly reduces the changes of conflicts when moving commits around. Plus, using hash signs and the .md extension makes the whole thing even easier to read, when your text editor has support for highlighting Markdown files!

Latest posts


Admin area