Jaharmi’s Irreality renewable hyperlinks with 0% transfat since 1999

The session slides and other materials for my Penn State MacAdmins 2012 talk on “Packaging Mac apps with The Luggage” will be posted here.

Session slides: download PDF from Dropbox.

Session video: TBA.

Other links:

• The Luggage on GitHub
• My examples from Bitbucket
• The Ten Commandments of Packaging on Mac OS X, collected by Gary Larizza
• PackageMaker how-to for non-flat packages
• Semantic Versioning, a suggested standard for version numbering that you can apply to your packages

I’ve been experiencing the problem documented as Issue #196 for Hg-Git.

Instead of cloning a remote GitHub repository with Hg-Git and being able to see the source files I want and expect, I see files related to the GitHub project pages. I’ve specifically seen the problem with the repository for The Luggage. Example:

The comments about Issue #196 mention a way to correct the situation. I have been able to successfully apply that.

As of this writing, the most recent update for The Luggage does appear to be a GitHub Page change. According to the Issue #196 comments, that appears to be an important piece of the puzzle.

Going through a lot of old memories, I came across one that I don’t think I ever wrote about before. I used to need to run a Java application that communicated with the backend for a help desk tracking system. Luckily, the Java client was both forward and backword compatible with different versions of the server software, and the vendor provided a packaged Java app for the Mac platform.

However, as the Mac zoomed from 32- to 64-bit (with the Power Mac G5) and then from PowerPC to Intel, the packaged Mac OS X applet suffered. Even though I was using one major version ahead of the server version, the vendor by that point wasn’t updating this edition of the software. It was starting to become a Web app world by then. Even when the vendor had been updating the special Java client, it was hard to find. I was left with a 32-bit PowerPC-wrapped Java applet, but one which was otherwise completely functional.

My group had found that we could enable that applet to run in 64-bit mode by replacing its original ./JavaApplication.app/Contents/MacOS/JavaApplicationStub with a newer one provided by Apple. I think that’s all it took. I also believe that the same thing also worked for the Intel transition, happily preventing the PowerPC-wrapped applet from starting up in Rosetta and then running in the JVM.

I wanted to set up a kiosk system that displayed some static and some constantly-updated information. I already had a kiosk that used Apple Keynote in full-screen presentation mode to show a slideshow, but all of the slides themselves were static.

In pondering the idea of keeping the slideshow fresh with more dynamic and up-to-date information, I wondered if I could start with an RSS or ATOM feed as the source. After all, the Web is full of dynamically-updated content, thanks to blogging and content management (CMS) software. These updates are often streamed out in RSS or ATOM format. If that software is already present and the workflow is (or can be) a part of a group’s Web presence, then repurposing those same dynamic updates is an efficient use of peoples’ time. That the software is often reasonable for use by trained staff or dedicated volunteers is another benefit.

With that in mind, I constructed a proof of concept that let me add new slides to a Keynote presentation.

For this task, I wanted to avoid controlling Keynote with AppleScript because I’d had an interest in trying my hand at Python Appscript for a while. I found Appscript to be simple to use when controlling Keynote — and it made as much if not more sense to me than AppleScript did.

Unfortunately, Appscript is now deprecated, so while my proof of concept (below) works for now, it may not continue to do so with inevitable march of software progress.

For this sample project, we need to have the Universal Feed Parser and Appscript installed.

Unfortunately, with the disappearance of Mark Pilgrim and his projects from the Web, the original source site for the Universal Feed Parser no longer exists. However, UFP is still open source software and people had the source and are interested in further developing it. When installing UFP, Python “easy_install” will fetch it from its home on Google Code.

At this point, with two key Python modules in strange circumstances, you are probably wondering what I was thinking. My only defense is that I did all of this some time ago and neither the AppScript nor UFP situations was apparent at the time.

Install Python Appscript. This requires that you are logged in with a “sudo”-ready account, or have used “su” to switch to such a user.

Install Python Appscript.

Launch Keynote and create a new presentation from the template selector. We will enter the “title” and “summary” RSS/ATOM feed data into the first Keynote presentation, so you need to have a presentation open first.

In either a Python script or the Python interpreter in Terminal, use the following sample code to download the feed data from the Apple Hot News RSS feed and enter it into the Keynote document.

I picked the Apple Hot News RSS feed because it is commonly seen on Macs that use the RSS screen saver and its defaults. Because of that, I also thought the feed was likely to be around long enough into the future to serve as a good example for others that came across this article. I am not endorsing this particular feed, don’t follow it, and don’t know its contents at any given time. You are free to substitute the RSS/ATOM feed URL of your own choosing — well, as long as the Universal Feed Parser can handle it — with the following example.

The Keynote document will be populated with new slides. Each new slide will feature the “title” of the RSS/ATOM feed item as the slide title, and the “summary” as the slide body. That’s it!

I’ll leave it as an exercise for another day to consider how to work a dynamic batch of RSS/ATOM-based slides into an existing static presentation.

The Mac turns 28 today. It has come a long way, and it’s amazing to think about how the original Macintosh compares to, say, a 27-inch LED-backlit aluminum-and-glass-clad LCD iMac of today. I think one could imagine the iMac being a successor to the original iMac, from its exterior design, through the software it runs, to the input devices used to interface with it.

But, will the Mac make it to thirty — and still be recognizable as a Macintosh? A lot can change in the next two years.

I’m updating the settings for my Harmony 520 and discovered that I couldn’t change the names of activities in Harmony Remote Software v7.7.0. I am not alone, but I couldn’t find a solution. While I had the problem on Mac OS X 10.6.8, others reported problems on various other operating systems, including Microsoft Windows.

The software wouldn’t let me to change the name of more than one activity. Instead, it would let me select and highlight the text, but not edit it. It was maddening, especially when it would beep instead of accepting characters I typed.

Then, by happenstance, I clicked over to Safari to do something while I was frustrated. When I flipped back to the Harmony Remote Software, it finally accepted my typed changes.

Therefore, if you have come across this problem, try switching to another application and back to the Harmony software again.

I’m continually astounded at how aggravating the Harmony remote can be, after all the hype. I suppose it is still better than many, if not most, of the alternatives, but that isn’t saying much.

I’ve now spent just over one year with my EVIL (electronic viewfinder, interchangeable lens) DSLR-like camera, the Sony Alpha SLT-A55V. It has been a rewarding year for me photographically.

I can’t express how much more fun it is to use this camera compared to anything I’ve had earlier. I was in the land of point-and-shoots (including a “super zoom” of its time, the Olympus C-750UZ) before the SLT-A55.

There isn’t much I don’t like, and most of that is simply comes with the territory of a DSLR-like camera. The extra expense and bulk and even uncertainty (which lens should I take?) of having interchangeable lenses could be a drawback. All things considered, I am a happy and satisfied SLT-A55 owner, nothing more.

But beyond that, I have found this camera very freeing. I worry less and less about the pictures I take. I love the camera’s:

• fast startup time
• focus and depth-of-field
• fast shot-to-shot time and rapid-fire shooting
• automatic GPS tagging (although for best performance, you should keep the GPS Assist data up-to-date; I Download Sony GPS Assist data automatically when a memory card mounts with a LaunchAgent)
• 1080i movies that I can play on my flat panel TV
• availability of Minolta lenses on eBay (I wish I’d known more about this up-front), as well as new Sony lenses (online and in a more limited fashion at retail)

There’s certainly more, but this camera has removed so many barriers for me. I’ve taken at least 17,375 photos with it in a year, and I haven’t counted how many video clips. The best part is that I think a higher percentage of my images have been good than ever before.

The camera has gotten some press but I’m continually surprised that I don’t see it advertised more or presented in the weekly sales circulars (where it’s all Canon and Nikon, predictably).

I had a repeat of a problem that I’ve probably had many times over the years. I wanted to write down the solution before I forgot it, because it had been long enough since the last time that I’d forgotten the fix.

Let’s set the stage: I wanted to SSH into a remote system. In my case, that remote system was a Mac OS Snow Leopard system. The client was also Mac OS X.

On that remote system, I had enabled sshd. This is done on Snow Leopard with System Preferences > Sharing > Remote Login. (In the Sharing System Preferences, you set up the users that are allowed to remote log in, either allowing all users or setting up an ACL that only allows specific users. If you set up the ACL, it should supercede whatever additional user/group login restrictions you’ve configured in /private/etc/sshd_config.)

Then, I tried to SSH from my client system. Instead of a successful login, I was told the following — before I was prompted for a password.

Scratching your head, you add verbosity to the SSH connection attempt.

I searched for other people having the same problem with “debug1: SSH2_MSG_KEXINIT sent,” because other people always have the same problem and some of them wrote about it and some of those solved it. Right?

Well, in this case, the other solutions I found were not helpful to my specific situation. But many people responding to pleas for help did mention the always-good advice to “check the server logs.” Which I could do, so I did.

In the secure.log, I found several groups of lines like this corresponding to the times I had tried to log in:

That reminded me of the common problem with SSH host keys on Radmind-managed computers. See, Mac OS X will try to create the host keys if they are missing, but not if they are zero-length. On Radmind-managed computers, it was trivially easy to get zero-length SSH host key files in /private/etc because the tendency was to manage them with negative transcripts. Files listed in negative transcripts would be created if they were missing, but they would be created as empty files (by design).

Empty SSH host key files will prevent you from logging into that system with SSH.

I checked the server and — sure enough — the host key files were zero length. I deleted them, then stopped and restarted Remote Login for good measure. This solved the problem, and I could log in from the client.

I was trying to install Dulwich on a Mac OS X Lion system this week and ran into difficulty. I kept getting installation failures that included a missing “python.h” and, eventually, llvm-gcc-4.2 failed to compile the module.

I found the situation frustrating, partly because I pretty much own the top search hits about how to install Dulwich and Hg-Git on Mac OS X Lion, thanks to some earlier article.

It turns out that I had reinstalled Lion about two weeks ago, and had not reinstalled Xcode 4. So, I updated to Xcode 4.2 and this completely eliminated my problem. Presumably, it would also work for you — and for future me, since I’m likely to repeat this — even if Lion hadn’t been reinstalled in between.

Things that didn’t work included but were not limited to:

• cursing under my breath
• stomping
• hand-waving
• complaining on Twitter
• the silent treatment
• waiting for 4, 12, and then 24 hours to see if it would fix itself
• installing the latest version of setuptools, v0.6c11, from an egg
• installing the current version of Distribute, new hotness or not
• any steps involving Linux distribution package managers like apt-get.

I had a need to read some settings from a Python script on Mac OS X recently. I wanted to be able to change selected parameters for the script — some of which could be site or implementation specific — without embedding them directly in the code. Since the script was Mac OS X-only, using a property list seemed like a good idea.

With customizable settings from a property list, a script could become useful and more customizable for a wider community — or even different internal audiences.

I thought reading preferences was going to take a lot of effort. I was, however, pleasantly surprised at how easily I was able to accomplish it.

Asking others who had been down this route before resulted in some links to Apple docs. I wanted a more concrete example of how it was done in Python, and I got a great one.

That example came from reading the source to munkilib from the open source project, Munki. Since Munki had its own preference file, it needed to read from it, and its example was very enlightening.

Frogor directed me to a specific spot in the Munki code. That spot demonstrated how to read a preferences file with CoreFoundation.

Munki also has its own internal defaults for preferences. The munkilib/munkicommon.py example showed how to implement default settings in their absence in a property list. That provides a fallback position so that you always have some value available. In Munki, setting the defaults was done within a function. It seemed that it would be more generic if those defaults were separated out of the preference-reading function.

My own example of how to read a plist is outlined below. This focuses on just what you need in order to read the preferences and provide default settings for a larger script. A single set of preferences can be shared between scripts, and each script can encode its set own defaults. While you can create your own keys and values, for the example below, I will use the keys “StringPreference,” “BooleanPreference,” “ArrayPreference,” and “DictionaryPreference.”

1. Create a new property list. There are several ways to do this, including the property list editor that has been rolled into Xcode (and is no longer a standalone application) in v4.
2. Save the file. The name will be used later.
3. Set up the basic shell of the script that will read the plist and import CoreFoundation.
   
   #!/usr/bin/env python
   
   from Foundation import CFPreferencesCopyAppValue
4. Add in a variable for the script’s bundle ID. The bundle ID uniquely identifies your script’s preferences. It is written in reverse DNS notation, which should be familiar to almost anyone who has dealt with property lists before. It’s handy to have this defined globally for your script so that you can refer back to it as needed.
   
   #!/usr/bin/env python
   
   from Foundation import CFPreferencesCopyAppValue
   
   this_bundle_id = ‘com.example.your-script-here’
5. Create a function to read a preference by its bundle ID. The business end of the function is the use of CFPreferencesCopyAppValue get a value for a key.
   
   #!/usr/bin/env python
   
   from Foundation import CFPreferencesCopyAppValue
   
   this_bundle_id = ‘com.example.your-script-here’
   
   def get_preference(preference_key, bundle_id=this_bundle_id):
       """
       Get the preference value for a given combination of preference
       key and bundle ID. Returns the requested preference value.
       """
       # Get the specified preference key from the specified preference
       # bundle ID using CoreFoundation
       preference_value = CFPreferencesCopyAppValue(preference_key, bundle_id)
       return preference_value
6. Tie the get_preferences function together with a default_preferences object. This way, any missing preferences will fall back to the defaults encoded in your script. Any preferences that are set in a property list will override the defaults.
   
   #!/usr/bin/env python
   
   from Foundation import CFPreferencesCopyAppValue
   
   this_bundle_id = ‘com.example.your-script-here’
   default_preferences = {
       ‘StringPreference’: False,
       ‘BooleanPreference’: False,
       ‘ArrayPreference’: list(),
       ‘DictionaryPreference’: dict(),
   }
   
   def get_preference(preference_key, bundle_id=this_bundle_id):
       """
       Get the preference value for a given combination of preference
       key and bundle ID. Returns the preference value.
       """
       # Get the specified preference key from the specified preference
       # bundle ID using CoreFoundation
       preference_value = CFPreferencesCopyAppValue(preference_key, bundle_id)
       # If the value is not set in the property list, get a default value
       # from the default_preferences objects
       if preference_value == None:
           preference_value = default_preferences.get(preference_key)
       return preference_value

The script won’t do anything yet, until we create a main() or other functions to call the get_preferences function. Since you’d be reading preferences as part of a larger script, this is fine for now. However, with what’s written already, you can test out reading preferences interactively with the shell and Python interpreter.

1. Start by checking the property list in the shell. In my case, I created an example property list that sets two of the four preferences.
   
   $ defaults read com.example.your-script-here
   {
       BooleanPreference = True;
       StringPreference = abc;
   }
2. Open Terminal, run “python” at the command prompt, and paste the script code above at the interactive Python “>>>” prompt.
3. Run the get_preferences function and print its output.
   
   >>> print(get_preference(‘StringPreference’))
   abc
   >>> print(get_preference(‘BooleanPreference’))
   True
   >>> print(get_preference(‘ArrayPreference’))
   []
   >>> print(get_preference(‘DictionaryPreference’))
   {}

That’s it, the expected results were returned. Notice that the output for StringPreference and BooleanPreference are taken from the property list, while the empty array and dictionary come from the default_preferences in the script.

Update: Greg pointed out that there is a certain degree of danger using #!/usr/bin/env python as the shebang line in the script. Should a system have a non-Apple installation of Python, then /usr/bin/env python might return that. Another Python is probably less likely to be able to bridge CoreFoundation, and thus wouldn’t be able to use the CFPreferencesCopyAppValue call to read preferences.

I think the overall shebang danger is small because few Mac OS X systems will have an alternative Python installed, but clearly your chances of that increase in certain situations. To eliminate this risk, do what Munki does and insert the #!/usr/bin/python shebang instead.