Could not load file or assembly 'Spladug.Project.Tests' or one of 
its dependencies. The system cannot find the file specified.

After poking around for a while, I discovered that my problem stemmed from being on Windows x64. XNA’s libraries are 32-bit only, which means that despite being .NET, applications (and class libraries) built on XNA are always 32-bit. As described in a post about testing 32-bit applications on Windows x64, you have to configure NUnit to run in 32-bit mode as well to be able to load the test assembly.

To do this, simply run the following command in a console with sufficient permissions and with filenames tweaked as necessary:

C:\>corflags "C:\Program Files (x86)\NUnit 2.5\net-2.0\nunit.exe" /32BIT+

corflags is a utility that comes with the .NET Framework SDK. See the documentation for .NET Framework Tools for more details.

A recent question on Stack Overflow asked why locked files can be deleted in Linux, but not Windows. As the answer states, it’s because of the underlying nature of inodes in the Unix filesystem architecture.

Background

Files in Unix are stored in an inode, which contains all the metadata for the file. Paths on the filesystem then link to the inode that contains the actual file data. As a result, “deleting” a file from the filesystem is really just removing a link to and decrementing a reference count for an inode. An inode that is still opened by a running process, but unlinked from everywhere on the filesystem, will continue to exist until the process closes and the reference count drops to zero.

Temporary Files

In my answer to the question, I mentioned that Unix programs use this behavior explicitly to make temporary files that a) don’t clutter up the file system, and b) are more secure. In the comments for the question, I was asked for examples of this usage. I had learned this tidbit of trivia during an operating systems class in college, and had forgotten the specifics, so I decided to look it up.

glibc

I started poking around looking for an explicit example of this usage, and found out that the behavior is built directly into the glibc. Specifically, the tmpfile function, which creates a temporary file and opens a corresponding stream automatically unlinks the file internally! Here is the psuedocode for the tmpfile function in glibc 2.7, with setup and error-checking snipped for clarity:

FILE *tmpfile (void)
{
  char buf[FILENAME_MAX];
  int fd;
  FILE *f;
 
  /* get a new filename and open it  */
  fd = __gen_tempname(buf);
 
  /* Note that this relies on the Unix semantics that
     a file is not really removed until it is closed.  */
  (void) __unlink (buf);
 
  /* make a FILE* for the file */
  f = __fdopen(fd, "w+b");
 
  return f;
}

So the tmpfile function automatically takes advantage of this behavior and unlinks the inode after opening it.

Test Program

To see this in action, I wrote a small test program in C:

#include <stdio.h>
#include <unistd.h>
#include <sys/stat.h>
 
int main(int argc, char** argv)
{
    FILE *temp;
    struct stat buffer;
    char line[100];
    int fd;
 
    /* open a temporary file and  figure out its inode */
    temp = tmpfile();
    fd = fileno(temp);
    fstat(fd, &#038;buffer);
    printf("inode: %d\n", buffer.st_ino);
 
    /* wait */
    fgets(line, 100, stdin);
 
    return 0;
}

Running the program spits out an inode number then waits around with the file held open. Searching for filenames pointing to that inode returns nothing:

[neil /]$ find -inum 1221 2> /dev/null
[neil /]$

So it would seem that my vague memory from operating systems class was correct; temporary files can be created, opened, and unlinked and the facilities to do this are built in to the system libraries themselves.

The dreaded XHTML

For a while, it seemed that XHTML was going to be the future of the web, and so everyone pushed towards it. Unfortunately, XHTML 2.0 has been a long time coming and the end is not in sight. With the recent progress on HTML 5 and the backlash against serving XHTML as text/html things seem to be swinging back in favor of HTML.

I wanted to make my site output valid, semantic, HTML 4.01 Strict. This seems like a reasonable goal to me. However, WordPress isn’t exactly too happy about that. As part of the push towards XHTML, WordPress, like many other CMSs converted to XHTML 1.0 at the exclusion of HTML. Generally, all this means is that those silly "one-off" tags like <br> and <link> get a self-closing / inserted in to them: <br />. Of course, this is invalid HTML 4.

Poking around in the WordPress source to see if it would be an easy change I realised that the developers had directly echo’d out the various snippets of (X)HTML whenever they needed it. Despite their highly flexible plugin API, only one of the four invalid tags that were affecting every page of my site was designed to be flexible in the output it generated.

According to the official WordPress documentation the only way to switch WordPress from XHTML to HTML is a plugin that filters all of the software’s output through a regular expression. What a hack! Oh well, that’s what I’ve ended up using.

Not wanting to complain about problems without offering a solution, I’ll put this forward: run all markup output through a single class that does it in one place. This not only affords an easy way to switch between HTML and XHTML modes (not to mention whatever may exist in the future!), but helps maintain the DRY principle. A simple class not unlike ASP.NET’s HtmlTextWriter would do the trick admirably.

I love it!

I don’t mean to sound jaded after all of this; I love WordPress! I really do. After maintaining my site without a CMS for years and then trying to get Drupal set up as a blog (nothing wrong with Drupal, it just felt too general for blogging), WordPress has been a breeze. The install was painless, the documentation excellent, and the interface slick.

The purpose of this code is to construct a regular polygon with n sides (though it doesn’t really make sense with n < 3 sides). When given the number of sides and the length (in “units” of each side), the code will generate a sequence of points starting at the origin, and proceeding counter-clockwise around the polygon.

One of the most helpful quantities when constructing a regular polygon is the exterior angle.

import math
 
def polygon(number_of_sides, side_length = 10):
    # the exterior angle is the difference in angle
    # between sides of the polygon and is the same
    # for every side of a simple polygon
    exterior_angle = 2. * math.pi / number_of_sides
 
    point = (0, 0)
    angle = 0.
 
    yield point
 
    for i in xrange(number_of_sides - 1):
        point = (point[0] + side_length * math.cos(angle),
                 point[1] + side_length * math.sin(angle))
 
        angle += exterior_angle
 
        yield point

To use this, just iterate over the result of the function:

for point in polygon(5):
    do_something(point)

or if you just want a list of points:

# use a list comprehension
[pt for pt in polygon(4)]
 
# which results in:
[(0, 0), (10.0, 0.0), (10.0, 10.0), (0.0, 10.000000000000002)]