Updating autoconf on OS 10.6.8

These instructions were copied from http://www.mattvsworld.com/blog/2010/02/install-the-latest-autoconf-and-automake-on-mac-os-10-6 and then updated so that the version numbers are much more recent ones.

Make sure that /usr/local/bin is in your $/.profile file in your path variable!

Make the two following sections of commands into 2 scripts.

#!/bin/bash
curl -O http://mirrors.kernel.org/gnu/m4/m4-1.4.16.tar.gz
tar -xzvf m4-1.4.16.tar.gz
cd m4-1.4.16
./configure --prefix=/usr/local
make
sudo make install
cd ..
curl -O http://mirrors.kernel.org/gnu/autoconf/autoconf-2.69.tar.gz
tar -xzvf autoconf-2.69.tar.gz
cd autoconf-2.69
./configure --prefix=/usr/local
make
sudo make install
cd ..


#!/bin/bash
curl -O http://mirrors.kernel.org/gnu/automake/automake-1.12.tar.gz
tar xzvf automake-1.12.tar.gz
cd automake-1.12
./configure --prefix=/usr/local
make
sudo make install
cd ..
curl -O http://mirrors.kernel.org/gnu/libtool/libtool-2.4.tar.gz
tar xzvf libtool-2.4.tar.gz
cd libtool-2.4
./configure --prefix=/usr/local
make
sudo make install

Run the first script, then open a new terminal window, then run the second script.
 You may have to type in your password when it hits the sudo steps.

This should update all of those tools to the newer versions.

Follow-up discussion of 0.2

I forgot to mention that there are a bunch of things left undone in version 0.2.
Leaving aside the whole thing about merging with other people's parsers, I haven't done the following yet:

• Get the timing of the previous cue to the current one so we'll know if this one violates the rules surrounding such things
• I left off at parsing the cue settings. Need to continue working on implementing that and the rest of the spec. This is probably the biggest item on the list, helpfully hidden in the middle.
• Add comments indicating sections implemented and the dates the sections were accessed to that future changes can be detected
• Allocate memory for the cue identifier and stick it in the cue. Right now we just don't do that because I judged it unsafe to write while tired
• Get rid of old webvtt_parse_cue when it's no longer needed

Webvtt C Parser version 0.2, mostly

I've been working on implementing a C parser for the webvtt standard.
The parser can be found at https://github.com/dperit/webvtt/tree/cparser
and the standard can be found at http://dev.w3.org/html5/webvtt/

Because I'm building very exacting code for a web browser that will be handling input from malicious attackers I chose to write the code very deliberately. This involved implementing each of the small steps in the standard in a different function, where each function only requires that the offset + buffer pointer in the parser struct point to the start of the text it is concerned with. It should be easy to update the code when parts of the spec changes because only the function that is concerned with that part of the spec will need to be updated and the rest of them will continue functioning independently.

Paired with the above method for splitting up the problem are the parser struct and the parse function.
The parser struct stores the buffer location, offset, and length, as well as the reached end of buffer and invalid webvtt flags. It also stores a parser state, which uses values declared in the state enum to indicate what step the parser is currently on.
The parse function loops until the parser struct indicates that it has reached the end of the buffer or has found an invalid part of the buffer. Inside of the loop is a switch statement for the parser state which executes the function associated with each step of the standard and, if successful, advances the state by one step.

The result of this is that the program is a series of small self contained steps, each responsible for advancing the offset and implementing a specific section of the spec. If something goes wrong it should be easy to trace the problem back to the source.

Another challenge in implementing this spec was that it's possible to receive incomplete buffers, where the parser could run out of buffer partway through a function. Splitting the functions into small steps deals with that effectively with the aid of the following conventions:

1. If the parser runs out of buffer in a function, return the offset to a point where, if the current function is run again, it will continue parsing properly. This could return the offset to the start of a block for the cue times or not chang it at all for proceeding through the blocks of "almost anything goes" text, which intended for comments.
2. If we hit something that indicates the thing being parsed is invalid, then return immediately without changing the offset. This means that the parser struct will always point to whatever the invalid part was, which is useful for debugging.
3. You shouldn't read from the buffer very much ahead of where the offset is pointing to or else it'll be unclear about what it broke on

With the way things are now if you pass the parser struct (with additional data in the buffer) and the first cue (if you have one) (as well as, optionally, the last) back into the parser function it'll pick up right where you left off, which seems to solve the "you could run out of data at any time but the webvtt file might still be valid" problem nicely. Or, if you never come back to it, you'll still have any cues it retrieved originally.

I'm not confident of my ability to edit this post to a point where it makes sense right now if it doesn't already, so I'm going to go ahead and hit the publish button and hope for the best.

Building firefox

First attempt was to clone the repo at Seneca on the wireless connection. This failed because the wireless is slow and I didn't have the time to sit around and wait for it to download.
So then I did it at home. I forked and cloned the mozilla-central repo and then started doing the build pre-requisite steps.

I entered the command to update macports (a very old version of which was on my machine) and then waited while it did its thing. Then it refused to update properly because it had a really old version of ncurses and apparently it switched development branches or something at some point and couldn't autoupdate it. So I decided not to bother changing that.

So I used homebrew instead to do the prerequisites and, after removing macports, it worked really well.

Then the compilation failed because I had xcode 3 installed on my machine and it needed xcode 4. Which I can't get because it requires that you have OSX 10.7 installed. Which I can't do because my mac has a 32 bit processor and 10.7 requires 64 bits.

Not seeing any way around this I decided to do it on my windows machine instead. I installed visual studio 2010, the directx sdk, and then the mozilla build package, and used git to clone my fork of mozilla-central. I then attempted to build it and ran into an error.

The error was "This source tree appears to have windows-style line endings. To convert it to Unix-style line endings, run "python mozilla/build/wind32/mozilla-dos2unix.py".
The problem is that that file doesn't exist.

So I fixed the error by following the instructions at help.github.com/articles/dealing-with-line-endings to change the git global configuration to unix style endings and then reset the working tree. This time it compiled without any problems, and it took around an hour to finish. Here is a screenshot of the result.

 

I made a game!

For the past few weeks I've been given the opportunity to spend my time on whatever I want to so long as it's shippable by the end of the month. So I decided to make a game using gladiusjs!

I have two reasons for doing so, the first being that making a game would allow me to see flaws/missing features in the engine that you really can't see unless you are forced to use it. This is called eating your own dogfood, and is a very important process for anyone shipping software that is going to be used by other people. The second reason is that it would provide a great example that other people can hack on or build off of to make their own game- anyone can just copy it and then skip whatever setup steps are required to make the engine work properly. I feel that this would make creating your own game as a new developer a much easier process.

You can see the game on the gallery page at dperit.github.com. Just click on the tank example to play it, or go directly to http://dperit.github.com/gladius/examples/tank/index.html

I found a number of ways to improve the engine while I was working with it. Here is a little change log detailing the enhancements I've made. It is rather jargon-y

Transform

• Added a directionToLocal function that takes a vector3 direction in the world frame and returns that vector3 direction in the local transform's frame of reference
• Added a transformToLocal function that takes a transform and returns the vector3 location of that transform in the current transform's frame of reference
• Added a toWorldPoint function that returns the vector3 location of this transform in the world's frame of reference

 Box2D

• Exposed the setAngularVelocity and setLinearVelocity functions of bodies
• Added a dimension mapping feature where you can specify the dimensions that you want box2D to map to in a 3D world. So you can have it map to XY (default), XZ, or ZY. This is done by giving arguments to the resolver when you are initializing the extension-there is code near the top of the tank example that maps the physics to the XZ plane
• Exposed the bullet property of the body definition, which indicates that this dynamic body is expected to collide with other dynamic bodies and should be monitored more closely for collisions as a result
• Exposed the friction, restitution (bounciness), and collision filter options for fixture definition. Collision filtering allows you to set, through bitmasks, the categories of objects that a given fixture will and will not collide with. There's an example of this being used in tank.js on line 286
• Changed boxshape so that the size you give it will match up exactly to size in transform
• Added a circleshape which makes a circle

General

•   Added a procedural sphere loader which allows you to put spheres in your game. Goes well with circleshape in Box2D

At the moment these changes can only be seen in various branches on my forks of gladius, gladius-core, and gladius-box2d.

Working out of Mozilla's offices

I've spent 2 days working at Mozilla Toronto's offices (MoTo) and I've found it to be a really effective space for getting work done.

The building itself is secure, meaning that I don't have to pay any attention to preventing my stuff from being stolen, and (unlike CDOT) I also don't have to ask wanderers what they are doing here or direct them to a prof's office.

I like the aesthetic of the office- wood flooring, support beams, and ceiling combined with brick exterior walls creates an atmosphere that ranges from cozy in the lounge area to professional in the meeting rooms.

There are many places available where I can work. A number of meeting rooms with sliding glass doors are available on a first come, first serve basis. These can be grabbed to do large meetings, pair programming, or even just solo work when you need absolute quiet. There's also a small lounge area, a kitchen, and a small dining area.

Supplies are quite plentiful. All of the spaces are equipped with Apple power adapters, so that I don't even have to unplug my adapter to move to a new space as wanted/needed. The entire office is also blanketed with wireless internet access that doesn't have any restrictions on it that have impacted my work ability. It's also clear that Mozilla employees have high priority placed on the supplies and equipment that they need, and there are resources in place to get those things to them quickly and reliably.

There's also a lot of food and snacks available. Various fruits and nuts, a wall of snacks, a cooler full of drinks, and (I'm sure) more are freely obtainable.

The combined effect of the things I've noted has been to remove obstacles from my workflow and substantially reduce the number of non-software development related tasks I have to think about in my day.
Aside from getting lunch I don't have to worry about making sure that I have a steady supply of food available to keep me thinking effectively throughout the day.
If I want to move and work at a new location I don't have to spend time unplugging my laptop and unlocking it and then dragging it plus my backpack with me to the new spot.
If I need to have a remote or in person meeting or do pair programming I don't have to take the time to reserve a meeting room or find someone with keys to unlock an office, nor do I have to manually reconfigure my network connection for the new wired connection because I can't rely on the wireless.
I don't have to spend time thinking about the security of my belongings because the doors to the office close and lock automatically, always.
The office environment also makes me feel valued and trusted, things that I want to return to the company in the form of lots of hard work, and I'm not even employed by them!

This has all made working with Mozilla on the gladius engine a very productive experience. I should mention that we're always looking for more people to contribute to or use the project- please don't hesitate to hop into #games on irc.mozilla.org and talk to dperit or ack or dmose about gladius!

I made a game!

I made a game! It's called Uprooted, and is part of the set of 4 Turtlesback games made for Native Earth by me and some other people. It's written in processing, and ported onto the web browser using processing.js
You can play it at http://turtlesback.ca/creationgames/
Enjoy!