Domain of the Bored

:g/^[-+].\+{\s*$/,/^}/fold ←Folds all Obj-C methods in the current file.

Technorati tags: vim

This bug is Can't drag-and-drop to “Title” field on PackageMaker's Interface tab. It was filed on 2006-05-19 at 02:38 PDT.

Summary:

The “Title” field on the “Installer Interface” tab is not a drop target.

Steps to Reproduce:

1. Drag text from the “Title” or “Description” field to the “Title” field.

Expected Results:

The cursor changes to the Copy cursor, and when the mouse button is released, the text is inserted at the drag destination insertion point.

Actual Results:

The cursor does not change, and when the mouse button is released, the drag snaps back.

Regression:

None known.

Notes:

None.

Technorati tags: Apple Bug Friday, applebugfriday

This bug is PackageMaker's keyboard shortcuts are not consistent with Xcode's. It was filed on 2006-05-19 at 02:28 PDT.

The list in the Notes section is adapted from another blog post of mine, Know your Xcode.

Summary:

PackageMaker's keyboard shortcuts for Build, Build Log, Run, and Run Log do not match up with Xcode's shortcuts for the same commands.

Steps to Reproduce:

1. Press ⇧⌘B.

Expected Results:

The Build Log appears.

Actual Results:

*Beep*

Regression:

None known.

Notes:

Xcode has a simple and elegant system for its keyboard shortcuts:

• ⌘_ builds, then performs the action.
• ⌘⌥_ performs the action without building. (Exception: Build's keyboard shortcut is ⌘B, presumably because it is impossible to build without building.)
• ⇧⌘_ shows the log for the action.

PackageMaker should adopt the same schema, both for its elegance and for uniformity with Xcode.

Technorati tags: Apple Bug Friday, applebugfriday

I just discovered this — you can use the numeric keypad to move views in a nib. The benefit of this is that you can perform atomic diagonal moves (as opposed to a rapid sequence of, for example, up followed by left).

Technorati tags: Interface Builder

I've been working on a header search tool in Python. You run the index tool, and it creates the database (using PostgreSQL and PyGreSQL); then you can use the search tool to look up headers either by name or by keyword:

python searchheaders.py name=NSAffineTransform.h  %~/Python/sql_headersearch(0)
NSAffineTransform.h     /System/Library/Frameworks/AppKit.framework/Headers/NSAffineTransform.h
NSAffineTransform.h     /System/Library/Frameworks/Foundation.framework/Headers/NSAffineTransform.h
___
python searchheaders.py symbol=NSAffineTransform  %~/Python/sql_headersearch(0)
NSAffineTransform       "/System/Library/Frameworks/AppKit.framework/Headers/NSFontDescriptor.h"
NSAffineTransform       "/System/Library/Frameworks/AppKit.framework/Headers/NSBezierPath.h"
NSAffineTransform       "/System/Library/Frameworks/AppKit.framework/Headers/NSAffineTransform.h"
NSAffineTransform       "/System/Library/Frameworks/AppKit.framework/Headers/NSFont.h"
NSAffineTransform       "/System/Library/Frameworks/Foundation.framework/Headers/NSAffineTransform.h"

It's not done yet, obviously (for one thing, I don't know why those quotes are in there), but it's coming along nicely. And it's quick, though not very:

time python searchheaders.py name=NSAffineTransform.h > /dev/null
python searchheaders.py name=NSAffineTransform.h > /dev/null  0.06s user 0.10s system 44% cpu 0.371 total
___
time python searchheaders.py symbol=NSAffineTransform > /dev/null  
python searchheaders.py symbol=NSAffineTransform > /dev/null  0.06s user 0.10s system 6% cpu 2.339 total

I want to see if there's anything I can do to fix that query time. Probably something involving PostgreSQL's array types, so that I can make the keyword column a primary key.

This, incidentally, is why I needed to parse the preprocessor.

Technorati tags: Programming.

If you've ever run GCC's preprocessor alone and looked at its output, you've seen lines like these:

# 1 "/usr/include/sys/types.h"
# 1 "<built-in>"
# 1 "<command line>"
# 1 "/usr/include/sys/types.h"
# 66 "/usr/include/sys/types.h"
# 1 "/usr/include/sys/appleapiopts.h" 1 3 4
# 67 "/usr/include/sys/types.h" 2


# 1 "/usr/include/sys/cdefs.h" 1 3 4
# 70 "/usr/include/sys/types.h" 2

And you probably wondered what all that means. Here's your secret decoder ring.

First, these are called "line markers" in libcpp. The format of a line marker is:

1. A line number
2. The path to the relevant file
3. Flags

The flag values are:

1

Push (enter) header

2

Pop (leave) header

3

This is a system header (determined by these rules with this modification)

4

Requires extern "C" protection (determined by the same rules as above); never found without 3

Note that a pop applies to the header above (in the include stack) the one referenced in the marker.

Example:

# 66 "/usr/include/sys/types.h"
# 1 "/usr/include/sys/appleapiopts.h" 1 3 4
# 67 "/usr/include/sys/types.h" 2

1. Fast-forward to line 66 of <sys/types.h> (nothing interesting occurs before this line).
2. Enter <sys/appleapiopts.h>. Everything from this point until the next marker is from that header. Note that this header is a system header (3) and requires extern "C" protection (4).
3. As it turns out, nothing interesting happened there. So the very next line is a pop marker: <sys/appleapiopts.h> is popped, so now we're back in <sys/types.h>, now on line 67 (the line after the #include <sys/appleapiopts.h>).

The relevant code in libcpp is in directives.c. The function that parses line markers (presumably used by the compiler rather than the preprocessor itself; the preprocessor generates them) is do_linemarker. Additional include-related code is in files.c.

UPDATE 23:24 PDT: Beware of pragmas. Seems obvious now, but I didn't think of it earlier: The preprocessor leaves #pragma directives untouched, being that they're for the compiler rather than the preprocessor. So if you're only looking for line markers, you may get tripped up if you don't properly handle/ignore a pragma.

Technorati tags: GCC, cpp, C preprocessor.

This bug is PackageMaker (and Installer?) does not support EPS, PDF, or SVG in packages. It was filed on 2006-05-19 at 02:20 PDT.

Summary:

PackageMaker/Installer should support the use of EPS, PDF, or SVG image files in Installer packages.

Steps to Reproduce:

1. Create a package in PackageMaker.
2. On the first step of the Interface Editor, drag a EPS, PDF, or SVG file onto the window, or click Custom Background Picture and choose a EPS, PDF, or SVG file.

Expected Results:

The EPS, PDF, or SVG file is accepted as the background of the package.

Actual Results:

The EPS, PDF, or SVG file snaps back (drag), or is disabled in the list (choose file).

Regression:

As far as I know, Installer has never supported EPS, PDF, or SVG files.

Notes:

Vector graphics would scale cleanly to any resolution, which is good for the coming resolution-independent UI. Currently, it is necessary to use a large and/or multi-image TIFF file, and hope that it's enough.

Technorati tags: Apple Bug Friday, applebugfriday

This bug is PackageMaker (and Installer?) does not support PNGs in packages. It was filed on 2006-05-19 at 02:00 PDT.

Summary:

PackageMaker/Installer should support the use of PNG image files in Installer packages.

Steps to Reproduce:

1. Create a package in PackageMaker.
2. On the first step of the Interface Editor, drag a PNG file onto the window, or click Custom Background Picture and choose a PNG file.

Expected Results:

The PNG file is accepted as the background of the package.

Actual Results:

The PNG file snaps back (drag), or is disabled in the list (choose file).

Regression:

As far as I know, Installer has never supported PNG files.

Notes:

PNG supports compression, for smaller Installer packages. True, Installer packages are often distributed on compressed disk images or in compressed zip archives, but PNG can “filter” the image bytes to be more compressable, resulting in greater savings.

Technorati tags: Apple Bug Friday, applebugfriday

This bug is IB refuses to keep pop-up menus open. It was filed on 2006-05-12 at 02:33 PDT.

Summary:

IB closes a pop-up menu being edited in response to any key or mouse event in the menu.

Steps to Reproduce:

1. Drag a pop-up button into a window in a nib.
2. Double-click on the pop-up button to edit it.
3. Change the selection by clicking on any item, or pressing up or down. Or, double-click on an item to rename it, then press return or enter or change the selection.

Expected Results:

The current selected item changes, or is renamed, or both.

Actual Results:

The current selected item changes, or is renamed, or both, and then IB closes the menu, interrupting any plans to further edit the menu until the menu is reopened by the user.

Regression:

This used to work, although I don't know in what version.

Notes:

No Console output is emitted by IB.

UPDATE 2006-05-24: I got an email from Apple recently telling me that the bug was a duplicate, and just today, Xcode 2.3 came out, including IB 2.5.4 which fixes this bug.

Technorati tags: Apple Bug Friday, applebugfriday

This bug is -mtune (Instruction Scheduling) does not include Intel processors. It was filed on 2006-04-28 at 00:35 PDT.

Summary:

With the move to Intel processors, Xcode needs to support processor-specific optimization for them.

Steps to Reproduce:

1. Get info on a target or project.
2. Switch to the Build tab.
3. Change the active Collection to one that includes GCC/Code Generation.
4. Edit the "Instruction Scheduling" setting.

Expected Results:

At least pentium-m is listed, being (presumably) the most similar to Yonah (the "Core Solo"/"Core Duo" processors). Ideally, scheduling optimizations for Yonah itself should be added to GCC, with a matching listing in Xcode's pop-up menu.

Actual Results:

Only G3, G4, and G5 are listed (besides "None").

Regression:

This wasn't a problem before the move to Intel.

Notes:

Direct Yonah support isn't supported by GCC (yet) according to the GCC manual's page "i386 and x86-64 Options". GNU's current documentation doesn't list it either.

Technorati tags: Apple Bug Friday, applebugfriday

Like many, I use the popular open-source text editor vim. Earlier, I set about making it more usable through syntax coloring. This included tweaking its support for Objective-C.

First, mkdir ~/.vim, and cd ~/.vim. Now mkdir syntax. cp /usr/share/vim/vim62/filetype.vim . and cp /usr/share/vim/vim62/syntax/objc.vim syntax/. Then select and copy this patch:

Index: filetype.vim
===================================================================
--- filetype.vim 2005-03-21 02:12:47.000000000 -0800
+++ filetype.vim 2006-04-24 03:33:27.000000000 -0700
@@ -262,7 +262,7 @@
 
 " .h files can be C or C++, set c_syntax_for_h if you want C
 au BufNewFile,BufRead *.h
- \ if exists("c_syntax_for_h") | setf c | else | setf cpp | endif
+ \ if exists("c_syntax_for_h") | setf c | else | if exists("objc_syntax_for_h") | setf objc | else | setf cpp | endif | endif
 
 " TLH files are C++ headers generated by Visual C++'s #import from typelibs
 au BufNewFile,BufRead *.tlh   setf cpp
Index: syntax/objc.vim
===================================================================
--- syntax/objc.vim 2005-03-21 02:12:49.000000000 -0800
+++ syntax/objc.vim 2006-04-24 03:19:25.000000000 -0700
@@ -43,6 +43,8 @@
 syn match  objcDirective "@class\|@end\|@defs"
 syn match  objcDirective "@encode\|@protocol\|@selector"
 
+syn keyword     objcStorageClass   in out inout byref bycopy
+
 " Match the ObjC method types
 "
 " NOTE: here I match only the indicators, this looks
@@ -73,6 +75,7 @@
   HiLink objcFactMethod Function
   HiLink objcStatement Statement
   HiLink objcDirective Statement
+  HiLink objcStorageClass StorageClass
 
   delcommand HiLink
 endif

Now type pbpaste | patch -p0.

OK, now you have modified copies of the file type detector and the Obj-C syntax coloring. Now you need a .vimrc. If you already have one, add this to it; otherwise, create it with this:

let c_gnu=1
let c_no_bracket_error=1
let objc_syntax_for_h=1
syntax enable

This makes the following changes:

c_gnu

Enables detection of some GCC extensions to C.

c_no_bracket_error

Allows {} inside of []. This lets you do compound literals inside messages; for example: [self setFrame:(NSRect){ NSZeroPoint, (NSSize){ 128.0f, 128.0f } }];

objc_syntax_for_h

Tells vim (with my modifications, that you did above) that a .h file is an Obj-C header, not a C++ header.

syntax enable

Enables syntax-highlighting.

Technorati tags: vim, Objective-C.

This bug is Xcode: Use standard Xcode text view as field editor. It was filed on 2006-04-21 at 22:03 PDT.

Summary:

Xcode's field editor should be an Xcode text view rather than a plain NSTextView, so that completion and ctrl-left/-right are supported.

Steps to Reproduce:

1. ⌥-click on a file reference in the project to rename it.
2. Press ctrl-left or ctrl-right to move within the class name.

Expected Results:

The insertion point moves to within the class name.

Actual Results:

Xcode/NSTextView beeps.

Regression:

None.

Notes:

None.

Technorati tags: Apple Bug Friday, applebugfriday.

This bug is Xcode: Cocoa Document-Based Application template uses old-style document methods. It was filed on 2006-04-21 at 21:19 PDT.

Summary:

NSDocument documentation recommends using -readFromData:ofType:error: and -dataOfType:error:, but the project template uses the older methods.

Steps to Reproduce:

1. Create a new project.
2. Use the Cocoa Document-Based Application template.

Expected Results:

MyDocument, from the new document, implements -readFromData:ofType:error: and -dataOfType:error:.

Actual Results:

MyDocument implements the deprecated methods -loadDataRepresentation:ofType: and -dataRepresentationOfType:.

Regression:

Prior to Mac OS X 10.4, this wasn't a problem, because -loadDataRepresentation:ofType: and -dataRepresentationOfType: were not deprecated.

Notes:

One could make the argument that the deprecated methods should still be implemented so that the new application is compatible with 10.3.x and earlier. But a new application is not likely to require such compatibility. Also, if this argument is indeed the motivation, then the project should target the 10.3 (or an earlier) SDK.

Technorati tags: Apple Bug Friday, applebugfriday.

This bug is Interface Builder should use +/- buttons for Outlets and Actions lists. It was filed on 2006-04-21 at 21:06 PDT.

Summary:

IB uses "Add" and "Remove" buttons on the Outlets and Actions lists; it should use +/- instead, like the Accounts prefpane.

Steps to Reproduce:

1. Inspect a class in the nib.
2. Switch to the Attributes Inspector.

Expected Results:

IB shows small square buttons labeled + and - like the Accounts prefpane has.

Actual Results:

IB shows plain "Add" and "Remove" push buttons.

Regression:

None.

Notes:

None.

Technorati tags: Apple Bug Friday, applebugfriday.

This bug is ⌘W and ⌘⌥W close Inspectors too. It was filed on 2006-04-14 at 23:45 PDT.

Summary:

When the user presses ⌘W, IB will close a floating window if it has focus. When the user presses ⌘⌥W to close all nib windows, IB also closes all of the floating windows.

Steps to Reproduce:

1. Press ⌘W or ⌘⌥W.

Expected Results:

The frontmost non-floating window closes, or all non-floating windows and no floating windows close.

Actual Results:

The frontmost window (floating or not) closes, or all windows (including floating windows) close.

Regression:

None known.

Notes:

Floating windows in IB are the Palette, the Alignment palette, and the Inspector.

Technorati tags: Apple Bug Friday, applebugfriday.

A couple of tips for using Xcode more efficiently.

• Most commands that start an operation stop it as well. ⌘B, for example, starts and stops a build. ⌘⌥R will terminate a running subprocess.

• Rule of key commands: With ⌘ and no other modifiers, the key command does at least a build. ⌘⌥ will do that thing alone, without building first. ⇧⌘ opens the progress window for that operation, without actually doing it. This applies to:

  • ⌘B/⇧⌘B (Build, Build Results)¹
  • ⌘R/⌘⌥R/⇧⌘R (Build and Run, Run, Run Log)
  • ⌘Y/⌘⌥Y/⇧⌘Y (Build and Debug, Debug Executable, Debugger).

Any other suggestions? Please post them in the comments.

1. There is no ⌘⌥B because, obviously, you cannot build without building. ↶

Technorati tags: Xcode.

This bug is Xcode's Condensed layout does not have scrollers. It was filed on 2006-04-07 at 23:42 PDT.

Summary:

The Condensed layout for Xcode's project window does not have scrollers.

Steps to Reproduce:

1. Choose "Preferences" from the Xcode menu, or press ⌘,.
2. Switch to the General pane.
3. Choose the Condensed layout.
4. Open or create a project.
5. If necessary, perform some combination of resizing the window and expanding groups and categories so that the total height of the rows of the visible items in the project window exceeds the height of the table view in that window.

Expected Results:

The window has or gains scrollers.

Actual Results:

No scrollers.

Regression:

The Default/Detail view, which is the only layout in all Mac OS X versions of Project Builder and the pre-Condensed versions of Xcode and the default in versions that do have Condensed, does not have this problem.

Notes:

The All-in-One layout does not have this problem either.

The window can be scrolled using a scroll wheel or scroll-capable trackpad, or software such as Catchy Software's MaxiMice. The window can also be indirectly scrolled by using the arrow keys to select the next item up/down.

Technorati tags: Apple Bug Friday, applebugfriday, Xcode.

UPDATE 2008-07-15: You no longer need to do this as of Xcode 3.1. Make sure you fill out your Address Book. (If you don't want to use the company name on your Address Book “Me” card, then you do need to follow these instructions.) Thanks to BJ Homer for pointing this out in his comment.

Xcode comes with a number of document templates. You see the list of them when you choose File→New Document in Xcode. The templates are actually stored at /Library/Application Support/Apple/Developer Tools/File Templates. Most files contain a header comment that looks like this:

/*
 *  «FILENAME»
 *  «PROJECTNAME»
 *
 *  Created by «FULLUSERNAME» on «DATE».
 *  Copyright «YEAR» «ORGANIZATIONNAME». All rights reserved.
 *
 */

The problem is ORGANIZATIONNAME. This gets replaced with “__MyCompanyName__”, and there is no obvious way to change this other than by changing it every time (or by editing the templates, a solution that gets clobbered when you upgrade Xcode).

I was reading Step into Xcode, and found that on page 53, it gives instructions for defeating __MyCompanyName__. Here's the important part, from the book:

defaults write com.apple.xcode PBXCustomTemplateMacroDefinitions '{ ORGANIZATIONNAME = "Joan Smith"; }'

This information is also available on this Xcode release notes page. It's slightly inaccurate (__CompanyName__ rather than __MyCompanyName__) and well-buried, but it documents the same thing as the book.

Presumably, you could override any macro name or add your own using that default. But ORGANIZATIONNAME is the important one.

I debated about posting this here (publicly, rather than only privately to the Adium and Growl developer lists), because I got the info from the book. But I decided that it's OK because (1) it is also documented by Apple and (2) it's an example of the good info in this book. So here it is.

UPDATE 2007-04-07: Markus Magnuson sagely points out that you must relaunch Xcode after making this change. This really applies to any application whose prefs you plan on hand-modifying; Xcode is no exception. Thanks for the reminder. ☺

fie on Blogger. this post isn't visible from the front page or the Dashboard, even though it exists. so I'm reposting it.

UPDATE 2006-02-25: it has been closed as a duplicate.

C99 escapes in Obj-C string contain UTF-8 interpreted as an 8-bit encoding. as last time, edited only for HTMLification.

Summary:

since C99, C has a \u escape for Unicode characters. for example, a snowman is \u2603.

when used in an Obj-C string literal (@"foo"), however, these escapes are broken.

Steps to Reproduce:

1. write a program that displays a string, created from an Obj-C string literal containing a Unicode escape.
2. compile it.
3. run it.
4. observe the display of the string.

Expected Results:

the Unicode character is displayed as such.

Actual Results:

the Unicode character's UTF-8 representation is displayed in some 8-bit encoding (possibly ISO 8859-1).

Regression:

none known.

Notes:

the bug only occurs in Obj-C string literals, not plain C string literals.

it appears that the compiler uses UTF-8 for internal storage, which works. NSConstantString, however, seems to expect ISO 8859-1, and interpret its input as such.

the enclosed tarball contains test programs (command-line) in plain C (using printf) and Obj-C (using NSLog). the plain C version works; the Obj-C does not.

I found the bug when displaying an Obj-C constant string (which had been passed through NSLocalizedString, but there is no matching localisation for it yet) as an NSMenuItem's title. so the problem is not specific to terminals or Terminal's display, nor dependent on the value of any locale environment variables.

I also attached two test cases.

Recently, I went to Apple’s games site and downloaded a bunch of puzzle/arcade games. I was dismayed to find that many of these games were distributed in formats other than UDIF (the .dmg format). So clearly this matter bears some explanation.

This is the second part of a two-part post. Part 1 came previously; it discussed the difference between compression, archive, and disk-image formats and described the different specific formats in each category. Part 2 covers why you should use a plain dmg (no StuffIt or *zip sprinkles) to distribute your software. This was originally one long post, but I Kill Billed it.