Sheep Systems

The Olympus LS-P4 voice recorder is capable of really high quality recording if properly configured.  This explains how to do that.

In our church, the built-in SCENE = MUSIC would be OK for most English Masses, but I don't use that because for Hispanic Masses using this scene results in a few dB of clipping in music such as cumbias with hard driving bass.  Fortunately, the LS-P4 will remember all settings, including the recording level Volume number.  So if you always record in the same way, you only need to do the following once.

Turn on the third (central) mic

The LS-P4 is capable of quite flat frequency response over the audible spectrum, but to get the bass end you need to use all three microphones – the tres mic feature.

Push button MENU.
Push DOWN button once to get to Rec Menu.
Push RIGHT button once to select it.
Push DOWN button a five times to get into Mic Select.
Push RIGHT button again to get into select it.
Push UP or DOWN button to get to Central Mic. 
Push RIGHT button to select it.

Version 2.5 of Smarky, Synkmark, Markster and BookMacster introduces a new document file format, replacing the old Bookmarkshelf document (.bkmslf file) with a new Collection document (.bmco file package).  Note: BookMacster users may have more than one document file.  Synkmark, Markster and Smarky only support a single document file, which appears as its “main

A .bkmslf file opened in version 2.5 or later will automatically be deleted from the disk and replaced with a new .bmco file package.  For BookMacster, if it resided in the default Bookmarkshelf Documents folder, the corresponding .bmco file will reside in a new Collections folder.  Like the old Bookmarkshelf Documents folder, the new Collections folder also resides in ~/Library/Application Support/BookMacster/.

The new file format plays nicer and more efficiently with recent versions of macOS.  It is a file package instead of a flat file, its SQLite store now supports write-ahead logging.  Instead of using Apple’s notoriously problematic NSPersistentDocument, it is based on BSManagedDocument.  It has adopted Apple's asynchronous saving.

As a developer, of course I always anxiously upgrade to the lastest beta macOS, forgetting that I’ll need to keep the older one around for testing our apps.  Then, I need to install an older macOS on a different partition.  The challenge is that, if you do the obvious thing and launch the “Install <earlier version>” app, a dialog will appear and tell you This copy of the ‘Install OS X/macOS’ applications is too old to be opened on this version of OS X/macOS – Quit.  Arghhh.  The following instrucions will work around that.

First of all, understand that it is definitely necessary to have three volumes to do this.  A “volume” is a disk “partition”.

Volume N - The volume with the new version of macOS which you are currently running.
Volume T - A “trampoline” volume which will become your bootable installer.  This volume must be only big enough to hold the installer.  This Volume T will be comnpletely erased during this process.  I used a 8 GB thumb drive for Volume T.
Volume D - The destination volume which is where you want the older version of macOS to be installed

Note that these three volume/partitions may or may not be on the same disk.

If you try to use one volume for T and D, everything will proceed OK until it inexplicably tells you that your disk image is damaged and you should redownload from Apple, which will not help.

I’ve often said that helmets serve no purpose when you’re riding a recumbent bike like my Tour Easy, because you’re highly unlikely to go flying head first, as commonly occurs when something bad happens to an upright bike.  Well, it turns out that is wrong.  Riding about as fast as I could on my steel Tour Easy (maybe 15 miles per hour at my age of 58), northbound on Sunol St., north of San Carlos St. in San José on Sunday 2015 April 19, I felt my front end lift up, and then a second later collapse under me.  Next thing I knew, my helmet bounced off of the asphalt, on the right side just above the visor.  Wow, this would have been a serious head injury.  (It was the first time that I’d ever “used” a bicycle helmet.)

The accident was due to a quite high ridge in the pavement that runs parallel to the direction of travel.  The only damage to me or my bike was a slightly sore shoulder that went away after a day, a loosened rear view mirror, which was kind of loose even before that, and another tear in the light cloth that I have clipped over my fairing to protect it from scuffs and degradation by sunlight.

A job I’m working on requires that the customer's massive old project be built with the 10.6 SDK.  After spending a few minutes with Xcode 3, I was thinking of walking out the door.  Actually, it was more than a few minutes – I watched Xcode 3 beachball for eight and a half minutes doing a Find in Project (not frameworks, just Project!).  I remembered the bad old days.

But then I also remembered how, years ago, I’d copied the 10.5 SDK into Xcode 4, I think when I needed to build Bookdog.  I  remembered there were some issues, though, and eventually it was no longer possible.  Realizing this was a much bigger stretch, in desperation I tried it again.  I copied the 10.6 SDK from an Xcode 3 installation to Xcode 6.1 as described in this Stack Overflow article  Amazingly, after 15 minutes of “indexing”, Xcode 6.1 Build Succeeded on this massive project, including CodeWarrior PowerPlant, using the 10.6 SDK, and the product launched and it works.  Hey, I got 999+ warnings, but they were supposedly getting 700+ in Xcode 3.

Hmmm, there were probably fewer issues with this than with Bookdog and 10.5, because back then we were dealing with the PowerPC thing and different gcc versions.

Something I don’t say very often:  Thank you, Apple, for not breaking this unsupported hack.

I might recommend still doing the final production build in Xcode 3 on the old Power Mac, but at least now I can develop.

Four ducks perch on the bank of one of the ponds in the Oakdale / Farmer's Creek wetland in Lapeer, Michigan.  A couple weeks ago, the geese left the area and for the last week or so, dozens of ducks like this were happily swimming and doing duck things in this pond, until a couple days ago when the temperatures became colder, rather early in the season, according to the local people I talk to.

Today, you can see to the left of these four remaining ducks is the one small still-shimmering section of the pond which has not yet skinned over with ice.  It is about 15:15 in the afternoon on Sunday, 2014 Nov 16.  Overnight, this small section will certainly become skinned with ice also, and with temperatures predicted to average -5 Celsius from Monday night thru Friday, the whole surface will be frozen hard.

I wonder what the ducks are thinking.

Follow-up resources regarding my talk to the Advanced iOS/Objective-C/Swift Meetup at Sandbox Suites in Sunnyvale, California, the evening of 2014 Sep 09.   Thank to all who attended!

Jerry Krinock

The project I showed to demonstrate Core Data Concurrency.

The High Level View

Brent Simmons’ 2010 blog post On Switching Away from Core Data

Tim Roadley's Ten Mistakes People Make with Core Data


From Apple

Apple's Core Data Programming Guide  

Apple's Technical Q&A 1809 on Write-Ahead Lookup Journaling, added in OS X 10.9 and iOS 7, which causes Core Data persistent store files to be three files instead of one, and how to work around it or revert to the old behavior.

Transcript of WWDC 2014 Session 225, What’s New in Core Data  Reading a searchable transcript on a technical topic is so much more efficient than watching a video!  Even if someone gives you a time marker in the video.  However, you might want to watch the video too.  It looks like there was only this one Core Data Session this year.


Open-Source Tools and Libraries

Matthew Morey’s Top 10 List of Core Data Tools and Libraries.  Number 2 in the list, mogenerator, contains some instructions for using mogenerator.

Wolf Rentzsch’ mogenerator, a tool for generting Core Data model classes.  Version 1.27, the current built binary download, does not support Swift, but supposedly the current trunk does and presumably 1.28 should.

Many years ago, when I worked for a company in a cubicle, after one of our many relocations, all of the engineers were busy rearranging our cubicles.  You had a desk, a chair, a computer, a file cabinet, usually a storage cabinet and whatever else you wanted which you could “appropriate”.  You were free to put these where you wanted.  Some people were trying to be innovative, others copied.  A wise engineer, older than me at the time, viewed the scene and remarked Yes, it’s hard to figure out the “optimum” arrangement.  Maybe stay at home and have them send the check every month.  He was great about saying stuff like that with a straight face.

I feel the same way about apps on my iPad Mini, which I use mostly for reading music notation with forScore, but of course it’s a note pad and web browser too.  I won’t do email on an iPad because I’m never far away from my MacBook Air, and I can type faster on a real keyboard.  iTunes tells me I have 34 apps.  I’d rearranged the apps once, “logically”, into three screens, but it never quite made sense.  Today I decided it do it like I do my bookmarks - in alphabetical order.

Since Google Chrome (and other browsers based on the Chromium source code, such as Google Chrome Canary, Opera 15+, Maxthon, White Hat Aviabor) will no longer support NPAPI soon, we needed to find a different way for our bookmarks managemenet apps to communication with our Chrome extension.  The alternative suggested by the Chrome team, Native Messaging, looks like it will do the job.  At least it passed our proof-of-concept test.   UPDATE: It is now shipping in the Stable/Production versions of our apps Synkmark, Markster and BookMacster.  The architecture looks like this…

This architecture looks quite similar to how NPAPI worked, except that Your “Messenger” Tool was your NPAPI plugin.  It still has two moving parts, but the Messenger has a drastically smaller surface area than the NPAPI Plugin…

• Its size, in our case, is looking to be less than 200 KB, compared to the 2 MB size of our NPAPI plugin, which is based on FireBreath.  (I gave up after a couple days of trying to write an NPAPI plugin myself, and found FireBreath.)

• Much as I appreciate the FireBreath product, it was scary to use such a complicated black box which I could barely troubleshoot when there was an issue.  You see, I gave up on C++ a decade ago after realizing that I could never learn the new C++ features as fast as the C++ gurus were adding them.  Life will be sweet with no more shared pointers, no more Boost library, no more black magic, no more CMake.  (CMake is another amazing open source project, one which Firebreath uses to create cross-platform project files for Apple’s Xcode.  Unfortunately, since Apple changes Xcode so much and so frequently, it is challenging to keep it working.)

• I no longer need to worry whether or not our NPAPI plugin will work when the Chrome team ever decides to ship a 64-bit version of Chrome for OS X.  (A 64-bit developer build has recently appeared for Microsoft Windows.)  Of course, it could not be tested until they do.  Now, it won't be needed :))

• When our extension is installed into multiple user profiles in Chrome (which can be running simultaneously), each profile launches its own instance of our Messenger tool.  Our NPAPI plugin required some careful accounting to avoid “crosstalk" in this case.

• Because whatever goes into ~/Library/Internet Plug-Ins gets loaded into all browsers whether it needs them or not, our plugin uselessly loads itself into Firefox, Safari, etc., where it has no effect other than to waste the user’s RAM, and paste our good name into the Crash Report whenever one of these browsers decides to take a nosedive.  Viva isolated processes!

* * *

Here is how the above subsystem seems to work.  When user opens the first window in a given Chrome profile, a background.html page in our Chrome extension invokes chrome.runtime.connectNative() with a given host name.  Chrome then looks for a special manifest file matching the given host name in
        ~/Library/Application Support/Google/Chrome/NativeMessagingHosts/
Of course, our extension installer will have installed this file. Most importantly, it contains the path to our new “Messenger” tool, a Command-Line tool written in Objective-C.  We’re probably going to install that into our own ~/Library/Application Support folder.  Knowing this path, Chrome launches an instance of our Messenger tool.

Chrome communicates with its child messenger via unix stdin and stdout.  It seemed like an odd choice for interprocess communication, until I realized that these big-name web browsers need to be cross-platform and run on old systems.  They needed something ubiquitous.

In the Chrome-to-Messenger direction, you first open communication via chrome.runtime.connectNative() , which returns a port object that will accept a postMessage() call whose single parameter is a JavaScript object, typically a dictionary.  Very nice; you can use the keys in the dictionary like commands, and the values like command parameters.  Via stdin, the Messenger receives a JSON serialization of this object, prefixed by a four byte header.  The four byte header is one field, the length of the JSON data in bytes.

In the Messenger-to-Chrome direction, your Messenger similarly creates a similar command/parameter dictionary, serializes it object into JSON, (using for example, NSJSONSerialization), encodes it to data as UTF8, then gets the length of the data, prepends it to the JSON, and writes it to stdout.  About 9 lines of Objective-C code if you’re verbose like me.  Not bad.

Apparently because the background.html is a child of the Chrome user profile and not of a window, communication remains open even after the last browser window of the current user profile in Chrome is closed.  (Whew!  This behavior is critical for edge-case apps like bookmarks management, that work on the background profile data, unrelated to a browser window.)

When Chrome completely quits, it apparently sends an end-of-file (EOF) to your Messenger.  (I can’t see the EOF for sure because NSFileHandle probably swallows it, but I’m guessing this must be what happens.)  Anyhow, when your messenger receives an empty stdin from NSFileHandle, it should terminate itself gracefully too.  Or you can just wait for the system to kill it due to its parent process (Chrome) terminating.

I’ve noticed one odd but probably harmless behavior and maybe beneficial behavior, which is that if Chrome is running with browser windows open in two different user profiles, and both have our extension loaded and consequently two of our Messenger tools are running, if you quit Chrome without closing the browser windows, then relaunch, two Messenger tools will launch, apparently one for each user profile, even though only one browser window opens (for the last-started user profile).  Probably, Chrome re-opens two background.html pages, one for each profile which had a browser window open when Chrome was quit.  If browser windows are closed first, then only one Messenger will launch, for the one browser window which opens.

Native Message has a very nice, super-minimalist, low-level protocol.  You define your own higher-level protocols with commands and parameters (Use JSON!).  The design process is natural, and easily extensible; you can pretty much make it up as you go along.

I think the Chrome team did a nice job on Native Messaging.  I just wish they’d done it four or five years ago, so I wouldn’t have had to design in and then design out NPAPI 😩

* * * 

Update 2017-03-03.  Firefox now uses the Chrome extension system, with this same Native Messaging.  Future versions of our Firefox extension will use it.

Safari extensions, unfortunately, still have so few capabilities that we’ve found no reason to bother writing one yet.

After upgrading to Mac OS X 10.9 on my main Mac account today, as happens every time I upgrade Mac OS X, my Perl scripts didn’t work.  Again,

Can't locate My/Module.pm in @INC (@INC contains:/Library/Perl/blah, /System/Library/Perl/blah, blah, blah…

Sigh.  The problem is that @INC is hard-coded into Perl to contain only system directories, and so the installers for third-party Perl modules that I’ve downloaded from the Comprehensive Perl Archive Network (CPAN) put modules that I need into these system directories, which are wiped by Apple’s installers when you upgrade Mac OS X.

It doesn’t seem to bother the Linux geeks.  But in Mac OS X, we try to to keep all of our stuff in our Home directories.  (We also don’t like kill several weekends per year reinstalling our systems from scratch.)

Rather than getting them off of my Time Machine disk and installing them back into the same stupid place, this time I put them in my Home directory,

~/Library/Perl/

and also I put all of the modules into that folder directly, foregoing the “5.10”, “5.12”, “5.16” etc. subfolders.  It doesn’t make any sense to me that these modules are associated with specific Perl versions.  I’m only running one version of Perl, and if I need to update a module, I need to update a module.  Old versions of modules, if that’s what those folders are for, don’t do me any good.

The Sparkle framework is built with an INSTALL_PATH set to @loader_path/../Frameworks.  This works fine when Sparkle is embedded into an app or a plugin, but not if you're embedding Sparkle inside of another framework, as a "sub" framework.

Short Explanation

The short explanation is that @loader_path is referenced to the executable inside the package, so the path from it to its target depends on the directory structure of the hosting app, plugin or framework.  The directory structure of a plugin is the same as that of an app, so it "just works", as explained in the ld man page.  But a framework is different, so it needs a different path.

Longer Explanation

The INSTALL_PATH of  @loader_path/../Frameworks works fine when Sparkle is embedded directly into an application or plugin.  In either case, the package looks like this…

   Contents
      MacOS
         MyPlugin (Unix executable)
      Resources
      Frameworks
         Sparkle.framework

because the @loader path is MacOS, the .. is Contents, and Frameworks is, nicely, a subfolder of Contents.

However, embedding Sparkle into another framework is different because of the different directory structure.

I spent some time yesterday improving our Trouble Zipper AppleScript package.  It now finds crash reports generated by Mac OS X 10.7 and 10.8.  (Apparently, we haven't needed to look at many crash reports since 10.7!)  Also, using a new Perl script in the package (filterConsoleLogs.pl), the filtering of console log entries for those written only by a target app now gets all lines of multi-line entries.

The AppleScript source, and other useful scripts and tools in the package, are all open for any other interested developers to dig in to.  Unfortunately, if your app is sandboxed, you may not be able to allow your users to download and run such a Trouble Zipper from the Help menu in your app, as BookMacster does.  But if you can figure out a way to deliver it to your users, you might want to download Trouble Zipper, tear it apart, and use whatever you like.

Oh, but, Apple gave us one more annoying surprise in Mountain Lion.  The applet executable in Trouble Zipper's Contents/MacOS/ subdirectory is a triple-fat binary: x86_64, i386, and ppc.  AppleScript Editor in Mountain Lion will not open it, apparently because it does not like the PowerPC (ppc) architecture in the applet.  And in characteristic Apple oversimplified style, the error dialog simply says that the script cannot be opened.  If you don't need to support any more PowerPC users, you can fix this problem by swapping in the applet from any other AppleScript application package you have.  Or, you can work around it by opening Contents/Resources/Scripts/main.scpt inside the package, instead of the package itself, and editing that.  AppleScript Editor will occasionally give you some crap about not being able to save the file because another app has modified it.  Just click Save Anyway.  Also, before testing or shipping, you'll need to manually click Compile before Save.

Because I got the Developer Preview of Lion, I didn't get the warning dialog that most people got about the "new and improved" scrolling direction.  For weeks, during the preview, I thought that the upside-down behavior was because of my old Macally trackball.  Then I tried an Apple mouse and found that it was backwards too!  I couldn't find anything in System Preferences ▸ Mouse.  Finally I called AppleCare and was pointed to the checkbox…

What in the world does that mean?  After a few seconds I guessed what they meant by content, then activated the engineering side of my brain, and visualized it moving as described.  "Oh, oh!  Now I get it."  Apparently I had skimmed over that checkbox, thinking that since it was so complicated it must not be what I was looking for.

Especially with early versions of BookMacster, people have commented to me that the control names, tooltips and other text "strings" as we call them were too long, too technical and hard to understand.  I've been working on simplifying those, trying to be more like Apple.  But with this checkbox, I see that Apple is going in the other direction.  I told the rep on the phone that the title of that checkbox should have been something more understandable like this…