Archive for November, 2013

Xcode & Breakpoints

Friday, November 29th, 2013

Just some things you might already know and some not:

The most common way of adding breakpoints in Xcode is to just enable them by clicking on the left side in the Code editor.

Screen Shot 2013-11-29 at 06.50.35

In the breakpoint navigator (Cmd+7) you can now see your breakpoint – and possibly more breakpoints you already added. If you click it again, you will disable it. To remove it, delete it from the navigator or drag & drop it away to trash it. So much for the obvious part.

Now there’s so much more you can do with breakpoints. First of all, breakpoints can be in different scopes:

  • Workspace
  • User (Global)
  • Project

Just right click it and select “Move Breakpoint to”. If you move it to “User”, it will show up in all your Xcode projects or workspaces you open with your current user.

The most common “User”-scope breakpoint is the symbolic breakpoint to objc_exception_throw in libobjc.A.dylib.

Now if you right-click again and click “Edit Breakpoint…”, you will start to scratch the surface of the world of breakpoints. You can execute scripts, debugger or shell commands, log messages or even play a sound (w00t!). Keep in mind, that whatever you do there will interrupt the execution of your application until whatever you selected here is finished. A typical debugger command you might want to execute is bt which will show a backtrace (call hierarchy) at the current position in code.

Next, another powerful feature is symbolic breakpoints. You can add symbolic breakpoints to object-specific symbols (-[UIViewController viewWillAppear]) or even just symbols (viewWillAppear). Just try it and you will suddenly get insight to a huge bunch of internal object classes you never heard of. The latter will break your execution each time any object receives the viewWillAppear message.

Next, watch points. In some situations you might wonder why some property or object value changes and you just don’t understand why. No problem, just add a watch point to that property! Just use any breakpoint to pause execution of you app and take a look at the Debug area.

Screen Shot 2013-11-29 at 07.09.29

Right-click any of the variables you see there and select Watch. From now on, every time the variable changes, your app will be interrupted. Keep in mind, that variables change when non-object types change (like an NSInteger increases) or object pointers change. For example, appending something to a NSMutableString does not change the object pointer, so the watchpoint will not fire. By default, watch points will fire on “write”, however you can also watch reads. Watchpoints will show up in the Breakpoint Navigator too.

Every time your app gets interrupted, you can also use the debug console (lldb by default) and write what we just did as a command there. This is much more powerful as you can do even more there. Just take some time and read the command documentation

If you are already familiar with gdb and want to know how you do the same with lldb there’s a nice GDB to LLDB command map.

Happy debugging!

Useful things when working with git

Wednesday, November 27th, 2013

So you’re working with git and you think it’s the best thing that every happened to you? Same with me, however there are a few settings that make working with git even more fun! Here they are:

This will always assume you want to push you current branch to origin with the same name (like develop to origin/develop).

More or less the same thing, just in the other direction. When you pull, git will assume you want to fetch & merge the origin branch with the same name.

This will disable fast-forward when doing merges. This means, that even if there is no merge needed (because one of the parents is the common ancestor), there will still be a merge commit. This is useful to keep track of the branch history.

This will tell git to use style diff3 to solve conflicts. Compared to the default style, this will also add the common ancestor version in the conflicting file, showing not only the result in both branches, but also the state before the changes. This often helps to resolve conflicts easier.

This tells git to remember how you solved a conflict. When a conflict appears, git will check the conflict history database and uses the same solution if the conflict is the same. Very helpful if you have conflicts that appear again and again (like storyboard files or submodules).