Corona SDK – build automation

In my experience, Corona SDK build process has been a source of pain. It feels like it has been an afterthought thrown in on top of the authorization and remote build system. For those that don’t know, building the code takes place on Ansca’s servers and the process follows something along the lines of:

  1. Edit and save the source files
  2. Launch or keep the Corona simulator open
  3. Go to File -> Build -> Android (or press , Cmd + shift + b)
  4. Fill in Application name, Version, Package, Keystore, Key alias and save path settings
  5. Press build button

Repeat builds do save some time by remembering typed in values, but it’s a far cry from a one click build I would like have. Ideally, the application should be launched on the device at the end of the sequence.

To achieve this, I had to resort to using SikuliGUI automation and little bit of Python scripting. Following gist contains the code: . Variables in the beginning point to the location of your project, terminal application and so on. Application specific data like name and version should be set there as well. The script will use Android adb tool to install and run the application at the end.

Paths inside the script are OSX specific, but changing them to work on Windows should be very easy.

What you will need: Python, Sikuli and the above gist. Here is a ready zip archive of the script and screen captures required to make it work:

Here it is in action building the sample Clock application:


Corona SDK – build automation from Arek Bochinski on Vimeo.


DropFuse – a file-system

DropFuse is a FUSE based file-system for linked folders.

Once you have a link to a shared folder, use it with this software to grab the files to your local

storage by using a regular file browser.

Source code is located here

How-to video:

DropFuse How-to from Arek Bochinski on Vimeo.

Reverse complement FASTA benchmark

FASTA format is used in bioinformatics to describe peptide sequences or nucleic acid sequences.

One of the benchmarks at the computer languages game requires that a program parse a ‘stdin’ redirected input of these FASTA formated sequences and print the content of the sequence in reverse order. Each character in the sequence should also be complemented according to this translation table:

code  meaning   complement

A    A                   T
C    C                   G
G    G                   C
T/U  T                   A
M    A or C              K
R    A or G              Y
W    A or T              W
S    C or G              S
Y    C or T              R
K    G or T              M
V    A or C or G         B
H    A or C or T         D
D    A or G or T         H
B    C or G or T         V
N    G or A or T or C    N


Each sequence contains a header with an id and description. These lines are printed ‘as is’ .


  • String reversal
  • Translation table substitution
  • Input handling and memory allocation

String Reversal

Sequences are reversed using a bitwise XOR and without using a temporary character or string buffers.

Operations are performed in a loop where forward is the first index and end is the last index in the sequence.


Translation table substitution

A small character array of complement values is created and accessed with the integer value of the source character matching to arrays index. For example:


Buffer at index end will receive a character at index ‘buffer[end]‘ from translation table array FtoCOMP. Index ‘buffer[end]’ translated to an integer , will point to a desired complement . This speeds up the process of substitution and allows for very fast array index notation.

Input handling

The requirement to handle input one line at a time corresponds quite well to the translation procedure. In pseudo-code,

  • process one line at a time
  • for each sequence , print header line, reverse the sequence, translate it into its complement and print it out

Only one buffer is used as a destination for reading input. Beginning pointer where each line is placed is dictated by moving a pointer through a character array. Once a line is read in, we check if it is the last line in a sequence by peeking into the input stream. If it is , it is processed according to above instructions and beginning pointer where the next line is placed is reset to 0.

These functions are called for each line N in the input stream:

fgets_unlocked, fgetc_unlocked.

These functions are called for each line that’s not a header line:

ungetc, strlen.

Other functions are called only at the end of a sequence and do not approach N runtime. This version written in C language has been compiled and tested using kernel 2.6.24 with GCC 4.2.3 .

Compile command:

gcc -Wall -O3 -fomit-frame-pointer revc.c -o revc.gcc_run

Source code is located here:

Atoi() or not to Atoi()

Update: May 13th, 2008

My solution has been accepted and placed in the interesting alternative category. A bitter-sweet victory considering my program as tested by their standards is the fastest C language entry . It is still a small honor to be recognized and to know that my entry shaved off almost 30% off the next fastest C program.

Let’s see how the FASTA benchmark program stacks up in the next few days.


see it here:

The computer language benchmarks game at matches up a fundamental processing task or algorithm in a variety of programming languages. One benchmark called ‘sumfile’ has the following requirements:

  • read integers from stdin, one line at a time
  • print the sum of those integers

It is based on this icon program:

procedure main(argv)
 write (sum)

The C language entry topped at 6th and 7th place. Surprising as it was, a Java 6 version came in second with more than a second shaved off the total CPU running time.

The task for all of these is to read a flat file containing one integer per line, add the integer to the total and print out the sum at the end. Three versions of test files containing 1,000, 11,000 and 21,000 lines are used. While there could be more interesting ways to tackle this task, it’s trivial and simple demands warranted a quick look.

The fastest C program used these function calls per each line in the file:

fgets_unlocked() , atoi() and a += operator to sum up the total. It seems that either one of these functions could be improved on, but since line-by-line reading is a strict requirement thus leaving the atoi function open to critique.

This following function will return an integer given a string. It handles positive and negative number strings.

int matoi(char *c) {
int res = 0,n=1;
while (*c >= '0' && *c <= '9')
res = res * 10 + *c++ - '0';
return res*n;


When compared to the standard atoi() function and parsing 500,000 lines of integers, this version on a 2.4 GHz Core2Duo performed 60% better . It’s simplicity is also it’s weakness as the matoi() function is designed to handle proper input. Perfect for a situation where input is controlled.

Original benchmark entry was modified with timing capture and the addition of matoi() function. Header contains any previous entry owners and information.

Archive with source code :

CSC209 – build . a simple make-like tool

Assignment 1 for CSC209 course at University of Toronto in Software Tools and Systems Programming


In this assignment a student is required to write a program in Bourne shell that performs some of the same operations that make does . A simpler file format for a build file is specified , which does not follow all rules of the make program .

Build file format

There are 4 types of valid lines in a build file:

  1. A blank line. I.e., a line containing nothing but whitespace.
  2. A line whose first character is # which indicates that the remainder of the line is a comment.
  3. A line whose first character is an @ followed by a space, and then followed by one or more words separated by a single space. This type of line marks the beginning of a build rule. The @ is ignored. The first word in the sequence is the target of the rule, and the remaining words, if any, are the prerequisites for the rule.
  4. Other lines are considered action lines which should be executable statements.

In example:
#Comment line
@target prerequisite1 prerequisite2
action with arguments

Functionality and Implementation

build program will take one or two arguments. The first argument is the target that you want to build. The second argument is the name of the build file to the program will read. If the second argument is not present, the program will try to read a file in the current working directory called buildfile.


  1. Read the build file looking for the appropriate rule. If found:
  2. Update prerequisites. (as with make, each prerequisite corresponds to a target in the buildfile, so we might need to execute another rule to ensure that a prerequisite is up to date.)
  3. If the target is a file and has been modified more recently than all of its prerequisites, then the actions are not executed.
  4. If the target is not a file, or any of the prerequisites are newer than the target, then the rule’s actions are executed.


  • If a rule has no prerequisites, then the rule will always be executed when it is encountered. Note that this differs from make where a rule with no prerequisites is only executed if it is called explicitly.
  • You don’t need to handle recursive targets and prerequisites.

The build process will likely want to call the build program from within the build program. (Recursion comes in many forms.) The best way to do this is to make sure that build is in a directory in the PATH variable.


Another obvious use for shell scripts is to automate testing programs. We will also write a shell script called testbuild that will run several tests of the build program.

The testbuild program will run at least 3 different test cases that test different parts of the program. We will also need to include one or more build files and possibly some other files. The touch (see “man touch”) command will come in quite handy when we want to change a file’s modification time automatically.

Zip archive can be obtained here:

OrangeStats – Team Fortress 2 log file parser

Orange Stats is a Python script that will parse Team Fortress 2 server log files in order to aggregate the data for later use. Regular expressions capture events as written to the log file by the game server. Each event has a corresponding structure containing various information such as : date , time, victim, aggressor, weapon type, event type and other event specific information. Team Fortress 2 adds a vast array of new gameplay and class specific events which extend the Half-Life 2 log file structure. More information can be obtained from Valve Developer Community here.

Orange Stats will insert extracted data into a database for later use by a web front-end or a Team Fortress 2 in-game plugin. The table schema is a bare bones implementation that supports CP map style gameplay. Design requirements focused on simplicity and light weight code implementation. Following game events are captured and categorized :

  • Connect
  • Disconnect
  • Map load
  • Join Team
  • Point Capture
  • Point Capture Block
  • Pick Character Class
  • Player Death
  • Player Assist
  • Revenge
  • Built Object
  • Destroy Object
  • Domination
  • Steam user events ( user ticket validation )

Character class specific data extraction works for events such as:

  • Sapper events, Uber charge events, Engineer object events

A web front-end will be uploaded along with the database schema as soon as possible. Orange Stats working demo can be viewed here . Web front-end features a slight AJAX touch through PrototypeJS .

Back end runs a light PHP script.

Python script is located here .

Unreal Tournament 3 resource package explorer!

Upkextract is a very early release of a simple utility that can open and parse the binary .upk packages shipped with Unreal Tournament 3. These packages are designed to be used by the game engine as well as by Unreal Editor. Contents within these archive varies from textures to sounds and shaders.

Current release of Upkextract can parse a UT3 resource file and find any sounds contained inside it. Unreal Tournament 3 uses Ogg Vorbis files for sound effects and encodes them using’s libVorbis aoTuvb5 library.

Sound file metrics such as gain, channels and others are not extracted in this release.

Archive contains the executable and a sample resource file from UT3.