How to build a Lua binary with MSYS2 that does not depend on MinGW-w64's DLLs


As an environment for building Windows binaries MSYS2 improves upon MinGW/MSYS in several important ways. When you switch, however, you will notice that its builds of Lua, unlike those produced with plain old mingw-base, depend upon external DLLs by default.

"Lua.exe - System Error" screenshot

When you build Lua 5.1.5 with MSYS2's 32-bit version of MinGW-w64 using the command make mingw you end up with a lua51.dll that requires libgcc_s_dw2-1.dll and libwinpthread-1.dll:

$ wget
$ tar xvf lua-5.1.5.tar.gz
$ cd lua-5.1.5/src/
$ make mingw
$ ldd lua51.dll
	ntdll.dll => /c/WINDOWS/system32/ntdll.dll (0x7c900000)
	kernel32.dll => /c/WINDOWS/system32/kernel32.dll (0x7c800000)
	msvcrt.dll => /c/WINDOWS/system32/msvcrt.dll (0x77c10000)
	libgcc_s_dw2-1.dll => /mingw32/bin/libgcc_s_dw2-1.dll (0x6eb40000)
	libwinpthread-1.dll => /mingw32/bin/libwinpthread-1.dll (0x64b40000)

If you want fewer DLLs to manage you have several options. For a quick fix you could build a Lua interpreter statically with make all — but then you would not be able to use binary modules, which expect a lua51.dll. A solution that keeps lua51.dll is explained below.

(read more)

In praise of rewriting


There is value in doing old things from scratch in a new project. You learn to simplify and to correct mistakes. If you reflect well on your previous design you may achieve a sort of reverse second system effect: a more spot-on, more straight-forward replacement for what was overly complicated. The common wisdom says you shouldn't rewrite a large existing codebase from scratch and it's probably correct for the vast majority of cases. However, if you are starting a new project that has overlap with what you've done before it may be an opportunity to get right what you didn't. If your new project has a sufficiently small scale that you are not forced into reusing bits from its predecessors rewriting should be fair game.

(read more)

Mistakes I made in the design of Tclssg (and how they can be fixed)


As the 1.0.0 release of Tclssg approaches I want to take a look at the less fortunate design decisions I made for the project. The goal of this post is to point out the design problems currently present in Tclssg, trace where they came from and outline how they could be mitigated and eventually solved without breaking backwards compatibility. It is also meant to serve as a reference to help avoid making the same mistakes in the future.

(read more)

Split or Steal?


The UK game show Golden Balls (don't laugh) asks the two participants who make it to the final round to split their win using a variant of the prisoner's dilemma. A typical final round of the game looks something like this: heavy on bluffing and serious-faced human drama. What happened when one participant applied a little game theory is rather different. It is worth watching just for how everybody else reacts to the smirking instigator's strategy.

Tcl's [binary scan] and the Go Challenge 1

Published , updated

In the programming language Tcl the command [binary scan] decodes binary data according to a format string. For example,

binary scan $data {cu4 f1 a*} fourBytes aFloat remainder

will read four unsigned 8-bit integers from the string data and put them into the variable fourBytes, then read one 32-bit floating point number and put it in aFloat, then, finally, put the remaining string in remainder (without altering data itself).

(read more)

MapReduce in terms of SQL


I found a great explanation of MapReduce in terms of SQL in a blog post about Hadoop by Chris Stucchio:

SQL-ish pseudocode:

SELECT G(...) FROM table GROUP BY F(...)

The only thing you are permitted to touch is F(k,v) and G(k,v), except of course for performance optimizations (usually not the fun kind!) at intermediate steps. Everything else is fixed.

Re: Data munging


A short while ago I read a curious blog post titled "Data munging in Perl 6 vs Perl 5". I liked how each individual Perl 6 code snippet for each data manipulation looked. I understood that the purpose of the exercise was to highlight this particular part of the language. And yet, in the end I couldn't shake off the thought that this was not the right way to solve the kind of problems of which the toy problem at hand was an example. I have come to suspect that complex dictionary manipulation is mostly an antipattern that appears in scripts as they evolve into complex programs over time.

(read more)

Scheme implementation performance


I found the following quote from helpful:

performance: Depends on what you're doing, but in general, -C compilers (Stalin, Bigloo, Gambit, Chicken) come at the top, with Stalin somewhat faster than the others; some compilers (mzc) are on par with fastest interpreters. Interpreters fall in three classes, fast (Racket, Gauche, RScheme, STklos), intermediate (Scheme48, scsh, SCM, MIT Scheme, Guile 2.0) and rather slow (guile1.6). guile1.4 is yet slower.

See also: