Re: [GHC] #7375: Building ghc fails because it is looking for an old version of libgmp

2012-11-09 Thread GHC
#7375: Building ghc fails because it is looking for an old version of libgmp
--+-
  Reporter:  mimosa   |  Owner:  
  Type:  bug  | Status:  closed  
  Priority:  normal   |  Milestone:  
 Component:  Compiler |Version:  7.4.2   
Resolution:  fixed|   Keywords:  
Os:  Linux|   Architecture:  Unknown/Multiple
   Failure:  Building GHC failed  | Difficulty:  Unknown 
  Testcase:   |  Blockedby:  
  Blocking:   |Related:  5743
--+-

Comment(by simonmar):

 GHC is already following your suggestion: there is a copy of the gmp
 library in the build tree that we use if there isn't one on the system.
 It's in `libraries/integer-gmp/gmp`, and the same is true for `libffi`
 (although for the latter the problem has been that we are ''always'' using
 our copy of `libffi`, and some distros wanted us to use the system one
 instead, which is what #5743 is about).

 To avoid needing a hack, you just need to provide a stage 0 compiler that
 has the right dependencies.  You can get one by building GHC and then
 making a binary distribution from it.  Having done that, you're all set -
 no need for `libgmp.so.3` symlinks.

-- 
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7375#comment:8
GHC http://www.haskell.org/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] #7401: Can't derive instance for Eq when datatype has no constructor, when it's trivial do do so.

2012-11-09 Thread GHC
#7401: Can't derive instance for Eq when datatype has no constructor, when it's
trivial do do so.
-+--
Reporter:  jpbernardy|  Owner:  
Type:  bug   | Status:  new 
Priority:  normal|  Component:  Compiler
 Version:  7.6.1 |   Keywords:  deriving
  Os:  Unknown/Multiple  |   Architecture:  Unknown/Multiple
 Failure:  None/Unknown  |  Blockedby:  
Blocking:|Related:  
-+--
 On a phantom datatype D, one gets the message:

 Can't make a derived instance of `Eq D':
   `D' must have at least one data constructor

 However there is a trivial, correct instance of Eq D:

 instance Eq D where
   (==) = undefined

-- 
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7401
GHC http://www.haskell.org/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] #7375: Building ghc fails because it is looking for an old version of libgmp

2012-11-09 Thread GHC
#7375: Building ghc fails because it is looking for an old version of libgmp
--+-
  Reporter:  mimosa   |  Owner:  
  Type:  bug  | Status:  closed  
  Priority:  normal   |  Milestone:  
 Component:  Compiler |Version:  7.4.2   
Resolution:  fixed|   Keywords:  
Os:  Linux|   Architecture:  Unknown/Multiple
   Failure:  Building GHC failed  | Difficulty:  Unknown 
  Testcase:   |  Blockedby:  
  Blocking:   |Related:  5743
--+-

Comment(by mimosa):

 So if a working GHC is present, I take it that will be used instead of
 stage 0 in the unknown-linux tarball, is that right?

 As I said above, the GHC I built still seems to require the old gmp, but
 maybe there's something wrong with my package.

 For practical purposes, a package is a build that works on a particular
 system (in my case, a Linux distribution), but from the point of view of
 that system's packaging procedures, it is a link to the source code and a
 build script; taken together these should be capable of recreating the
 package from zero. However you go about it, GHC is going to need special
 treatment somewhere. For instance, the package source might include the
 locally built stage 0 compiler you suggest.

 Thank you for your helpful explanations. I'll talk to the Salix developers
 to see what solution they regard as ideal and try and deliver that for the
 next packaging cycle. Meanwhile, the existing package should be available
 from Salix repos shortly, and can be considered a Slackware package too.

-- 
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7375#comment:9
GHC http://www.haskell.org/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] #7395: DefaultSignatures conflict with default implementations

2012-11-09 Thread GHC
#7395: DefaultSignatures conflict with default implementations
--+-
Reporter:  cgaebel|   Owner:   
Type:  bug|  Status:  new  
Priority:  normal |   Milestone:   
   Component:  Compiler   | Version:  7.6.1
Keywords:  DefaultSignatures  |  Os:  Unknown/Multiple 
Architecture:  Unknown/Multiple   | Failure:  GHC rejects valid program
  Difficulty:  Unknown|Testcase:   
   Blockedby: |Blocking:   
 Related: |  
--+-

Comment(by hvr):

 just a thought:

 ...what if the default-signature implementation would be only selectable
 by using the `deriving` facilities for auto-derivable classes? I.e. by
 using

 {{{
 #!hs
 data A = A { unA :: Int }
 deriving (Generic,Klass)
 }}}
 or
 {{{
 #!hs
 data A = A { unA :: Int }
 deriving Generic

 deriving instance Klass A
 }}}

 would both result in `A` getting the default-signature based
 implementation, wheras

 {{{
 #!hs
 data A = A { unA :: Int }
 deriving Generic

 instance Klass A
 }}}

 would get the ordinary default implementation (as if the default-
 signature implementation wasn't there). Wouldn't this help the issue at
 hand by making the choice explicit?

-- 
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7395#comment:7
GHC http://www.haskell.org/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] #7400: Strange closure type 17 internal error

2012-11-09 Thread GHC
#7400: Strange closure type 17 internal error
---+
Reporter:  ropoctl |   Owner:   
Type:  bug |  Status:  new  
Priority:  highest |   Milestone:  7.6.2
   Component:  Runtime System  | Version:  7.4.2
Keywords:  |  Os:  Linux
Architecture:  x86_64 (amd64)  | Failure:  Runtime crash
  Difficulty:  Unknown |Testcase:   
   Blockedby:  |Blocking:   
 Related:  |  
---+
Changes (by simonmar):

  * priority:  normal = highest
  * difficulty:  = Unknown
  * milestone:  = 7.6.2
  * failure:  None/Unknown = Runtime crash


Comment:

 Thanks for the report, we'll take a look.

-- 
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7400#comment:1
GHC http://www.haskell.org/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] #7401: Can't derive instance for Eq when datatype has no constructor, when it's trivial do do so.

2012-11-09 Thread GHC
#7401: Can't derive instance for Eq when datatype has no constructor, when it's
trivial do do so.
--+-
Reporter:  jpbernardy |  Owner:  
Type:  feature request| Status:  new 
Priority:  normal |  Component:  Compiler
 Version:  7.6.1  |   Keywords:  deriving
  Os:  Unknown/Multiple   |   Architecture:  Unknown/Multiple
 Failure:  GHC rejects valid program  |  Blockedby:  
Blocking: |Related:  
--+-
Changes (by jpbernardy):

  * failure:  None/Unknown = GHC rejects valid program
  * type:  bug = feature request


-- 
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7401#comment:1
GHC http://www.haskell.org/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] #7401: Can't derive instance for Eq when datatype has no constructor, while it is trivial do do so. (was: Can't derive instance for Eq when datatype has no constructor, when it's trivial do

2012-11-09 Thread GHC
#7401: Can't derive instance for Eq when datatype has no constructor, while it 
is
trivial do do so.
--+-
Reporter:  jpbernardy |  Owner:  
Type:  feature request| Status:  new 
Priority:  normal |  Component:  Compiler
 Version:  7.6.1  |   Keywords:  deriving
  Os:  Unknown/Multiple   |   Architecture:  Unknown/Multiple
 Failure:  GHC rejects valid program  |  Blockedby:  
Blocking: |Related:  
--+-

-- 
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7401#comment:2
GHC http://www.haskell.org/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] #7395: DefaultSignatures conflict with default implementations

2012-11-09 Thread GHC
#7395: DefaultSignatures conflict with default implementations
--+-
Reporter:  cgaebel|   Owner:   
Type:  bug|  Status:  new  
Priority:  normal |   Milestone:   
   Component:  Compiler   | Version:  7.6.1
Keywords:  DefaultSignatures  |  Os:  Unknown/Multiple 
Architecture:  Unknown/Multiple   | Failure:  GHC rejects valid program
  Difficulty:  Unknown|Testcase:   
   Blockedby: |Blocking:   
 Related: |  
--+-

Comment(by cgaebel):

 +1 to hvr's idea. This would have the additional (very awesome) benefit of
 allowing the deriving of Show, Read, Eq, Ord, etc. to be implemented in a
 library (Prelude?) instead of living as compiler magic.

 This bug just got a whole lot more exciting.

-- 
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7395#comment:8
GHC http://www.haskell.org/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] #7394: SafeHaskell permits OPTIONS_GHC pragmas

2012-11-09 Thread GHC
#7394: SafeHaskell permits OPTIONS_GHC pragmas
---+
  Reporter:  dag   |  Owner:  
  Type:  bug   | Status:  closed  
  Priority:  normal|  Milestone:  7.8.1   
 Component:  Documentation |Version:  7.4.1   
Resolution:  fixed |   Keywords:  
Os:  Unknown/Multiple  |   Architecture:  Unknown/Multiple
   Failure:  None/Unknown  | Difficulty:  Unknown 
  Testcase:|  Blockedby:  
  Blocking:|Related:  
---+
Changes (by dterei):

  * status:  new = closed
  * resolution:  = fixed


Comment:

 OK, thanks for the report! Added some documentation about this issue in
 b78b6b3472511c7e39d5c91b0449a59e0f361dcf.

-- 
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7394#comment:3
GHC http://www.haskell.org/ghc/
The Glasgow Haskell Compiler

___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs