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

stack bench truncates final output on a slow terminal #413

Closed
simonmichael opened this Issue Jun 25, 2015 · 16 comments

Comments

Projects
None yet
4 participants
@simonmichael
Contributor

simonmichael commented Jun 25, 2015

If a benchmark executable prints much output, in a slow terminal (such as an emacs shell buffer) "stack bench" truncates it.

@snoyberg

This comment has been minimized.

Contributor

snoyberg commented Jun 25, 2015

Do you have a repo for this? stack bench just calls runghc Setup.hs bench under the surface, which I thought sent all of the output to a log file.

@simonmichael

This comment has been minimized.

Contributor

simonmichael commented Jun 25, 2015

Hey Michael, https://github.com/simonmichael/hledger/ master should show the problem now if you uncomment hledger/bench/bench.hs line 30 or 31 and run stack bench hledger in an emacs shell buffer (M-x shell in emacs). You can see the full non-truncated output eg with:

(cd hledger; stack exec -- ghc -ibench bench/bench && stack exec -- bench/bench --simplebench)`
@snoyberg

This comment has been minimized.

Contributor

snoyberg commented Jun 26, 2015

I didn't realize that Cabal's bench output went to the terminal, interesting.

@snoyberg

This comment has been minimized.

Contributor

snoyberg commented Jun 26, 2015

Since we're just reusing Cabal's run code here, can you tell me if the same problem appears when you would run cabal bench?

@simonmichael

This comment has been minimized.

Contributor

simonmichael commented Jun 26, 2015

I don't see the problem when running cabal bench myself.

@snoyberg

This comment has been minimized.

Contributor

snoyberg commented Jun 26, 2015

@chrisdone Do you have any thoughts on this?

@snoyberg snoyberg added this to the 0.2.0.0 milestone Jun 26, 2015

@snoyberg

This comment has been minimized.

Contributor

snoyberg commented Jun 26, 2015

I just merged a PR that changes the buffering of stdout, I'm not sure if that will have any impact. For the record, I've been unable to repro so far.

@simonmichael

This comment has been minimized.

Contributor

simonmichael commented Jun 26, 2015

Today's stack (revision 2cac22d) has the same problem here, FWIW.

I think maybe Stack.Build.Execute.printBuildOutput should hold on to the printing thread's id, so that the main thread can wait for it to finish before exiting ?

@simonmichael

This comment has been minimized.

Contributor

simonmichael commented Jun 26, 2015

PS awkward that you can't reproduce. To be more specific, I see this in a shell buffer in GNU Emacs 25.0.50.1 running in the normal GUI mode on OSX Yosemite on a 2013 macbook air.

@radix

This comment has been minimized.

Contributor

radix commented Jun 26, 2015

Emacs for OS X has really slow buffer drawing compared to Linux, so it may be difficult to repro on Linux vs Mac.

@snoyberg snoyberg modified the milestones: 0.3.0.0, 0.2.0.0 Jul 2, 2015

@snoyberg

This comment has been minimized.

Contributor

snoyberg commented Aug 23, 2015

Can you think of any other way to reproduce this problem? As it stands right now, I don't think anyone else can attempt to fix this.

@simonmichael

This comment has been minimized.

Contributor

simonmichael commented Aug 23, 2015

Have you tried it in an emacs shell on a mac ?

@snoyberg

This comment has been minimized.

Contributor

snoyberg commented Aug 23, 2015

No, I don't have access to a Mac.

On Sun, Aug 23, 2015, 9:16 PM Simon Michael notifications@github.com
wrote:

Have you tried it in an emacs shell on a mac ?


Reply to this email directly or view it on GitHub
#413 (comment)
.

@borsboom

This comment has been minimized.

Contributor

borsboom commented Aug 23, 2015

I was able to reproduce this on my Mac:

screen shot 2015-08-23 at 12 20 33 pm

(a bunch more output appears when I run the same command in a regular terminal)

I'm also running into something possibly related on Windows, where GHC's output is cut off. I'm on Windows 10 in a VirtualBox VM and running stack in the "Git Bash" shell (from msysgit), which has incredibly slow output (seriously, it's almost like being on a dial-up modem).

borsboom added a commit that referenced this issue Aug 24, 2015

@borsboom

This comment has been minimized.

Contributor

borsboom commented Aug 24, 2015

I've pushed a change that fixes this for my case and also the similar problem I saw in Windows. @simonmichael, please re-open if this doesn't work for you (your suggestion of waiting for the printBuildOutput threads to finish was indeed the fix).

@simonmichael

This comment has been minimized.

Contributor

simonmichael commented Aug 25, 2015

Hurrah! Thank you.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment