Gems on the interwebs – luakernel, stb, and me

Since the day of their inception, the interwebs have been a tremendous ‘resource’ to mankind.  Sharing academic papers… cat videos!!  Endless amounts of shopping, and who can ever do without pop-up ads!

Well, I have actually found very interesting things on the interwebs of late, particularly related to coding.  There’s almost nothing under the sun which has not been coded to date, or can’t be used as a building block to code up the next big thing.

Interesting people and tidbits I’ve looked at in the past year:

Karl Malbrain – Tons of interesting stuff related to data structures in particular

Sean Barrett – Tons of stuff from truetype font rendering to image reading/writing

Bob Jenkins – Hashes, random, math, physics, just all around good stuff

There are plenty more interesting libraries out there in the world.  These few stand out because they’re not libraries.  They’re not a part of some big grand platform.  They just plain standalone pieces of code which tend to be useful as learning tools.  The other thing that stands out is their liberal licensing.  There’s nothing worse than that monkey hand in the gourd moment when you’ve found some great piece of code to borrow from, and then you realize it’s a GPL’d thing, which is enough to curdle the strongest of milks.

I favor public domain, MIT, Apache, WTF, licensing myself because if you’re going to share, then share…  Otherwise, keep it to yourself.

I the Lua world, I’ve run across some gems lately that have been very interesting.

Reuben Thomaslua-stdlib : Perhaps the most useful thing out of this library is the std.optparse routines.  They allow you to easily specify, and then parse the arguments you pass to your program.  That takes care of an amazingly annoying set of routines (getopt, optind, optarg, argc, argv…) which are extremely buggy for me, and error prone.  There are other gems and techniques in this library which make it a real treasure trove to the Lua developer.

Eric R. Schulzluakernel Wait, what?  A kernel for x64 which boots into a Lua runtime?  Well, ok, embedded Lua did that a long time ago, but this seems like something I can easily approach.  I’ve got to add my graphic library to this thing so that I can boot into a Lua kernel, and party on with my killer graphics.  So, Lua kernels from tiny devices such as the ESP8266, to higher end x64 machines.  Not bad for the little language that could.

I’m just constantly amazed at how, after slaving away at something for a while, I’ll stumble across a gem on the internet which solves the exact problem I was after, or comes close enough to make me feel like I need to leverage that work, rather than start from scratch.

The best thing to do as a developer, is to get in the habit of looking out, leveraging, building your own treasure chest of tools, so that you can create that next big thing even quicker and more robustly than before.

Now I’m going to have to make a project of getting luakernel on one of my tired old boxes, so that I can host my graphics library, and develop the UI code (including full trutype support) even further.


Is that cool or what – Embedding LuaJIT bytecode

I write a lot of script code, and while it’s under development, it’s great that I can easily access it, change it, and just run it immediately and see what happens. I think it would be great though if I could combine several scripts into a single self sufficient executable file.

How to do this with LuaJIT?

Well, first of all, let’s say I want to create an executable called tinn.exe. I want this executable to be just like luajit.exe, except for the addition of the extra stuff I want to throw in. The ultimate link command would look something like this:

%LJLINK% /out:tinn.exe tinn.obj %TINNLIB% %WIN32LIB% %LJLIBNAME%

Easy enough to understand. Just a standard linker command. TINNLIB IN32LIB look something like this:

@set TINNLIB=base64.obj BinaryStream.obj BitBang.obj Collections.obj 
@set WIN32LIB=BCrypt.obj BCryptUtils.obj win_kernel32.obj win_socket.obj NativeSocket.obj

Great! This is exactly what I would expect to see if I were compiling a standard ‘C’ based application. Basically just combine all these .obj files and link them with the primary file ‘tinn.c’, and we have a program.

But, my sources are lua script ‘.lua’ files. How to go from there to ‘.obj’ files? It turns out to be shockingly easy using LuaJIT.

luajit.exe -b base64.lua base64.obj

In this case, luajit, with the ‘-b’ flag, will compile the specified file into the specified output file format. You could do the same to generate a .c, or .h file if you want.

What do you get for your troubles? Here’s what I think is real magic. Once you generate the .obj file, and link it into the intended program, you can easily access it just like you normally would:

local b64 = require("base64")
b64.encode(somestring);

It’s that easy. The only real gotcha is that you have to make sure you get the spelling right, at least in the Windows environment. ‘Base64’ is a different module than ‘base64’.

So, you can write your script code, try it out while in development, and once you’ve solidified something you want to make available, use this technique to throw everything together into a single ‘.exe’ file, and distribute that. I think this is fairly special because it makes the executable on par with any other kind of application. The user will have no knowledge that the thing was actually created and run using lua scripts.

I think this is very cool, and just one more reason I really like using LuaJIT.