2718.us blog » 2718.us http://2718.us/blog Miscellaneous Technological Geekery Tue, 18 May 2010 02:42:55 +0000 en hourly 1 http://wordpress.org/?v=3.0.4 MacWJ: It’s like Windows Journal for Tablet Macs http://2718.us/blog/2010/05/07/macwj-its-like-windows-journal-for-tablet-macs/ http://2718.us/blog/2010/05/07/macwj-its-like-windows-journal-for-tablet-macs/#comments Fri, 07 May 2010 09:59:44 +0000 2718.us http://2718.us/blog/?p=263 MacWJ… because there are oh-so-many tablet Macs.  There are ModBooks and there are non-Apple tablet machines running Mac OS X.  So, if you have such a device and are looking for something that provides a surface on which to draw, write, etc., with various “pens” and with the ability to save to PDF and PNG, MacWJ may be of use to you. It’s open-source under MIT license.

MacWJ requires OS X 10.5 or newer and some sort of tablet-pen input, whether a tablet-form computer or a Wacom graphics tablet or something else of that sort.  Ready-to-run recent build(s) are available on bitbucket, as well as the full source code.

]]>
http://2718.us/blog/2010/05/07/macwj-its-like-windows-journal-for-tablet-macs/feed/ 0
Simplifying the Assembly of Localizations in Xcode http://2718.us/blog/2010/04/22/simplifying-the-assembly-of-localizations-in-xcode/ http://2718.us/blog/2010/04/22/simplifying-the-assembly-of-localizations-in-xcode/#comments Thu, 22 Apr 2010 20:11:51 +0000 2718.us http://2718.us/blog/?p=254 A comment on a bitbucket fork of Murky led me to “Automatically localize your nibs when building“, which suggests a great way to automate the hard developer-side stuff in localizing in Xcode–pulling the original strings from the XIB files and putting the translated strings back in.  You absolutely should read the original blog post there, because I cannot adequately explain the big-picture part of the idea with a short quote.

My one complaint with the setup described is that the script for the “Run Script” build phase described there is a maintenance headache that I could do without.  Here’s my solution:  Create two new build targets, both of the “Shell Script” type–these are targets that just run a shell script, so they are created with only a “Run Script” build phase.  I called my two new targets “Create/Update English .strings files” and “Create/Update l10n XIBs” but you can call them whatever you want.

In the “Create/Update English .strings files” target’s “Run Script” phase, the script is:

# Create/Update English .strings files
  1. for xibFile in "$PROJECT_DIR/English.lproj/"*.xib; do
  2.  ibtool –generate-strings-file "${xibFile}.strings" "$xibFile"
  3. done
  4. exit 0

This uses ibtool to create a strings file for every XIB in the English localization (from foo.xib, foo.xib.strings will be created).

In the “Create/Update l10n XIBs” target’s “Run Script” phase, the script is:

# Create/Update l10n XIBs
  1. originalResourceDirectory="$PROJECT_DIR/English.lproj"
  2. for localizedDirectory in "$PROJECT_DIR/"*.lproj; do
  3.  if [ localizedDirectory != originalResourceDirectory ]; then
  4.   for xibFile in "${originalResourceDirectory}/"*.xib; do
  5.    xibBaseName=$(basename "${xibFile}")
  6.    ibtool –strings-file "${localizedDirectory}/${xibBaseName}.strings" \
  7.     –write "${localizedDirectory}/${xibBaseName}" \
  8.     "$xibFile"
  9.   done
  10.  fi
  11. done
  12. exit 0

This goes through every .lproj directory except English.lproj and uses ibtool to apply the .xib.strings files in those localizations to the XIB files in English.lproj.

By having these as two separate targets, they aren’t run every time I build and each part can be run on its own, on demand.  By using the power of shell scripting, I avoid having to alter the scripts for every new localization or XIB.

]]>
http://2718.us/blog/2010/04/22/simplifying-the-assembly-of-localizations-in-xcode/feed/ 0
Changing from BSD to MIT License http://2718.us/blog/2010/03/29/changing-from-bsd-to-mit-license/ http://2718.us/blog/2010/03/29/changing-from-bsd-to-mit-license/#comments Mon, 29 Mar 2010 13:56:43 +0000 2718.us http://2718.us/blog/?p=246 I’m changing the license on most (maybe all) of my active open-source projects, largely because the MIT license does not have as many blanks that have to be filled in as the New BSD license and the language is a bit simpler.  To the best of my knowledge, any rights granted under the New BSD license are also granted under the MIT license, so this is really more of a housekeeping/paperwork issue than a conceptual or substantive change.

If this is of concern for some reason, for the things that were under BSD license and no longer are, the version-controlled repositories still have older versions that are BSD-licensed.

]]>
http://2718.us/blog/2010/03/29/changing-from-bsd-to-mit-license/feed/ 0
Integrating Version Control Revisions in Mac App Version Numbers http://2718.us/blog/2010/03/22/integrating-version-control-revisions-in-mac-app-version-numbers/ http://2718.us/blog/2010/03/22/integrating-version-control-revisions-in-mac-app-version-numbers/#comments Mon, 22 Mar 2010 13:57:26 +0000 2718.us http://2718.us/blog/?p=238 When I was using Subversion for version control in working on my Mac apps in Xcode, I had come to use a build script phase to tack on the subversion revision number as the last part to the version number:

# tack the subversion revision number onto the CFBundleVersion
  1. REV=`svnversion -n "${PROJECT_DIR}"`
  2. REV=${REV/#[0-9]*:/}
  3. REV=${REV//[^0-9]/}
  4. BASE=`/usr/libexec/PlistBuddy -c "Print :CFBundleVersion" "${PROJECT_DIR}/Info.plist"`
  5. /usr/libexec/PlistBuddy -c "Set :CFBundleVersion $BASE.$REV" "${TARGET_BUILD_DIR}/${INFOPLIST_PATH}"

This takes the CFBundleVersion from the project’s Info.plist, adds a period and the subversion revision number, and injects that into the Info.plist of the built product.

When I made the move to Mercurial, I couldn’t quite do this anymore.  While subversion revision numbers are monotone increasing and consistent everywhere (they are the unique identifiers of a particular version), Mercurial’s “revision numbers” are local to a particular instance of the repository and may not match up from one instance to another.  Mercurial uses a hash as the unique identifier of a particular version, and these hexadecimal hashes are not monotone, making them unsuitable for use in CFBundleVersion.

Though it took some time, I’ve finally come to a system with Mercurial that I think is workable:

# use the number of minutes between the tip and the most recent tagged commit
  1. HG_LAST_TAG_TIMESTAMP=$(/usr/local/bin/hg log -r "$(/usr/local/bin/hg log -r '.' –template '{latesttag}' –repository "${PROJECT_DIR}|>")" –template "{date|hgdate}\n" –repository "${PROJECT_DIR}" | cut -f1 -d' ')
  2. HG_TIP_TIMESTAMP=$(/usr/local/bin/hg log -r '.' –template "{date|hgdate}\n" –repository "${PROJECT_DIR}" | cut -f1 -d' ')
  3. REV=$(( ($HG_TIP_TIMESTAMP$HG_LAST_TAG_TIMESTAMP) / 60 ))
  4. BASE=`/usr/libexec/PlistBuddy -c "Print :CFBundleVersion" "${PROJECT_DIR}/Info.plist"`
  5. /usr/libexec/PlistBuddy -c "Set :CFBundleVersion $BASE.$REV" "${TARGET_BUILD_DIR}/${INFOPLIST_PATH}"

This calculates the number of minutes between the most recent tagged ancestor of the tip and the tip itself and adds that to the CFBundleVersion.  Because it’s time-based, it is guaranteed to be monotone increasing, consistent, and unique (well, provided multiple commits don’t happen within a 1-minute span, which is safe for me).

]]>
http://2718.us/blog/2010/03/22/integrating-version-control-revisions-in-mac-app-version-numbers/feed/ 0
Converting a Google Code Project from Subversion to Mercurial http://2718.us/blog/2010/03/21/converting-a-google-code-project-from-subversion-to-mercurial/ http://2718.us/blog/2010/03/21/converting-a-google-code-project-from-subversion-to-mercurial/#comments Sun, 21 Mar 2010 15:01:33 +0000 2718.us http://2718.us/blog/?p=234 The Google Code support wiki article ConvertingSvnToHg is quite easy to follow, but there is one thing worth noting that is kind of buried in the comments.  Assuming you’re doing full history conversion, it is very useful to know that running hg convert locally is much much faster than running it on a remote SVN repository, so it is well worth using svnsync to make a local mirror of the SVN repository and then run hg convert on that.

]]>
http://2718.us/blog/2010/03/21/converting-a-google-code-project-from-subversion-to-mercurial/feed/ 0
Subversions is (on its way) Out, Mercurial is In http://2718.us/blog/2010/03/20/subversions-is-on-its-way-out-mercurial-is-in/ http://2718.us/blog/2010/03/20/subversions-is-on-its-way-out-mercurial-is-in/#comments Sat, 20 Mar 2010 14:33:24 +0000 2718.us http://2718.us/blog/?p=232 I have very happily been using Subversion since 2008.  I was quite clearly late to the version control system (VCS) party and I wish I’d known about VCS much earlier.  About 5-6 months ago, I finally gave in and tried Mercurial and hated it.  While I could kind of get my head around why I should like a distributed VCS (DVCS), I just couldn’t make the paradigm work for me.  I was pretty sure that with all the people talking about how great DVCS was, I must be doing something wrong, but that didn’t stop me from putting Mercurial back on the shelf.

A little over a month ago, I went back and played with Mercurial some more, and it just clicked.  I think it had something to do with reading the Mercurial guide, but I couldn’t really put my finger on it.  That is, until a few days ago, when I read Distributed Version Control is here to stay, baby.  Joel’s explanation of his transition to DVCS really hit on the shift in thinking that took place for me in moving to Mercurial.  Plus, it has one of the best lines I’ve ever read in a blog post:

If you are using Subversion, stop it. Just stop. Subversion = Leeches. Mercurial and Git = Antibiotics. We have better technology now.

]]>
http://2718.us/blog/2010/03/20/subversions-is-on-its-way-out-mercurial-is-in/feed/ 0
A WebView Subclass with Isolated Cookie Storage http://2718.us/blog/2010/03/11/a-webview-subclass-with-isolated-cookie-storage/ http://2718.us/blog/2010/03/11/a-webview-subclass-with-isolated-cookie-storage/#comments Thu, 11 Mar 2010 07:38:14 +0000 2718.us http://2718.us/blog/?p=227 Following the advice of Kevin Ballard on StackOverflow, I created IGIsolatedCookieWebView, a subclass of WebView that does not access or affect the system-wide shared cookie storage (shared among all WebKit apps).  Each instance of IGIsolatedCookieWebView has its own cookie storage so that, for example, multiple instances of IGIsolatedCookieWebView within the same application can be logged in to the same web site with different credentials.  IGIsolatedCookieWebView should be usable in place of WebView, except that IGIsolatedCookieWebView uses the resource load delegate, so that can’t be used by the application.  IGIsolatedCookieWebView is published under a 3-clause BSD an MIT license.

]]>
http://2718.us/blog/2010/03/11/a-webview-subclass-with-isolated-cookie-storage/feed/ 0
A Drag-Resizable Subclass of NSComboBox http://2718.us/blog/2010/03/10/a-drag-resizable-subclass-of-nscombobox/ http://2718.us/blog/2010/03/10/a-drag-resizable-subclass-of-nscombobox/#comments Wed, 10 Mar 2010 09:57:02 +0000 2718.us http://2718.us/blog/?p=223 IGResizableComboBox is a drag-resizable subclass of NSComboBox—that is, IGResizableComboBox should be usable in place of NSComboBox and it adds a small bar at the bottom of the pop-up list that can be dragged to resize the pop-up list.  IGResizableComboBox is published under a 3-clause BSD an MIT license.

It still has some quirks:

  • behavior is strange when the pop-up is above the combo box (whereas it is usually below) [fixed; when the pop-up is above the combo box, the drag-handle is at the top and the top edge moves while the bottom edge stays fixed at the combo box]
  • the formula for resetting the number of visible items after dragging occurs is not quite right [fixed; dragging now snaps to whole-item positions]
]]>
http://2718.us/blog/2010/03/10/a-drag-resizable-subclass-of-nscombobox/feed/ 0
Randomizing by Random-Comparison Sorting (Revisited) http://2718.us/blog/2010/02/24/randomizing-by-random-comparison-sorting-revisited/ http://2718.us/blog/2010/02/24/randomizing-by-random-comparison-sorting-revisited/#comments Wed, 24 Feb 2010 21:09:28 +0000 2718.us http://2718.us/blog/?p=215 Yesterday, I posted the results of my quick exploration of whether sorting the list {0,1,2,3,4} using a comparison function that randomly returns < or > (with equal probability).  My exploration was prompted by a report on the non-uniformity of the distribution of the random orderings of the browsers in Microsoft’s EU browser ballot.  I had said that it seemed likely that the distribution would vary based on the sorting algorithm used.

Today, I have data (and code) that confirms the distribution is sorting-algorithm-dependent.  For each sorting algorithm, 1,000,000 instances of the list {0,1,2,3,4} were sorted with a random comparison function and the relative frequencies (rounded to the nearest whole percent) of each number in each position were computed.

Mathematica’s Sort[]
position/number 0 1 2 3 4
first 18% 12% 12% 12% 46%
second 18% 24% 18% 18% 24%
third 20% 20% 26% 20% 12%
fourth 22% 22% 22% 28% 6%
fifth 22% 22% 22% 22% 12%
BubbleSort
position/number 0 1 2 3 4
first 36% 28% 20% 10% 6%
second 28% 32% 22% 12% 6%
third 20% 22% 32% 18% 10%
fourth 12% 12% 18% 38% 20%
fifth 6% 6% 10% 20% 60%
QuickSort (random pivot)
position/number 0 1 2 3 4
first 20% 20% 20% 20% 20%
second 20% 20% 20% 20% 20%
third 20% 20% 20% 20% 20%
fourth 20% 20% 20% 20% 20%
fifth 20% 20% 20% 20% 20%
MergeSort
position/number 0 1 2 3 4
first 24% 24% 26% 12% 12%
second 26% 24% 18% 16% 16%
third 18% 18% 22% 20% 20%
fourth 16% 16% 18% 26% 26%
fifth 16% 16% 18% 26% 26%
SelectionSort
position/number 0 1 2 3 4
first 6% 6% 12% 26% 50%
second 12% 12% 20% 32% 24%
third 20% 20% 26% 20% 12%
fourth 30% 30% 20% 12% 6%
fifth 30% 30% 20% 12% 6%

The distributions are significantly different among these sorts.  QuickSort appears to provide a uniform distribution.  I believe that this is because QuickSort will only compare a particular pair of elements once, whereas each of the other sorting algorithms may compare a given pair of elements more than once (and with a random comparison function, receive a different result from one time to the next).

Here is the Mathematica notebook I used to generate this data: Randomize by Sorting.nb.  As noted in the file, some of the code for the sorting algorithms was taken from other locations and may be/is subject to their copyrights and/or license terms (I reasonably believe that this use complies with their licenses and/or constitutes fair use.  Also, some algorithms exhibited improper behavior when trying to sort lists with duplicate entries using a normal comparison function as noted in the file, though this should have no effect on the data above.

]]>
http://2718.us/blog/2010/02/24/randomizing-by-random-comparison-sorting-revisited/feed/ 1
The EU Browser Ballot and Random Sorting http://2718.us/blog/2010/02/23/the-eu-browser-ballot-and-random-sorting/ http://2718.us/blog/2010/02/23/the-eu-browser-ballot-and-random-sorting/#comments Wed, 24 Feb 2010 02:09:44 +0000 2718.us http://2718.us/blog/?p=212 An Ars Technica “etc” post linked to a TechCrunch article (apparently based on a Slovakian article, but I didn’t look into the Slovakian article to be sure) that talks about the ordering of the browsers in Microsoft’s EU Browser Ballot not being uniformly distributed.  At a glance at the Javascript that does the randomizing of the browsers (randomly orders the top 5, and randomly orders the rest), it appears to randomize by calling the Javascript array sort with a comparison function that returns < half the time and > the other half of the time.  I believe that this is likely the underlying cause of the non-uniformity of the orderings.

The second result in a google search for “javascript sort” says:

To randomize the order of the elements within an array, what we need is the body of our sortfunction to return a number that is randomly <0, 0, or >0, irrespective to the relationship between “a” and “b”. The below will do the trick:

//Randomize the order of the array:
var myarray=[25, 8, "George", "John"]
myarray.sort(function() {return 0.5 - Math.random()}) //Array elements now scrambled

This is almost exactly the method of randomization used in the browser ballot javascript.

To test the results of this randomization technique, I applied it 1,000,000 times to the list {0,1,2,3,4} in Mathematica and tabulated the relative frequencies of each number in each position. (Rounded to the nearest whole %).

position/number 0 1 2 3 4
first 18% 12% 12% 12% 47%
second 18% 24% 18% 18% 24%
third 20% 21% 27% 20% 12%
fourth 22% 22% 22% 28% 6%
fifth 22% 22% 22% 22% 12%

At a glance, it appears that the distribution is far from uniform.  My quick attempt at re-learning how to use the Χ2 test gave a probability less than 1×10-100000 that this data matched a uniform distribution (if someone can confirm/fix that, please comment).

I used the Mathematica Sort[] command to do the sorting.  I don’t know what algorithm that uses.  It appears that the algorithm used by Javascript’s sort() varies from browser to browser, though the browser ballot would be displayed in IE8 by default.  I suspect that the distribution is highly dependent on the sorting algorithm used, though I cannot readily verify it [edit: I verified it].  Regardless, this seems to be a very poor way to generate a random ordering.

]]>
http://2718.us/blog/2010/02/23/the-eu-browser-ballot-and-random-sorting/feed/ 1