Hello, World!

Hello, I am a computer science student currently attending UALR, this page is a listing of some of my projects.

To contact me, use my email, my Google+ at +ConnorTaffe, my LinkedIn, or just have a browse through my resume and my open source projects on github.

These projects represent just a few of my interests. Recently I've pursued lower level coding in C, C++, and (x86/x86_64) assembly languages for projects involving bootable operating system-style programs and compilers/interpreters. Note that many of these projects were educational experiences which represent first delves into their respective fields.


The IEEE VR Talk repository contains the slides my colleagues and I at UALR's Emerging Analytic Center presented at 2015's IEEE Virtual Reality conference in Arles, France. Under Dr. Carolina Cruz-Niera, we presented a series of slides outlining how to integrate Vuforia, OpenCV, and Unity to build Virtual and Augmented reality applications with the Unity game engine and interface.

The talk itself is written using the reveal.js framework and markdown for content representation.

The talk and materials can be found here.


Lispy is a lisp-like language interpreter written in Python. The language is specifically known as Basilisk, and is of my own devising.

The repository includes sample functions in std/math, including math:!. To import them, just do:

The code for the factorial (!) function is this: (: math:! (@ (n) (if n 1 (* n (self (- n 1)))))). It recursively checks if n is 1, multiplying n by the result of recursing with n - 1.

The evalutation portion of the interpreter is written monadically, returning a tuple containing a function pointer and the arguments to that function for each function. This way, the evaluator recurses only once for every source recursion.

It does nice error reporting by saving the line and character location for each token and printing said info when an error is found. In this particular interpreter, I used a coroutine-based model without using coroutines by having each piece save state in its own structure and on subsequent calling pick up where it left off.


The idea behind the CSS Zen challenge is to style a page with as much functionality as CSS can provide. My attempt at this challenge can be seen here, you can find the repo with my css code here.


Mesher is a client-side web application for rendering, editing, and saving 3D printable stls. It uses the newest web technologies and libraries such as THREE.js, JQuery, and Bootstrap.

It is a modular applicaton written in JS, with support for multiple models, views, and projects. Each object stores its state in some data structure, allowing many instances of each to exist simultaneosly. Although not currently used, the api can support tabbed editor panes for each model. Multiple models on the same canvas are well supported and the undo-redo stack has been written to accomidate these states.

Why not check out the live demo, here.


bf is a just-in-time (jit) compiler for the "BrainFuck" langauge. It uses a similar approach in the lexer-parser, using a concurrent, threaded approach which uses a mutex'd queue to pass tokens from the lexer to the evaluator. For this particular compiler, I did not write a tree-based evaluator, but an jit component.

The jit compiler produces 64-bit instructions which it writes to an executable page, executing each full statement, which modifies some allocated memory. The jit uses one-byte operation isntructions, and uses one-byte registers for these operations, but keeps the current memory pointer in rsi for quick access and modification. At the end of each execution, the state is saved, moving rsi into a memory location in the jit structure. At the beginning of the next statement execution, this state is restored, keeping a persistent state for every execution.

The following is a statement in BrainFuck; it adds 4, moves left 2, and adds 4:

The program reports the exec page contains the following insructions: exec: { 0x48, 0xbe, 0x0, 0x20, 0xf9, 0x8, 0x1, 0x0, 0x0, 0x0, 0x80, 0x6, 0x4, 0x48, 0x83, 0xc6, 0x2, 0x80, 0x6, 0x4, 0x48, 0x89, 0xf0, 0x48, 0xa3, 0xc8, 0x4d, 0x40, 0x68, 0xba, 0x7f, 0x0, 0x0, 0xc3 }; and the following memory state after execution: mem: { 4, 0, 4, 0, 0 }[2].

This means that index 0 and 2 were increment 4 times, and that the last indice (position of rsi) is 2.

The following is some dissassembly output from the above executable instructions:


utf8 is a utf-8 parser written in C. It has a useful interface featuring utf8_rune utf8_encode(const int32_t cp) and int32_t utf8_decode(const utf8_rune rune) functions for encoding and decoding runes. There is also a utf8_parser and related functions for parsing utf-8 characters from a string, as well as a validation function.

Safety was not taken lightly in utf8 and several error values exist for types. int32_t's treated as code-points are a maximum of 21 bits in length, opening all negative numbers for error values, so utf8_CP_INVALID and utf8_CP_ERROR are used to indicate invalid runes (in conversion) and other program errors. With runes, there are the values 0xf5 to 0xff are invalid, and are thusly used for rune errors with the constants utf8_RUNE_INVALID, utf8_RUNE_ERROR, and utf8_RUNE_SHORT. These are used to indicate the same errors as the associated codepoint errors, except that SHORT is used to indicate a rune cannot be lexed for lack of length (only returned from functions doing this).

I took some pains to write complete comments so the source should be quite well documented. It complies with RFC 3629 as much as possible, and checks for and handles errors properly. Compiling with make test invokes the test program, also written in C, which does a series of calls and stress tests, reporting if anything failed with plenty of debugging information. If a test failed, make will fail.

Here's some example code using utf8:


utf8plus is a C++ wrapper for the utf8 repo. It provides a utf8 namespace and a rune class.

The rune class has two static instantiator methods, encode and get. Encode takes an int32_t codepoint and encodes it to a rune, returning the instantiated rune (created using rune's constructor, which takes an int32_t encoded utf8). Get takes a void * to a memory location and a size_t which conveys the size, a utf8 rune is lexed from the beginning of this memory, if the memory is too short, an exception of type rune::exception with a code attribute of type rune::exception::errcode and value SHORT All rune functions will use this exception and either raise SHORT or INVALID. If something was interpretted as an utf8_CP_ERROR or utf8_RUNE_ERROR in the utf8 package, a logic_error will be thrown here.

Rune class methods include decode, which returns an int32_t whose value is a code-point; isvalid which returns a bool indicating whether the rune is a valid utf-8 rune; and len, which returns the length of the rune in bytes.

Here's a simple translation of the first example:

This summary does not do justice to either, so check out the code for utf8 and utf8plus.


lex is an implementation of a monadic state machine framework written in C. It has a lex structure with related methods and is thusly object-oriented. This code allows for the running of a state-machine which keeps track of state via function pointers. These function pointers are called until one or more tokens are avaliable on the queue, then one is returned. On subsequent calls, the queue is checked for tokens, and if it is empty, the state machine is run.

The ideas behind my lexer come from a talk on the go lexer, that video can be found here.

shunting yard

shunting yard is a program that parses an infix expression and returns the result using Dijkstra's shunting yard algrorithm. This program was a test of building with the gyp build system.