Live data from Hacker News

Show HN: Austin-Tui – Spy inside a running Python program at no performance cost

github.com

11–20 of 38 posts

Re: Show HN: Austin-Tui – Spy inside a running Python program at no performance cost

#12

Love the TUI! Which library did you use for it?

I wrote a blog post about the technology behind the TUI

https://p403n1x87.github.io/the-austin-tui-way-to-resourcefu...

It's a custom resource-based framework that uses curses as back-end.

Re: Show HN: Austin-Tui – Spy inside a running Python program at no performance cost

#14

What’s the difference between a TUI and a CLI? (Also my preferred TUI acronym is tactile user interface).

I would say that a CLI is primarily for entering commands, while a TUI is primarily for viewing and interacting with data.

Re: Show HN: Austin-Tui – Spy inside a running Python program at no performance cost

#16
post #4

Two other profilers that also let you spy on a running Python program: - py-spy: https://github.com/benfred/py-spy (written in Rust) - pyflame: https://github.com/uber-archive/pyflame (C++, seems to be not maintained anymore) The "no performance cost" thing is interesting: my experience writing a similar profiler is that there are a couple of things that can affect performance a little bit: 1. You have to make a lot…

>you're likely to win the race, because C is faster than Python

Heh, so the only reason there's "no performance cost" is the enormous performance cost of using Python in the first place?

Re: Show HN: Austin-Tui – Spy inside a running Python program at no performance cost

#17

What’s the difference between a TUI and a CLI? (Also my preferred TUI acronym is tactile user interface).

If a CLI program ceases to make sense when its standard-output is a physical line-printer onto a roll of paper, then it's a TUI.

Re: Show HN: Austin-Tui – Spy inside a running Python program at no performance cost

#18
post #16
post #4

Two other profilers that also let you spy on a running Python program: - py-spy: https://github.com/benfred/py-spy (written in Rust) - pyflame: https://github.com/uber-archive/pyflame (C++, seems to be not maintained anymore) The "no performance cost" thing is interesting: my experience writing a similar profiler is that there are a couple of things that can affect performance a little bit: 1. You have to make a lot…

>you're likely to win the race, because C is faster than Python Heh, so the only reason there's "no performance cost" is the enormous performance cost of using Python in the first place?

Running Python is not a performance cost. The meaning behind "no performance cost" is that a tool like this is unlikely going to impact the performance of the application that is being profiled. The fact that Python is not a "fast" programming language is then a different matter.

Re: Show HN: Austin-Tui – Spy inside a running Python program at no performance cost

#19

What’s the difference between a TUI and a CLI? (Also my preferred TUI acronym is tactile user interface).

Another example:

https://en.wikipedia.org/wiki/Ed_(text_editor) has a CLI, but

https://en.wikipedia.org/wiki/Vim_(text_editor) has a TUI.

Re: Show HN: Austin-Tui – Spy inside a running Python program at no performance cost

#20

What’s the difference between a TUI and a CLI? (Also my preferred TUI acronym is tactile user interface).

Both use the terminal, but in different ways. A CLI interface uses the basic terminal functionality of writing and perhaps reading lines, or even simply accepting flags and running non-interactively. A TUI uses the terminal's advanced features, using the terminal as the basis for a kind of GUI, generally occupying the full area of the terminal.

Vim, Midnight Commander, and htop have TUIs. They rely heavily on the terminal's 'control character' features to accomplish this. apt-get has a CLI, as its interactive IO is handled with printing lines and having the user submit lines (even if it's just the letter y).

Somewhere in the middle are interfaces like bash and zsh which make light use of the terminal's advanced features for things like auto-complete, but which don't take over the whole terminal area.

I'd count non-interactive applications like gcc and sort as command-line applications, although strictly speaking you could just as well use a graphical interface to configure their flags and run commands.

See also https://en.wikipedia.org/wiki/Text-based_user_interface

Post reply on HN