The source code view should reload when the underlying file changes, or at least offer to do so

[ell1e]

The source code view should reload when the underlying file changes, or at least offer to do so. When I debug with Seer, which I've done extensively a few hours ago to test it out, I often seem to be getting stuck in this loop when I fix things:

1. I hit a bug of my program that I can see in Seer. Seer is still open at this point and execution is paused.
2. I edit the underlying code to make a partial fix, but often that's still breaking. I do that in my code editor which is not Seer but a separate window.
3. I do a rebuild outside of Seer, via make or whatever.
4. (Optional/only sometimes) I run some sort of unit test outside, Seer still open, confirming it's still not working right. Or for some other reason I suspect it can't be fully working yet at this point.
5. I click "Run" in Seer, or "File" > "Debug" and then "OK" in the launch dialog, to restart with the updated executable.
6. I step through Seer again, only to see that while I'm using the new executable I'm looking at the old code and the whole debugging session turned kind of useless since nothing really lines up.

So at that point I just end up CTRL+C'ing Seer a lot and just restarting it, and then re-entering the launch path and everything, and it slows down debugging by a lot since I need to do this after every partial fix. An automatic code reload would fix all that and would be very appreciated as a result! (Unless there's already a way to somehow fix this workflow that I just haven't run into.)

[epasveer]

I can see that problem happening.

I'll add something for the editor windows to detect if the underlying file changes (timestamp or size) and prompt for a reload,

[ell1e]

It would be nice if on a reload, it would keep the vertical scroll position of the code view tabs! Also, instead of a popup prompt, since the other popup (the execution messages) is already pretty disruptive sometimes, maybe something like gedit's change toolbar notification would be less so?

Sorry if all of that is too much work, but in Seer this would reduce a reload to 2 targeted slow clicks:

• Click a hypothetical "Reload" in code view tool bar without all the other clicks to get back where I was.

• One click to "Run" again after adjusting breakpoints, and untargeted fast click to hide the stdin/stdout window (just anywhere outside is enough since it's not always-on-top). Assuming the execution messages popup can be and was disabled.

While currently it's like, 4+ targeted slow clicks:

• One targeted click to close outdated center code view tab.

• Two targeted clicks or more in the file tree to the left to show and reopen the code view tab, then a scroll in the center code view and/or a click in the frames list to get back to where I was.

• One click at "Run" to start over after I adjusted breakpoints.

• One targeted click to close the execution messages window, then the fast untargeted one to get rid of stdin/stdout blocking my view.

With multiple fix and debug cycles, I feel like it just adds up a lot.

[epasveer]

maybe something like gedit's change toolbar notification would be less so?

I think this is do-able.

[epasveer]

So far, I have it look like this when Seer automatically detects the file has changed.

To force a manual reload, there is a button available after you hit ^F (to bring up the search bar).

I'll likely add a ^R hot-key to manually reload the file at any time.

[ell1e]

It looks great. A small improvement suggestion I have is it would look visually more clear if the "Reload" button was surrounded by the green as well, so it's visually grouped, even if that needs slightly more screen space to fit it all into the green area. But that's a really minor nitpick. Thanks so much for looking into this!

[epasveer]

But that's a really minor nitpick. Thanks so much for looking into this!

Not a problem at all. I'm loving this!

[epasveer]

The buttons get their colors changed too. I suspect that is okay.

[ell1e]

It looks great, but the "Reload" is a bit low contrast. Could be solved with just making the shade of green darker on everything, or alternatively, making the shade of green brighter and keeping black text color. But this is looking neat, I like it!

[epasveer]

The latest "main" has everything.

The shade difference is due to KDE's/Qt's theming of buttons and widgets.

[epasveer]

One thing to note about breakpoints.

Seer tries to remember breakpoints after a program restart. With line numbers changing, and reloading of source files, it's likely the breakpoints will get out of sync. GDB will try its best to shuffle them around. Seer will honor whatever GDB does. It may not behave 100% the way you like (ie: the breakpoints may not be moved properly).

[ell1e]

The latest "main" has everything.

Rebuilding to test it out right now! I'm very excited. :blush:

[ell1e]

It seems to be working! However:

Maybe this is due to dark mode? Maybe you could try to override either all of the colors (both to a green darker background and to a white text) of all the elements, or none of them, to avoid this.

[ell1e]

Okay, after some use of this I ran into a conceptual problem:

Often I update the underlying code file(s) once I realize there is some bug, with the intention of then retesting. The exact moment I realize that is usually when SeerGDB just let GDB get to some error condition that either caused execution to hit a breakpoint or SIGABRT and hence it paused, or I manually stepped there with it now paused, and I stared at the output realizing I did something dumb. So at this point, GDB is attached, the program binary was launched but is paused, and now I change the code file and save and type "make" to rebuild the binary, and right after, I hit the new "Reload" for the file in the SeerGDB code view. GDB is still attached and paused at this point.

Now I'm in a bad state where no button really does what I want: because what I would naturally do now is set up the break points again because now I'm looking at the new code, and I fixed something, and I just want to start over and do the whole thing again with new breakpoints and new binary from the new code I'm now looking at. However, GDB is still up and attached with the old binary and sources loaded. So I can't set the breakpoints, because SeerGDB immediately passes them to GDB but based on the new file, but GDB has the old files, and GDB is having none of it and is just doing super weird stuff, changing to random nonsensical lines for the breakpoints, etc. To solve that, the only working button that stops GDB from being stuck in this useless state seems absurdly enough to be the "Run" button, which would also clear out GDB's outdated state, make it reload source files and binary, and finally fix the breakpoints - but the thing is, I don't want to run yet, because I didn't yet set my new breakpoints! Even SeerGDB's "Interrupt" > "SIGKILL" doesn't help, because even when issuing that it seems like GDB doesn't let go of the killed program before I make it resume somehow.

Long story short, I think for longer sessions SeerGBB really could use a prominent "Stop" button. That button should do the equivalent of quitting the program in GDB but not GDB itself, loading the binary in GDB again but without executing GDB's run to launch it, and get me back into a clean stopped state where I can set up breakpoints and then press SeerGDB's "Run" again.

I hope that made sense and is actionable.

[epasveer]

Maybe you could try to override either all of the colors (both to a green darker background and to a white text) of all the elements, or none of them, to avoid this.

I couldn't get this to work. In the end, I changed it to an icon. There is something fishy with the Gnome qt style. My attempts at overriding the button's display style fails. So for now, it's an icon.

I've updated the "main" branch.

[epasveer]

I ran into a conceptual problem:

For this one, can you put it in its own task?

[ell1e]

Oh like, file a separate issue here on GitHub? Or is "task" some gdb or seergdb feature I should be testing out?

[epasveer]

A separate issue here on github. This way I can eventually close this issue and then work on the "conceptual " issue.

Sent from AT&T Yahoo Mail on Android

On Wed, Oct 4, 2023 at 6:48 PM, @.***> wrote:

Oh like, file a separate issue here on GitHub? Or is "task" some gdb or seergdb feature I should be testing out?

— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you were assigned.Message ID: @.***>

[ell1e]

Okay, here it is: #162 :+1:

[epasveer]

Thanks!

[epasveer]

I'm going to close this task. It can be reopened if need be.