Debugger: source code modifications of a self halted debugged method are out of sync (modifications outside the debugger)

[labordep]

During a debugging, when I'm started a test I'm arriving in an interessed method. In my case the concerned method have a self halt, I place some self halt to cannot forget an implementation of behavior during my dev. So the debugger is opening because of the self halt, ok. I'm editing the source code in a out of debugger code browser (with the system browser), warning : not inside the debugger. When I accept the new source code the currently debugged method are not synchronous with my new modifications.

Illustrated steps :

1 - Running my test

2 - Debugguer open when halt

3 - Open a browser on the same method and edit the source code, then do "Accept"

When I do "Accept" there is no update confirmation popup from the debugger.

4 - Restart the method step, but my modifications cannot appears : the source code iss out of sync

Other illustration of the out of sync adding a line of code true ifTrue:[nil].

[adri09070]

I just realized that I wanted to ask you a question but I forgot, @labordep.

Actually, this is not a bug in itself, in the sense that what happens is the current expected behavior (for us).

We can change this behavior but we will have to make a compromise between what you want (having the new method after refresh) and what others want (keep the same method).

I don't know what would be better : having an option in the debugger settings or having a popup that systematically asks the user which version of the method to choose ?

[labordep]

Hi @adri09070 good question! I think asking the user with a pop up after a modification is a good way. After an "Accept" the system should display a pop up with a message which notify that the source code of the currently debugging method have changed and if the user wants to load it (and restart) or not (ignore). I think this is the strategy used by visualworks, I don't remember in details but I need to check that.

[labordep]

For example this is the popup when I do the same thing in VisualWorks :

Exit : close the debugger. Ignore changes : this is the actual Pharo debugger behavior. Resend : this is my need :)

[StevenCostiou]

@labordep do you mean that, if the modified method is somewhere in the sender chain, you want it to be resent? It will potentially restart a context in the middle of your stack.

Isn't a popup intrusive? We could add a setting that enables the popup, and by default the current behavior stays. What do you think?

[labordep]

Yes of course it restart the stack at the edited point, but this is voluntary when you develop directly in the debugger. I think a popup is not intruisive, contrary this is good to ask the user. I think a good settings should propose to define a default action OR to ask for an action to do, because we cannot prevent user needs and to not propose a popup should be a problem because the user can forgot the default settings. For example the settings can be : [Actual behavior] [Resend message] [Ask with a popup]