Inactive Memory Problem With Photoshop CS6

I’ve been scanning several hundred postcards from the early 1900s recently. I’ve scanned them at as high a DPI and colour depth as I can to try to make the images as useful as possible in the future.

Each image is about 1.2Gb. I’ve been editing each one in Photoshop CS6 to correct rotation, crop out whitespace, etc.

I found that I can edit about a dozen images before I see a gradual slow down of my iMac, until after a few more edits it is almost unusable.

When this happened last time I checked Activity Monitor and noticed that I only had 700Mb of RAM free, while I had 6Gb of ‘inactive’ RAM.

FYI, I was doing this on a Core i7 iMac with 12Gb of RAM and 500Gb of free disk space.

Googling around a bit revealed that I could remedy this inactive RAM problem by rebooting, or by running the following in a Terminal window:

purge

This frees up inactive RAM, and makes it available to the iMac again. Once I did this everything sprang back into life.

Update: I find that Adobe Bridge CS6 is a bigger cause of this than Photoshop CS6.

Mapping Solution for OS X

Disclaimer – This posting is my personal view based on the information I have found to date – it does not represent the official views of Google Inc., and is not legal advice. You should seek guidance from Google Inc. for your individual application needs and circumstances.

I’ve been working on my first OS X app recently, and it’s going pretty well. It’s a simple app for genealogists that allows them to perform geospatial searches against places (parishes, towns, cities, etc.). The app is written for OS X, and there is an iPhone / iPad version planned.

When the user performs a search the results are initially displayed in a table, but the user has the option to overlay the results on a Google map. It’s a simple feature, but very useful for genealogists to be able to see search results in context.

The obvious choice for implementation of this feature was Google Maps. It’s a great mapping engine, and the API has a lot of power. I wanted to make sure that my app conformed to Google’s commercial terms and conditions so I had a look through the Google Maps documentation.

Google provides two licencing models for their map engine:

  • The free Google Maps API licence
  • Google Maps Premier API (commercial) licence

However, the Google Maps API web site did not, in my view, make clear exactly what constitutes an app that conforms to the free licence model, and one that requires the use of the commercial licence.

There are two relevant sets of API terms and conditions, one for iPhone and one for web/desktop apps:

Google don’t appear to differentiate between web apps and desktop apps (from the FAQ):

Can I use Google Maps in my non-Web application?

Yes, the Google Maps APIs can now be used in Desktop applications, provided that they adhere to the other restrictions of the Terms of Service. Note that in order for a desktop application to be deemed “publicly accessible”, there must be a publicly accessible webpage from which it can be downloaded. See Section 7.1c of the Terms of Service for more information.

However, there is a clear distinction between the Ts & Cs for iPhone apps and web/desktop apps. One of the differentiating clauses is clause 9.1:

iPhone Ts & Cs:

9. License Requirements. Google’s licenses above are subject to your adherence to the following requirements:

9.1 Accessibility to Your Maps API Implementation. Your Maps API Implementation may not charge an incremental fee solely for the Service.

…and

Web/Desktop Ts & Cs:

9. License Requirements. Google’s licenses above are subject to your adherence to the following requirements:

9.1 Free, Public Accessibility to Your Maps API Implementation. Your Maps API Implementation must be generally accessible to users without charge. You may require users to log in to your Maps API Implementation if you do not require users to pay a fee. Unless you have entered into a separate written agreement with Google or obtained Google’s written permission, your Maps API Implementation must not:

  • (a) require a fee-based subscription or other fee-based restricted access; or
  • (b) operate only behind a firewall or only on an internal network (except during the development and testing phase).

It wasn’t clear if the restriction was related to the just the implementation of Google Maps in an application (i.e. just that bit of an application’s functionality), or rather the application as a whole.

I contacted the Google Maps Premier API Sales team for an explanation and to ask them which licence my desktop app requires, and after much debate, was told this:

“…unfortunately I have to reiterate, if there is any payment for any aspect of a service which involves maps, then this requires a licence…”

So, it seems that for web/desktop apps any payment of any kind for your software means that you need a Google Maps Premier licence, while an iPhone app only requires a Google Maps Premier licence if you charge specifically for the mapping functionality.

Hope that helps.

Updating an SVN repository IP address on a checked-out project

If you run an SVN server on your network and you also run DHCP, you’ll know that at some point the DHCP lease for the IP address of your SVN server will expire, and (unless you have reserved an IP address for it in the DHCP admin) the next IP address allocated to that server could be different from the last one.

This is fine for most day to day work. IP addresses get allocated and reallocated in the background all the time, and mostly you don’t need to know if anything changes. However, if you have files checked out of an SVN repository and the IP address of the SVN server changes you are going to get an error when you try to check the files back in.

The reason for the error is that the IP address of the SVN server is hardcoded into the entries file in each \.svn folder. In case you didn’t know, SVN clients create a hidden folder called \.svn at each level of the folder tree you checked out. If you want to check the folder tree back in you will need to change the embedded IP addresses. The problem is, there could be a lot of files to change.

Thankfully there is a simple way to make these changes programmatically:

  1. Open up a terminal.app window
  2. cd to the root folder of your SVN repository
  3. Type in the following command:

    find ./ -name entries -print0 | xargs -0 perl -pi -e 's/OLD IP/NEW IP/'

And that’s it, all references to the old IP address have now been changed to the new IP address.

Setting up subversion on Mac OS X 10.5+

If you need a source control system (why wouldn’t you?) and you have a Mac, you have everything you need already built in. OS X ships with a Subversion (SVN) server and client by default. All you need to do is turn them on.

Setting Up Subversion Server

Create the following launchctl service definition file, name it org.tigris.subversion.svnserve.plist, and store it in /Library/LaunchDaemons:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple Computer//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
        <key>Debug</key>
        <false/>
        <key>GroupName</key>
        <string>staff</string>
        <key>Label</key>
        <string>org.tigris.subversion.svnserve</string>
        <key>OnDemand</key>
        <true/>
        <key>Program</key>
        <string>/usr/bin/svnserve</string>
        <key>ProgramArguments</key>
        <array>
                <string>svnserve</string>
                <string>--inetd</string>
                <string>--root=/PATHTOSVNGOESHERE/svn</string>
        </array>
        <key>ServiceDescription</key>
        <string>SVN Version Control System</string>
        <key>Sockets</key>
        <dict>
                <key>Listeners</key>
                <array>
                <dict>
                        <key>SockFamily</key>
                        <string>IPv4</string>
                        <key>SockServiceName</key>
                        <string>svn</string>
                        <key>SockType</key>
                        <string>stream</string>
                </dict>
                <dict>
                        <key>SockFamily</key>
                        <string>IPv6</string>
                        <key>SockServiceName</key>
                        <string>svn</string>
                        <key>SockType</key>
                        <string>stream</string>
                </dict>
                </array>
        </dict>
        <key>Umask</key>
        <integer>2</integer>
        <key>UserName</key>
        <string>USERNAMEGOESHERE</string>
        <key>inetdCompatibility</key>
        <dict>
                <key>Wait</key>
                <false/>
        </dict>
</dict>
</plist>

Set the username to the user account that will run the server (your username will do), and the groupname to the usergroup your account is associated with, usually staff.

Make sure you chown the user and group of the plist file:

sudo chown root:wheel /Library/LaunchDaemons/org.tigris.subversion.svnserve.plist

Now we need to set up the launchctl script to run the service:

sudo launchctl load /Library/LaunchDaemons/org.tigris.subversion.svnserve.plist
sudo launchctl start org.tigris.subversion.svnserve

The above set up will run the svnserve subversion server on-demand, as and when clients connect to it.

SVN Clients I recommend that you use a graphical SVN client. You don’t need to, as OS X ships with a command-line client built in, which you can test with the following command:

svn co svn://your.host.name/SomewhereInYourRepository

However, life will be a lot simpler if you use something like Versions

Thanks to the following blog posts for source information