ANSI enabled terminal progress bar that implements IRascalMonitor. Thread safe-ish" #1933
Conversation
…fixes a nasty off-by-one error
…ound bar (saves space for the message string) and builtin timers, checkboxes for finished indicators, and always using the full width of terminal
…s imports and extends todos for the importing or extending module. The depending module is only finished when the necessary imported ones are fully loaded. The bar is never completed in case one of the modules fails to an parse error or serious static error. That way people can see what the state is of the system by the state of the progress bars and the printed error messages
…aks the monitor because it is not thread safe yet.
…r solution using a concurrent list implementation
|
This is the same behavior as on Windows. Some of those issues have been fixed now.
It helps the user to know which modules have been (re)loaded and how much time each module took. I've tried merging the bars into one "loading" bar, but that did not work out because I can not find a natural place in the interpreter where the loading job starts and where the job ends. With 20 modules it is actually quite interesting to see what happens: We get the same information as before, when we did not have the bars: a list of loaded modules. However, while they are loading we see them being resolved one by one, and you can also seep dependencies via imports and extends explicitly. Note that extended modules are loaded every time they are being extended, so that bar will keep moving a while, or sometimes come back if it was finished in the meantime. Imported modules make the progress bar of the depending module wait. Every module that finished advances the bar for the dependent module. In principle the top module should always be the last to finish, and therefore it is always the last bar to be printed and it ends up at the bottom with the longest running time. |
See above; printing the bars and printing the normal output are not separate responsibilities; or at least they can not be since we have to synchronize on what is shown in the terminal. Unless this is not true, it would not help to talk about it more. If you really really want to separate this, then we could print the bars to the output with some escaped quotes around them. Then let another wrapper around stdout detect those quotes and move the output to the right place. I tried this, but it generates a lot of flickering and other artefacts due to moving large part of the screen all the time. Also such a solution would mean a deep semantic interaction between the producer and the consumer of the bars, which also needs to be timed correctly, which I'd like even less than the current design where everything that semantically depends is close by. The core essence of why the current design works is the |
|
TODO: pressing |
I think this might be the right time to merge. @DavyLandman thanks for the feedback; I've fixed all issues identified. The general design issue with the two interfaces for one class is something beyond me, or at least this PR. |
Can't we detect the
In VS Code you would see this:
So that's quite a big difference for most users. I know that if you run rascal in some less typical setups, you could see all those prints, but they weren't visible for most users. I do not think people will appreciate that much internal "information".
|
…alues from IRascalMonitor.job to get this working. Minor change since it used to return a boolean, now it can return anything. Should be backward compatible (source, not binary)
|
Thanks for the sugestions Davy. The importer now prints only one bar for the entire loading processes. It's still the same steps. This means it has a bit of a "Zeno" feeling as more work is discovered while more imports are being discovered per module, recursively. But it works and it uses less real estate. There is no more insight into module loading time now, except for the entire process. The bug with the first few bars repeating themselves is back; and there is sometimes this stacktrace: depending on the initial size or cursor position of the terminal that the REPL starts in. strange. |
|
Thanks, that sounds better indeed 👍🏽
Maybe there is a race, where the terminal is still getting initialized? Also, for comparison, this is what we have to do in VS Code to detect the encoding & fix a windows issue: |
…ed more of jline builtin features for encodig checking
… solves this annoying shifting of the screen after a few seconds into the Rascal REPL
…g printed under mvn test runs
…ccidental empty line
…g monitor with it
…curred at startup. Apparantly scrolling down 0 lines, means scrolling down 1 line in ANSI
This PR introduces TerminalProgressBarMonitor, an implementation of IRascalMonitor that uses ANSI codes
to position a list of active progress bar in the terminal. It leads the other output around the bars by filtering the
standard output stream.
This PR also contains changes to all the uses of IRascalMonitor in the interpreter and the JUnit integrations, such that we don't see too many bars on the screen at the same time, and also not too few, and the bars show meaningful progress.
If the terminal is interactive, then the TerminalProgressBarMonitor is always used. Otherwise the interpreter and the test runners default to the normal RascalConsoleMonitor. Pretty unicode characters are used if the terminal can print them, otherwise we stick with ASCII.
The time between every jobStart and jobEnd is measured and printed to the right of the progress bar. Also every bar shows the time spent since the start, after every jobStep.