Here’s a nice 4 page reference for Lua 5.1. It was created by Thomas Lauer and can be downloaded from his website. I’ve reposted it here just-in-case… I’ve been bitten before.
I’ve been working lately on embedding Lua 5.1.4 into a C++ application. I’m really impressed with Lua, and most things are pretty straight-forward. However, when it comes to mapping typed enumerations into Lua, I just haven’t found an easy way to do it. For example, let’s say you want to expose a C++ function into Lua called create(), which takes an enumerated type as a parameter. In C++ this would look like:
typedef enum _TYPE {
TYPE_FOO = 0,
TYPE_BAR,
TYPE_BAZ,
TYPE_MAX
} TYPE;
bool create(const TYPE type);
To me, it makes the most sense to call create() from Lua with syntax like:
> create(type.foo)
Ideally, we’d also like the following:
- The enumeration is const, and can’t be altered from Lua code.
- The C++ implementation of
create()could validate the type passed to it is the expected type.
Unfortunately, this isn’t as straight-forward as everything else I’ve done with Lua.
Solution (i.e. cut-to-the-chase and explain later)
Okay, I’m a practical guy… download lua_typed_enums.h and include it in your code. Then you can add the enums shown above to Lua by calling add_enum_to_lua():
add_enum_to_lua( L, "type",
"foo", TYPE_FOO,
"bar", TYPE_BAR,
"baz", TYPE_BAZ,
0 );
Your enums are now available in Lua as:
type.foo
type.bar
type.baz
Now, your C++ code that takes TYPE as an input and returns a boolean would be written as follows:
static int lua_create( lua_State *L )
{
if( !check_enum_type( L, "type", -1 ) ) {
/* error */
}
int value = get_enum_value( L, -1 );
/* do something cool */
lua_pushboolean( L, 1 );
return (1);
}
You can now call your create() method from Lua how we wanted:
> create(type.bar)
Look at the comments in the header file if you want more info about using add_enum_to_lua(), check_enum_type(), and get_enum_value().
How it Works
There’s no direct way to map the expected behavior of C-enums into Lua (const-ness with typing). What I did was to create a read-only Lua table representing the enumerated type and then make each value in that table have a defined type.
Let’s deal with the first task: making a read-only table. This is pretty well documented on the web, but I’ve included a drawing below that would have helped me a lot in the beginning. Let’s assume we want to represent our enum as a Lua table. We could visualize it as follows:
We could still use the type.foo syntax with this table, but a user could assign a new value to the enum like:
> type.foo = 9
To prevent this, we need to deny write access to the table. The trick to doing this is to use a metatable and set the __index and __newindex values.
So how does this work? When the user reads a value from the table (i.e. by using type.foo), Lua fails to find “foo” in the table. So it looks in the metatable for the __index key. If that is set to point to a table, then it will try to lookup the value in that table. In the case above, it finds the “foo” value and returns it like normal. However, if the user attempts to assign to type.foo, Lua follows the __newindex path, which causes a function to get called that does nothing but print an error… effectively, the write is denied. Here’s what happens:
> type.foo = 9
[string "?"]:1: Attempt to modify read-only table
Okay, cool… we’ve made read-only enumerations, but what about typing. Glad you asked! We add one more layer of abstraction, of course <groaning>:
Basically, we make each value a table that includes the actual value and a type (“type” in our example above). The check_enum_type() function looks at the “type” field in the table to make sure the correct type was passed to your function. The get_enum_value() function gets the “value” field… which is equal to the actual C-enum type you’d expect. From the Lua side, you can inspect the enums like:
> print(type.foo.value)
0
> print(type.foo.type)
type
Explicitly, “type” is a read-only table with value “foo”. The value of “foo” is the table { value=0, type="type" }. I hope this explanation helps. Obviously, I’ve been geeking out on Lua a little too much lately
Yesterday, I needed to get my server’s network information for a Bash script I was writing. Here are the commands so I don’t forget. They were tested using Fedora 12.
Get IP address:
ifconfig eth0 | awk '/inet / {print $2}' | awk -F: '{print $2}‘
Get MAC address:
ifconfig eth0 | awk '/HWaddr/ {print $5}'
Get network gateway IP address:
route -n | awk '/^0.0.0.0/ {print $2}'
Using the Tcpreplay tools to edit a Wireshark capture (*.pcap), I wanted to change the destination address to be multicast. I knew the IP multicast address I wanted (server IP address with the first octet changed to 239), but I had to change the MAC address also.
Here’s the mapping, taken from a Microsoft TechNet article:
To support IP multicasting, the Internet authorities have reserved the multicast address range of 01-00-5E-00-00-00 to 01-00-5E-7F-FF-FF for… media access control (MAC) addresses.
To map an IP multicast address to a MAC-layer multicast address, the low order 23 bits of the IP multicast address are mapped directly to the low order 23 bits in the MAC-layer multicast address. Because the first 4 bits of an IP multicast address are fixed according to the class D convention, there are 5 bits in the IP multicast address that do not map to the MAC-layer multicast address. Therefore, it is possible for a host to receive MAC-layer multicast packets for groups to which it does not belong. However, these packets are dropped by IP once the destination IP address is determined.
For example, the multicast address 224.192.16.1 becomes 01-00-5E-40-10-01.
Happy hacking!
FFMpeg provides many powerful features for processing audio and video. One cool thing it can do is resample an audio stream. This allows you to convert, say, a 44.1kHz audio stream down to 8kHz, or up to 48kHz. What’s more, FFMpeg can do the conversion to any arbitrary sample rate. This allows you to do cool things like smoothly changing the audio playback speed over time (see sample code below).
There are many pages describing how to resample audio using the ffmpeg command line application, but what about doing resampling in your own program? To do that, you need to use the avcodec library (libavcodec.so on Linux and avcodec.dll on Windows).
- Include
avcodec.h - Call
avcodec_init()to initialize the FFMpeg library. - Create a resampling context using
av_resample_init()that describes how you want the resampling done. - Call
av_resample()to do the actual resampling on your audio buffer. - When you’re done with the resampling context, delete it with
av_resample_close(). - Finally, link your application against
avcodec,avutil, andzlib(it won’t work on Linux without this one).
Here it is in pseudocode:
#include "libavcodec/avcodec.h"
avcodec_init();
struct AVResampleContext* ctx = av_resample_init( ... );
av_resample( ctx, ... );
av_resample_close( ctx );
That’s it… seriously!
Sample Code (Linux):
Here’s a sample program I wrote that takes a raw 44.1kHz/16bit/mono audio file and plays it back using the pulseaudio API. The catch is that it allows you to specify a “skew” parameter which will cause the audio to dynamically speed up and slow down (via resampling). The amount of resampling is controlled by a sine wave, which is what drives the speed changes.
Download: resample.tar.bz
To unpack and build, type:
$ tar -xjvf resample.tar.bz
$ make
First, run the sample with no skew:
$ ./resample audio_16b_44k_mono_pcm_raw 0
Now, try it with a heavy skew:
$ ./resample audio_16b_44k_mono_pcm_raw -10000
When rendering graphics or video to the screen, it’s important to understand the display process; in particular, vertical sync (v-sync). A common problem when starting out is an issue called “tearing”… where the video appears to be torn horizontally down the middle (see picture). I’ve been looking for a good explanation to share about why video tearing occurs and how to solve it (from a technical perspective). I found the following thread over at [H]ard|Forum, which I think does a pretty good job.
For the thread “How VSync works, and why people loathe it“:
There is a technique called triple-buffering that solves this VSync problem. Lets go back to our 50FPS, 75Hz example. Frame 1 is in the frame buffer, and 2/3 of frame 2 are drawn in the back buffer. The refresh happens and frame 1 is grabbed for the first time. The last third of frame 2 are drawn in the back buffer, and the first third of frame 3 is drawn in the second back buffer (hence the term triple-buffering). The refresh happens, frame 1 is grabbed for the second time, and frame 2 is copied into the frame buffer and the first part of frame 3 into the back buffer. The last 2/3 of frame 3 are drawn in the back buffer, the refresh happens, frame 2 is grabbed for the first time, and frame 3 is copied to the frame buffer. The process starts over. This time we still got 2 frames, but in only 3 refresh cycles. That’s 2/3 of the refresh rate, which is 50FPS, exactly what we would have gotten without it. Triple-buffering essentially gives the video card someplace to keep doing work while it waits to transfer the back buffer to the frame buffer, so it doesn’t have to waste time. Unfortunately, triple-buffering isn’t available in every game, and in fact it isn’t too common. It also can cost a little performance to utilize, as it requires extra VRAM for the buffers, and time spent copying all of them around. However, triplebuffered VSync really is the key to the best experience as you eliminate tearing without the downsides of normal VSync (unless you consider the fact that your FPS is capped a downside… which is silly because you can’t see an FPS higher than your refresh anyway).
If the thread is ever unavailable, you can download a PDF version HERE.
ThreadNinja is a Linux library my team created that tracks pthread_create() and pthread_join() calls in an application. It prints a stacktrace where each thread is created and where it is joined. Any rogue (unjoined) threads are reported when the application exits. ThreadNinja is unobtrusive: it does NOT have to be compiled into the code. This means you can use it on applications you didn’t compile.
We found it useful and thought we’d share it. It’s be no means production code… just a tool. Hack on it, expand it, change it… whatever. It’s pretty small, so it should be easy to dive right in. We’ve released it under the BSD license.
Cut To The Chase
You can checkout the source code from Google Code, or download the version 1.0 tarball directly (threadninja.tar.gz).
To build ThreadNinja, simply untar it and call make:
> tar -zxf threadninja.tar.gz
> make
Now, simply use LD_PRELOAD to run the application:
> LD_PRELOAD=/path/to/threadninja/build/libthreadninja.so.1 TheApplication
If you don’t see function names in the stacktraces that are generated, then the application needs to be compiled with debug symbols. For my test app, I had to compile with the -rdynamic option:
> g++ -Wall -rdynamic main.cpp -lpthread
This causes the global symbol table to be included in the executable, which contains all the application’s function names. For more info, look at the --export-dynamic option on the GNU linker (ld) man page.
The Story Behind ThreadNinja
My team was assigned to stabilize a large video application that runs as a Linux-based appliance. The application consisted of 100,000+ of lines to code that was a tangle of build warnings, circular references, and many creative hacks. Our particular task was to fix a persistent set of seg-faults and memory leaks.
Continue reading »
“Cryptography can be used to secure my data. Therefore, if I use cryptography my data is secure.”
Wrong.
I think Bruce Schneier described it best (paraphrased): Cryptography is like having a really strong front door on your house… 2 foot thick steal, blast proof, the whole 9 yards. A thief isn’t going to try and break through your front door… they’ll just climb through a window!
Security is about the whole system; not just the crypto. xkcd summed it up nicely:
High-performance timing is hard… no doubt about it. I can’t tell you how many times I’ve seen high-performance timing code done wrong. Timing is one of those things where a little knowledge can be problematic; the code may work, but it either won’t perform or will exhibit “unexplained” behavior. The purpose of this post is to explain a foundational component to getting timing right: the clock. I won’t focus on theory… this post is meant to be pragmatic.
Note: I’m talking here about interval timing (i.e. accurately measuring the duration between 2 events). This is different than synchronizing different clocks or maintaining accurate wall time.
Anatomy of the Clock
The first mistake most people make when doing timing is to use functions like gettimeofday(), GetSystemTime(), etc. These functions return what is called “wall time”… time that corresponds to a calendar date/time. These clocks suffer from the follow limitations:
- They have a low resolution: “High-performance” timing, by my definition, requires clock resolutions into the microseconds or better.
- They can jump forwards and backwards in time: Computer clocks all tick at slightly different rates, which causes the time to drift. Most systems have NTP enabled which periodically adjusts the system clock to keep them in sync with “actual” time. The adjustment can cause the clock to suddenly jump forward (artificially inflating your timing numbers) or jump backwards (causing your timing calculations to go negative or hugely positive).
For interval timing, all that’s needed for a clock is a simple counter that increments at a stable rate. For high-performance timing, the rate this counter increments should be high. A related constraint is that the counter must be monotonic (can never “tick” backwards… ever). The counter may overflow and wrap back to 0, but using unsigned math in your timing calculations can compensate for that (see example below).
Something to note: since we are usually measuring short durations, the drift of the clock is so small that we aren’t concerned by it (what matters is the drift between successive reads, not total drift over time).
Continue reading »
Being a parent now, I found this commercial pretty funny.







