GHC | 1 Jul 09:09 2011

Re: #4459: Polymorphic Data.Dynamic

#4459: Polymorphic Data.Dynamic
-----------------------------------------------------+----------------------
    Reporter:  vivian                                |        Owner:  vivian      
        Type:  feature request                       |       Status:  new         
    Priority:  normal                                |    Milestone:  7.4.1       
   Component:  GHC API                               |      Version:  7.1         
    Keywords:  polymorphic, dynamic, class, linking  |     Testcase:              
   Blockedby:                                        |   Difficulty:              
          Os:  Unknown/Multiple                      |     Blocking:  4316        
Architecture:  Unknown/Multiple                      |      Failure:  None/Unknown
-----------------------------------------------------+----------------------

Comment(by simonpj):

 I too am very hazy about what this ticket is asking for.  The existing
 `Data.Dynamic` looks like this
 {{{
 data Dynamic = Dynamic TypeRep Obj   -- Obj is like HValue; GHC is
 inconsistent
 toDyn :: Typeable a => a -> Dynamic
 fromDynamic :: Typeable a => Dynamic -> Maybe a
 dynApply :: Dynamic -> Dynamic -> Maybe Dynamic
 }}}
 I think that `Dynamic` is what you call `TypedAny`.

 In the existing setup you cannot put a polymorphic value in a `Dynamic`.
 So if `sort :: Ord a => [a] -> [a]`, you can say
 {{{
     toDyn (sort :: [Int] -> [Int])
     toDyn (sort :: [Bool] -> [Bool])
(Continue reading)

GHC | 1 Jul 09:13 2011

Re: #1595: duplicate "not in scope" error when giving multiple vars type-signatures at once

#1595: duplicate "not in scope" error when giving multiple vars type-signatures at
once
------------------------------------------------+---------------------------
  Reporter:  Isaac Dupree                       |          Owner:  michalt         
      Type:  bug                                |         Status:  closed          
  Priority:  normal                             |      Milestone:  7.2.1           
 Component:  Compiler                           |        Version:  6.6.1           
Resolution:  fixed                              |       Keywords:                  
  Testcase:  rename/should_fail/T1595           |      Blockedby:                  
Difficulty:  Unknown                            |             Os:  Unknown/Multiple
  Blocking:                                     |   Architecture:  Unknown/Multiple
   Failure:  Incorrect warning at compile-time  |  
------------------------------------------------+---------------------------
Changes (by simonpj):

  * testcase:  => rename/should_fail/T1595

--

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/1595#comment:21>
GHC | 1 Jul 09:15 2011

Re: #3843: Merge plugins into HEAD

#3843: Merge plugins into HEAD
---------------------------------+------------------------------------------
    Reporter:  dreixel           |        Owner:  simonpj     
        Type:  task              |       Status:  new         
    Priority:  normal            |    Milestone:  7.2.1       
   Component:  Compiler          |      Version:  6.13        
    Keywords:                    |     Testcase:              
   Blockedby:                    |   Difficulty:              
          Os:  Unknown/Multiple  |     Blocking:              
Architecture:  Unknown/Multiple  |      Failure:  None/Unknown
---------------------------------+------------------------------------------

Comment(by simonpj):

 Guys, I'm getting validate failures from plugin tests. What's up?
 {{{
 Unexpected failures:
    plugins             plugins01 [bad exit code] (normal)
    plugins             plugins02 [stderr mismatch] (normal)
    plugins             plugins03 [stderr mismatch] (normal)
 }}}

 Here's some log stuff
 {{{
 =====> plugins01(normal) 2731 of 2829 [0, 3, 1]
 cd ./plugins && $MAKE -s --no-print-directory plugins01    </dev/null
 >plugins01.run.stdout 2>plugins01.run.stderr
 Wrong exit code (expected 0 , actual 2 )
 Stdout:

(Continue reading)

GHC | 1 Jul 09:17 2011

Re: #5263: Compiler panic, trying to compile text-0.5

#5263: Compiler panic, trying to compile text-0.5
---------------------------+------------------------------------------------
  Reporter:  guest         |          Owner:         
      Type:  bug           |         Status:  closed 
  Priority:  normal        |      Milestone:         
 Component:  Compiler      |        Version:  7.0.3  
Resolution:  fixed         |       Keywords:         
  Testcase:                |      Blockedby:         
Difficulty:                |             Os:  Windows
  Blocking:                |   Architecture:  x86    
   Failure:  None/Unknown  |  
---------------------------+------------------------------------------------
Changes (by simonpj):

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

Comment:

 Thanks. That was a bad bug.  It's fixed by this patch
 {{{
 commit 2395cdff13a150016ec47bbe7da7bb8239b3a252
 Author: Simon Peyton Jones <simonpj <at> microsoft.com>
 Date:   Mon Jun 27 09:14:45 2011 +0100

     Fix Trac #5263: bug in chooseExternalIds

     An identifier used in an unfolding wasn't getting marked
     as an external Id, which caused subsequent chaos.

(Continue reading)

GHC | 1 Jul 09:28 2011

Re: #4081: Strict constructor fields inspected in loop

#4081: Strict constructor fields inspected in loop
---------------------------------+------------------------------------------
    Reporter:  rl                |        Owner:  benl                   
        Type:  bug               |       Status:  new                    
    Priority:  normal            |    Milestone:  7.2.1                  
   Component:  Compiler          |      Version:  6.13                   
    Keywords:                    |     Testcase:                         
   Blockedby:                    |   Difficulty:                         
          Os:  Unknown/Multiple  |     Blocking:                         
Architecture:  Unknown/Multiple  |      Failure:  Runtime performance bug
---------------------------------+------------------------------------------
Changes (by simonpj):

  * owner:  => benl

Comment:

 Right this is done, I think.  Give it a try.  '''Ben or Roman''' do you
 think you might think of a way to test this?  I can think of two possible
 ways:
  * Find a case where there is a big runtime difference, and measure that.
 But that is fragile to which system you are running on.
  * Dump the Core and grep for something or other.  Perhaps in your example
 all the primops should be together, rather than separated by unboxing?
 I'd just like a test that'll trip if this optimisation stops happening.
 Thanks.

 Two main patches:
 {{{
 commit 9cb20b488d4986c122b0461a54bc5c970f9d8502
(Continue reading)

GHC | 1 Jul 09:36 2011

Re: #5286: panic: getPredTyDescription EqPred [7.0 regression]

#5286: panic: getPredTyDescription EqPred [7.0 regression]
---------------------------------+------------------------------------------
  Reporter:  simonmar            |          Owner:  simonpj         
      Type:  bug                 |         Status:  closed          
  Priority:  highest             |      Milestone:  7.2.1           
 Component:  Compiler            |        Version:  7.0.3           
Resolution:  fixed               |       Keywords:                  
  Testcase:                      |      Blockedby:                  
Difficulty:                      |             Os:  Unknown/Multiple
  Blocking:                      |   Architecture:  Unknown/Multiple
   Failure:  Compile-time crash  |  
---------------------------------+------------------------------------------
Changes (by simonpj):

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

Comment:

 Fixed by
 {{{
 commit 83cacd522a78cd7a19359b3df3e160cb44e2ca3f
 Author: Simon Peyton Jones <simonpj <at> microsoft.com>
 Date:   Thu Jun 30 17:45:00 2011 +0100

     Fix Trac #5286: getPredTyDescription

 >---------------------------------------------------------------

  compiler/codeGen/ClosureInfo.lhs  |    2 +-
(Continue reading)

GHC | 1 Jul 09:39 2011

Re: #4081: Strict constructor fields inspected in loop

#4081: Strict constructor fields inspected in loop
---------------------------------+------------------------------------------
    Reporter:  rl                |        Owner:  benl                   
        Type:  bug               |       Status:  new                    
    Priority:  normal            |    Milestone:  7.2.1                  
   Component:  Compiler          |      Version:  6.13                   
    Keywords:                    |     Testcase:                         
   Blockedby:                    |   Difficulty:                         
          Os:  Unknown/Multiple  |     Blocking:                         
Architecture:  Unknown/Multiple  |      Failure:  Runtime performance bug
---------------------------------+------------------------------------------

Comment(by simonpj):

 Here are a couple more examples Max suggested, which I want to capture in
 this ticket.
 {{{
 module T4081a where

 ----------------
 data S1 = S1 !Product
 data Product = Product !Int

 foo :: S1 -> Int
 foo (S1 x) = go 0 10
   where
     go acc 0 = acc
     go acc y = case x of Product x -> go (acc + (y * x)) (y - 1)

 ---------------------
(Continue reading)

GHC | 1 Jul 09:40 2011

#5291: GhcDynamic build fails on Windows: can't find DLLs

#5291: GhcDynamic build fails on Windows: can't find DLLs
---------------------------------+------------------------------------------
    Reporter:  batterseapower    |       Owner:                     
        Type:  bug               |      Status:  new                
    Priority:  normal            |   Component:  Build System       
     Version:  7.0.3             |    Keywords:                     
    Testcase:                    |   Blockedby:                     
          Os:  Windows           |    Blocking:                     
Architecture:  Unknown/Multiple  |     Failure:  Building GHC failed
---------------------------------+------------------------------------------
 Enabling GhcDynamic causes the Windows build to fail:

 {{{
 "inplace/bin/ghc-stage2.exe"   -H64m -O0 -fasm     -i -iutils/ghctags/.
 -iutils/ghctags/dist-install/build -iutils/ghctags/dist-
 install/build/autogen -Iutils/ghctags/dist-install/build -Iutils/ghctags
 /dist-install/build/autogen        -package ghc -no-user-package-conf
 -rtsopts     -odir utils/ghctags/dist-install/build -hidir utils/ghctags
 /dist-install/build -stubdir utils/ghctags/dist-install/build -hisuf hi
 -osuf  o -hcsuf hc -c utils/ghctags/./Main.hs -o utils/ghctags/dist-
 install/build/Main.o
 /home/Max/Programming/Checkouts/ghc.shared/inplace/bin/ghc-stage2.exe:
 error while loading shared libraries:
 libHSprocess-1.0.1.4-ghc7.1.20110630.dll: cannot open shared object file:
 No such file or directory
 }}}

 The reason is that Windows searches for DLLs in the application directory,
 and the DLLs that a dynamic GHC depends on are not placed in that
 directory. (See http://msdn.microsoft.com/en-
(Continue reading)

GHC | 1 Jul 10:03 2011

Re: #5291: GhcDynamic build fails on Windows: can't find DLLs

#5291: GhcDynamic build fails on Windows: can't find DLLs
---------------------------------+------------------------------------------
    Reporter:  batterseapower    |       Owner:                     
        Type:  bug               |      Status:  new                
    Priority:  normal            |   Component:  Build System       
     Version:  7.0.3             |    Keywords:                     
    Testcase:                    |   Blockedby:                     
          Os:  Windows           |    Blocking:                     
Architecture:  Unknown/Multiple  |     Failure:  Building GHC failed
---------------------------------+------------------------------------------

Comment(by guest):

 Concerning after GHC is installed: DLLs should never go into System32,
 it's considered pollution/bad practice.  DLLs shipped with GHC should be
 under the GHC install directory if they belong to GHC.

--

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/5291#comment:1>
GHC | 1 Jul 10:10 2011

Re: #5284: Simplifier performance regression (or infinite loop)

#5284: Simplifier performance regression (or infinite loop)
---------------------------------+------------------------------------------
    Reporter:  simonmar          |        Owner:                              
        Type:  bug               |       Status:  new                         
    Priority:  highest           |    Milestone:  7.2.1                       
   Component:  Compiler          |      Version:  7.0.3                       
    Keywords:                    |     Testcase:                              
   Blockedby:                    |   Difficulty:                              
          Os:  Unknown/Multiple  |     Blocking:                              
Architecture:  Unknown/Multiple  |      Failure:  Compile-time performance bug
---------------------------------+------------------------------------------

Comment(by simonpj):

 That's odd.  It seems ok now.  Can you try again?
 {{{
 bash$ wc T3016.hs
    584   3486 174956 T3016.hs

 bash$ time ~/builds/validate-HEAD/inplace/bin/ghc-stage2 -c -O T3016.hs
 -fforce-recomp +RTS -s
   13,862,317,264 bytes allocated in the heap
    8,584,884,064 bytes copied during GC
      123,304,256 bytes maximum residency (54 sample(s))
        2,311,912 bytes maximum slop
              325 MB total memory in use (0 MB lost due to fragmentation)

                                     Tot time (elapsed)  Avg pause  Max
 pause
   Gen  0     26462 colls,     0 par   12.39s   12.40s     0.0005s
(Continue reading)


Gmane