413.srt

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:00:11.446 --> 00:00:15.166 A:middle
>> Good morning and welcome to
Advanced Debugging with LLDB.

00:00:15.976 --> 00:00:19.126 A:middle
[ Applause ]

00:00:19.626 --> 00:00:21.286 A:middle
I hope you're having
a great show so far,

00:00:21.326 --> 00:00:23.186 A:middle
we've got one last day
of content for you.

00:00:23.186 --> 00:00:25.706 A:middle
So let's make the most of
it by starting with one

00:00:25.706 --> 00:00:27.266 A:middle
of the more important
topics when it comes

00:00:27.266 --> 00:00:30.486 A:middle
to software development, making
sure that everything is clean

00:00:30.486 --> 00:00:32.726 A:middle
and polished in your
application before it goes live.

00:00:33.456 --> 00:00:36.216 A:middle
My name is Kate Stone I manage
the team responsible for LLDB.

00:00:36.216 --> 00:00:38.366 A:middle
I'm going to get things
going here, but I'm going

00:00:38.366 --> 00:00:41.256 A:middle
to spend most of the time in
the session turning things

00:00:41.256 --> 00:00:43.666 A:middle
over to my engineers who
walk you through some

00:00:43.666 --> 00:00:46.986 A:middle
of the exciting things
that we love about LLDB

00:00:46.986 --> 00:00:50.056 A:middle
that you deserve
to know about too.

00:00:50.286 --> 00:00:51.716 A:middle
So what should you
expect from this talk?

00:00:52.726 --> 00:00:55.456 A:middle
Well, the vast majority of
our time here is spent focused

00:00:55.456 --> 00:00:58.516 A:middle
on LLDB as the foundation
for the debugging experience.

00:00:59.386 --> 00:01:02.546 A:middle
LLDB is essentially a library
that knows how to do all kinds

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:00:59.386 --> 00:01:02.546 A:middle
LLDB is essentially a library
that knows how to do all kinds

00:01:02.546 --> 00:01:04.916 A:middle
of interesting things with
the running application.

00:01:05.676 --> 00:01:07.006 A:middle
It's a command line experience

00:01:07.316 --> 00:01:09.366 A:middle
but it's also the
foundation for Xcode.

00:01:09.936 --> 00:01:12.396 A:middle
So while we'll talk about how
to use it from a command line,

00:01:12.566 --> 00:01:14.226 A:middle
we'll talk about
the Xcode experience

00:01:14.616 --> 00:01:17.036 A:middle
to really understand
what Xcode adds on top

00:01:17.036 --> 00:01:19.426 A:middle
of our debugging
foundation, you should go back

00:01:19.426 --> 00:01:21.906 A:middle
and watch the video for the
debugging with Xcode session,

00:01:22.316 --> 00:01:23.916 A:middle
which unfortunately, it
was earlier this week,

00:01:23.916 --> 00:01:27.016 A:middle
but there's a lot
of good news there.

00:01:27.226 --> 00:01:29.146 A:middle
What we're going to
talk about here are tips

00:01:29.196 --> 00:01:30.946 A:middle
to streamline your
debugging experience.

00:01:31.366 --> 00:01:34.086 A:middle
So you've doubtless know a
lot about debugging already,

00:01:34.446 --> 00:01:36.446 A:middle
but if you haven't worked
with LLDB extensively,

00:01:36.446 --> 00:01:38.006 A:middle
you may not be aware
of everything

00:01:38.006 --> 00:01:39.116 A:middle
that you can do with
the product.

00:01:39.646 --> 00:01:42.426 A:middle
And specifically, we're going to
talk about it not just as a tool

00:01:42.426 --> 00:01:43.766 A:middle
for finding and fixing bugs.

00:01:43.766 --> 00:01:46.356 A:middle
But we're going to talk about,
it is an investigative tool

00:01:46.756 --> 00:01:49.516 A:middle
for looking at your application,
understanding what's going on,

00:01:49.586 --> 00:01:52.256 A:middle
perhaps when you've written a
new feature to walk through it

00:01:52.256 --> 00:01:54.286 A:middle
to make sure that it's working
the way you expect it to.

00:01:54.536 --> 00:01:56.196 A:middle
It's not always about going in

00:01:56.196 --> 00:02:00.016 A:middle
and finding a specific
defect in your code.

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:01:56.196 --> 00:02:00.016 A:middle
and finding a specific
defect in your code.

00:02:00.236 --> 00:02:01.846 A:middle
Because our collective
goal is to make sure

00:02:01.846 --> 00:02:04.826 A:middle
that your applications
are as reliable as solid

00:02:04.826 --> 00:02:07.976 A:middle
as they can possibly be by the
time they reach your end users.

00:02:09.106 --> 00:02:10.656 A:middle
So that's our focus
for the session.

00:02:10.916 --> 00:02:12.966 A:middle
Let's keep our eye in
your apps and making sure

00:02:12.966 --> 00:02:15.076 A:middle
that they can be the
best apps possible.

00:02:15.476 --> 00:02:18.976 A:middle
What does LLDB look like today?

00:02:19.596 --> 00:02:23.956 A:middle
Well, LLDB as you know is our
ground-up replacement for GDB.

00:02:23.956 --> 00:02:27.236 A:middle
We both-- from the ground-up
this tool, this is designed

00:02:27.236 --> 00:02:29.506 A:middle
to be incredibly
flexible, this is designed

00:02:29.596 --> 00:02:30.696 A:middle
to accommodate the needs

00:02:30.696 --> 00:02:33.776 A:middle
of applications looking
forward rather than backward.

00:02:34.536 --> 00:02:36.886 A:middle
So with that in mind, we
focused on making sure

00:02:36.886 --> 00:02:40.366 A:middle
that it is absolutely
rock solid, this release.

00:02:41.076 --> 00:02:43.086 A:middle
If you have any issues,
whatsoever,

00:02:43.296 --> 00:02:44.766 A:middle
make sure that we
hear about them

00:02:44.766 --> 00:02:48.186 A:middle
because when Xcode5
shifts LLDB will be your

00:02:48.186 --> 00:02:49.226 A:middle
debugging experience.

00:02:49.966 --> 00:02:52.506 A:middle
What have we done?

00:02:53.206 --> 00:02:56.016 A:middle
We've put in hundreds of
improvements this release.

00:02:56.216 --> 00:02:59.376 A:middle
A lot of them are relatively
subtle, you'll see a lot

00:02:59.376 --> 00:03:02.656 A:middle
of the old features working
faster, more predictably

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:02:59.376 --> 00:03:02.656 A:middle
of the old features working
faster, more predictably

00:03:02.916 --> 00:03:04.726 A:middle
with fewer edge cases
that you need to worry

00:03:04.726 --> 00:03:05.766 A:middle
about than never before.

00:03:06.326 --> 00:03:09.256 A:middle
But we've also focused on
data inspection in particular.

00:03:09.916 --> 00:03:12.346 A:middle
When you're looking at
standard system types,

00:03:12.556 --> 00:03:14.616 A:middle
when you're looking at
anything from foundation

00:03:14.866 --> 00:03:17.546 A:middle
or if you're looking for a
C++ standard library type,

00:03:17.766 --> 00:03:20.856 A:middle
you should get a more reasonable
summary now, you should be able

00:03:20.856 --> 00:03:23.816 A:middle
to get summaries for things
like NSErrors, for NSSets,

00:03:24.406 --> 00:03:27.096 A:middle
things that, again, you
could dig in to before

00:03:27.096 --> 00:03:28.716 A:middle
but now we'll tell
you the information

00:03:28.716 --> 00:03:30.456 A:middle
that you were looking for
right out of the gate.

00:03:30.456 --> 00:03:34.976 A:middle
Our expression parser
is always improving.

00:03:35.256 --> 00:03:37.906 A:middle
It's not necessarily something
that my team is responsible for,

00:03:38.196 --> 00:03:41.736 A:middle
more importantly because my team
took the idea that we wanted

00:03:41.736 --> 00:03:44.366 A:middle
to rely on clang as
our expression parser.

00:03:44.826 --> 00:03:48.666 A:middle
We have a full compiler built
into the product, any expression

00:03:48.666 --> 00:03:50.416 A:middle
that would normally
parse and run as part

00:03:50.416 --> 00:03:53.056 A:middle
of your source code will
work in LLDB as well.

00:03:53.516 --> 00:03:56.026 A:middle
So we're always up-to-date with
the latest language features.

00:03:56.396 --> 00:03:59.736 A:middle
When we added things along
the lines of the new syntax

00:03:59.736 --> 00:04:02.366 A:middle
for Objective-C,
Objective-Constants,

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:03:59.736 --> 00:04:02.366 A:middle
for Objective-C,
Objective-Constants,

00:04:02.956 --> 00:04:06.556 A:middle
they just showed up in LLDB and
that's through going forward

00:04:06.556 --> 00:04:09.056 A:middle
as well, every new language
feature should be part

00:04:09.056 --> 00:04:09.706 A:middle
of our debugger.

00:04:10.846 --> 00:04:11.976 A:middle
One of the things that's tricky

00:04:11.976 --> 00:04:14.686 A:middle
about this is while we pass
the text that you give us

00:04:14.686 --> 00:04:16.606 A:middle
for an expression
directly to the compiler,

00:04:17.716 --> 00:04:20.606 A:middle
the context that we set
up for, we have to infer

00:04:20.886 --> 00:04:22.086 A:middle
from looking at that code.

00:04:22.346 --> 00:04:24.436 A:middle
So as a result, you may
have found in the past

00:04:24.436 --> 00:04:26.286 A:middle
that you needed to
cast the result

00:04:26.406 --> 00:04:28.336 A:middle
so that we knew what
the result type was

00:04:28.596 --> 00:04:30.206 A:middle
and could explore
it appropriately.

00:04:30.626 --> 00:04:33.026 A:middle
You'll find that in most
cases, we can now infer that

00:04:33.026 --> 00:04:36.036 A:middle
and far fewer explicit
casts are required

00:04:36.036 --> 00:04:37.856 A:middle
for the expression evaluator.

00:04:38.516 --> 00:04:44.106 A:middle
[ Applause ]

00:04:44.606 --> 00:04:47.096 A:middle
So let's think a little bit
about the debugging experience.

00:04:47.206 --> 00:04:48.076 A:middle
What is it that you should do?

00:04:48.076 --> 00:04:50.106 A:middle
Well, to start with,
you should go

00:04:50.106 --> 00:04:51.856 A:middle
into debugging a
particular problem

00:04:51.856 --> 00:04:54.926 A:middle
or exploring something
really well-informed.

00:04:55.526 --> 00:04:56.976 A:middle
There are a bunch of
techniques for doing this

00:04:56.976 --> 00:04:58.336 A:middle
that we'll cover
in detail later.

00:04:58.596 --> 00:05:01.596 A:middle
They should be familiar
ideas, things like assertions

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:04:58.596 --> 00:05:01.596 A:middle
They should be familiar
ideas, things like assertions

00:05:01.596 --> 00:05:04.156 A:middle
and logging, static
analysis, and using some

00:05:04.156 --> 00:05:07.526 A:middle
of the runtime tools that
will watch your code for us

00:05:07.826 --> 00:05:09.386 A:middle
and tell you, here's
what's going

00:05:09.386 --> 00:05:10.906 A:middle
on that you might
need to be aware of.

00:05:11.536 --> 00:05:13.716 A:middle
But you should also
focus on unit tests.

00:05:14.536 --> 00:05:18.166 A:middle
A unit test will tell you that
this is the narrow situation

00:05:18.296 --> 00:05:20.116 A:middle
in which your code is
not behaving the way you

00:05:20.116 --> 00:05:20.836 A:middle
expected to.

00:05:21.166 --> 00:05:23.336 A:middle
So if you are already
writing a lot of unit test,

00:05:23.646 --> 00:05:26.746 A:middle
make sure you review the
unit testing in Xcode session

00:05:27.026 --> 00:05:31.106 A:middle
to get some idea
what that intends.

00:05:31.106 --> 00:05:34.696 A:middle
And lastly, we need to trust
the Xcode debug configuration.

00:05:35.056 --> 00:05:38.056 A:middle
Out of the box, a new project
in Xcode will be configured

00:05:38.316 --> 00:05:41.566 A:middle
to build debug information,
you need to make sure that,

00:05:41.566 --> 00:05:43.336 A:middle
that's what you're
feeding to the debugger

00:05:43.466 --> 00:05:44.826 A:middle
that you weren't
stripping that away

00:05:44.976 --> 00:05:46.606 A:middle
or else you won't be
able to find symbols.

00:05:47.136 --> 00:05:49.256 A:middle
You need to make sure that
optimization is disabled

00:05:49.256 --> 00:05:51.536 A:middle
which it is by default or
you'll find that stepping

00:05:51.536 --> 00:05:53.446 A:middle
through your code and
leads to surprises.

00:05:53.916 --> 00:05:56.766 A:middle
If you attach to a running
application, you may find

00:05:56.766 --> 00:06:00.156 A:middle
that these have not
been taken care of,

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:05:56.766 --> 00:06:00.156 A:middle
that these have not
been taken care of,

00:06:00.526 --> 00:06:02.306 A:middle
that's why you're not getting
the information you need

00:06:02.306 --> 00:06:03.396 A:middle
if that's why you're
not stepping

00:06:03.396 --> 00:06:04.906 A:middle
through code in a
logical fashion.

00:06:05.216 --> 00:06:07.996 A:middle
Going back in building with the
debug configuration is always a

00:06:07.996 --> 00:06:11.416 A:middle
good idea for debug session.

00:06:11.576 --> 00:06:14.536 A:middle
Secondly, we need to avoid
some of the common mistakes.

00:06:14.616 --> 00:06:17.156 A:middle
You can go and you can do
the brute-force debugging.

00:06:17.596 --> 00:06:20.676 A:middle
Everybody knows how to do
this, set a breakpoint right

00:06:20.676 --> 00:06:22.926 A:middle
at the beginning of our
code and step, step our way

00:06:22.926 --> 00:06:24.026 A:middle
to where we need to get to.

00:06:24.186 --> 00:06:26.736 A:middle
But in practice, that's
not the most efficient way

00:06:26.956 --> 00:06:28.506 A:middle
to take advantage of LLDB.

00:06:28.676 --> 00:06:31.556 A:middle
So during the session, we'll
talk about how to stop exactly

00:06:31.556 --> 00:06:35.676 A:middle
where you want to, not keep
running 20 times until you get

00:06:35.676 --> 00:06:38.186 A:middle
to the right pass,
how to stop actually

00:06:38.186 --> 00:06:39.716 A:middle
under the conditions
you're interested in.

00:06:40.836 --> 00:06:43.096 A:middle
How to then customize
what you're seeing

00:06:43.276 --> 00:06:45.596 A:middle
with custom formatters
and custom commands

00:06:45.906 --> 00:06:47.746 A:middle
because we're going to give
you a reasonable format

00:06:47.996 --> 00:06:50.866 A:middle
for system types, but we don't
know about your types yet.

00:06:51.226 --> 00:06:52.926 A:middle
We'll allow you to
introduce us to your types

00:06:53.176 --> 00:06:54.876 A:middle
and tell us what's
interesting about them.

00:06:55.726 --> 00:07:00.146 A:middle
And lastly, we want to focus
on how you can write debug code

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:06:55.726 --> 00:07:00.146 A:middle
And lastly, we want to focus
on how you can write debug code

00:07:00.386 --> 00:07:02.916 A:middle
without stopping your
project altering your source,

00:07:02.916 --> 00:07:04.846 A:middle
going through rebuild
cycle and then trying

00:07:04.846 --> 00:07:05.956 A:middle
to get back to that state.

00:07:06.476 --> 00:07:08.596 A:middle
Because again, we've got a
full expression evaluator,

00:07:08.816 --> 00:07:11.406 A:middle
you can write incredibly
sophisticated code right there

00:07:11.406 --> 00:07:14.376 A:middle
in the debugger to alter the way
your application is executing

00:07:14.466 --> 00:07:16.696 A:middle
and explore things that
your source may not

00:07:16.696 --> 00:07:20.316 A:middle
yet be set up for.

00:07:20.536 --> 00:07:23.086 A:middle
Along the way though, especially
when you're taking the advantage

00:07:23.086 --> 00:07:25.586 A:middle
of the expression evaluator, you
should watch out for the fact

00:07:25.586 --> 00:07:27.596 A:middle
that while the debugger
goes well out of its way

00:07:27.596 --> 00:07:28.896 A:middle
to avoid side effects.

00:07:29.626 --> 00:07:33.366 A:middle
If you're telling us explicitly
to run some code, we are running

00:07:33.366 --> 00:07:34.926 A:middle
that code in your
live application,

00:07:34.926 --> 00:07:38.596 A:middle
it can change the state of
things that can be a good thing

00:07:38.826 --> 00:07:40.466 A:middle
if your intent is to try to work

00:07:40.466 --> 00:07:43.376 A:middle
around an issue during the
debug session or a bad thing

00:07:43.376 --> 00:07:45.566 A:middle
if you're trying to see exactly
what your application is going

00:07:45.566 --> 00:07:47.156 A:middle
to do without the
debugger attached.

00:07:49.556 --> 00:07:50.886 A:middle
So for the rest of this session,

00:07:51.296 --> 00:07:53.546 A:middle
the focus is this
canonical process

00:07:53.546 --> 00:07:55.816 A:middle
of how do I use the
debugger each and every time

00:07:56.046 --> 00:07:57.156 A:middle
to catch those tasty bugs?

00:07:58.946 --> 00:08:01.986 A:middle
The answer is step one we
need to pick our focus.

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:07:58.946 --> 00:08:01.986 A:middle
The answer is step one we
need to pick our focus.

00:08:02.506 --> 00:08:03.666 A:middle
We need to choose what it is

00:08:03.696 --> 00:08:04.906 A:middle
that we're trying
to investigate?

00:08:04.906 --> 00:08:06.926 A:middle
What's the question
that we have in mind

00:08:06.926 --> 00:08:08.146 A:middle
that the debugger
can help answer?

00:08:09.386 --> 00:08:13.546 A:middle
Step two, how do I stop right
before the interesting path

00:08:14.136 --> 00:08:17.616 A:middle
before the problem has
occurred but not so far from it

00:08:17.616 --> 00:08:21.236 A:middle
that we're going to be
stepping endlessly to get there.

00:08:21.456 --> 00:08:23.616 A:middle
Then we need to step
through our live code looking

00:08:23.616 --> 00:08:25.826 A:middle
at the interesting things
that are going on the path

00:08:25.926 --> 00:08:29.436 A:middle
that it's following, and
looking at data along the way.

00:08:29.876 --> 00:08:31.666 A:middle
So we understand the
state of our application

00:08:31.826 --> 00:08:33.336 A:middle
and the changes that
are being made.

00:08:33.796 --> 00:08:37.765 A:middle
So our focus here is to help you
be experts at all of the above.

00:08:39.155 --> 00:08:41.666 A:middle
To get it started, I'd like
to invite up Sean Callan,

00:08:41.866 --> 00:08:43.716 A:middle
one of my engineers
who will walk you

00:08:43.716 --> 00:08:46.866 A:middle
through a few incredibly
helpful tips at the start

00:08:46.866 --> 00:08:49.886 A:middle
of this process, but you should
also tackle them in the labs,

00:08:49.886 --> 00:08:52.346 A:middle
if you have any questions at all
about the expression evaluator

00:08:52.606 --> 00:08:54.186 A:middle
because he is our
expert on the subject.

00:08:54.726 --> 00:08:55.226 A:middle
Thank you, Sean.

00:08:59.186 --> 00:09:00.006 A:middle
>> Thank you very much, Kate.

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:08:59.186 --> 00:09:00.006 A:middle
>> Thank you very much, Kate.

00:09:00.756 --> 00:09:04.066 A:middle
I'm really excited to show you
all the great ways you can debug

00:09:04.066 --> 00:09:04.906 A:middle
with LLDB.

00:09:05.496 --> 00:09:07.706 A:middle
But I think one of the most
important things to understand

00:09:07.706 --> 00:09:11.466 A:middle
when you're debugging is when
to use LLDB and what sort

00:09:11.466 --> 00:09:13.746 A:middle
of information can help you
out when you're debugging.

00:09:16.296 --> 00:09:21.876 A:middle
So one situation where LLDB
might not be the first stop

00:09:21.876 --> 00:09:25.316 A:middle
for you is if you're not sure
whether your program has a bug

00:09:25.316 --> 00:09:27.896 A:middle
in the first place.

00:09:28.096 --> 00:09:32.566 A:middle
One way you can check, whether
what your assumptions are,

00:09:32.716 --> 00:09:34.196 A:middle
or actually what's happening

00:09:34.196 --> 00:09:36.486 A:middle
in your code is by
using assertions.

00:09:37.536 --> 00:09:40.416 A:middle
Now what assertions
let you do is express

00:09:40.716 --> 00:09:42.826 A:middle
that you make a particular
assumption

00:09:43.046 --> 00:09:45.396 A:middle
and you believe this
is not only unlikely

00:09:45.576 --> 00:09:47.006 A:middle
but it's actually impossible.

00:09:48.026 --> 00:09:51.836 A:middle
Now remember, as programmers, we
want to be using arrow handling

00:09:52.066 --> 00:09:53.736 A:middle
to count, to handle the cases

00:09:53.736 --> 00:09:56.656 A:middle
that we actually think are
possible just, you know,

00:09:56.656 --> 00:09:59.396 A:middle
that are, that where our
program won't work correctly.

00:09:59.906 --> 00:10:03.966 A:middle
So this is really for
cases where your app is,

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:09:59.906 --> 00:10:03.966 A:middle
So this is really for
cases where your app is,

00:10:04.306 --> 00:10:07.336 A:middle
has encountered something
that just can't be.

00:10:08.126 --> 00:10:11.096 A:middle
Now another case where
assertions can be handy is

00:10:11.096 --> 00:10:14.576 A:middle
if you have internal
APIs between components

00:10:15.196 --> 00:10:18.506 A:middle
and they have contract between
them that shouldn't be violated.

00:10:18.506 --> 00:10:21.116 A:middle
Now remember, that's
for internal APIs.

00:10:21.116 --> 00:10:23.226 A:middle
For external APIs,
you really want

00:10:23.226 --> 00:10:24.816 A:middle
to be using correct
error handling.

00:10:25.636 --> 00:10:28.796 A:middle
What an assertion will do is
if this contract is violated,

00:10:29.026 --> 00:10:33.056 A:middle
your application will
crash right then and there.

00:10:33.276 --> 00:10:37.886 A:middle
Now having your application
crash deliberately isn't exactly

00:10:37.886 --> 00:10:39.806 A:middle
a recipe for good
reviews on the App Store.

00:10:40.166 --> 00:10:44.226 A:middle
So you want to make sure that
the assertions are disabled

00:10:44.226 --> 00:10:45.066 A:middle
when you build release.

00:10:45.906 --> 00:10:49.126 A:middle
Xcode does that for you and
now default project templates,

00:10:49.406 --> 00:10:52.246 A:middle
we've disabled assertions
when you build release.

00:10:52.986 --> 00:10:55.046 A:middle
Now there's one other thing

00:10:55.046 --> 00:10:57.166 A:middle
about assertions you
have to be aware of.

00:10:58.076 --> 00:11:00.516 A:middle
When you've got an assertion
compiled into your code,

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:10:58.076 --> 00:11:00.516 A:middle
When you've got an assertion
compiled into your code,

00:11:01.646 --> 00:11:06.046 A:middle
the condition is evaluated
only if the assertion is there.

00:11:06.296 --> 00:11:09.416 A:middle
So your condition should
not do useful work otherwise

00:11:09.416 --> 00:11:11.946 A:middle
when you build release
that useful work is gone.

00:11:11.946 --> 00:11:13.276 A:middle
All right.

00:11:13.436 --> 00:11:18.506 A:middle
Now let's say, you don't have
a clear red flag that says, OK,

00:11:18.506 --> 00:11:19.476 A:middle
something's going wrong.

00:11:20.576 --> 00:11:26.056 A:middle
You more have behaviors in your
app where over a period of time,

00:11:26.246 --> 00:11:30.566 A:middle
your app gets, you know, through
code pass that look reasonable

00:11:30.726 --> 00:11:32.566 A:middle
but ends up somewhere
where it shouldn't be.

00:11:33.186 --> 00:11:35.426 A:middle
This is where logging
can be really handy.

00:11:36.976 --> 00:11:40.596 A:middle
Now you all maybe familiar
with NSLog, but what I'm going

00:11:40.596 --> 00:11:43.226 A:middle
to tell you about is
the Apple System Log.

00:11:44.506 --> 00:11:47.126 A:middle
Logging let's you review
execution of your code

00:11:47.126 --> 00:11:49.766 A:middle
after the fact and
the Apple System Log,

00:11:49.766 --> 00:11:55.086 A:middle
you can review using the
console.app utility on your Mac.

00:11:55.226 --> 00:11:58.956 A:middle
One great feature of the Apple
System Log is you can indicate

00:11:59.076 --> 00:12:02.306 A:middle
how severe the log messages
are that you're sending out.

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:11:59.076 --> 00:12:02.306 A:middle
how severe the log messages
are that you're sending out.

00:12:03.386 --> 00:12:07.236 A:middle
You can distinguish between
absolute emergencies, oh,

00:12:07.236 --> 00:12:09.296 A:middle
my God, stop now,
this is terrible.

00:12:10.096 --> 00:12:14.126 A:middle
And just debug information that
you want to communicate just

00:12:14.126 --> 00:12:17.746 A:middle
to let into the program or
the user know what's going on.

00:12:18.566 --> 00:12:21.216 A:middle
Now I've shown you two
levels, the most severe

00:12:21.216 --> 00:12:23.366 A:middle
and the least severe,
but there's a gradient

00:12:23.366 --> 00:12:24.736 A:middle
in between them that
you can use.

00:12:26.306 --> 00:12:28.846 A:middle
Now another cool thing you
can do with logging is,

00:12:29.176 --> 00:12:31.576 A:middle
you can use hashtags
kind of like in Twitter.

00:12:32.366 --> 00:12:35.676 A:middle
Now hastags are not some
magic, you just search for them

00:12:35.676 --> 00:12:38.986 A:middle
in console.app and you can find
all the logs that are relevant

00:12:38.986 --> 00:12:40.346 A:middle
to that part of your program.

00:12:41.756 --> 00:12:44.256 A:middle
One other single-- to
remember with logs is,

00:12:44.696 --> 00:12:47.356 A:middle
sometimes you get really
enthusiastic and you're like,

00:12:47.356 --> 00:12:48.706 A:middle
oh, I love this logging thing,

00:12:48.816 --> 00:12:51.506 A:middle
I'm going to dump all my data
structures out to the log just

00:12:51.506 --> 00:12:53.546 A:middle
to see what could
might, maybe go wrong.

00:12:53.546 --> 00:12:57.166 A:middle
Now that's going to mean, your
program is going to spend time

00:12:57.366 --> 00:12:59.376 A:middle
in looking through with
state of structures

00:12:59.656 --> 00:13:00.776 A:middle
and printing everything.

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:12:59.656 --> 00:13:00.776 A:middle
and printing everything.

00:13:01.406 --> 00:13:03.416 A:middle
Now maybe, you want to
turn that on and off

00:13:03.636 --> 00:13:05.996 A:middle
so that your program isn't
spending all that time

00:13:05.996 --> 00:13:07.056 A:middle
when you don't care about it.

00:13:08.286 --> 00:13:10.926 A:middle
Now there are a couple of ways
doing this and I'm not going

00:13:10.926 --> 00:13:13.696 A:middle
to tell you anyway this
app is terribly wrong.

00:13:14.246 --> 00:13:17.836 A:middle
I've seen people use
compile-time debug--

00:13:17.836 --> 00:13:21.356 A:middle
compile-time hash defines to
enable and disable logging.

00:13:21.356 --> 00:13:25.126 A:middle
I've also seen people use
environment variables.

00:13:25.846 --> 00:13:27.676 A:middle
One of my favorite
ways of enabling

00:13:27.676 --> 00:13:31.056 A:middle
and disabling logging is using
the NSUserDefault subsystem.

00:13:31.416 --> 00:13:34.336 A:middle
With NSUserDefaults which
you can look up in man pages,

00:13:34.336 --> 00:13:39.436 A:middle
you can set a variable and pick
up from the command line that is

00:13:39.496 --> 00:13:41.816 A:middle
from your shell and
just picks that up

00:13:41.816 --> 00:13:43.216 A:middle
from your app as it's running.

00:13:43.216 --> 00:13:45.906 A:middle
So it's a great way to
turn off and on logging.

00:13:45.906 --> 00:13:52.296 A:middle
Now, I've shown you a couple
of ways of making your program,

00:13:52.586 --> 00:13:55.196 A:middle
use your DDbug by
modifying your source code.

00:13:55.676 --> 00:13:59.586 A:middle
But we've also provided you with
some great ways inside Xcode

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:14:00.016 --> 00:14:01.736 A:middle
to find bugs in your program.

00:14:02.786 --> 00:14:05.046 A:middle
Double your everything in clang

00:14:06.096 --> 00:14:08.866 A:middle
and the static analyzer
are great ways

00:14:09.096 --> 00:14:12.736 A:middle
to find problems before you
even start running your program.

00:14:14.166 --> 00:14:16.916 A:middle
Another couple of tools that you
can use while your program is

00:14:16.946 --> 00:14:20.426 A:middle
running are Guard Malloc
and Zombie Objects.

00:14:21.116 --> 00:14:23.676 A:middle
Now there are great
sessions both this year

00:14:23.816 --> 00:14:26.986 A:middle
and in previous years which
cover both of these areas.

00:14:27.366 --> 00:14:29.086 A:middle
So I'm not going to go
into too much detail,

00:14:29.086 --> 00:14:31.166 A:middle
but do check those out.

00:14:32.176 --> 00:14:33.416 A:middle
All right.

00:14:33.416 --> 00:14:35.796 A:middle
Now we've gone on and off
about what to do before you get

00:14:35.796 --> 00:14:39.246 A:middle
into LLDB, I kind of like
spending time in LLDB,

00:14:39.246 --> 00:14:41.326 A:middle
so let's get right in there.

00:14:41.606 --> 00:14:43.626 A:middle
Now in LLDB, there--

00:14:43.626 --> 00:14:46.336 A:middle
you're going to have two
general ways of doing things.

00:14:47.466 --> 00:14:50.776 A:middle
This going to be the way by
clicking buttons in Xcode

00:14:51.126 --> 00:14:53.736 A:middle
which is really nice and
convenient for many cases.

00:14:54.506 --> 00:14:57.666 A:middle
And we also have a command
language that you can use

00:14:57.716 --> 00:15:00.676 A:middle
through the LLDB
console to achieve many

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:14:57.716 --> 00:15:00.676 A:middle
through the LLDB
console to achieve many

00:15:00.676 --> 00:15:02.366 A:middle
of the same things
and a couple more.

00:15:02.366 --> 00:15:06.276 A:middle
The reason you might want
to use the LLDB console even

00:15:06.276 --> 00:15:09.056 A:middle
when there's an equivalent
Xcode function is

00:15:09.056 --> 00:15:12.526 A:middle
that it's a great way of keeping
a record of what you've done

00:15:12.526 --> 00:15:16.476 A:middle
in the past and how you got into
the situation you're in now.

00:15:18.016 --> 00:15:21.926 A:middle
Now commands in the LLDB
console have a couple of forms.

00:15:22.656 --> 00:15:25.946 A:middle
There's the most discoverable
form, for each command

00:15:26.226 --> 00:15:30.086 A:middle
that let's you find it easily
through the help system.

00:15:30.546 --> 00:15:35.826 A:middle
Also the options in this most
discoverable form, very verbose

00:15:36.106 --> 00:15:39.276 A:middle
and you can see exactly what
this command is trying to do.

00:15:39.756 --> 00:15:43.266 A:middle
So for example, if you
want to run an expression,

00:15:43.626 --> 00:15:47.076 A:middle
get the result of it and pass
the description method to it,

00:15:47.076 --> 00:15:49.196 A:middle
assuming it's an
Objective-C object,

00:15:49.636 --> 00:15:52.986 A:middle
then you can say
expression-- object description,

00:15:53.466 --> 00:15:56.996 A:middle
and then type what
you want to output.

00:15:58.076 --> 00:16:00.916 A:middle
Now, after you've used
that a couple of times,

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:15:58.076 --> 00:16:00.916 A:middle
Now, after you've used
that a couple of times,

00:16:00.956 --> 00:16:03.066 A:middle
you're probably going to say,
well that's a lot to type.

00:16:03.746 --> 00:16:07.016 A:middle
And we provided abbreviated
forms of these for you.

00:16:07.356 --> 00:16:08.686 A:middle
Now this isn't any magic,

00:16:09.006 --> 00:16:11.966 A:middle
you just hacked off the
tail end of expression.

00:16:12.256 --> 00:16:14.936 A:middle
You shortened object description
down to a single letter.

00:16:15.906 --> 00:16:21.386 A:middle
That's a great way of typing
common things very quickly.

00:16:22.706 --> 00:16:25.926 A:middle
Another way that we provide,
when there's a command

00:16:25.926 --> 00:16:28.986 A:middle
that you use a lot, and
you use a particular set

00:16:28.986 --> 00:16:31.346 A:middle
of options with it is aliases.

00:16:32.226 --> 00:16:34.726 A:middle
Now in this case,
we have the PO alias

00:16:34.726 --> 00:16:36.196 A:middle
which probably many of you know.

00:16:36.196 --> 00:16:39.576 A:middle
But the great thing is,
we've also provided you ways

00:16:39.786 --> 00:16:41.696 A:middle
to write your own aliases.

00:16:42.136 --> 00:16:44.546 A:middle
And while I'm not going to
go into this these this talk,

00:16:45.076 --> 00:16:47.776 A:middle
last year's LLDB talk
shows you how to do that.

00:16:48.366 --> 00:16:50.586 A:middle
What I'm going to show you

00:16:50.586 --> 00:16:53.556 A:middle
in this talk is both
the shortest form

00:16:54.076 --> 00:16:57.466 A:middle
which maybe an alias and
the long form if you want

00:16:57.466 --> 00:16:58.666 A:middle
to explore it on your own.

00:16:58.766 --> 00:16:59.366 A:middle
All right.

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:17:00.696 --> 00:17:05.606 A:middle
Now that I've gotten through the
background, let's show you how

00:17:05.606 --> 00:17:07.756 A:middle
to stop your program with LLDB.

00:17:08.776 --> 00:17:10.236 A:middle
One of the most important parts

00:17:10.236 --> 00:17:15.366 A:middle
of the debugging process is
stopping before your bug occurs.

00:17:15.606 --> 00:17:20.036 A:middle
Now here, I have two
sub classes of UIView

00:17:20.205 --> 00:17:22.415 A:middle
and both implement
the drawRect method.

00:17:22.415 --> 00:17:26.776 A:middle
What I want to see is how
can I stop at these methods,

00:17:26.776 --> 00:17:29.096 A:middle
what different ways
does LLDB provide?.

00:17:29.966 --> 00:17:32.366 A:middle
Well, the most common
one is probably stopping

00:17:32.366 --> 00:17:34.356 A:middle
at a particular line
in the source code.

00:17:34.356 --> 00:17:37.916 A:middle
Now this is very easy to
tell LLDB, I want to stop

00:17:37.916 --> 00:17:39.946 A:middle
at a particular file
in the line.

00:17:40.956 --> 00:17:44.446 A:middle
Now if the same thing
can be done in Xcode,

00:17:44.746 --> 00:17:47.556 A:middle
simply by clicking
next to that line.

00:17:47.916 --> 00:17:49.466 A:middle
That's a breakpoint right there.

00:17:49.976 --> 00:17:51.986 A:middle
Now this is something you've
probably done very often.

00:17:52.666 --> 00:17:56.566 A:middle
On the other hand, if you don't
know the filing by line number,

00:17:56.956 --> 00:17:59.606 A:middle
you can tell LLDB, just
stop at this method

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:18:00.436 --> 00:18:04.376 A:middle
and just make sure you include
the dash and the brackets.

00:18:04.876 --> 00:18:06.426 A:middle
But LLDB will stop even

00:18:06.426 --> 00:18:09.926 A:middle
if you don't know what the
filing by line number are.

00:18:10.656 --> 00:18:12.256 A:middle
You can do the same
thing in Xcode

00:18:12.506 --> 00:18:15.246 A:middle
by clicking the little plus
sign at the bottom left

00:18:15.246 --> 00:18:16.496 A:middle
of the breakpoint navigator

00:18:16.496 --> 00:18:19.526 A:middle
and then clicking add
symbolic breakpoint.

00:18:21.316 --> 00:18:23.916 A:middle
In the window that pops up,
you can type the name, again,

00:18:23.916 --> 00:18:25.596 A:middle
remembering the dash
and brackets.

00:18:26.796 --> 00:18:30.916 A:middle
There's a third way that you
can do from the LLDB console

00:18:32.016 --> 00:18:35.446 A:middle
which is stopping whenever
any object receives a

00:18:35.446 --> 00:18:36.466 A:middle
particular selector.

00:18:37.336 --> 00:18:39.626 A:middle
This is great if you've
gotten multiple objects

00:18:39.836 --> 00:18:42.876 A:middle
that implement the same
selector, for example drawRect.

00:18:45.556 --> 00:18:46.696 A:middle
All right.

00:18:46.826 --> 00:18:49.276 A:middle
Now you've set your breakpoint,
but I'm sure you've--

00:18:49.276 --> 00:18:53.126 A:middle
many of you have encountered
breakpoints that you hit over

00:18:53.126 --> 00:18:56.226 A:middle
and over again and constantly,
you're going back and forth

00:18:56.226 --> 00:18:58.606 A:middle
between your app triggering
breakpoints and OK,

00:18:58.606 --> 00:19:01.866 A:middle
back to Xcode, doing something
at the console, then going back

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:18:58.606 --> 00:19:01.866 A:middle
back to Xcode, doing something
at the console, then going back

00:19:01.866 --> 00:19:03.656 A:middle
to your app doing some what--

00:19:03.656 --> 00:19:05.746 A:middle
this hopping back and forth
can get really frustrating

00:19:05.746 --> 00:19:06.246 A:middle
over time.

00:19:07.466 --> 00:19:09.306 A:middle
To help you out in
those situations,

00:19:09.556 --> 00:19:13.106 A:middle
we've provided the facility
of breakpoint commands.

00:19:14.726 --> 00:19:17.216 A:middle
Breakpoint commands
are a way to tell LLDB,

00:19:17.216 --> 00:19:18.726 A:middle
I want you to do this set

00:19:18.956 --> 00:19:21.876 A:middle
of actions each time
you hit the breakpoint.

00:19:23.226 --> 00:19:26.416 A:middle
Now those actions can
collect some data for you.

00:19:26.686 --> 00:19:29.976 A:middle
In this case, when you
need to redisplay a Rect,

00:19:30.226 --> 00:19:33.326 A:middle
we print the Rect that
you've been provided with,

00:19:34.016 --> 00:19:38.226 A:middle
and you can also get a back
trace of the current thread

00:19:38.226 --> 00:19:39.806 A:middle
to tell you who told
you about this.

00:19:41.446 --> 00:19:43.406 A:middle
Now one other cool
thing you can do is,

00:19:43.756 --> 00:19:45.896 A:middle
you can actually just
continue your process

00:19:45.936 --> 00:19:47.396 A:middle
after you hit that breakpoint.

00:19:48.516 --> 00:19:51.716 A:middle
This is really handy because it
means you can do all your app

00:19:51.716 --> 00:19:53.606 A:middle
interaction that
triggers all these events.

00:19:53.696 --> 00:19:55.906 A:middle
And then go to Xcode afterwards

00:19:56.106 --> 00:19:58.506 A:middle
and see all the output
from your commands.

00:19:59.136 --> 00:20:02.016 A:middle
There's a way to do
this in Xcode too.

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:19:59.136 --> 00:20:02.016 A:middle
There's a way to do
this in Xcode too.

00:20:02.726 --> 00:20:05.636 A:middle
You select the breakpoint,
you right-click,

00:20:06.906 --> 00:20:12.316 A:middle
click Edit Breakpoint, and then
there's the Add Action button

00:20:12.556 --> 00:20:14.376 A:middle
in this little window
that pops up.

00:20:14.376 --> 00:20:19.846 A:middle
You click Add Action, and
then, you can click Plus

00:20:20.156 --> 00:20:23.306 A:middle
to add more commands then
you type in the commands.

00:20:23.936 --> 00:20:26.446 A:middle
The only difference between
the way you do it in LLDB

00:20:26.446 --> 00:20:29.006 A:middle
and the way you do
it in Xcode is

00:20:29.006 --> 00:20:31.286 A:middle
that there's a little
check box that tells you

00:20:31.286 --> 00:20:33.866 A:middle
that you can continue
after evaluating.

00:20:34.516 --> 00:20:38.506 A:middle
Now in this case, we
actually want to do that.

00:20:38.506 --> 00:20:39.166 A:middle
All right.

00:20:39.166 --> 00:20:40.556 A:middle
So breakpoint commands
are great.

00:20:41.486 --> 00:20:43.756 A:middle
But there's another
type of situation

00:20:43.936 --> 00:20:46.176 A:middle
in which breakpoints
are frustrating to use.

00:20:47.306 --> 00:20:50.656 A:middle
If you have a situation where
you hit a breakpoint a bunch

00:20:50.656 --> 00:20:53.186 A:middle
of times but most times
you actually don't care,

00:20:53.186 --> 00:20:56.216 A:middle
that's the time when
you might want

00:20:56.216 --> 00:20:57.666 A:middle
to use a breakpoint condition.

00:20:58.886 --> 00:21:00.496 A:middle
So let's look at
this example here,

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:20:58.886 --> 00:21:00.496 A:middle
So let's look at
this example here,

00:21:00.776 --> 00:21:05.356 A:middle
I'm stopped at the Init function
for a class I wrote and I want

00:21:05.506 --> 00:21:09.556 A:middle
to see when that class is, when
that exact object is the alloc.

00:21:10.046 --> 00:21:15.266 A:middle
Now here's where my favorite
part because we're going to get

00:21:15.266 --> 00:21:17.796 A:middle
to use clang to help us out.

00:21:18.516 --> 00:21:21.136 A:middle
So we're using the
expression command again

00:21:21.716 --> 00:21:23.306 A:middle
and inside the expression
command,

00:21:23.306 --> 00:21:24.926 A:middle
notice we're doing
something interesting.

00:21:26.426 --> 00:21:30.626 A:middle
We are declaring a variable
and setting it equal to self.

00:21:30.626 --> 00:21:35.336 A:middle
Now the only thing we have to do
here that's unusual is we have

00:21:35.396 --> 00:21:38.546 A:middle
to put a dollar sign
as the first character

00:21:38.546 --> 00:21:39.566 A:middle
in the variables name.

00:21:40.476 --> 00:21:42.386 A:middle
The reason we have
a dollar sign is

00:21:42.386 --> 00:21:45.056 A:middle
because that tells LLDB,
hey, remember this.

00:21:46.186 --> 00:21:49.926 A:middle
Then later, when we set the
condition of the breakpoint,

00:21:50.196 --> 00:21:52.366 A:middle
we can refer back
to that variable.

00:21:52.906 --> 00:21:56.866 A:middle
So we can stop it the alloc
only when self is equal

00:21:56.866 --> 00:22:00.626 A:middle
to the current value of self.

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:21:56.866 --> 00:22:00.626 A:middle
to the current value of self.

00:22:00.816 --> 00:22:04.906 A:middle
That's really handy and you
can do in the next code too.

00:22:05.856 --> 00:22:10.046 A:middle
So you have to set the
variable at the LLDB console

00:22:10.046 --> 00:22:11.426 A:middle
like I showed you just there.

00:22:11.426 --> 00:22:15.556 A:middle
And then, you set the condition
by clicking edit breakpoint

00:22:15.956 --> 00:22:18.456 A:middle
and putting your
breakpoint condition

00:22:18.456 --> 00:22:19.786 A:middle
into the condition field here.

00:22:20.426 --> 00:22:25.156 A:middle
Now that's going to
cover probably most

00:22:25.156 --> 00:22:26.386 A:middle
of the cases you run into.

00:22:27.206 --> 00:22:31.186 A:middle
But there are rare cases where
you actually want to look

00:22:31.186 --> 00:22:34.826 A:middle
at modifications to a very
specific variable in memory.

00:22:36.036 --> 00:22:40.106 A:middle
In those cases, you may want to
use LLDB's watchpoint facility.

00:22:41.666 --> 00:22:45.366 A:middle
Now watchpoints let you stop
when a particular location

00:22:45.366 --> 00:22:49.966 A:middle
in memory is modified and you
tell LLDB about that location

00:22:49.966 --> 00:22:52.166 A:middle
in memory by giving it the name

00:22:52.166 --> 00:22:54.516 A:middle
of a variable that's
at that location.

00:22:55.116 --> 00:23:00.176 A:middle
In this case, you use the
watchpoint set variable command

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:22:55.116 --> 00:23:00.176 A:middle
In this case, you use the
watchpoint set variable command

00:23:00.176 --> 00:23:04.846 A:middle
to do so and LLDB will stop the
program whenever it modifies

00:23:04.896 --> 00:23:05.556 A:middle
that variable.

00:23:05.556 --> 00:23:08.516 A:middle
Now there is a caveat here.

00:23:09.256 --> 00:23:12.036 A:middle
We could implement this by
single-stepping your program

00:23:12.156 --> 00:23:13.356 A:middle
and constantly looking, oh,

00:23:13.356 --> 00:23:15.776 A:middle
is this instruction modified
app location, does this?

00:23:16.776 --> 00:23:19.146 A:middle
The problem with that
is it's really slow.

00:23:19.556 --> 00:23:24.536 A:middle
So we use special CPU support
to make this a lot faster.

00:23:26.066 --> 00:23:29.596 A:middle
Intel CPUs provide four
slots for watchpoints

00:23:29.946 --> 00:23:32.276 A:middle
and on ARM we support two slots.

00:23:32.786 --> 00:23:36.836 A:middle
So remember, the number of
watchpoints you have is limited

00:23:36.836 --> 00:23:40.396 A:middle
so use them effectively and
delete them when you're done.

00:23:41.616 --> 00:23:44.166 A:middle
You can also use
watchpoints in Xcode.

00:23:44.716 --> 00:23:47.876 A:middle
If you have the variable
visible in the variables view,

00:23:48.176 --> 00:23:51.566 A:middle
you can right-click
on it, click Watch.

00:23:52.466 --> 00:23:58.356 A:middle
And then afterwards, if you
click Continue, you'll stop.

00:23:58.416 --> 00:24:00.456 A:middle
Now notice here we've
stopped right

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:23:58.416 --> 00:24:00.456 A:middle
Now notice here we've
stopped right

00:24:00.456 --> 00:24:03.656 A:middle
after we actually set the
watchpoint because we're--

00:24:03.656 --> 00:24:07.396 A:middle
we had broken first, we were
about to set the variable to No.

00:24:08.096 --> 00:24:09.796 A:middle
That if we click Continue again,

00:24:10.286 --> 00:24:12.346 A:middle
we stop where it sets
the variable to yes.

00:24:13.786 --> 00:24:16.296 A:middle
Now, one thing that I
was mentioning here,

00:24:17.026 --> 00:24:20.006 A:middle
this is a little bit different
from setting a breakpoint

00:24:20.006 --> 00:24:24.036 A:middle
where it gets set to yes because
the breakpoint would trigger

00:24:24.036 --> 00:24:28.216 A:middle
whenever any piece of code
sets a variable called needs

00:24:28.216 --> 00:24:29.566 A:middle
synchronization to yes.

00:24:31.046 --> 00:24:36.066 A:middle
The thing that happens here
is, you've set your watchpoint

00:24:36.296 --> 00:24:40.326 A:middle
on that exact copy of the
need synchronization variable

00:24:40.656 --> 00:24:45.846 A:middle
so you will only see when
your code touches that.

00:24:46.056 --> 00:24:46.836 A:middle
All right.

00:24:47.136 --> 00:24:49.946 A:middle
So now, I've shown you
how to stop your program.

00:24:50.276 --> 00:24:54.406 A:middle
Now, let's see a couple
of ways to avoid headaches

00:24:54.576 --> 00:24:56.866 A:middle
when you're actually
trying to stop your program

00:24:57.036 --> 00:24:58.696 A:middle
and make it go where you want.

00:24:58.696 --> 00:25:04.996 A:middle
One of the most annoying things
that I run into when I'm trying

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:24:58.696 --> 00:25:04.996 A:middle
One of the most annoying things
that I run into when I'm trying

00:25:04.996 --> 00:25:08.726 A:middle
to step is I'm at one place
in my function, I want to get

00:25:08.726 --> 00:25:11.206 A:middle
to another place and there's
like a million lines of,

00:25:11.426 --> 00:25:15.676 A:middle
you know, logging and stuff
that I don't care about,

00:25:15.676 --> 00:25:17.066 A:middle
I have to go steps,
steps, steps, steps.

00:25:17.066 --> 00:25:19.346 A:middle
And the most frust-- it's
even more frustrating

00:25:19.466 --> 00:25:23.106 A:middle
when I can step past
that line and then I got

00:25:23.106 --> 00:25:24.856 A:middle
to restart it, it's frustrating.

00:25:25.676 --> 00:25:27.526 A:middle
So I think, ah I'm
clever, all right,

00:25:27.626 --> 00:25:31.376 A:middle
I'm going to set a breakpoint
at that line and hit continue.

00:25:31.376 --> 00:25:35.696 A:middle
Well, it turns out that
line was in an if statement

00:25:35.696 --> 00:25:37.296 A:middle
and that if didn't get hit.

00:25:37.296 --> 00:25:42.116 A:middle
So now my programs run away
on me and it's frustrating.

00:25:42.456 --> 00:25:43.746 A:middle
That's what cap videos are for.

00:25:43.926 --> 00:25:48.936 A:middle
I-- now if-- I love cap
videos, but we've actually gone

00:25:48.936 --> 00:25:49.876 A:middle
to gone you're one better.

00:25:50.646 --> 00:25:53.726 A:middle
LLDB has a special
feature called thread

00:25:53.726 --> 00:26:01.036 A:middle
until which will stop at the
line you tell it to or if you're

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:25:53.726 --> 00:26:01.036 A:middle
until which will stop at the
line you tell it to or if you're

00:26:01.036 --> 00:26:04.086 A:middle
about to leave the function
you're in currently thread

00:26:04.086 --> 00:26:06.336 A:middle
until you stop you then to.

00:26:06.666 --> 00:26:09.906 A:middle
So no more steps, steps, steps,
steps, just trust the LLDB

00:26:09.906 --> 00:26:11.596 A:middle
to get you where you need to go.

00:26:11.846 --> 00:26:16.236 A:middle
You can do this in Xcode as
well, let's say I'm stopped

00:26:16.236 --> 00:26:19.966 A:middle
for example at the beginning of
a loop and I don't want to have

00:26:19.966 --> 00:26:22.866 A:middle
to step overall the
loop condition code.

00:26:23.536 --> 00:26:28.926 A:middle
In Xcode I can simply click,
right-click, click continue

00:26:28.926 --> 00:26:35.026 A:middle
to hear, and Xcode
will get me there.

00:26:35.236 --> 00:26:38.986 A:middle
Now here's one other frustrating
thing that I think some

00:26:38.986 --> 00:26:39.886 A:middle
of you have run into,

00:26:40.016 --> 00:26:43.476 A:middle
that I want to tell you is
not such a bad situation.

00:26:44.966 --> 00:26:47.026 A:middle
When you're stepping
through your code

00:26:47.206 --> 00:26:50.956 A:middle
and if you have breakpoint set,
you may step over a function

00:26:50.956 --> 00:26:52.116 A:middle
that triggers a breakpoint.

00:26:52.756 --> 00:26:58.556 A:middle
In this situation, don't panic,
we've actually got a stock

00:26:59.186 --> 00:27:01.246 A:middle
and we remember what
you were doing

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:26:59.186 --> 00:27:01.246 A:middle
and we remember what
you were doing

00:27:01.376 --> 00:27:02.676 A:middle
when you hit that breakpoint.

00:27:03.926 --> 00:27:06.836 A:middle
So in this case,
I'm about to step

00:27:06.836 --> 00:27:09.286 A:middle
over this function
called remove duplicates.

00:27:09.986 --> 00:27:11.276 A:middle
And if you remember
from earlier,

00:27:11.276 --> 00:27:12.726 A:middle
I had breakpoint set in there.

00:27:13.906 --> 00:27:20.066 A:middle
So I step over this and
then I hit that breakpoint.

00:27:20.636 --> 00:27:23.986 A:middle
Now some of you might
say, oh, I just, you know,

00:27:23.986 --> 00:27:25.376 A:middle
disable your breakpoints
when you step,

00:27:26.066 --> 00:27:27.016 A:middle
don't worry about that.

00:27:27.466 --> 00:27:31.516 A:middle
If you click continue here, LLDB
remembers that you were stepping

00:27:33.886 --> 00:27:36.276 A:middle
and gets you back to the
code that you cared about.

00:27:37.516 --> 00:27:43.716 A:middle
[ Applause ]

00:27:44.216 --> 00:27:48.576 A:middle
There's one other cool
thing that you can do just

00:27:48.576 --> 00:27:52.736 A:middle
from the LLDB command line and
that is call your code by hand

00:27:53.026 --> 00:27:56.786 A:middle
to trigger the breakpoints
you care about.

00:27:56.946 --> 00:28:01.816 A:middle
Sometimes you're in situations
where you're testing your code

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:27:56.946 --> 00:28:01.816 A:middle
Sometimes you're in situations
where you're testing your code

00:28:02.006 --> 00:28:04.386 A:middle
and you're trying to
cover all your bases,

00:28:04.656 --> 00:28:07.486 A:middle
but you can't make one
particular method run.

00:28:07.486 --> 00:28:10.776 A:middle
Now this can be frustrating
and you're like trying

00:28:10.776 --> 00:28:13.476 A:middle
to concoct weird environments.

00:28:13.816 --> 00:28:16.666 A:middle
This is a great time for unit
test, but if you're just trying

00:28:16.666 --> 00:28:19.876 A:middle
to get this one case covered,
LLDB can help you out.

00:28:20.386 --> 00:28:23.136 A:middle
Now again, this is a
part that I really enjoy

00:28:23.136 --> 00:28:26.176 A:middle
because it uses clang and
what can be better than clang?

00:28:27.086 --> 00:28:32.056 A:middle
So the way you do this is you
use the expression command

00:28:32.546 --> 00:28:36.106 A:middle
to run the code that
you want to test.

00:28:37.296 --> 00:28:40.776 A:middle
In this case, we can call the
remove duplicates function

00:28:40.776 --> 00:28:43.506 A:middle
on self just using the
expression command.

00:28:44.216 --> 00:28:48.696 A:middle
But that's not all, we can set
a breakpoint in that function,

00:28:49.256 --> 00:28:54.606 A:middle
then pass-- ignore breakpoints
falls to the expression command.

00:28:55.416 --> 00:28:58.786 A:middle
And then, LLDB will
actually stop

00:28:58.786 --> 00:29:01.196 A:middle
when you've entered function
and you can watch it run.

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:28:58.786 --> 00:29:01.196 A:middle
when you've entered function
and you can watch it run.

00:29:02.736 --> 00:29:07.356 A:middle
Now remember, because we're
integrated with clang,

00:29:08.016 --> 00:29:11.406 A:middle
we're actually running
the code in your program

00:29:11.816 --> 00:29:13.356 A:middle
that you type after expression.

00:29:14.016 --> 00:29:18.106 A:middle
What that means is, you actually
did remove duplicates here,

00:29:18.566 --> 00:29:21.236 A:middle
your program will run
differently after you continue.

00:29:21.946 --> 00:29:25.016 A:middle
So that's something important
to remember as you go through.

00:29:26.196 --> 00:29:27.506 A:middle
All right.

00:29:27.506 --> 00:29:31.836 A:middle
So now you've got your program
where you want it and you want

00:29:31.836 --> 00:29:33.906 A:middle
to see its data and
all it glory.

00:29:33.906 --> 00:29:38.206 A:middle
Now I'm going to call up Enrico
Granata who's developed too much

00:29:38.206 --> 00:29:39.666 A:middle
of the infrastructure
that we used

00:29:39.666 --> 00:29:40.986 A:middle
to present that data to you.

00:29:41.546 --> 00:29:44.146 A:middle
Enrico is a great guy to know
because not only does he know

00:29:44.146 --> 00:29:45.906 A:middle
about this stuff,
but he also knows

00:29:45.906 --> 00:29:48.496 A:middle
about LLDB's Python
interface, and he's going

00:29:48.496 --> 00:29:51.306 A:middle
to give you a little
bit of introduction now.

00:29:55.696 --> 00:29:58.546 A:middle
>> Thank you, Sean.

00:29:58.716 --> 00:29:59.616 A:middle
Hello, everyone.

00:29:59.776 --> 00:30:00.796 A:middle
I'm Enrico.

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:29:59.776 --> 00:30:00.796 A:middle
I'm Enrico.

00:30:00.866 --> 00:30:04.126 A:middle
I'm one of the engineers that
worked on LLDB and we're going

00:30:04.126 --> 00:30:06.796 A:middle
to be together for the
next, about 30 minutes,

00:30:07.076 --> 00:30:09.726 A:middle
and we're going to cover a
bunch of great LLDB features.

00:30:10.336 --> 00:30:11.876 A:middle
So let's get right started.

00:30:13.156 --> 00:30:15.676 A:middle
We're going to talk about
inspecting your data

00:30:15.676 --> 00:30:18.196 A:middle
and we're going to
cover three things.

00:30:19.386 --> 00:30:20.666 A:middle
We're going to talk about ways

00:30:20.666 --> 00:30:23.046 A:middle
that you can inspect
data at LLDB console.

00:30:23.616 --> 00:30:26.736 A:middle
We're going to talk about the
LLDB data formatter facility

00:30:27.036 --> 00:30:29.546 A:middle
and we're going to
cover a cool technique

00:30:29.546 --> 00:30:31.956 A:middle
that involves the
expression parser as a way

00:30:31.956 --> 00:30:34.446 A:middle
to inspect opaque data.

00:30:34.446 --> 00:30:38.176 A:middle
So inspecting data
at a command line.

00:30:38.326 --> 00:30:42.306 A:middle
Some of you have probably
used GDB quite a while

00:30:42.306 --> 00:30:44.196 A:middle
in the last few years
and you know

00:30:44.196 --> 00:30:46.356 A:middle
that there are certain commands
that you can use to get GDB

00:30:46.356 --> 00:30:47.506 A:middle
to show you your data.

00:30:47.906 --> 00:30:51.606 A:middle
And now you're transitioning to
LLDB and there are some commands

00:30:51.606 --> 00:30:53.706 A:middle
that are the same and
some that are different

00:30:53.706 --> 00:30:56.026 A:middle
and you're really
confused as to what,

00:30:56.026 --> 00:30:57.426 A:middle
you should be using
for each case.

00:30:58.216 --> 00:31:00.586 A:middle
Well, I like to think
of the LLDB facilities

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:30:58.216 --> 00:31:00.586 A:middle
Well, I like to think
of the LLDB facilities

00:31:00.666 --> 00:31:03.186 A:middle
to show data as a tool box.

00:31:03.306 --> 00:31:05.106 A:middle
I had a set of tools and I know

00:31:05.106 --> 00:31:07.426 A:middle
that each one is good
for a specific task.

00:31:07.956 --> 00:31:10.346 A:middle
And once I know that,
I can open my tool box

00:31:10.346 --> 00:31:13.076 A:middle
and I can be confident that
for each task I have at hand,

00:31:13.306 --> 00:31:14.526 A:middle
I'm going to pick
the right tool.

00:31:14.526 --> 00:31:16.966 A:middle
So what we were going to
do for the next couple

00:31:16.966 --> 00:31:19.016 A:middle
of minutes is going to
go through the toolchain

00:31:19.436 --> 00:31:20.726 A:middle
and see what we have available.

00:31:20.726 --> 00:31:25.946 A:middle
Our first command
is friend variable,

00:31:26.616 --> 00:31:29.986 A:middle
friend variable allows you to
see all the current arguments

00:31:29.986 --> 00:31:31.706 A:middle
to your function, all
the local variables,

00:31:31.706 --> 00:31:33.986 A:middle
everything that is
currently in your local scope.

00:31:34.636 --> 00:31:38.486 A:middle
If you want, you can also pass
in one or more specific names,

00:31:38.626 --> 00:31:41.246 A:middle
you can say friend variable
RC, friend variable RV,

00:31:41.246 --> 00:31:44.406 A:middle
friend variable flu bar and all

00:31:44.406 --> 00:31:46.576 A:middle
of those names will be
shown by the debugger.

00:31:48.216 --> 00:31:51.996 A:middle
Expression as Sean and Kate
mentioned before is the entry

00:31:51.996 --> 00:31:54.446 A:middle
point to our expression
parser which allows you

00:31:54.446 --> 00:31:57.686 A:middle
to execute arbitrary chunks of
data, arbitrary chunks of code.

00:31:58.286 --> 00:32:01.126 A:middle
We're actually having
clang right there,

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:31:58.286 --> 00:32:01.126 A:middle
We're actually having
clang right there,

00:32:01.196 --> 00:32:03.686 A:middle
that means a type
expression, you're typing code.

00:32:03.926 --> 00:32:06.856 A:middle
And that opens a local scope
for your right where you stop

00:32:06.856 --> 00:32:09.836 A:middle
in your code and what
every you take is executed

00:32:09.836 --> 00:32:13.396 A:middle
by the very same compiler that
has taken in your source code

00:32:13.396 --> 00:32:19.796 A:middle
from Xcode and made it
into the app ironic.

00:32:19.926 --> 00:32:22.576 A:middle
If you're like me though,
you're not really like to type

00:32:22.576 --> 00:32:25.396 A:middle
that much on the
command line expression,

00:32:25.656 --> 00:32:27.206 A:middle
you're like to be
quick and efficient.

00:32:27.206 --> 00:32:29.286 A:middle
So you can use B
which is an alias

00:32:29.286 --> 00:32:30.756 A:middle
for expression that we provided.

00:32:31.216 --> 00:32:34.816 A:middle
And if you're casting with
GDBs facility for formatting,

00:32:35.116 --> 00:32:36.856 A:middle
you can also use that Y,
you can say [inaudible],

00:32:36.856 --> 00:32:39.606 A:middle
we totally support that.

00:32:41.016 --> 00:32:43.306 A:middle
And for your Objective-C,
guys in the audience,

00:32:44.046 --> 00:32:46.026 A:middle
if you have an Objective-C
object and you want

00:32:46.026 --> 00:32:49.106 A:middle
to see something meaningful
about them, you can say PO.

00:32:49.106 --> 00:32:52.356 A:middle
PO will run the expression
whatever thing you pass to it

00:32:52.356 --> 00:32:55.566 A:middle
and that if the result is an
Objective-C object is going

00:32:55.566 --> 00:32:57.006 A:middle
to call the description selector

00:32:57.006 --> 00:32:58.436 A:middle
and that option show
you the result.

00:32:59.486 --> 00:33:02.756 A:middle
Description is the select
that Apple implemented

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:32:59.486 --> 00:33:02.756 A:middle
Description is the select
that Apple implemented

00:33:02.756 --> 00:33:06.196 A:middle
for see some classes, but
that you can also implement

00:33:06.196 --> 00:33:08.086 A:middle
on your very own classes
and then will get picked

00:33:08.086 --> 00:33:09.476 A:middle
in the same way by debugger.

00:33:09.856 --> 00:33:11.726 A:middle
You can implement
description to your objects

00:33:11.896 --> 00:33:14.386 A:middle
and that you can po them
at will from the debugger.

00:33:17.746 --> 00:33:22.216 A:middle
So here are the tools available
just choose the one you need

00:33:22.216 --> 00:33:24.696 A:middle
in each case and you look great.

00:33:25.436 --> 00:33:30.396 A:middle
Let's talk about another
way to look at data,

00:33:30.846 --> 00:33:33.096 A:middle
let's talk about the LLDB
data formatter facility.

00:33:33.586 --> 00:33:36.506 A:middle
And first of all, let's see
why we need the data formatter

00:33:36.586 --> 00:33:39.846 A:middle
facility at all, I could just
[inaudible] po my objects.

00:33:40.576 --> 00:33:43.766 A:middle
Well, it turns that
there's cases where raw data

00:33:44.166 --> 00:33:45.236 A:middle
which is exactly what is

00:33:45.236 --> 00:33:48.776 A:middle
in memory is not always the
easiest thing to make sense of.

00:33:49.196 --> 00:33:52.976 A:middle
We're all smart guys here, but
sometimes, it's really just

00:33:52.976 --> 00:33:56.406 A:middle
so complicated for
a person to look at

00:33:56.406 --> 00:34:00.056 A:middle
or maybe it's not our own
types, maybe we got a library

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:33:56.406 --> 00:34:00.056 A:middle
or maybe it's not our own
types, maybe we got a library

00:34:00.056 --> 00:34:01.506 A:middle
and we're trying to
make sense of it.

00:34:02.226 --> 00:34:07.206 A:middle
And maybe it is simply too much
of it and makes sense here,

00:34:07.206 --> 00:34:10.045 A:middle
what doesn't make sense here
just don't know I'm lost.

00:34:10.176 --> 00:34:13.716 A:middle
Let's see an example of what
exactly I'm talking about.

00:34:14.166 --> 00:34:16.906 A:middle
Let's all pretend for a
second that LLDB did not shift

00:34:16.906 --> 00:34:18.156 A:middle
with any data formatter at all.

00:34:18.156 --> 00:34:22.576 A:middle
This is what the variables
view would look like.

00:34:23.266 --> 00:34:27.576 A:middle
IM MMS array and only tells
me is its memory location.

00:34:28.025 --> 00:34:30.706 A:middle
I have an NSString, and
so it tells me it's the

00:34:30.706 --> 00:34:31.795 A:middle
memory location.

00:34:32.626 --> 00:34:34.386 A:middle
I don't think this
is really helpful.

00:34:34.386 --> 00:34:41.266 A:middle
Well, this is what you
actually get in Xcode 5.

00:34:42.106 --> 00:34:44.626 A:middle
Your MMS array is going to
tell you many objects it has,

00:34:45.065 --> 00:34:46.596 A:middle
you're going to see
each one of those.

00:34:48.016 --> 00:34:48.335 A:middle
Thank you.

00:34:51.616 --> 00:34:52.025 A:middle
Thank you.

00:34:52.696 --> 00:34:55.186 A:middle
And your NSString is going to
tell you what its content is

00:34:55.426 --> 00:34:58.306 A:middle
and your class instances
will tell you what class they

00:34:58.306 --> 00:34:59.656 A:middle
belong to.

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:35:00.396 --> 00:35:04.416 A:middle
But that's just a solution with
the data types of we [inaudible]

00:35:04.416 --> 00:35:09.036 A:middle
to you, it's not a
solution with your types.

00:35:09.216 --> 00:35:11.466 A:middle
We've all been here, we're
in the variables view,

00:35:11.466 --> 00:35:13.256 A:middle
we're debugging, we
have our own objects,

00:35:13.256 --> 00:35:14.986 A:middle
we have the instances
of an address class.

00:35:15.306 --> 00:35:18.206 A:middle
And only tells me, I'm
in this memory location,

00:35:19.046 --> 00:35:22.056 A:middle
that's really helpful if I'm the
computer, but that's not helpful

00:35:22.056 --> 00:35:23.016 A:middle
if I'm the programmer.

00:35:23.606 --> 00:35:26.166 A:middle
So now I flip it open,
open to see something.

00:35:27.446 --> 00:35:30.736 A:middle
Indeed, I do, but what
string would I see here?

00:35:31.236 --> 00:35:34.216 A:middle
I see [inaudible] Enrico
Granata, California,

00:35:34.216 --> 00:35:36.536 A:middle
instance loop, what 95014.

00:35:36.536 --> 00:35:39.646 A:middle
I don't know about any of you
guys here in the audience,

00:35:39.866 --> 00:35:41.976 A:middle
but I am usually branded
and addressed that way

00:35:41.976 --> 00:35:44.286 A:middle
and I don't think the postal
service accepts addresses

00:35:44.286 --> 00:35:45.036 A:middle
written that way.

00:35:46.096 --> 00:35:48.576 A:middle
I'd really like to see something
that makes more sense to me,

00:35:48.906 --> 00:35:51.486 A:middle
I'd like to see something
like this.

00:35:52.146 --> 00:35:54.656 A:middle
I see the names of the people.

00:35:54.656 --> 00:35:57.006 A:middle
I don't see a number
that means nothing to me.

00:35:57.696 --> 00:36:01.386 A:middle
And the way to get here is
with the LLDB data formatters.

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:35:57.696 --> 00:36:01.386 A:middle
And the way to get here is
with the LLDB data formatters.

00:36:02.036 --> 00:36:08.556 A:middle
The cool news is, we did all
the work for system libraries.

00:36:09.266 --> 00:36:13.286 A:middle
For you C++ people, your
SDL vectors, your SDL maps,

00:36:13.496 --> 00:36:14.646 A:middle
they'll show correctly.

00:36:18.946 --> 00:36:19.276 A:middle
Thank you.

00:36:20.376 --> 00:36:22.726 A:middle
And for those that actually
write Objective-C code,

00:36:23.066 --> 00:36:25.256 A:middle
we did the work for Cocoa
Foundation and Foundation.

00:36:25.986 --> 00:36:29.406 A:middle
In the Xcode 5, in addition
to what we have NSArrays

00:36:29.406 --> 00:36:32.436 A:middle
and NSDictionaries in
Xcode 5 NSS also show

00:36:32.436 --> 00:36:34.626 A:middle
with data formatters.

00:36:37.996 --> 00:36:42.196 A:middle
Great news is, we just didn't
build some hard coding notion

00:36:42.196 --> 00:36:43.836 A:middle
or what our classes look like

00:36:44.026 --> 00:36:46.186 A:middle
and left you guys
alone out in the dark.

00:36:46.576 --> 00:36:49.916 A:middle
We built a data formatter
subsystem that is pluggable

00:36:50.186 --> 00:36:52.756 A:middle
and that means that what
we did for the data types

00:36:52.756 --> 00:36:55.136 A:middle
that we invent, you
can do the same thing

00:36:55.136 --> 00:36:56.386 A:middle
for your own data types.

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:37:00.556 --> 00:37:02.946 A:middle
So let's see exactly
what you can do,

00:37:02.946 --> 00:37:04.296 A:middle
how you can plug
in into the system.

00:37:05.236 --> 00:37:07.206 A:middle
There's two main
types of formatters.

00:37:07.856 --> 00:37:08.736 A:middle
They're summaries.

00:37:09.646 --> 00:37:13.636 A:middle
Summaries are a very quick way
to look at an option at a glance

00:37:13.636 --> 00:37:16.136 A:middle
and see what's most important
about it like the number

00:37:16.136 --> 00:37:17.106 A:middle
of items in the array.

00:37:18.086 --> 00:37:21.716 A:middle
You can also write this family
name synthetic children,

00:37:22.326 --> 00:37:25.836 A:middle
synthetic children allow
you to give structure,

00:37:26.116 --> 00:37:28.046 A:middle
aggregate structure,
the data that isn't.

00:37:28.676 --> 00:37:31.846 A:middle
I have an NSS array and I
know that it contains objects

00:37:31.846 --> 00:37:34.196 A:middle
but its underlying structure
doesn't show me that.

00:37:34.516 --> 00:37:37.636 A:middle
With synthetic children, I can
actually see the items that are

00:37:37.636 --> 00:37:40.786 A:middle
into the array as if they
really physically are right

00:37:40.786 --> 00:37:41.466 A:middle
into the array.

00:37:41.796 --> 00:37:46.906 A:middle
And here I see my NS
numbers into there.

00:37:47.116 --> 00:37:49.496 A:middle
We'll focus on giving
an example of summaries.

00:37:49.496 --> 00:37:51.566 A:middle
So let's briefly
see how they work.

00:37:52.216 --> 00:37:56.056 A:middle
Summaries worked by matching a
data type to a Python function

00:37:56.056 --> 00:37:57.106 A:middle
that implement the summary.

00:37:57.986 --> 00:38:02.076 A:middle
The base matching is by
name, you say type name full,

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:37:57.986 --> 00:38:02.076 A:middle
The base matching is by
name, you say type name full,

00:38:02.076 --> 00:38:04.666 A:middle
LLDB call this function
to summarize the object.

00:38:05.336 --> 00:38:07.956 A:middle
There's a bunch of other
rules and you can refer

00:38:07.956 --> 00:38:10.166 A:middle
to the LLDB website
for further details.

00:38:11.776 --> 00:38:14.106 A:middle
Whenever we need to display
a value of that type,

00:38:14.456 --> 00:38:17.576 A:middle
we call the function and we
pass to that function and object

00:38:17.576 --> 00:38:18.866 A:middle
that we call an SB Value.

00:38:19.616 --> 00:38:23.166 A:middle
SB Value is part of a
larger LLDB object model

00:38:23.166 --> 00:38:24.846 A:middle
that we're going to
cover in greater detail.

00:38:25.596 --> 00:38:27.266 A:middle
It is an object that
represents a variable,

00:38:27.266 --> 00:38:28.676 A:middle
think of it as a variable.

00:38:29.556 --> 00:38:32.556 A:middle
And that function can do
whatever processing it wants

00:38:32.556 --> 00:38:34.796 A:middle
because it's Python code
and that the end is going

00:38:34.796 --> 00:38:37.656 A:middle
to return a string and we're
going to show that string

00:38:37.656 --> 00:38:42.026 A:middle
on the screen as the
summary as the value.

00:38:42.666 --> 00:38:44.826 A:middle
So with that, it's an option
that represents a variable.

00:38:45.196 --> 00:38:47.126 A:middle
So it probably has
variable-like behaviors.

00:38:47.206 --> 00:38:49.706 A:middle
That's probably variable-like
questions that we can ask of it.

00:38:50.286 --> 00:38:53.146 A:middle
In fact, among the many
questions that you can ask

00:38:53.146 --> 00:38:56.116 A:middle
of an SB Value, you can
ask it, what's your name,

00:38:56.636 --> 00:38:58.416 A:middle
what's your data type,

00:38:59.316 --> 00:39:01.286 A:middle
what's your summary
string if you have any?

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:38:59.316 --> 00:39:01.286 A:middle
what's your summary
string if you have any?

00:39:01.696 --> 00:39:03.346 A:middle
Do you have children?

00:39:03.906 --> 00:39:04.866 A:middle
How many do you have?

00:39:04.946 --> 00:39:06.716 A:middle
Can you tell me about
each one of those?

00:39:06.766 --> 00:39:08.906 A:middle
And each one of those
is an SB Value itself,

00:39:09.116 --> 00:39:11.266 A:middle
the model is total
recursive in this respect.

00:39:11.936 --> 00:39:15.786 A:middle
And if it's a scalar like a
number, integer, floating-point,

00:39:15.786 --> 00:39:17.516 A:middle
you can also ask
what's your value

00:39:17.856 --> 00:39:18.976 A:middle
and it will return
you the number.

00:39:19.936 --> 00:39:23.526 A:middle
So let's see our example,
we have our address class,

00:39:23.946 --> 00:39:25.106 A:middle
we see the number, we want

00:39:25.106 --> 00:39:26.836 A:middle
to see the name,
let's make it happen.

00:39:27.606 --> 00:39:30.736 A:middle
We start writing the prototype
or a function and here we see

00:39:30.736 --> 00:39:33.806 A:middle
that we're passing a value, and
that value is an SB Value one

00:39:33.806 --> 00:39:35.286 A:middle
of the objects we
just talked about.

00:39:35.776 --> 00:39:40.986 A:middle
We can't extract fields out of
that variable and here we get

00:39:40.986 --> 00:39:44.476 A:middle
into first and the last name
which are again SB Values.

00:39:44.966 --> 00:39:47.556 A:middle
That means I can iterate
the reasoning and ask five

00:39:47.556 --> 00:39:48.786 A:middle
of the questions
of these objects.

00:39:50.086 --> 00:39:52.296 A:middle
Since I know these
are NSStrings,

00:39:52.376 --> 00:39:54.326 A:middle
I know that LLDB is going
[inaudible] me a summary

00:39:54.326 --> 00:39:56.496 A:middle
out for those so I
ask for the summary

00:39:56.716 --> 00:39:58.556 A:middle
and now I have two
Python strings

00:39:58.606 --> 00:40:00.326 A:middle
that represent my
first and my last name.

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:39:58.606 --> 00:40:00.326 A:middle
that represent my
first and my last name.

00:40:00.776 --> 00:40:03.526 A:middle
And since our Python strings,
I'm really free to the--

00:40:03.526 --> 00:40:05.146 A:middle
all the processing
I need in those.

00:40:06.166 --> 00:40:08.496 A:middle
And again, I'll just
return the string

00:40:08.886 --> 00:40:11.496 A:middle
and back to my variables view.

00:40:11.496 --> 00:40:14.776 A:middle
I still see the numbers because
I haven't told the LLDB how

00:40:14.776 --> 00:40:15.466 A:middle
to do the magic.

00:40:16.056 --> 00:40:18.076 A:middle
So let's apply the
secret sauce right now.

00:40:18.876 --> 00:40:22.796 A:middle
The type summary app command
named Python function is the

00:40:22.796 --> 00:40:25.956 A:middle
LLDB secret sauce and it tells
the debugger whenever you see an

00:40:25.956 --> 00:40:28.726 A:middle
option of this type, call this
function to provide a summary,

00:40:29.666 --> 00:40:33.246 A:middle
and from the moment on,
numbers are no more,

00:40:33.726 --> 00:40:35.426 A:middle
strings are on the string.

00:40:37.176 --> 00:40:37.356 A:middle
Thanks.

00:40:44.376 --> 00:40:47.366 A:middle
Expression, the expression
parser is a great tool

00:40:47.366 --> 00:40:49.866 A:middle
to run your code, it's a
great tool to check on state

00:40:49.866 --> 00:40:52.146 A:middle
of things, it can
also be a great tool

00:40:52.146 --> 00:40:53.906 A:middle
for looking at opaque data.

00:40:54.686 --> 00:40:56.926 A:middle
Sometimes you have some data

00:40:57.056 --> 00:41:00.136 A:middle
and you don't really know
its format 'cause they didn't

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:40:57.056 --> 00:41:00.136 A:middle
and you don't really know
its format 'cause they didn't

00:41:00.136 --> 00:41:01.086 A:middle
[inaudible] you how
to explore them.

00:41:01.666 --> 00:41:05.476 A:middle
But you can go on Google and
you can probably figure it out.

00:41:05.986 --> 00:41:08.206 A:middle
And now all the knowledge
about the internals

00:41:08.206 --> 00:41:13.206 A:middle
of this data stretcher are here,
but sometimes it's not enough,

00:41:13.746 --> 00:41:17.516 A:middle
we'd also like for those-- that
information to go from here

00:41:17.646 --> 00:41:20.616 A:middle
into the Xcode UI when
I'm debugging something.

00:41:21.086 --> 00:41:23.646 A:middle
An expression parser is a
great tool to make that happen,

00:41:24.106 --> 00:41:25.156 A:middle
let's see a quick example.

00:41:26.446 --> 00:41:28.756 A:middle
I've been banded this
API from a third party,

00:41:29.106 --> 00:41:32.706 A:middle
it's an opaque object and it
says create me, do something

00:41:32.706 --> 00:41:33.886 A:middle
with me and then release me.

00:41:34.226 --> 00:41:36.536 A:middle
I Googled it, I'm really
smart, I figured it out,

00:41:37.386 --> 00:41:39.576 A:middle
that's what the object
really is.

00:41:40.416 --> 00:41:43.876 A:middle
But the fact that I know it
doesn't translate into here.

00:41:43.876 --> 00:41:48.426 A:middle
In the user interface, it's
still just a set opaque object.

00:41:48.906 --> 00:41:50.296 A:middle
Let's shed some light here.

00:41:50.856 --> 00:41:54.316 A:middle
I can type expression
in the LLDB console

00:41:54.316 --> 00:41:56.686 A:middle
and I can define a
full data structure.

00:41:57.266 --> 00:41:58.766 A:middle
Again, this is the power

00:41:58.766 --> 00:42:00.856 A:middle
of having the compiler
the expression parser,

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:41:58.766 --> 00:42:00.856 A:middle
of having the compiler
the expression parser,

00:42:01.286 --> 00:42:03.336 A:middle
you can define a
full native structure

00:42:03.336 --> 00:42:06.336 A:middle
and that will be
accepted, that will work.

00:42:06.396 --> 00:42:09.716 A:middle
I can also define it
as a persistent object,

00:42:09.716 --> 00:42:12.356 A:middle
as Sean was saying, you
put a dollar sign there

00:42:12.696 --> 00:42:13.856 A:middle
and that's persistent.

00:42:14.246 --> 00:42:16.926 A:middle
That's really powerful
because now I can right-click

00:42:16.926 --> 00:42:19.616 A:middle
in my variables view, I
can say an expression,

00:42:20.086 --> 00:42:23.056 A:middle
and I can use an expression
that takes my opaque pointer

00:42:23.296 --> 00:42:26.596 A:middle
and converts it into a point
that was nonopaque structure.

00:42:27.266 --> 00:42:30.006 A:middle
So I define it in a
console and it stays alive

00:42:30.146 --> 00:42:31.586 A:middle
in the Xcode user interface.

00:42:31.676 --> 00:42:36.656 A:middle
And for the moment on,
it's not opaque anymore,

00:42:36.736 --> 00:42:47.046 A:middle
I can actually say the
data that I care about.

00:42:48.056 --> 00:42:48.806 A:middle
All right.

00:42:49.186 --> 00:42:51.266 A:middle
So we've talked about
interesting ways

00:42:51.336 --> 00:42:52.826 A:middle
that you can actually
look at your data.

00:42:53.216 --> 00:42:56.386 A:middle
Let's cover another interesting
topic where the full parallel

00:42:56.386 --> 00:42:57.766 A:middle
to be actually shines.

00:42:58.286 --> 00:43:00.556 A:middle
Let's talk about ways that
it can extend the debugger

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:42:58.286 --> 00:43:00.556 A:middle
Let's talk about ways that
it can extend the debugger

00:43:00.846 --> 00:43:04.186 A:middle
and make the debugger
experience your very own.

00:43:04.756 --> 00:43:08.776 A:middle
And we're going to cover three
topics on how to extend LLDB.

00:43:08.776 --> 00:43:11.816 A:middle
We're going to talk about
cast on LLDB commands.

00:43:12.626 --> 00:43:14.526 A:middle
We're going to talk
about breakpoint actions

00:43:15.076 --> 00:43:17.616 A:middle
and we're going to cover
the LLDB init file.

00:43:18.616 --> 00:43:22.586 A:middle
[inaudible] Custom
LLDB commands.

00:43:24.676 --> 00:43:27.966 A:middle
I'm sure some of you have
used GDB quite a while

00:43:28.006 --> 00:43:28.636 A:middle
over the years.

00:43:29.316 --> 00:43:31.866 A:middle
And you have a library
of scripts that you wrote

00:43:31.866 --> 00:43:34.856 A:middle
and you used them
all or all the time

00:43:34.856 --> 00:43:36.526 A:middle
and they make you
extremely productive.

00:43:37.276 --> 00:43:40.486 A:middle
Now we're transitioning you
to LLDB and we're telling

00:43:40.486 --> 00:43:41.996 A:middle
that you can write
commands in Python.

00:43:43.036 --> 00:43:44.266 A:middle
What happens on your scripts?

00:43:45.016 --> 00:43:47.536 A:middle
Well, it's going to be
some work to convert them.

00:43:47.826 --> 00:43:49.316 A:middle
You're actually going
to have to seat there

00:43:49.406 --> 00:43:54.496 A:middle
and do the conversion, but the
reward that you're going to get

00:43:54.496 --> 00:43:57.006 A:middle
at the end of this process
is going to be huge.

00:43:57.456 --> 00:43:59.426 A:middle
You're going to get a
huge reward for making

00:43:59.426 --> 00:44:01.796 A:middle
that transition in
terms of how easy

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:43:59.426 --> 00:44:01.796 A:middle
that transition in
terms of how easy

00:44:01.796 --> 00:44:04.296 A:middle
to maintain your commands
can be and how powerful

00:44:04.296 --> 00:44:05.596 A:middle
that your commands can
be because they're going

00:44:05.596 --> 00:44:07.606 A:middle
to be full Pythons scripts.

00:44:08.466 --> 00:44:11.856 A:middle
For those of you that really
have not written your custom

00:44:11.856 --> 00:44:14.836 A:middle
library in GDB scripts, this
is also extremely important

00:44:15.006 --> 00:44:17.166 A:middle
because it allows you to do a
number of interesting things.

00:44:17.766 --> 00:44:20.306 A:middle
It allows you to create
a new debugger feature.

00:44:20.756 --> 00:44:22.916 A:middle
You have this great idea
of exactly the thing

00:44:22.916 --> 00:44:24.726 A:middle
that the debugger should
do for you and it doesn't.

00:44:25.096 --> 00:44:27.736 A:middle
You can make it happen.

00:44:27.926 --> 00:44:31.806 A:middle
The default behavior of
LLDB is just debug-perfect,

00:44:31.926 --> 00:44:35.176 A:middle
but if they could change
that one little thing for me,

00:44:35.176 --> 00:44:37.786 A:middle
that will be awesome while
you can change a little thing

00:44:37.786 --> 00:44:40.016 A:middle
yourself, you can implement
your favored behavior.

00:44:41.006 --> 00:44:44.586 A:middle
And let's say, you always doing
the same thing over and over

00:44:44.586 --> 00:44:46.086 A:middle
and over again, you
do the same thing all

00:44:46.086 --> 00:44:47.186 A:middle
over and over, over again.

00:44:47.366 --> 00:44:50.296 A:middle
Well, you can take that kind
of logic, you can make it

00:44:50.296 --> 00:44:51.666 A:middle
into its own building block.

00:44:51.866 --> 00:44:53.576 A:middle
And now every time
you call the command,

00:44:53.826 --> 00:44:56.266 A:middle
the command is a building block
like contains all the logic

00:44:56.616 --> 00:44:59.146 A:middle
and it just automatically
executes for you.

00:44:59.146 --> 00:45:03.936 A:middle
Let's make a quick example
of a great LLDB Command.

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:44:59.146 --> 00:45:03.936 A:middle
Let's make a quick example
of a great LLDB Command.

00:45:04.536 --> 00:45:06.706 A:middle
Let's say that my
program is a recursion.

00:45:06.896 --> 00:45:09.006 A:middle
I'm recursing, calling foo,
calling foo, calling foo,

00:45:09.006 --> 00:45:10.826 A:middle
calling foo and I
am stopped somewhere

00:45:10.826 --> 00:45:12.286 A:middle
in the middle of that recursion.

00:45:12.576 --> 00:45:15.136 A:middle
I'd like to know how deep
does recursion has gone.

00:45:15.136 --> 00:45:18.506 A:middle
Is it really too deep
and I can see darn

00:45:18.506 --> 00:45:20.816 A:middle
to be a little coming
monkey 1, 2, 3, 4,

00:45:20.816 --> 00:45:23.266 A:middle
5 or I can actually
let [inaudible]

00:45:23.266 --> 00:45:24.406 A:middle
to become the frames for me.

00:45:24.406 --> 00:45:27.866 A:middle
LLDB is basically computer
programs so it seems

00:45:27.866 --> 00:45:29.606 A:middle
like counting should
be something

00:45:29.606 --> 00:45:31.926 A:middle
that it should be
easily able to do rather

00:45:31.926 --> 00:45:33.476 A:middle
than having to do with myself.

00:45:34.166 --> 00:45:35.816 A:middle
With an LLDB Command
you can do that

00:45:36.326 --> 00:45:39.636 A:middle
and the reason why the LLDB
Command is so powerful is

00:45:39.636 --> 00:45:42.036 A:middle
that they have access to
the LLDB Object Model.

00:45:42.566 --> 00:45:45.376 A:middle
We call it SB which stands
for Scripting Bridge.

00:45:46.356 --> 00:45:49.796 A:middle
It's a Python API, it's what
Xcode uses as the foundation

00:45:49.796 --> 00:45:51.206 A:middle
of the Debugger User Interface

00:45:51.206 --> 00:45:54.016 A:middle
and that means it's not
just a little toy API

00:45:54.216 --> 00:45:56.696 A:middle
that somehow somebody
brought one day

00:45:56.696 --> 00:45:57.776 A:middle
when it was brought
in the office.

00:45:58.046 --> 00:46:02.036 A:middle
It means it's the full power of
the debugger, the entire power

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:45:58.046 --> 00:46:02.036 A:middle
It means it's the full power of
the debugger, the entire power

00:46:02.036 --> 00:46:05.516 A:middle
of the debugger and you that you
use in Xcode is available to you

00:46:05.516 --> 00:46:09.336 A:middle
when you want to write all
your LLDB Scripts right there.

00:46:09.526 --> 00:46:11.926 A:middle
We'd like to say
that it is a good way

00:46:11.926 --> 00:46:14.886 A:middle
to represent the debugger
session, let's look at it.

00:46:16.376 --> 00:46:19.176 A:middle
You will send this whether
you've got five Apps

00:46:19.176 --> 00:46:22.346 A:middle
under your belt or
you're just starting

00:46:22.346 --> 00:46:23.486 A:middle
to develop for platforms.

00:46:23.746 --> 00:46:24.366 A:middle
You've seen this.

00:46:24.556 --> 00:46:26.166 A:middle
This is the Xcode
User Interface.

00:46:27.216 --> 00:46:29.566 A:middle
Let's look at it with the
eye of a debugger engineer

00:46:29.566 --> 00:46:30.786 A:middle
for a second, will we?

00:46:30.786 --> 00:46:35.646 A:middle
Let's look at that, that
is the after debugging,

00:46:36.046 --> 00:46:38.526 A:middle
that is the thing in which
you put so much effort

00:46:38.526 --> 00:46:39.986 A:middle
and so much passion
and so much love.

00:46:40.516 --> 00:46:44.596 A:middle
That is the thing you want to
rock the stores while we called

00:46:44.596 --> 00:46:47.126 A:middle
that an SB target, it's the
target of your debugging,

00:46:47.126 --> 00:46:49.126 A:middle
it's the thing you're
aiming to make perfect.

00:46:50.176 --> 00:46:53.526 A:middle
And then you click the little
Run Button in the user interface

00:46:53.886 --> 00:46:56.956 A:middle
and this thing that you put all
that passion, all that coning,

00:46:56.956 --> 00:47:00.616 A:middle
all that wet and toiling too
suddenly becomes a live entity,

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:46:56.956 --> 00:47:00.616 A:middle
all that wet and toiling too
suddenly becomes a live entity,

00:47:00.836 --> 00:47:03.726 A:middle
you can suddenly type and type
and click and type and type.

00:47:04.146 --> 00:47:06.936 A:middle
That's a process on the
underlying physical machine.

00:47:07.396 --> 00:47:09.276 A:middle
So we call it an SB process

00:47:09.956 --> 00:47:12.846 A:middle
and processes have
tried an execution

00:47:12.846 --> 00:47:16.496 A:middle
that are all striving
together right job done

00:47:16.496 --> 00:47:17.856 A:middle
and they're all doing
their own thing

00:47:17.856 --> 00:47:20.206 A:middle
and those are an SB thread.

00:47:20.206 --> 00:47:21.256 A:middle
Each one of those
is an SB thread.

00:47:21.256 --> 00:47:23.936 A:middle
And of course a thread is
going to call a function,

00:47:23.936 --> 00:47:25.386 A:middle
it's going to call a function,
it's going to call a function,

00:47:25.386 --> 00:47:26.206 A:middle
it's going to call a function,

00:47:26.206 --> 00:47:28.106 A:middle
it's going to call a
function again and each one

00:47:28.106 --> 00:47:30.656 A:middle
of those things is going to
be a frame on your stacks.

00:47:30.656 --> 00:47:34.046 A:middle
So it's going to be
surprisingly an SB frame.

00:47:34.046 --> 00:47:37.416 A:middle
Now that we're armed
with all these objects

00:47:37.416 --> 00:47:39.796 A:middle
that actually represent a state
of a program and we have access

00:47:39.796 --> 00:47:41.906 A:middle
to them, we see how
easy it should be

00:47:41.906 --> 00:47:45.606 A:middle
to actually get our task done.

00:47:45.606 --> 00:47:47.666 A:middle
So how does a Python
Command actually work?

00:47:48.136 --> 00:47:50.936 A:middle
It works by associating
a name that you type

00:47:50.936 --> 00:47:53.166 A:middle
at the command line
with a Python function

00:47:53.566 --> 00:47:56.196 A:middle
when LLDB is the command,
it calls the function.

00:47:57.446 --> 00:48:00.656 A:middle
That's the prototype
of Python commands.

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:47:57.446 --> 00:48:00.656 A:middle
That's the prototype
of Python commands.

00:48:01.616 --> 00:48:04.526 A:middle
They get past the debugger
which an SB Debugger.

00:48:05.076 --> 00:48:07.366 A:middle
They get past the user
input which is a String.

00:48:07.526 --> 00:48:09.436 A:middle
You get the real Python
String that a user a types

00:48:09.866 --> 00:48:11.836 A:middle
so you're free to chop
it up however you like,

00:48:11.926 --> 00:48:14.526 A:middle
whatever library you
like to use, feel free

00:48:14.746 --> 00:48:17.906 A:middle
and then you get an SB
command return object which is

00:48:17.906 --> 00:48:19.496 A:middle
like of a talk-back object.

00:48:19.496 --> 00:48:21.226 A:middle
It's the command
talking to LLDB.

00:48:21.606 --> 00:48:24.606 A:middle
That object allows the command
to tell the debugger, "Hey,

00:48:24.606 --> 00:48:27.076 A:middle
I worked, everything
is fine" or "Love,

00:48:27.196 --> 00:48:29.106 A:middle
sorry I really couldn't
do this today

00:48:29.106 --> 00:48:30.566 A:middle
for you, try again tomorrow."

00:48:30.566 --> 00:48:35.186 A:middle
And could you please tell
the user, "Hello Wilt,"

00:48:35.266 --> 00:48:37.306 A:middle
yes the command return
object knows how to do that.

00:48:37.376 --> 00:48:43.456 A:middle
And that's how you add one
to the LLDB environment.

00:48:43.456 --> 00:48:45.006 A:middle
So, we have all these knowledge.

00:48:45.456 --> 00:48:47.616 A:middle
Now let's get back to
our task calculated

00:48:47.616 --> 00:48:48.656 A:middle
in the depth of a recursion.

00:48:49.296 --> 00:48:51.936 A:middle
What I need to do is I need
to loop over all the frames,

00:48:52.486 --> 00:48:55.686 A:middle
check if each frame is a
part of my recursion or not

00:48:55.686 --> 00:48:58.746 A:middle
and at the end I would not tell
the user I did the calculation

00:48:58.746 --> 00:48:59.856 A:middle
for you and it looks

00:48:59.856 --> 00:49:01.686 A:middle
like there's 10 frames
of your recursion.

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:48:59.856 --> 00:49:01.686 A:middle
like there's 10 frames
of your recursion.

00:49:01.926 --> 00:49:04.846 A:middle
This is how you do
the first step.

00:49:05.906 --> 00:49:08.366 A:middle
It's one line of Python,
it's really powerful

00:49:08.366 --> 00:49:10.436 A:middle
because now you see that
you have this thread object

00:49:10.686 --> 00:49:12.896 A:middle
and you can tell the
thread what are all frames

00:49:13.236 --> 00:49:17.056 A:middle
and these frames object
binds you a Python iterator

00:49:17.056 --> 00:49:18.296 A:middle
so they can loop over each one.

00:49:18.796 --> 00:49:23.386 A:middle
But hold on, I know some
of you are looking at this

00:49:23.386 --> 00:49:25.466 A:middle
and they're perplexed
because they saw

00:49:25.466 --> 00:49:27.716 A:middle
that I was given an SB debugger.

00:49:27.716 --> 00:49:29.006 A:middle
I wasn't given an SB thread.

00:49:29.476 --> 00:49:30.606 A:middle
How do I get here?

00:49:30.826 --> 00:49:33.696 A:middle
Well, the LLDB object
model is extremely powerful

00:49:33.696 --> 00:49:36.146 A:middle
in this respect because
I can ask the debugger

00:49:36.146 --> 00:49:37.756 A:middle
that I could pass
as a Python command.

00:49:38.296 --> 00:49:39.786 A:middle
Tell me the thing
you're debugging now,

00:49:39.786 --> 00:49:42.646 A:middle
tell me your SB target, the
thing at the top of the UI.

00:49:42.826 --> 00:49:46.346 A:middle
And then I can tell that
target, "Give me your process,

00:49:46.506 --> 00:49:49.526 A:middle
give me your live-running
thing and process.

00:49:49.756 --> 00:49:52.986 A:middle
Can you please tell me what
thread I currently selected,

00:49:52.986 --> 00:49:54.636 A:middle
we're currently looking at."

00:49:55.466 --> 00:49:57.626 A:middle
And now I actually
have the thread

00:49:57.626 --> 00:49:59.276 A:middle
and you're not perplexed
anymore.

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:50:00.036 --> 00:50:03.986 A:middle
So let's get going, I can ask
you to frame the question,

00:50:05.126 --> 00:50:06.876 A:middle
what's your function
and I can ask

00:50:07.086 --> 00:50:08.956 A:middle
that function a question,
what's your name?

00:50:09.616 --> 00:50:11.646 A:middle
If that name is the
name that I'm looking

00:50:11.646 --> 00:50:14.466 A:middle
at is my target name then I
know to update the calendar.

00:50:14.556 --> 00:50:18.446 A:middle
And at the end, I'll
say this is the result.

00:50:19.276 --> 00:50:21.576 A:middle
Now I can print to
that result object

00:50:21.576 --> 00:50:25.126 A:middle
as if it was a Python file
because we went so deeply

00:50:25.126 --> 00:50:28.766 A:middle
with this API Integration that
has become a return object.

00:50:28.846 --> 00:50:31.736 A:middle
Looks just like a file to Python
just praying to it at will.

00:50:33.456 --> 00:50:36.556 A:middle
This is the full code and you
can look at it from the slides,

00:50:36.556 --> 00:50:38.956 A:middle
I'm not going to go
all of these right now.

00:50:39.166 --> 00:50:40.796 A:middle
Let's just look at
the command in action.

00:50:41.286 --> 00:50:42.856 A:middle
We stop, we got a recursion.

00:50:43.016 --> 00:50:46.956 A:middle
I can count the frames,
I can barely see 1, 2,

00:50:46.956 --> 00:50:49.416 A:middle
3 or maybe that's not
good, OK let's not do this.

00:50:49.866 --> 00:50:52.406 A:middle
Let's just ask LLDB, I'll
call the [inaudible] command.

00:50:52.846 --> 00:50:55.166 A:middle
LLDB will think about it,
hopefully very briefly

00:50:55.166 --> 00:50:58.426 A:middle
and it will give us the
answer that's 20 frames.

00:50:58.906 --> 00:51:01.306 A:middle
Some of you probably
have counted the frames

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:50:58.906 --> 00:51:01.306 A:middle
Some of you probably
have counted the frames

00:51:01.396 --> 00:51:03.506 A:middle
and raise your hand
if they're not ready.

00:51:04.816 --> 00:51:08.176 A:middle
No one? OK then I guess
I believe the Debugger.

00:51:09.206 --> 00:51:11.376 A:middle
Let's move on, breakpoint
actions.

00:51:12.776 --> 00:51:16.146 A:middle
Sean has told us a lot of
great things about breakpoints.

00:51:16.336 --> 00:51:18.266 A:middle
He has shown us that
they are really powerful

00:51:18.266 --> 00:51:19.426 A:middle
and there's all these
amazing ways

00:51:19.426 --> 00:51:20.926 A:middle
that he can set breakpoints
in your code.

00:51:21.916 --> 00:51:23.716 A:middle
But by default, it's

00:51:23.716 --> 00:51:25.556 A:middle
at a breakpoint it
stops all the time.

00:51:26.256 --> 00:51:28.146 A:middle
That's why we have
conditional breakpoints, right?

00:51:28.366 --> 00:51:29.916 A:middle
So they don't stop all the time

00:51:30.726 --> 00:51:34.286 A:middle
but conditional breakpoints
unlike looking at your program

00:51:34.286 --> 00:51:37.366 A:middle
from within so they don't have
access to the LLDB object model,

00:51:37.366 --> 00:51:39.086 A:middle
they're like peers
to your program.

00:51:39.876 --> 00:51:41.666 A:middle
Breakpoint action
is written in Python

00:51:41.706 --> 00:51:45.536 A:middle
in a full program inspection
and by full program inspection,

00:51:45.656 --> 00:51:48.586 A:middle
I mean that they have access
to the data, they have access

00:51:48.586 --> 00:51:51.976 A:middle
to the code and they have also
access to the LLDB object model

00:51:52.146 --> 00:51:54.546 A:middle
because they're like running
from above, they're running

00:51:54.546 --> 00:51:57.426 A:middle
on peer with debugger and
looking at your program instead

00:51:57.426 --> 00:51:59.266 A:middle
of on peer with your programs.

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:52:00.556 --> 00:52:01.586 A:middle
How do they work?

00:52:01.826 --> 00:52:04.966 A:middle
Pretty easy, you probably
hold and got this by now,

00:52:05.366 --> 00:52:07.696 A:middle
breakpoint actions
associated in breakpoint

00:52:07.906 --> 00:52:08.926 A:middle
with a Python function.

00:52:09.386 --> 00:52:12.356 A:middle
Whenever I hit the breakpoint,
the Python function is invoked.

00:52:13.736 --> 00:52:16.276 A:middle
That's one little bit of a
secret sauce here which is new

00:52:16.276 --> 00:52:19.746 A:middle
in Xcode 5 and it's a little
bit of a secret sauce is

00:52:19.806 --> 00:52:22.266 A:middle
that the Python function can
choose to return a value.

00:52:22.916 --> 00:52:25.696 A:middle
If that function chooses
to return the value false,

00:52:25.846 --> 00:52:28.886 A:middle
the logical value false,
that is the equivalent

00:52:28.886 --> 00:52:30.886 A:middle
of checking the automatically
continue

00:52:31.026 --> 00:52:33.736 A:middle
after evaluating check box
in the Xcode user interface.

00:52:34.726 --> 00:52:36.976 A:middle
What's so interesting
about this is

00:52:36.976 --> 00:52:39.976 A:middle
that these can actually employ
arbitrary amounts of logic

00:52:40.156 --> 00:52:43.156 A:middle
to decide whether that little
check box should be checked

00:52:43.156 --> 00:52:44.826 A:middle
or not in this particular
instance

00:52:44.826 --> 00:52:46.546 A:middle
of stopping at a breakpoint.

00:52:47.106 --> 00:52:50.646 A:middle
You read a function with
this kind of prototype

00:52:51.026 --> 00:52:53.356 A:middle
and gets Python as
reframed, and gets Python

00:52:53.356 --> 00:52:55.486 A:middle
as the breakpoint location
which is the location

00:52:55.486 --> 00:52:56.756 A:middle
on which the breakpoint was hit.

00:52:57.616 --> 00:53:00.416 A:middle
And that's how you bind
one breakpoint command at.

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:52:57.616 --> 00:53:00.416 A:middle
And that's how you bind
one breakpoint command at.

00:53:01.026 --> 00:53:05.226 A:middle
Let's give an example,
let's go back

00:53:05.226 --> 00:53:07.276 A:middle
to our old idea of recursion.

00:53:07.366 --> 00:53:09.436 A:middle
I find it right recursion a lot.

00:53:10.736 --> 00:53:12.626 A:middle
My program is doing
some recursive thing

00:53:12.696 --> 00:53:15.056 A:middle
but I'm not great of recursion

00:53:15.056 --> 00:53:17.026 A:middle
so my program hangs
while doing it.

00:53:17.576 --> 00:53:19.756 A:middle
I don't really know
what's going on.

00:53:19.756 --> 00:53:23.566 A:middle
I get some reports and sometimes
I can actually make it happen

00:53:23.566 --> 00:53:25.556 A:middle
sometimes I cannot
actually make it happen.

00:53:26.076 --> 00:53:27.546 A:middle
It's really frustrating.

00:53:27.546 --> 00:53:29.576 A:middle
I don't know how to set a
breakpoint condition here.

00:53:30.756 --> 00:53:32.146 A:middle
Well here's the idea.

00:53:32.976 --> 00:53:36.846 A:middle
I can make a breakpoint action
that looks at the call stack

00:53:36.956 --> 00:53:40.546 A:middle
and I can tell LLDB you
really should always stop

00:53:40.546 --> 00:53:43.306 A:middle
if that recursion is getting
too deep out of control.

00:53:44.226 --> 00:53:45.076 A:middle
So that's what you get

00:53:45.196 --> 00:53:46.966 A:middle
for actually attending
the LLDB session.

00:53:47.026 --> 00:53:48.906 A:middle
You get these cool ideas
that you can go back

00:53:48.906 --> 00:53:50.356 A:middle
and implement in
your situations.

00:53:51.566 --> 00:53:54.866 A:middle
Let's make it happen, there's
two things that I need to do

00:53:54.866 --> 00:53:56.816 A:middle
to make this magic
happen, right?

00:53:57.306 --> 00:54:00.796 A:middle
I need to see how deep the
recursion is and I need to stop

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:53:57.306 --> 00:54:00.796 A:middle
I need to see how deep the
recursion is and I need to stop

00:54:00.796 --> 00:54:03.476 A:middle
if that's more deep than
I'm willing to accept.

00:54:04.686 --> 00:54:08.066 A:middle
Here's great news, there's
two things that we need to do

00:54:08.236 --> 00:54:09.466 A:middle
and we already did one.

00:54:10.206 --> 00:54:12.646 A:middle
That's the exact same
command that we did before

00:54:12.856 --> 00:54:14.526 A:middle
and since this is
a Python thing,

00:54:14.526 --> 00:54:16.186 A:middle
this is not some little
heart codie [phonetic]

00:54:16.186 --> 00:54:17.066 A:middle
command language.

00:54:17.406 --> 00:54:20.096 A:middle
It means that I can actually
take all these features

00:54:20.096 --> 00:54:22.616 A:middle
that I've read before
and I can reuse them

00:54:22.616 --> 00:54:23.906 A:middle
in these different scenarios.

00:54:23.906 --> 00:54:26.686 A:middle
I'll only need to do
one little thing here.

00:54:27.496 --> 00:54:30.526 A:middle
If I count the depth and I see

00:54:30.526 --> 00:54:33.336 A:middle
that the recursion depth is
smaller than the threshold

00:54:33.336 --> 00:54:35.976 A:middle
that I decided that is too
deep going out of control,

00:54:36.366 --> 00:54:38.316 A:middle
then my breakpoint
action returns false

00:54:38.316 --> 00:54:39.966 A:middle
and LLDB just continues.

00:54:40.676 --> 00:54:44.846 A:middle
It's for lines of code
right here that implement

00:54:44.846 --> 00:54:47.596 A:middle
that breakpoint action that
looks at all the frames,

00:54:47.726 --> 00:54:50.596 A:middle
calculates the depth and
decides if it should stop or not

00:54:50.596 --> 00:54:52.456 A:middle
at their breakpoint
for lines of code.

00:54:53.056 --> 00:54:55.986 A:middle
And here it is in action.

00:54:57.046 --> 00:54:59.996 A:middle
It's the same situation
as before we stopped

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:55:00.316 --> 00:55:01.736 A:middle
and there's 20 frames.

00:55:01.926 --> 00:55:04.016 A:middle
I guess we can-- we
have a confirmation

00:55:04.016 --> 00:55:06.366 A:middle
that it really was trying
the frames an example before.

00:55:10.656 --> 00:55:12.376 A:middle
Prototypes and customizations,

00:55:12.486 --> 00:55:14.546 A:middle
why do we need prototypes
and customization?

00:55:14.716 --> 00:55:18.916 A:middle
Well, I hope that by the time
WWDC is over and you're all back

00:55:18.916 --> 00:55:22.056 A:middle
to your offices, you're actually
going to take my word for it

00:55:22.326 --> 00:55:24.306 A:middle
and you're going to start
running your LLDB summaries

00:55:24.306 --> 00:55:27.096 A:middle
and your LLDB commands and then
you're going to click the LLDB

00:55:27.096 --> 00:55:29.826 A:middle
and you're going to type
them again the next time

00:55:29.996 --> 00:55:31.996 A:middle
and then you're going to
type them again the next time

00:55:32.186 --> 00:55:33.736 A:middle
and then you're going to
type them again the next time

00:55:33.966 --> 00:55:35.806 A:middle
until all you're doing is
actually typing this LLDB

00:55:35.806 --> 00:55:37.796 A:middle
customizations and you're
a little typing monkey

00:55:37.796 --> 00:55:39.236 A:middle
and you wish you never
really started doing this

00:55:39.236 --> 00:55:42.826 A:middle
in the first place, it's
horrible, stop this please.

00:55:42.876 --> 00:55:45.356 A:middle
Well, it doesn't
have to be like that.

00:55:45.806 --> 00:55:47.386 A:middle
We thought about the situation

00:55:47.386 --> 00:55:51.186 A:middle
and LLDB has a specific
configuration file

00:55:51.466 --> 00:55:54.856 A:middle
which very unsurprisingly
is called .lldbinit

00:55:54.856 --> 00:55:56.486 A:middle
and sits in your home folder.

00:55:57.136 --> 00:55:59.796 A:middle
That file is loaded
every time we start

00:55:59.796 --> 00:56:01.476 A:middle
up a debug session with LLDB.

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:55:59.796 --> 00:56:01.476 A:middle
up a debug session with LLDB.

00:56:02.226 --> 00:56:04.656 A:middle
It's a great place to
treat debugger settings.

00:56:05.186 --> 00:56:06.966 A:middle
It's a great place
to load scripts

00:56:07.016 --> 00:56:09.156 A:middle
that you find yourself
using more and more

00:56:09.156 --> 00:56:12.046 A:middle
as you become proficient
with LLDB.

00:56:12.296 --> 00:56:15.546 A:middle
If anything is to be loaded
only when you're using LLDB

00:56:15.546 --> 00:56:21.076 A:middle
from within Xcode, the LLDB
init-Xcode is the place

00:56:21.076 --> 00:56:22.276 A:middle
to go to put those things.

00:56:22.956 --> 00:56:27.876 A:middle
So we covered quite
a great deal today.

00:56:28.226 --> 00:56:31.166 A:middle
We're almost at the end of
this brief journey together.

00:56:31.306 --> 00:56:33.486 A:middle
Well good things must
come to an end I guess

00:56:34.056 --> 00:56:39.576 A:middle
but let's make a recap the
most topics that we saw today.

00:56:39.576 --> 00:56:42.836 A:middle
LLDB is the debugger in Xcode 5.

00:56:43.496 --> 00:56:46.776 A:middle
It's more efficient than
ever before and it's packed

00:56:46.876 --> 00:56:49.606 A:middle
with great new features
for you to go out and use.

00:56:50.236 --> 00:56:53.846 A:middle
We actually covered some of
those great features right

00:56:53.946 --> 00:56:55.236 A:middle
in this room, right today.

00:56:56.786 --> 00:57:00.096 A:middle
Sean showed us great way to
be effective when debugging.

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:56:56.786 --> 00:57:00.096 A:middle
Sean showed us great way to
be effective when debugging.

00:57:01.076 --> 00:57:03.606 A:middle
How I can use logging
and assertions

00:57:03.986 --> 00:57:06.346 A:middle
to debug even before
actually starting debugging

00:57:07.116 --> 00:57:10.026 A:middle
and how I can set the right
breakpoints to make sure

00:57:10.026 --> 00:57:12.476 A:middle
that I'm looking at just
the code I care about

00:57:12.476 --> 00:57:13.596 A:middle
and I don't waste my time

00:57:13.596 --> 00:57:15.876 A:middle
and I can be a productive
debugger engineer.

00:57:16.886 --> 00:57:19.656 A:middle
Well, then we talked about how

00:57:19.656 --> 00:57:21.716 A:middle
to exploit customizations
properly.

00:57:21.916 --> 00:57:24.596 A:middle
We showed ways that data
formatter has allowed us to be--

00:57:25.126 --> 00:57:27.966 A:middle
to view data in a much more
meaningful way than before.

00:57:27.966 --> 00:57:31.206 A:middle
And we saw that we can
automate repeated workflows

00:57:31.206 --> 00:57:33.796 A:middle
with custom commands and
with breakpoint actions,

00:57:35.066 --> 00:57:36.306 A:middle
has lots of great content.

00:57:38.566 --> 00:57:40.686 A:middle
For more information
about any of these things

00:57:40.686 --> 00:57:42.646 A:middle
and anything else to be really,

00:57:42.846 --> 00:57:45.036 A:middle
Dave DeLong is our
famous evangelist.

00:57:45.036 --> 00:57:46.106 A:middle
You can talk to him.

00:57:46.736 --> 00:57:49.096 A:middle
We have a lot of
documentation about LLDB though

00:57:49.096 --> 00:57:50.976 A:middle
that you can consult
before asking for help.

00:57:51.376 --> 00:57:53.996 A:middle
You can check the quick
start guide or you can log

00:57:53.996 --> 00:57:56.906 A:middle
in to LLDB website or
within LLDB itself,

00:57:57.016 --> 00:57:58.286 A:middle
you can get help about LLDB.

00:57:58.286 --> 00:58:00.796 A:middle
If you don't know exactly
what you're looking for,

WEBVTT
X-TIMESTAMP-MAP=MPEGTS:181083,LOCAL:00:00:00.000

00:57:58.286 --> 00:58:00.796 A:middle
If you don't know exactly
what you're looking for,

00:58:01.036 --> 00:58:02.756 A:middle
you can use the appropriate
po keyword for--

00:58:02.756 --> 00:58:05.116 A:middle
appropriate po command
followed by one or more keywords

00:58:05.116 --> 00:58:06.856 A:middle
and LLDB will look for
help on that thing.

00:58:07.336 --> 00:58:09.036 A:middle
And of course if
you have questions,

00:58:09.366 --> 00:58:11.836 A:middle
the Apple developer forums
are a great place to go.

00:58:11.836 --> 00:58:16.216 A:middle
There's been a couple of
related sessions over the week

00:58:16.216 --> 00:58:19.106 A:middle
that will mention LLDB
and debugging in general,

00:58:19.296 --> 00:58:22.256 A:middle
the new in Xcode 5 and the
session about debugging

00:58:22.256 --> 00:58:24.166 A:middle
with Xcode that Kate
mentioned before

00:58:24.946 --> 00:58:26.886 A:middle
and thank you for
joining us today.

00:58:27.016 --> 00:58:28.576 A:middle
[ Applause ]

00:58:28.576 --> 00:58:28.846 A:middle
Thank you.