Press "Enter" to skip to content

Category: Programming

AppKit bug in 10.12.2: NSTextField with tabs in text displays incorrectly

UPDATE: The bug described below is fixed in macOS 10.12.4 and the workaround described is no longer necessary (except for backward compatibility).

In a recent macOS project I have an NSTextField that contains text with tab characters in order to display a data table. (The text is an NSAttributedString to which I apply an NSParagraphStyle with its tabStops property set to an array containing a number of right-aligned NSTextTabs.)

The text field was drawn as intended (with the text aligned to the tab stops) before upgrading to 10.12.2. After upgraded, the text was no longer aligned to the tab stops, and when using monospacedDigitSystemFont there were cosmetic glitches displayed as well:

Under time pressure for a release, I implemented the workaround of replacing the NSTextField with an NSTextView. (I did this dynamically since it is not obvious how to create “bare” NSTextViews in Xcode’s Interface Builder.) Using an NSTextView I was able to get the data table to display as I had intended.

When writing up this bug (#29758498; Radar, Open Radar) I tried to create a simple test case that would illustrate the issue, but on my first try to recreate the problem from scratch, the issue didn’t appear. Puzzled, I copied the code and .xib file from my application into the test project, and was able to reproduce the issue.

By examining the text of the .xib files, I discovered that my newly created .xib file has a content view with wantsLayer=”YES”, and in this case the NSTextField works as intended under 10.12.2; but the .xib file from my application (which was created before Xcode 8 was released) did not have a layer set on the content view, and this did not work under 10.12.2 (although it had worked fine on 10.12.1 and earlier). Setting a layer on the application’s window’s content view (in the View Effects tab of the Assistant Editor in Xcode) was enough to fix the issue and make the table display as intended:

(Yes, bridge players, those point counts are bogus; my test program is generating random values to insert into the table.)

My wider questions are:

  1. What happened? We know there were a lot of graphic updates in 10.12.2, but it’s odd that the problem only occurs with the system font. I haven’t investigated whether the font file itself has changed.
  2. I can’t believe I’m the only person that’s run into this (although my usual googling produced no other hits). Is this really an uncommon case? Or is this a(nother) gap in Apple’s test suite?
  3. If Apple is expecting that the default case for content views is to have wantsLayer set, then it should certainly make this more widely known. I couldn’t find any references to this issue in the AppKit release notes.
2 Comments

Reading text files with arbitrary line endings in Swift 3

It’s easy enough in Swift to get an array of strings representing the lines of a text file:

  let contents = try! String(contentsOf: textFileURL)
  let lines = contents.components(separatedBy: .newlines)

…but what if the input might be a DOS format text file? CharacterSet.newlines contains both "\r" and "\n", so the code above will divide the text at each of them, and the array of strings will contain an extra empty string between every line.

Turns Out™ that Foundation has a number of APIs that understand all the ways line endings are represented in text files. The easiest way to read a text file with arbitrary line endings is to use the enumerateSubstrings(in:options:body:) method, specifying EnumerationOptions.byLines. This uses getLineStart(_:end:contentsEnd:for:) to recognize the line endings (see the documentation thereof for details) and is powerful enough to handle files with mixed line endings.

(In Objective-C these are the -enumerateSubstringsInRange:options:usingBlock: and -getLineStart:end:contentsEnd:forRange: methods of NSString.)

It’s straightforward to wrap this into an extension on String:

The name separatedIntoLines() seems like the best choice to describe the work being done; the alternative of a computed property simply called lines seems a little too terse to me.

Leave a Comment

VisualEffectPlayground in Swift

When searching for information on implementing vibrancy effects and NSVisualEffectView, developers often find references to the VisualEffectPlayground sample code presented by Apple at WWDC 2014. However, they soon quickly discover that Apple pulled the sample code from the Apple Developer site. Perhaps the application was thrown together for WWDC and didn’t meet the usual standard for Apple sample code; however, to date Apple has not seen fit to post any replacement. And so the search continues.

During my own search, I discovered that a Xamarin engineer named Oleg Demchenko had ported the sample code to Mono and posted it to the Xamarin samples site. In order to get a working sample application, I decided to port this code back to Swift and posted it to GitHub.

DISCLAIMER: I don’t know C# and I’m still learning Swift. Nevertheless, the resulting application appears to perform as expected (although I haven’t made an exhaustive test). I will certainly consider any pull requests.

1 Comment

Updating the cover of the Swift iBook

Apple updated the cover of The Swift Programming Language to match the new book in the series, but deleting and redownloading the book within iBooks in OS X Mavericks didn’t update the cover — it continued to display the original cover.

The solution was to quit iBooks, delete the iBooks cache located at ~/Library/Containers/com.apple.iBooksX/Data/Library/Caches/com.apple.iBooksX, and restart iBooks.

You’re welcome, Internet.

5 Comments

Improved cwd restoration in tcsh

My previous post illustrating a technique for restoring the current working directory in Apple’s Terminal for tcsh users was discovered by Khoo Yit Phang, who suggested an improved version down in the comments. I’m reproducing it here for greater visibility:

if ("$?TERM_PROGRAM") then
  if ("$TERM_PROGRAM" == "Apple_Terminal") then
    alias cwdcmd '( set echo_style = both; echo -n "33]7;file://${host}${cwd:ags/ /%20/}a" )'
    cwdcmd
  endif
endif

Compared to my approach, it has two improvements: (1) by using cwdcmd (of which I was previously unaware) rather than precmd, it only runs when you actually change directories; and (2) by using a suitably configured echo, it avoids running an external command (printf is not built into tcsh, but is present in /usr/bin).

Thanks, Yit.

Update: Of course, with this technique you have to explicitly run the command once, to restore the working directory to the title bar for the first time when you start up. Fixed above.

Leave a Comment

Current working directory restoration in Mavericks Terminal with tcsh

In John Siracusa’s excellent review of OS X Mavericks, he (originally) mentioned that the Terminal application is able to restore the current working directory of open shells across launches.

However, this section has subsequently disappeared from the online version, perhaps for the reasons given below (update: see below). Try looking here for a cached version of the original; scroll down to page/slide number 94. Sorry, John. Please purchase the full review on the iBooks store or the Amazon Kindle store to support John’s work.

Of course I was excited to try this out as, in the course of my work as a software developer, I often have several shell windows open in specific directories. So I tried it, and it didn’t work. It turns out the built-in support supplied by Apple assumes that you’re using the bash shell, but as an old-timer I’m stuck on tcsh instead:

Well, that’s no good, I thought. So I looked in the supporting code’s implementation (/etc/bashrc), and figured out how to do the same thing in tcsh. Simply place the following in your .tcshrc file:

if ("$?TERM_PROGRAM") then
 if ("$TERM_PROGRAM" == "Apple_Terminal") then
  alias precmd 'printf "33]7;%sa" "file://$host$cwd:ags/ /%20/"'
 endif
endif

This uses the appropriate escape sequence to send the URL of the current working directory to the terminal before each command; Terminal detects this information and uses it to update the state of the window (including a proxy icon in the window’s title bar for the corresponding folder). It turns out that the key is doing it using precmd (tcsh’s equivalent of PROMPT_COMMAND), and not sending the sequence in the prompt string itself as one might think. (The outer if statement is necessary to avoid an error when remotely logging in, as with ssh. It has to be a separate statement because of the variable expansion rules in tcsh.)

I’ve notified John via Twitter, so perhaps he add restore this information back to his review. In any case, it’s documented here for future generations. Drop me a note below if you have any issues with it.

Update: It turns out John removed it because he discovered it was a feature in Mountain Lion as well, which had happened not to work on his machine:

If you listen to John’s podcasts, you’ll realize that makes sense: he wouldn’t let something not new in Mavericks stand in the Mavericks review. Regardless, I wasn’t aware of the feature before and it still wouldn’t have worked in tcsh, so this post is presumably still useful. (Note that I haven’t tried it on Mountain Lion, and I’ve already upgraded my working machines to Mavericks; I don’t know why this technique wouldn’t work on Mountain Lion, but use it at your own risk.)

Update 2: OK, so it turns out the feature was first implemented in Lion, and other people have already figured out how to port it to other shells; see here for an implementation in zsh, for example. How did I manage to not learn about this for the last two years? Oh, well…

5 Comments

Debugging software for laymen

Brent Simmons provides what is possibly the best description for laymen of the joy/agony of debugging software that I’ve ever seen:

If it took 10 minutes to reduce memory usage by 96MB, then — were there a linear relationship — it should take under half a minute, less than 30 seconds, to go the rest of the way.

That’s the way things work in the real world, after all. If you have 100 bags of leaves to carry out to the curb, each bag will take about the same amount of time as the others.

Instead, it will probably take me about two hours, maybe more, to get rid of that last 4MB.

It’s almost as if you carried out 96 bags of leaves easily and quickly, then realized you can’t get those last four bags, even though they’re exactly the same as all the others, without pouring a new driveway first.

Which is crazy, right? If the real world operated like that all the time, we’d go completely nuts.

Leave a Comment

OCPython, anyone?

As dynamic scripting languages become more widely used, many developers are interested in using them to write “native” Mac OS X software, rather than having to learn Objective-C (which, of course, is a dynamic language in its own right). And in fact it is often possible to do so, using Apple’s BridgeSupport to generate the necessary metadata. Apple explicitly supports bridges for Ruby (RubyCocoa) and Python (PyObjC).

Nevertheless, there is necessarily an impedance mismatch between the runtime models — when passing objects to Cocoa, the bridge must convert the object from the dynamic language’s runtime to an Objective-C object derived from NSObject, and vice versa. This introduces a certain amount of inefficiency, which is not normally a big problem, but it would be desirable to avoid it.

Now, over the last few months, I’ve seen a variety of projects to do this by using the Objective-C 2.0 runtime to implement the object model for the dynamic language. In other words, objects in the dynamic language are subclasses of NSObject and no conversion is necessary.

These range from the venerable F-Script, which is even closer to Smalltalk than Objective-C, to Tim Burks’ original language Nu, which uses a Lisp-like syntax. I believe I’ve seen a reference to a JavaScript implementation as well, but I can’t seem to find it now.

The project that seems to be getting the most buzz in the Mac community right now is MacRuby, a port of Ruby 1.9 done by the developer of RubyCocoa (who is also an Apple employee). There was even a article about it featured on the Apple developer site recently.

Conspicuous by its absence from this list is my preferred dynamic language Python. I would love to see an implementation of Python hosted on the Objective-C runtime. I’ve always felt Python’s language model was a good match for Cocoa (of course, PyObjC not only predates BridgeSupport but even Cocoa itself, going back to the days of NextStep), and I’m personally more familiar with it than Ruby or other dynamic languages. So it seems like a logical step to take.

This project couldn’t be called MacPython, because that name has already been used to denote the Mac port of Python. For now I’m calling it “OCPython”, but I’m certainly open to a cleverer name (especially if there’s one that can riff on IronPython; unfortunately the element most associated with Mac OS X is Carbon, which is entirely wrong for this project).

I’ve been thinking about which version of Python to use as a jumping-off point; originally I was leaning towards 2.5 because it’s the version shipped with Leopard, but now I’m persuaded by Bill Bumgarner’s comment to use 3.0 and take advantage of the revised, less crufty implementation. (This is based on the stated goal of the 3.0 development project; I haven’t actually looked at the source code yet.)

I wish I could say I’m prepared to get the project off the ground myself, but right now I’m between jobs, as they say, and given the current financial situation I’m actively looking for full-time employment and can’t dedicate much time to something that won’t bring in any revenue. (Of course, if anyone out there would like to fund development of OCPython, contact me immediately.)

6 Comments

Visual Studio 2005: Not Ready To Lead

Glenn Howe writes of an anomaly in Visual Studio 2005’s C++ compiler:

… I discovered today (Friday) that if you compile something like:

double x = (false) ? 0 : 1.4;

that x will not equal 1.4 as most people (and the gcc compiler) would think, but rather it will equal 1.0. Why? Because it sees 0, interprets it as an integer and decides that if both halves of the : have to have the same type, then that type will be integer. The fact that this is in the middle of an assignment to double means nothing.

Yes, in fact it does mean nothing; the type of the lvalue on the left-hand side of an assignment expression has no effect on the type of the rvalue on the right-hand side.

He goes on:

I’m not even saying that Visual Studio is wrong. It’s different from gcc which leads to platform specific bugs, …

Well, I was a language lawyer in a previous life, so I can’t let it rest there. (And those of you out there saying “Of course Visual Studio is wrong!” should recall that gcc doesn’t always get it right, either.)

Where were we? The type of the conditional operator, right. To find what that type should be, we have to look at the definition of the operator.

In C99, this is pretty straightforward. Section 6.5.15, which defines the conditional operator, says the result of the expression “is the value of the second or third operand (whichever is evaluated), converted to the type described below”. Looking “below”, it further says when you have two operands of arithmetic type, the result type is the type that would be determined by the “usual arithmetic conversions” applied to the two operands.

Now a simple jump to section 6.3.1.8, which defines the “usual arithmetic conversions”, tells us: “… if the corresponding real type of either operand is double, the other operand is converted, without change of type domain, to a type whose
corresponding real type is double.”

OK, so that’s not completely straightforward, talking about “real types” and “type domains”, but basically we have two numbers, and if one of them is double the other is converted to double, and so that’s that; the type of the expression should be double, as we’d expect, and so Visual Studio 2005 is wrong.

If we’re in C.

C++ is more complicated.

(What a shock, right?)

Well, C++ has to allow for the possibility that either or both operand is a class type, and if so can it be converted to the other’s type, blah blah blah (section 5.16, if you’re following along at home).

Since we don’t have class type operands, we go on, applying the “standard conversions” to the operands (none of which apply here), and then, if “the second and third operands have arithmetic or enumeration type[,] the usual arithmetic conversions are performed to bring them to a common type, and the result is of that type.”

Hey, that was pretty simple after all. No, wait: are the usual arithmetic conversions the same in C++ as they are in C? Good question; let me see… (flip, flip, …) here we are, clause 5: yes, they are.

So from where I sit, Visual Studio 2005 is wrong in C++, too.

Wrong on conditional operators.

Wrong for America.

(I can’t wait for this election to be over…)

Comments closed

I have a bad feeling about this

Sometime when I wasn’t looking Apple posted the WWDC session schedule. I hope I’m wrong, but already I see the potential for some serious problems.

WWDC does not seem to have a big reputation for being well-run. I can’t speak to this personally with any great authority; I’ve only attended one previous conference, in 2006. I didn’t really know what to expect, and I was excited just to be there, but even still there were a few issues I noticed. That year the sessions on the newly-announced Objective-C 2.0 and garbage collection were scheduled in a room that clearly was too small for the amount of interest. I saw there was a problem and decided to bypass the sessions, even though I was interested, figuring I could read up on the material later.

Meanwhile, the session on application code signing had been put in Presidio, the largest room — which I interpreted as a sign of the importance of the topic to Apple — but there were well fewer than a hundred people there. So Apple’s track record on predicting attendance is suspect at best.

Now this year they’ve sold out the conference, so we know it’s going to be crowded, and we know many if not most of those people are there for the iPhone. Apple seems to have booked Presidio exclusively with the key iPhone sessions, which is wise, but I fear it won’t be enough. I imagine four or five hundred people lining up early Tuesday morning, parking themselves in Presidio, and staying there for three and a half days. People who try to come for a later session are going to be annoyed if they can’t get in — but if Apple tries to clear the room after each session, people will get really angry.

[In 2006 they apparently ended up “repeating” a few of the overcrowded sessions by replaying them on a video projector one evening. I didn’t go; if I remember correctly, that was Wednesday, the night of the Apple Design Awards and Stump the Experts, and I didn’t want to miss those. This time around I’d probably pass them up, though. For one thing, the former DTS engineer with whom I saw Stump the Experts, and who made it twice as much fun by filling in the back story for me, is probably not attending this year.]

As a would-be independent developer with interests in both desktop and iPhone software, I’m anxious about the scheduling. On the one hand, if the iPhone session fill up I can usually find other sessions of interest to me. On the other hand, the trip out to San Francisco from the East Coast is a big deal in both time and money, and it’s not clear when I’ll be able to do it again, so I’d like to take advantage of the iPhone sessions as much as possible, since they’re clearly of more immediate value. (After all, I’ve got my Hillegas third edition right here already.)

At least if I keep myself on Eastern Time I can show up early every morning and get in line. I’ll miss the evening socializing, but I’m pretty introverted and don’t know anyone in SF, so that’s not much of a loss for me.

I sure hope this works out…

Comments closed