Breakpoint Addresses Not Being Reevaluated On Each Run

[Pete-L-72]

To reproduce:

• Create a new project with the Klive sample code.
• Put a breakpoint on a line of code. e.g. line 9, "or a" in the sample code.
• Run the code.
• Insert a new line of code at line 9, moving the breakpoint to line 10 - I added another ld a,(hl)
• Run the code.
• -The code will break at line 9 instead of line 10.

My guess is the address associated with the breakpoint isn't being reevaluated as code around it changes and gets rebuilt.

Running the 0.37.0 build.

[Dotneteer]

Thanks for signing this issue! You are absolutely right about the reason for the issue.

Initially, I thought I could quickly fix this issue. However, it raises several questions:

1. Should I be able to edit source code while debugging a project? In my opinion, all source code files contributing to the current compilation should remain read-only during the debug session. (The editor does not behave like this currently.)
2. When the machine is stopped in a debug session, should the last execution point (if it is in the source code) be displayed to indicate where the machine has been stopped, or should it be removed? I think this last execution point should be removed; if it stays, you may think you're still debugging. (The editor does not behave like this currently.)
   When you edit the code, all the resolved breakpoints (the ones that got a physical address due to compilation) should be unresolved (their physical address removed).

Any thoughts?

[TheStruggleForAntiSpaghetti]

1. You could either:
   a. Freeze all text editor windows to prevent editing. Visual indication that editing is locked would help understand the situation, for example the tabs of open code files turning to a different color, such as orange tint:

Any typing when one of the source windows is focused, could result in a message like:

Editing not possible while debugging. Stop debugging to changes to the source code.

b. Stop debugging (basically "pressing" the Stop button as soon as a change is being made in one of the text (code) files.

I feel the 1st option is more explicit and clear.

2. I'm not sure if I'm understanding your question correctly. But when the Stop (or Pause for that matter) button is pressed, it should stop at the line of the source code which was being executed.

[Pete-L-72]

I suspect allowing editing while still debugging is more work than it's ultimately worth; it would presumably imply recompilation and reevaluation of the PC every time they resumed execution. Doable but likely difficult.
Making the code read-only would be reasonable. I'd suggest avoiding a modal message box though.. Perhaps a quiet message somewhere if possible.

[TheStruggleForAntiSpaghetti]

I'd suggest avoiding a modal message box though.. Perhaps a quiet message somewhere if possible.
Overall I don't prefer modal message boxes. But I feel in this case it might be justified as it's only an extra clarification that likely only happens once if the other hints aren't understood first time.

[Dotneteer]

Sorry for being silent for a while, i've just arrived back from a family retreat. Thanks for thu suggestions! I will use them to desing and implement this functionality.

[Pete-L-72]

No apology required! The tool is great already :)

On this issue, re-evaluating the breakpoint address on recompilation would make a huge difference regardless of any other nice-to-haves.

[Dotneteer]

You can download the private build (v0.46.5) from this link: https://1drv.ms/f/c/79da757d3d2b5baa/QqpbKz19ddoggHlnPAkAAAAAyMaLSBXRXrYANw

Now, compiled files are locked while a debug session is in progress.

[Pete-L-72]

Interestingly, I'm not finding compiled files to be locked during debugging. I wonder if this is a Windows vs Mac thing.

[TheStruggleForAntiSpaghetti]

They also don't lock here.

[Dotneteer]

@Pete-L-72, @TheStruggleForAntiSpaghetti, I'll check this issue soon.

[Dotneteer]

Interestingly, I'm not finding compiled files to be locked during debugging. I wonder if this is a Windows vs Mac thing.

@Pete-L-72 , When running your project with source code debugging, can you see the locked editor files (a little lock icon in their header)? All my tests (Mac, Windows) work and the compiled files are locked from editing during the source code debugging section. This feature requires v0.46.5 or above.

[TheStruggleForAntiSpaghetti]

It doesn't here (0.46.5). I can still freely edit while in debug.

[Dotneteer]

I see. I tried to reproduce this issue on my emulated Windows -- no success so far. I will try it again.