Opened 5 years ago

Last modified 5 months ago

#7298 new bug

GHCi is setting stdin/stdout to NoBuffering in runghc when DYNAMIC_GHC_PROGRAMS=YES

Reported by: igloo Owned by:
Priority: high Milestone:
Component: GHCi Version: 7.6.1
Keywords: Cc:
Operating System: Unknown/Multiple Architecture: Unknown/Multiple
Type of failure: None/Unknown Test Case: ghc-e/should_run/T2228
Blocked By: Blocking:
Related Tickets: #2228 Differential Rev(s):
Wiki Page:

Description

=====> 2228(normal) 6 of 8 [0, 0, 0]
cd . && $MAKE --no-print-directory -s 2228    </dev/null >2228.run.stdout 2>2228.run.stderr
Actual stdout output differs from expected:
--- ./2228.stdout       2011-07-21 12:03:54.000000000 +0100
+++ ./2228.run.stdout   2012-10-05 02:07:04.000000000 +0100
@@ -1,2 +1,2 @@
 BlockBuffering Nothing
-BlockBuffering Nothing
+NoBuffering
*** unexpected failure for 2228(normal)

Change History (9)

comment:1 Changed 4 years ago by igloo

Owner: igloo deleted

comment:2 Changed 3 years ago by thoughtpolice

Milestone: 7.8.37.8.4

Moving to 7.8.4.

comment:3 Changed 3 years ago by thoughtpolice

Milestone: 7.8.47.10.1

Moving (in bulk) to 7.10.4

comment:4 Changed 2 years ago by thoughtpolice

Cc: hvr added
Resolution: wontfix
Status: newclosed

Closing, since we're moving away from dynamic by default anyway.

comment:5 Changed 2 years ago by thoughtpolice

Milestone: 7.10.1

comment:6 Changed 20 months ago by thomie

Cc: hvr removed
Resolution: wontfix
Status: closednew
Summary: Test 2228 fails with dynamic-by-defaultGHCi is setting stdin/stdout to NoBuffering in runghc when DYNAMIC_GHC_PROGRAMS=YES
Test Case: ghc-e/should_run/T2228

This issue is not fixed. According to ticket:2228#6, runghc shouldn't set stdin/stdout to NoBuffering.

comment:7 Changed 18 months ago by bgamari

Milestone: 8.2.1

While it's a bit late to handle this for 8.0 let's at least try for 8.2.

comment:8 Changed 11 months ago by thomie

comment:9 Changed 5 months ago by bgamari

Milestone: 8.2.1

This is still not fixed, it seems like no one is terribly eager to see it fixed, and the fix won't be terrible simple. Consequently I'm going to un-milestone this.

Note: See TracTickets for help on using tickets.