Using blocks on Objective-C, especially NSArray indexOfObjectWithOptions:passingTest:

Just recording a bunch of links when I need to deal with this topic again.

Blogs:

• http://cocoasamurai.blogspot.com/2009/09/guide-to-blocks-grand-central-dispatch.html
• http://www.fieryrobot.com/blog/2010/06/20/being-a-blockhead/

Apple:

• http://developer.apple.com/library/mac/#documentation/Cocoa/Conceptual/Blocks/Articles/00_Introduction.html
• http://developer.apple.com/library/mac/#featuredarticles/BuildingWithBlocks/
• http://developer.apple.com/library/ios/#featuredarticles/Short_Practical_Guide_Blocks/

Best example yet:

• http://developer.apple.com/library/mac/#documentation/General/Conceptual/DevPedia-CocoaCore/Block.html%23//apple_ref/doc/uid/TP40008195-CH3-SW1

Fixing SVN 'entries', and Xcode red file under SCM won't go away.

Somehow, someway, I ended with a file, which I'll call fileX, not being in the SVN repository (because I deleted it) and not having a working copy of it (again, because I wanted it gone), but there was still a record for it in <DIR>/.svn/entries. This was all Xcode's fault since I got into this situation only by using Xcode SCM operations.

I don't recall what combo of XCode SCM operations got me to this point. I started off just wanting to delete a file.

The symptom in Xcode was that fileX was under the SCM twisty in the left pane. It's name was in red. It looked like this:

I tried every operation from the CTRL-click context menu to get rid of it. Closing the project and reopening it didn't make it go away either. These tactics usually work.

I could also not Commit Entire Project because of SVN errors involving fileX.  The error dialogs were like this.

The text of the errors is:

First dialog box shown.

Error: 155005 (Working copy not locked; this is probably a bug, please report) Description Commit failed (details follow):
Error: 155005 (Working copy not locked; this is probably a bug, please report) Description: Directory '/Users/jbm/Code/MyProjectThingyHere/English.lproj/MainMenu.nib'is missing
Error: 1550010 (Can't find a working copy path) Description: Directory '/Users/jbm/Code/MyProjectThingyHere/English.lproj/MainMenu.nib'is missing

Second dialog box shown.

Error: 155016 (Working copy is corrupt) Description:
Commit failed (details follow):
Error: 155016 (Working copy is corrupt) Description:
Entry for '/Users/jbm/Code/MyProjectThingyHere/English.lproj/MainMenu.nib' has no URL

This guys blog gave me a big hint.

In any case, the solution was simple enough.

1. Start Terminal.
2. cd <DIR>/.svn.
3. vim entries
4. The records are separated by CTRL+L characters (^L).
5. Delete the record for fileX while being careful of the ^L characters.

It really is that simple, once I figured out what was going on.

Convert NIB to XIB in Interface Builder and Xcode.

Why do this? It turns out NIB files don't play nicely with SCM. XIB contains the same information as NIB, but it works with SCM. This is because NIB files are "packages" to the OS and/or file system. XIB files are just XML.

This stuff was pointed out to me by the kind gentleman, Mark, at Stack Overflow.

More info about XIB files at Apple.

1. Backup just in case. In Terminal:
1. cd ~/Code/MyThing/English.lproj/
2. cp -pr MainMenu.nib ~/tmp
2. Make certain MyThing project is closed in Xcode. The auto-add-to-project feature will invoke later if Xcode has the project open, and I had trouble with that feature.
3. In Interface Builder, File | Open Recent | MainMenu.nib - MyThing.
4. File | Save As, choose File Type Interface Builder Cocoa Document (XIB 3.x). Don't save it under ~/Code/MyThing/English.lproj, but up one level in ~/Code/MyThing.
5. You'll probably see the "foreign files" warning dialog telling you, "file .svn will not be preserved". Who cares. Press Save button.
6. Open Xcode.
7. In Xcode, left pane, CTRL-Click MainMenu.nib, Delete. Press Also Move to Trash button.
8. In left pane, CTRL-Click MyThing at top, Add | Existing Files... Choose ~/Code/MyThing/MainMenu.xib. Do not add to any targets. Other defaults in dialog box should be OK.
9. After dialog, back in left pane, CTRL-Click MainMenu.xib, Get Info.
10. In File "MainMenu.xib" Info dialog, General tab, change File Type to file.xib. Close dialog.
11. Drag MainMenu.xib into Compile Sources folder of your targets.
12. Build | Clean All Targets, followed by Build | Build, and then press the Run button in the tool bar.
13. Your application should be running like it was before with the NIB file as a resource, but now it is compiling the XIB into a NIB during build instead.
14. In Xcode, left pane, under SCM twisty, CTRL-click MainMenu.xib, Add to Repository.

Unresolved problem

When I double-click MainMenu.xib in Xcode, it opens the file in a text editor (since it is XML). In order to open it in Interface Builder, I have to CTRL-click and Open in Finder. Annoying.

I think I finally get the point of cuil.com.

Cuil.com tries to generate search results that are contextually unique. This can really come in handy when you are searching for something that may not exist, and your goal, of course, is to find out if such a thing does exist.

For example, someone asked me if WebSphere Application Server 6.1 had a significant performance penalty from generating FFDC logs. When I searched Google for "WebSphere 6.1 ffdc log creation performance" I got 1130 results. Then I would have to look at the summary paragraph for each hit and ask myself, "Does this have anything to do with a performance problem from FFDC log generation?"

Of course, the problem is that I will get lots of results where folks are saying, "Here is my performance-related problem and the accompanying ffdc logs." That is why there are 1130 hits.

The same search on Cuil yields 7 hits.

After reading the Cuil results, I still don't know the answer for certain, but I could, with a bit more confidence, write back to the person asking me the question and say that a quick Internet search did not yield any results.

Whereas with Google's search results, I still wouldn't know, and I'd also have to slog through a lot more search results before I could write back with a grain of confidence.

UPDATE (2010-10-10): My timing of this post could not have been more ironic, I now realize.  Too bad.