Category Archives: Programming

I have been working on getting our new Mac Mini (macmini4,1) machines ready to become Mac OS X 10.6 testing machines.  One of the last things needed before I start testing on a larger scale is a program to set the resolution on the command line.  We need this because our tests depend on having a specific resolution set.  Even if there was no dependency on a specific resolution, the GPU could perform differently depending on the size of the display it is working on.  As well, we run these minis without a real display so its really important that we have active confirmation that the desired resolution is set.

Previously, we used cscreen.  This is a utility that has fallen off the internet and was only ever released as a PowerPC binary.  I needed to decide between finding a replacement for cscreen and installing Rosetta.  While we currently have Rosetta on our testing slaves, I didn’t want us to depend on this.  This is because partly because I just don’t think its good hygiene and partly because I want to prepare for OS X 10.7, where Rosetta has been removed.  I searched the internet for a tool to do this, and sadly, there was nothing that fit the bill.  I tried alternatives like modifying the com.apple.Boot.plist file to specify resolution, but it didn’t work.  I also found some binary plist files that I could have edited and might have worked, but it seemed like a really flaky solution that would break *all* *the* *time*.  I decided that I’d have to write something to do this.

I did find a program that looked like it would be a good starting point, however, this program lacked any error checking.  Furthermore, when I investigated the APIs used, it looked like many of the important APIs were deprecated in 10.6 and would not be available in 10.7.  One particularly annoying deprecation was CGDisplayBestModeForParameters, because it takes the exact data I have (height, width and bit depth) and picked the best mode available.  In the end, I think I have a better solution that iterates through all modes and picks one that matches my inputs exactly.  I also noticed that CGDisplayBestModeForParameters doesn’t always return a mode that matches exactly to what was requestion, though, it does have facilities to deal with this case.

Alas, I started writing an application called screenresolution.  This program can be used to query the current and available resolutions as well as setting the resolution on one or more screens attached to the system.  This is my first C project in quite some time and I was never a C rockstar to begin with.  If you have a desire for Mozilla testing infrastructure to not suck and know C and CoreGraphics please slide on over to the source to check for issues!  I know that I could organize the code better and write a better command line interface, but I don’t think the benefits of that outweigh the cost of waiting even longer for these new machines.

I have posted thecode on my github account and have licensed it with the GPL v2 license in hopes that no one ever go through the search engine hell that was Friday Aug 26, 2011.  Below is a build of verison 1.3.  Why not 1.0?  Even though I wrote a test for the program, I neglected to actually run it. Multiple times   Once I started to actually run the tests, I started finding issues before bumping version numbers, gasp!

screenresolution-1.3.dmg

Update: Thanks Josh Aas and Richard Newman for reviewing my code and the great suggestions! I have a new version posted
screenresolution-1.4.dmg

Because this is a command line application, I recorded a video of my machine running the test suite.

We are working on getting our infrastructure up to speed for Maemo 5 and Maemo 5 QT builds. A critical part of Maemo5 building is the scratchbox. This is a toolkit that Nokia uses to make development on for their linux based phones easier. We have enough linux build slaves in production that it is impractical to deploy scratchbox by hand on each machine. Scratchbox also does internet package downloads which means that we could get different packages each time we try to install the scratchbox. We already have a fairly old version of scratchbox which is set up with the Chinook sdk that we have used for doing our Maemo builds thus far. Originally I was under the impression that we were going to need to have 2 totally seperate scratchbox installations but thanks to Doug T. for showing me how to upgrade our existing scratchbox 4 installation to scratchbox 5.

My concern with this upgrade, however, was that files outside the /builds/scratchbox directory were going to be touched. I wanted to be thorough so I did an experiment. I ran find -mount -type f -exec openssl md5 '{}' \; | tee -a /file-list ; find -mount -type f -exec openssl md5 '{}' \; | tee -a /file-list before and after the scratchbox upgrade. The -mount and two different runs at our two mountpoints was to ensure that we didn’t hash things like the /dev, /proc, /sys filesystem. My original intent was to do diff file-list1 file-list2 but that resulted in showing me every single file that changed. I only wanted to know the files that changed outside of my scratchbox root directory of /builds/scratchbox. My diff was polluted by 77,000 files that resided in the scratcbox root. I figured that the best option at the time was to hack up a quick python script:

#!/usr/bin/python
#This file is a quick script to process the output of
# find / -mount -type f -exec openssl md5 '{}' \; | tee -a
import sys, os.path, re

if not len(sys.argv) == 3:
    print "purple monkey dishwasher"
    exit(1)
filename_a = sys.argv[1]
filename_b = sys.argv[2]
if not os.path.exists(filename_a) or not os.path.exists(filename_b):
    print "insert change into meter and press green button"
    exit(1)
data={}
pattern = re.compile("^MD5\((?P.*)\)= (?P.*)$")
#Get the data from A
f = open(filename_a, 'r')
for i in f.readlines():
    m = pattern.search(i)
    data[m.group('file')] = m.group('hash')
f.close()
f = open(filename_b, 'r')
sbfile = re.compile("^/builds/scratchbox") #pattern describing files to ignore
#Figure out diff to B
f = open(filename_b, 'r')
for i in f.readlines():
    m = pattern.search(i)
    if not data.has_key(m.group('file')):
        if not sbfile.search(m.group('file')):
            print 'new file - ', m.group('file')
    else:
         if not sbfile.search(m.group('file')):
             if not data[m.group('file')] == m.group('hash'):
                 print 'updated file - ', m.group('file')

This is code I have written to scratch my own itch. I am posting this as it might be useful to someone else. if you wanted to ignore a different directory you’d change sbfile = re.compile("^/builds/scratchbox") to be a pattern describing your path to ignore. If you wanted to find all things that changed over your whole partition you would remove sbfile and all sbfile checks to have a final bit of code like

#Figure out diff to B
f = open(filename_b, 'r')
for i in f.readlines():
    m = pattern.search(i)
    if not data.has_key(m.group('file')):
        print 'new file - ', m.group('file')
    else:
         if not data[m.group('file')] == m.group('hash'):
             print 'updated file - ', m.group('file')

In the end, I found that the scratchbox upgrade that I did only changed my bash_history and added some tarballs to /tmp. I am very glad that this is the case as it really simplifies our deployment of the new scratchbox!