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)

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)

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: