Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Strange colored output #227

Closed
favonia opened this issue Mar 7, 2022 · 4 comments
Closed

Strange colored output #227

favonia opened this issue Mar 7, 2022 · 4 comments

Comments

@favonia
Copy link
Contributor

favonia commented Mar 7, 2022

With colors being true but long and verbose being false, the output of run_tests_main is somehow strange. Here is the captured output with control characters being escaped (except for line feeds). For some reasons, random was repeated.

^[[2K^Mrandom seed: 356596957^[[0m^M
^[[2K^Mrandom================================================================================^[[0m^M
^[[2K^Mrando;32;1msuccess^[[0m (ran 12 tests)^M

I have tried different shells and terminal emulators, and the behavior seems to be the same.

@c-cube
Copy link
Owner

c-cube commented Mar 7, 2022

I've tried: dune exec example/QCheck_runner_test.exe -- --colors but I don't see any escaped control character. Would you mind providing a more specific repro? :)

@favonia
Copy link
Contributor Author

favonia commented Mar 7, 2022

I discovered that directly running dune exec in my case would have the correct output. However, dune test would screw up the control sequences. The control sequences in the first post were captured by script and then converted so that I can report the issue on GitHub. Because dune exec and dune test seem to differ, it's quite possible that qcheck is actually fine and the bug lies somewhere else.

Anyways, the most reliable reproducible step is to check out https://github.com/RedPRL/yuujinchou/tree/qcheck-bug, install the dependencies, and run dune test -f. I am removing the branch because @jmid made a great minimum working example below.

@jmid
Copy link
Collaborator

jmid commented Mar 7, 2022

I looked at this a bit to create a small repro:

repro/dune:

(test
 (name test)
 (libraries qcheck-core qcheck-core.runner))

repro/test.ml:

let test =
  QCheck2.Test.make ~name:"name" QCheck2.Gen.int (fun _ -> true)

let _ = QCheck_base_runner.run_tests (*~colors:true*)  [test]

With dune exec there is no issue - while dune test (aka dune runtest aka ...) confuses the output:

$ dune exec repro/test.exe -f
random seed: 283984449
================================================================================
success (ran 1 tests)
$ dune runtest repro/ -f
        test alias repro/runtest
random seed: 4234572
random================================================================================
rando;32;1msuccess (ran 1 tests)

The problem goes away if using dune runtest repro/ -f --no-buffer instead.
The idea is that dune runs things in parallel while buffering each task's output. Using --no-buffer writes the output straight to the terminal - with a risk of interleaved/mangled output (unless it is combined with -j 1).
Alternatively you can pass --colors:false to run_test in QCheck to avoid control characters.

This seems to be a known issue with dune: ocaml/dune#3160
There's another description of how dune parses the escape codes here: ocaml/dune#2664 (comment)
The code for implementing the parsing is moved here: https://github.com/ocaml/dune/blob/main/otherlibs/stdune/ansi_color.ml AFAICS it handles only colors - and not the ANSI escape code for "Erase in Line" (clearing a line) that we use for printing the initial "random seed" line:

let reset_line = "\x1b[2K\r"

I'm wondering whether we need to clear the line before the first "random seed" print out?

@jmid
Copy link
Collaborator

jmid commented Nov 7, 2022

Closing as this should be fixed in ocaml/dune#5528 released with dune 3.5.0

@jmid jmid closed this as completed Nov 7, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants