Understanding LLDB contexts in Xcode

Sometimes when debugging on Xcode with LLDB’s p or po on a a codebase that have both Objective-C and Swift, Xcode will throw a syntax error at you and you might be wondering out why? You checked for any typos but everything seems to be correct. So what gives?

Well, that’s because you might be using it in the wrong context.

Here’s a quick rundown:

  1. When you stop in Objective-C code using breakpoint, LLDB will use Objective-C debugging context.

    So you have to use Objective-C syntax to debug:

    (lldb) po [ViewController description]
  2. Similarly when you add a breakpoint in Swift code, LLDB will use Swift debugging context instead.

    So you have to use Swift syntax to debug:

    (lldb) po ViewController.description()
  3. And finally, Xcode will always use Objective-C as the default context. Meaning if you pause the program execution without using breakpoint, you’ll have to use Objective-C syntax.

That’s it. Hopefully this tips will helps you a little bit when debugging a project that have a mixture of both Swift and Objective-C codes. ✌️

How to use Go Dep to Manage Dependencies

dep is a dependency management tool for golang. If you have work on other programming languages, dep is similar to npm, pod or pip. In simple words, it is a package manager to manage your project’s third party libraries.

How to install it

There’s a few ways to install dep. Personally, I prefer to install it with Homebrew To install it run:

$~ brew install dep

Initializing a project with dep

To initialize it in your go project, go to your project directory and run the following

$~ dep init

This will create three things in your directory

  1. Gopkg.toml: This where you specifies the project dependencies
  2. Gopkg.lock: File generated as a result from running dep. It’s a complete dependency graph for your project. You shouldn’t edit this manually.
  3. vendor/: This is where the dependencies are stored

dep init will behave differently depending on the state of your project.

If it is a new project, Gopkg.toml and vendor/ will be essentially empty aside from the usual commented out guides on how to use it.

If it is an existing project, Gopkg.toml adn vendor/ will add all the dependencies that you have added in your project with go get.

How to use dep?

Adding a new depencies

To add a new depencies in your project, run the following

$~ dep ensure -add <DEPENDENCIES>

Replace <DEPENDENCIES> with the path to its project repo. For example

$~ dep ensure -add github.com/gorilla/mux

Others

A few more commands that I find useful:

  1. dep status: Will report the status of your project dependencies
  2. dep prune: Will tell you which libraries that are out of sync

Conclusion

I am sure by now you are asking “why should I use go dep when go already comes with go get?”.

Well, imagine you are working in a team project that uses a lot of dependencies. Each having their own version of libraries. Pretty soon you will have those “Works on my machine!” real quick.

dep solve this by making sure everyone who works on the project is guaranteed to be using the same version of dependencies.

That’s it. Hopefully now you have learned the basic usage sof go dep to manage your project dependencies.

How to Change Git Branch Name

Here’s a quick reference on how you can change your git branch name:

If you want to rename of your current local branch:

git branch -m new-branch-name

If you want to change the name of a different local branch

git branch -m old-branch new-branch-name

That’s it. Bye.

How to set default git push behaviour

Oftentimes, I forget that I have to specify the current branch name when pushing it to a remote.

For example:

$~ git push

or like this

$~ git push -u origin

Either way, these commands will fail since I didn’t specify the upstream branch. git will return an error similar like this:

fatal: The current branch develop has no upstream branch.
To push the current branch and set the remote as upstream, use

    git push --set-upstream origin <INSERT BRANCH NAME HERE>

To avoid this error, I have to set the upstream branch name explicitly first before pushing it to the remote repository. For example:

$~ git push -u origin <INSERT BRANCH NAME HERE>

However, this approach can get pretty tedious since the name of my branches are usually long and usually prefixes with feature/, chore/ or fix/. I can’t exactly depend on tab-completion either since I have to tab multiple times before pushing in the branch that I wanted to.

Good thing that there is a way for me to implicitly push the current branch by configuring the default git behaviour. Regardless if the branch already exists in upstream or not. Neat right? To do this simply run the following in your terminal:

$~ git config --global push.default current

git will then implicitly assume that I want to push my current branch to upstream. With the configuration set up, I can now simply push my current branch to upstream with the simple command of:

$~ git push

That’s really short and simple. Pretty neat right?


How to set zsh as the default terminal shell

I prefer zsh over bash as my everyday shell. Unfortunately, zsh is not the default shell on macOS.

Here’s a quick guide on how to make it as a default shell for your machine:

1. Install zsh

Make sure zsh is available on your system. If not, install it with brew.

$~ brew install zsh

$~ which zsh
/usr/local/bin/zsh #output

2. Set zsh as default shell

To set is as default shell, run the following in your terminal:

$~ sudo sh -c "echo $(which zsh) >> /etc/shells"
$~ chsh -s $(which zsh)

Then, simply reopen your shell again and it should used zsh as the default shell. That’s it.

To check which shell you’re using

If you are still unsure whether your shell is running zsh or bash, run the following in your terminal:

$~ echo $0
-zsh  #output