Compact submission/testcase overview

[mzuenni]

I would like to add a compact overview of all submission/testcases to the bt run command (similar to what domjudge displays). It could look something like this: Right now it first prints all testcases with an id and then displays a table with the verdicts. (A for AC, T for TLE, R for RTE and W for WA)

some thoughts about this

• less terminal pollution than -v but also less information
• the table could need some more tweaking (split samples and secret testcases, make the mapping from column to testcase clearer)

what do other think about this?

[RagnarGrootKoerkamp]

@mpsijm @ludopulles wdyt?

I don't like the printing of the list of testcases so much. Could also do that separately in bt list-testcases or so.

I'd like it a lot if the table was rendered incrementally.

What if the number of testcases is larger than terminal width?

Numbering should continue from sample to secret, but could have a column of | in between.

I'd prefer not adding another flag (beyond default and -v output). I don't think this should be the default (which is currently to only print unexpected results), so we could add it to -v output, but that sounds a bit too much. So not sure really.

When would you like this output over the current default?

[mpsijm]

Since the total number of test cases can become quite large, I don't think this should be the default. I think having --table flag for the run command is fine, because the behaviour of the command doesn't change, only the presentation. Additionally, printing the full list of test cases every time sounds like a bit much, so adding an extra command or flag to do that sounds good.

Other than that, I agree with @RagnarGrootKoerkamp :slightly_smiling_face:

[mzuenni]

rendering incrementally sounds nice. If the number of testcases is too large continuing in the next line with the same amount of whitespace to the left would be nice but I don't know if that can be done? (maybe just limit the width of the table?)

Without the testcases the numbering could be removed completely I guess? (would be hard to find the testcase in any way...)

I would like this as a quick overview. additionally adding some columns like AC|TLE|R|WA where the number of WA etc. testcases is counted could be nice.

I personally would not like to overwrite the --table option with this since that option also displays more/other informations

[ludopulles]

For rendering it seems like the current bt run --table works most likely. I think adding the verdict {A,T,R,W} with same green/red coloring is a nice way to add more info to the table. May I ask what the added benefit is for transposing the table? I think this --table option is already rarely used, so perhaps adding a --transpose flag to it might be a bit too much.

[mzuenni]

For me the transposed table would fit better on screen (especially if the row wrappes like described above) and I am using the table for different purposes i.e. I don't want to find a specific testcase but want to quickly see if the submissions fail on specific/multiple testcases. Therefore the transposed table feels more natural. Also note that the current --table command discards some rows since it has a different purpose

Adding the ATRW to the current --table would also be nice I guess.

[mzuenni]

I implemented an example how the table could look like: https://github.com/mzuenni/BAPCtools/tree/overview

• If --no-bar is provided no incremental updates are done only the final table is drawn
• If --table is provided only the incremental updates are drawn (and the other table at the end)
• Else right now the table is always drown but I would prefer to make this optional with a flag

[RagnarGrootKoerkamp]

@mzuenni could you make a PR for this?

[mzuenni]

Yes, but right now it is always printed, we probably only draw this if a flag is passed?

[RagnarGrootKoerkamp]

hmm; it's reasonable to print it by default I think, and maybe disable it with a flag when you don't like it / the terminal doesn't support it.

[mzuenni]

It already respects --no-bar. Not sure about making it default (even though I always use it myself...). But still, there are things like "print this at most once per 0.1sec" or something like that, and i am not sure how to add this ^^'

[RagnarGrootKoerkamp]

Do we need rate limiting? It would be a bit annoying to implement is nicely indeed.

On Sat, 10 Dec 2022, 14:41 mzuenni, @.***> wrote:

It already respects --no-bar. Not sure about making it default (even though I always use it myself...). But still, there are things like "print this at most once per 0.1sec" or something like that, and i am not sure how to add this ^^'

— Reply to this email directly, view it on GitHub https://github.com/RagnarGrootKoerkamp/BAPCtools/issues/195#issuecomment-1345267608, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABPR4UQKQW5RLTDKXZH5A6DWMSCBXANCNFSM5QZE5VMA . You are receiving this because you were mentioned.Message ID: @.***>