Hello everyone.

In this sequence we're going
to quickly present the debugger,

and the notion of breakpoints,
the different breakpoints in Pharo.

What you'll see is that

the system is alive
and that we can communicate,

we have to communicate
with it and its objects.

We don't work with source code,
we work with objects,

which have a state,
and receive and send messages.

Don't be afraid of using the debugger.

We can code in debugger,
inspect the program while it's running...

It's a powerful and really useful tool.

I know several developers,
myself included,

who have a tendency
to develop directly in debuggers.

So a great deal of code
is written in debuggers rather than

in a code browser.

The advantage of that is,
while you're writing the code,

you've access to the method settings,
to the objects, to the variables.

You can see it all and test it.

You've all the data to hand
to be able to test it

while writing the code.

The debugger looks like this.

There's a title bar
indicating the error message.

Here's the "stack", the call stack,

that's to say the call method.
Here we can see that

this method, "performTest"
has called the method "testSumming",

which has called the method "place",

which has raised the problem
"DoesNotUnderstand".

Here we have the code
of the area that's selected here.

What's selected here is the method
plus the DiceHandle class,

so it appears in the lower window.

And right at the bottom
we have different variables,

all the variables accessible

within the context
of the execution underway,

in order to modify the variables,

to inspect the objects, etc...

It's a group of actions
in that area that allows us

to restart the execution
of the method or dive into the code

or see line by line what's happening.

When a debugger opens,
closing it won't solve the problem.

It's much easier to open the debugger,

to look inside in detail
at what's causing the problem

and inspect the call stack and objects,

and fix the problem in debugger

rather than close it and then
guess why debugger opened.

The debugger is your best friend.

It allows you to communicate
with all the context objects,

whether it's the settings,
the instance variables, etc...

To check the state of all the variables
and even modify this state.

To send messages to check
the state of certain objects

or check how they're reacting.

We can, of course, modify the methods
on the call stack, saved,

and continue with the new code
without any problem,

all without restarting
execution from scratch.

So if a method fails,
we correct the method,

we restart execution of the method
and the program continues.

One way of debugging

that's very frequently used

is showing things on the console.

We can see that this is really

a poor way of debugging,
because you have to modify

all the methods you want traces in,
and then modify them again

to remove them when the problem's fixed.

And then you have to know,
or have an idea, where the problem...

Where the problem might lie,
or where it comes from,

to know where to put the line
and what to show.

The other way of doing this
is using breakpoints.

A breakpoint is a place in the code
where we'll indicate

to Pharo that it has to stop
next time it passes this place.

So the most simple breakpoint
is "Halt now".

Send the message "now"
to the object "Halt", which is a class,

which will immediately stop execution.

From there, a debugger will open.

We can see line by line what's happening,
the state of the program, etc...

So, "Halt now" pauses the program...

we can restart it,
but for now it's paused...

and opens a debugger with
the current state of the application.

So, "Halt now" is very good,

unless you put it in a method
that's executed constantly,

including by the system itself.

You can have dozens
of debuggers opening

if you put a "Halt now" in a place
used by an opening debugger.

So you put "Halt now"
in the debugger's code.

If the debugger opens,

it will execute "Halt now" itself,

which will open another debugger, etc,
recursively, and pause your system.

In this case, we use "Halt once",

which, once "Halt once" is activated,
stops once, pauses once,

and all the subsequent passages through
"Halt once" won't pause the program.

So we write "Halt once"
anywhere in the code,

we activate it, once,

we execute the program,

a debugger opens and
"Halt once" is immediately disabled.

Another possibility is to stop
after a number of iterations.

We might stop after the 10th iteration

if we know that an element
in a collection that interests us

is in 10th position.
It's not necessarily worth

debugging the 9
previous times for nothing,

so we stop at the 10th iteration.

Another possibility is to stop
when a particular condition

is true, so for that we have "Halt if".

"Halt if" either takes

a symbol indicating a method,

which has to be in the call stack
for the debugger to open,

meaning that,
if I put "Halt if:printString"

the Dice>>faces code has to be called

from the printString method

for the breakpoint

to activate and the program to pause.

"If" can also take a block.

We can put any
bit of code in the block,

if it evaluates to true,
to make the debugger stop,

for it not to open
and the program to continue.

Since the tests in Pharo
are methods in the call stack,

you can put the test number,
so that a bit of code only stops

when it's executed from a test.

All of these methods,
"now", "once", "onCount" and "if",

are methods in Halt class.

You can study the code,
see what the code's done to it,

and you can also add your own methods,

add your own kind of breakpoint
according to your needs.

So in the example below,

I've coded a breakpoint,
called "between: and"

which only stops the program

when it's in between
"minTime" and "maxTime".

So this program will only stop,

the debugger will only open,
between midnight and 2am.

You should know that
the debugger is a very powerful tool.

There are a lot of breakpoints
already defined in the system.

You can add as many as you like.

To add a breakpoint,
modify one method, the debugger opens,

and you can see line by line
what's happening.

The breakpoints are really powerful

and you shouldn't hesitate
to use them or the debuggers.