Skip to content

Only read stdout when running with --more-verbose #5

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

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

thomie
Copy link
Contributor

@thomie thomie commented Feb 27, 2025

When not running with -V or --more-verbose, we now pipe the stdout of the executable under test to /dev/null. This prevents quickbench from running out of memory in case the output is huge (GBs).

MINOR REMARK

With my version of GHC (9.6.6), all exceptions unfortunately get annoted withBinaryFile, see https://gitlab.haskell.org/ghc/ghc/-/issues/20886.

For example, when running quickbench -w doesnotexist, the error message is:

/dev/null: withBinaryFile: does not exist (No such file or directory)

When running quickbench -w doesnotexist --more-verbose, avoiding the call to withBinaryFile, the error message is the much clearer:

doesnotexist: readCreateProcess: posix_spawnp: does not exist (No such file or directory)

This is not ideal, but I believe using the latest version of GHC will fix it.

Fixes #4 .

t2 <- getCurrentTime
when (not $ null o) $ outvv opts $ (if verbose opts then "\n" else "") ++ o
unless (c == ExitSuccess) $ out opts $ " (error: " ++ clean e ++ ") "
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Instead of capturing stderr, I now let the child process inherit stderr from the parent process (the default). So any error messages written to stderr by say hledger will be verbatim written to the stderr of quickbench.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The other change is that now, a failure of the childprocess will immediately result in failure of the parent process. I consider this an improvement, because before errors from the child process could get obscured by the normal output table. But perhaps you want to keep the original behavior @simonmichael ?

Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hmm. Should quickbench require that all tested commands succeed ? I think it's better to continue if some fail, because sometimes you're benchmarking many things and partial information is better than none.

I think it would be an improvement if it could show the failed status (or some of the error output, if it's not too disruptive of layout) in the results table though ?

@simonmichael
Copy link
Owner

Let's rebase this and I'll test.

When not running with `-V` or `--more-verbose`, we now pipe the stdout
of the executable under test to /dev/null. This prevents quickbench from
running out of memory in case the output is huge (GBs).

MINOR REMARK

With my version of GHC (9.6.6), all exceptions unfortunately get annoted
`withBinaryFile`, see https://gitlab.haskell.org/ghc/ghc/-/issues/20886.

For example, when running `quickbench -w doesnotexist`, the error
message is:

```
/dev/null: withBinaryFile: does not exist (No such file or directory)
```

When running `quickbench -w doesnotexist --more-verbose`, avoiding the
call to `withBinaryFile`, the error message is the much clearer:

```
doesnotexist: readCreateProcess: posix_spawnp: does not exist (No such file or directory)
```

This is not ideal, but I believe using the latest version of GHC will
fix it.
@thomie thomie force-pushed the do-not-read-stdout branch from 05cbdd2 to 2823eb9 Compare April 6, 2025 14:45
@simonmichael
Copy link
Owner

simonmichael commented Apr 9, 2025

With my version of GHC (9.6.6), all exceptions unfortunately get annoted withBinaryFile

Thanks for noting this. I think we'll ignore it.

I see this change in output (old and new are compiled with newer GHC):

old:

$ quickbench -w nosuchexe echo
Running 1 tests 1 times with 1 executables at 2025-04-09 09:26:36 HST:
 (error: nosuchexe: readCreateProcessWithExitCode: posix_spawnp: does not exist (No such file or directory)) 
Best times:
+-----------++-----------+
|           || nosuchexe |
+===========++===========+
| nosuchexe ||      0.00 |
+-----------++-----------+

new:

$ stack exec -- quickbench -w nosuchexe echo
Running 1 tests 1 times with 1 executables at 2025-04-09 09:26:41 HST:
nosuchexe: createProcess: posix_spawnp: does not exist (No such file or directory)

The new behaviour seems better (reports the command line error once and exits early).

`catch` \(e :: IOException) -> return (ExitFailure 1, "", show e)
callProcessIgnoreOutput :: FilePath -> [String] -> IO ()
callProcessIgnoreOutput cmd args =
withBinaryFile "/dev/null" WriteMode $ \devNull ->
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this is a unixism, unfortunately ? quickbench should be robust on Windows too.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just to be sure: supporting only WSL is not sufficient?

Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, supporting only WSL is not sufficient.

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

Successfully merging this pull request may close these issues.

Out of memory error with executables producing a lot of output
2 participants