Re: [GHC] #1936: When lazy IO blocks, it blocks the whole runtime

[GHC]

#1936: When lazy IO blocks, it blocks the whole runtime
--+-
 Reporter:  guest |  Owner:  
 Type:  bug   | Status:  new 
 Priority:  normal|  Milestone:  6.8.3   
Component:  None  |Version:  6.8.1   
 Severity:  normal| Resolution:  
 Keywords:  lazy IO getContents blocking  | Difficulty:  Unknown 
 Testcase:|   Architecture:  Multiple
   Os:  Linux |  
--+-
Changes (by igloo):

  * milestone:  => 6.8.3

Comment:

 I have a vague memory that something similar was caused by one function
 (here getContents) taking a lock on a Handle (I think stdin and stdout
 might be a single handle for this purpose), so another function (here
 putStrLn) can't get a lock on it. Might be worth searching out the old bug
 report (not sure if it would be closed or not, and it's possible it was
 only a list discussion or something).

-- 
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] #1937: Configure script fails on target ia64 machine when trying to cross-compile ghc-6.8.1

[GHC]

#1937: Configure script fails on target ia64 machine when trying to 
cross-compile
ghc-6.8.1
--+-
 Reporter:  ylitus|  Owner:   
 Type:  bug   | Status:  closed   
 Priority:  normal|  Milestone:   
Component:  Compiler  |Version:  6.8.1
 Severity:  normal| Resolution:  duplicate
 Keywords:| Difficulty:  Unknown  
 Testcase:|   Architecture:  Unknown  
   Os:  Unknown   |  
--+-
Changes (by igloo):

  * status:  new => closed
  * difficulty:  => Unknown
  * resolution:  => duplicate

Comment:

 The bootstrapping procedure hasn't been updated for 6.8 yet. #1346 is the
 bug for that.

 Regardless, the easiest way to bootstrap is to take the 6.6.1 binaries
 from another Linux distro, such as Debian or Gentoo. You will have to
 tweak the paths by hand (assuming you don't want to unpack them in /usr).

-- 
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] #1954: Incorrect "Defined but not used" warning when using GeneralizedNewtypeDeriving

[GHC]

#1954: Incorrect "Defined but not used" warning when using
GeneralizedNewtypeDeriving
--+-
 Reporter:  magnus|  Owner:
 Type:  bug   | Status:  new   
 Priority:  normal|  Milestone:  6.8 branch
Component:  Compiler  |Version:  6.8.1 
 Severity:  normal| Resolution:
 Keywords:| Difficulty:  Unknown   
 Testcase:|   Architecture:  Unknown   
   Os:  Unknown   |  
--+-
Changes (by igloo):

  * milestone:  => 6.8 branch

Comment:

 Thanks for the report

-- 
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] #1955: Heap profiling on Windows doesn't work

[GHC]

#1955: Heap profiling on Windows doesn't work
+---
 Reporter:  NeilMitchell|  Owner: 
 Type:  bug | Status:  new
 Priority:  normal  |  Milestone:  6.8.3  
Component:  Runtime System  |Version:  6.8.1  
 Severity:  normal  | Resolution: 
 Keywords:  | Difficulty:  Unknown
 Testcase:  |   Architecture:  Unknown
   Os:  Windows |  
+---
Changes (by igloo):

  * milestone:  => 6.8.3

Comment:

 Thanks for the report; should be easy to fix, so let's do it for 6.8.3.

-- 
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] #1944: round function causes cblas NaNs

[GHC]

#1944: round function causes cblas NaNs
---+
 Reporter:  SevenThunders  |  Owner: 
 Type:  bug| Status:  new
 Priority:  normal |  Milestone:  6.8.2  
Component:  Compiler   |Version:  6.8.1  
 Severity:  critical   | Resolution: 
 Keywords: | Difficulty:  Unknown
 Testcase: |   Architecture:  x86
   Os:  Windows|  
---+
Comment (by SevenThunders):

 I downloaded 6.8.2 and tried it with my current test case and atlas binary
 and the bug still persists.  I recompiled my test case on an intel core
 duo 32 bit windows xp machine.  I guess you better set the solution
 milestone further out than 6.8.2

-- 
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] #1970: ghci -hide-all-packages gives bad error message

[GHC]

#1970: ghci -hide-all-packages gives bad error message
-+--
 Reporter:  dfranke  |  Owner:
 Type:  bug  | Status:  new   
 Priority:  normal   |  Milestone:  6.8 branch
Component:  GHCi |Version:  6.8.1 
 Severity:  trivial  | Resolution:
 Keywords:   | Difficulty:  Unknown   
 Testcase:   |   Architecture:  x86_64 (amd64)
   Os:  Linux|  
-+--
Comment (by igloo):

 See also #1956

-- 
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] #1956: panic on runhaskell Setup configure on base

[GHC]

#1956: panic on runhaskell Setup configure on base
--+-
 Reporter:  NeilMitchell  |  Owner:
 Type:  bug   | Status:  new   
 Priority:  normal|  Milestone:  6.8 branch
Component:  Compiler  |Version:  6.8.1 
 Severity:  normal| Resolution:
 Keywords:| Difficulty:  Unknown   
 Testcase:|   Architecture:  Unknown   
   Os:  Windows   |  
--+-
Changes (by igloo):

  * milestone:  => 6.8 branch

Comment:

 See also #1970

-- 
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] #1973: non-exhaustive pattern in getSRTInfo

[GHC]

#1973: non-exhaustive pattern in getSRTInfo
--+-
 Reporter:  darinm|  Owner: 
 Type:  bug   | Status:  new
 Priority:  normal|  Milestone:  6.8.3  
Component:  Compiler  |Version:  6.8.1  
 Severity:  normal| Resolution: 
 Keywords:| Difficulty:  Unknown
 Testcase:|   Architecture:  Unknown
   Os:  MacOS X   |  
--+-
Comment (by darinm):

 Replying to [comment:1 simonpj]:
 > I think you need to call `SimplStg.stg2stg` first.  It transforms
 `SRTEntries` to the other forms, using `SRT.computeSRTs`.  Does that help?
 >
 > Simon

 Yes, thanks, that does seem to get things further along.  I'm getting
 another panic now at the Cmm stage though.  I'll try to post more details
 on this.  It looks like there's a bug in the way I'm generating core (core
 linting fails) that I need to try fixing first since that might be
 contributing to the cmm issue.

-- 
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] #1958: collect2: ld terminated with signal 10 [Bus error]: Building parsec on a PPC Mac OS X 10.5 Leopard as part of GHC 6.9

[GHC]

#1958: collect2: ld terminated with signal 10 [Bus error]: Building parsec on a
PPC Mac OS X 10.5 Leopard as part of GHC 6.9
-+--
 Reporter:  thorkilnaur  |  Owner: 
 Type:  bug  | Status:  new
 Priority:  normal   |  Milestone:  6.8.3  
Component:  Compiler |Version:  6.9
 Severity:  normal   | Resolution: 
 Keywords:   | Difficulty:  Unknown
 Testcase:   |   Architecture:  powerpc
   Os:  MacOS X  |  
-+--
Changes (by igloo):

  * milestone:  => 6.8.3

-- 
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] #1980: sporadic segmentation faults

[GHC]

#1980: sporadic segmentation faults
+---
 Reporter:  maeder  |  Owner:  simonmar
 Type:  bug | Status:  new 
 Priority:  normal  |  Milestone:  6.8.3   
Component:  Runtime System  |Version:  6.8.2   
 Severity:  normal  | Resolution:  
 Keywords:  | Difficulty:  Unknown 
 Testcase:  |   Architecture:  x86 
   Os:  Linux   |  
+---
Comment (by maeder):

 With `-threaded` it also seg-faults. I've attached a new log2 (after
 recompiling with -debug) for our example attached in
 http://trac.informatik.uni-bremen.de:8080/hets/ticket/448. (It crashed
 after the second prove attempt.)

-- 
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] #1970: ghci -hide-all-packages gives bad error message

[GHC]

#1970: ghci -hide-all-packages gives bad error message
-+--
 Reporter:  dfranke  |  Owner:
 Type:  bug  | Status:  new   
 Priority:  normal   |  Milestone:  6.8 branch
Component:  GHCi |Version:  6.8.1 
 Severity:  trivial  | Resolution:
 Keywords:   | Difficulty:  Unknown   
 Testcase:   |   Architecture:  x86_64 (amd64)
   Os:  Linux|  
-+--
Changes (by igloo):

  * milestone:  => 6.8 branch

-- 
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] #1980: sporadic segmentation faults

[GHC]

#1980: sporadic segmentation faults
+---
 Reporter:  maeder  |  Owner:  simonmar
 Type:  bug | Status:  new 
 Priority:  normal  |  Milestone:  6.8.3   
Component:  Runtime System  |Version:  6.8.2   
 Severity:  normal  | Resolution:  
 Keywords:  | Difficulty:  Unknown 
 Testcase:  |   Architecture:  x86 
   Os:  Linux   |  
+---
Comment (by maeder):

 We do not use `-threaded`, should we? But `libpthread` is linked in. I've
 attached the old log of my `-debug` run.

 Trying your flags (compiled without -debug) crashed with `Floating point
 exception` (never seen before):
 {{{
 [EMAIL PROTECTED]:~/Hets-lib> hets -g Triv.casl +RTS -V0 -C0
 Analyzing library Triv
 Analyzing spec s
 Floating point exception
 }}}

-- 
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] #1980: sporadic segmentation faults

[GHC]

#1980: sporadic segmentation faults
+---
 Reporter:  maeder  |  Owner:  simonmar
 Type:  bug | Status:  new 
 Priority:  normal  |  Milestone:  6.8.3   
Component:  Runtime System  |Version:  6.8.2   
 Severity:  normal  | Resolution:  
 Keywords:  | Difficulty:  Unknown 
 Testcase:  |   Architecture:  x86 
   Os:  Linux   |  
+---
Changes (by simonmar):

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

Comment:

 The backtraces do look suspicious: asynchronous-exception related, by the
 looks of it.

 Are you using `-threaded`?

 You can try to get a more repeatable run by disabling the context switch
 timer: `+RTS -V0 -C0`.

 If you can produce the complete output from `+RTS -Ds`, I might be able to
 figure out what the problem is.

-- 
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] #1979: Add variants of tails and inits not returning empty lists

[GHC]

#1979: Add variants of tails and inits not returning empty lists
+---
 Reporter:  mux |  Owner: 
 Type:  proposal| Status:  new
 Priority:  normal  |  Milestone:  Not GHC
Component:  libraries/base  |Version:  6.8.1  
 Severity:  normal  | Resolution: 
 Keywords:  | Difficulty:  Unknown
 Testcase:  |   Architecture:  Unknown
   Os:  Unknown |  
+---
Changes (by mux):

  * milestone:  6.8.3 => Not GHC

-- 
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] #1971: unjustified warning about documentation

[GHC]

#1971: unjustified warning about documentation
--+-
 Reporter:  maeder|  Owner:  
 Type:  bug   | Status:  new 
 Priority:  normal|  Milestone:  6.8.3   
Component:  Build System  |Version:  6.8.1   
 Severity:  normal| Resolution:  
 Keywords:| Difficulty:  Unknown 
 Testcase:|   Architecture:  Multiple
   Os:  Multiple  |  
--+-
Changes (by igloo):

  * milestone:  => 6.8.3

Comment:

 Thanks for the report. This should be easy to fix for 6.8.3.

-- 
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] #1973: non-exhaustive pattern in getSRTInfo

[GHC]

#1973: non-exhaustive pattern in getSRTInfo
--+-
 Reporter:  darinm|  Owner: 
 Type:  bug   | Status:  new
 Priority:  normal|  Milestone:  6.8.3  
Component:  Compiler  |Version:  6.8.1  
 Severity:  normal| Resolution: 
 Keywords:| Difficulty:  Unknown
 Testcase:|   Architecture:  Unknown
   Os:  MacOS X   |  
--+-
Changes (by igloo):

  * milestone:  => 6.8.3

Comment:

 It sounds like that unhandled case could give a panic making that
 suggestion?

 Better still would be to have more precise types, of course.

-- 
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

[GHC] #1980: sporadic segmentation faults

[GHC]

#1980: sporadic segmentation faults
---+
Reporter:  maeder  |   Owner:   
Type:  bug |  Status:  new  
Priority:  normal  |   Milestone:   
   Component:  Runtime System  | Version:  6.8.2
Severity:  normal  |Keywords:   
  Difficulty:  Unknown |Testcase:   
Architecture:  x86 |  Os:  Linux
---+
 Our big interactive hets application sometimes produces segmentation
 faults that are hard to reproduce. They happened before with ghc-6.6.1 and
 ghc-6.8.1 and I was able to get gdb output and output when compiled with
 -debug (and some RTS flag when calling):

 http://trac.informatik.uni-bremen.de:8080/hets/ticket/448#comment:4
 http://trac.informatik.uni-bremen.de:8080/hets/ticket/448#comment:9

 Maybe the linux kernel plays a role:
 {{{
 Linux leibniz 2.6.18.8-0.5-default #1 SMP Fri Jun 22 12:17:53 UTC 2007
 i686 i686 i386 GNU/Linux
 gcc (GCC) 4.1.2 20061115 (prerelease) (SUSE Linux)
 }}}

 For ghc-6.8.2 I could also reproduce segmentation faults, but they somehow
 disappear after a couple of retries.

 However installing prerequisites, building, and calling our hets
 application is not a trivial task.

 http://trac.informatik.uni-bremen.de:8080/hets/wiki/HetsForDevelopers
 http://www.dfki.de/sks/hets/src-distribution/versions/Hets/INSTALL

 Does anybody have suggestions what we might try or ideas about the reason?

 Regards Christian

-- 
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] #1976: System.Posix.User.getUserEntryForName: incorrect error for non-existent user

[GHC]

#1976: System.Posix.User.getUserEntryForName: incorrect error for non-existent
user
+---
 Reporter:  guest   |  Owner:
 Type:  bug | Status:  new   
 Priority:  normal  |  Milestone:  6.8.3 
Component:  libraries/unix  |Version:  6.8.2 
 Severity:  normal  | Resolution:
 Keywords:  | Difficulty:  Easy (1 hr)   
 Testcase:  |   Architecture:  x86_64 (amd64)
   Os:  Linux   |  
+---
Changes (by igloo):

  * version:  6.8.1 => 6.8.2
  * milestone:  => 6.8.3

Comment:

 Thanks for the report.

-- 
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

[GHC] #1979: Add variants of tails and inits not returning empty lists

[GHC]

#1979: Add variants of tails and inits not returning empty lists
---+
Reporter:  mux |   Owner: 
Type:  proposal|  Status:  new
Priority:  normal  |   Milestone:  6.8.3  
   Component:  libraries/base  | Version:  6.8.1  
Severity:  normal  |Keywords: 
  Difficulty:  Unknown |Testcase: 
Architecture:  Unknown |  Os:  Unknown
---+
 This patch adds the tails1 and inits1 function, that behave like their
 counterpart except that they won't return an empty list.  I've needed them
 several times already, so it seems to me they would be useful to have in
 base.

-- 
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] #1896: Keep old bindings until :load succeeds

[GHC]

#1896: Keep old bindings until :load succeeds
-+--
 Reporter:  tibbe|  Owner:
 Type:  feature request  | Status:  new   
 Priority:  normal   |  Milestone:  6.8 branch
Component:  GHCi |Version:  6.8.1 
 Severity:  normal   | Resolution:
 Keywords:   | Difficulty:  Unknown   
 Testcase:   |   Architecture:  Multiple  
   Os:  Multiple |  
-+--
Changes (by igloo):

  * difficulty:  => Unknown
  * milestone:  => 6.8 branch

Comment:

 We should think about what the best behaviour is here.

-- 
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] #1965: Allow unconstrained existential contexts in newtypes

[GHC]

#1965: Allow unconstrained existential contexts in newtypes
-+--
 Reporter:  guest|  Owner: 
 Type:  feature request  | Status:  closed 
 Priority:  normal   |  Milestone: 
Component:  Compiler |Version:  6.8.1  
 Severity:  minor| Resolution:  wontfix
 Keywords:   | Difficulty:  Unknown
 Testcase:   |   Architecture:  Unknown
   Os:  Unknown  |  
-+--
Changes (by igloo):

  * status:  new => closed
  * resolution:  => wontfix

Comment:

 Please reopen this ticket if you have a useful application for it.

-- 
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] #1960: Add Applicative and Monoid instances for STM

[GHC]

#1960: Add Applicative and Monoid instances for STM
+---
 Reporter:  conal   |  Owner: 
 Type:  proposal| Status:  new
 Priority:  normal  |  Milestone:  Not GHC
Component:  libraries/base  |Version:  6.8.1  
 Severity:  normal  | Resolution: 
 Keywords:  | Difficulty:  Easy (1 hr)
 Testcase:  |   Architecture:  Unknown
   Os:  Unknown |  
+---
Changes (by igloo):

  * milestone:  => Not GHC

Comment:

 It's a libraries proposal. The instances would need to go in the stm
 package as far as I can see.

-- 
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] #1974: length "foo" doesn't work with -XOverloadedStrings

[GHC]

#1974: length "foo" doesn't work with -XOverloadedStrings
-+--
 Reporter:  ganesh   |  Owner: 
 Type:  feature request  | Status:  new
 Priority:  low  |  Milestone:  6.10 branch
Component:  Compiler |Version:  6.8.1  
 Severity:  minor| Resolution: 
 Keywords:   | Difficulty:  Unknown
 Testcase:   |   Architecture:  Unknown
   Os:  Unknown  |  
-+--
Changes (by igloo):

  * milestone:  => 6.10 branch

Comment:

 Once #1877 is fixed, having the behaviour set by ExtendedDefaultRules
 won't do what you want (assuming you want to be able to do this in source
 files rather than at the GHCi prompt).

-- 
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] #1969: enormous compile times

[GHC]

#1969: enormous compile times
-+--
 Reporter:  duncan   |  Owner:
 Type:  bug  | Status:  new   
 Priority:  normal   |  Milestone:  6.8.3 
Component:  Compiler |Version:  6.8.1 
 Severity:  normal   | Resolution:
 Keywords:  performance  | Difficulty:  Difficult (1 week)
 Testcase:   |   Architecture:  Multiple  
   Os:  Multiple |  
-+--
Changes (by igloo):

  * priority:  low => normal
  * keywords:  => performance
  * type:  task => bug
  * milestone:  => 6.8.3

Comment:

 Thanks for the report. We have a few similar bugs; I've just keyworded
 them all "performance".

-- 
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] #783: performance problem compiling large file

[GHC]

#783: performance problem compiling large file
-+--
 Reporter:  guest|  Owner:  
 Type:  bug  | Status:  new 
 Priority:  normal   |  Milestone:  6.8.3   
Component:  Compiler |Version:  6.4.2   
 Severity:  normal   | Resolution:  
 Keywords:  performance  | Difficulty:  Unknown 
 Testcase:   |   Architecture:  Multiple
   Os:  Multiple |  
-+--
Changes (by igloo):

  * keywords:  => performance

-- 
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] #1136: High memory use when compiling many let bindings.

[GHC]

#1136: High memory use when compiling many let bindings.
-+--
 Reporter:  igloo|  Owner: 
 Type:  bug  | Status:  new
 Priority:  high |  Milestone:  6.8.3  
Component:  Compiler |Version:  6.6
 Severity:  normal   | Resolution: 
 Keywords:  performance  | Difficulty:  Unknown
 Testcase:   |   Architecture:  Unknown
   Os:  Unknown  |  
-+--
Changes (by igloo):

  * keywords:  => performance

-- 
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] #1875: Compiling with -O is 30 times slower than with -Onot

[GHC]

#1875: Compiling with -O is 30 times slower than with -Onot
-+--
 Reporter:  simonpj  |  Owner: 
 Type:  bug  | Status:  new
 Priority:  normal   |  Milestone:  6.8.3  
Component:  Compiler |Version:  6.8.1  
 Severity:  normal   | Resolution: 
 Keywords:  performance  | Difficulty:  Unknown
 Testcase:   |   Architecture:  Unknown
   Os:  Unknown  |  
-+--
Changes (by igloo):

  * keywords:  => performance

-- 
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] #1977: Adding small check in Linux installer

[GHC]

#1977: Adding small check in Linux installer
-+--
 Reporter:  Tener|  Owner: 
 Type:  bug  | Status:  new
 Priority:  lowest   |  Milestone:  6.8.3  
Component:  None |Version:  6.8.1  
 Severity:  trivial  | Resolution: 
 Keywords:  installer, path  | Difficulty:  Easy (1 hr)
 Testcase:   |   Architecture:  Unknown
   Os:  Linux|  
-+--
Changes (by igloo):

  * type:  proposal => bug
  * milestone:  => 6.8.3

Comment:

 Good point; this should be easy, so let's do it for 6.8.3.

-- 
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] #1978: Error message: Undefined reference to `XXX_closure'

[GHC]

#1978: Error message: Undefined reference to `XXX_closure'
--+-
 Reporter:  Andriy|  Owner: 
 Type:  bug   | Status:  new
 Priority:  normal|  Milestone: 
Component:  Compiler  |Version:  6.6
 Severity:  major | Resolution: 
 Keywords:| Difficulty:  Unknown
 Testcase:|   Architecture:  x86
   Os:  Linux |  
--+-
Comment (by simonpj):

 Very mysterious.

 You say "GHC 6.6", but Ubuntu 7.04 comes with GHC 6.6.1, we think.  GHC
 6.6.1 fixes a lot of bugs in 6.6 so we don't want to trace bugs in 6.6.
 Can you try 6.6.1 at least.

 Better still try 6.8.2.

 And please add `-dcore-lint` when you compile and see if that changes
 behaviour (adds a strong internal consistency check).

 Simon

-- 
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] #1838: do not use getEnv "HOME", use System.Directory.getHomeDirectory

[GHC]

#1838: do not use getEnv "HOME", use System.Directory.getHomeDirectory
-+--
 Reporter:  guest|  Owner:  igloo   
 Type:  bug  | Status:  reopened
 Priority:  normal   |  Milestone:  6.8.3   
Component:  GHCi |Version:  6.8.2   
 Severity:  normal   | Resolution:  
 Keywords:   | Difficulty:  Unknown 
 Testcase:   |   Architecture:  Unknown 
   Os:  Windows  |  
-+--
Changes (by [EMAIL PROTECTED]):

  * status:  closed => reopened
  * type:  merge => bug
  * version:  6.6.1 => 6.8.2
  * resolution:  fixed =>
  * milestone:  6.8.2 => 6.8.3

Comment:

 Mailing list contributors say the new behaviour is a regression.  Their
 suggestion is to preserve backwards compatibility, while still allowing
 the new behaviour.

 Juanma Barranquero says:
   In fact, it'd be better if GHC/GHCi would do what Emacs on Windows
   does: use HOME if defined, else use ShGetFolderPath to find the
   Windows-defined "home directory".

 Yitzchak Gale says:
   %HOMEPATH% is *not* the usual Windows native way of finding a place for
 files like dot-ghci.
   Note that the old cmd.exe shell itself is deprecated on Vista - the new
 MSH shell is based on .NET.
   There I think you would use the IKnownFolders interface to get
 (something vagualy analagous to)
   the home directory, not %HOMEPATH%

   Also, %HOMEPATH% is unsuitable for a Unix-style home directory on pre-
 Vista systems, because it usually points to
   a directory with spaces in its path name.

   %HOME% is the de-facto standard for Unix-like shell applications that
 were ported to Windows and
   need a home directory. If someone sets that, it means they want to use
 the folder in that way. And
   yes, that is the way GHCi has been working until now, so I think it
 should still be supported if someone
   sets it.

   Otherwise, the native Windows way is via ShGetFolderPath on pre-Vista,
 and ShGetKnownFolder on Vista.
   The installer should create a GHC subfolder of that, and that is where
 dot-ghci should go on Windows,
   unless %HOME% is set.

-- 
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