Screen flashes at each step

[inducer]

Screen flashes at each step

[lega911]

for me it depends on TERM, e.g. if TERM=screen it doesn't flash

[NguyenTam]

What terminal emulator do you use? I'm guessing many have the same issue iterm2 had, where flashes happen even when the steps are very fast. For steps that take time to complete, it will require the much more difficult fix described here.

I have just tested pudb3 with other terminals. Here are the results:

1. SSH to Debian 10 using Git Bash ($TERM=xterm) => flashes ~every step.
2. SSH to Debian 10 using powershell => ~ Doesn't flash.
3. Logged in the Debian 10 and opened gnome-terminal ($TERM = xterm-256color) => ~Doesn't flash.

So I will use powershell from now on 👍

P.S. Debian 10 is a virtual machine.

[inducer]

It's been irritating to me, too. First, a fact--VT100 (or some variety, whatever) supports "main" and "alternate" buffers. pudb (urwid really) draws itself in the alternate buffer. Whenever the program gets executed, pudb switches back to the main buffer, and when the program returns control to pudb, it restarts urwid and switches to the back buffer. Ta-da, screen flashes.

I can see a number of possible fixes:

• Put one of our agents in place of sys.stdout and sys.stderr and sys.stdin. Only switch screens if there's interaction with them going on. This is potentially wrong, because those are not the only things that may output to the screen. It's also breakable--as soon as the debuggee starts messing with sys.std{in,out,err}, we're pretty hosed. Upside: solves most of the issue, most of the time, and is pretty easy.
• Redirect output wholesale to a window within urwid. Even more breakable. Harder. Not clear what to do with stdin. Bonus points: Do this at the level of the file descriptors. This starts to get really yucky. Oh, urwid messes with file descriptors, too. I reported this to Ian a long while ago, so perhaps this has been fixed.

My favorite solution: Option 1, with a user-accessible option to fall back the current behavior (switch on every debuggee execution).

[asmeurer]

I don't see how option 2 is much more than option 1 (certainly option 2 requires option 1). Stdin could just be an Urwid input box. Another annoyance that I failed to mention is that when there actually is output to stdout, it disappears before you have a chance to see it. Of course, there are a thousand ways that the debuggee could mess up the debugger, so I wouldn't feel too bad about adding another one. We could probably even be a little robust against it by checking at each stage if sys.std{in,out,err} is still the custom std{in,out,err}.

Of course, option 1 is the easiest, and it would fix the problem at hand. So I would go for that for starters. But I wouldn't rule out option 2 if someone wants to implement it.

[asmeurer]

Does this solution make sense for stdin? How does one detect when raw_input (or equivalent) is being used?

[asmeurer]

Since, as I noted, you can't actually see the result of stdout/stderr unless the step takes a long time, would it be reasonable to just not switch screens until quit (or maybe add a command to see the main screen without quitting)?

[inducer]

Ctrl-o is that command, i think... as is '!'. Also, sadly, the main buffer has to be active during output .

Aaron Meurer [email protected] schrieb:

Since, as I noted, you can't actually see the result of stdout/stderr
unless the step takes a long time, would it be reasonable to just not
switch screens until quit (or maybe add a command to see the main
screen without quitting)?

---

Reply to this email directly or view it on GitHub:
#48 (comment)

[asmeurer]

Ah, so stdout doesn't work unless the buffer is active. I wasn't sure. So we would have to buffer it.

[inducer]

Except instead of buffering, I would say, switch screen, perform output, and switch screen back on reentry to debugger--that's essentially option 1 above.

[asmeurer]

And we're back full circle :) I guess my thought that we could never switch at all was based on the thought that you could write to stdout without switching screens.

I figured out where this is happening in the code (show and hide). I also figured out that if you show but don't hide, it messes up your terminal session permanently, so a good deal of care is needed to make sure that screen.stop is always called (i.e., in a finally block).

[bukzor]

@asmeurer If you'd show your non-working patches, I might be able to pick up where you left off.

It seems to me that fixing this flicker and getting ctrl+o to work would be one patch. Capture the debug-ee processes output into a fake stdout object (avoiding flicker), then write the contents of our fake stdout buffer to screen upon ctrl+o?

This might become problematic if the output of a program is quite large. Possibly a pty or something would be a more general solution. How much does pudb care about windows compatibility?

[asmeurer]

Let me see if I can reproduce it.

[inducer]

You also need to deal with stdin. As soon as something starts reading from that, you need to be on the output screen.

I'm also not entirely happy with just catching I/O at the level of Python--what about output from C extensions?

Should we run the debuggee with I/O attached to a pseudoterminal?

Note that I'm not trying to make this harder than it already is. I'm ok merging a half-way solution as long as:

• It's easy to back out.
• It's optional.

[asmeurer]

I don't remember if I did more, but the place in the code that does this is at https://github.com/inducer/pudb/blob/master/pudb/debugger.py#L1342. I'm not sure why it uses an integer instead of a boolean btw. If you replace hide with a noop, it doesn't stop showing the debugger. It apparently still does print, but it goes away immediately because of redraw. Also be warned that if you do remove hide that your terminal will be broken as soon as you exit pudb (or at least it is for me with iTerm 2).

[asmeurer]

Might we have more control over the situation when PuDB is run on a script (as opposed to a set_trace)? We could then run everything through subprocess for example.

[audleman]

Any movement on this? I've just installed pudb and I freakin' love it, other than that the screen flash makes it unusuable.

[inducer]

In almost every terminal I've tried (Gnome Terminal, KDE Konsole, xterm, tmux inisde all of these), the flicker from buffer swapping is not noticeable (to me) because it's so fast. The only terminal where I noticed flickering was Google hterm (and that ran over websockets to a cheapo VM that's six states away). So while I sympathize with attempts to solve this, it's not high up on my personal list of priorities. Maybe a faster terminal could help make this less irritating?

[asmeurer]

Interesting. For me, the flashing is really bad in iTerm2 and Terminal.app, but when using tmux in Terminal.app, it's not bad (basically doesn't happen at all unless something is printed the screen). However, it's even worse when using tmux in iTerm2 without tmux integration and about the same when using the integration. The iTerm2 developer is pretty responsive, so maybe we should contact him and see if he has any thoughts.

@audleman what terminal do you use?

[asmeurer]

I sent an email to the iTerm2 mailing list.

[audleman]

I'm in Terminal.app. Can you tell me how to use tmux? If that solves it the majority of the time I'm happy.

[bukzor]

tmux new" will drop you into a fresh session

On Wed, Jan 6, 2016, 17:38 Kevin Audleman [email protected] wrote:

I'm in Terminal.app. Can you tell me how to use tmux? If that solves it
the majority of the time I'm happy.

—
Reply to this email directly or view it on GitHub
#48 (comment).

[audleman]

It works way better in tmux. Still a flicker, but not too much of a bother. Certainly worth putting up with for the speed and power this tool gives me. Thanks for the info!

A separate question: does anybody know how to properly configure key bindings in OSX? Backspace prints out a ^H; once I've gone to the command line and typed anything, my whole session is ruined. All keyboard commands get captured by the console, and all I can do is Ctl-D to exit.

[asmeurer]

I believe Terminal has a setting regarding sending backspace as Ctrl-H. No idea about the rest of tmux. You'll have to look that up.

[audleman]

Guys I got it working well enough. Still a bit of trouble with the mini console, but if I use ! to go to ipython I can do what I want.

I can barely contain my excitement at this tool. Seriously, thank you for the work you've put into it!

[asmeurer]

Thanks to @gnachman, this is no longer an issue in iTerm2 https://gitlab.com/gnachman/iterm2/issues/4123 (and there's no need to use tmux). As long as the code run for each step is fast, it won't flash (the delay seems to be long enough that when it does change modes it doesn't appear "flashy").

You can download a nightly https://iterm2.com/downloads.html to test it, and hopefully it will make it to a beta or final release soon.

Getting an Urwid I/O to avoid buffer changing entirely would still be awesome, as it would mean that you look at your code even when it is running, but that is a lot of work as noted above.

[NguyenTam]

Same issue in pudb 2019.1 on Debian 10.
Flash console output ~every step.

[asmeurer]

What terminal emulator do you use? I'm guessing many have the same issue iterm2 had, where flashes happen even when the steps are very fast. For steps that take time to complete, it will require the much more difficult fix described here.

[bukzor]

Has anyone figured out what exactly causes/correlates with this issue? It sounds like it's a combination of terminal implementation and TERM setting, but I wonder if there's anything more specific than that.

[asmeurer]

Well the flashing in principle can occur whenever pudb enables/disables the alternate screen in quick succession. Perhaps we can create a short script that does just this at various rates to experiment. The only pudb option that should affect it is the display driver option.

[gnachman]

Have you thought of using decset 2026?

CSI 2026 h

switch to alternate screen, do whatever — the screen will not be redrawn

CSI 2026 l

For context: microsoft/terminal#8331

[inducer]

IIUC the control sequence from the link would not serve us for this purpose, as we use primary/alternate to keep debugger and main program output separate. If we were to use this, the program output would write over the debugger UI at some indeterminate location.

[asmeurer]

Most of the time, nothing is written to stdout though. Is it possible to use this in the common case and only do the "flash" sequence when stdout gets written to?

(although I will admit that if we're going to monkeypatch/capture stdout, that's already half of just implementing an inline output widget as discussed above, unless we can detect if the primary screen is being written to in some other way)

[bukzor]

If you could write the patch, I'll certainly try it out.

…

On Wed, Jul 13, 2022, 1:24 PM George Nachman ***@***.***> wrote: Have you thought of using decset 2026? CSI 2026 h switch to alternate screen, do whatever — the screen will not be redrawn CSI 2026 l For context: microsoft/terminal#8331 <microsoft/terminal#8331> — Reply to this email directly, view it on GitHub <#48 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAE4KSB5O34LIR5723ONHOLVT4CVFANCNFSM4AB7KFXQ> . You are receiving this because you commented.Message ID: ***@***.***>

[apivovarov]

year 2023 - how to solve the issues with flashing terminal? I'm using ssh to connect to some aws instance where I need to debug.

[laoshaw]

yes it still flashes, TERM to screen does not help either. otherwise pudb will be the perfect TUI debug tool