[GHC] #2189: hSetBuffer stdin NoBuffering doesn't seem to work in ghc 6.8.2 on Windows XP

[GHC]

#2189: hSetBuffer stdin NoBuffering doesn't seem to work in ghc 6.8.2 on Windows
XP
---+
Reporter:  FalconNL|   Owner: 
Type:  bug |  Status:  new
Priority:  normal  |   Component:  GHCi   
 Version:  6.8.2   |Severity:  normal 
Keywords:  hsetbuffering buffering buffer  |Testcase: 
Architecture:  x86 |  Os:  Windows
---+
 The following program repeats inputted characters until the escape key is
 pressed.


 {{{
 import IO
 import Monad
 import Char

 main :: IO ()
 main = do hSetBuffering stdin NoBuffering
   inputLoop

 inputLoop :: IO ()
 inputLoop = do i <- getContents
mapM_ putChar $ takeWhile ((/= 27) . ord) i
 }}}


 Because of the "hSetBuffering stdin NoBuffering" line it should not be
 necessary to press the enter key between keystrokes. This program works
 correctly in WinHugs (sep 2006 version). However, GHC 6.8.2 does not
 repeat the characters until the enter key is pressed. The problem was
 reproduced with all GHC executables (ghci, ghc, runghc, runhaskell), using
 both cmd.exe and command.com on Windows XP Professional.

-- 
Ticket URL: 
GHC 
The Glasgow Haskell Compiler___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs

Re: [GHC] #2187: Top-level bindings are broken for polymorphic values

[GHC]

#2187: Top-level bindings are broken for polymorphic values
--+-
 Reporter:  yallop|  Owner: 
 Type:  bug   | Status:  new
 Priority:  normal|  Milestone:  6.10 branch
Component:  Compiler  |Version:  6.8.2  
 Severity:  major | Resolution: 
 Keywords:| Difficulty:  Unknown
 Testcase:|   Architecture:  Unknown
   Os:  Unknown   |  
--+-
Comment (by simonmar):

 Linking to the Haskell' page with the motivation for this change:
 [http://hackage.haskell.org/cgi-bin/haskell-
 prime/trac.cgi/wiki/MonomorphicPatternBindings]

 As for whether it makes the implementation simpler, I presume the
 intention was to deprecate and eventually remove `-XNoMonoPatBinds` at
 which point the complexities to deal with polymorphic pattern bindings
 would go away. (however we can't do that while we still want to support
 Haskell 98, of course).  I'm going to follow up on this with the Haskell'
 committee.

-- 
Ticket URL: 
GHC 
The Glasgow Haskell Compiler___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs

Re: [GHC] #1673: Template Haskell support for type families

[GHC]

#1673: Template Haskell support for type families
+---
 Reporter:  [EMAIL PROTECTED]  |  Owner: 
 Type:  feature request | Status:  new
 Priority:  low |  Milestone:  6.10 branch
Component:  Template Haskell|Version:  6.7
 Severity:  normal  | Resolution: 
 Keywords:  | Difficulty:  Unknown
 Testcase:  |   Architecture:  x86
   Os:  Linux   |  
+---
Changes (by ganesh):

 * cc: [EMAIL PROTECTED] (added)

-- 
Ticket URL: 
GHC 
The Glasgow Haskell Compiler___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs

Re: [GHC] #1148: Bad warnings about unused imports that are in fact needed

[GHC]

#1148: Bad warnings about unused imports that are in fact needed
---+
 Reporter:  brianh |  Owner: 
 Type:  bug| Status:  new
 Priority:  lowest |  Milestone:  _|_
Component:  Compiler   |Version:  6.8.2  
 Severity:  trivial| Resolution: 
 Keywords:  warning unused import  | Difficulty:  Unknown
 Testcase: |   Architecture:  x86
   Os:  Windows|  
---+
Comment (by Eelis-):

 Hm, I'm confused. Maybe my testcase was bad, because it might've suggested
 that the warning was simply a consequence of b being unused. Here's a
 better testcase:
 {{{
   import List
   import Prelude

   main = do
 l <- getLine
 print $ List.null l
 }}}
 Here there can be absolutely no doubt that List.null is used, yet still
 GHC warns that nothing from List is used. Furthermore, the warning goes
 away if the "import Prelude" line is removed or if the two import lines
 are reversed. It seems to me that this can only be considered a genuine
 bug, not a reasonable consequence of any particular design choice.

-- 
Ticket URL: 
GHC 
The Glasgow Haskell Compiler___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs

Re: [GHC] #2168: ghci should show haddock comments for identifier

[GHC]

#2168: ghci should show haddock comments for identifier
-+--
 Reporter:  j.waldmann   |  Owner: 
 Type:  feature request  | Status:  new
 Priority:  normal   |  Milestone:  6.10 branch
Component:  GHCi |Version:  6.8.2  
 Severity:  normal   | Resolution: 
 Keywords:   | Difficulty:  Unknown
 Testcase:   |   Architecture:  Unknown
   Os:  Unknown  |  
-+--
Comment (by simonmar):

 The documentation is stored in the Haddock interface file now, and Haddock
 has a library that provides access to the .haddock files.  So it seems to
 me the right way to go is for GHCi to invoke the Haddock library to get
 the docs.  Unfortunately this needs some restructuring: the Haddock
 library would become a boot package.

-- 
Ticket URL: 
GHC 
The Glasgow Haskell Compiler___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs

Re: [GHC] #2180: Any installed signal handler stops deadlock detection, but XCPU never happens in a deadlock

[GHC]

#2180: Any installed signal handler stops deadlock detection, but XCPU never
happens in a deadlock
-+--
 Reporter:  Baughn   |  Owner:  Baughn 
 Type:  feature request  | Status:  assigned   
 Priority:  normal   |  Milestone:  6.10 branch
Component:  Runtime System   |Version:  6.9
 Severity:  minor| Resolution: 
 Keywords:   | Difficulty:  Unknown
 Testcase:   |   Architecture:  Unknown
   Os:  Multiple |  
-+--
Comment (by simonmar):

 I think this needs to be under programmer control if we do it at all.

 Also, the patch doesn't affect the behaviour of the threaded RTS, we
 should make sure the two behave consistently.

-- 
Ticket URL: 
GHC 
The Glasgow Haskell Compiler___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs

Re: [GHC] #2185: Memory leak with parMap

[GHC]

#2185: Memory leak with parMap
--+-
 Reporter:  igloo |  Owner:  simonmar   
 Type:  run-time performance bug  | Status:  new
 Priority:  normal|  Milestone:  6.10 branch
Component:  Compiler  |Version:  6.8.2  
 Severity:  normal| Resolution: 
 Keywords:| Difficulty:  Unknown
 Testcase:|   Architecture:  Unknown
   Os:  Unknown   |  
--+-
Changes (by simonmar):

  * owner:  => simonmar
  * milestone:  6.8.3 => 6.10 branch

Comment:

 I think sparks are currently treated as roots by the GC, which is wrong.
 I won't get around to fixing this in 6.8.3, but I'll do it in the new GC
 code in 6.10.

-- 
Ticket URL: 
GHC 
The Glasgow Haskell Compiler___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs

Re: [GHC] #1148: Bad warnings about unused imports that are in fact needed

[GHC]

#1148: Bad warnings about unused imports that are in fact needed
---+
 Reporter:  brianh |  Owner: 
 Type:  bug| Status:  new
 Priority:  lowest |  Milestone:  _|_
Component:  Compiler   |Version:  6.8.2  
 Severity:  trivial| Resolution: 
 Keywords:  warning unused import  | Difficulty:  Unknown
 Testcase: |   Architecture:  x86
   Os:  Windows|  
---+
Comment (by simonmar):

 I like the current behaviour.  GHC used to have the former behaviour, and
 there were complaints that we didn't detect unused cycles.

 (I presume the original bug about reporting unused qualified names still
 stands, though).

-- 
Ticket URL: 
GHC 
The Glasgow Haskell Compiler___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs

Re: [GHC] #1475: Adding imports and exports with Template Haskell

[GHC]

#1475: Adding imports and exports with Template Haskell
--+-
 Reporter:  igloo |  Owner: 
 Type:  feature request   | Status:  new
 Priority:  normal|  Milestone:  _|_
Component:  Template Haskell  |Version:  6.8.2  
 Severity:  normal| Resolution: 
 Keywords:| Difficulty:  Unknown
 Testcase:|   Architecture:  Unknown
   Os:  Unknown   |  
--+-
Changes (by m4dc4p):

  * version:  6.6.1 => 6.8.2

Comment:

 I would love for template haskell to be able to add imports. I am using
 haskelldb to write strongly-typed SQL queries. These queries depend on a
 compile time representation of the database schema. That representation is
 obtained by running a program which produces Haskell source describing a
 given set of tables, etc. If TH could write import statements, I could
 dynamically generated my modules and then import them in one go. My
 queries would always be compiled against the most recent schema! It would
 be a great feature to have.

-- 
Ticket URL: 
GHC 
The Glasgow Haskell Compiler___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs

Re: [GHC] #838: GHC binary for FreeBSD/amd64

[GHC]

#838: GHC binary for FreeBSD/amd64
-+--
 Reporter:  alter|  Owner:  igloo 
 Type:  feature request  | Status:  new   
 Priority:  normal   |  Milestone:  6.8 branch
Component:  Compiler |Version:  6.4.2 
 Severity:  normal   | Resolution:
 Keywords:   | Difficulty:  Unknown   
 Testcase:  N/A  |   Architecture:  x86_64 (amd64)
   Os:  FreeBSD  |  
-+--
Comment (by guest):

 We have a bootstrap tarball for the FreeBSD port at
 http://www.freshports.org/lang/ghc. There was some problem with darcs, but
 we'd have to ask Olli about it since I couldn't keep track of AMD64 things
 (he's on the [EMAIL PROTECTED], so we should here from him soon)..I'm not
 sure this was related to only FreeBSD 7.

 Volker

-- 
Ticket URL: 
GHC 
The Glasgow Haskell Compiler___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs

Re: [GHC] #838: GHC binary for FreeBSD/amd64

[GHC]

#838: GHC binary for FreeBSD/amd64
-+--
 Reporter:  alter|  Owner:  igloo 
 Type:  feature request  | Status:  new   
 Priority:  normal   |  Milestone:  6.8 branch
Component:  Compiler |Version:  6.4.2 
 Severity:  normal   | Resolution:
 Keywords:   | Difficulty:  Unknown   
 Testcase:  N/A  |   Architecture:  x86_64 (amd64)
   Os:  FreeBSD  |  
-+--
Comment (by cce):

 I'm wondering if this has had any progress.  What needs to be done?  It
 seems that we lack a bootstrap file, what is this?  Can you cross-compile
 a bootstrap from another architecture?
 Anyway, having ghc running on 64 bits would be very nice -- I'm unable to
 run xmonad on my system
 without this compiled on amd64 arch.  Thank you kindly for any help you
 may provide.

-- 
Ticket URL: 
GHC 
The Glasgow Haskell Compiler___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs

Re: [GHC] #2187: Top-level bindings are broken for polymorphic values

[GHC]

#2187: Top-level bindings are broken for polymorphic values
--+-
 Reporter:  yallop|  Owner: 
 Type:  bug   | Status:  new
 Priority:  normal|  Milestone:  6.10 branch
Component:  Compiler  |Version:  6.8.2  
 Severity:  major | Resolution: 
 Keywords:| Difficulty:  Unknown
 Testcase:|   Architecture:  Unknown
   Os:  Unknown   |  
--+-
Comment (by yallop):

 Thanks for the reply.  Yes, I ran into the problem in a real program.

 I have code that looks like this:
 {{{
(x1,...,xn) = (e1,...en)
   where y = e
 z = f
 }}}

 which is generated via Template Haskell.  Sometimes the bindings are
 supposed to be polymorphic, sometimes not.

 It looks like I have two choices, neither of which is particularly
 desirable:

1. Change the generation scheme to emit less elegant code, which will
 also
   complicate the generation code.
2. Require all users of the library to add -XNoMonoPatBinds

 From a user's perspective (at least, from this user's), defaulting to
 monomorphic pattern bindings looks like quite an unfortunate choice:

1. It doesn't bring any actual benefits to the user (that I can see).
2. It breaks compatibility with Haskell 98, so code that works on other
 implementations mysteriously fails without so much as a warning.
3. It generates quite unusable code: there's no realistic use for
 functions of type
 {{{
 GHC.Prim.Any -> GHC.Prim.Any
 }}}
   so why default to generating that sort of thing?
4. It makes it more difficult to transform programs, since you can no
 longer replace
 {{{
x = f (a,b)
 }}}
   with
 {{{
(c,d) = (a,b)
f (c,d)
 }}}

 It's difficult to see how it can simplify the implementation, since you
 still have to cope with -XNoMonoPatBinds.  There must be *some* reason for
 this change, but what can it be?

-- 
Ticket URL: 
GHC 
The Glasgow Haskell Compiler___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs