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.