From trac at galois.com  Tue Jan  1 09:06:31 2008
From: trac at galois.com (GHC)
Date: Tue Jan  1 09:00:36 2008
Subject: [GHC] #1985: IntSet.deleteMin doesn't agree with Set.deleteMin
In-Reply-To: <047.5a3c908303a81d833e8535fa59db8e2e@localhost>
References: <047.5a3c908303a81d833e8535fa59db8e2e@localhost>
Message-ID: <056.93959bc636abd47fdce80197551a685a@localhost>

#1985: IntSet.deleteMin doesn't agree with Set.deleteMin
-------------------------------+--------------------------------------------
 Reporter:  dbenbenn           |          Owner:             
     Type:  bug                |         Status:  new        
 Priority:  normal             |      Milestone:  6.10 branch
Component:  libraries (other)  |        Version:  6.8.1      
 Severity:  normal             |     Resolution:             
 Keywords:                     |     Difficulty:  Unknown    
 Testcase:                     |   Architecture:  Multiple   
       Os:  Multiple           |  
-------------------------------+--------------------------------------------
Changes (by igloo):

 * cc: jeanphilippe.bernardy (added)
  * milestone:  => 6.10 branch

Comment:

 Good spot! Jean-Philippe, does David's patch look right to you?

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/1985#comment:1>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Tue Jan  1 09:12:41 2008
From: trac at galois.com (GHC)
Date: Tue Jan  1 09:06:47 2008
Subject: [GHC] #1989: GHC-6.8.1 fails arith003 on amd64/FreeBSD-7.0
In-Reply-To: <047.e1a81f31ca9bdca7e0fd42494374e2fa@localhost>
References: <047.e1a81f31ca9bdca7e0fd42494374e2fa@localhost>
Message-ID: <056.7828575d8bafc2018fb6c919476d6f22@localhost>

#1989: GHC-6.8.1 fails arith003 on amd64/FreeBSD-7.0
----------------------+-----------------------------------------------------
 Reporter:  wb.kloke  |          Owner:                
     Type:  bug       |         Status:  new           
 Priority:  normal    |      Milestone:                
Component:  Compiler  |        Version:  6.8.2         
 Severity:  normal    |     Resolution:                
 Keywords:            |     Difficulty:  Unknown       
 Testcase:            |   Architecture:  x86_64 (amd64)
       Os:  FreeBSD   |  
----------------------+-----------------------------------------------------
Old description:

> I am trying to build a native amd64 compiler on FreeBSD. At the bootstrap
> stage I use the -i386
> compiler as ghc: This works to stage1. The stage1 compiler is usable in a
> limited way. But the stage2 compiler built with this fails very early
> (before even complaining about missing -B options, if started naked).
>
> Ex.:
> /home/wb.local/ghc-6.8.2 0$ compiler/stage2/ghc-6.8.2
> Segmentation fault: 11 (core dumped)
> wb@yorikke:ttyp2
> /home/wb.local/ghc-6.8.2 0$ compiler/stage1/ghc-6.8.2
> ghc-6.8.2: missing -B<dir> option
>

> The most reproducable misbehaviour of the stage1 compiler is the
> unability to run test arith003. The value minInt is converted to a
> nonprintable 1-char string in the int_ops part. Most other results,
> including the multiple precision tests, look better than the output from
> x86-64-openbsd (as published with the 6.6.1-testsuite). It looks as if
> there is a specific problem with bit pattern 0x8000000000000000L. If I
> change the source code to avoid this pattern (minInt -> minInt+1) the
> error does not occur.
>
> First lines of arith003 output:
>
> (+) 0 0 = 0
> (+) 0 1 = 1
> (+) 0 -1 = -1
> (+) 0 2 = 2
> (+) 0 -2 = -2
> (+) 0 -<FC>8 = -<FC>8
> (+) 0 9223372036854775807 = 9223372036854775807
> (+) 1 0 = 1
> (+) 1 1 = 2
> (+) 1 -1 = 0
> (+) 1 2 = 3
> (+) 1 -2 = -1
> (+) 1 -<FC>8 = -9223372036854775807
> (+) 1 9223372036854775807 = -<FC>8
> (+) -1 0 = -1
> (+) -1 1 = 0
> (+) -1 -1 = -2
> (+) -1 2 = 1
> (+) -1 -2 = -3
> (+) -1 -<FC>8 = 9223372036854775807
> (+) -1 9223372036854775807 = 9223372036854775806
> (+) 2 0 = 2
> (+) 2 1 = 3
> (+) 2 -1 = 1
> (+) 2 2 = 4
> (+) 2 -2 = 0
> (+) 2 -<FC>8 = -9223372036854775806
> (+) 2 9223372036854775807 = -9223372036854775807
> (+) -2 0 = -2
> (+) -2 1 = -1
> (+) -2 -1 = -3
> (+) -2 2 = 0
> (+) -2 -2 = -4
> (+) -2 -<FC>8 = 9223372036854775806
> (+) -2 9223372036854775807 = 9223372036854775805
> (+) -<FC>8 0 = -<FC>8
> (+) -<FC>8 1 = -9223372036854775807
> (+) -<FC>8 -1 = 9223372036854775807
> (+) -<FC>8 2 = -9223372036854775806
> (+) -<FC>8 -2 = 9223372036854775806
> (+) -<FC>8 -<FC>8 = 0
> (+) -<FC>8 9223372036854775807 = -1
> (+) 9223372036854775807 0 = 9223372036854775807
> (+) 9223372036854775807 1 = -<FC>8
> (+) 9223372036854775807 -1 = 9223372036854775806
> (+) 9223372036854775807 2 = -9223372036854775807
> (+) 9223372036854775807 -2 = 9223372036854775805
> (+) 9223372036854775807 -<FC>8 = -1
> (+) 9223372036854775807 9223372036854775807 = -2
> ...

New description:

 I am trying to build a native amd64 compiler on FreeBSD. At the bootstrap
 stage I use the -i386
 compiler as ghc: This works to stage1. The stage1 compiler is usable in a
 limited way. But the stage2 compiler built with this fails very early
 (before even complaining about missing -B options, if started naked).
 {{{
 Ex.:
 /home/wb.local/ghc-6.8.2 0$ compiler/stage2/ghc-6.8.2
 Segmentation fault: 11 (core dumped)
 wb@yorikke:ttyp2
 /home/wb.local/ghc-6.8.2 0$ compiler/stage1/ghc-6.8.2
 ghc-6.8.2: missing -B<dir> option
 }}}

 The most reproducable misbehaviour of the stage1 compiler is the unability
 to run test arith003. The value minInt is converted to a nonprintable
 1-char string in the int_ops part. Most other results, including the
 multiple precision tests, look better than the output from x86-64-openbsd
 (as published with the 6.6.1-testsuite). It looks as if there is a
 specific problem with bit pattern 0x8000000000000000L. If I change the
 source code to avoid this pattern (minInt -> minInt+1) the error does not
 occur.

 First lines of arith003 output:
 {{{
 (+) 0 0 = 0
 (+) 0 1 = 1
 (+) 0 -1 = -1
 (+) 0 2 = 2
 (+) 0 -2 = -2
 (+) 0 -<FC>8 = -<FC>8
 (+) 0 9223372036854775807 = 9223372036854775807
 (+) 1 0 = 1
 (+) 1 1 = 2
 (+) 1 -1 = 0
 (+) 1 2 = 3
 (+) 1 -2 = -1
 (+) 1 -<FC>8 = -9223372036854775807
 (+) 1 9223372036854775807 = -<FC>8
 (+) -1 0 = -1
 (+) -1 1 = 0
 (+) -1 -1 = -2
 (+) -1 2 = 1
 (+) -1 -2 = -3
 (+) -1 -<FC>8 = 9223372036854775807
 (+) -1 9223372036854775807 = 9223372036854775806
 (+) 2 0 = 2
 (+) 2 1 = 3
 (+) 2 -1 = 1
 (+) 2 2 = 4
 (+) 2 -2 = 0
 (+) 2 -<FC>8 = -9223372036854775806
 (+) 2 9223372036854775807 = -9223372036854775807
 (+) -2 0 = -2
 (+) -2 1 = -1
 (+) -2 -1 = -3
 (+) -2 2 = 0
 (+) -2 -2 = -4
 (+) -2 -<FC>8 = 9223372036854775806
 (+) -2 9223372036854775807 = 9223372036854775805
 (+) -<FC>8 0 = -<FC>8
 (+) -<FC>8 1 = -9223372036854775807
 (+) -<FC>8 -1 = 9223372036854775807
 (+) -<FC>8 2 = -9223372036854775806
 (+) -<FC>8 -2 = 9223372036854775806
 (+) -<FC>8 -<FC>8 = 0
 (+) -<FC>8 9223372036854775807 = -1
 (+) 9223372036854775807 0 = 9223372036854775807
 (+) 9223372036854775807 1 = -<FC>8
 (+) 9223372036854775807 -1 = 9223372036854775806
 (+) 9223372036854775807 2 = -9223372036854775807
 (+) 9223372036854775807 -2 = 9223372036854775805
 (+) 9223372036854775807 -<FC>8 = -1
 (+) 9223372036854775807 9223372036854775807 = -2
 ...
 }}}

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/1989#comment:2>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Tue Jan  1 09:36:08 2008
From: trac at galois.com (GHC)
Date: Tue Jan  1 09:30:10 2008
Subject: [GHC] #1989: GHC-6.8.1 fails arith003 on amd64/FreeBSD-7.0
In-Reply-To: <047.e1a81f31ca9bdca7e0fd42494374e2fa@localhost>
References: <047.e1a81f31ca9bdca7e0fd42494374e2fa@localhost>
Message-ID: <056.e23c909558be83ef0d8fa824c7c28c12@localhost>

#1989: GHC-6.8.1 fails arith003 on amd64/FreeBSD-7.0
----------------------+-----------------------------------------------------
 Reporter:  wb.kloke  |          Owner:                
     Type:  bug       |         Status:  new           
 Priority:  normal    |      Milestone:  6.8.3         
Component:  Compiler  |        Version:  6.8.2         
 Severity:  normal    |     Resolution:                
 Keywords:            |     Difficulty:  Unknown       
 Testcase:            |   Architecture:  x86_64 (amd64)
       Os:  FreeBSD   |  
----------------------+-----------------------------------------------------
Changes (by igloo):

  * milestone:  => 6.8.3

Comment:

 If you've built stage3 then that means the compiler itself is now
 basically working, right?

 For arith003, the maths looks OK, I assume the problem is with the
 printing code:
 {{{
 showSignedInt :: Int -> Int -> ShowS
 showSignedInt (I# p) (I# n) r
     | n <# 0# && p ># 6# = '(' : itos n (')' : r)
     | otherwise          = itos n r

 itos :: Int# -> String -> String
 itos n# cs
     | n# <# 0# =
     let I# minInt# = minInt in
     if n# ==# minInt#
         -- negateInt# minInt overflows, so we can't do that:
        then '-' : itos' (negateInt# (n# `quotInt#` 10#))
                              (itos' (negateInt# (n# `remInt#` 10#)) cs)
        else '-' : itos' (negateInt# n#) cs
     | otherwise = itos' n# cs
     where
     itos' :: Int# -> String -> String
     itos' n# cs
         | n# <# 10#  = C# (chr# (ord# '0'# +# n#)) : cs
         | otherwise = case chr# (ord# '0'# +# (n# `remInt#` 10#)) of { c#
 ->
               itos' (n# `quotInt#` 10#) (C# c# : cs) }
 }}}
 My suspicion is that the sign of one or both of these will be wrong:
 {{{
 Prelude> :set -fglasgow-exts
 Prelude> :m + GHC.Exts
 Prelude GHC.Exts> I# ((-9223372036854775808#) `remInt#` 10#)
 -8
 Prelude GHC.Exts> I# ((-9223372036854775808#) `quotInt#` 10#)
 -922337203685477580
 }}}
 Otherwise, reproducing the problem with the printing code in a module of
 its own, using `showSignedInt 0 minBound ""` (you'll need to import
 GHC.Exts, and possibly other modules, and the problem may be sensitive to
 commandline flags like `-fvia-C/-fasm`, `-O0/-O/-O2`) and then cutting it
 down to work out exactly which step gives the wrong answer may point in
 the direction of the problem.

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/1989#comment:3>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Tue Jan  1 10:05:41 2008
From: trac at galois.com (GHC)
Date: Tue Jan  1 09:59:50 2008
Subject: [GHC] #1992: 6.8.2 intermittent build failure on multiple OS X
 versions
In-Reply-To: <044.6e3d43e6297883ec96aae365685c0c7d@localhost>
References: <044.6e3d43e6297883ec96aae365685c0c7d@localhost>
Message-ID: <053.0fd7bcb2f2e2fcd1787cf157cef776f9@localhost>

#1992: 6.8.2 intermittent build failure on multiple OS X versions
----------------------+-----------------------------------------------------
 Reporter:  guest     |          Owner:          
     Type:  bug       |         Status:  new     
 Priority:  normal    |      Milestone:  6.8.3   
Component:  Compiler  |        Version:  6.8.2   
 Severity:  normal    |     Resolution:          
 Keywords:            |     Difficulty:  Unknown 
 Testcase:            |   Architecture:  Multiple
       Os:  MacOS X   |  
----------------------+-----------------------------------------------------
Changes (by igloo):

  * milestone:  => 6.8.3

Comment:

 Thanks for the report. Does running
 {{{
 ../compiler/stage1/ghc-inplace -M -optdep-f -optdep.depend-BASE  -osuf o
 -I../includes   -H16m -O -I/opt/local/include -I/usr/include
 -L/opt/local/lib -L/usr/lib -iutils -ibasicTypes -itypes -ihsSyn -iprelude
 -irename -itypecheck -ideSugar -icoreSyn -ivectorise -ispecialise
 -isimplCore -istranal -istgSyn -isimplStg -icodeGen -imain -iprofiling
 -iparser -icprAnalysis -indpFlatten -iiface -icmm -inativeGen -ighci -Wall
 -fno-warn-name-shadowing -fno-warn-orphans -Istage2 -package hpc -package
 bytestring -DGHCI -package template-haskell -DGHCI_TABLES_NEXT_TO_CODE
 -package readline -DUSE_READLINE -cpp -fglasgow-exts -fno-generics -Rghc-
 timing -I. -Iparser -package unix -package Cabal -ignore-package lang
 -recomp -Rghc-timing -H16M '-#include "cutils.h"' -package-name ghc-6.8.2
 -fgenerics basicTypes/BasicTypes.lhs basicTypes/DataCon.lhs
 basicTypes/Demand.lhs basicTypes/Id.lhs basicTypes/IdInfo.lhs
 basicTypes/Literal.lhs basicTypes/MkId.lhs basicTypes/Module.lhs
 basicTypes/Name.lhs basicTypes/NameEnv.lhs basicTypes/NameSet.lhs
 basicTypes/NewDemand.lhs basicTypes/OccName.lhs basicTypes/RdrName.lhs
 basicTypes/SrcLoc.lhs basicTypes/UniqSupply.lhs basicTypes/Unique.lhs
 basicTypes/Var.lhs basicTypes/VarEnv.lhs basicTypes/VarSet.lhs
 cmm/CLabel.hs cmm/Cmm.hs cmm/CmmBrokenBlock.hs cmm/CmmCPS.hs
 cmm/CmmCPSGen.hs cmm/CmmCallConv.hs cmm/CmmInfo.hs cmm/CmmLex.hs
 cmm/CmmLint.hs cmm/CmmLive.hs cmm/CmmOpt.hs cmm/CmmParse.hs
 cmm/CmmProcPoint.hs cmm/CmmUtils.hs cmm/Dataflow.hs cmm/MachOp.hs
 cmm/PprC.hs cmm/PprCmm.hs codeGen/Bitmap.hs codeGen/CgBindery.lhs
 codeGen/CgCallConv.hs codeGen/CgCase.lhs codeGen/CgClosure.lhs
 codeGen/CgCon.lhs codeGen/CgExpr.lhs codeGen/CgForeignCall.hs
 codeGen/CgHeapery.lhs codeGen/CgHpc.hs codeGen/CgInfoTbls.hs
 codeGen/CgLetNoEscape.lhs codeGen/CgMonad.lhs codeGen/CgParallel.hs
 codeGen/CgPrimOp.hs codeGen/CgProf.hs codeGen/CgStackery.lhs
 codeGen/CgTailCall.lhs codeGen/CgTicky.hs codeGen/CgUtils.hs
 codeGen/ClosureInfo.lhs codeGen/CodeGen.lhs codeGen/SMRep.lhs
 coreSyn/CoreFVs.lhs coreSyn/CoreLint.lhs coreSyn/CorePrep.lhs
 coreSyn/CoreSubst.lhs coreSyn/CoreSyn.lhs coreSyn/CoreTidy.lhs
 coreSyn/CoreUnfold.lhs coreSyn/CoreUtils.lhs coreSyn/ExternalCore.lhs
 coreSyn/MkExternalCore.lhs coreSyn/PprCore.lhs coreSyn/PprExternalCore.lhs
 cprAnalysis/CprAnalyse.lhs deSugar/Check.lhs deSugar/Coverage.lhs
 deSugar/Desugar.lhs deSugar/DsArrows.lhs deSugar/DsBinds.lhs
 deSugar/DsCCall.lhs deSugar/DsExpr.lhs deSugar/DsForeign.lhs
 deSugar/DsGRHSs.lhs deSugar/DsListComp.lhs deSugar/DsMeta.hs
 deSugar/DsMonad.lhs deSugar/DsUtils.lhs deSugar/Match.lhs
 deSugar/MatchCon.lhs deSugar/MatchLit.lhs ghci/ByteCodeAsm.lhs
 ghci/ByteCodeFFI.lhs ghci/ByteCodeGen.lhs ghci/ByteCodeInstr.lhs
 ghci/ByteCodeItbls.lhs ghci/ByteCodeLink.lhs ghci/Debugger.hs
 ghci/GhciMonad.hs ghci/GhciTags.hs ghci/InteractiveUI.hs ghci/Linker.lhs
 ghci/ObjLink.lhs ghci/RtClosureInspect.hs hsSyn/Convert.lhs
 hsSyn/HsBinds.lhs hsSyn/HsDecls.lhs hsSyn/HsDoc.hs hsSyn/HsExpr.lhs
 hsSyn/HsImpExp.lhs hsSyn/HsLit.lhs hsSyn/HsPat.lhs hsSyn/HsSyn.lhs
 hsSyn/HsTypes.lhs hsSyn/HsUtils.lhs iface/BinIface.hs iface/BuildTyCl.lhs
 iface/IfaceEnv.lhs iface/IfaceSyn.lhs iface/IfaceType.lhs
 iface/LoadIface.lhs iface/MkIface.lhs iface/TcIface.lhs main/BreakArray.hs
 main/CmdLineParser.hs main/CodeOutput.lhs main/Config.hs
 main/Constants.lhs main/DriverMkDepend.hs main/DriverPhases.hs
 main/DriverPipeline.hs main/DynFlags.hs main/ErrUtils.lhs main/Finder.lhs
 main/GHC.hs main/HeaderInfo.hs main/HscMain.lhs main/HscStats.lhs
 main/HscTypes.lhs main/InteractiveEval.hs main/Main.hs
 main/PackageConfig.hs main/Packages.lhs main/ParsePkgConf.hs
 main/PprTyThing.hs main/StaticFlags.hs main/SysTools.lhs main/TidyPgm.lhs
 nativeGen/AsmCodeGen.lhs nativeGen/GraphBase.hs nativeGen/GraphColor.hs
 nativeGen/GraphOps.hs nativeGen/GraphPpr.hs nativeGen/MachCodeGen.hs
 nativeGen/MachInstrs.hs nativeGen/MachRegs.lhs nativeGen/NCGMonad.hs
 nativeGen/PositionIndependentCode.hs nativeGen/PprMach.hs
 nativeGen/RegAllocColor.hs nativeGen/RegAllocInfo.hs
 nativeGen/RegAllocLinear.hs nativeGen/RegAllocStats.hs
 nativeGen/RegArchBase.hs nativeGen/RegArchX86.hs nativeGen/RegCoalesce.hs
 nativeGen/RegLiveness.hs nativeGen/RegSpill.hs nativeGen/RegSpillClean.hs
 nativeGen/RegSpillCost.hs ndpFlatten/FlattenInfo.hs
 ndpFlatten/FlattenMonad.hs ndpFlatten/Flattening.hs
 ndpFlatten/NDPCoreUtils.hs ndpFlatten/PArrAnal.hs parser/Ctype.lhs
 parser/HaddockLex.hs parser/HaddockParse.hs parser/HaddockUtils.hs
 parser/LexCore.hs parser/Lexer.hs parser/Parser.hs parser/ParserCore.hs
 parser/ParserCoreUtils.hs parser/RdrHsSyn.lhs prelude/ForeignCall.lhs
 prelude/PrelInfo.lhs prelude/PrelNames.lhs prelude/PrelRules.lhs
 prelude/PrimOp.lhs prelude/TysPrim.lhs prelude/TysWiredIn.lhs
 profiling/CostCentre.lhs profiling/SCCfinal.lhs rename/RnBinds.lhs
 rename/RnEnv.lhs rename/RnExpr.lhs rename/RnHsDoc.hs rename/RnHsSyn.lhs
 rename/RnNames.lhs rename/RnSource.lhs rename/RnTypes.lhs
 simplCore/CSE.lhs simplCore/FloatIn.lhs simplCore/FloatOut.lhs
 simplCore/LiberateCase.lhs simplCore/OccurAnal.lhs simplCore/SAT.lhs
 simplCore/SATMonad.lhs simplCore/SetLevels.lhs simplCore/SimplCore.lhs
 simplCore/SimplEnv.lhs simplCore/SimplMonad.lhs simplCore/SimplUtils.lhs
 simplCore/Simplify.lhs simplStg/SRT.lhs simplStg/SimplStg.lhs
 simplStg/StgStats.lhs specialise/Rules.lhs specialise/SpecConstr.lhs
 specialise/Specialise.lhs stgSyn/CoreToStg.lhs stgSyn/StgLint.lhs
 stgSyn/StgSyn.lhs stranal/DmdAnal.lhs stranal/SaAbsInt.lhs
 stranal/SaLib.lhs stranal/StrictAnal.lhs stranal/WorkWrap.lhs
 stranal/WwLib.lhs typecheck/FamInst.lhs typecheck/Inst.lhs
 typecheck/TcArrows.lhs typecheck/TcBinds.lhs typecheck/TcClassDcl.lhs
 typecheck/TcDefaults.lhs typecheck/TcDeriv.lhs typecheck/TcEnv.lhs
 typecheck/TcExpr.lhs typecheck/TcForeign.lhs typecheck/TcGadt.lhs
 typecheck/TcGenDeriv.lhs typecheck/TcHsSyn.lhs typecheck/TcHsType.lhs
 typecheck/TcInstDcls.lhs typecheck/TcMType.lhs typecheck/TcMatches.lhs
 typecheck/TcPat.lhs typecheck/TcRnDriver.lhs typecheck/TcRnMonad.lhs
 typecheck/TcRnTypes.lhs typecheck/TcRules.lhs typecheck/TcSimplify.lhs
 typecheck/TcSplice.lhs typecheck/TcTyClsDecls.lhs typecheck/TcTyDecls.lhs
 typecheck/TcTyFuns.lhs typecheck/TcType.lhs typecheck/TcUnify.lhs
 types/Class.lhs types/Coercion.lhs types/FamInstEnv.lhs types/FunDeps.lhs
 types/Generics.lhs types/InstEnv.lhs types/TyCon.lhs types/Type.lhs
 types/TypeRep.lhs types/Unify.lhs utils/Bag.lhs utils/Binary.hs
 utils/BufWrite.hs utils/Digraph.lhs utils/Encoding.hs utils/FastMutInt.lhs
 utils/FastString.lhs utils/FastTypes.lhs utils/FiniteMap.lhs
 utils/IOEnv.hs utils/ListSetOps.lhs utils/Maybes.lhs utils/OrdList.lhs
 utils/Outputable.lhs utils/Panic.lhs utils/Pretty.lhs utils/State.hs
 utils/StringBuffer.lhs utils/UniqFM.lhs utils/UniqSet.lhs utils/Util.lhs
 vectorise/VectBuiltIn.hs vectorise/VectCore.hs vectorise/VectMonad.hs
 vectorise/VectType.hs vectorise/VectUtils.hs vectorise/Vectorise.hs
 }}}
 by hand in `compiler/` reproduce the problem? It sounds like printing info
 from the internals of openFile, as you suggest, or looking at the
 equivalent of strace's output (ktrace on OS X, if I remember correctly),
 should shed some light.

 It's curious that I haven't seen anyone else report this. What sort of
 filesystem are you working on?

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/1992#comment:3>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Tue Jan  1 10:08:40 2008
From: trac at galois.com (GHC)
Date: Tue Jan  1 10:02:42 2008
Subject: [GHC] #1993: "RegAllocLinear.getStackSlotFor: out of stack
 slots" when compiling SHA1.hs in darcs
In-Reply-To: <047.e84806530b859709e5179210f10fbc2c@localhost>
References: <047.e84806530b859709e5179210f10fbc2c@localhost>
Message-ID: <056.66a1a36c86079a914149a06e35562fd0@localhost>

#1993: "RegAllocLinear.getStackSlotFor: out of stack slots" when compiling SHA1.hs
in darcs
----------------------+-----------------------------------------------------
 Reporter:  apstrand  |          Owner:         
     Type:  bug       |         Status:  new    
 Priority:  normal    |      Milestone:         
Component:  Compiler  |        Version:  6.8.2  
 Severity:  normal    |     Resolution:         
 Keywords:            |     Difficulty:  Unknown
 Testcase:            |   Architecture:  x86    
       Os:  Windows   |  
----------------------+-----------------------------------------------------
Old description:

> I got the following error when compiling darcs under win32/cygwin with
> ghc 6.8.2 and profiling turned on.
>
> $ make VERBOSE=1
> ghc -DPACKAGE_NAME=\"darcs\" -DPACKAGE_TARNAME=\"darcs\"
> -DPACKAGE_VERSION=\"2.0.0pre3\" -DPACKAGE_STRING=\"darcs\ 2.0.0pre3\"
> -DPACKAGE_BUGREPORT=\"bugs@darcs.net\" -DSTDC_HEADERS=1
> -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1
> -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1
> -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -Isrc/win32 -cpp
> -package regex-compat -package QuickCheck -package mtl -package parsec
> -package html -package containers -package pretty -O -funbox-strict-
> fields  -prof -auto-all -Wall -Werror -I. -I./src -i./src -isrc/win32
> -Isrc/win32 -DWIN32
> -DHAVE_MAPI -no-auto-all -funfolding-use-threshold20 -c src/SHA1.lhs
> ghc.exe: panic! (the 'impossible' happened)
>   (GHC version 6.8.2 for i386-unknown-mingw32):
>         RegAllocLinear.getStackSlotFor: out of stack slots
>
> Please report this as a GHC bug:  http://www.haskell.org/ghc/reportabug
>
> make: *** [src/SHA1.o] Error 1
>

> Context for the darcs version I tried to compile is attached.

New description:

 I got the following error when compiling darcs under win32/cygwin with ghc
 6.8.2 and profiling turned on.
 {{{
 $ make VERBOSE=1
 ghc -DPACKAGE_NAME=\"darcs\" -DPACKAGE_TARNAME=\"darcs\"
 -DPACKAGE_VERSION=\"2.0.0pre3\" -DPACKAGE_STRING=\"darcs\ 2.0.0pre3\"
 -DPACKAGE_BUGREPORT=\"bugs@darcs.net\" -DSTDC_HEADERS=1
 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1
 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1
 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -Isrc/win32 -cpp  -package regex-
 compat -package QuickCheck -package mtl -package parsec -package html
 -package containers -package pretty -O -funbox-strict-fields  -prof -auto-
 all -Wall -Werror -I. -I./src -i./src -isrc/win32 -Isrc/win32 -DWIN32
 -DHAVE_MAPI -no-auto-all -funfolding-use-threshold20 -c src/SHA1.lhs
 ghc.exe: panic! (the 'impossible' happened)
   (GHC version 6.8.2 for i386-unknown-mingw32):
         RegAllocLinear.getStackSlotFor: out of stack slots

 Please report this as a GHC bug:  http://www.haskell.org/ghc/reportabug

 make: *** [src/SHA1.o] Error 1
 }}}

 Context for the darcs version I tried to compile is attached.

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/1993#comment:2>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Tue Jan  1 10:59:27 2008
From: trac at galois.com (GHC)
Date: Tue Jan  1 10:53:30 2008
Subject: [GHC] #1993: "RegAllocLinear.getStackSlotFor: out of stack
 slots" when compiling SHA1.hs in darcs
In-Reply-To: <047.e84806530b859709e5179210f10fbc2c@localhost>
References: <047.e84806530b859709e5179210f10fbc2c@localhost>
Message-ID: <056.7628525568351a67c62205c662afaa6a@localhost>

#1993: "RegAllocLinear.getStackSlotFor: out of stack slots" when compiling SHA1.hs
in darcs
----------------------+-----------------------------------------------------
 Reporter:  apstrand  |          Owner:         
     Type:  bug       |         Status:  new    
 Priority:  normal    |      Milestone:  6.8.3  
Component:  Compiler  |        Version:  6.8.2  
 Severity:  normal    |     Resolution:         
 Keywords:            |     Difficulty:  Unknown
 Testcase:            |   Architecture:  x86    
       Os:  Windows   |  
----------------------+-----------------------------------------------------
Changes (by igloo):

  * milestone:  => 6.8.3

Comment:

 I've added a standalone example:
 {{{
 $ ghc -O -funbox-strict-fields -prof -funfolding-use-threshold20 -c
 SHA1.lhs
 ghc.exe: panic! (the 'impossible' happened)
   (GHC version 6.8.2 for i386-unknown-mingw32):
         RegAllocLinear.getStackSlotFor: out of stack slots

 Please report this as a GHC bug:  http://www.haskell.org/ghc/reportabug
 }}}

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/1993#comment:3>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Tue Jan  1 11:41:55 2008
From: trac at galois.com (GHC)
Date: Tue Jan  1 11:36:31 2008
Subject: [GHC] #1999: panic with GADT etc.
In-Reply-To: <046.74c6dc616261a913ffd4180fb00731f0@localhost>
References: <046.74c6dc616261a913ffd4180fb00731f0@localhost>
Message-ID: <055.0ed2c0010def488e22c88748affab9ff@localhost>

#1999: panic with GADT etc.
----------------------+-----------------------------------------------------
 Reporter:  jeltsch   |          Owner:             
     Type:  bug       |         Status:  new        
 Priority:  normal    |      Milestone:  6.10 branch
Component:  Compiler  |        Version:  6.9        
 Severity:  normal    |     Resolution:             
 Keywords:            |     Difficulty:  Unknown    
 Testcase:            |   Architecture:  x86        
       Os:  Linux     |  
----------------------+-----------------------------------------------------
Changes (by igloo):

  * milestone:  => 6.10 branch

Comment:

 Thanks for the report! This works in 6.8.2.

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/1999#comment:1>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Tue Jan  1 11:46:55 2008
From: trac at galois.com (GHC)
Date: Tue Jan  1 11:40:58 2008
Subject: [GHC] #2000: -funfolding-update-in-place badly documented
In-Reply-To: <045.ac76dc598481f3a493531a6d155a8b48@localhost>
References: <045.ac76dc598481f3a493531a6d155a8b48@localhost>
Message-ID: <054.e8dc6b8ae6eacfa820debc05de574e39@localhost>

#2000: -funfolding-update-in-place badly documented
----------------------+-----------------------------------------------------
 Reporter:  m4dc4p    |          Owner:  igloo  
     Type:  bug       |         Status:  new    
 Priority:  normal    |      Milestone:  6.8.3  
Component:  Compiler  |        Version:  6.8.1  
 Severity:  normal    |     Resolution:         
 Keywords:            |     Difficulty:  Unknown
 Testcase:            |   Architecture:  x86    
       Os:  Windows   |  
----------------------+-----------------------------------------------------
Changes (by igloo):

  * owner:  => igloo
  * milestone:  => 6.8.3

Comment:

 Thanks for the report, you are right. I'll fix the docs.

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/2000#comment:3>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Tue Jan  1 11:53:06 2008
From: trac at galois.com (GHC)
Date: Tue Jan  1 11:47:08 2008
Subject: [GHC] #2001: panic when recompiling after ctrl-C leaves .o
 without .hi
In-Reply-To: <051.a9f35addcc3c7bb910990fccf4192860@localhost>
References: <051.a9f35addcc3c7bb910990fccf4192860@localhost>
Message-ID: <060.f7463048d08a12ee57f77c9255cbe356@localhost>

#2001: panic when recompiling after ctrl-C leaves .o without .hi
--------------------------+-------------------------------------------------
 Reporter:  Isaac Dupree  |          Owner:         
     Type:  bug           |         Status:  closed 
 Priority:  normal        |      Milestone:         
Component:  Compiler      |        Version:  6.8.2  
 Severity:  minor         |     Resolution:  wontfix
 Keywords:                |     Difficulty:  Unknown
 Testcase:                |   Architecture:  x86    
       Os:  Linux         |  
--------------------------+-------------------------------------------------
Changes (by igloo):

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

Comment:

 GHC can't just recompile the other module as it's being used in one-file
 mode, so it doesn't know what command line flags should be used for the
 other module. Even if it did, I don't think it should recompile
 dependencies if you don't use `--make`.

 Thanks

 Ian

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/2001#comment:1>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Tue Jan  1 12:10:53 2008
From: trac at galois.com (GHC)
Date: Tue Jan  1 12:04:54 2008
Subject: [GHC] #2002: problems with very large (list) literals
In-Reply-To: <051.64c621f5afc3e8cbd43368bfecf19488@localhost>
References: <051.64c621f5afc3e8cbd43368bfecf19488@localhost>
Message-ID: <060.a49cf70449eea5b62f288add0d01e04d@localhost>

#2002: problems with very large (list) literals
--------------------------+-------------------------------------------------
 Reporter:  Isaac Dupree  |          Owner:         
     Type:  bug           |         Status:  new    
 Priority:  high          |      Milestone:  6.8.3  
Component:  Compiler      |        Version:  6.8.2  
 Severity:  normal        |     Resolution:         
 Keywords:                |     Difficulty:  Unknown
 Testcase:                |   Architecture:  x86    
       Os:  Linux         |  
--------------------------+-------------------------------------------------
Changes (by igloo):

  * priority:  normal => high
  * milestone:  => 6.8.3

Comment:

 It sounds like this could be a regression, so I've marked it as high
 priority.

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/2002#comment:1>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Tue Jan  1 12:34:57 2008
From: trac at galois.com (GHC)
Date: Tue Jan  1 12:28:58 2008
Subject: [GHC] #2004: Pattern matching against GADTs without -XGADTs has
 odd behavior.
In-Reply-To: <044.b468022ed3fa4097df9a462be70e8e2e@localhost>
References: <044.b468022ed3fa4097df9a462be70e8e2e@localhost>
Message-ID: <053.1c263b9fb21d61d83605ff377583c4b9@localhost>

#2004: Pattern matching against GADTs without -XGADTs has odd behavior.
-------------------------------------+--------------------------------------
 Reporter:  guest                    |          Owner:  simonpj    
     Type:  bug                      |         Status:  new        
 Priority:  normal                   |      Milestone:  6.10 branch
Component:  Compiler (Type checker)  |        Version:  6.8.1      
 Severity:  normal                   |     Resolution:             
 Keywords:                           |     Difficulty:  Unknown    
 Testcase:                           |   Architecture:  Unknown    
       Os:  Unknown                  |  
-------------------------------------+--------------------------------------
Changes (by igloo):

  * owner:  => simonpj
  * milestone:  => 6.10 branch

Comment:

 Simon, is this the expected behaviour?

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/2004#comment:1>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Tue Jan  1 13:50:42 2008
From: trac at galois.com (GHC)
Date: Tue Jan  1 13:44:44 2008
Subject: [GHC] #2006: unreachable GADT pattern clauses show up as
 warnings with -Wall
In-Reply-To: <044.a004885c928a62e2a73bf12df457c462@localhost>
References: <044.a004885c928a62e2a73bf12df457c462@localhost>
Message-ID: <053.ea686eb12159db53a8578bcea26b247e@localhost>

#2006: unreachable GADT pattern clauses show up as warnings with -Wall
----------------------+-----------------------------------------------------
 Reporter:  ryani     |          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: <http://hackage.haskell.org/trac/ghc/ticket/2006#comment:1>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Tue Jan  1 13:55:27 2008
From: trac at galois.com (GHC)
Date: Tue Jan  1 13:49:33 2008
Subject: [GHC] #2007: :main deals poorly with \escape characters
In-Reply-To: <051.31a1f2da1e7713c9cec48de31e4dfc28@localhost>
References: <051.31a1f2da1e7713c9cec48de31e4dfc28@localhost>
Message-ID: <060.d0fa383aad44d6d3c3844aa269dd0850@localhost>

#2007: :main deals poorly with \escape characters
--------------------------+-------------------------------------------------
 Reporter:  NeilMitchell  |          Owner:             
     Type:  bug           |         Status:  new        
 Priority:  normal        |      Milestone:  6.10 branch
Component:  GHCi          |        Version:  6.9        
 Severity:  normal        |     Resolution:             
 Keywords:                |     Difficulty:  Unknown    
 Testcase:                |   Architecture:  Unknown    
       Os:  Unknown       |  
--------------------------+-------------------------------------------------
Changes (by igloo):

  * milestone:  => 6.10 branch

Comment:

 I'd prefer that it worked more like a shell, i.e. in
 {{{
 :main foo bar
 :main "foo bar"
 :main "foo\nbar"
 }}}
 the first call has 2 arguments and the latter 2 have 1.

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/2007#comment:1>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Tue Jan  1 14:21:23 2008
From: trac at galois.com (GHC)
Date: Tue Jan  1 14:15:25 2008
Subject: [GHC] #2010: out of stack slots
In-Reply-To: <051.e72c7b92923d8544c2af0d69efb8bb0f@localhost>
References: <051.e72c7b92923d8544c2af0d69efb8bb0f@localhost>
Message-ID: <060.629be9062ade8d2637ed3e4ba4789f59@localhost>

#2010: out of stack slots
--------------------------+-------------------------------------------------
 Reporter:  jim.stuttard  |          Owner:           
     Type:  bug           |         Status:  closed   
 Priority:  normal        |      Milestone:           
Component:  Compiler      |        Version:  6.8.2    
 Severity:  normal        |     Resolution:  duplicate
 Keywords:                |     Difficulty:  Unknown  
 Testcase:                |   Architecture:  x86      
       Os:  Unknown       |  
--------------------------+-------------------------------------------------
Changes (by igloo):

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

Comment:

 Thanks for the report! I'm closing this ticket as it's a duplicate of
 #1993.

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/2010#comment:1>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Tue Jan  1 14:23:07 2008
From: trac at galois.com (GHC)
Date: Tue Jan  1 14:17:08 2008
Subject: [GHC] #1986: runhaskell doesn't have a --version option
In-Reply-To: <042.44d90b1d57525d17b12ffab59d5bba78@localhost>
References: <042.44d90b1d57525d17b12ffab59d5bba78@localhost>
Message-ID: <051.79e58a1a7963c66398d70d2744e180ca@localhost>

#1986: runhaskell doesn't have a --version option
-----------------------------+----------------------------------------------
 Reporter:  tim              |          Owner:             
     Type:  feature request  |         Status:  new        
 Priority:  normal           |      Milestone:  6.10 branch
Component:  Compiler         |        Version:  6.9        
 Severity:  minor            |     Resolution:             
 Keywords:                   |     Difficulty:  Unknown    
 Testcase:                   |   Architecture:  Unknown    
       Os:  Unknown          |  
-----------------------------+----------------------------------------------
Changes (by igloo):

  * milestone:  => 6.10 branch

Comment:

 Thanks for the report. In an ideal world `runhaskell --help` would only
 mention the portable flags.

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/1986#comment:1>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Tue Jan  1 14:28:34 2008
From: trac at galois.com (GHC)
Date: Tue Jan  1 14:23:10 2008
Subject: [GHC] #2005: localhost on mac causes getnameinfo error in
 safari.
In-Reply-To: <043.2e0e6309ca162e2f7e3751b621e7afca@localhost>
References: <043.2e0e6309ca162e2f7e3751b621e7afca@localhost>
Message-ID: <052.8e28d7859a87679065abb6efc28174ef@localhost>

#2005: localhost on mac causes getnameinfo error in safari.
------------------------------------+---------------------------------------
 Reporter:  alex                    |          Owner:            
     Type:  bug                     |         Status:  new       
 Priority:  normal                  |      Milestone:  6.8 branch
Component:  libraries/network       |        Version:  6.8.2     
 Severity:  normal                  |     Resolution:            
 Keywords:  network localhost ipv6  |     Difficulty:  Unknown   
 Testcase:                          |   Architecture:  x86       
       Os:  MacOS X                 |  
------------------------------------+---------------------------------------
Changes (by igloo):

 * cc: therp, allbery_b (removed)

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/2005#comment:2>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Tue Jan  1 15:55:45 2008
From: trac at galois.com (GHC)
Date: Tue Jan  1 15:49:47 2008
Subject: [GHC] #2007: :main deals poorly with \escape characters
In-Reply-To: <051.31a1f2da1e7713c9cec48de31e4dfc28@localhost>
References: <051.31a1f2da1e7713c9cec48de31e4dfc28@localhost>
Message-ID: <060.eb2e0a2666e615e84834036aebb0d617@localhost>

#2007: :main deals poorly with \escape characters
--------------------------+-------------------------------------------------
 Reporter:  NeilMitchell  |          Owner:             
     Type:  bug           |         Status:  new        
 Priority:  normal        |      Milestone:  6.10 branch
Component:  GHCi          |        Version:  6.9        
 Severity:  normal        |     Resolution:             
 Keywords:                |     Difficulty:  Unknown    
 Testcase:                |   Architecture:  Unknown    
       Os:  Unknown       |  
--------------------------+-------------------------------------------------
Comment (by NeilMitchell):

 Using "quotes" to group arguments is definately a good idea. Treating \n
 as a newline rather than the literal slash followed by n follows the Linux
 behaviour, but would probably be a bit annoying for Windows users. Ideally
 the syntax for :main should be identical to the system shell - whatever
 that may be. Is it too frustrating to have the same command behave
 differently depending on your OS?

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/2007#comment:2>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Tue Jan  1 16:54:11 2008
From: trac at galois.com (GHC)
Date: Tue Jan  1 16:48:13 2008
Subject: [GHC] #2007: :main deals poorly with \escape characters
In-Reply-To: <051.31a1f2da1e7713c9cec48de31e4dfc28@localhost>
References: <051.31a1f2da1e7713c9cec48de31e4dfc28@localhost>
Message-ID: <060.363f1fe0e1fedb781d618937a7147a8e@localhost>

#2007: :main deals poorly with \escape characters
--------------------------+-------------------------------------------------
 Reporter:  NeilMitchell  |          Owner:             
     Type:  bug           |         Status:  new        
 Priority:  normal        |      Milestone:  6.10 branch
Component:  GHCi          |        Version:  6.9        
 Severity:  normal        |     Resolution:             
 Keywords:                |     Difficulty:  Unknown    
 Testcase:                |   Architecture:  Unknown    
       Os:  Unknown       |  
--------------------------+-------------------------------------------------
Comment (by igloo):

 I was thinking that if an argument began with " then we would parse it as
 a Haskell string, and otherwise we would do something like `break
 isWhite`.

 Trying to emulate the system shell sounds far too difficult to me.

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/2007#comment:3>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Tue Jan  1 17:35:43 2008
From: trac at galois.com (GHC)
Date: Tue Jan  1 17:29:43 2008
Subject: [GHC] #2001: panic when recompiling after ctrl-C leaves .o
 without .hi
In-Reply-To: <051.a9f35addcc3c7bb910990fccf4192860@localhost>
References: <051.a9f35addcc3c7bb910990fccf4192860@localhost>
Message-ID: <060.60e24dc3172c5396dc194d46d5cff989@localhost>

#2001: panic when recompiling after ctrl-C leaves .o without .hi
--------------------------+-------------------------------------------------
 Reporter:  Isaac Dupree  |          Owner:         
     Type:  bug           |         Status:  closed 
 Priority:  normal        |      Milestone:         
Component:  Compiler      |        Version:  6.8.2  
 Severity:  minor         |     Resolution:  wontfix
 Keywords:                |     Difficulty:  Unknown
 Testcase:                |   Architecture:  x86    
       Os:  Linux         |  
--------------------------+-------------------------------------------------
Comment (by Isaac Dupree):

 oh, I see, it was not CmmSpillReload that was being recompiled, but
 something that depends on it, and it was GHC-HEAD's Makefile system
 getting confused.  I'm not sure if it should be called "Panic!" though --
 I thought that was only for conditions that were supposed to be impossible
 given a correct GHC build?

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/2001#comment:2>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Tue Jan  1 17:42:39 2008
From: trac at galois.com (GHC)
Date: Tue Jan  1 17:36:41 2008
Subject: [GHC] #2002: problems with very large (list) literals
In-Reply-To: <051.64c621f5afc3e8cbd43368bfecf19488@localhost>
References: <051.64c621f5afc3e8cbd43368bfecf19488@localhost>
Message-ID: <060.f730c1ec41a276607649f4e698199163@localhost>

#2002: problems with very large (list) literals
--------------------------+-------------------------------------------------
 Reporter:  Isaac Dupree  |          Owner:         
     Type:  bug           |         Status:  new    
 Priority:  high          |      Milestone:  6.8.3  
Component:  Compiler      |        Version:  6.8.2  
 Severity:  normal        |     Resolution:         
 Keywords:                |     Difficulty:  Unknown
 Testcase:                |   Architecture:  x86    
       Os:  Linux         |  
--------------------------+-------------------------------------------------
Comment (by Isaac Dupree):

 Could be. Compared to 6.6, though, it's not really a regression, in fact
 it's an improvement (in 6.6.1 no amount of memory will allow it to finish
 -- I think that might have been a quadratic-behavior bug that was fixed.
 I don't think "stack overflow" is really a regression from "fails to
 terminate on valid code"?)

 As for the second part of my report (large alex files), I haven't tested
 it with 6.6.1, but I'm sure it wouldn't terminate, since in 6.6.1 the
 large list literals alone would ensure that.

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/2002#comment:2>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Tue Jan  1 17:56:11 2008
From: trac at galois.com (GHC)
Date: Tue Jan  1 17:50:13 2008
Subject: [GHC] #2007: :main deals poorly with \escape characters
In-Reply-To: <051.31a1f2da1e7713c9cec48de31e4dfc28@localhost>
References: <051.31a1f2da1e7713c9cec48de31e4dfc28@localhost>
Message-ID: <060.4491d49a016c2f1327aa18fcbc9732f8@localhost>

#2007: :main deals poorly with \escape characters
--------------------------+-------------------------------------------------
 Reporter:  NeilMitchell  |          Owner:             
     Type:  bug           |         Status:  new        
 Priority:  normal        |      Milestone:  6.10 branch
Component:  GHCi          |        Version:  6.9        
 Severity:  normal        |     Resolution:             
 Keywords:                |     Difficulty:  Unknown    
 Testcase:                |   Architecture:  Unknown    
       Os:  Unknown       |  
--------------------------+-------------------------------------------------
Comment (by NeilMitchell):

 What would `:main "foo" "bar"` give? If we parse it as a Haskell string,
 it does need to be a sequence of Haskell strings. What about `:main bar
 foo "foo bar"`?

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/2007#comment:4>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Tue Jan  1 19:48:04 2008
From: trac at galois.com (GHC)
Date: Tue Jan  1 19:42:05 2008
Subject: [GHC] #2008: GHCi takes increasingly more memory
In-Reply-To: <051.6d649c23331d31238e1b16c9a01068ae@localhost>
References: <051.6d649c23331d31238e1b16c9a01068ae@localhost>
Message-ID: <060.f8457f26fff2c2c74124bbff9373093a@localhost>

#2008: GHCi takes increasingly more memory
--------------------------+-------------------------------------------------
 Reporter:  NeilMitchell  |          Owner:             
     Type:  bug           |         Status:  new        
 Priority:  normal        |      Milestone:  6.10 branch
Component:  GHCi          |        Version:  6.9        
 Severity:  normal        |     Resolution:             
 Keywords:                |     Difficulty:  Unknown    
 Testcase:                |   Architecture:  Unknown    
       Os:  Windows       |  
--------------------------+-------------------------------------------------
Changes (by igloo):

  * milestone:  => 6.10 branch

Comment:

 After 5.5 hours, with GHC 6.8.2 and Windows XP, I see no difference in any
 of the virtual or physical memory figures in process explorer, or in the
 memory usage reported by task manager.

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/2008#comment:2>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Tue Jan  1 19:51:46 2008
From: trac at galois.com (GHC)
Date: Tue Jan  1 19:45:49 2008
Subject: [GHC] #2003: The Data.Time.Format parser should be more liberal
In-Reply-To: <054.afa516df5a0125b80d39ff7f1a5eecb2@localhost>
References: <054.afa516df5a0125b80d39ff7f1a5eecb2@localhost>
Message-ID: <063.9d63aef6da00f71efdbdc718631178c3@localhost>

#2003: The Data.Time.Format parser should be more liberal
-------------------------------+--------------------------------------------
 Reporter:  BjornBuckwalter    |          Owner:         
     Type:  feature request    |         Status:  new    
 Priority:  normal             |      Milestone:  Not GHC
Component:  libraries (other)  |        Version:         
 Severity:  normal             |     Resolution:         
 Keywords:                     |     Difficulty:  Unknown
 Testcase:                     |   Architecture:  Unknown
       Os:  Unknown            |  
-------------------------------+--------------------------------------------
Changes (by igloo):

  * milestone:  => Not GHC

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/2003#comment:1>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Wed Jan  2 06:20:53 2008
From: trac at galois.com (GHC)
Date: Wed Jan  2 06:15:22 2008
Subject: [GHC] #2005: localhost on mac causes getnameinfo error in
 safari.
In-Reply-To: <043.2e0e6309ca162e2f7e3751b621e7afca@localhost>
References: <043.2e0e6309ca162e2f7e3751b621e7afca@localhost>
Message-ID: <052.7c9dbaf364a0353bb5b20f0549ed178c@localhost>

#2005: localhost on mac causes getnameinfo error in safari.
------------------------------------+---------------------------------------
 Reporter:  alex                    |          Owner:         
     Type:  bug                     |         Status:  new    
 Priority:  normal                  |      Milestone:  Not GHC
Component:  libraries/network       |        Version:  6.8.2  
 Severity:  normal                  |     Resolution:         
 Keywords:  network localhost ipv6  |     Difficulty:  Unknown
 Testcase:                          |   Architecture:  x86    
       Os:  MacOS X                 |  
------------------------------------+---------------------------------------
Changes (by igloo):

  * milestone:  6.8 branch => Not GHC

Comment:

 Ooops, milestone should be Not GHC as network isn't a bootlib.

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/2005#comment:3>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Wed Jan  2 06:23:25 2008
From: trac at galois.com (GHC)
Date: Wed Jan  2 06:17:25 2008
Subject: [GHC] #2007: :main deals poorly with \escape characters
In-Reply-To: <051.31a1f2da1e7713c9cec48de31e4dfc28@localhost>
References: <051.31a1f2da1e7713c9cec48de31e4dfc28@localhost>
Message-ID: <060.3f91b0cd4927ee2fda4deb6b39eca120@localhost>

#2007: :main deals poorly with \escape characters
--------------------------+-------------------------------------------------
 Reporter:  NeilMitchell  |          Owner:             
     Type:  bug           |         Status:  new        
 Priority:  normal        |      Milestone:  6.10 branch
Component:  GHCi          |        Version:  6.9        
 Severity:  normal        |     Resolution:             
 Keywords:                |     Difficulty:  Unknown    
 Testcase:                |   Architecture:  Unknown    
       Os:  Unknown       |  
--------------------------+-------------------------------------------------
Comment (by igloo):

 `getArgs` would return `["foo", "bar"]` and `["bar", "foo", "foo bar"]`.

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/2007#comment:5>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Wed Jan  2 07:10:20 2008
From: trac at galois.com (GHC)
Date: Wed Jan  2 07:04:30 2008
Subject: [GHC] #1845: unconditional relative branch out of range (GHC
 version 6.8.1 for powerpc_apple_darwin)
In-Reply-To: <044.65389402080b2ab045a1b2fde12245f8@localhost>
References: <044.65389402080b2ab045a1b2fde12245f8@localhost>
Message-ID: <053.b41eaeaabb6b3c68e61764ef855bbbec@localhost>

#1845: unconditional relative branch out of range (GHC version 6.8.1 for
powerpc_apple_darwin)
---------------------+------------------------------------------------------
 Reporter:  guest    |          Owner:  thorkilnaur
     Type:  bug      |         Status:  new        
 Priority:  normal   |      Milestone:  6.8.3      
Component:  GHCi     |        Version:  6.8.1      
 Severity:  normal   |     Resolution:             
 Keywords:           |     Difficulty:  Unknown    
 Testcase:           |   Architecture:  powerpc    
       Os:  MacOS X  |  
---------------------+------------------------------------------------------
Comment (by maeder):

 Just adding `-mlongcall` to `extra-gcc-opts` did not help. When trying to
 compile with

 {{{
 SRC_HC_OPTS += -fvia-C
 }}}

 in `mk/build.mk` I got the following error:

 {{{
  ../compiler/ghc-inplace -H16m -O -fvia-C -optc-O2 -package-name rts
 -static -I../gmp/gmpbuild -I. -#include HCIncludes.h -dcmm-lint     -c
 Apply.cmm -o Apply.o
 /tmp/ghc24169_0/ghc24169_0.s:unknown:Undefined local symbol
 L___DISCARD__$stub
 make[1]: *** [Apply.o] Error 1
 make: *** [stage1] Error 1
 }}}

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/1845#comment:8>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Wed Jan  2 07:33:51 2008
From: trac at galois.com (GHC)
Date: Wed Jan  2 07:27:52 2008
Subject: [GHC] #1998: Stricter enumFrom instance for Integer,
 to match Int
In-Reply-To: <043.376380d7218ee2804ccca585f66a35df@localhost>
References: <043.376380d7218ee2804ccca585f66a35df@localhost>
Message-ID: <052.d74a25c5d8042c741247ce48e4e9d1e6@localhost>

#1998: Stricter enumFrom instance for Integer, to match Int
---------------------------------+------------------------------------------
 Reporter:  dons                 |          Owner:             
     Type:  bug                  |         Status:  closed     
 Priority:  normal               |      Milestone:  6.8.3      
Component:  libraries/base       |        Version:  6.8.2      
 Severity:  normal               |     Resolution:  duplicate  
 Keywords:  Integer, strictness  |     Difficulty:  Easy (1 hr)
 Testcase:                       |   Architecture:  Multiple   
       Os:  Multiple             |  
---------------------------------+------------------------------------------
Changes (by simonmar):

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

Comment:

 #1997 is now a bug report, so closing this one.

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/1998#comment:1>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Wed Jan  2 07:44:53 2008
From: trac at galois.com (GHC)
Date: Wed Jan  2 07:38:51 2008
Subject: [GHC] #2011: [6.8.1 regression] panic: lookupVers1 base:GHC.Prim
 sym{tc}
Message-ID: <047.5794bcb02e44dfb8bb70a89a113f27e3@localhost>

#2011: [6.8.1 regression] panic: lookupVers1 base:GHC.Prim sym{tc}
-------------------------+--------------------------------------------------
    Reporter:  simonmar  |       Owner:  simonpj
        Type:  bug       |      Status:  new    
    Priority:  high      |   Milestone:  6.8.3  
   Component:  Compiler  |     Version:  6.8.2  
    Severity:  normal    |    Keywords:         
  Difficulty:  Unknown   |    Testcase:         
Architecture:  Unknown   |          Os:  Unknown
-------------------------+--------------------------------------------------
 When rebuilding the base package you might encounter this:

 {{{
 ../../compiler/stage1/ghc-inplace -package-name base-3.0.1.0 -hide-all-
 packages -split-objs -i -idist/build/autogen -idist/build -i. -Idist/build
 -Iinclude -#include "HsBase.h" -odir dist/build -hidir dist/build -stubdir
 dist/build -package rts-1.0 -O -fglasgow-exts -package-name base -XCPP
 -idist/build  -H16m -O -O -Rghc-timing -fgenerics -c
 Data/Generics/Twins.hs -o dist/build/Data/Generics/Twins.o  -ohi
 dist/build/Data/Generics/Twins.hi
 ghc-6.8.2: panic! (the 'impossible' happened)
   (GHC version 6.8.2 for powerpc-apple-darwin):
         lookupVers1 base:GHC.Prim sym{tc}
 }}}

 Workaround is to clean in `libraries/base`.

 The problem is that `MkIface.computeChangedOccs` needs to avoid wired-in
 names when checking version numbers, because wired-in names are never
 mentioned in usages.

 I believe simonpj has a patch for this in his working tree, we diagnosed
 it before disappearing for the Christmas period.

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/2011>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Wed Jan  2 07:54:01 2008
From: trac at galois.com (GHC)
Date: Wed Jan  2 07:48:09 2008
Subject: [GHC] #2012: compiling via-C does not work on ppc
Message-ID: <045.6ad3ccd84b7b179a5baec1657fb43453@localhost>

#2012: compiling via-C does not work on ppc
-------------------------+--------------------------------------------------
    Reporter:  maeder    |       Owner:         
        Type:  bug       |      Status:  new    
    Priority:  normal    |   Milestone:         
   Component:  Compiler  |     Version:  6.8.2  
    Severity:  normal    |    Keywords:         
  Difficulty:  Unknown   |    Testcase:         
Architecture:  powerpc   |          Os:  MacOS X
-------------------------+--------------------------------------------------
 building ghc-6.8.2 on ppc Mac OS X 10.4 (Tiger) with "`SRC_HC_OPTS +=
 -fvia-C`" (see #1845) yields:

 {{{
 ../compiler/ghc-inplace -H16m -O -fvia-C -keep-tmp-files -optc-O2
 -package-name rts -static -I../gmp/gmpbuild -I. -#include HCIncludes.h
 -dcmm-lint     -c Apply.cmm -o Apply.o
 /tmp/ghc24131_0/ghc24131_0.s:unknown:Undefined local symbol
 L___DISCARD__$stub
 make[1]: *** [Apply.o] Error 1
 make: *** [stage1] Error 1
 }}}

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/2012>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Wed Jan  2 08:54:15 2008
From: trac at galois.com (GHC)
Date: Wed Jan  2 08:48:14 2008
Subject: [GHC] #1509: Make unboxed tuples more supported
In-Reply-To: <044.1f30aaa9c80145fa2207f4959b5f6c5d@localhost>
References: <044.1f30aaa9c80145fa2207f4959b5f6c5d@localhost>
Message-ID: <053.b6f95c7ec34d45e37a514ce3898e8007@localhost>

#1509: Make unboxed tuples more supported
-----------------------------+----------------------------------------------
 Reporter:  guest            |          Owner:         
     Type:  feature request  |         Status:  new    
 Priority:  low              |      Milestone:  _|_    
Component:  Compiler         |        Version:  6.6.1  
 Severity:  minor            |     Resolution:         
 Keywords:                   |     Difficulty:  Unknown
 Testcase:                   |   Architecture:  Unknown
       Os:  Unknown          |  
-----------------------------+----------------------------------------------
Comment (by Isaac Dupree):

 Adding prefix-unboxed-tuples turned out to just require a parser
 modification -- for GHC at least, Data.Tuple only defines data types and
 constructors (and Eq,Ord... instances) of (boxed) tuples; unboxed tuples
 were already built-in, (or anyway my test passed and ran successfully
 after a simple parser addition).  see darcs patches on cvs-ghc list.

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/1509#comment:2>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From Christian.Maeder at dfki.de  Wed Jan  2 09:39:36 2008
From: Christian.Maeder at dfki.de (Christian Maeder)
Date: Wed Jan  2 09:33:39 2008
Subject: Problem building hdbc-sqlite3 with ghc 6.8.2
In-Reply-To: <49E913CA-C853-451A-9E6C-FA460EFC6B39@citycampus.com>
References: <49E913CA-C853-451A-9E6C-FA460EFC6B39@citycampus.com>
Message-ID: <477BA228.9030406@dfki.de>

manu wrote:
> hello,
> 
> has anybody managed to build hdbc-sqlite3 with ghc 6.8.2 ?
> 
> I get the following error :
> 
> Macintosh:HDBC-sqlite3-1.1.3.0 manu$ runhaskell Setup.lhs build
> Preprocessing library HDBC-sqlite3-1.1.3.0...
> ghc-6.8.2: unrecognised flags: -F/Users/manu/Library/Frameworks
> Usage: For basic information, try the `--help' option.
> compiling dist/build/Database/HDBC/Sqlite3/Statement_hsc_make.c failed
> command was: /usr/local/bin/ghc -c -package base-3.0.1.0 -package
> mtl-1.1.0.0 -package HDBC-1.1.3 -I. -F/Users/manu/Library/Frameworks
> dist/build/Database/HDBC/Sqlite3/Statement_hsc_make.c -o
> dist/build/Database/HDBC/Sqlite3/Statement_hsc_make.o
> 
> 
> if somebody has an idea...

I seems you used my binary dist that I made with a modified
utils/hsc2hs/Main.hs
http://article.gmane.org/gmane.comp.lang.haskell.glasgow.user/13583
http://hackage.haskell.org/trac/ghc/ticket/1395

hsc2hs only worked for me when gcc was used instead ghc (when
bootstrapping ghc-6.8.2 itself). Maybe I should build new binary-dists.
Is it for ppc or x86?

Cheers Christian
From trac at galois.com  Wed Jan  2 10:24:16 2008
From: trac at galois.com (GHC)
Date: Wed Jan  2 10:18:30 2008
Subject: [GHC] #1395: let ./configure check for a GNUreadline framework
In-Reply-To: <052.068bc0f583c08a182f51a06ad4864715@localhost>
References: <052.068bc0f583c08a182f51a06ad4864715@localhost>
Message-ID: <061.312f7bafe14fca64aef2af819b46ec0c@localhost>

#1395: let ./configure check for a GNUreadline framework
-----------------------------+----------------------------------------------
 Reporter:  maeder@tzi.de    |          Owner:             
     Type:  feature request  |         Status:  reopened   
 Priority:  normal           |      Milestone:  6.8 branch 
Component:  Build System     |        Version:  6.8        
 Severity:  normal           |     Resolution:             
 Keywords:                   |     Difficulty:  Easy (1 hr)
 Testcase:                   |   Architecture:  Multiple   
       Os:  MacOS X          |  
-----------------------------+----------------------------------------------
Comment (by maeder):

 My modification of `utils/hsc2hs/Main.hs` (probably) caused the problem
 reported in
 http://article.gmane.org/gmane.comp.lang.haskell.cafe/34373

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/1395#comment:25>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Wed Jan  2 10:51:21 2008
From: trac at galois.com (GHC)
Date: Wed Jan  2 10:45:20 2008
Subject: [GHC] #1997: Stricter enumFrom instance for Integer,
 to match Int
In-Reply-To: <043.bda0d5ecfd811d8fda5e74a0019c2fae@localhost>
References: <043.bda0d5ecfd811d8fda5e74a0019c2fae@localhost>
Message-ID: <052.f385347f924ca8f405f11443dedc8b2c@localhost>

#1997: Stricter enumFrom instance for Integer, to match Int
----------------------------+-----------------------------------------------
 Reporter:  dons            |          Owner:             
     Type:  bug             |         Status:  new        
 Priority:  normal          |      Milestone:  6.10 branch
Component:  libraries/base  |        Version:  6.8.2      
 Severity:  normal          |     Resolution:             
 Keywords:                  |     Difficulty:  Easy (1 hr)
 Testcase:                  |   Architecture:  Multiple   
       Os:  Multiple        |  
----------------------------+-----------------------------------------------
Changes (by simonmar):

  * milestone:  Not GHC => 6.10 branch

Comment:

 Note that this was reported already in #1097, but it got forgotten
 probably because it has a milestone of "Not GHC" and no deadline.

 The Haskell 98 report has a bug (already documented in
 [http://haskell.org/definition/haskell98-revised-bugs.html]) in that the
 reference implementation of the `Enum` class for `Float` and `Double` is
 lazy.

 I suggest we do as Don suggests, and make all the numeric types behave
 consistently with respect to strictness of `enumFrom*`.

 (re-milestoning to 6.10 so we don't forget)

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/1997#comment:3>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Wed Jan  2 10:52:26 2008
From: trac at galois.com (GHC)
Date: Wed Jan  2 10:46:30 2008
Subject: [GHC] #1097: enumFrom on basic numeric types should be strict
In-Reply-To: <056.1ac69e07bac1f738b8d4a415ad25c1fe@localhost>
References: <056.1ac69e07bac1f738b8d4a415ad25c1fe@localhost>
Message-ID: <065.24356a806e861bec55adbb5bcb1f2a9b@localhost>

#1097: enumFrom on basic numeric types should be strict
-----------------------------------+----------------------------------------
 Reporter:  bdonlan@gmail.com      |          Owner:             
     Type:  bug                    |         Status:  closed     
 Priority:  normal                 |      Milestone:  Not GHC    
Component:  libraries/base         |        Version:  6.6        
 Severity:  minor                  |     Resolution:  duplicate  
 Keywords:  enum strictness        |     Difficulty:  Easy (1 hr)
 Testcase:  lib/should_run/enum04  |   Architecture:  Unknown    
       Os:  Unknown                |  
-----------------------------------+----------------------------------------
Changes (by simonmar):

  * status:  reopened => closed
  * resolution:  => duplicate

Comment:

 duplicated by #1997

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/1097#comment:5>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Wed Jan  2 10:52:43 2008
From: trac at galois.com (GHC)
Date: Wed Jan  2 10:46:42 2008
Subject: [GHC] #1997: Stricter enumFrom instance for Integer,
 to match Int
In-Reply-To: <043.bda0d5ecfd811d8fda5e74a0019c2fae@localhost>
References: <043.bda0d5ecfd811d8fda5e74a0019c2fae@localhost>
Message-ID: <052.5a08f63346b82362b028fb5c3d61d944@localhost>

#1997: Stricter enumFrom instance for Integer, to match Int
-----------------------------------+----------------------------------------
 Reporter:  dons                   |          Owner:             
     Type:  bug                    |         Status:  new        
 Priority:  normal                 |      Milestone:  6.10 branch
Component:  libraries/base         |        Version:  6.8.2      
 Severity:  normal                 |     Resolution:             
 Keywords:                         |     Difficulty:  Easy (1 hr)
 Testcase:  lib/should_run/enum04  |   Architecture:  Multiple   
       Os:  Multiple               |  
-----------------------------------+----------------------------------------
Changes (by simonmar):

  * testcase:  => lib/should_run/enum04

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/1997#comment:4>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Wed Jan  2 10:58:43 2008
From: trac at galois.com (GHC)
Date: Wed Jan  2 10:52:42 2008
Subject: [GHC] #2013: ghci crash on startup: R_X86_64_32S relocation out of
 range.
Message-ID: <044.2f007075e8a3e652be5aa7c77056c714@localhost>

#2013: ghci crash on startup: R_X86_64_32S relocation out of range.
-------------------------------+--------------------------------------------
    Reporter:  mboes           |       Owner:         
        Type:  bug             |      Status:  new    
    Priority:  normal          |   Milestone:         
   Component:  GHCi            |     Version:  6.8.1  
    Severity:  normal          |    Keywords:         
  Difficulty:  Unknown         |    Testcase:         
Architecture:  x86_64 (amd64)  |          Os:  FreeBSD
-------------------------------+--------------------------------------------
 On freebsd-7.0 I have a working ghc-6.8.2 bootstrapped from a ghc-6.6.1
 itself boostrapped from a 32-bit machine. I'd like to create a bindist for
 this platform, for which there are as yet no available binary distribution
 of ghc, but before that it would be nice if ghci worked. Currently I get
 the following error:

 {{{
 mboes@caracas:~/ > ghci
 GHCi, version 6.8.2: http://www.haskell.org/ghc/  :? for help
 ghc-6.8.2: internal error: R_X86_64_32S relocation out of range: (noname)
 = 0x802d779c0

     (GHC version 6.8.2 for x86_64_unknown_freebsd)
     Please report this as a GHC bug:
 http://www.haskell.org/ghc/reportabug
 [1]    21394 abort      ghci
 }}}

 This bug has also been spotted before by [http://www.haskell.org/pipermail
 /cvs-ghc/2007-November/039305.html Tim Newsham] on ghc-6.8.1 on Freebsd-
 amd64 as well. Could this be related to #1562 or #1073 on Linux?

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/2013>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Wed Jan  2 11:23:58 2008
From: trac at galois.com (GHC)
Date: Wed Jan  2 11:17:57 2008
Subject: [GHC] #1288: ghci 6.6 foreign import stdcall broken, panic,
 panic!!!!
In-Reply-To: <057.ee3a70497de9cc3d83abf1aab5293225@localhost>
References: <057.ee3a70497de9cc3d83abf1aab5293225@localhost>
Message-ID: <066.07d870e20db951b837fd10f5445e77bf@localhost>

#1288: ghci 6.6 foreign import stdcall broken, panic, panic!!!!
-------------------------------------------------+--------------------------
 Reporter:  jvlask@hotmail.com                   |          Owner:  simonmar        
     Type:  bug                                  |         Status:  new             
 Priority:  normal                               |      Milestone:  6.8.3           
Component:  GHCi                                 |        Version:  6.6             
 Severity:  critical                             |     Resolution:                  
 Keywords:  ghci foreign ffi dll import stdcall  |     Difficulty:  Moderate (1 day)
 Testcase:                                       |   Architecture:  x86             
       Os:  Windows                              |  
-------------------------------------------------+--------------------------
Changes (by felixmar):

 * cc: fmartini@gmail.com (added)

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/1288#comment:8>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Wed Jan  2 12:42:41 2008
From: trac at galois.com (GHC)
Date: Wed Jan  2 12:36:41 2008
Subject: [GHC] #2014: getLinkDeps panic
Message-ID: <043.959b8170a1a6ec2b7cea0d1cfc8fd3ff@localhost>

#2014: getLinkDeps panic
-------------------------+--------------------------------------------------
    Reporter:  fons      |       Owner:         
        Type:  bug       |      Status:  new    
    Priority:  normal    |   Milestone:         
   Component:  Compiler  |     Version:  6.8.2  
    Severity:  blocker   |    Keywords:         
  Difficulty:  Unknown   |    Testcase:         
Architecture:  Unknown   |          Os:  Unknown
-------------------------+--------------------------------------------------
 I am working on a project which uses mutually recursive modules and
 Template Haskell. Since "ghc --make" does not seem to figure out the
 dependencies properly in this case (see bug #1012) I gave Cabal's make
 backend a try without luck (I'm stuck again).

 The compilation results in:


 {{{
 /usr/local/bin/ghc -package-name ForSyDe-0.1 -hide-all-packages -i
 -idist/build/autogen -idist/build -isrc -Idist/build -odir dist/build
 -hidir dist/build -stubdir dist/build -package packedstring-0.1.0.0
 -package base-3.0.1.0 -package regex-posix-0.72.0.2 -package mtl-1.1.0.0
 -package pretty-1.0.0.0 -package template-haskell-2.2.0.0 -O -Wall -fno-
 warn-name-shadowing -fno-warn-orphans -idist/build  -c
 src/ForSyDe/Process/SynchProc.hs -o dist/build/ForSyDe/Process/SynchProc.o
 -ohi dist/build/ForSyDe/Process/SynchProc.hi
 Loading package base ... linking ... done.
 Loading package pretty-1.0.0.0 ... linking ... done.
 Loading package array-0.1.0.0 ... linking ... done.
 Loading package packedstring-0.1.0.0 ... linking ... done.
 Loading package containers-0.1.0.1 ... linking ... done.
 Loading package template-haskell ... linking ... done.
 Loading package mtl-1.1.0.0 ... linking ... done.
 Loading package bytestring-0.9.0.1 ... linking ... done.
 Loading package regex-base-0.72.0.1 ... linking ... done.
 Loading package regex-posix-0.72.0.2 ... linking ... done.
 ghc-6.8.2: panic! (the 'impossible' happened)
   (GHC version 6.8.2 for i386-apple-darwin):
         getLinkDeps No iface for ForSyDe-0.1:ForSyDe.System.SysDef

 Please report this as a GHC bug:  http://www.haskell.org/ghc/reportabug

 make: *** [dist/build/ForSyDe/Process/SynchProc.o] Error 1
 }}}

 However, the interface file is available to ghc:


 {{{
 $ ls -l dist/build/ForSyDe/System/SysDef.hi
 -rw-r--r--  1 fons  staff  2225  2 ene 18:13
 dist/build/ForSyDe/System/SysDef.hi
 }}}

 Sorry, but I couldn't narrow down the problem. To reproduce it, simply
 download my library
 (http://homepage.mac.com/alfonso.acosta/.Public/ForSyDe.tgz ) and build
 using Cabal's make backend:


 {{{
 $ tar -xvzf ForSyDe.tgz; cd ForSyDe; ./Setup.hs configure; ./Setup.hs
 makefile; make
 }}}


 Curiously enough, building the library itself does not work but loading a
 test in ghci, works perfectly well and builds the whole library without
 problems:


 {{{
 $ cd ForSyDe/examples/ ; ghci -i../src ParAddFour.hs
 GHCi, version 6.8.2: http://www.haskell.org/ghc/  :? for help
 Loading package base ... linking ... done.
 ... (vompilation skipped)
 Ok, modules loaded: ForSyDe, ParAddFour, ForSyDe.AbsentExt,
 Language.Haskell.TH.Lift, ForSyDe.Vector, ForSyDe.Backend,
 ForSyDe.Backend.Simulate, Language.Haskell.TH.TypeLib, ForSyDe.Process,
 ForSyDe.Process.ProcVal, ForSyDe.ForSyDeErr, ForSyDe.ForSyDeErr,
 ForSyDe.Netlist, ForSyDe.Process.ProcFun, ForSyDe.Process.ProcFun,
 Language.Haskell.TH.LiftInstances, ForSyDe.System, ForSyDe.System.SysDef,
 ForSyDe.System.SysDef, ForSyDe.OSharing, ForSyDe.OSharing.UDynamic,
 ForSyDe.System.SysFun, ForSyDe.Signal, ForSyDe.Netlist.Traverse,
 ForSyDe.System.Instantiate, ForSyDe.Process.SynchProc.
 *ParAddFour>
 }}}

 It is a major blocker for the project (I have been stuck for days). I hope
 you find appropiate that I tagged it as such.

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/2014>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Wed Jan  2 12:51:11 2008
From: trac at galois.com (GHC)
Date: Wed Jan  2 12:45:13 2008
Subject: [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
In-Reply-To: <050.c31695132cb1b93380c95a8b6c208782@localhost>
References: <050.c31695132cb1b93380c95a8b6c208782@localhost>
Message-ID: <059.38760715a2080cff52726cac89a9d322@localhost>

#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:  thorkilnaur
     Type:  bug          |         Status:  new        
 Priority:  high         |      Milestone:  6.8.3      
Component:  Compiler     |        Version:  6.9        
 Severity:  normal       |     Resolution:             
 Keywords:               |     Difficulty:  Unknown    
 Testcase:               |   Architecture:  powerpc    
       Os:  MacOS X      |  
-------------------------+--------------------------------------------------
Comment (by thorkilnaur):

 Thanks a lot for this information. I would assume that the PPC Mac OS X
 Leopard builder fails to build stage 2 for the same reason
 (http://darcs.haskell.org/buildbot/all/tnaur%20PPC%20OSX%20head%202/builds/20
 /step-stage2/0):
 {{{
 /usr/bin/ld -r -x -o HSghc.o  stage2/basicTypes/BasicTypes.o
 stage2/basicTypes/DataCon.o stage2/basicTypes/Demand.o
 stage2/basicTypes/Id.o stage2/basicTypes/IdInfo.o
 stage2/basicTypes/Literal.o stage2/basicTypes/MkId.o
 stage2/basicTypes/Module.o stage2/basicTypes/Name.o
 stage2/basicTypes/NameEnv.o stage2/basicTypes/NameSet.o
 stage2/basicTypes/NewDemand.o stage2/basicTypes/OccName.o
 stage2/basicTypes/RdrName.o stage2/basicTypes/SrcLoc.o
 stage2/basicTypes/UniqSupply.o stage2/basicTypes/Unique.o
 stage2/basicTypes/Var.o stage2/basicTypes/VarEnv.o
 stage2/basicTypes/VarSet.o stage2/cmm/CLabel.o stage2/cmm/Cmm.o
 stage2/cmm/CmmBrokenBlock.o stage2/cmm/CmmCPS.o stage2/cmm/CmmCPSGen.o
 stage2/cmm/CmmCPSZ.o stage2/cmm/CmmCallConv.o stage2/cmm/CmmContFlowOpt.o
 stage2/cmm/CmmCvt.o stage2/cmm/CmmExpr.o stage2/cmm/CmmInfo.o
 stage2/cmm/CmmLex.o stage2/cmm/CmmLint.o stage2/cmm/CmmLive.o
 stage2/cmm/CmmLiveZ.o stage2/cmm/CmmOpt.o stage2/cmm/CmmParse.o
 stage2/cmm/CmmProcPoint.o stage2/cmm/CmmProcPointZ.o
 stage2/cmm/CmmSpillReload.o stage2/cmm/CmmTx.o stage2/cmm/CmmUtils.o
 stage2/cmm/CmmZipUtil.o stage2/cmm/DFMonad.o stage2/cmm/Dataflow.o
 stage2/cmm/MachOp.o stage2/cmm/MkZipCfg.o stage2/cmm/MkZipCfgCmm.o
 stage2/cmm/OptimizationFuel.o stage2/cmm/PprC.o stage2/cmm/PprCmm.o
 stage2/cmm/PprCmmZ.o stage2/cmm/StackColor.o stage2/cmm/StackPlacements.o
 stage2/cmm/ZipCfg.o stage2/cmm/ZipCfgCmmRep.o stage2/cmm/ZipCfgExtras.o
 stage2/cmm/ZipDataflow0.o stage2/codeGen/Bitmap.o
 stage2/codeGen/CgBindery.o stage2/codeGen/CgCallConv.o
 stage2/codeGen/CgCase.o stage2/codeGen/CgClosure.o stage2/codeGen/CgCon.o
 stage2/codeGen/CgExpr.o stage2/codeGen/CgForeignCall.o
 stage2/codeGen/CgHeapery.o stage2/codeGen/CgHpc.o
 stage2/codeGen/CgInfoTbls.o stage2/codeGen/CgLetNoEscape.o
 stage2/codeGen/CgMonad.o stage2/codeGen/CgParallel.o
 stage2/codeGen/CgPrimOp.o stage2/codeGen/CgProf.o
 stage2/codeGen/CgStackery.o stage2/codeGen/CgTailCall.o
 stage2/codeGen/CgTicky.o stage2/codeGen/CgUtils.o
 stage2/codeGen/ClosureInfo.o stage2/codeGen/CodeGen.o
 stage2/codeGen/SMRep.o stage2/coreSyn/CoreFVs.o stage2/coreSyn/CoreLint.o
 stage2/coreSyn/CorePrep.o stage2/coreSyn/CoreSubst.o
 stage2/coreSyn/CoreSyn.o stage2/coreSyn/CoreTidy.o
 stage2/coreSyn/CoreUnfold.o stage2/coreSyn/CoreUtils.o
 stage2/coreSyn/ExternalCore.o stage2/coreSyn/MkExternalCore.o
 stage2/coreSyn/PprCore.o stage2/coreSyn/PprExternalCore.o
 stage2/cprAnalysis/CprAnalyse.o stage2/deSugar/Check.o
 stage2/deSugar/Coverage.o stage2/deSugar/Desugar.o
 stage2/deSugar/DsArrows.o stage2/deSugar/DsBinds.o
 stage2/deSugar/DsCCall.o stage2/deSugar/DsExpr.o
 stage2/deSugar/DsForeign.o stage2/deSugar/DsGRHSs.o
 stage2/deSugar/DsListComp.o stage2/deSugar/DsMeta.o
 stage2/deSugar/DsMonad.o stage2/deSugar/DsUtils.o stage2/deSugar/Match.o
 stage2/deSugar/MatchCon.o stage2/deSugar/MatchLit.o
 stage2/ghci/ByteCodeAsm.o stage2/ghci/ByteCodeFFI.o
 stage2/ghci/ByteCodeGen.o stage2/ghci/ByteCodeInstr.o
 stage2/ghci/ByteCodeItbls.o stage2/ghci/ByteCodeLink.o
 stage2/ghci/Debugger.o stage2/ghci/GhciMonad.o stage2/ghci/GhciTags.o
 stage2/ghci/InteractiveUI.o stage2/ghci/Linker.o stage2/ghci/ObjLink.o
 stage2/ghci/RtClosureInspect.o stage2/hsSyn/Convert.o
 stage2/hsSyn/HsBinds.o stage2/hsSyn/HsDecls.o stage2/hsSyn/HsDoc.o
 stage2/hsSyn/HsExpr.o stage2/hsSyn/HsImpExp.o stage2/hsSyn/HsLit.o
 stage2/hsSyn/HsPat.o stage2/hsSyn/HsSyn.o stage2/hsSyn/HsTypes.o
 stage2/hsSyn/HsUtils.o stage2/iface/BinIface.o stage2/iface/BuildTyCl.o
 stage2/iface/IfaceEnv.o stage2/iface/IfaceSyn.o stage2/iface/IfaceType.o
 stage2/iface/LoadIface.o stage2/iface/MkIface.o stage2/iface/TcIface.o
 stage2/main/BreakArray.o stage2/main/CmdLineParser.o
 stage2/main/CodeOutput.o stage2/main/Config.o stage2/main/Constants.o
 stage2/main/DriverMkDepend.o stage2/main/DriverPhases.o
 stage2/main/DriverPipeline.o stage2/main/DynFlags.o stage2/main/ErrUtils.o
 stage2/main/Finder.o stage2/main/GHC.o stage2/main/HeaderInfo.o
 stage2/main/HscMain.o stage2/main/HscStats.o stage2/main/HscTypes.o
 stage2/main/InteractiveEval.o stage2/main/PackageConfig.o
 stage2/main/Packages.o stage2/main/ParsePkgConf.o stage2/main/PprTyThing.o
 stage2/main/StaticFlags.o stage2/main/SysTools.o stage2/main/TidyPgm.o
 stage2/nativeGen/AsmCodeGen.o stage2/nativeGen/MachCodeGen.o
 stage2/nativeGen/MachInstrs.o stage2/nativeGen/MachRegs.o
 stage2/nativeGen/NCGMonad.o stage2/nativeGen/PositionIndependentCode.o
 stage2/nativeGen/PprMach.o stage2/nativeGen/RegAllocColor.o
 stage2/nativeGen/RegAllocInfo.o stage2/nativeGen/RegAllocLinear.o
 stage2/nativeGen/RegAllocStats.o stage2/nativeGen/RegArchBase.o
 stage2/nativeGen/RegArchX86.o stage2/nativeGen/RegCoalesce.o
 stage2/nativeGen/RegLiveness.o stage2/nativeGen/RegSpill.o
 stage2/nativeGen/RegSpillClean.o stage2/nativeGen/RegSpillCost.o
 stage2/ndpFlatten/FlattenInfo.o stage2/ndpFlatten/FlattenMonad.o
 stage2/ndpFlatten/Flattening.o stage2/ndpFlatten/NDPCoreUtils.o
 stage2/ndpFlatten/PArrAnal.o stage2/parser/Ctype.o
 stage2/parser/HaddockLex.o stage2/parser/HaddockParse.o
 stage2/parser/HaddockUtils.o stage2/parser/LexCore.o stage2/parser/Lexer.o
 stage2/parser/Parser.o stage2/parser/ParserCore.o
 stage2/parser/ParserCoreUtils.o stage2/parser/RdrHsSyn.o
 stage2/prelude/ForeignCall.o stage2/prelude/PrelInfo.o
 stage2/prelude/PrelNames.o stage2/prelude/PrelRules.o
 stage2/prelude/PrimOp.o stage2/prelude/TysPrim.o
 stage2/prelude/TysWiredIn.o stage2/profiling/CostCentre.o
 stage2/profiling/SCCfinal.o stage2/rename/RnBinds.o stage2/rename/RnEnv.o
 stage2/rename/RnExpr.o stage2/rename/RnHsDoc.o stage2/rename/RnHsSyn.o
 stage2/rename/RnNames.o stage2/rename/RnPat.o stage2/rename/RnSource.o
 stage2/rename/RnTypes.o stage2/simplCore/CSE.o stage2/simplCore/FloatIn.o
 stage2/simplCore/FloatOut.o stage2/simplCore/LiberateCase.o
 stage2/simplCore/OccurAnal.o stage2/simplCore/SAT.o
 stage2/simplCore/SATMonad.o stage2/simplCore/SetLevels.o
 stage2/simplCore/SimplCore.o stage2/simplCore/SimplEnv.o
 stage2/simplCore/SimplMonad.o stage2/simplCore/SimplUtils.o
 stage2/simplCore/Simplify.o stage2/simplStg/SRT.o
 stage2/simplStg/SimplStg.o stage2/simplStg/StgStats.o
 stage2/specialise/Rules.o stage2/specialise/SpecConstr.o
 stage2/specialise/Specialise.o stage2/stgSyn/CoreToStg.o
 stage2/stgSyn/StgLint.o stage2/stgSyn/StgSyn.o stage2/stranal/DmdAnal.o
 stage2/stranal/SaAbsInt.o stage2/stranal/SaLib.o
 stage2/stranal/StrictAnal.o stage2/stranal/WorkWrap.o
 stage2/stranal/WwLib.o stage2/typecheck/FamInst.o stage2/typecheck/Inst.o
 stage2/typecheck/TcArrows.o stage2/typecheck/TcBinds.o
 stage2/typecheck/TcClassDcl.o stage2/typecheck/TcDefaults.o
 stage2/typecheck/TcDeriv.o stage2/typecheck/TcEnv.o
 stage2/typecheck/TcExpr.o stage2/typecheck/TcForeign.o
 stage2/typecheck/TcGadt.o stage2/typecheck/TcGenDeriv.o
 stage2/typecheck/TcHsSyn.o stage2/typecheck/TcHsType.o
 stage2/typecheck/TcInstDcls.o stage2/typecheck/TcMType.o
 stage2/typecheck/TcMatches.o stage2/typecheck/TcPat.o
 stage2/typecheck/TcRnDriver.o stage2/typecheck/TcRnMonad.o
 stage2/typecheck/TcRnTypes.o stage2/typecheck/TcRules.o
 stage2/typecheck/TcSimplify.o stage2/typecheck/TcSplice.o
 stage2/typecheck/TcTyClsDecls.o stage2/typecheck/TcTyDecls.o
 stage2/typecheck/TcTyFuns.o stage2/typecheck/TcType.o
 stage2/typecheck/TcUnify.o stage2/types/Class.o stage2/types/Coercion.o
 stage2/types/FamInstEnv.o stage2/types/FunDeps.o stage2/types/Generics.o
 stage2/types/InstEnv.o stage2/types/TyCon.o stage2/types/Type.o
 stage2/types/TypeRep.o stage2/types/Unify.o stage2/utils/Bag.o
 stage2/utils/Binary.o stage2/utils/BufWrite.o stage2/utils/Digraph.o
 stage2/utils/Encoding.o stage2/utils/FastMutInt.o
 stage2/utils/FastString.o stage2/utils/FastTypes.o
 stage2/utils/FiniteMap.o stage2/utils/GraphBase.o
 stage2/utils/GraphColor.o stage2/utils/GraphOps.o stage2/utils/GraphPpr.o
 stage2/utils/IOEnv.o stage2/utils/Interval.o stage2/utils/ListSetOps.o
 stage2/utils/Maybes.o stage2/utils/OrdList.o stage2/utils/Outputable.o
 stage2/utils/Panic.o stage2/utils/Pretty.o stage2/utils/State.o
 stage2/utils/StringBuffer.o stage2/utils/UniqFM.o stage2/utils/UniqSet.o
 stage2/utils/Util.o stage2/vectorise/VectBuiltIn.o
 stage2/vectorise/VectCore.o stage2/vectorise/VectMonad.o
 stage2/vectorise/VectType.o stage2/vectorise/VectUtils.o
 stage2/vectorise/Vectorise.o stage2/parser/cutils.o
 make[1]: *** [HSghc.o] Bus error
 make[1]: *** Deleting file `HSghc.o'
 make: *** [stage2] Error 2
 }}}
 I have looked a bit more into this and still believe that it is a Leopard
 ld problem. Although I am not able to understand what goes on with the
 failing PPC code in detail, I am a bit concerned about the use of an
 expression that subtracts a {{{.text}}} section relocatable symbol from a
 {{{.const_data}}} section relocatable symbol: The Apple Assembler
 documentation seems to suggest that this is invalid (see section headed
 "Relocatable Expressions" in
 http://developer.apple.com/documentation/DeveloperTools/Reference/Assembler/Assembler.pdf).

 Although I am not sure of the difference between {{{.const_data}}} and
 {{{.text}}}, I tried to change the code generator to replace
 {{{.const_data}}} sections with {{{.text}}} sections as indicated in the
 attached patch. The resulting compiler is able to pass the sore spots
 encountered earlier. It is also able to pass validate with relatively few
 errors reported, but I am not sure that this is particularly significant.
 For completion, the errors reported are
 {{{
 OVERALL SUMMARY for test run started at Wed Jan  2 09:53:41 CET 2008
     2051 total tests, which gave rise to
     7771 test cases, of which
        1 caused framework failures
     6026 were skipped

     1666 expected passes
       76 expected failures
        0 unexpected passes
        3 unexpected failures

 Unexpected failures:
    currentDirectory001(normal)
    directory001(normal)
    ghci024(ghci)
 }}}
 but I don't believe that they are relevant to this issue.

 Suggestions for further investigation are most welcome.

 Best regards
 Thorkil

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/1958#comment:9>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Thu Jan  3 00:24:31 2008
From: trac at galois.com (GHC)
Date: Thu Jan  3 00:18:28 2008
Subject: [GHC] #1944: round function causes cblas NaNs
In-Reply-To: <052.7827d863c451a2b4d8c8af2c2416f81c@localhost>
References: <052.7827d863c451a2b4d8c8af2c2416f81c@localhost>
Message-ID: <061.f54eb299fa7b34606bb9b9659be532fb@localhost>

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

 I have tested this bug now with an entirely different cblas, namely the
 acml library distributed by AMD.  Although my simplified test case
 compiles and runs correctly for the acml library, when the library is
 linked against my complex numerical application, NaNs proliferate
 everywhere in ghc 6.8.2.  This happens for both the single and multiple
 threaded cblas code.  Hopefully I won't need to generate a test case for
 the acml library.

 If I compile it with ghc 6.6.1 it works fine.  I'd say this is a pretty
 serious bug and I'm surprised that it hasn't appeared in other
 applications and other bug reports.  I simply would not trust any external
 floating point library that has been linked into ghc 6.8.2.  I've
 replicated the bug now on two different windows machines, one AMD and one
 core duo, and with three different cblas libraries.

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/1944#comment:6>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Thu Jan  3 04:49:28 2008
From: trac at galois.com (GHC)
Date: Thu Jan  3 04:43:25 2008
Subject: [GHC] #2013: ghci crash on startup: R_X86_64_32S relocation out
 of range.
In-Reply-To: <044.2f007075e8a3e652be5aa7c77056c714@localhost>
References: <044.2f007075e8a3e652be5aa7c77056c714@localhost>
Message-ID: <053.c25ead2b8d94adc0b23e55139b501898@localhost>

#2013: ghci crash on startup: R_X86_64_32S relocation out of range.
---------------------+------------------------------------------------------
 Reporter:  mboes    |          Owner:                
     Type:  bug      |         Status:  new           
 Priority:  normal   |      Milestone:  6.8.3         
Component:  GHCi     |        Version:  6.8.1         
 Severity:  normal   |     Resolution:                
 Keywords:           |     Difficulty:  Unknown       
 Testcase:           |   Architecture:  x86_64 (amd64)
       Os:  FreeBSD  |  
---------------------+------------------------------------------------------
Changes (by simonmar):

  * milestone:  => 6.8.3

Comment:

 Could you link the stage 2 compiler with -debug:
 {{{
 $ cd compiler
 $ rm stage2/ghc-6.9*
 $ make stage=2 EXTRA_HC_OPTS=-debug
 }}}
 and then capture the linker debugging output:
 {{{
 $ ./stage2/ghc-inplace +RTS -Dl 2>&1 | tee log
 }}}

 this should help track down the problem.

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/2013#comment:1>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Thu Jan  3 05:14:31 2008
From: trac at galois.com (GHC)
Date: Thu Jan  3 05:08:28 2008
Subject: [GHC] #1012: ghc panic with mutually recursive modules and
 template haskell
In-Reply-To: <044.e3ec0fd0938800cc6a7ce608eb8687c2@localhost>
References: <044.e3ec0fd0938800cc6a7ce608eb8687c2@localhost>
Message-ID: <053.f322183d6818d89f7ed3207438522025@localhost>

#1012: ghc panic with mutually recursive modules and template haskell
------------------------------+---------------------------------------------
 Reporter:  guest             |          Owner:          
     Type:  bug               |         Status:  reopened
 Priority:  normal            |      Milestone:  _|_     
Component:  Template Haskell  |        Version:  6.8.2   
 Severity:  normal            |     Resolution:          
 Keywords:                    |     Difficulty:  Unknown 
 Testcase:  TH_import_loop    |   Architecture:  Multiple
       Os:  Multiple          |  
------------------------------+---------------------------------------------
Comment (by simonmar):

 Since `ModuleB` is outside the `ModuleA/ModuleC` loop, it can import
 `ModuleA` without creating any new loops, and I bet this will work around
 the problem and get you unblocked.

 What's happening is that the dependency analysis isn't figuring out that
 the real `ModuleA` must be compiled before `ModuleB`.  I think the
 solution is something along the lines of: every module that depends on a
 module in a cycle, but is not a member of that cycle, should have an
 implicit dependency on each of the modules in the cycle.

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/1012#comment:9>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Thu Jan  3 05:15:00 2008
From: trac at galois.com (GHC)
Date: Thu Jan  3 05:08:57 2008
Subject: [GHC] #1012: ghc panic with mutually recursive modules and
 template haskell
In-Reply-To: <044.e3ec0fd0938800cc6a7ce608eb8687c2@localhost>
References: <044.e3ec0fd0938800cc6a7ce608eb8687c2@localhost>
Message-ID: <053.440a1471d4abb689abee79a7cca4ac15@localhost>

#1012: ghc panic with mutually recursive modules and template haskell
------------------------------+---------------------------------------------
 Reporter:  guest             |          Owner:            
     Type:  bug               |         Status:  reopened  
 Priority:  normal            |      Milestone:  6.8 branch
Component:  Template Haskell  |        Version:  6.8.2     
 Severity:  normal            |     Resolution:            
 Keywords:                    |     Difficulty:  Unknown   
 Testcase:  TH_import_loop    |   Architecture:  Multiple  
       Os:  Multiple          |  
------------------------------+---------------------------------------------
Changes (by simonmar):

  * milestone:  _|_ => 6.8 branch

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/1012#comment:10>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Thu Jan  3 05:50:43 2008
From: trac at galois.com (GHC)
Date: Thu Jan  3 05:44:40 2008
Subject: [GHC] #1944: round function causes cblas NaNs
In-Reply-To: <052.7827d863c451a2b4d8c8af2c2416f81c@localhost>
References: <052.7827d863c451a2b4d8c8af2c2416f81c@localhost>
Message-ID: <061.9bbe4b4db9ba6c4e5e64eceb26a7bb9d@localhost>

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

 Presumably something in the floating-point unit state is changing in a way
 that upsets the code in the cblas library.  I don't know of anything that
 could cause this; the native code generator does in one place generate
 code that saves and restores the FPU control word, but that was added in
 6.8.2 (see #1910).

 To proceed we really need to know what is changing in the FPU state, so
 that we can trace it back to the point at which it changed.  At the very
 least, we need a reproducible test case.  I downloaded your files and
 tried it, but it looks like I have a DLL missing:

 {{{
 c:\builds\atlas\Test2>maketest

 c:\builds\atlas\Test2>set CLIB=atlas

 c:\builds\atlas\Test2>set TopFile=Test2

 c:\builds\atlas\Test2>set csrc=ctest2.c

 c:\builds\atlas\Test2>set OutFile=Test2.exe

 c:\builds\atlas\Test2>dlltool.exe -D atlas.dll -l atlas.lib

 c:\builds\atlas\Test2>set XFLAGS=-threaded -O -XForeignFunctionInterface

 c:\builds\atlas\Test2>rem set XFLAGS=-threaded -O -fffi

 c:\builds\atlas\Test2>ghc -threaded -O -XForeignFunctionInterface -I.
 -I..\matri
 xstack --make Test2.hs ctest2.c -o Test2.exe -optl-latlas -optl-L"."
 [1 of 1] Compiling Main             ( Test2.hs, Test2.o )
 Linking Test2.exe ...

 c:\builds\atlas\Test2>Test2

 c:\builds\atlas\Test2>dir
  Volume in drive C has no label.
  Volume Serial Number is 6041-4C23

  Directory of c:\builds\atlas\Test2

 03/01/2008  10:38    <DIR>          .
 03/01/2008  10:38    <DIR>          ..
 29/11/2007  02:28         5,485,456 atlas.dll
 03/01/2008  10:38             1,490 atlas.lib
 29/11/2007  02:28               547 ctest2.c
 29/11/2007  02:28               721 ctest2.h
 03/01/2008  10:38               849 ctest2.o
 03/01/2008  10:37               433 index.html
 29/11/2007  02:28               309 maketest.bat
 03/01/2008  10:38           687,370 Test2.exe
 03/01/2008  10:38               502 Test2.exe.manifest
 03/01/2008  10:38             1,913 Test2.hi
 29/11/2007  02:28               178 Test2.hs
 03/01/2008  10:38             4,920 Test2.o
               12 File(s)      6,184,688 bytes
                2 Dir(s)  47,145,406,464 bytes free

 c:\builds\atlas\Test2>Test2.exe

 c:\builds\atlas\Test2>
 }}}

 Using dependency walker it looks like I don't have "MSJAVA.DLL".  Although
 why I need that, I have no idea.

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/1944#comment:7>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Thu Jan  3 06:32:04 2008
From: trac at galois.com (GHC)
Date: Thu Jan  3 06:26:02 2008
Subject: [GHC] #1898: segfault with +RTS -N2 (related to tryTakeMVar?)
In-Reply-To: <049.0881d74ddf1057ac706f274f5a37f964@localhost>
References: <049.0881d74ddf1057ac706f274f5a37f964@localhost>
Message-ID: <058.f150b32790ec522197d75a0b0833b722@localhost>

#1898: segfault with +RTS -N2 (related to tryTakeMVar?)
------------------------+---------------------------------------------------
 Reporter:  j.waldmann  |          Owner:  simonmar
     Type:  bug         |         Status:  new     
 Priority:  high        |      Milestone:  6.8.3   
Component:  Compiler    |        Version:  6.8.1   
 Severity:  normal      |     Resolution:          
 Keywords:              |     Difficulty:  Unknown 
 Testcase:              |   Architecture:  x86     
       Os:  Linux       |  
------------------------+---------------------------------------------------
Changes (by simonmar):

  * owner:  => simonmar

Comment:

 I'm testing a fix for this.

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/1898#comment:5>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From Christian.Maeder at dfki.de  Thu Jan  3 08:41:56 2008
From: Christian.Maeder at dfki.de (Christian Maeder)
Date: Thu Jan  3 08:35:53 2008
Subject: http://www.haskell.org/ghc/dist/mac_frameworks/GNUreadline-framework.zip
Message-ID: <477CE624.3040806@dfki.de>

Hi Ian,

Judah's framework (2342543 Bytes)
http://www.math.ucla.edu/~jjacobson/ghc/GNUreadline-framework.zip

should replace (my old one)
http://www.haskell.org/ghc/dist/mac_frameworks/GNUreadline-framework.zip

as described in http://hackage.haskell.org/trac/ghc/ticket/1931

I've also a copy at
http://www.informatik.uni-bremen.de/agbkb/forschung/formal_methods/CoFI/hets/mac/GNUreadline-framework.zip

Cheers Christian

(only the header files are different to allow inclusion via the -F flag
to gcc on Macs)
From trac at galois.com  Thu Jan  3 09:14:55 2008
From: trac at galois.com (GHC)
Date: Thu Jan  3 09:08:51 2008
Subject: [GHC] #2013: ghci crash on startup: R_X86_64_32S relocation out
 of range.
In-Reply-To: <044.2f007075e8a3e652be5aa7c77056c714@localhost>
References: <044.2f007075e8a3e652be5aa7c77056c714@localhost>
Message-ID: <053.31a58b088eba2d0c8bac24ec00587536@localhost>

#2013: ghci crash on startup: R_X86_64_32S relocation out of range.
---------------------+------------------------------------------------------
 Reporter:  mboes    |          Owner:                
     Type:  bug      |         Status:  new           
 Priority:  normal   |      Milestone:  6.8.3         
Component:  GHCi     |        Version:  6.8.1         
 Severity:  normal   |     Resolution:                
 Keywords:           |     Difficulty:  Unknown       
 Testcase:           |   Architecture:  x86_64 (amd64)
       Os:  FreeBSD  |  
---------------------+------------------------------------------------------
Comment (by mboes):

 Debug output of
 {{{
 ./stage2/ghc-inplace --interactive +RTS -Dl 2>&1 | tee log
 }}}
 is at [http://code.haskell.org/~mboes/log.bz2] (log too big for attachment
 on trac).

 Note that FreeBSD, just like OpenBSD, does not define MAP_32BIT and
 MAP_ANONYMOUS. I see in Linker.c the following #define:
 {{{
 #if defined(x86_64_HOST_ARCH) && defined(MAP_32BIT)
 #define EXTRA_MAP_FLAGS MAP_32BIT
 #else
 #define EXTRA_MAP_FLAGS 0
 #endif
 }}}

 But then I see an attempt to resolve symbols allocated in high memory
 using a bounce sequence:
 {{{
 // On x86_64, 32-bit relocations are often used, which requires that
 // we can resolve a symbol to a 32-bit offset.  However, shared
 // libraries are placed outside the 2Gb area, which leaves us with a
 // problem when we need to give a 32-bit offset to a symbol in a
 // shared library.
 //
 // For a function symbol, we can allocate a bounce sequence inside the
 // 2Gb area and resolve the symbol to this.  The bounce sequence is
 // simply a long jump instruction to the real location of the symbol.
 //
 // For data references, we're screwed.
 //
 ...
 static void*
 x86_64_high_symbol( char *lbl, void *addr )
 {
     x86_64_bounce *bounce;

     if ( x86_64_bounce_buffer == NULL ||
          x86_64_bb_next_off >= X86_64_BB_SIZE ) {
         x86_64_bounce_buffer =
             mmap(NULL, X86_64_BB_SIZE * sizeof(x86_64_bounce),
                  PROT_EXEC|PROT_READ|PROT_WRITE,
                  MAP_PRIVATE|EXTRA_MAP_FLAGS|MAP_ANONYMOUS, -1, 0);
         if (x86_64_bounce_buffer == MAP_FAILED) {
             barf("x86_64_high_symbol: mmap failed");
         }
         x86_64_bb_next_off = 0;
     }
 ...
 }}}

 Since there is no MAP_32BIT on FreeBSD it would seem the above bounce
 sequence can get arbitrarily allocated in high memory. Could this be the
 problem? I'm way out of my depth here, so please forgive the daftness of
 this question, but on my system there are no 32bit libraries at all, only
 64bit ones. Hence, could we do away with 32bit relocations entirely?

 Hope this helps,

 Mathieu

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/2013#comment:2>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Thu Jan  3 09:40:40 2008
From: trac at galois.com (GHC)
Date: Thu Jan  3 09:35:15 2008
Subject: [GHC] #1999: panic with GADT etc.
In-Reply-To: <046.74c6dc616261a913ffd4180fb00731f0@localhost>
References: <046.74c6dc616261a913ffd4180fb00731f0@localhost>
Message-ID: <055.c0cfc2eb05633a1f914507479d03ad0c@localhost>

#1999: panic with GADT etc.
----------------------+-----------------------------------------------------
 Reporter:  jeltsch   |          Owner:  chak       
     Type:  bug       |         Status:  new        
 Priority:  normal    |      Milestone:  6.10 branch
Component:  Compiler  |        Version:  6.9        
 Severity:  normal    |     Resolution:             
 Keywords:            |     Difficulty:  Unknown    
 Testcase:            |   Architecture:  x86        
       Os:  Linux     |  
----------------------+-----------------------------------------------------
Changes (by simonpj):

  * owner:  => chak

Comment:

 However, it may well not work in the HEAD, where Manuel is busy ripping
 out the old implementation of GADTs, in favour of the new type-function-
 based machinery.

 So I'm assigning this to Manuel; it'd be good to make a test case out of
 it too.

 Simon

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/1999#comment:2>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Thu Jan  3 10:03:28 2008
From: trac at galois.com (GHC)
Date: Thu Jan  3 09:57:24 2008
Subject: [GHC] #1898: segfault with +RTS -N2 (related to tryTakeMVar?)
In-Reply-To: <049.0881d74ddf1057ac706f274f5a37f964@localhost>
References: <049.0881d74ddf1057ac706f274f5a37f964@localhost>
Message-ID: <058.e0ac528ea5bf2ae51eb0fe33245137bd@localhost>

#1898: segfault with +RTS -N2 (related to tryTakeMVar?)
------------------------+---------------------------------------------------
 Reporter:  j.waldmann  |          Owner:  igloo  
     Type:  merge       |         Status:  new    
 Priority:  high        |      Milestone:  6.8.3  
Component:  Compiler    |        Version:  6.8.1  
 Severity:  normal      |     Resolution:         
 Keywords:              |     Difficulty:  Unknown
 Testcase:              |   Architecture:  x86    
       Os:  Linux       |  
------------------------+---------------------------------------------------
Changes (by simonmar):

  * owner:  simonmar => igloo
  * type:  bug => merge

Comment:

 Fixed:
 {{{
 Thu Jan  3 03:27:17 PST 2008  Simon Marlow <simonmar@microsoft.com>
   * FIX #1898: add a missing UNTAG_CLOSURE() in checkBlackHoles
 }}}

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/1898#comment:6>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From igloo at earth.li  Thu Jan  3 10:18:43 2008
From: igloo at earth.li (Ian Lynagh)
Date: Thu Jan  3 10:12:44 2008
Subject: http://www.haskell.org/ghc/dist/mac_frameworks/GNUreadline-framework.zip
In-Reply-To: <477CE624.3040806@dfki.de>
References: <477CE624.3040806@dfki.de>
Message-ID: <20080103151843.GA15045@matrix.chaos.earth.li>


Hi Christian,

On Thu, Jan 03, 2008 at 02:41:56PM +0100, Christian Maeder wrote:
> 
> Judah's framework (2342543 Bytes)
> http://www.math.ucla.edu/~jjacobson/ghc/GNUreadline-framework.zip
> 
> should replace (my old one)
> http://www.haskell.org/ghc/dist/mac_frameworks/GNUreadline-framework.zip

Done!


Thanks
Ian

From trac at galois.com  Thu Jan  3 10:19:39 2008
From: trac at galois.com (GHC)
Date: Thu Jan  3 10:13:36 2008
Subject: [GHC] #595: Overhaul GHC's overlapping/non-exhaustive pattern
 checking
In-Reply-To: <047.bea78f01cbb904765ad77c751bc8d3af@localhost>
References: <047.bea78f01cbb904765ad77c751bc8d3af@localhost>
Message-ID: <056.856d99077c5d941618f0e4c8df60628d@localhost>

#595: Overhaul GHC's overlapping/non-exhaustive pattern checking
----------------------+-----------------------------------------------------
 Reporter:  simonmar  |          Owner:                    
     Type:  task      |         Status:  new               
 Priority:  normal    |      Milestone:  _|_               
Component:  Compiler  |        Version:  None              
 Severity:  normal    |     Resolution:  None              
 Keywords:  warnings  |     Difficulty:  Difficult (1 week)
 Testcase:  N/A       |   Architecture:  Unknown           
       Os:  Unknown   |  
----------------------+-----------------------------------------------------
Comment (by simonpj):

 And #2006

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/595#comment:5>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Thu Jan  3 10:20:26 2008
From: trac at galois.com (GHC)
Date: Thu Jan  3 10:14:24 2008
Subject: [GHC] #2006: unreachable GADT pattern clauses show up as
 warnings with -Wall
In-Reply-To: <044.a004885c928a62e2a73bf12df457c462@localhost>
References: <044.a004885c928a62e2a73bf12df457c462@localhost>
Message-ID: <053.451e4e7cb7965e956e88252b9a4f7f5e@localhost>

#2006: unreachable GADT pattern clauses show up as warnings with -Wall
----------------------+-----------------------------------------------------
 Reporter:  ryani     |          Owner:             
     Type:  bug       |         Status:  new        
 Priority:  normal    |      Milestone:  6.10 branch
Component:  Compiler  |        Version:  6.8.1      
 Severity:  normal    |     Resolution:             
 Keywords:            |     Difficulty:  Unknown    
 Testcase:            |   Architecture:  Unknown    
       Os:  Unknown   |  
----------------------+-----------------------------------------------------
Changes (by simonpj):

  * milestone:  6.8 branch => 6.10 branch

Comment:

 Quite right.  The "non-exhaustive pattern" warning comes from a part of
 the compiler that needs a serious overhaul.  See #595.  In particular,
 it's utterly unaware of GADTs, so it's going to produce spurious warnings,
 and will continue to do so until it is overhauled.

 We definitely won't fix this on the 6.8 branch.  Probably it needs a
 volunteer.

 Simon

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/2006#comment:2>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Thu Jan  3 11:03:28 2008
From: trac at galois.com (GHC)
Date: Thu Jan  3 10:57:24 2008
Subject: [GHC] #2000: -funfolding-update-in-place badly documented
In-Reply-To: <045.ac76dc598481f3a493531a6d155a8b48@localhost>
References: <045.ac76dc598481f3a493531a6d155a8b48@localhost>
Message-ID: <054.7889f75585f24f40040b93548112ca64@localhost>

#2000: -funfolding-update-in-place badly documented
----------------------+-----------------------------------------------------
 Reporter:  m4dc4p    |          Owner:  igloo  
     Type:  merge     |         Status:  new    
 Priority:  normal    |      Milestone:  6.8.3  
Component:  Compiler  |        Version:  6.8.1  
 Severity:  normal    |     Resolution:         
 Keywords:            |     Difficulty:  Unknown
 Testcase:            |   Architecture:  x86    
       Os:  Windows   |  
----------------------+-----------------------------------------------------
Changes (by simonpj):

  * type:  bug => merge

Comment:

 It's an obsolete flag that does nothing.  I'll remove the documentation:
 {{{
 Thu Jan  3 16:00:36 GMT 2008  simonpj@microsoft.com
   * Remove -funfolding-update-in-place flag documentation
 }}}
 Merge to 6.8 branch, pls.

 Simon

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/2000#comment:4>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Thu Jan  3 11:18:11 2008
From: trac at galois.com (GHC)
Date: Thu Jan  3 11:12:09 2008
Subject: [GHC] #2011: [6.8.1 regression] panic: lookupVers1
 base:GHC.Prim sym{tc}
In-Reply-To: <047.5794bcb02e44dfb8bb70a89a113f27e3@localhost>
References: <047.5794bcb02e44dfb8bb70a89a113f27e3@localhost>
Message-ID: <056.f0caab7bc45b9f30f833a81592425da5@localhost>

#2011: [6.8.1 regression] panic: lookupVers1 base:GHC.Prim sym{tc}
----------------------+-----------------------------------------------------
 Reporter:  simonmar  |          Owner:  igloo  
     Type:  merge     |         Status:  new    
 Priority:  high      |      Milestone:  6.8.3  
Component:  Compiler  |        Version:  6.8.2  
 Severity:  normal    |     Resolution:         
 Keywords:            |     Difficulty:  Unknown
 Testcase:            |   Architecture:  Unknown
       Os:  Unknown   |  
----------------------+-----------------------------------------------------
Changes (by simonpj):

  * owner:  simonpj => igloo
  * type:  bug => merge

Comment:

 The patch is this one.  Ian, please merge to 6.8 branch.
 {{{
 Thu Dec 20 16:43:07 GMT 2007  simonpj@microsoft.com
   * Fix nasty recompilation bug in MkIface.computeChangedOccs

         MERGE to 6.8 branch

   In computeChangedOccs we look up the old version of a Name.
   But a WiredIn Name doesn't have an old version, because WiredIn things
   don't appear in interface files at all.

   Result: ghc-6.9: panic! (the 'impossible' happened)
     (GHC version 6.9 for x86_64-unknown-linux):
         lookupVers1 base:GHC.Prim chr#{v}

   This fixes the problem.  The patch should merge easily onto the branch.
 }}}

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/2011#comment:1>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Thu Jan  3 11:47:13 2008
From: trac at galois.com (GHC)
Date: Thu Jan  3 11:41:14 2008
Subject: [GHC] #793: Use gcc's libffi to replace Adjustor.c and
 ByteCodeFFI.hs?
In-Reply-To: <047.bebe0ee1522997ea1300a5b9fc8eb59f@localhost>
References: <047.bebe0ee1522997ea1300a5b9fc8eb59f@localhost>
Message-ID: <056.f21472831cab3c730bb9ee5e60b3d35f@localhost>

#793: Use gcc's libffi to replace Adjustor.c and ByteCodeFFI.hs?
----------------------------+-----------------------------------------------
 Reporter:  simonmar        |          Owner:  simonmar        
     Type:  task            |         Status:  new             
 Priority:  normal          |      Milestone:  6.8 branch      
Component:  Runtime System  |        Version:  6.4.1           
 Severity:  normal          |     Resolution:                  
 Keywords:                  |     Difficulty:  Moderate (1 day)
 Testcase:  N/A             |   Architecture:  Unknown         
       Os:  Unknown         |  
----------------------------+-----------------------------------------------
Changes (by simonmar):

  * owner:  => simonmar

Comment:

 I have the `createAdjustor` part of this working, but it needs proper
 autoconf gubbins etc., and we need to decide whether to import `libffi`
 into our tree and hook it into the build system or not.  Right now I'm
 compiling against the `libffi` supplied by Debian/Ubuntu, which appears to
 be close to the version in the gcc SVN repository.

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/793#comment:7>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Thu Jan  3 11:57:32 2008
From: trac at galois.com (GHC)
Date: Thu Jan  3 11:51:29 2008
Subject: [GHC] #793: Use gcc's libffi to replace Adjustor.c and
 ByteCodeFFI.hs?
In-Reply-To: <047.bebe0ee1522997ea1300a5b9fc8eb59f@localhost>
References: <047.bebe0ee1522997ea1300a5b9fc8eb59f@localhost>
Message-ID: <056.6dc72f64f12c9d647f60d775a9a3a78e@localhost>

#793: Use gcc's libffi to replace Adjustor.c and ByteCodeFFI.hs?
----------------------------+-----------------------------------------------
 Reporter:  simonmar        |          Owner:  simonmar        
     Type:  task            |         Status:  new             
 Priority:  normal          |      Milestone:  6.8 branch      
Component:  Runtime System  |        Version:  6.4.1           
 Severity:  normal          |     Resolution:                  
 Keywords:                  |     Difficulty:  Moderate (1 day)
 Testcase:  N/A             |   Architecture:  Unknown         
       Os:  Unknown         |  
----------------------------+-----------------------------------------------
Comment (by igloo):

 I don't think we should bundle it. It's the sort of thing where more
 obscure platforms need the latest version, and we don't another thing we
 have to make sure we keep up-to-date. Also, for the common case (including
 Windows users) it isn't necessary to have it, as the existing code can be
 used instead.

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/793#comment:8>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Thu Jan  3 12:16:35 2008
From: trac at galois.com (GHC)
Date: Thu Jan  3 12:10:44 2008
Subject: [GHC] #1395: let ./configure check for a GNUreadline framework
In-Reply-To: <052.068bc0f583c08a182f51a06ad4864715@localhost>
References: <052.068bc0f583c08a182f51a06ad4864715@localhost>
Message-ID: <061.bece9f1d24cbbf8d44894353c9d66305@localhost>

#1395: let ./configure check for a GNUreadline framework
-----------------------------+----------------------------------------------
 Reporter:  maeder@tzi.de    |          Owner:             
     Type:  feature request  |         Status:  reopened   
 Priority:  normal           |      Milestone:  6.8 branch 
Component:  Build System     |        Version:  6.8        
 Severity:  normal           |     Resolution:             
 Keywords:                   |     Difficulty:  Easy (1 hr)
 Testcase:                   |   Architecture:  Multiple   
       Os:  MacOS X          |  
-----------------------------+----------------------------------------------
Comment (by guest):

 Replying to [comment:25 maeder]:
 > My modification of `utils/hsc2hs/Main.hs` (probably) caused the problem
 reported in
 > http://article.gmane.org/gmane.comp.lang.haskell.cafe/34373

 Cabal already handles this type of problem by passing different flags
 based on whether `hsc2hs` is using `gcc` or `ghc`.  This is done in
 `Distribution.Simple.PreProcess.ppHsc2hs` and
 `Simple.Program.hsc2hsProgram`.

 Perhaps Cabal should add the `-F$HOME/Library/Frameworks` instead of
 `hsc2hs` itself?   See http://hackage.haskell.org/trac/hackage/ticket/189

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/1395#comment:26>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Thu Jan  3 12:24:11 2008
From: trac at galois.com (GHC)
Date: Thu Jan  3 12:18:14 2008
Subject: [GHC] #1395: let ./configure check for a GNUreadline framework
In-Reply-To: <052.068bc0f583c08a182f51a06ad4864715@localhost>
References: <052.068bc0f583c08a182f51a06ad4864715@localhost>
Message-ID: <061.8317ed53871cada8d7d4dfa7521dd7a1@localhost>

#1395: let ./configure check for a GNUreadline framework
-----------------------------+----------------------------------------------
 Reporter:  maeder@tzi.de    |          Owner:             
     Type:  feature request  |         Status:  reopened   
 Priority:  normal           |      Milestone:  6.8 branch 
Component:  Build System     |        Version:  6.8        
 Severity:  normal           |     Resolution:             
 Keywords:                   |     Difficulty:  Easy (1 hr)
 Testcase:                   |   Architecture:  Multiple   
       Os:  MacOS X          |  
-----------------------------+----------------------------------------------
Comment (by guest):

 By the way; I wrote the previous comment while logged in as `guest`, but
 forgot to sign it.

 -Judah

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/1395#comment:27>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Thu Jan  3 13:03:07 2008
From: trac at galois.com (GHC)
Date: Thu Jan  3 12:57:14 2008
Subject: [GHC] #1987: GHCi's config file in <AppData>\ghc folder on
 Windows
In-Reply-To: <047.80a8b57d40878eeae0279f928cac66b2@localhost>
References: <047.80a8b57d40878eeae0279f928cac66b2@localhost>
Message-ID: <056.f6ae8f08f40f54eb1f16515eabd096b9@localhost>

#1987: GHCi's config file in <AppData>\ghc folder on Windows
-----------------------------+----------------------------------------------
 Reporter:  felixmar         |          Owner:             
     Type:  feature request  |         Status:  new        
 Priority:  low              |      Milestone:  6.10 branch
Component:  GHCi             |        Version:  6.9        
 Severity:  normal           |     Resolution:             
 Keywords:                   |     Difficulty:  Unknown    
 Testcase:                   |   Architecture:  Unknown    
       Os:  Windows          |  
-----------------------------+----------------------------------------------
Changes (by ross):

  * type:  proposal => feature request

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/1987#comment:2>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From naur at post11.tele.dk  Thu Jan  3 14:58:47 2008
From: naur at post11.tele.dk (Thorkil Naur)
Date: Thu Jan  3 14:53:41 2008
Subject: http://www.haskell.org/ghc/dist/mac_frameworks/GNUreadline-framework.zip
In-Reply-To: <20080103151849.DJSH5833.fep27.mail.dk@matrix.matrix.chaos.earth.li>
References: <477CE624.3040806@dfki.de>
	<20080103151849.DJSH5833.fep27.mail.dk@matrix.matrix.chaos.earth.li>
Message-ID: <200801032058.47615.naur@post11.tele.dk>

Hello,

Thanks everybody. However, I believe that using a modified readline library is 
debatable, mainly because it adds the burden of keeping this library 
up-to-date to the GHC maintenance process. Having a renamed library is one 
thing and it does not seem that also modifying the contents of the library is 
an improvement.  For me to consider this idea, it should be the very last 
solution, every other stone having been turned. And I certainly believe that 
stones remain to be turned in this case.

I would very much like to hear your comments to this.

In addition, if you must replace this framework with another with different 
contents, I would suggest the use of some versioning scheme. Otherwise is 
seems that a lot of confusion could result.

Thanks and best regards
Thorkil

On Thursday 03 January 2008 16:18, Ian Lynagh wrote:
> 
> Hi Christian,
> 
> On Thu, Jan 03, 2008 at 02:41:56PM +0100, Christian Maeder wrote:
> > 
> > Judah's framework (2342543 Bytes)
> > http://www.math.ucla.edu/~jjacobson/ghc/GNUreadline-framework.zip
> > 
> > should replace (my old one)
> > http://www.haskell.org/ghc/dist/mac_frameworks/GNUreadline-framework.zip
> 
> Done!
> 
> 
> Thanks
> Ian
> 
> 
From trac at galois.com  Thu Jan  3 15:48:43 2008
From: trac at galois.com (GHC)
Date: Thu Jan  3 15:42:40 2008
Subject: [GHC] #1944: round function causes cblas NaNs
In-Reply-To: <052.7827d863c451a2b4d8c8af2c2416f81c@localhost>
References: <052.7827d863c451a2b4d8c8af2c2416f81c@localhost>
Message-ID: <061.811f364dc099b7ac8023cf7d4998f345@localhost>

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

 Replying to [comment:7 simonmar]:
 > Presumably something in the floating-point unit state is changing in a
 way that upsets the code in the cblas library.  I don't know of anything
 that could cause this; the native code generator does in one place
 generate code that saves and restores the FPU control word, but that was
 added in 6.8.2 (see #1910).
 >
 > To proceed we really need to know what is changing in the FPU state, so
 that we can trace it back to the point at which it changed.  At the very
 least, we need a reproducible test case.  I downloaded your files and
 tried it, but it looks like I have a DLL missing:

 > Using dependency walker it looks like I don't have "MSJAVA.DLL".
 Although why I need that, I have no idea.

 Hmmm, my dependency walker is not showing the same results.  I have no
 dependency on MSJAVA.dll.  The dependencies I show are MSVCRT.dll,
 KERNEL32.dll, NTDLL.dll.  This could be because of the C runtime libraries
 that you are linking  to on your system.  So this is what I did to try to
 remove any possible variation in results.

 First I recompiled my test case using GHC 6.8.2 on my intel core duo
 laptop running windows xp (32 bit).  It still shows the errant NaNs.  I
 then uploaded my atlas.dll file once again just in case.  (Although the
 size of the two files is identical). I then uploaded my C runtime DLLs and
 the system DLLs.  They should be virus free, if my virus protection
 software is any good.  These files are now in subdirectory CRunTime.  I
 suspect it's not entirely kosher to freely publish copyrighted MS software
 so if you can get these to work, let me know and I will delete the system
 files.  You will probably temporarily have to mess with your path or put
 all the DLL's in the same directory with the application to force it to
 pick up the C Runtime I've provided.

 The location of these binaries can be found in:
 http://home.earthlink.net/~mattcbro/Test2/

 Apparently igloo was able to run my test case with my binaries and
 obtained some odd results so I am not alone in this.

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/1944#comment:8>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Thu Jan  3 16:37:10 2008
From: trac at galois.com (GHC)
Date: Thu Jan  3 16:31:11 2008
Subject: [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
In-Reply-To: <050.c31695132cb1b93380c95a8b6c208782@localhost>
References: <050.c31695132cb1b93380c95a8b6c208782@localhost>
Message-ID: <059.da7961db705744a1aad718017c455dd2@localhost>

#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:  thorkilnaur
     Type:  bug          |         Status:  new        
 Priority:  high         |      Milestone:  6.8.3      
Component:  Compiler     |        Version:  6.9        
 Severity:  normal       |     Resolution:             
 Keywords:               |     Difficulty:  Unknown    
 Testcase:               |   Architecture:  powerpc    
       Os:  MacOS X      |  
-------------------------+--------------------------------------------------
Comment (by eelco):

 I haven't spent much time on this (because I compiling GHC wasn't the
 final goal ;), but the compiler built with 'quickest' gave some strange
 errors concerning interface files when trying to build HAppS.  So I tried
 building 6.8.2 again, again with ld_classic, but now with build flavor
 'quick'.  I had to restart the build 3 or 4 times, since it segfaulted on
 (seemingly) random files.  After that I tried building HAppS again.
 Unfortunately, I got stuck at the same point, this time with a panic.

 {{{
 [10 of 18] Compiling HAppS.State.Transaction (
 src/HAppS/State/Transaction.hs, dist/build/HAppS/State/Transaction.o )

 src/HAppS/State/Transaction.hs:264:42:
     Warning: Defined but not used: `logger'

 src/HAppS/State/Transaction.hs:264:52:
     Warning: Defined but not used: `ev'
 ghc-6.8.2: panic! (the 'impossible' happened)
   (GHC version 6.8.2 for powerpc-apple-darwin):
         splitFunTy
     <nt>base:GHC.Conc.STM{tc r2T} base:GHC.Base.(){(w) tc 40}
 }}}

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/1958#comment:10>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Thu Jan  3 20:29:24 2008
From: trac at galois.com (GHC)
Date: Thu Jan  3 20:23:18 2008
Subject: [GHC] #2015: SOE samples crash when running from ghci rather than
 compiling and running with ghc
Message-ID: <047.485ea5c57b8e879f2c33305a489b8545@localhost>

#2015: SOE samples crash when running from ghci rather than compiling and running
with ghc
-------------------------+--------------------------------------------------
    Reporter:  justinhj  |       Owner:          
        Type:  bug       |      Status:  new     
    Priority:  normal    |   Milestone:          
   Component:  GHCi      |     Version:  6.8.2   
    Severity:  normal    |    Keywords:  SOE ghci
  Difficulty:  Unknown   |    Testcase:          
Architecture:  Unknown   |          Os:  Windows 
-------------------------+--------------------------------------------------
 When running the SOE samples from http://haskell.org/soe/software1.htm
 I can compile and run at the command line fine, but if I use ghci instead
 of ghc I always get this error...

 {{{

 C:\cygwin\home\Justin\haskell\SOE\src>ghci
 GHCi, version 6.8.2: http://www.haskell.org/ghc/  :? for help
 Loading package base ... linking ... done.
 Prelude> :load test.hs
 Ok, modules loaded: Snowflake, Main, SOE.
 Prelude Main> main
 Loading package old-locale-1.0.0.0 ... linking ... done.
 Loading package old-time-1.0.0.0 ... linking ... done.
 Loading package OpenGL-2.2.1.1 ... linking ... done.
 Loading package GLFW-0.1 ... <interactive>: Unknown PEi386 section name
 `.reloc'
  (while processing: C:\Program
 Files\Haskell\GLFW-0.1\ghc-6.8.2/HSGLFW-0.1.o)
 : panic! (the 'impossible' happened)
   (GHC version 6.8.2 for i386-unknown-mingw32):
         loadObj: failed

 Please report this as a GHC bug:  http://www.haskell.org/ghc/reportabug

 }}}

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/2015>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Fri Jan  4 05:15:03 2008
From: trac at galois.com (GHC)
Date: Fri Jan  4 05:08:57 2008
Subject: [GHC] #2013: ghci crash on startup: R_X86_64_32S relocation out
 of range.
In-Reply-To: <044.2f007075e8a3e652be5aa7c77056c714@localhost>
References: <044.2f007075e8a3e652be5aa7c77056c714@localhost>
Message-ID: <053.16ee04bbc1dbdfdaafa1c3812a8e45af@localhost>

#2013: ghci crash on startup: R_X86_64_32S relocation out of range.
---------------------+------------------------------------------------------
 Reporter:  mboes    |          Owner:                
     Type:  bug      |         Status:  new           
 Priority:  normal   |      Milestone:  6.8.3         
Component:  GHCi     |        Version:  6.8.1         
 Severity:  normal   |     Resolution:                
 Keywords:           |     Difficulty:  Unknown       
 Testcase:           |   Architecture:  x86_64 (amd64)
       Os:  FreeBSD  |  
---------------------+------------------------------------------------------
Comment (by simonmar):

 See also Greg Wright's email in which he mentions exactly this problem:
 [http://www.haskell.org/pipermail/glasgow-haskell-
 users/2007-April/012291.html]

 In the HEAD, the fragment of code mentioned above is now gone, in favour
 of a more general mechanism.  You want the patch entitled "add PIC
 relocations for x86_64, and use a simpler hack in place of
 x86_64_high_symbol()" from HEAD.

 However, this on its own won't be enough: when we allocate memory for
 objects with `mmap()`, we need to get memory in the low 2Gb, which is why
 we use `MAP_32BIT` on Linux.  I'm not sure what the right way to do this
 on *BSD is, but you could try adding a hint address to the `mmap()` call,
 something in the low 2Gb, as Greg suggested in his mail above.

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/2013#comment:3>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From Christian.Maeder at dfki.de  Fri Jan  4 06:03:10 2008
From: Christian.Maeder at dfki.de (Christian Maeder)
Date: Fri Jan  4 05:57:05 2008
Subject: http://www.haskell.org/ghc/dist/mac_frameworks/GNUreadline-framework.zip
In-Reply-To: <200801032058.47615.naur@post11.tele.dk>
References: <477CE624.3040806@dfki.de>	<20080103151849.DJSH5833.fep27.mail.dk@matrix.matrix.chaos.earth.li>
	<200801032058.47615.naur@post11.tele.dk>
Message-ID: <477E126E.90301@dfki.de>

(Let's discuss this openly on glasgow-haskell-users)

I'm not happy about this framework hick-hack either. I've only pushed
it, because we needed a readline solution on macs.

The alternative is to use static linking of gmp (as suggested by chak)
_and_ readline (version 5), so that user programs are also statically
linked with these libs. Nobody supplied a binary distribution so far,
though. I only supplied the binary distributions that I (naively) made
anyway.

Regarding this actual GNUreadline-framework.zip replacement, this is
harmless and seems to matter only for those who build ghc with
frameworks (as only the inclusion of header files changed)

In any case we should strive to fix the frameworks issues _and_ add
support for static linking of gmp, readline and possibly other libs
(plus license issues).

HTH Christian

Thorkil Naur wrote:
> Hello,
> 
> Thanks everybody. However, I believe that using a modified readline library is 
> debatable, mainly because it adds the burden of keeping this library 
> up-to-date to the GHC maintenance process. Having a renamed library is one 
> thing and it does not seem that also modifying the contents of the library is 
> an improvement.  For me to consider this idea, it should be the very last 
> solution, every other stone having been turned. And I certainly believe that 
> stones remain to be turned in this case.
> 
> I would very much like to hear your comments to this.
> 
> In addition, if you must replace this framework with another with different 
> contents, I would suggest the use of some versioning scheme. Otherwise is 
> seems that a lot of confusion could result.
> 
> Thanks and best regards
> Thorkil
> 
> On Thursday 03 January 2008 16:18, Ian Lynagh wrote:
>> Hi Christian,
>>
>> On Thu, Jan 03, 2008 at 02:41:56PM +0100, Christian Maeder wrote:
>>> Judah's framework (2342543 Bytes)
>>> http://www.math.ucla.edu/~jjacobson/ghc/GNUreadline-framework.zip
>>>
>>> should replace (my old one)
>>> http://www.haskell.org/ghc/dist/mac_frameworks/GNUreadline-framework.zip
>> Done!
>>
>>
>> Thanks
>> Ian
>>
>>
From trac at galois.com  Fri Jan  4 07:27:13 2008
From: trac at galois.com (GHC)
Date: Fri Jan  4 07:21:07 2008
Subject: [GHC] #1012: ghc panic with mutually recursive modules and
 template haskell
In-Reply-To: <044.e3ec0fd0938800cc6a7ce608eb8687c2@localhost>
References: <044.e3ec0fd0938800cc6a7ce608eb8687c2@localhost>
Message-ID: <053.9824333cecd6210d24a1b2868b2c1ab6@localhost>

#1012: ghc panic with mutually recursive modules and template haskell
------------------------------+---------------------------------------------
 Reporter:  guest             |          Owner:            
     Type:  bug               |         Status:  closed    
 Priority:  normal            |      Milestone:  6.8 branch
Component:  Template Haskell  |        Version:  6.8.2     
 Severity:  normal            |     Resolution:  fixed     
 Keywords:                    |     Difficulty:  Unknown   
 Testcase:  TH_import_loop    |   Architecture:  Multiple  
       Os:  Multiple          |  
------------------------------+---------------------------------------------
Changes (by simonpj):

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

Comment:

 Simon is right: B.hs depends on C.hs, which depends on A.hs-boot.  I think
 it's quite accidental that A happens to be compiled before B in your
 "curiously enough" case, but after B in your original case.

 All you need do is to make B depend on A, thus
 {{{
 {-# LANGUAGE TemplateHaskell #-}
 module ModuleB where

 import ModuleC
 import ModuleA

 $(nothing)
 }}}
 and it all works fine.  Use -v to see the compilation order.

 I will clarify the documentation, thus:

    You can only run a function at compile time if it is imported from
 another module ''that is not part of a mutually-recursive group of modules
 that includes the module currently being compiled''.  Furthermore, all of
 the modules of the mutually-recursive group must be reachable by non-
 SOURCE imports from the module where the splice is to be run.

 {{{
 Fri Jan  4 12:19:39 GMT 2008  simonpj@microsoft.com
   * Document SOURCE pragma; clarify TH behavior for
     mutually-recurive modules (Trac #1012)
 }}}
 It's not clear to me how to improve the error message, at least not
 without adding more plumbing to say "I'm in a Template Haskell splice".
 Let's see if it happens again.

 Meanwhile I'll close the bug.

 Simon

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/1012#comment:11>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Fri Jan  4 07:58:03 2008
From: trac at galois.com (GHC)
Date: Fri Jan  4 07:52:00 2008
Subject: [GHC] #1509: Make unboxed tuples more supported
In-Reply-To: <044.1f30aaa9c80145fa2207f4959b5f6c5d@localhost>
References: <044.1f30aaa9c80145fa2207f4959b5f6c5d@localhost>
Message-ID: <053.b797de8f254ae9151c68e11fd6cba41e@localhost>

#1509: Make unboxed tuples more supported
-----------------------------+----------------------------------------------
 Reporter:  guest            |          Owner:         
     Type:  feature request  |         Status:  new    
 Priority:  low              |      Milestone:  _|_    
Component:  Compiler         |        Version:  6.6.1  
 Severity:  minor            |     Resolution:         
 Keywords:                   |     Difficulty:  Unknown
 Testcase:                   |   Architecture:  Unknown
       Os:  Unknown          |  
-----------------------------+----------------------------------------------
Comment (by simonpj):

 Note: current unboxed tuples are eta-expanded by `CorePrep` since
 `Id.hasNoBinding` returns True.  So we don't need to worry about
 generating curried versions of them.  Nor would be possible to do so,
 since unboxed tuples can have unboxed components of varying width; they
 are not parametrically polymorphic.

 See also `Note [Primop wrappers]` in `Id.lhs`.

 Simon

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/1509#comment:3>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Fri Jan  4 08:00:51 2008
From: trac at galois.com (GHC)
Date: Fri Jan  4 07:54:43 2008
Subject: [GHC] #2004: Pattern matching against GADTs without -XGADTs has
 odd behavior.
In-Reply-To: <044.b468022ed3fa4097df9a462be70e8e2e@localhost>
References: <044.b468022ed3fa4097df9a462be70e8e2e@localhost>
Message-ID: <053.9d6820a7f39c31f2675cf959c9406808@localhost>

#2004: Pattern matching against GADTs without -XGADTs has odd behavior.
-------------------------------------+--------------------------------------
 Reporter:  guest                    |          Owner:  simonpj    
     Type:  bug                      |         Status:  new        
 Priority:  normal                   |      Milestone:  6.10 branch
Component:  Compiler (Type checker)  |        Version:  6.8.1      
 Severity:  normal                   |     Resolution:             
 Keywords:                           |     Difficulty:  Unknown    
 Testcase:                           |   Architecture:  Unknown    
       Os:  Unknown                  |  
-------------------------------------+--------------------------------------
Comment (by simonpj):

 Turns out that if `-XGADTs` was not set when pattern matching on a GADT,
 we simply ignored the equational constraints.  This is silly.

 I've changed it so that `-XGADTs` is consulted only when deciding whether
 to permit the ''definition'' of a GADT, not to permit its use.  This is
 consistent with (eg) overlapping instances.

 Here's the note from TcPat
 {{{
 Note [Flags and equational constraints]
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 If there are equational constraints, we take account of them
 regardless of flag settings; -XGADTs etc applies only to the
 *definition* of a data type.

 An alternative would be also to reject a program that *used*
 constructors with equational constraints.  But want we should avoid at
 all costs is simply to *ignore* the constraints, since that gives
 incomprehensible errors (Trac #2004).
 }}}
 Probably worth merging into the 6.8 branch, but not a big deal:
 {{{
 Fri Jan  4 12:58:14 GMT 2008  simonpj@microsoft.com
   * Do not consult -XGADTs flag when pattern matching on GADTs
 }}}

 Simon

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/2004#comment:2>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Fri Jan  4 08:01:10 2008
From: trac at galois.com (GHC)
Date: Fri Jan  4 07:55:02 2008
Subject: [GHC] #2004: Pattern matching against GADTs without -XGADTs has
 odd behavior.
In-Reply-To: <044.b468022ed3fa4097df9a462be70e8e2e@localhost>
References: <044.b468022ed3fa4097df9a462be70e8e2e@localhost>
Message-ID: <053.d9207bd49c3c8d3cabbe7137d7aa4c46@localhost>

#2004: Pattern matching against GADTs without -XGADTs has odd behavior.
-------------------------------------+--------------------------------------
 Reporter:  guest                    |          Owner:  igloo      
     Type:  merge                    |         Status:  new        
 Priority:  normal                   |      Milestone:  6.10 branch
Component:  Compiler (Type checker)  |        Version:  6.8.1      
 Severity:  normal                   |     Resolution:             
 Keywords:                           |     Difficulty:  Unknown    
 Testcase:                           |   Architecture:  Unknown    
       Os:  Unknown                  |  
-------------------------------------+--------------------------------------
Changes (by simonpj):

  * owner:  simonpj => igloo
  * type:  bug => merge

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/2004#comment:3>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Fri Jan  4 08:02:59 2008
From: trac at galois.com (GHC)
Date: Fri Jan  4 07:56:54 2008
Subject: [GHC] #1012: ghc panic with mutually recursive modules and
 template haskell
In-Reply-To: <044.e3ec0fd0938800cc6a7ce608eb8687c2@localhost>
References: <044.e3ec0fd0938800cc6a7ce608eb8687c2@localhost>
Message-ID: <053.8cad3cd72c2ec6ad7791733a06913630@localhost>

#1012: ghc panic with mutually recursive modules and template haskell
------------------------------+---------------------------------------------
 Reporter:  guest             |          Owner:            
     Type:  bug               |         Status:  closed    
 Priority:  normal            |      Milestone:  6.8 branch
Component:  Template Haskell  |        Version:  6.8.2     
 Severity:  normal            |     Resolution:  fixed     
 Keywords:                    |     Difficulty:  Unknown   
 Testcase:  TH_import_loop    |   Architecture:  Multiple  
       Os:  Multiple          |  
------------------------------+---------------------------------------------
Comment (by fons):

 Replying to [comment:11 simonpj]:
 > Simon is right: B.hs depends on C.hs, which depends on A.hs-boot.  I
 think it's quite accidental that A happens to be compiled before B in your
 "curiously enough" case, but after B in your original case.
 >
 > All you need do is to make B depend on A, thus
 > {{{
 > {-# LANGUAGE TemplateHaskell #-}
 > module ModuleB where
 >
 > import ModuleC
 > import ModuleA
 >
 > $(nothing)
 > }}}
 > and it all works fine.  Use -v to see the compilation order.

 I finally managed to solve the problem "turning around" the circular
 dependencies of my project (tranforming the SOURCE imports of the loop in
 normal onces and vice versa). However, the workaround suggested by Simon
 should work as you said.


 > Meanwhile I'll close the bug.

 As far as I understand, ghc's dependency analysis could be improved
 (otherwise a workaround would not be needed). I don't personally think
 this bug should be closed and include it as a limitation in the docs
 before considering simonmar's proposal, that is:

 ''What's happening is that the dependency analysis isn't figuring out that
 the real ModuleA must be compiled before ModuleB. I think the solution is
 something along the lines of: every module that depends on a module in a
 cycle, but is not a member of that cycle, should have an implicit
 dependency on each of the modules in the cycle. ''

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/1012#comment:12>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Fri Jan  4 08:22:24 2008
From: trac at galois.com (GHC)
Date: Fri Jan  4 08:16:27 2008
Subject: [GHC] #1980: sporadic segmentation faults
In-Reply-To: <045.34c65a2a458babd045d171ffc0376518@localhost>
References: <045.34c65a2a458babd045d171ffc0376518@localhost>
Message-ID: <054.e6ecffb4041e83972cd756094b86cccc@localhost>

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

  * os:  Linux => Multiple
  * architecture:  x86 => Multiple

Comment:

 relevant for Macs and Solaris, too

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/1980#comment:8>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Fri Jan  4 08:29:02 2008
From: trac at galois.com (GHC)
Date: Fri Jan  4 08:22:54 2008
Subject: [GHC] #2016: GHC generates bad code for pointer manipulations from
 .cmm
Message-ID: <047.7e21adbce2d9f0fdc1af57fb709c258c@localhost>

#2016: GHC generates bad code for pointer manipulations from .cmm
-------------------------------+--------------------------------------------
    Reporter:  wb.kloke        |       Owner:         
        Type:  bug             |      Status:  new    
    Priority:  normal          |   Milestone:         
   Component:  Compiler        |     Version:  6.8.2  
    Severity:  major           |    Keywords:         
  Difficulty:  Unknown         |    Testcase:         
Architecture:  x86_64 (amd64)  |          Os:  FreeBSD
-------------------------------+--------------------------------------------
 In files rts/StgStdThunks.cmm (and rts/StgMiscClosures.cmm also) a
 natively booted x86_64 compiler generates the following wrong assembler
 output:

 {{{
 .text
         .align 8
         .quad   0
         .quad   34
 .globl stg_sel_ret_0_upd_info
 stg_sel_ret_0_upd_info:
         movl $4294967288,%eax
         movq %rbx,%rcx
         andq %rax,%rcx
         movq 8(%rcx),%rbx
         addq $8,%rbp
 ...
 }}}

 The correct code for the movl line is
 {{{
        movq $-8,%rax
 }}}

 The real output from a correct compiler (such as the stage1 compiler
 crosscompiled from i386) is slightly different due to optimisation, but
 equivalent to my correction.

 I checked this bug with different compilation flags in the stage1 and
 stage2 creation phase (with -fasm or -fvia-C). I am not sure whether the
 bug is present in other x86_64 OSs, which are supported for longer than
 FreeBSD. But it is easy to check. Just compile the file with -S with a
 stage2 compiler.

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/2016>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Fri Jan  4 09:30:29 2008
From: trac at galois.com (GHC)
Date: Fri Jan  4 09:24:29 2008
Subject: [GHC] #793: Use gcc's libffi to replace Adjustor.c and
 ByteCodeFFI.hs?
In-Reply-To: <047.bebe0ee1522997ea1300a5b9fc8eb59f@localhost>
References: <047.bebe0ee1522997ea1300a5b9fc8eb59f@localhost>
Message-ID: <056.f3d67caeda3a9c3215e8f48dd1f832fe@localhost>

#793: Use gcc's libffi to replace Adjustor.c and ByteCodeFFI.hs?
----------------------------+-----------------------------------------------
 Reporter:  simonmar        |          Owner:  simonmar        
     Type:  task            |         Status:  new             
 Priority:  normal          |      Milestone:  6.8 branch      
Component:  Runtime System  |        Version:  6.4.1           
 Severity:  normal          |     Resolution:                  
 Keywords:                  |     Difficulty:  Moderate (1 day)
 Testcase:  N/A             |   Architecture:  Unknown         
       Os:  Unknown         |  
----------------------------+-----------------------------------------------
Comment (by simonmar):

 Replying to [comment:8 igloo]:
 > I don't think we should bundle it. It's the sort of thing where more
 obscure platforms need the latest version, and we don't another thing we
 have to make sure we keep up-to-date. Also, for the common case (including
 Windows users) it isn't necessary to have it, as the existing code can be
 used instead.

 I agree, except that I've just done a bit of digging and libffi would fix:

  * #1288 (stdcall in GHCi on Windows)
  * #738 (SELinux)
  * #631 (FFI in GHCi unregisterised)

 For #738, we could pinch the code from `libffi` which works around the
 issue (the license is unrestrictive).  For #1288, I'd rather just use
 `libffi` than implement it myself, but that means requiring `libffi` on
 Windows.  For #631, I assume it's not a problem to require `libffi` for
 unregisterised builds.

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/793#comment:9>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Fri Jan  4 09:59:56 2008
From: trac at galois.com (GHC)
Date: Fri Jan  4 09:53:48 2008
Subject: [GHC] #2016: GHC generates bad code for pointer manipulations
 from .cmm
In-Reply-To: <047.7e21adbce2d9f0fdc1af57fb709c258c@localhost>
References: <047.7e21adbce2d9f0fdc1af57fb709c258c@localhost>
Message-ID: <056.1fc5e88b17fc3afefd4bb55b7f44167a@localhost>

#2016: GHC generates bad code for pointer manipulations from .cmm
----------------------+-----------------------------------------------------
 Reporter:  wb.kloke  |          Owner:                
     Type:  bug       |         Status:  closed        
 Priority:  normal    |      Milestone:                
Component:  Compiler  |        Version:  6.8.2         
 Severity:  major     |     Resolution:  duplicate     
 Keywords:            |     Difficulty:  Unknown       
 Testcase:            |   Architecture:  x86_64 (amd64)
       Os:  FreeBSD   |  
----------------------+-----------------------------------------------------
Changes (by simonmar):

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

Comment:

 I strongly suspect you are experiencing another symptom of #1989.  The
 code is compiled correctly for me:

 {{{
 ~/builds/testing/rts > make StgStdThunks.s HC=../compiler/stage2/ghc-
 inplace
 ../compiler/stage2/ghc-inplace -Werror -H64m -Onot -fasm -optc-O2
 -I../includes -I. -Iparallel -Ism -DCOMPILING_RTS -package-name rts
 -static -I../gmp/gmpbuild -I. -#include HCIncludes.h -dcmm-lint     -S
 StgStdThunks.cmm -o StgStdThunks.s
 ~/builds/testing/rts > head -50 StgStdThunks.s
 .text
         .align 8
         .quad   0
         .quad   34
 .globl stg_sel_ret_0_upd_info
 .type stg_sel_ret_0_upd_info, @object
 stg_sel_ret_0_upd_info:
 .Lcg:
         movq %rbx,%rax
         andq $-8,%rax
         movq 8(%rax),%rbx
         addq $8,%rbp
 .Lc3:
         testq $7,%rbx
         jne .Lce
 .Lcd:
         movq (%rbx),%rax
         movslq -8(%rax),%rcx
         jmp *.Lnea(,%rcx,8)
 .Lcb:
         movq 8(%rbx),%rbx
         jmp .Lc3
 .Lca:
         jmp *(%rbp)
 .Lcc:
         jmp *%rax
 .Lce:
         jmp *(%rbp)
 }}}

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/2016#comment:1>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Fri Jan  4 10:44:52 2008
From: trac at galois.com (GHC)
Date: Fri Jan  4 10:39:33 2008
Subject: [GHC] #1395: let ./configure check for a GNUreadline framework
In-Reply-To: <052.068bc0f583c08a182f51a06ad4864715@localhost>
References: <052.068bc0f583c08a182f51a06ad4864715@localhost>
Message-ID: <061.b9196af657d90bcc62259fd882344213@localhost>

#1395: let ./configure check for a GNUreadline framework
-----------------------------+----------------------------------------------
 Reporter:  maeder@tzi.de    |          Owner:             
     Type:  feature request  |         Status:  reopened   
 Priority:  normal           |      Milestone:  6.8 branch 
Component:  Build System     |        Version:  6.8        
 Severity:  normal           |     Resolution:             
 Keywords:                   |     Difficulty:  Easy (1 hr)
 Testcase:                   |   Architecture:  Multiple   
       Os:  MacOS X          |  
-----------------------------+----------------------------------------------
Comment (by maeder):

 Instead of modifying `hsc2hs` it is possible to add

 {{{
                    --hsc2hs-options="-C -F$(HOME)/Library/Frameworks" \
 }}}

 to libraries/Makefile (as line 246). I'll attach a patch that works on
 other platforms, too.

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/1395#comment:28>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Fri Jan  4 13:07:52 2008
From: trac at galois.com (GHC)
Date: Fri Jan  4 13:01:49 2008
Subject: [GHC] #1989: GHC-6.8.1 fails arith003 on amd64/FreeBSD-7.0
In-Reply-To: <047.e1a81f31ca9bdca7e0fd42494374e2fa@localhost>
References: <047.e1a81f31ca9bdca7e0fd42494374e2fa@localhost>
Message-ID: <056.c85f1944a4b7134154986543c2e68dea@localhost>

#1989: GHC-6.8.1 fails arith003 on amd64/FreeBSD-7.0
----------------------+-----------------------------------------------------
 Reporter:  wb.kloke  |          Owner:                
     Type:  bug       |         Status:  new           
 Priority:  normal    |      Milestone:  6.8.3         
Component:  Compiler  |        Version:  6.8.2         
 Severity:  normal    |     Resolution:                
 Keywords:            |     Difficulty:  Unknown       
 Testcase:            |   Architecture:  x86_64 (amd64)
       Os:  FreeBSD   |  
----------------------+-----------------------------------------------------
Comment (by wb.kloke):

 This problem was caused by some code from the bootstrap compiler
 hibernating in the compat library. It seems advisable to rebuild compat
 after building compiler/stage1 with the new compiler if this is
 sufficiently different from the bootstrap compiler.

 This ticket may be either closed or changed to the request above. The
 error reported in #1620 was indeed caused by the same issue, as Simon
 Marlow correctly suggested.

 The perl script driver/ghc-asm.lprl has to be changed for FreeBSD-amd64
 support.

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/1989#comment:4>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Sat Jan  5 12:14:21 2008
From: trac at galois.com (GHC)
Date: Sat Jan  5 12:08:11 2008
Subject: [GHC] #2017: Normal Guards are internally spliced as Pattern Guards
 causing compiler warnings
Message-ID: <043.0257207c9ea5e0a53cd58c7799a3a94d@localhost>

#2017: Normal Guards are internally spliced as Pattern Guards causing compiler
warnings
---------------------------------+------------------------------------------
    Reporter:  fons              |       Owner:         
        Type:  bug               |      Status:  new    
    Priority:  normal            |   Milestone:         
   Component:  Template Haskell  |     Version:  6.8.2  
    Severity:  normal            |    Keywords:         
  Difficulty:  Unknown           |    Testcase:         
Architecture:  Unknown           |          Os:  Unknown
---------------------------------+------------------------------------------
 Here is an example

 Foo.hs
 {{{
 {-# OPTIONS_GHC -XTemplateHaskell -ddump-splices #-}

 module Foo where

 import Language.Haskell.TH

 $(do e <- [d| f a b
                 | a == b = a
                 | otherwise = b |]
      runIO (putStrLn $ show e)
      return e)
 }}}

 The example shows that even if the quasiquotes lift the declarations as
 normal guards, they are, for some reson, internally spliced as equivalent
 pattern guards. That shouldn't be a big problem as long as the compiler
 didn't cause warnings for it.


 See the compilation result:

 {{{
 $ ghci Foo.hs
 GHCi, version 6.8.2: http://www.haskell.org/ghc/  :? for help
 Loading package base ... linking ... done.
 [1 of 1] Compiling Foo              ( Foo.hs, interpreted )
 Loading package array-0.1.0.0 ... linking ... done.
 Loading package packedstring-0.1.0.0 ... linking ... done.
 Loading package pretty-1.0.0.0 ... linking ... done.
 Loading package containers-0.1.0.1 ... linking ... done.
 Loading package template-haskell ... linking ... done.
 [FunD f [Clause [VarP a_1627394778,VarP b_1627394779] (GuardedB [(NormalG
 (InfixE (Just (VarE a_1627394778)) (VarE GHC.Base.==) (Just (VarE
 b_1627394779))),VarE a_1627394778),(NormalG (VarE GHC.Base.otherwise),VarE
 b_1627394779)]) []]]
 Foo.hs:1:0:
     Foo.hs:1:0: Splicing declarations
         let
           >>= = (>>=) @ Q $dMonad
           $dMonad = $dMonad
           >> = (>>) @ Q $dMonad
           $dMonad = Language.Haskell.TH.Syntax.$f22
           show = show @ [Dec] $dShow
           $dShow = GHC.Show.$f21 @ Dec $dShow
           $dShow = Language.Haskell.TH.Syntax.$f52
           return = return @ Q $dMonad
           $dMonad = $dMonad
         in
           do e <- [d| :THFake.f a b
                                   | a == b = a
                                   | otherwise = b |]
              runIO @ () (($) @ String @ (IO ()) putStrLn show e)
              return @ [Dec] e
       ======>
         Foo.hs:(7,2)-(11,12)
         f a[a1fQ] b[a1fR]
             | True <- (a[a1fQ] `GHC.Base.==` b[a1fR]) = a[a1fQ]
             | True <- GHC.Base.otherwise = b[a1fR]

 Foo.hs:7:2:
     Warning: accepting non-standard pattern guards (use -XPatternGuards to
 suppress this message)
                  True <- (a[a1fQ] == b[a1fR])

 Foo.hs:7:2:
     Warning: accepting non-standard pattern guards (use -XPatternGuards to
 suppress this message)
                  True <- otherwise
 Ok, modules loaded: Foo.
 *Foo>
 }}}

 The logical thing a user would expect is to see the guards spliced as:

 {{{
    | (a[a1fQ] `GHC.Base.==` b[a1fR]) = a[a1fQ]
 }}}

 and not

 {{{
    | True <- (a[a1fQ] `GHC.Base.==` b[a1fR]) = a[a1fQ]
 }}}


 As expected and suggested by the compiler the warnings are silenced with
 the -XPatternGuards.

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/2017>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Sun Jan  6 02:09:16 2008
From: trac at galois.com (GHC)
Date: Sun Jan  6 02:03:05 2008
Subject: [GHC] #2018: Interface file error with GADT and -O1
Message-ID: <053.c8166aa67d18eb09eef50518c042c0a1@localhost>

#2018: Interface file error with GADT and -O1
-------------------------------+--------------------------------------------
    Reporter:  Ashley Yakeley  |       Owner:       
        Type:  bug             |      Status:  new  
    Priority:  normal          |   Milestone:       
   Component:  Compiler        |     Version:  6.8.2
    Severity:  normal          |    Keywords:       
  Difficulty:  Unknown         |    Testcase:       
Architecture:  x86_64 (amd64)  |          Os:  Linux
-------------------------------+--------------------------------------------
 I've tried to simplify this as much as possible. In particular, the bug
 goes away if -O1 is removed.

 {{{
 module Bug1 where

 data A a where
   MkA :: A ()

 class C w where
   f :: forall a . w a -> Maybe a

 instance C A where
   f MkA  = Just ()
 }}}

 {{{
 module Bug2 where
 import Bug1

 f' :: A a -> Maybe a
 f' = f
 }}}

 Run with this:

 {{{
 #!/bin/sh
 rm -f *.hi *.o
 ghc --version
 ghc -c -XGADTs -XRankNTypes -O1 Bug1.hs
 ghc -c -XGADTs -XRankNTypes -O1 Bug2.hs
 }}}

 This is the result I get:

 {{{
 The Glorious Glasgow Haskell Compilation System, version 6.8.2
 Bug1.hi
 Declaration for a:
   Iface type variable out of scope:  a
 Cannot continue after interface file error
 }}}

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/2018>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Sun Jan  6 07:56:14 2008
From: trac at galois.com (GHC)
Date: Sun Jan  6 07:50:09 2008
Subject: [GHC] #1980: sporadic segmentation faults
In-Reply-To: <045.34c65a2a458babd045d171ffc0376518@localhost>
References: <045.34c65a2a458babd045d171ffc0376518@localhost>
Message-ID: <054.ea38dd2048c1a467670d54493baf604f@localhost>

#1980: sporadic segmentation faults
----------------------------+-----------------------------------------------
 Reporter:  maeder          |          Owner:  igloo   
     Type:  merge           |         Status:  closed  
 Priority:  normal          |      Milestone:  6.8.3   
Component:  Runtime System  |        Version:  6.8.2   
 Severity:  normal          |     Resolution:  fixed   
 Keywords:                  |     Difficulty:  Unknown 
 Testcase:                  |   Architecture:  Multiple
       Os:  Multiple        |  
----------------------------+-----------------------------------------------
Changes (by igloo):

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

Comment:

 Merged

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/1980#comment:9>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Sun Jan  6 07:57:49 2008
From: trac at galois.com (GHC)
Date: Sun Jan  6 07:51:35 2008
Subject: [GHC] #2004: Pattern matching against GADTs without -XGADTs has
 odd behavior.
In-Reply-To: <044.b468022ed3fa4097df9a462be70e8e2e@localhost>
References: <044.b468022ed3fa4097df9a462be70e8e2e@localhost>
Message-ID: <053.940b33af6f714052970800deeaaedecb@localhost>

#2004: Pattern matching against GADTs without -XGADTs has odd behavior.
-------------------------------------+--------------------------------------
 Reporter:  guest                    |          Owner:  igloo      
     Type:  merge                    |         Status:  closed     
 Priority:  normal                   |      Milestone:  6.10 branch
Component:  Compiler (Type checker)  |        Version:  6.8.1      
 Severity:  normal                   |     Resolution:  fixed      
 Keywords:                           |     Difficulty:  Unknown    
 Testcase:                           |   Architecture:  Unknown    
       Os:  Unknown                  |  
-------------------------------------+--------------------------------------
Changes (by igloo):

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

Comment:

 Merged

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/2004#comment:4>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Sun Jan  6 07:58:23 2008
From: trac at galois.com (GHC)
Date: Sun Jan  6 07:52:10 2008
Subject: [GHC] #2000: -funfolding-update-in-place badly documented
In-Reply-To: <045.ac76dc598481f3a493531a6d155a8b48@localhost>
References: <045.ac76dc598481f3a493531a6d155a8b48@localhost>
Message-ID: <054.3799d48a4b4b9cfa9fe0b2b37917d600@localhost>

#2000: -funfolding-update-in-place badly documented
----------------------+-----------------------------------------------------
 Reporter:  m4dc4p    |          Owner:  igloo  
     Type:  merge     |         Status:  closed 
 Priority:  normal    |      Milestone:  6.8.3  
Component:  Compiler  |        Version:  6.8.1  
 Severity:  normal    |     Resolution:  fixed  
 Keywords:            |     Difficulty:  Unknown
 Testcase:            |   Architecture:  x86    
       Os:  Windows   |  
----------------------+-----------------------------------------------------
Changes (by igloo):

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

Comment:

 Merged

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/2000#comment:5>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Sun Jan  6 07:59:42 2008
From: trac at galois.com (GHC)
Date: Sun Jan  6 07:54:34 2008
Subject: [GHC] #1981: panic when compiling record implementation using
 type families
In-Reply-To: <046.fe36da3c443f822335ef20d9f6a45708@localhost>
References: <046.fe36da3c443f822335ef20d9f6a45708@localhost>
Message-ID: <055.259db4670bb0d1980f03bc70f8dd9a1f@localhost>

#1981: panic when compiling record implementation using type families
----------------------+-----------------------------------------------------
 Reporter:  jeltsch   |          Owner:  igloo  
     Type:  merge     |         Status:  closed 
 Priority:  normal    |      Milestone:         
Component:  Compiler  |        Version:  6.8.2  
 Severity:  normal    |     Resolution:  fixed  
 Keywords:            |     Difficulty:  Unknown
 Testcase:  T1981     |   Architecture:  x86    
       Os:  Linux     |  
----------------------+-----------------------------------------------------
Changes (by igloo):

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

Comment:

 Merged

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/1981#comment:5>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Sun Jan  6 08:05:29 2008
From: trac at galois.com (GHC)
Date: Sun Jan  6 07:59:29 2008
Subject: [GHC] #1495: newtype fixpoint sends the compiler into an
 infinite loop
In-Reply-To: <044.6381e40719ef0688225ef3c22fd168e3@localhost>
References: <044.6381e40719ef0688225ef3c22fd168e3@localhost>
Message-ID: <053.a591f45cfbb202a3fcd65844036c34a6@localhost>

#1495: newtype fixpoint sends the compiler into an infinite loop
----------------------+-----------------------------------------------------
 Reporter:  guest     |          Owner:  igloo   
     Type:  merge     |         Status:  closed  
 Priority:  normal    |      Milestone:  6.8.3   
Component:  Compiler  |        Version:  6.6.1   
 Severity:  minor     |     Resolution:  fixed   
 Keywords:            |     Difficulty:  Unknown 
 Testcase:  T1495     |   Architecture:  Multiple
       Os:  Multiple  |  
----------------------+-----------------------------------------------------
Changes (by igloo):

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

Comment:

 Merged (it pulled cleanly)

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/1495#comment:10>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Sun Jan  6 08:06:21 2008
From: trac at galois.com (GHC)
Date: Sun Jan  6 08:00:06 2008
Subject: [GHC] #2011: [6.8.1 regression] panic: lookupVers1
 base:GHC.Prim sym{tc}
In-Reply-To: <047.5794bcb02e44dfb8bb70a89a113f27e3@localhost>
References: <047.5794bcb02e44dfb8bb70a89a113f27e3@localhost>
Message-ID: <056.b1443dc2e4e7caf73696b9ff7cd55dbf@localhost>

#2011: [6.8.1 regression] panic: lookupVers1 base:GHC.Prim sym{tc}
----------------------+-----------------------------------------------------
 Reporter:  simonmar  |          Owner:  igloo  
     Type:  merge     |         Status:  closed 
 Priority:  high      |      Milestone:  6.8.3  
Component:  Compiler  |        Version:  6.8.2  
 Severity:  normal    |     Resolution:  fixed  
 Keywords:            |     Difficulty:  Unknown
 Testcase:            |   Architecture:  Unknown
       Os:  Unknown   |  
----------------------+-----------------------------------------------------
Changes (by igloo):

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

Comment:

 Merged

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/2011#comment:2>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Sun Jan  6 08:06:42 2008
From: trac at galois.com (GHC)
Date: Sun Jan  6 08:00:29 2008
Subject: [GHC] #1988: [6.8.1 regression] 6.8.2 panics in nameModule with
 -O2
In-Reply-To: <044.4236adaadc94918ceb8351bc299dba42@localhost>
References: <044.4236adaadc94918ceb8351bc299dba42@localhost>
Message-ID: <053.b8652b9839683eddb77c4ea187269003@localhost>

#1988: [6.8.1 regression] 6.8.2 panics in nameModule with -O2
----------------------+-----------------------------------------------------
 Reporter:  guest     |          Owner:  igloo  
     Type:  merge     |         Status:  closed 
 Priority:  high      |      Milestone:  6.8.3  
Component:  Compiler  |        Version:  6.8.2  
 Severity:  normal    |     Resolution:  fixed  
 Keywords:            |     Difficulty:  Unknown
 Testcase:  T1988     |   Architecture:  x86    
       Os:  MacOS X   |  
----------------------+-----------------------------------------------------
Changes (by igloo):

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

Comment:

 Merged

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/1988#comment:3>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Sun Jan  6 08:07:22 2008
From: trac at galois.com (GHC)
Date: Sun Jan  6 08:01:09 2008
Subject: [GHC] #1898: segfault with +RTS -N2 (related to tryTakeMVar?)
In-Reply-To: <049.0881d74ddf1057ac706f274f5a37f964@localhost>
References: <049.0881d74ddf1057ac706f274f5a37f964@localhost>
Message-ID: <058.7e04a1336ab0d3779f22fe8c5beb5ed3@localhost>

#1898: segfault with +RTS -N2 (related to tryTakeMVar?)
------------------------+---------------------------------------------------
 Reporter:  j.waldmann  |          Owner:  igloo  
     Type:  merge       |         Status:  closed 
 Priority:  high        |      Milestone:  6.8.3  
Component:  Compiler    |        Version:  6.8.1  
 Severity:  normal      |     Resolution:  fixed  
 Keywords:              |     Difficulty:  Unknown
 Testcase:              |   Architecture:  x86    
       Os:  Linux       |  
------------------------+---------------------------------------------------
Changes (by igloo):

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

Comment:

 Merged

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/1898#comment:7>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Sun Jan  6 09:19:47 2008
From: trac at galois.com (GHC)
Date: Sun Jan  6 09:13:32 2008
Subject: [GHC] #2019: GADT record with polytype argument causes irrefutable
 pattern failure in basicTypes/MkId.lhs
Message-ID: <045.791b8f9a465ed91be02dc1a0633e357f@localhost>

#2019: GADT record with polytype argument causes irrefutable pattern failure in
basicTypes/MkId.lhs
-------------------------+--------------------------------------------------
    Reporter:  japple    |       Owner:       
        Type:  bug       |      Status:  new  
    Priority:  normal    |   Milestone:       
   Component:  Compiler  |     Version:  6.8.2
    Severity:  normal    |    Keywords:       
  Difficulty:  Unknown   |    Testcase:       
Architecture:  x86       |          Os:  Linux
-------------------------+--------------------------------------------------
 {{{
 data GADTRecordPoly a n where
     G {val :: a} :: GADTRecordPoly a (forall n . n)
 }}}
 causes

 *** Exception: basicTypes/MkId.lhs:642:8-70: Irrefutable pattern failed
 for pattern Maybes.Succeeded refinement

 when loaded in GHCi

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/2019>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Sun Jan  6 11:08:54 2008
From: trac at galois.com (GHC)
Date: Sun Jan  6 11:02:42 2008
Subject: [GHC] #1349: Generalise the ! and UNPACK mechanism for data
 types, to unpack function arguments
In-Reply-To: <046.9dd17815048ce25749ab5bff260d2925@localhost>
References: <046.9dd17815048ce25749ab5bff260d2925@localhost>
Message-ID: <055.98a98dd06b2737f53eb0197698eaa293@localhost>

#1349: Generalise the ! and UNPACK mechanism for data types, to unpack function
arguments
----------------------+-----------------------------------------------------
 Reporter:  simonpj   |          Owner:             
     Type:  task      |         Status:  new        
 Priority:  normal    |      Milestone:  6.10 branch
Component:  Compiler  |        Version:  6.6.1      
 Severity:  normal    |     Resolution:             
 Keywords:            |     Difficulty:  Unknown    
 Testcase:            |   Architecture:  Unknown    
       Os:  Unknown   |  
----------------------+-----------------------------------------------------
Comment (by Isaac Dupree):

 Strictness annotations in function results don't make sense (for the same
 reason `id` is strict -- function results are "already WHNF-strict" as
 much as it makes sense), and they're already lifted (in the sense that
 they can possibly produce _|_) even for unboxed result types (e.g. {{{bot
 :: () -> Int#; bot x = bot x}}}).  But unboxing a result-tuple can result
 in a loss of sharing, so in
 {{{
 newtype State s a
         = State
         { runState' :: s -> (# a, s #) }
 }}}
 the unboxedness of the tuple really is significant for efficiency reasons,
 to tell GHC that it doesn't need to preserve sharing. See
 http://www.nabble.com/there-isn%27t-any-difference%2C-is-there%2C-with-
 unboxed-tuples--to14629139.html

 So I also want a function-result-syntax of UNPACK, presumably without an
 intervening meaningless strictness annotation:
 {{{
 newtype State s a
         = State
         { runState' :: s -> {-# UNPACK #-} ( a, s ) }
 }}}

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/1349#comment:4>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Sun Jan  6 11:12:07 2008
From: trac at galois.com (GHC)
Date: Sun Jan  6 11:05:52 2008
Subject: [GHC] #1963: Pressing ^C at the right moment can trash GHC's
 package list
In-Reply-To: <044.fe68034f1a304106efaa8e4a323fded8@localhost>
References: <044.fe68034f1a304106efaa8e4a323fded8@localhost>
Message-ID: <053.c05b289ae3ce84cb0c318a33ec91e998@localhost>

#1963: Pressing ^C at the right moment can trash GHC's package list
----------------------+-----------------------------------------------------
 Reporter:  igloo     |          Owner:  igloo  
     Type:  merge     |         Status:  closed 
 Priority:  normal    |      Milestone:  6.8.3  
Component:  Compiler  |        Version:  6.8.1  
 Severity:  normal    |     Resolution:  fixed  
 Keywords:            |     Difficulty:  Unknown
 Testcase:            |   Architecture:  Unknown
       Os:  Unknown   |  
----------------------+-----------------------------------------------------
Changes (by igloo):

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

Comment:

 Merged

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/1963#comment:3>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Sun Jan  6 11:23:57 2008
From: trac at galois.com (GHC)
Date: Sun Jan  6 11:17:44 2008
Subject: [GHC] #2019: GADT record with polytype argument causes
 irrefutable pattern failure in basicTypes/MkId.lhs
In-Reply-To: <045.791b8f9a465ed91be02dc1a0633e357f@localhost>
References: <045.791b8f9a465ed91be02dc1a0633e357f@localhost>
Message-ID: <054.fc236aeaae6782a256b1be4980491299@localhost>

#2019: GADT record with polytype argument causes irrefutable pattern failure in
basicTypes/MkId.lhs
----------------------+-----------------------------------------------------
 Reporter:  japple    |          Owner:         
     Type:  bug       |         Status:  new    
 Priority:  normal    |      Milestone:  6.8.3  
Component:  Compiler  |        Version:  6.8.2  
 Severity:  normal    |     Resolution:         
 Keywords:            |     Difficulty:  Unknown
 Testcase:            |   Architecture:  x86    
       Os:  Linux     |  
----------------------+-----------------------------------------------------
Changes (by igloo):

  * milestone:  => 6.8.3

Comment:

 Thanks for the report; confirmed, with:
 {{{
 ghci -XGADTs -XPolymorphicComponents v.hs
 }}}

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/2019#comment:1>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Sun Jan  6 13:19:49 2008
From: trac at galois.com (GHC)
Date: Sun Jan  6 13:13:35 2008
Subject: [GHC] #1349: Generalise the ! and UNPACK mechanism for data
 types, to unpack function arguments
In-Reply-To: <046.9dd17815048ce25749ab5bff260d2925@localhost>
References: <046.9dd17815048ce25749ab5bff260d2925@localhost>
Message-ID: <055.9883d698fa8a466ca4e123b3aa833b79@localhost>

#1349: Generalise the ! and UNPACK mechanism for data types, to unpack function
arguments
----------------------+-----------------------------------------------------
 Reporter:  simonpj   |          Owner:             
     Type:  task      |         Status:  new        
 Priority:  normal    |      Milestone:  6.10 branch
Component:  Compiler  |        Version:  6.6.1      
 Severity:  normal    |     Resolution:             
 Keywords:            |     Difficulty:  Unknown    
 Testcase:            |   Architecture:  Unknown    
       Os:  Unknown   |  
----------------------+-----------------------------------------------------
Comment (by duncan):

 Replying to [comment:3 Isaac Dupree]:
 > seems tricky. I hope it can be done in a way that makes the language
 feel no more complicated. e.g.
 > {{{
 > type F = !Int -> Foo
 > data Foo where C :: F
 > }}}

 This feature request is not about distinguishing strictness in types as
 the above would indicate. It's about changing the strictness and data
 representation of data type constructors that have higher order
 components.

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/1349#comment:5>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Sun Jan  6 14:49:40 2008
From: trac at galois.com (GHC)
Date: Sun Jan  6 14:43:38 2008
Subject: [GHC] #1777: Refactor the implementation of arrow notation
In-Reply-To: <046.63b5bec87dcae7ef0abe8b264d5d1cef@localhost>
References: <046.63b5bec87dcae7ef0abe8b264d5d1cef@localhost>
Message-ID: <055.ae2c7317b676152c8efa4c9e62f92981@localhost>

#1777: Refactor the implementation of arrow notation
----------------------+-----------------------------------------------------
 Reporter:  simonpj   |          Owner:  ross       
     Type:  task      |         Status:  new        
 Priority:  normal    |      Milestone:  6.10 branch
Component:  Compiler  |        Version:  6.6.1      
 Severity:  normal    |     Resolution:             
 Keywords:            |     Difficulty:  Unknown    
 Testcase:            |   Architecture:  Unknown    
       Os:  Unknown   |  
----------------------+-----------------------------------------------------
Comment (by clanehin):

 I believe that this is an example of the problem:

 {{{
 arrowAddInt :: (Arrow a) => a Integer (forall n. (Num n) => n -> n)
 arrowAddInt = proc n -> returnA -< (+ fromInteger n)

     Cannot match a monotype with `forall n. (Num n) => n -> n'
       Expected type: a b (forall n. (Num n) => n -> n)
       Inferred type: a b b
     In the expression: proc n -> returnA -< (+ (fromInteger n))
     In the definition of `arrowAddInt':
         arrowAddInt = proc n -> returnA -< (+ (fromInteger n))
 }}}

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/1777#comment:2>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Sun Jan  6 23:04:15 2008
From: trac at galois.com (GHC)
Date: Sun Jan  6 22:57:59 2008
Subject: [GHC] #2020: configure script shipped with ghc is built by broken
 version of autoconf
Message-ID: <042.e78128d4b8de30e1332500e785efc22a@localhost>

#2020: configure script shipped with ghc is built by broken version of autoconf
-------------------------+--------------------------------------------------
    Reporter:  bos       |       Owner:         
        Type:  bug       |      Status:  new    
    Priority:  normal    |   Milestone:         
   Component:  Compiler  |     Version:  6.8.2  
    Severity:  normal    |    Keywords:         
  Difficulty:  Unknown   |    Testcase:         
Architecture:  Unknown   |          Os:  Unknown
-------------------------+--------------------------------------------------
 I've been looking into a downstream packaging problem:

 https://bugzilla.redhat.com/show_bug.cgi?id=237398

 The problem in question being that package.conf contains incorrect paths
 to haddock directories.

 I tried to address this problem in the obvious way.  Unfortunately, when I
 pass --docdir to the configure script that ships with GHC 6.8.1 and 6.8.2,
 an option that configure claims it supports, I get an error:

 ghc-6.8.2 $ ./configure --docdir=/tmp
 configure: error: unrecognized option: --docdir=/tmp
 Try `./configure --help' for more information.

 This is due to configure being built by autoconf 2.59.  If I regenerate
 the configure script using autoconf 2.61, it parses the --docdir argument
 correctly.

 I've got a temporary workaround in the Fedora packaging spec that runs
 autoreconf before configure, but it would be best if this were addressed
 in GHC itself.

 Please upgrade the version of autoconf that you use prior to the next
 release.

 Thanks!

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/2020>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Sun Jan  6 23:22:19 2008
From: trac at galois.com (GHC)
Date: Sun Jan  6 23:16:03 2008
Subject: [GHC] #2020: configure script shipped with ghc is built by
 broken version of autoconf
In-Reply-To: <042.e78128d4b8de30e1332500e785efc22a@localhost>
References: <042.e78128d4b8de30e1332500e785efc22a@localhost>
Message-ID: <051.c0c399ef8d925767139f79f9005d8184@localhost>

#2020: configure script shipped with ghc is built by broken version of autoconf
----------------------+-----------------------------------------------------
 Reporter:  bos       |          Owner:         
     Type:  bug       |         Status:  new    
 Priority:  normal    |      Milestone:         
Component:  Compiler  |        Version:  6.8.2  
 Severity:  normal    |     Resolution:         
 Keywords:            |     Difficulty:  Unknown
 Testcase:            |   Architecture:  Unknown
       Os:  Unknown   |  
----------------------+-----------------------------------------------------
Comment (by bos):

 This didn't occur to me at the time, but if you rebuild configure in the
 ghc directory, you'll have to rebuild it in each of the libraries
 directories too.

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/2020#comment:1>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Mon Jan  7 05:07:57 2008
From: trac at galois.com (GHC)
Date: Mon Jan  7 05:02:15 2008
Subject: [GHC] #1838: do not use getEnv "HOME",
 use System.Directory.getHomeDirectory
In-Reply-To: <044.7c14aad23d72fc1f99272ac17d7d5b67@localhost>
References: <044.7c14aad23d72fc1f99272ac17d7d5b67@localhost>
Message-ID: <053.bab6c9c483cb60a9ab8fa08a8c432b03@localhost>

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

  * priority:  normal => high

Comment:

 We definitely need to resolve this for 6.8.3.

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/1838#comment:4>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Mon Jan  7 05:42:02 2008
From: trac at galois.com (GHC)
Date: Mon Jan  7 05:35:46 2008
Subject: [GHC] #955: more object-code blow-up in ghc-6.6 vs. ghc-6.4.2
 (both with optimization)
In-Reply-To: <052.784670e095eb0d591995e903dae303b2@localhost>
References: <052.784670e095eb0d591995e903dae303b2@localhost>
Message-ID: <061.e96511daeef3e3d31691098850395277@localhost>

#955: more object-code blow-up in ghc-6.6 vs. ghc-6.4.2 (both with optimization)
--------------------------------------+-------------------------------------
 Reporter:  maeder@tzi.de             |          Owner:          
     Type:  run-time performance bug  |         Status:  new     
 Priority:  high                      |      Milestone:  6.8.3   
Component:  Compiler                  |        Version:  6.6     
 Severity:  normal                    |     Resolution:          
 Keywords:  object-code blow-up       |     Difficulty:  Unknown 
 Testcase:                            |   Architecture:  Multiple
       Os:  Multiple                  |  
--------------------------------------+-------------------------------------
Changes (by simonmar):

  * type:  bug => run-time performance bug

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/955#comment:5>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Mon Jan  7 05:42:30 2008
From: trac at galois.com (GHC)
Date: Mon Jan  7 05:36:12 2008
Subject: [GHC] #1136: High memory use when compiling many let bindings.
In-Reply-To: <044.2f9aae100a9caba688d31e410efb3444@localhost>
References: <044.2f9aae100a9caba688d31e410efb3444@localhost>
Message-ID: <053.310a074218c955da77ff17f963d3f601@localhost>

#1136: High memory use when compiling many let bindings.
------------------------------------------+---------------------------------
 Reporter:  igloo                         |          Owner:         
     Type:  compile-time performance 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 simonmar):

  * type:  bug => compile-time performance bug

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/1136#comment:6>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Mon Jan  7 05:42:57 2008
From: trac at galois.com (GHC)
Date: Mon Jan  7 05:36:40 2008
Subject: [GHC] #1818: Code size increase vs. 6.6.1
In-Reply-To: <047.29fbfe8c48a7e251205ebcb2f6270931@localhost>
References: <047.29fbfe8c48a7e251205ebcb2f6270931@localhost>
Message-ID: <056.c8aa577e59b68a35966a1e068f85998b@localhost>

#1818: Code size increase vs. 6.6.1
--------------------------------------+-------------------------------------
 Reporter:  simonmar                  |          Owner:         
     Type:  run-time performance bug  |         Status:  new    
 Priority:  high                      |      Milestone:  6.8.3  
Component:  Compiler                  |        Version:  6.8.1  
 Severity:  normal                    |     Resolution:         
 Keywords:                            |     Difficulty:  Unknown
 Testcase:                            |   Architecture:  Unknown
       Os:  Unknown                   |  
--------------------------------------+-------------------------------------
Changes (by simonmar):

  * type:  bug => run-time performance bug

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/1818#comment:3>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Mon Jan  7 05:43:21 2008
From: trac at galois.com (GHC)
Date: Mon Jan  7 05:37:20 2008
Subject: [GHC] #1889: Regression in concurrency performance from ghc 6.6
 to 6.8
In-Reply-To: <043.e16206d260f09af870b49b2d72f0b205@localhost>
References: <043.e16206d260f09af870b49b2d72f0b205@localhost>
Message-ID: <052.06b6440e0db0138091cc916d3919f84d@localhost>

#1889: Regression in concurrency performance from ghc 6.6 to 6.8
-----------------------------------------------+----------------------------
 Reporter:  dons                               |          Owner:  simonmar
     Type:  run-time performance bug           |         Status:  new     
 Priority:  high                               |      Milestone:  6.8.3   
Component:  Runtime System                     |        Version:  6.8.1   
 Severity:  normal                             |     Resolution:          
 Keywords:  threads, concurrency, performance  |     Difficulty:  Unknown 
 Testcase:                                     |   Architecture:  Multiple
       Os:  Multiple                           |  
-----------------------------------------------+----------------------------
Changes (by simonmar):

  * type:  bug => run-time performance bug

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/1889#comment:7>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Mon Jan  7 05:43:43 2008
From: trac at galois.com (GHC)
Date: Mon Jan  7 05:37:25 2008
Subject: [GHC] #149: missed CSE opportunity
In-Reply-To: <045.82dbf1ade5f39047db873a9122708a49@localhost>
References: <045.82dbf1ade5f39047db873a9122708a49@localhost>
Message-ID: <054.20ba79ef9f4840ebeb840dfb66100e46@localhost>

#149: missed CSE opportunity
--------------------------------------+-------------------------------------
 Reporter:  nobody                    |          Owner:         
     Type:  run-time performance bug  |         Status:  new    
 Priority:  high                      |      Milestone:  6.8.3  
Component:  Compiler                  |        Version:  5.04.2 
 Severity:  normal                    |     Resolution:  None   
 Keywords:  optimisations             |     Difficulty:  Unknown
 Testcase:  simplrun006               |   Architecture:  Unknown
       Os:  Unknown                   |  
--------------------------------------+-------------------------------------
Changes (by simonmar):

  * type:  bug => run-time performance bug

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/149#comment:8>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Mon Jan  7 05:44:08 2008
From: trac at galois.com (GHC)
Date: Mon Jan  7 05:37:52 2008
Subject: [GHC] #1890: Regression in mandelbrot benchmark due to inlining
In-Reply-To: <043.44a9b851e3c9386c0796e9d01c31dd61@localhost>
References: <043.44a9b851e3c9386c0796e9d01c31dd61@localhost>
Message-ID: <052.1dde3323bbcfef510c5af7ff703565d3@localhost>

#1890: Regression in mandelbrot benchmark due to inlining
--------------------------------------+-------------------------------------
 Reporter:  dons                      |          Owner:                
     Type:  run-time performance bug  |         Status:  new           
 Priority:  high                      |      Milestone:  6.8.3         
Component:  Compiler (NCG)            |        Version:  6.8.1         
 Severity:  normal                    |     Resolution:                
 Keywords:  asm, double               |     Difficulty:  Unknown       
 Testcase:                            |   Architecture:  x86_64 (amd64)
       Os:  Unknown                   |  
--------------------------------------+-------------------------------------
Changes (by simonmar):

  * type:  bug => run-time performance bug

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/1890#comment:6>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Mon Jan  7 05:44:35 2008
From: trac at galois.com (GHC)
Date: Mon Jan  7 05:38:18 2008
Subject: [GHC] #2002: problems with very large (list) literals
In-Reply-To: <051.64c621f5afc3e8cbd43368bfecf19488@localhost>
References: <051.64c621f5afc3e8cbd43368bfecf19488@localhost>
Message-ID: <060.5b7342cd8a062cfc68b2a4f5cf9a963a@localhost>

#2002: problems with very large (list) literals
------------------------------------------+---------------------------------
 Reporter:  Isaac Dupree                  |          Owner:         
     Type:  compile-time performance bug  |         Status:  new    
 Priority:  high                          |      Milestone:  6.8.3  
Component:  Compiler                      |        Version:  6.8.2  
 Severity:  normal                        |     Resolution:         
 Keywords:                                |     Difficulty:  Unknown
 Testcase:                                |   Architecture:  x86    
       Os:  Linux                         |  
------------------------------------------+---------------------------------
Changes (by simonmar):

  * type:  bug => compile-time performance bug

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/2002#comment:3>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Mon Jan  7 05:44:56 2008
From: trac at galois.com (GHC)
Date: Mon Jan  7 05:38:49 2008
Subject: [GHC] #783: performance problem compiling large file
In-Reply-To: <044.a7a580fed8a85952633cd84570dae070@localhost>
References: <044.a7a580fed8a85952633cd84570dae070@localhost>
Message-ID: <053.69bd49f01a744bcd6675363fe2bb9ff2@localhost>

#783: performance problem compiling large file
------------------------------------------+---------------------------------
 Reporter:  guest                         |          Owner:          
     Type:  compile-time performance 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 simonmar):

  * type:  bug => compile-time performance bug

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/783#comment:10>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Mon Jan  7 05:45:47 2008
From: trac at galois.com (GHC)
Date: Mon Jan  7 05:39:30 2008
Subject: [GHC] #1969: enormous compile times
In-Reply-To: <045.1ab99ac1a52ae6b35a7131dc801608a9@localhost>
References: <045.1ab99ac1a52ae6b35a7131dc801608a9@localhost>
Message-ID: <054.002e61a4e396ea77aa1daa462aa56f97@localhost>

#1969: enormous compile times
------------------------------------------+---------------------------------
 Reporter:  duncan                        |          Owner:                    
     Type:  compile-time performance 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 simonmar):

  * type:  bug => compile-time performance bug

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/1969#comment:2>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Mon Jan  7 05:46:09 2008
From: trac at galois.com (GHC)
Date: Mon Jan  7 05:39:51 2008
Subject: [GHC] #1875: Compiling with -O is 30 times slower than with
 -Onot
In-Reply-To: <046.51ad0647d4145de0c60e9541c64632d5@localhost>
References: <046.51ad0647d4145de0c60e9541c64632d5@localhost>
Message-ID: <055.2464a3e8856b4337c6df309dcd6a5f07@localhost>

#1875: Compiling with -O is 30 times slower than with -Onot
------------------------------------------+---------------------------------
 Reporter:  simonpj                       |          Owner:         
     Type:  compile-time performance 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 simonmar):

  * type:  bug => compile-time performance bug

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/1875#comment:3>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Mon Jan  7 05:47:59 2008
From: trac at galois.com (GHC)
Date: Mon Jan  7 05:41:43 2008
Subject: [GHC] #1747: debugger: :trace is wasting time
In-Reply-To: <047.b9bb4088c80d0d5b1d518a14686f3b5c@localhost>
References: <047.b9bb4088c80d0d5b1d518a14686f3b5c@localhost>
Message-ID: <056.2e510cb71806943cea16fd3e196327b9@localhost>

#1747: debugger: :trace is wasting time
------------------------------------------+---------------------------------
 Reporter:  simonmar                      |          Owner:         
     Type:  compile-time performance bug  |         Status:  new    
 Priority:  low                           |      Milestone:  6.8.3  
Component:  GHCi                          |        Version:  6.6.1  
 Severity:  minor                         |     Resolution:         
 Keywords:                                |     Difficulty:  Unknown
 Testcase:                                |   Architecture:  Unknown
       Os:  Unknown                       |  
------------------------------------------+---------------------------------
Changes (by simonmar):

  * type:  bug => compile-time performance bug

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/1747#comment:3>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From Christian.Maeder at dfki.de  Mon Jan  7 06:53:50 2008
From: Christian.Maeder at dfki.de (Christian Maeder)
Date: Mon Jan  7 06:47:37 2008
Subject: haskell package installation problem
In-Reply-To: <8f4ec6fc0801031149q5b11cab5wbe655efaa4048d2f@mail.gmail.com>
References: <8f4ec6fc0801031149q5b11cab5wbe655efaa4048d2f@mail.gmail.com>
Message-ID: <478212CE.9040709@dfki.de>

Brian Park wrote:
> Hi,
> 
> I was installing various haskell packages from hackage.
> 
> When I was installing HaXml, I think it was complaining about
> Text.PrettyPrint.HughesPJ not installed or something. (can't remember
> the specific message and I can't reproduce now...)

HaXml-1.13.2 needs pretty and containers as additional "build-depends"
in HaXml.cabal for ghc-6.8.x (HaXml-1.13.3 should work).

I don't know about
http://hackage.haskell.org/cgi-bin/hackage-scripts/package/HaXml-1.19.1

> So I installed "pretty-1.0.0.0" package as well.

bad move, Cabal itself depends on (this) pretty (package). Reinstalling
pretty failed and spoiled you're installation.

Maybe such kind of (re-)installation should be prohibited somehow.

Cheers Christian

> Ever since then, when I try to install other haskell packages, I get the
> following error message:
> "brian@bp-desktop:~/Download/mtl-1.1.0.0$ runghc Setup.hs configure
> <interactive>:
> /usr/local/lib/ghc-6.8.2/lib/Cabal-1.2.3.0/HSCabal-1.2.3.0.o
> <http://1.2.3.0/HSCabal-1.2.3.0.o>: unknown symbol
> `prettyzm1zi0zi0zi0_TextziPrettyPrintziHughesPJ_lvl18_closure'
> ghc-6.8.2: unable to load package `Cabal-1.2.3.0 <http://1.2.3.0>'"
> 
> Does anyone know what the problem is?
> 
> Currently installed packages are:
> =========
> /usr/local/lib/ghc-6.8.2/package.conf:
>     Cabal-1.2.3.0, HTTP-3001.0.4, HUnit-1.2.0.0, X11-1.4.1,
>     array-0.1.0.0, base-3.0.1.0, bytestring-0.9.0.1,
>     containers-0.1.0.1, directory-1.0.0.0, filepath-1.1.0.0,
>     (ghc-6.8.2), haskell98-1.0.1.0 , hpc-0.5.0.0, hxt-7.4, mtl-1.1.0.0,
>     network-2.1.0.0, old-locale-1.0.0.0, old-time-1.0.0.0,
>     packedstring-0.1.0.0, parsec-2.1.0.0, polyparse-1.1,
>     pretty-1.0.0.0, process-1.0.0.0, random-1.0.0.0, readline-1.0.1.0 ,
>     rts-1.0, template-haskell-2.2.0.0, unix-2.3.0.0, xmonad-0.5,
>     xmonad-contrib-0.5
> =========
> 
> 
> Thank you,
> 
> - Brian
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe@haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
From trac at galois.com  Mon Jan  7 07:31:54 2008
From: trac at galois.com (GHC)
Date: Mon Jan  7 07:25:37 2008
Subject: [GHC] #1989: GHC-6.8.1 fails arith003 on amd64/FreeBSD-7.0
In-Reply-To: <047.e1a81f31ca9bdca7e0fd42494374e2fa@localhost>
References: <047.e1a81f31ca9bdca7e0fd42494374e2fa@localhost>
Message-ID: <056.c728bd249b30e968fdd8c25cbd5e8483@localhost>

#1989: GHC-6.8.1 fails arith003 on amd64/FreeBSD-7.0
----------------------+-----------------------------------------------------
 Reporter:  wb.kloke  |          Owner:                
     Type:  bug       |         Status:  new           
 Priority:  normal    |      Milestone:  6.8.3         
Component:  Compiler  |        Version:  6.8.2         
 Severity:  normal    |     Resolution:                
 Keywords:            |     Difficulty:  Unknown       
 Testcase:            |   Architecture:  x86_64 (amd64)
       Os:  FreeBSD   |  
----------------------+-----------------------------------------------------
Comment (by simonmar):

 While I'm happy that you've tracked down the problem, I don't fully
 understand your explanation.

 The compat library is linked into the stage1 compiler, and hence it should
 be compiled by the same compiler you use to build stage1, i.e. the
 "bootstrap compiler".  compat isn't linked into any program that the
 stage1 compiler builds, including `arith003`.  So I'm not sure how the
 compat library could contribute to this problem you observed.

 The only reason to rebuild compat after building stage1, is in order to
 build the programs in `utils/` using the stage1 compiler, and in fact we
 do this when building distributions (see the `binary-dist` target in the
 top-level `Makefile`).

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/1989#comment:5>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Mon Jan  7 08:52:04 2008
From: trac at galois.com (GHC)
Date: Mon Jan  7 08:45:50 2008
Subject: [GHC] #1989: GHC-6.8.1 fails arith003 on amd64/FreeBSD-7.0
In-Reply-To: <047.e1a81f31ca9bdca7e0fd42494374e2fa@localhost>
References: <047.e1a81f31ca9bdca7e0fd42494374e2fa@localhost>
Message-ID: <056.ece5c4ca94da0e0239d98133212b94f4@localhost>

#1989: GHC-6.8.1 fails arith003 on amd64/FreeBSD-7.0
----------------------+-----------------------------------------------------
 Reporter:  wb.kloke  |          Owner:                
     Type:  bug       |         Status:  new           
 Priority:  normal    |      Milestone:  6.8.3         
Component:  Compiler  |        Version:  6.8.2         
 Severity:  normal    |     Resolution:                
 Keywords:            |     Difficulty:  Unknown       
 Testcase:            |   Architecture:  x86_64 (amd64)
       Os:  FreeBSD   |  
----------------------+-----------------------------------------------------
Comment (by wb.kloke):

 Thinking again about this, I agree that my former idea where the bug may
 have hibernated is too short-sighted. Though, the utils may have been the
 place.

 The only other place is the rts, where I used the stage2 generated files
 with only the ostensibly bad StgStdThunks.o and StgMisc...o replaced by
 those compiled with the stage1 cross compiler from i386.

 I don't know whether this is really worth to tracked down further. This
 type of failure should only happen in the special case of systems which
 allow to use both 64bit and 32bit applications and the 32bit system is
 used to bootstrap the 64bit compiler.

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/1989#comment:6>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Mon Jan  7 09:03:23 2008
From: trac at galois.com (GHC)
Date: Mon Jan  7 08:57:08 2008
Subject: [GHC] #1989: GHC-6.8.1 fails arith003 on amd64/FreeBSD-7.0
In-Reply-To: <047.e1a81f31ca9bdca7e0fd42494374e2fa@localhost>
References: <047.e1a81f31ca9bdca7e0fd42494374e2fa@localhost>
Message-ID: <056.be6e063fe611d5656eb6dc1141cd39af@localhost>

#1989: GHC-6.8.1 fails arith003 on amd64/FreeBSD-7.0
----------------------+-----------------------------------------------------
 Reporter:  wb.kloke  |          Owner:                
     Type:  bug       |         Status:  closed        
 Priority:  normal    |      Milestone:  6.8.3         
Component:  Compiler  |        Version:  6.8.2         
 Severity:  normal    |     Resolution:  fixed         
 Keywords:            |     Difficulty:  Unknown       
 Testcase:            |   Architecture:  x86_64 (amd64)
       Os:  FreeBSD   |  
----------------------+-----------------------------------------------------
Changes (by simonmar):

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

Comment:

 Ok, closing the bug.

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/1989#comment:7>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Mon Jan  7 09:15:27 2008
From: trac at galois.com (GHC)
Date: Mon Jan  7 09:09:24 2008
Subject: [GHC] #2021: let ghc find framework header files and link with
 frameworks located in $HOME/Library/Frameworks
Message-ID: <045.f644abcffe54149a52e1b357b6ba7b01@localhost>

#2021: let ghc find framework header files and link with frameworks located in
$HOME/Library/Frameworks
--------------------------------+-------------------------------------------
    Reporter:  maeder           |       Owner:         
        Type:  feature request  |      Status:  new    
    Priority:  normal           |   Milestone:         
   Component:  Compiler         |     Version:  6.8.2  
    Severity:  normal           |    Keywords:         
  Difficulty:  Easy (1 hr)      |    Testcase:         
Architecture:  Multiple         |          Os:  MacOS X
--------------------------------+-------------------------------------------
 As described in ticket #1395 I want ghc to be able to work with my local
 frameworks. Therefore I've extended the file
 `compiler/main/DriverPipeline.hs`.

 In my latest (attached) version I've also removed a few duplications.

 I've considered to check if the directory `$HOME/Library/Frameworks`
 exists using `doesDirectoryExist`, but that's done anyway by gcc and ld on
 mac. I've also considered to only pass
 `"-F$HOME/Library/Frameworks"` if there are `-framework` flags on the
 command line at all, but this did not work for `HsReadline_cbits.c`:

 {{{
 ../../compiler/stage1/ghc-inplace -Iinclude -package base-3.0.1.0 -package
 process-1.0.0.0 -optc-O2 -odir dist/build -c HsReadline_cbits.c -o
 dist/build/HsReadline_cbits.o

 In file included from HsReadline_cbits.c:1:0:

 include/HsReadline.h:7:43:
      error: GNUreadline/readline/readline.h: No such file or directory

 include/HsReadline.h:8:42:
      error: GNUreadline/readline/history.h: No such file or directory
 HsReadline_cbits.c: In function 'hs_rl_message':

 HsReadline_cbits.c:5:0:
      warning: implicit declaration of function 'rl_message'
 make[2]: *** [dist/build/HsReadline_cbits.o] Error 1
 make[1]: *** [make.library.readline] Error 2
 make: *** [stage1] Error 2
 }}}

 This (single) case may be fixed by passing "`-F$HOME/Library/Frameworks`"
 manually, but what is the risk of passing "`-F$HOME/Library/Frameworks`"
 always? Well, someone may have spoiled frameworks there, but even that is
 no problem as long as they are not used, because dylibs are used instead.
 Of course other C-compilers may not like the -F flag (in fact that is a
 problem if ghc is used as C-compiler and was actually bad for hsc2hs
 #1395).

 Maybe configure should check if gcc understands -F on macs? What do others
 think? Would you commit my `DriverPipeline.hs` changes?

 A `"diff -u -w"` currently looks as follows:
 {{{
 +++ compiler/main/DriverPipeline.hs     2008-01-07 14:39:12.000000000
 +0100
 @@ -822,6 +822,9 @@
          let include_paths = foldr (\ x xs -> "-I" : x : xs) []
                               (cmdline_include_paths ++ pkg_include_dirs)

 +#ifdef darwin_TARGET_OS
 +        framework_path_opts <- getFrameworkPathOpts dflags pkgs
 +#endif
         let (md_c_flags, md_regd_c_flags) = machdepCCOpts dflags
          gcc_extra_viac_flags <- getExtraViaCOpts dflags
          let pic_c_flags = picCCOpts dflags
 @@ -905,6 +908,9 @@
                        ++ cc_opts
                        ++ split_opt
                        ++ include_paths
 +#ifdef darwin_TARGET_OS
 +                       ++ framework_path_opts
 +#endif
                        ++ pkg_extra_cc_opts
                        ))

 @@ -1199,17 +1205,10 @@
      pkg_link_opts <- getPackageLinkOpts dflags dep_packages

  #ifdef darwin_TARGET_OS
 -    pkg_framework_paths <- getPackageFrameworkPath dflags dep_packages
 -    let pkg_framework_path_opts = map ("-F"++) pkg_framework_paths
 -
 -    let framework_paths = frameworkPaths dflags
 -        framework_path_opts = map ("-F"++) framework_paths
 -
 +    framework_path_opts <- getFrameworkPathOpts dflags dep_packages
      pkg_frameworks <- getPackageFrameworks dflags dep_packages
 -    let pkg_framework_opts = concat [ ["-framework", fw] | fw <-
 pkg_frameworks ]
 -
 -    let frameworks = cmdlineFrameworks dflags
 -        framework_opts = concat [ ["-framework", fw] | fw <- reverse
 frameworks ]
 +    let framework_opts = concat [ ["-framework", fw]
 +          | fw <- pkg_frameworks ++ reverse (cmdlineFrameworks dflags) ]
          -- reverse because they're added in reverse order from the cmd
 line
  #endif

 @@ -1264,10 +1263,6 @@
  #endif
                       ++ pkg_lib_path_opts
                       ++ pkg_link_opts
 -#ifdef darwin_TARGET_OS
 -                     ++ pkg_framework_path_opts
 -                     ++ pkg_framework_opts
 -#endif
                       ++ debug_opts
                       ++ thread_opts
                     ))
 @@ -1278,6 +1273,15 @@
               if success then return ()
                          else throwDyn (InstallationError ("cannot move
 binary to PVM dir")))

 +-- options to pass to gcc and ld on macs only
 +getFrameworkPathOpts  :: DynFlags -> [PackageId] -> IO [String]
 +getFrameworkPathOpts dflags pkgs = do
 +  ps <- getPackageFrameworkPath dflags pkgs
 +  let fps = ps ++ frameworkPaths dflags
 +  eitherDir <- IO.try getHomeDirectory
 +  return $ map ("-F" ++) $ case eitherDir of
 +    Left _ -> fps
 +    Right hdir -> (hdir ++ "/Library/Frameworks") : fps

  exeFileName :: DynFlags -> FilePath
  exeFileName dflags
 }}}

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/2021>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Mon Jan  7 09:29:32 2008
From: trac at galois.com (GHC)
Date: Mon Jan  7 09:23:24 2008
Subject: [GHC] #1395: let ./configure check for a GNUreadline framework
In-Reply-To: <052.068bc0f583c08a182f51a06ad4864715@localhost>
References: <052.068bc0f583c08a182f51a06ad4864715@localhost>
Message-ID: <061.6956d7e988e70e0f4b5b92c1b015a91e@localhost>

#1395: let ./configure check for a GNUreadline framework
-----------------------------+----------------------------------------------
 Reporter:  maeder@tzi.de    |          Owner:             
     Type:  feature request  |         Status:  reopened   
 Priority:  normal           |      Milestone:  6.8 branch 
Component:  Build System     |        Version:  6.8        
 Severity:  normal           |     Resolution:             
 Keywords:                   |     Difficulty:  Easy (1 hr)
 Testcase:                   |   Architecture:  Multiple   
       Os:  MacOS X          |  
-----------------------------+----------------------------------------------
Comment (by maeder):

 I've created #2021 for the `DriverPipeline.hs` issue. The subject of this
 ticket can be settled by committing `libraries/readline/configure.ac` and
 `libraries/Makefile` afterwards.

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/1395#comment:29>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Mon Jan  7 09:41:01 2008
From: trac at galois.com (GHC)
Date: Mon Jan  7 09:34:46 2008
Subject: [GHC] #2022: DLL support broken
Message-ID: <042.43c39ca72c9b8eecfec3978a18e72791@localhost>

#2022: DLL support broken
-------------------------+--------------------------------------------------
    Reporter:  mte       |       Owner:         
        Type:  bug       |      Status:  new    
    Priority:  normal    |   Milestone:         
   Component:  Compiler  |     Version:  6.8.2  
    Severity:  normal    |    Keywords:         
  Difficulty:  Unknown   |    Testcase:         
Architecture:  x86       |          Os:  Windows
-------------------------+--------------------------------------------------
 Creating a DLL using the -shared option does not work for me:

 1. ghc tries to create a static library (foobar.dll.a).

 2. The linker complains about missing symbols.

 Building an executable from the same project works fine and the resulting
 executable runs all unit tests without errors.

 With 6.6 and the --mk-dll option, the DLL was built without problems.


 /vol/c/ghc/ghc-6.8.2/bin/ghc.exe \
           -fglasgow-exts  -odir ../targets/i686-CYGWIN_NT-5.1/plain -hidir
 ../targets/i686-CYGWIN_NT-5.1/plain -i../targets/i686-CYGWIN_NT-5.1/plain
 +RTS -M64m -RTS \
           -shared \
           -o ../targets/i686-CYGWIN_NT-5.1/plain/foobar.dll \
           foobar.def \
           ../targets/i686-CYGWIN_NT-5.1/plain/*.o
 Creating library file: ..\targets\i686-CYGWIN_NT-5.1\plain\foobar.dll.a
 ../targets/i686-CYGWIN_NT-5.1/plain/foobar.o(.text+0x1696):fake: undefined
 reference to `containerszm0zi1zi0zi1_DataziSet_empty_closure'
 ../targets/i686-CYGWIN_NT-5.1/plain/foobar.o(.text+0x44c3):fake: undefined
 reference to `containerszm0zi1zi0zi1_DataziSet_zdf3_closure'
 ../targets/i686-CYGWIN_NT-5.1/plain/foobar.o(.text+0x7e6d):fake: undefined
 reference to `containerszm0zi1zi0zi1_DataziSet_elems_closure'
 ../targets/i686-CYGWIN_NT-5.1/plain/foobar.o(.text+0xf392):fake: undefined
 reference to `containerszm0zi1zi0zi1_DataziSet_delete_closure'
 ../targets/i686-CYGWIN_NT-5.1/plain/foobar.o(.text+0xf3f6):fake: undefined
 reference to `containerszm0zi1zi0zi1_DataziSet_insert_closure'
 ../targets/i686-CYGWIN_NT-5.1/plain/foobar.o(.text+0xf8e3):fake: undefined
 reference to `containerszm0zi1zi0zi1_DataziSet_elems_closure'
 ../targets/i686-CYGWIN_NT-5.1/plain/foobar.o(.text+0xf933):fake: undefined
 reference to `containerszm0zi1zi0zi1_DataziSet_sizze_closure'
 ../targets/i686-CYGWIN_NT-5.1/plain/foobar.o(.text+0xffae):fake: undefined
 reference to `containerszm0zi1zi0zi1_DataziSet_delete_closure'
 ../targets/i686-CYGWIN_NT-5.1/plain/foobar.o(.text+0x10012):fake:
 undefined reference to `containerszm0zi1zi0zi1_DataziSet_insert_closure'
 ../targets/i686-CYGWIN_NT-5.1/plain/foobar.o(.text+0x10076):fake:
 undefined reference to `containerszm0zi1zi0zi1_DataziSet_delete_closure'
 ../targets/i686-CYGWIN_NT-5.1/plain/foobar.o(.text+0x100c7):fake:
 undefined reference to `containerszm0zi1zi0zi1_DataziSet_elems_closure'
 ../targets/i686-CYGWIN_NT-5.1/plain/foobar.o(.text+0x101ef):fake:
 undefined reference to `containerszm0zi1zi0zi1_DataziSet_null_closure'
 ../targets/i686-CYGWIN_NT-5.1/plain/foobar.o(.text+0x125e7):fake:
 undefined reference to
 `containerszm0zi1zi0zi1_DataziSet_toAscList_closure'
 ../targets/i686-CYGWIN_NT-5.1/plain/foobar.o(.text+0x133e2):fake:
 undefined reference to `containerszm0zi1zi0zi1_DataziSet_empty_closure'
 ../targets/i686-CYGWIN_NT-5.1/plain/foobar.o(.text+0x1c91f):fake:
 undefined reference to `containerszm0zi1zi0zi1_DataziSet_elems_closure'
 ../targets/i686-CYGWIN_NT-5.1/plain/foobar.o(.text+0x1ca0f):fake:
 undefined reference to `containerszm0zi1zi0zi1_DataziSet_sizze_closure'
 ../targets/i686-CYGWIN_NT-5.1/plain/foobar.o(.text+0x1cecb):fake:
 undefined reference to `containerszm0zi1zi0zi1_DataziSet_sizze_closure'
 ../targets/i686-CYGWIN_NT-5.1/plain/foobar.o(.text+0x1cfb0):fake:
 undefined reference to `containerszm0zi1zi0zi1_DataziSet_empty_closure'
 ../targets/i686-CYGWIN_NT-5.1/plain/foobar.o(.text+0x1f3ec):fake:
 undefined reference to
 `containerszm0zi1zi0zi1_DataziSet_singleton_closure'
 ../targets/i686-CYGWIN_NT-5.1/plain/foobar.o(.text+0x1fdd5):fake:
 undefined reference to `__stginit_arrayzm0zi1zi0zi0_DataziArray_'
 ../targets/i686-CYGWIN_NT-5.1/plain/foobar.o(.text+0x1fdf3):fake:
 undefined reference to `__stginit_containerszm0zi1zi0zi1_DataziSet_'
 ../targets/i686-CYGWIN_NT-5.1/plain/foobar.o(.text+0x1fdfd):fake:
 undefined reference to `__stginit_haskell98_List_'
 ../targets/i686-CYGWIN_NT-5.1/plain/foobar.o(.text+0x1fe07):fake:
 undefined reference to `__stginit_haskell98_Maybe_'
 ../targets/i686-CYGWIN_NT-5.1/plain/foobar.o(.data+0x124):fake: undefined
 reference to `containerszm0zi1zi0zi1_DataziSet_empty_closure'
 ../targets/i686-CYGWIN_NT-5.1/plain/foobar.o(.data+0x3dc):fake: undefined
 reference to `containerszm0zi1zi0zi1_DataziSet_zdf3_closure'
 ../targets/i686-CYGWIN_NT-5.1/plain/foobar.o(.data+0x4a8):fake: undefined
 reference to `containerszm0zi1zi0zi1_DataziSet_elems_closure'
 ../targets/i686-CYGWIN_NT-5.1/plain/foobar.o(.data+0xdc0):fake: undefined
 reference to `containerszm0zi1zi0zi1_DataziSet_delete_closure'
 ../targets/i686-CYGWIN_NT-5.1/plain/foobar.o(.data+0xdd8):fake: undefined
 reference to `containerszm0zi1zi0zi1_DataziSet_insert_closure'
 ../targets/i686-CYGWIN_NT-5.1/plain/foobar.o(.data+0xe48):fake: undefined
 reference to `containerszm0zi1zi0zi1_DataziSet_sizze_closure'
 ../targets/i686-CYGWIN_NT-5.1/plain/foobar.o(.data+0xe4c):fake: undefined
 reference to `containerszm0zi1zi0zi1_DataziSet_elems_closure'
 ../targets/i686-CYGWIN_NT-5.1/plain/foobar.o(.data+0xf58):fake: undefined
 reference to `containerszm0zi1zi0zi1_DataziSet_delete_closure'
 ../targets/i686-CYGWIN_NT-5.1/plain/foobar.o(.data+0xf70):fake: undefined
 reference to `containerszm0zi1zi0zi1_DataziSet_insert_closure'
 ../targets/i686-CYGWIN_NT-5.1/plain/foobar.o(.data+0xf88):fake: undefined
 reference to `containerszm0zi1zi0zi1_DataziSet_delete_closure'
 ../targets/i686-CYGWIN_NT-5.1/plain/foobar.o(.data+0xfc4):fake: undefined
 reference to `containerszm0zi1zi0zi1_DataziSet_null_closure'
 ../targets/i686-CYGWIN_NT-5.1/plain/foobar.o(.data+0xfc8):fake: undefined
 reference to `containerszm0zi1zi0zi1_DataziSet_elems_closure'
 ../targets/i686-CYGWIN_NT-5.1/plain/foobar.o(.data+0x118c):fake: undefined
 reference to `containerszm0zi1zi0zi1_DataziSet_empty_closure'
 ../targets/i686-CYGWIN_NT-5.1/plain/foobar.o(.data+0x1190):fake: undefined
 reference to `containerszm0zi1zi0zi1_DataziSet_toAscList_closure'
 ../targets/i686-CYGWIN_NT-5.1/plain/foobar.o(.data+0x192c):fake: undefined
 reference to `containerszm0zi1zi0zi1_DataziSet_empty_closure'
 ../targets/i686-CYGWIN_NT-5.1/plain/foobar.o(.data+0x1930):fake: undefined
 reference to `containerszm0zi1zi0zi1_DataziSet_sizze_closure'
 ../targets/i686-CYGWIN_NT-5.1/plain/foobar.o(.data+0x1934):fake: undefined
 reference to `containerszm0zi1zi0zi1_DataziSet_elems_closure'
 ../targets/i686-CYGWIN_NT-5.1/plain/foobar.o(.data+0x19f4):fake: undefined
 reference to `containerszm0zi1zi0zi1_DataziSet_singleton_closure'
 ../targets/i686-CYGWIN_NT-5.1/plain/Types.o(.text+0xa5b9):fake: undefined
 reference to `__stginit_arrayzm0zi1zi0zi0_DataziArray_'
 collect2: ld returned 1 exit status

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/2022>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Mon Jan  7 10:14:00 2008
From: trac at galois.com (GHC)
Date: Mon Jan  7 10:07:44 2008
Subject: [GHC] #2023: Packages.lhs:mungePackagePaths doesn't handle
 haddock-html & haddock-interfaces
Message-ID: <044.353c7e94c0ee9b420199f0094f141941@localhost>

#2023: Packages.lhs:mungePackagePaths doesn't handle haddock-html & haddock-
interfaces
----------------------------+-----------------------------------------------
    Reporter:  guest        |       Owner:          
        Type:  bug          |      Status:  new     
    Priority:  normal       |   Milestone:  6.8.3   
   Component:  Compiler     |     Version:  6.8.2   
    Severity:  normal       |    Keywords:  packages
  Difficulty:  Easy (1 hr)  |    Testcase:          
Architecture:  Unknown      |          Os:  Unknown 
----------------------------+-----------------------------------------------
 Substitution for $topdir et al should be done for haddock-html and
 haddock-interfaces as well.

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/2023>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From mechvel at botik.ru  Mon Jan  7 10:56:13 2008
From: mechvel at botik.ru (Serge D. Mechveliani)
Date: Mon Jan  7 10:50:16 2008
Subject: hs-boot types in 6.8.2
Message-ID: <20080107155613.GA3639@scico.botik.ru>

Dear GHC developers,

This is about possibile bug in  ghc-6.8.2  related to types in  hs-boot.

I have a project with module import loop, in which the module  Split  
imports the source of  Reduce. 
Now, I changed the type of the function  Reduce.evaluate_c
and forgotten to change it in  Reduce.hs-boot.

When GHC `makes' this project (under Cabal), it first processes
Reduce[boot], and then gets to  Split.hs:

------------------------------------------------------------------
[16 of 45] Compiling Dumatel.Reduce[boot] 
            ( Dumatel/Reduce.hs-boot, dist/build/Dumatel/Reduce.o-boot )
[17 of 45] Compiling Split            ( Split.hs, dist/build/Split.o )

Split.hs:393:58:
    Couldn't match expected type `Term' against inferred type `[a]'
    In the third argument of `evaluate_c', namely `[]'
...
---------------------------------------------------------

-- and it only reports of several type mismatches in  Split.hs.
If the user guesses to fix the type in  Reduce.hs-boot,  the `make' 
improves.

In many situations, GHC reports first what namely is the type 
disagreement between *.hs and *.hs-boot.
But not in this situation.
And here the report is misleading: the user looks into Reduce.hs and 
Splis.hs, and wonders what is wrong with types.

Can this be fixed ?

If you ask me, I would provide the source on www.

Thank you in advance for your explanation.

-----------------
Serge Mechveliani
mechvel@botik.ru
From igloo at earth.li  Mon Jan  7 11:37:16 2008
From: igloo at earth.li (Ian Lynagh)
Date: Mon Jan  7 11:31:00 2008
Subject: hs-boot types in 6.8.2
In-Reply-To: <20080107155613.GA3639@scico.botik.ru>
References: <20080107155613.GA3639@scico.botik.ru>
Message-ID: <20080107163716.GA23946@matrix.chaos.earth.li>


Hi Serge,

On Mon, Jan 07, 2008 at 06:56:13PM +0300, Serge D. Mechveliani wrote:
> 
> In many situations, GHC reports first what namely is the type 
> disagreement between *.hs and *.hs-boot.

We can't look for differences between Reduce.hs-boot and Reduce.hs until
we have typechecked Reduce.hs, and we can't do that until we have
compiled Split.hs.


Thanks
Ian

From trac at galois.com  Mon Jan  7 12:11:10 2008
From: trac at galois.com (GHC)
Date: Mon Jan  7 12:04:58 2008
Subject: [GHC] #1907: HPC and Template Haskell don't mix
In-Reply-To: <044.04728c864207e67b417a4402811081dd@localhost>
References: <044.04728c864207e67b417a4402811081dd@localhost>
Message-ID: <053.f6eb25f5d6954478673ab1a6646ee42c@localhost>

#1907: HPC and Template Haskell don't mix
---------------------------+------------------------------------------------
 Reporter:  guest          |          Owner:  AndyGill   
     Type:  bug            |         Status:  new        
 Priority:  normal         |      Milestone:  6.10 branch
Component:  Code Coverage  |        Version:  6.8.1      
 Severity:  normal         |     Resolution:             
 Keywords:                 |     Difficulty:  Unknown    
 Testcase:                 |   Architecture:  Unknown    
       Os:  Unknown        |  
---------------------------+------------------------------------------------
Changes (by AndyGill):

  * owner:  andy@galois.com => AndyGill

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/1907#comment:3>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Mon Jan  7 12:33:18 2008
From: trac at galois.com (GHC)
Date: Mon Jan  7 12:27:00 2008
Subject: [GHC] #2019: GADT record with polytype argument causes
 irrefutable pattern failure in basicTypes/MkId.lhs
In-Reply-To: <045.791b8f9a465ed91be02dc1a0633e357f@localhost>
References: <045.791b8f9a465ed91be02dc1a0633e357f@localhost>
Message-ID: <054.28c43aae04706b79fd0e6c1ca266f2fe@localhost>

#2019: GADT record with polytype argument causes irrefutable pattern failure in
basicTypes/MkId.lhs
---------------------------------------------+------------------------------
 Reporter:  japple                           |          Owner:  igloo  
     Type:  merge                            |         Status:  new    
 Priority:  normal                           |      Milestone:  6.8.3  
Component:  Compiler                         |        Version:  6.8.2  
 Severity:  normal                           |     Resolution:         
 Keywords:                                   |     Difficulty:  Unknown
 Testcase:  tcfail195, tcfail196, tcfail197  |   Architecture:  x86    
       Os:  Linux                            |  
---------------------------------------------+------------------------------
Changes (by simonpj):

  * testcase:  => tcfail195, tcfail196, tcfail197
  * owner:  => igloo
  * type:  bug => merge

Comment:

 Shouldn't be valid; in general equality constraints can't involve
 polytypes.  I'm adding a test in the code, and some testsuite cases.

 Thanks for pointing this out.

 Ian can you merge this:
 {{{
 Mon Jan  7 12:53:22 GMT 2008  simonpj@microsoft.com
   * Add tests for type signature validity (cf Trac 2019)
 }}}

 Simon

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/2019#comment:2>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Mon Jan  7 12:35:35 2008
From: trac at galois.com (GHC)
Date: Mon Jan  7 12:29:17 2008
Subject: [GHC] #2013: ghci crash on startup: R_X86_64_32S relocation out
 of range.
In-Reply-To: <044.2f007075e8a3e652be5aa7c77056c714@localhost>
References: <044.2f007075e8a3e652be5aa7c77056c714@localhost>
Message-ID: <053.a91a5a1efba7d9ddc69e34319db678fd@localhost>

#2013: ghci crash on startup: R_X86_64_32S relocation out of range.
---------------------+------------------------------------------------------
 Reporter:  mboes    |          Owner:                
     Type:  bug      |         Status:  new           
 Priority:  normal   |      Milestone:  6.8.3         
Component:  GHCi     |        Version:  6.9           
 Severity:  normal   |     Resolution:                
 Keywords:           |     Difficulty:  Unknown       
 Testcase:           |   Architecture:  x86_64 (amd64)
       Os:  FreeBSD  |  
---------------------+------------------------------------------------------
Changes (by mboes):

  * version:  6.8.1 => 6.9

Comment:

 The problem actually occurs before x86_64_high_symbol gets called. It
 occurs because in loadObj() oc->image gets mmapped elsewhere than in the
 low 2Gb to start with, causing do_Elf_Rela_relocations() to fail.
 Unfortunately I can't convince FreeBSD to mmap in the low 2Gb, even with a
 hint address.

 The patch above looks like a good step forward, because as I understand
 the R_X86_64_PC32S and friend ELF relocations disappear by virtue of using
 PIC code. Trouble is though that ocAllocateSymbolExtras() won't compile on
 FreeBSD due to the use of the mremap() linuxism. mremap() doesn't exist on
 FreeBSD. This would have to be replaced by a pair of munmap(); mmap()
 calls, along with passing in the fd of the file being loaded to
 ocAllocateSymbolExtras(). I tried the simpler approach of #undef USE_MMAP
 and hence using stgReallocBytes() to map in the object instead and space
 for the GOT entries, along with a call to mprotect() to set the region
 executable. This however yields limited success: base links in fine
 (what's more in the low 2Gb!) but I get a segfault shortly after that:
 {{{
 $ ./stage2/ghc-inplace +RTS -Di -RTS --interactive
 GHCi, version 6.9.20071215: http://www.haskell.org/ghc/  :? for help
 Loading package base ... linking ... done.
 Sp = 0x8029f4ef8   pc = 1      PUSH_G   0x802f7fff8
 Sp = 0x8029f4ef0   pc = 3      PUSH_G   0x802f859c8
 Sp = 0x8029f4ee8   pc = 5      PACK      2 words with itbl 0x802d48258
         Built Object 0x802a7d000 = CONSTR(0x802d48258(tag=1), 0x802f859c8,
 0x802f7fff8)
 Sp = 0x8029f4ef0   pc = 8      PUSH_L   0
 Sp = 0x8029f4ee8   pc = 10      PUSH_APPLY_P
 Sp = 0x8029f4ee0   pc = 11      PUSH_G   0x802f8a498
 Sp = 0x8029f4ed8   pc = 13      SLIDE     3 down by 1
 Sp = 0x8029f4ee0   pc = 16      ENTER

 ---------------------------------------------------------------
 Evaluating: Object 0x802f8a498 = FUN/2(0x802db3618)
 Sp = 0x8029f4ee8

 RET_SMALL (0x1374330)
    stk[34] (0x8029f4ef0) = 0x802a7d000
 Object 0x8029f4ef8 = UPDATE_FRAME(0x1372400,0x8026eb470)
 RET_SMALL (0x1372570)
 RET_SMALL (0x12af7a0)
    stk[29] (0x8029f4f18) = 0x8026eb651
 RET_SMALL (0x12af7a0)
    stk[27] (0x8029f4f28) = 0x80292a6f1
 RET_SMALL (0x12af7a0)
    stk[25] (0x8029f4f38) = 0x80292a701
 RET_SMALL (0x12af7a0)
    stk[23] (0x8029f4f48) = 0x80292a711
 RET_SMALL (0x136a810)
 Object 0x8029f4f58 = CATCH_FRAME(0x136ac10,0x80292a722)
 RET_SMALL (0x12d1fe8)
    stk[17] (0x8029f4f78) = 0x80292a730
 RET_SMALL (0x136a6b8)
 Object 0x8029f4f88 = CATCH_FRAME(0x136ac10,0x80292a749)
 Object 0x8029f4fa0 = CATCH_FRAME(0x136ac10,0x80292a761)
 Object 0x8029f4fb8 = CATCH_FRAME(0x136ac10,0x80292a779)
 RET_SMALL (0x12c8dd8)
 Object 0x8029f4fd8 = CATCH_FRAME(0x136ac10,0x16f8f30)
 RET_SMALL (0x1370fe0)
 Object 0x8029f4ff8 = STOP_FRAME(0x1370a90)



 ---------------------------------------------------------------
 Returning: Object 0x802f8a498 = FUN/2(0x802db3618)
 Sp = 0x8029f4ee8

 RET_SMALL (0x1374330)
    stk[34] (0x8029f4ef0) = 0x802a7d000
 Object 0x8029f4ef8 = UPDATE_FRAME(0x1372400,0x8026eb470)
 RET_SMALL (0x1372570)
 RET_SMALL (0x12af7a0)
    stk[29] (0x8029f4f18) = 0x8026eb651
 RET_SMALL (0x12af7a0)
    stk[27] (0x8029f4f28) = 0x80292a6f1
 RET_SMALL (0x12af7a0)
    stk[25] (0x8029f4f38) = 0x80292a701
 RET_SMALL (0x12af7a0)
    stk[23] (0x8029f4f48) = 0x80292a711
 RET_SMALL (0x136a810)
 Object 0x8029f4f58 = CATCH_FRAME(0x136ac10,0x80292a722)
 RET_SMALL (0x12d1fe8)
    stk[17] (0x8029f4f78) = 0x80292a730
 RET_SMALL (0x136a6b8)
 Object 0x8029f4f88 = CATCH_FRAME(0x136ac10,0x80292a749)
 Object 0x8029f4fa0 = CATCH_FRAME(0x136ac10,0x80292a761)
 Object 0x8029f4fb8 = CATCH_FRAME(0x136ac10,0x80292a779)
 RET_SMALL (0x12c8dd8)
 Object 0x8029f4fd8 = CATCH_FRAME(0x136ac10,0x16f8f30)
 RET_SMALL (0x1370fe0)
 Object 0x8029f4ff8 = STOP_FRAME(0x1370a90)


 Sp = 0x8029f4ef8   pc = 1      PUSH_G   0x802f7fff8
 Sp = 0x8029f4ef0   pc = 3      PUSH_G   0x802f85a40
 Sp = 0x8029f4ee8   pc = 5      PACK      2 words with itbl 0x802d48258
         Built Object 0x802a3c000 = CONSTR(0x802d48258(tag=1), 0x802f85a40,
 0x802f7fff8)
 Sp = 0x8029f4ef0   pc = 8      PUSH_L   0
 Sp = 0x8029f4ee8   pc = 10      PUSH_APPLY_P
 Sp = 0x8029f4ee0   pc = 11      PUSH_G   0x802f8a498
 Sp = 0x8029f4ed8   pc = 13      SLIDE     3 down by 1
 Sp = 0x8029f4ee0   pc = 16      ENTER

 ---------------------------------------------------------------
 Evaluating: Object 0x802f8a498 = FUN/2(0x802db3618)
 Sp = 0x8029f4ee8

 RET_SMALL (0x1374330)
    stk[34] (0x8029f4ef0) = 0x802a3c000
 Object 0x8029f4ef8 = UPDATE_FRAME(0x1372400,0x802693bb8)
 RET_SMALL (0x1372570)
 RET_SMALL (0x12af7a0)
    stk[29] (0x8029f4f18) = 0x802693d99
 RET_SMALL (0x12af7a0)
    stk[27] (0x8029f4f28) = 0x802a3a641
 RET_SMALL (0x12af7a0)
    stk[25] (0x8029f4f38) = 0x80292a701
 RET_SMALL (0x12af7a0)
    stk[23] (0x8029f4f48) = 0x80292a711
 RET_SMALL (0x136a810)
 Object 0x8029f4f58 = CATCH_FRAME(0x136ac10,0x80292a722)
 RET_SMALL (0x12d1fe8)
    stk[17] (0x8029f4f78) = 0x80292a730
 RET_SMALL (0x136a6b8)
 Object 0x8029f4f88 = CATCH_FRAME(0x136ac10,0x80292a749)
 Object 0x8029f4fa0 = CATCH_FRAME(0x136ac10,0x80292a761)
 Object 0x8029f4fb8 = CATCH_FRAME(0x136ac10,0x80292a779)
 RET_SMALL (0x12c8dd8)
 Object 0x8029f4fd8 = CATCH_FRAME(0x136ac10,0x16f8f30)
 RET_SMALL (0x1370fe0)
 Object 0x8029f4ff8 = STOP_FRAME(0x1370a90)



 ---------------------------------------------------------------
 Returning: Object 0x802f8a498 = FUN/2(0x802db3618)
 Sp = 0x8029f4ee8

 RET_SMALL (0x1374330)
    stk[34] (0x8029f4ef0) = 0x802a3c000
 Object 0x8029f4ef8 = UPDATE_FRAME(0x1372400,0x802693bb8)
 RET_SMALL (0x1372570)
 RET_SMALL (0x12af7a0)
    stk[29] (0x8029f4f18) = 0x802693d99
 RET_SMALL (0x12af7a0)
    stk[27] (0x8029f4f28) = 0x802a3a641
 RET_SMALL (0x12af7a0)
    stk[25] (0x8029f4f38) = 0x80292a701
 RET_SMALL (0x12af7a0)
    stk[23] (0x8029f4f48) = 0x80292a711
 RET_SMALL (0x136a810)
 Object 0x8029f4f58 = CATCH_FRAME(0x136ac10,0x80292a722)
 RET_SMALL (0x12d1fe8)
    stk[17] (0x8029f4f78) = 0x80292a730
 RET_SMALL (0x136a6b8)
 Object 0x8029f4f88 = CATCH_FRAME(0x136ac10,0x80292a749)
 Object 0x8029f4fa0 = CATCH_FRAME(0x136ac10,0x80292a761)
 Object 0x8029f4fb8 = CATCH_FRAME(0x136ac10,0x80292a779)
 RET_SMALL (0x12c8dd8)
 Object 0x8029f4fd8 = CATCH_FRAME(0x136ac10,0x16f8f30)
 RET_SMALL (0x1370fe0)
 Object 0x8029f4ff8 = STOP_FRAME(0x1370a90)


 Sp = 0x8029f4ef8   pc = 1      PUSH_G   0x802f7fff8
 Sp = 0x8029f4ef0   pc = 3      PUSH_G   0x802f85960
 Sp = 0x8029f4ee8   pc = 5      PACK      2 words with itbl 0x802d48258
         Built Object 0x802a40000 = CONSTR(0x802d48258(tag=1), 0x802f85960,
 0x802f7fff8)
 Sp = 0x8029f4ef0   pc = 8      PUSH_L   0
 Sp = 0x8029f4ee8   pc = 10      PUSH_APPLY_P
 Sp = 0x8029f4ee0   pc = 11      PUSH_G   0x802f8a498
 Sp = 0x8029f4ed8   pc = 13      SLIDE     3 down by 1
 Sp = 0x8029f4ee0   pc = 16      ENTER

 ---------------------------------------------------------------
 Evaluating: Object 0x802f8a498 = FUN/2(0x802db3618)
 Sp = 0x8029f4ee8

 RET_SMALL (0x1374330)
    stk[34] (0x8029f4ef0) = 0x802a40000
 Object 0x8029f4ef8 = UPDATE_FRAME(0x1372400,0x8026bdca0)
 RET_SMALL (0x1372570)
 RET_SMALL (0x12af7a0)
    stk[29] (0x8029f4f18) = 0x8026bde81
 RET_SMALL (0x12af7a0)
    stk[27] (0x8029f4f28) = 0x802a3f2b1
 RET_SMALL (0x12af7a0)
    stk[25] (0x8029f4f38) = 0x80292a701
 RET_SMALL (0x12af7a0)
    stk[23] (0x8029f4f48) = 0x80292a711
 RET_SMALL (0x136a810)
 Object 0x8029f4f58 = CATCH_FRAME(0x136ac10,0x80292a722)
 RET_SMALL (0x12d1fe8)
    stk[17] (0x8029f4f78) = 0x80292a730
 RET_SMALL (0x136a6b8)
 Object 0x8029f4f88 = CATCH_FRAME(0x136ac10,0x80292a749)
 Object 0x8029f4fa0 = CATCH_FRAME(0x136ac10,0x80292a761)
 Object 0x8029f4fb8 = CATCH_FRAME(0x136ac10,0x80292a779)
 RET_SMALL (0x12c8dd8)
 Object 0x8029f4fd8 = CATCH_FRAME(0x136ac10,0x16f8f30)
 RET_SMALL (0x1370fe0)
 Object 0x8029f4ff8 = STOP_FRAME(0x1370a90)



 ---------------------------------------------------------------
 Returning: Object 0x802f8a498 = FUN/2(0x802db3618)
 Sp = 0x8029f4ee8

 RET_SMALL (0x1374330)
    stk[34] (0x8029f4ef0) = 0x802a40000
 Object 0x8029f4ef8 = UPDATE_FRAME(0x1372400,0x8026bdca0)
 RET_SMALL (0x1372570)
 RET_SMALL (0x12af7a0)
    stk[29] (0x8029f4f18) = 0x8026bde81
 RET_SMALL (0x12af7a0)
    stk[27] (0x8029f4f28) = 0x802a3f2b1
 RET_SMALL (0x12af7a0)
    stk[25] (0x8029f4f38) = 0x80292a701
 RET_SMALL (0x12af7a0)
    stk[23] (0x8029f4f48) = 0x80292a711
 RET_SMALL (0x136a810)
 Object 0x8029f4f58 = CATCH_FRAME(0x136ac10,0x80292a722)
 RET_SMALL (0x12d1fe8)
    stk[17] (0x8029f4f78) = 0x80292a730
 RET_SMALL (0x136a6b8)
 Object 0x8029f4f88 = CATCH_FRAME(0x136ac10,0x80292a749)
 Object 0x8029f4fa0 = CATCH_FRAME(0x136ac10,0x80292a761)
 Object 0x8029f4fb8 = CATCH_FRAME(0x136ac10,0x80292a779)
 RET_SMALL (0x12c8dd8)
 Object 0x8029f4fd8 = CATCH_FRAME(0x136ac10,0x16f8f30)
 RET_SMALL (0x1370fe0)
 Object 0x8029f4ff8 = STOP_FRAME(0x1370a90)

 [1]    60850 segmentation fault  ./stage2/ghc-inplace --interactive +RTS
 -Di -RTS
 }}}

 Could this due to stgRealloc'ed region being still non-executable, despite
 the mprotect() call? Should I instead stick to mmap()'ing the object and
 work out some of avoiding mremap()?

 Many thanks,

 Mathieu

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/2013#comment:4>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Mon Jan  7 12:36:11 2008
From: trac at galois.com (GHC)
Date: Mon Jan  7 12:29:53 2008
Subject: [GHC] #2018: Interface file error with GADT and -O1
In-Reply-To: <053.c8166aa67d18eb09eef50518c042c0a1@localhost>
References: <053.c8166aa67d18eb09eef50518c042c0a1@localhost>
Message-ID: <062.6fbbf45d72b3f7ad11e25928a376d670@localhost>

#2018: Interface file error with GADT and -O1
----------------------------+-----------------------------------------------
 Reporter:  Ashley Yakeley  |          Owner:  igloo         
     Type:  merge           |         Status:  new           
 Priority:  normal          |      Milestone:                
Component:  Compiler        |        Version:  6.8.2         
 Severity:  normal          |     Resolution:                
 Keywords:                  |     Difficulty:  Unknown       
 Testcase:  tc241           |   Architecture:  x86_64 (amd64)
       Os:  Linux           |  
----------------------------+-----------------------------------------------
Changes (by simonpj):

  * testcase:  => tc241
  * owner:  => igloo
  * type:  bug => merge

Comment:

 Great catch.  It was a bug in the full-laziness transformation, related to
 coercion variables.  `-dcore-lint` catches it when you compile `Bug1`.

 Thanks for finding this one.

 Patches to merge:
 {{{
 Mon Jan  7 14:23:06 GMT 2008  simonpj@microsoft.com
   * Make the treatment of equalities more uniform

 Mon Jan  7 14:26:01 GMT 2008  simonpj@microsoft.com
   * Fix Trac #2018: float-out was ignoring the kind of a coercion variable
 }}}

 Simon

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/2018#comment:1>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Mon Jan  7 12:37:57 2008
From: trac at galois.com (GHC)
Date: Mon Jan  7 12:31:39 2008
Subject: [GHC] #2017: Normal Guards are internally spliced as Pattern
 Guards causing compiler warnings
In-Reply-To: <043.0257207c9ea5e0a53cd58c7799a3a94d@localhost>
References: <043.0257207c9ea5e0a53cd58c7799a3a94d@localhost>
Message-ID: <052.f5ce0eb0cc776c480d4530b7e30090f0@localhost>

#2017: Normal Guards are internally spliced as Pattern Guards causing compiler
warnings
------------------------------+---------------------------------------------
 Reporter:  fons              |          Owner:  igloo  
     Type:  merge             |         Status:  new    
 Priority:  normal            |      Milestone:         
Component:  Template Haskell  |        Version:  6.8.2  
 Severity:  normal            |     Resolution:         
 Keywords:                    |     Difficulty:  Unknown
 Testcase:  TH_spliceGuard    |   Architecture:  Unknown
       Os:  Unknown           |  
------------------------------+---------------------------------------------
Changes (by simonpj):

  * testcase:  => TH_spliceGuard
  * owner:  => igloo
  * type:  bug => merge

Comment:

 Good point.  The fix is trivial, and makes the code simpler.  I'm not at
 all sure why it was the way it was.

 Please merge this patch
 {{{
 Mon Jan  7 12:58:19 GMT 2008  simonpj@microsoft.com
   * Fix Trac #2017
 }}}

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/2017#comment:1>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From mechvel at botik.ru  Mon Jan  7 12:41:54 2008
From: mechvel at botik.ru (Serge D. Mechveliani)
Date: Mon Jan  7 12:35:57 2008
Subject: hs-boot types in 6.8.2
In-Reply-To: <20080107163716.GA23946@matrix.chaos.earth.li>
References: <20080107155613.GA3639@scico.botik.ru>
	<20080107163716.GA23946@matrix.chaos.earth.li>
Message-ID: <20080107174154.GA3671@scico.botik.ru>

On Mon, Jan 07, 2008 at 04:37:16PM +0000, Ian Lynagh wrote:
> 
> Hi Serge,
> 
> On Mon, Jan 07, 2008 at 06:56:13PM +0300, Serge D. Mechveliani wrote:
> > 
> > In many situations, GHC reports first what namely is the type 
> > disagreement between *.hs and *.hs-boot.
> 
> We can't look for differences between Reduce.hs-boot and Reduce.hs until
> we have typechecked Reduce.hs, and we can't do that until we have
> compiled Split.hs.

I see. Thank you.
From trac at galois.com  Mon Jan  7 13:26:15 2008
From: trac at galois.com (GHC)
Date: Mon Jan  7 13:19:58 2008
Subject: [GHC] #2020: configure script shipped with ghc is built by
 broken version of autoconf
In-Reply-To: <042.e78128d4b8de30e1332500e785efc22a@localhost>
References: <042.e78128d4b8de30e1332500e785efc22a@localhost>
Message-ID: <051.89db0089b8a274b388b145d89a20d6d7@localhost>

#2020: configure script shipped with ghc is built by broken version of autoconf
----------------------+-----------------------------------------------------
 Reporter:  bos       |          Owner:         
     Type:  bug       |         Status:  new    
 Priority:  normal    |      Milestone:         
Component:  Compiler  |        Version:  6.8.2  
 Severity:  normal    |     Resolution:         
 Keywords:            |     Difficulty:  Unknown
 Testcase:            |   Architecture:  Unknown
       Os:  Unknown   |  
----------------------+-----------------------------------------------------
Comment (by bos):

 Unfortunately, rebuilding ghc after rebuilding the configure scripts was
 not in itself enough to fix the problem.  Even when I configure with
 --docdir=/usr/share/doc/ghc-6.8.2, the package.conf file still contains
 directories of the form /usr/share/doc/ghc.

 I'm adding --htmldir=/usr/share/doc/ghc-6.8.2 to the configure line to see
 if that helps.  The turnaround time for these tests is long, because
 they're run on the distro's main build servers, in clean source trees :-)

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/2020#comment:2>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Mon Jan  7 13:30:16 2008
From: trac at galois.com (GHC)
Date: Mon Jan  7 13:24:16 2008
Subject: [GHC] #2021: let ghc find framework header files and link with
 frameworks located in $HOME/Library/Frameworks
In-Reply-To: <045.f644abcffe54149a52e1b357b6ba7b01@localhost>
References: <045.f644abcffe54149a52e1b357b6ba7b01@localhost>
Message-ID: <054.b2280f43a3bdabbf3c2ce5dc99c41896@localhost>

#2021: let ghc find framework header files and link with frameworks located in
$HOME/Library/Frameworks
-----------------------------+----------------------------------------------
 Reporter:  maeder           |          Owner:             
     Type:  feature request  |         Status:  new        
 Priority:  normal           |      Milestone:             
Component:  Compiler         |        Version:  6.8.2      
 Severity:  normal           |     Resolution:             
 Keywords:                   |     Difficulty:  Easy (1 hr)
 Testcase:                   |   Architecture:  Multiple   
       Os:  MacOS X          |  
-----------------------------+----------------------------------------------
Comment (by thorkilnaur):

 I have not been able to find any mention in Apple documentation (man gcc,
 man ld,
 http://developer.apple.com/documentation/MacOSX/Conceptual/BPFrameworks/BPFrameworks.pdf)
 that $HOME/Library/Frameworks is to be searched automatically. In fact,
 the latter document says
 {{{
 Applications that link to frameworks in other directories, such as
 ~/Library/Frameworks or /Network/Library/Frameworks, must specify the
 exact path to the framework at build time so that the dynamic linker can
 find it.
 }}}
 I do not believe that GHC should provide such an additional service: In
 some cases, it will cause confusion and additional work.

 If the problem is that GHC is not able to pass enough framework-related
 parameters to gcc, ld, and possibly other programs, then that is the
 problem to be solved. That would also allow someone to store local
 frameworks in any desired location, in addition to
 $HOME/Library/Frameworks.

 As I have mentioned elsewhere (http://haskell.org/pipermail/glasgow-
 haskell-users/2008-January/014022.html), I see a need to figure out a
 comprehensive solution to this framework-related matter. I do not
 presently see such a comprehensive solution. Until I do, I am unable to
 tell whether any particular step goes in the right direction or is merely
 a temporary hack to get out of a tight spot.

 Best regards
 Thorkil

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/2021#comment:1>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Mon Jan  7 15:54:48 2008
From: trac at galois.com (GHC)
Date: Mon Jan  7 15:48:29 2008
Subject: [GHC] #2020: configure script shipped with ghc is built by
 broken version of autoconf
In-Reply-To: <042.e78128d4b8de30e1332500e785efc22a@localhost>
References: <042.e78128d4b8de30e1332500e785efc22a@localhost>
Message-ID: <051.2e7d9cb9f2805f9c743560631cc211f3@localhost>

#2020: configure script shipped with ghc is built by broken version of autoconf
----------------------+-----------------------------------------------------
 Reporter:  bos       |          Owner:         
     Type:  bug       |         Status:  new    
 Priority:  normal    |      Milestone:         
Component:  Compiler  |        Version:  6.8.2  
 Severity:  normal    |     Resolution:         
 Keywords:            |     Difficulty:  Unknown
 Testcase:            |   Architecture:  Unknown
       Os:  Unknown   |  
----------------------+-----------------------------------------------------
Comment (by bos):

 Adding --htmldir does not help, either.  I conclude that docdir and
 htmldir are somehow going missing.

 If you'd like to see the output from a build that verifies that docdir and
 htmldir are being used properly, please take a look here:
 http://koji.fedoraproject.org/koji/getfile?taskID=331547&name=build.log

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/2020#comment:3>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Mon Jan  7 16:55:11 2008
From: trac at galois.com (GHC)
Date: Mon Jan  7 16:48:53 2008
Subject: [GHC] #2020: configure script shipped with ghc is built by
 broken version of autoconf
In-Reply-To: <042.e78128d4b8de30e1332500e785efc22a@localhost>
References: <042.e78128d4b8de30e1332500e785efc22a@localhost>
Message-ID: <051.7f71909ad2056328a44ff6d312053073@localhost>

#2020: configure script shipped with ghc is built by broken version of autoconf
----------------------+-----------------------------------------------------
 Reporter:  bos       |          Owner:         
     Type:  bug       |         Status:  closed 
 Priority:  normal    |      Milestone:         
Component:  Compiler  |        Version:  6.8.2  
 Severity:  normal    |     Resolution:  wontfix
 Keywords:            |     Difficulty:  Unknown
 Testcase:            |   Architecture:  Unknown
       Os:  Unknown   |  
----------------------+-----------------------------------------------------
Changes (by igloo):

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

Comment:

 We still want to be able to build on machines with older autoreconf's (as
 some of the nightly builders, and probably some of the developer's
 machines, still have it). That means that we can't rely on the docdir flag
 existing, so we ignore its value.

 You can specify docdir by setting the variable in `mk/build.mk`.
 Unfortunately, this doesn't modify htmldir etc in the way that you would
 expect. When building the Debian packages we put these lines in
 `mk/build.mk`:

 {{{
 docdir  := $(datarootdir)/doc/ghc6-doc
 htmldir := $(docdir)
 dvidir  := $(docdir)
 pdfdir  := $(docdir)
 psdir   := $(docdir)
 }}}

 This code is due to be rewritten in 6.10 so that only the first line is
 necessary: see #1924.

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/2020#comment:4>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Mon Jan  7 20:12:51 2008
From: trac at galois.com (GHC)
Date: Mon Jan  7 20:06:44 2008
Subject: [GHC] #2021: let ghc find framework header files and link with
 frameworks located in $HOME/Library/Frameworks
In-Reply-To: <045.f644abcffe54149a52e1b357b6ba7b01@localhost>
References: <045.f644abcffe54149a52e1b357b6ba7b01@localhost>
Message-ID: <054.f15d2841df32477d12d2bafc5605a24d@localhost>

#2021: let ghc find framework header files and link with frameworks located in
$HOME/Library/Frameworks
-----------------------------+----------------------------------------------
 Reporter:  maeder           |          Owner:             
     Type:  feature request  |         Status:  new        
 Priority:  normal           |      Milestone:             
Component:  Compiler         |        Version:  6.8.2      
 Severity:  normal           |     Resolution:             
 Keywords:                   |     Difficulty:  Easy (1 hr)
 Testcase:                   |   Architecture:  Multiple   
       Os:  MacOS X          |  
-----------------------------+----------------------------------------------
Comment (by guest):

 Replying to [comment:1 thorkilnaur]:
 >
 > If the problem is that GHC is not able to pass enough framework-related
 parameters to gcc, ld, and possibly other programs, then that is the
 problem to be solved. That would also allow someone to store local
 frameworks in any desired location, in addition to
 $HOME/Library/Frameworks.

 GHC can pass -F (the only relevant parameter, I believe) to `gcc` and `ld`
 just fine.  The problem IMHO is that there's no way to run the build of
 ghc+libraries as a whole against an extra framework directory without
 editing several different `Makefile` and/or `.cabal` files.

 I think this problem will be solved when at most one change is required
 to, for example, link the build against a version of
 `GNUreadline.framework` which is in a nonstandard location.  That "change"
 could be one of (but not limited to): editing `mk/build.mk` or
 `readline.cabal`, or passing a configure flag.

 Incidentally, the above was my reason for proposing the following Cabal
 enhancement: http://hackage.haskell.org/trac/hackage/ticket/189

 -Judah

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/2021#comment:2>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Mon Jan  7 20:30:31 2008
From: trac at galois.com (GHC)
Date: Mon Jan  7 20:24:16 2008
Subject: [GHC] #2024: Template Haskell doesn't work well with Lexically
 Scoped Type Variables
Message-ID: <043.ad4f76fd8928e0aaf2d125b91ef52e82@localhost>

#2024: Template Haskell doesn't work well with Lexically Scoped Type Variables
---------------------------------+------------------------------------------
    Reporter:  fons              |       Owner:         
        Type:  bug               |      Status:  new    
    Priority:  normal            |   Milestone:         
   Component:  Template Haskell  |     Version:  6.8.2  
    Severity:  normal            |    Keywords:         
  Difficulty:  Unknown           |    Testcase:         
Architecture:  Unknown           |          Os:  Unknown
---------------------------------+------------------------------------------
 I don't know if TH is meant to work properly with LSTV. I don't personally
 need it and I run into this bug by chance, but at least I think that the
 error should be friendlier in any case. See this (pretty stupid, sorry)
 example.

 Foo.hs
 {{{
 {-# LANGUAGE TemplateHaskell, ScopedTypeVariables #-}
 module Foo where


 myid :: forall a . a -> a
 myid = $([| (\x -> x) :: (a -> a) |])
 }}}

 Ghci shows this user-unfriendly error:


 {{{
 $ ghci Foo.hs
 GHCi, version 6.8.2: http://www.haskell.org/ghc/  :? for help
 Loading package base ... linking ... done.
 [1 of 1] Compiling Foo              ( Foo.hs, interpreted )

 Foo.hs:6:12:
     DsMeta: failed binder lookup when desugaring a TH bracket: a
 Failed, modules loaded: none.
 Prelude>
 }}}

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/2024>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Mon Jan  7 21:22:09 2008
From: trac at galois.com (GHC)
Date: Mon Jan  7 21:15:54 2008
Subject: [GHC] #1599: testsuite timeout doesn't kill subprocesses on
 Windows
In-Reply-To: <047.b1020b9504f2c2f7ec4496c2c9545397@localhost>
References: <047.b1020b9504f2c2f7ec4496c2c9545397@localhost>
Message-ID: <056.4a173092b72d39223642aff66c5f58c0@localhost>

#1599: testsuite timeout doesn't kill subprocesses on Windows
------------------------+---------------------------------------------------
 Reporter:  simonmar    |          Owner:  igloo     
     Type:  bug         |         Status:  new       
 Priority:  normal      |      Milestone:  6.8 branch
Component:  Test Suite  |        Version:  6.6.1     
 Severity:  normal      |     Resolution:            
 Keywords:              |     Difficulty:  Unknown   
 Testcase:              |   Architecture:  x86       
       Os:  Windows     |  
------------------------+---------------------------------------------------
Comment (by igloo):

 Using this python program:
 {{{
 #!/usr/bin/python

 from killableprocess import *
 from sys import argv

 p = Popen(args=argv[1])
 r = p.wait(timeout=1)
 print r
 }}}
 and this Haskell program:
 {{{
 import Foreign.C
 import System.Cmd
 import System.IO

 main :: IO ()
 main = do hSetBuffering stdout NoBuffering
           putStrLn "start main"
           -- rawSystem "c:/cygwin/bin/sh"
           --           ["-c", "echo wibble; sleep 3; echo flibble"]
           -- system "sh -c \"echo wibble; sleep 3; echo flibble\""
           withCString "sh -c \"echo wibble; sleep 3; echo flibble\"" s
           putStrLn "end main"

 foreign import ccall "stdlib.h system" s :: CString -> IO CInt
 }}}
 it doesn't seem to work (the "flibble" on the last line is printed after
 the command has terminated):
 {{{
 $ ghc --make Foo -fffi
 [1 of 1] Compiling Main             ( Foo.hs, Foo.o )
 Linking Foo.exe ...

 $ ./ptimeout.py ./Foo
 start main
 wibble
 -9

 $ flibble
 }}}
 Even with this C program:
 {{{
 #include <stdio.h>
 #include <stdlib.h>

 int main(void) {
       printf("start main\n");
       system("sh -c \"echo wibble; sleep 3; echo flibble\"");
       printf("end main\n");
 }
 }}}
 it doesn't seem to work right:
 {{{
 $ gcc c.c -o c

 $ ./ptimeout.py ./c
 start main
 wibble
 flibble
 -9

 $ ./ptimeout.py ./c
 start main
 wibble
 -9
 end main

 $ ./ptimeout.py ./c
 start main
 wibble
 -9
 }}}

 The C++ program that is linked to also doesn't work for me:
 {{{
 $ Debug/killableprocess.exe ./c
 start main
 end main

 $
 }}}

 I'll try to investigate further.

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/1599#comment:2>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Tue Jan  8 01:33:35 2008
From: trac at galois.com (GHC)
Date: Tue Jan  8 01:27:25 2008
Subject: [GHC] #2021: let ghc find framework header files and link with
 frameworks located in $HOME/Library/Frameworks
In-Reply-To: <045.f644abcffe54149a52e1b357b6ba7b01@localhost>
References: <045.f644abcffe54149a52e1b357b6ba7b01@localhost>
Message-ID: <054.af6b5cd390f4835901f8fdc086b057ed@localhost>

#2021: let ghc find framework header files and link with frameworks located in
$HOME/Library/Frameworks
-----------------------------+----------------------------------------------
 Reporter:  maeder           |          Owner:             
     Type:  feature request  |         Status:  new        
 Priority:  normal           |      Milestone:             
Component:  Compiler         |        Version:  6.8.2      
 Severity:  normal           |     Resolution:             
 Keywords:                   |     Difficulty:  Easy (1 hr)
 Testcase:                   |   Architecture:  Multiple   
       Os:  MacOS X          |  
-----------------------------+----------------------------------------------
Comment (by thorkilnaur):

 This sounds like a problem in the GHC build process, then. Not something
 that should necessarily involve changes to GHC (as proposed in the present
 ticket). Nor to Cabal, for that matter
 (http://hackage.haskell.org/trac/hackage/ticket/189).

 I still believe that we must start out by figuring out what the total
 problem is. So in this case, I would expect to start out with a detailed
 list of changes, under the present circumstances, needed to add whatever
 framework-related parameters are needed in whatever phase of the
 GHC/libraries build process they are needed, to introduce a new framework.
 And then, in terms of the GHC/libraries build process, figure out a way to
 become able to, as you say, introduce the framework in just one place.

 It may very well turn out that we find, in this process, that some other
 component, GHC, Cabal, some utility program, also needs to be extended:
 hsc2hs has been discussed, the Haskell CPP implementation comes to mind as
 another place where changes might be needed. But without the total view,
 it is difficult to decide whether any particular proposed change makes
 sense.

 Best regards Thorkil

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/2021#comment:3>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Tue Jan  8 03:14:42 2008
From: trac at galois.com (GHC)
Date: Tue Jan  8 03:08:32 2008
Subject: [GHC] #2025: supply a testsuite archive together with a source
 release (for ghc-6.8.3)
Message-ID: <045.0e8ff99e04b969df257e0d8f895be8f0@localhost>

#2025: supply a testsuite archive together with a source release (for ghc-6.8.3)
--------------------------------+-------------------------------------------
    Reporter:  maeder           |       Owner:          
        Type:  feature request  |      Status:  new     
    Priority:  normal           |   Milestone:          
   Component:  Build System     |     Version:  6.8.2   
    Severity:  normal           |    Keywords:          
  Difficulty:  Easy (1 hr)      |    Testcase:          
Architecture:  Multiple         |          Os:  Multiple
--------------------------------+-------------------------------------------
 For those who build bindists and users who use them some checking against
 a testsuite might be desirable.

 I did not test my builds because a `testsuite.tgz` was not (easily)
 available.

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/2025>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Tue Jan  8 03:56:16 2008
From: trac at galois.com (GHC)
Date: Tue Jan  8 03:49:57 2008
Subject: [GHC] #998: Tab-completion of filenames does not work in GHCi
 6.6
In-Reply-To: <061.a0a29a0da74b1264616768b293fe2c41@localhost>
References: <061.a0a29a0da74b1264616768b293fe2c41@localhost>
Message-ID: <070.dcf231ac90e3b82ea0953692c91dc9a0@localhost>

#998: Tab-completion of filenames does not work in GHCi 6.6
------------------------------------+---------------------------------------
 Reporter:  dm.maillists@gmail.com  |          Owner:  simonmar   
     Type:  bug                     |         Status:  new        
 Priority:  low                     |      Milestone:  6.10 branch
Component:  GHCi                    |        Version:  6.6        
 Severity:  minor                   |     Resolution:             
 Keywords:                          |     Difficulty:  Unknown    
 Testcase:                          |   Architecture:  Multiple   
       Os:  Multiple                |  
------------------------------------+---------------------------------------
Comment (by guest):

 If it is too difficult to implement both function and file name
 completion, then I like to have an command line option which switches back
 to pure file name completion like in GHC-6.4 and before.

 In SWI-PROLOG they solved it somehow, that you can complete predicate
 names with TAB and if no predicate with the given prefix exists then a
 file name is chosen. I don't know if it is a good idea to port this to
 GHCi. Texts after :load and in quotation marks are certainly no function
 names and thus should cause file name completion.

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/998#comment:10>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Tue Jan  8 04:30:06 2008
From: trac at galois.com (GHC)
Date: Tue Jan  8 04:23:47 2008
Subject: [GHC] #2022: DLL support broken
In-Reply-To: <042.43c39ca72c9b8eecfec3978a18e72791@localhost>
References: <042.43c39ca72c9b8eecfec3978a18e72791@localhost>
Message-ID: <051.1b4682943504c1b47ab89b74322421a8@localhost>

#2022: DLL support broken
----------------------+-----------------------------------------------------
 Reporter:  mte       |          Owner:         
     Type:  bug       |         Status:  new    
 Priority:  normal    |      Milestone:         
Component:  Compiler  |        Version:  6.8.2  
 Severity:  normal    |     Resolution:         
 Keywords:            |     Difficulty:  Unknown
 Testcase:            |   Architecture:  x86    
       Os:  Windows   |  
----------------------+-----------------------------------------------------
Comment (by simonmar):

 It looks like you need to add `-package containers -package array`.  Could
 you confirm that that fixes it?

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/2022#comment:1>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Tue Jan  8 04:46:57 2008
From: trac at galois.com (GHC)
Date: Tue Jan  8 04:40:39 2008
Subject: [GHC] #2013: ghci crash on startup: R_X86_64_32S relocation out
 of range.
In-Reply-To: <044.2f007075e8a3e652be5aa7c77056c714@localhost>
References: <044.2f007075e8a3e652be5aa7c77056c714@localhost>
Message-ID: <053.ed41dcd183a296bef4d005b49c2b431f@localhost>

#2013: ghci crash on startup: R_X86_64_32S relocation out of range.
---------------------+------------------------------------------------------
 Reporter:  mboes    |          Owner:                
     Type:  bug      |         Status:  new           
 Priority:  normal   |      Milestone:  6.8.3         
Component:  GHCi     |        Version:  6.9           
 Severity:  normal   |     Resolution:                
 Keywords:           |     Difficulty:  Unknown       
 Testcase:           |   Architecture:  x86_64 (amd64)
       Os:  FreeBSD  |  
---------------------+------------------------------------------------------
Comment (by simonmar):

 Setting milestone to 6.8.3 as we would like GHCi to work properly on
 FreeBSD/x86-64.

 I don't have any good suggestions yet.  Object code that is not compiled
 with `-fPIC` must be all linked together in the same 2Gb segment of the
 address space, because 32-bit relative addressing is used throughout.  We
 use the small memory model by default, like gcc - I haven't investigated
 using larger memory models, but in any case `-fPIC` would be better than
 moving to another memory model as it is already implemented.

 Unfortunately `-fPIC` doesn't really solve the problem - even objects
 compiled with `-fPIC` assume that other objects in the same package are
 within the same 2Gb segment.  So we really do need a way to map memory in
 the low 2Gb.  As far as I can tell, the only way to do this when MAP_32BIT
 is not supported is with the hint address - perhaps look at the memory map
 of the running process, and figure out a suitable place to request memory?
 It might be necessary to coordinate with `MBlock.c` to avoid requesting
 memory in the low 2Gb when we don't need it.

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/2013#comment:5>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Tue Jan  8 08:40:39 2008
From: trac at galois.com (GHC)
Date: Tue Jan  8 08:34:21 2008
Subject: [GHC] #2013: ghci crash on startup: R_X86_64_32S relocation out
 of range.
In-Reply-To: <044.2f007075e8a3e652be5aa7c77056c714@localhost>
References: <044.2f007075e8a3e652be5aa7c77056c714@localhost>
Message-ID: <053.28a736c8254f64904960db8464e6975c@localhost>

#2013: ghci crash on startup: R_X86_64_32S relocation out of range.
---------------------+------------------------------------------------------
 Reporter:  mboes    |          Owner:                
     Type:  bug      |         Status:  new           
 Priority:  normal   |      Milestone:  6.8.3         
Component:  GHCi     |        Version:  6.9           
 Severity:  normal   |     Resolution:                
 Keywords:           |     Difficulty:  Unknown       
 Testcase:           |   Architecture:  x86_64 (amd64)
       Os:  FreeBSD  |  
---------------------+------------------------------------------------------
Comment (by wb.kloke):

 Is it feasible to link packages like base statically to ghci to get ghci
 working for simple programs not loading modules?

 Or else, as base is already wired-in, is the loading of base necessary at
 all?

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/2013#comment:6>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Tue Jan  8 10:21:37 2008
From: trac at galois.com (GHC)
Date: Tue Jan  8 10:15:26 2008
Subject: [GHC] #2013: ghci crash on startup: R_X86_64_32S relocation out
 of range.
In-Reply-To: <044.2f007075e8a3e652be5aa7c77056c714@localhost>
References: <044.2f007075e8a3e652be5aa7c77056c714@localhost>
Message-ID: <053.ad26e47d33477ea17e9004fa32bcf068@localhost>

#2013: ghci crash on startup: R_X86_64_32S relocation out of range.
---------------------+------------------------------------------------------
 Reporter:  mboes    |          Owner:                
     Type:  bug      |         Status:  new           
 Priority:  normal   |      Milestone:  6.8.3         
Component:  GHCi     |        Version:  6.9           
 Severity:  normal   |     Resolution:                
 Keywords:           |     Difficulty:  Unknown       
 Testcase:           |   Architecture:  x86_64 (amd64)
       Os:  FreeBSD  |  
---------------------+------------------------------------------------------
Comment (by mboes):

 Good news: I have a working ghci loading base and giving me a prompt! This
 is done by adding MAP_FIXED to the EXTRA_MAP_FLAGS and giving a hint
 address, both in loadObj() and in x64_64_high_symbol(). Of course, ghci
 segfaults the minute you try to link in more packages, because  new
 objects will overwrite the old ones in memory at the fixed address.

 The upshot is that forcing 32-bit clean mmap()'s is the only issue needing
 solving for ghci on FreeBSD/amd64. All the bugs I used to see with 6.6.1
 (eg. race conditions with writing characters to the screen) are now gone.
 The trick to solve this issue is to calculate a valid place in memory to
 mmap() objects in, large enough for the whole object, that does not
 conflict with anything else living in memory. Simon, any suggestions as to
 the best way to do that?

 At the moment I'm loading the object at the 1Gb boundary, and looking
 around on the web that's the way that Xorg project are working around
 their need for a MAP_32BIT flag on NetBSD. It's an ugly hack, but I don't
 see any other way of dealing with a lack of MAP_32BIT. We could increment
 the load address by oc->fileSize + <space for jump islands> at each object
 load, so that all objects are somewhere above the 1Gb mark. Then create
 jump islands for each loaded object directly after it in memory. However,
 if we're loading so much in memory at fixed locations we'd have to be very
 sure that nothing else is allocated above the 1Gb mark before the linking.
 How feasible is this?

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/2013#comment:7>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Tue Jan  8 10:56:44 2008
From: trac at galois.com (GHC)
Date: Tue Jan  8 10:50:24 2008
Subject: [GHC] #2026: Simple data types in System.Posix.IO should have Eq,
 Ord, etc. instances
Message-ID: <042.c7b8191d6013374955fde7ef230ffb1a@localhost>

#2026: Simple data types in System.Posix.IO should have Eq, Ord, etc. instances
----------------------------------+-----------------------------------------
    Reporter:  wjt                |       Owner:         
        Type:  bug                |      Status:  new    
    Priority:  normal             |   Milestone:         
   Component:  libraries (other)  |     Version:  6.6.1  
    Severity:  minor              |    Keywords:         
  Difficulty:  Easy (1 hr)        |    Testcase:         
Architecture:  Unknown            |          Os:  Unknown
----------------------------------+-----------------------------------------
 When trying to use `OpenMode` in a `Data.Map` key, I noticed that it's not
 an instance of `Ord` or even `Eq`.  Nor are `OpenFileFlags`, `FdOption`,
 `LockRequest`.  I don't see particularly meaningful orderings for them,
 but meaningless orderings would be useful nonetheless.

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/2026>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Tue Jan  8 13:21:53 2008
From: trac at galois.com (GHC)
Date: Tue Jan  8 13:15:42 2008
Subject: [GHC] #1907: HPC and Template Haskell don't mix
In-Reply-To: <044.04728c864207e67b417a4402811081dd@localhost>
References: <044.04728c864207e67b417a4402811081dd@localhost>
Message-ID: <053.c64361109299f315a84ac2d0274b88cd@localhost>

#1907: HPC and Template Haskell don't mix
---------------------------+------------------------------------------------
 Reporter:  guest          |          Owner:  AndyGill   
     Type:  bug            |         Status:  closed     
 Priority:  normal         |      Milestone:  6.10 branch
Component:  Code Coverage  |        Version:  6.8.1      
 Severity:  normal         |     Resolution:  worksforme 
 Keywords:                 |     Difficulty:  Unknown    
 Testcase:                 |   Architecture:  Unknown    
       Os:  Unknown        |  
---------------------------+------------------------------------------------
Changes (by AndyGill):

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

Comment:

 This works just fine in ghc-6.9.20080107; but does fail on 6.8.1.
 I'm closing it as resolved for now.

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/1907#comment:4>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Tue Jan  8 13:39:43 2008
From: trac at galois.com (GHC)
Date: Tue Jan  8 13:33:24 2008
Subject: [GHC] #2027: ghc -e sometimes spills control characters into its
 output
Message-ID: <044.17b329c7bf8a300b55ac85b04d1b0204@localhost>

#2027: ghc -e  sometimes spills control characters into its output
----------------------------+-----------------------------------------------
    Reporter:  int-e        |       Owner:       
        Type:  bug          |      Status:  new  
    Priority:  normal       |   Milestone:       
   Component:  GHCi         |     Version:  6.8.2
    Severity:  minor        |    Keywords:       
  Difficulty:  Easy (1 hr)  |    Testcase:       
Architecture:  Unknown      |          Os:  Linux
----------------------------+-----------------------------------------------
 The behaviour depends on the TERM variable. For example,

 {{{
 # TERM=xterm ghc -e 'return ()' | od -a
 0000000 esc   [   ?   1   0   3   4   h
 0000010
 }}}

 Workaround: unset the TERM variable.

 Analysis: Those control characters are emitted by libreadline on
 initialisation. They enable the terminal's meta mode.

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/2027>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Tue Jan  8 14:14:21 2008
From: trac at galois.com (GHC)
Date: Tue Jan  8 14:07:59 2008
Subject: [GHC] #2027: ghc -e sometimes spills control characters into
 its output
In-Reply-To: <044.17b329c7bf8a300b55ac85b04d1b0204@localhost>
References: <044.17b329c7bf8a300b55ac85b04d1b0204@localhost>
Message-ID: <053.c1e51a9a901b1cc7633ffb0b1d56df4f@localhost>

#2027: ghc -e  sometimes spills control characters into its output
--------------------+-------------------------------------------------------
 Reporter:  int-e   |          Owner:             
     Type:  bug     |         Status:  new        
 Priority:  normal  |      Milestone:             
Component:  GHCi    |        Version:  6.8.2      
 Severity:  minor   |     Resolution:             
 Keywords:          |     Difficulty:  Easy (1 hr)
 Testcase:          |   Architecture:  Unknown    
       Os:  Linux   |  
--------------------+-------------------------------------------------------
Comment (by duncan):

 I get this behavior with runghc too. It adds some control character to the
 end of the output. This makes it unusable in many scripting applications
 and breaks some testsuite tests. Again, setting TERM=vt100 or similar
 rather than "xterm" fixes it.

 So when verifying the fix, test with runghc as well as ghc -e.

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/2027#comment:1>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Tue Jan  8 15:22:50 2008
From: trac at galois.com (GHC)
Date: Tue Jan  8 15:16:29 2008
Subject: [GHC] #2027: ghc -e sometimes spills control characters into
 its output
In-Reply-To: <044.17b329c7bf8a300b55ac85b04d1b0204@localhost>
References: <044.17b329c7bf8a300b55ac85b04d1b0204@localhost>
Message-ID: <053.6c4c096bb07c0c5d34707db8d89b6ee7@localhost>

#2027: ghc -e  sometimes spills control characters into its output
--------------------+-------------------------------------------------------
 Reporter:  int-e   |          Owner:             
     Type:  bug     |         Status:  new        
 Priority:  normal  |      Milestone:             
Component:  GHCi    |        Version:  6.8.2      
 Severity:  minor   |     Resolution:             
 Keywords:          |     Difficulty:  Easy (1 hr)
 Testcase:          |   Architecture:  Unknown    
       Os:  Linux   |  
--------------------+-------------------------------------------------------
Comment (by int-e):

 Replying to [comment:1 duncan]:
 > I get this behavior with runghc too. It adds some control character to
 the end of the output. This makes it unusable in many scripting
 applications and breaks some testsuite tests. Again, setting TERM=vt100 or
 similar rather than "xterm" fixes it.

 Good point. I tried that with my patch and it fixes that case as well,
 even when input is from a terminal.

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/2027#comment:2>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Tue Jan  8 19:31:20 2008
From: trac at galois.com (GHC)
Date: Tue Jan  8 19:24:58 2008
Subject: [GHC] #1779: unknown symbol `hs_hpc_module'
In-Reply-To: <044.e238a8559ffe0a21198f4a819a87e869@localhost>
References: <044.e238a8559ffe0a21198f4a819a87e869@localhost>
Message-ID: <053.a8e425604ba1acae48396c209433809b@localhost>

#1779: unknown symbol `hs_hpc_module'
-----------------------------+----------------------------------------------
 Reporter:  guest            |          Owner:  AndyGill   
     Type:  feature request  |         Status:  closed     
 Priority:  low              |      Milestone:  6.10 branch
Component:  GHCi             |        Version:  6.9        
 Severity:  minor            |     Resolution:  worksforme 
 Keywords:  hpc              |     Difficulty:  Unknown    
 Testcase:                   |   Architecture:  Unknown    
       Os:  Unknown          |  
-----------------------------+----------------------------------------------
Changes (by AndyGill):

  * status:  assigned => closed
  * resolution:  => worksforme

Comment:

 This no longer prints a message, and works just fine, in HEAD.

 I compiled a module using -fhpc, then used ghci on another module that
 used
 the original module and it ran just fine.

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/1779#comment:5>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Wed Jan  9 05:25:26 2008
From: trac at galois.com (GHC)
Date: Wed Jan  9 05:19:06 2008
Subject: [GHC] #2013: ghci crash on startup: R_X86_64_32S relocation out
 of range.
In-Reply-To: <044.2f007075e8a3e652be5aa7c77056c714@localhost>
References: <044.2f007075e8a3e652be5aa7c77056c714@localhost>
Message-ID: <053.b363a5b54d8aabaabeb5b5e039a24b4b@localhost>

#2013: ghci crash on startup: R_X86_64_32S relocation out of range.
---------------------+------------------------------------------------------
 Reporter:  mboes    |          Owner:                
     Type:  bug      |         Status:  new           
 Priority:  normal   |      Milestone:  6.8.3         
Component:  GHCi     |        Version:  6.9           
 Severity:  normal   |     Resolution:                
 Keywords:           |     Difficulty:  Unknown       
 Testcase:           |   Architecture:  x86_64 (amd64)
       Os:  FreeBSD  |  
---------------------+------------------------------------------------------
Comment (by simonmar):

 Replying to [comment:6 wb.kloke]:
 > Is it feasible to link packages like base statically to ghci to get ghci
 working for simple programs not loading modules?
 >
 > Or else, as base is already wired-in, is the loading of base necessary
 at all?

 With static linking, the short answer is no (we have investigated various
 strategies and not found a way to do this reliably).  The right way is to
 use dynamic linking, where the base package is a shared library, and can
 be used by both GHCi itself and the running program.  Dynamic linking is
 mostly working, we're just fixing issues with installation and
 distributions.

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/2013#comment:8>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Wed Jan  9 05:28:43 2008
From: trac at galois.com (GHC)
Date: Wed Jan  9 05:22:20 2008
Subject: [GHC] #2013: ghci crash on startup: R_X86_64_32S relocation out
 of range.
In-Reply-To: <044.2f007075e8a3e652be5aa7c77056c714@localhost>
References: <044.2f007075e8a3e652be5aa7c77056c714@localhost>
Message-ID: <053.db5f511297a357b55a80ca8fc973eb6a@localhost>

#2013: ghci crash on startup: R_X86_64_32S relocation out of range.
---------------------+------------------------------------------------------
 Reporter:  mboes    |          Owner:                
     Type:  bug      |         Status:  new           
 Priority:  normal   |      Milestone:  6.8.3         
Component:  GHCi     |        Version:  6.9           
 Severity:  normal   |     Resolution:                
 Keywords:           |     Difficulty:  Unknown       
 Testcase:           |   Architecture:  x86_64 (amd64)
       Os:  FreeBSD  |  
---------------------+------------------------------------------------------
Comment (by simonmar):

 Replying to [comment:7 mboes]:
 > Good news: I have a working ghci loading base and giving me a prompt!
 This is done by adding MAP_FIXED to the EXTRA_MAP_FLAGS and giving a hint
 address, both in loadObj() and in x64_64_high_symbol(). Of course, ghci
 segfaults the minute you try to link in more packages, because  new
 objects will overwrite the old ones in memory at the fixed address.
 >
 > The upshot is that forcing 32-bit clean mmap()'s is the only issue
 needing solving for ghci on FreeBSD/amd64. All the bugs I used to see with
 6.6.1 (eg. race conditions with writing characters to the screen) are now
 gone. The trick to solve this issue is to calculate a valid place in
 memory to mmap() objects in, large enough for the whole object, that does
 not conflict with anything else living in memory. Simon, any suggestions
 as to the best way to do that?
 >
 > At the moment I'm loading the object at the 1Gb boundary, and looking
 around on the web that's the way that Xorg project are working around
 their need for a MAP_32BIT flag on NetBSD. It's an ugly hack, but I don't
 see any other way of dealing with a lack of MAP_32BIT. We could increment
 the load address by oc->fileSize + <space for jump islands> at each object
 load, so that all objects are somewhere above the 1Gb mark. Then create
 jump islands for each loaded object directly after it in memory. However,
 if we're loading so much in memory at fixed locations we'd have to be very
 sure that nothing else is allocated above the 1Gb mark before the linking.
 How feasible is this?

 This is encouraging.  It looks like the solution is going to be dependent
 on the layout of memory on FreeBSD and hence might be fragile to future
 changes in that area, but it's better than nothing.

 You want to look at the memory map of the running process to figure out
 where the best place to allocate memory is.  On Linux the memory map is
 available in `/proc/<pid>/maps` for process `<pid>`.

 Note that `MBlock.c` also allocates memory using `mmap`, you probably want
 to check that it isn't accidentally grabbing some of the sub-2Gb memory
 which would cause problems for the linker.

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/2013#comment:9>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Wed Jan  9 10:55:37 2008
From: trac at galois.com (GHC)
Date: Wed Jan  9 10:49:16 2008
Subject: [GHC] #2022: DLL support broken
In-Reply-To: <042.43c39ca72c9b8eecfec3978a18e72791@localhost>
References: <042.43c39ca72c9b8eecfec3978a18e72791@localhost>
Message-ID: <051.a06e07c67a3b5bf4e335ca21803a82df@localhost>

#2022: DLL support broken
----------------------+-----------------------------------------------------
 Reporter:  mte       |          Owner:         
     Type:  bug       |         Status:  new    
 Priority:  normal    |      Milestone:         
Component:  Compiler  |        Version:  6.8.2  
 Severity:  normal    |     Resolution:         
 Keywords:            |     Difficulty:  Unknown
 Testcase:            |   Architecture:  x86    
       Os:  Windows   |  
----------------------+-----------------------------------------------------
Comment (by mte):

 Adding -package containers -package array AND -package haskell98 fixes the
 problem, both foobar.dll and foobar.dll.a are built and the DLL works
 fine. It is misleading, however, that ghc reports the creation of
 foobar.dll.a only.

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/2022#comment:2>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Wed Jan  9 11:26:13 2008
From: trac at galois.com (GHC)
Date: Wed Jan  9 11:19:49 2008
Subject: [GHC] #2028: STM slightly conservative on write-only transactions
Message-ID: <048.c06b21d8ef59b6cc153a10d02c678d4e@localhost>

#2028: STM slightly conservative on write-only transactions
--------------------------+-------------------------------------------------
    Reporter:  JulesBean  |       Owner:         
        Type:  proposal   |      Status:  new    
    Priority:  normal     |   Milestone:         
   Component:  Compiler   |     Version:  6.8.1  
    Severity:  normal     |    Keywords:         
  Difficulty:  Unknown    |    Testcase:         
Architecture:  Unknown    |          Os:  Unknown
--------------------------+-------------------------------------------------
 The STM appears to be slightly too conservative on write-only
 transactions.

 It will store a copy of the current (that is, old) value on a writeTVar,
 even if it was never read from. This can cause a spurious retry.

 E.g. {{{atomically $ writeTVar tv 0}}} really has no reason to ever retry.
 Neither, in fact, does {{{atomically $ mapM (\tv -> writeTVar tv 0)
 [tv1,tv2,tv3,tv4]}}}.

 My suggestion is to instead indicate "no prior value" for that TVar, and
 then make no consistency checks on TVars marked as no prior value...

 Jules

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/2028>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Wed Jan  9 13:01:10 2008
From: trac at galois.com (GHC)
Date: Wed Jan  9 12:54:47 2008
Subject: [GHC] #2029: Add --with-libedit flag to the readline package
Message-ID: <044.f95d970cfe3a09acd95facdbee2dd79a@localhost>

#2029: Add --with-libedit flag to the readline package
----------------------------------+-----------------------------------------
    Reporter:  judah              |       Owner:          
        Type:  proposal           |      Status:  new     
    Priority:  normal             |   Milestone:  Not GHC 
   Component:  libraries (other)  |     Version:          
    Severity:  normal             |    Keywords:          
  Difficulty:  Unknown            |    Testcase:          
Architecture:  Multiple           |          Os:  Multiple
----------------------------------+-----------------------------------------
 It would be useful for the readline package to support compiling against
 the libedit library (which provides a subset of the readline APIs):
  - libedit is available by default on OS X.
  - since libedit is BSD-licensed, there are no problems statically linking
 ghc with it.  (This may be useful on Windows.)

 I propose adding a `--with-libedit` flag to the readline autoconf script.
 Without that flag, the package will behave exactly as before, refusing to
 link against libedit.  With that flag, the following behavior occurs:
  - `GNUreadline.framework` (OS X - only) is ignored, if present
  - We try to link with -lreadline, and don't fail if readline is actually
 libedit.
  - If it is libedit, we #ifdef out all of the functions not supported by
 libedit.  (these are generally low-level APIs not needed by most
 applications, including `ghci`.)  Otherwise, if we're linking against GNU
 readline, we support all the available APIs.

 Suggested deadline: Jan. 23, 2008.

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/2029>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Wed Jan  9 13:18:13 2008
From: trac at galois.com (GHC)
Date: Wed Jan  9 13:11:52 2008
Subject: [GHC] #2030: GHC internal error: `m' is not in scope
Message-ID: <043.1667a40fa37775839c3eb6215de0afe4@localhost>

#2030: GHC internal error: `m' is not in scope
-------------------------------+--------------------------------------------
    Reporter:  ToRA            |       Owner:       
        Type:  bug             |      Status:  new  
    Priority:  normal          |   Milestone:       
   Component:  Compiler        |     Version:  6.8.1
    Severity:  normal          |    Keywords:       
  Difficulty:  Unknown         |    Testcase:       
Architecture:  x86_64 (amd64)  |          Os:  Linux
-------------------------------+--------------------------------------------
 Tripped this while trying to use ScopedTypeVariables under 6.8.2

 Have stripped the code down as far as I could simply see while retaining
 the bug.  isSafeAlt seems to be the starting point.

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/2030>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Wed Jan  9 13:21:04 2008
From: trac at galois.com (GHC)
Date: Wed Jan  9 13:14:40 2008
Subject: [GHC] #2030: GHC internal error: `m' is not in scope
In-Reply-To: <043.1667a40fa37775839c3eb6215de0afe4@localhost>
References: <043.1667a40fa37775839c3eb6215de0afe4@localhost>
Message-ID: <052.52e7057401d2ad1f63505ce020925e77@localhost>

#2030: GHC internal error: `m' is not in scope
----------------------+-----------------------------------------------------
 Reporter:  ToRA      |          Owner:                
     Type:  bug       |         Status:  new           
 Priority:  normal    |      Milestone:                
Component:  Compiler  |        Version:  6.8.2         
 Severity:  normal    |     Resolution:                
 Keywords:            |     Difficulty:  Unknown       
 Testcase:            |   Architecture:  x86_64 (amd64)
       Os:  Linux     |  
----------------------+-----------------------------------------------------
Changes (by ToRA):

  * version:  6.8.1 => 6.8.2

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/2030#comment:1>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Wed Jan  9 13:21:21 2008
From: trac at galois.com (GHC)
Date: Wed Jan  9 13:14:56 2008
Subject: [GHC] #2030: GHC internal error: `m' is not in scope
In-Reply-To: <043.1667a40fa37775839c3eb6215de0afe4@localhost>
References: <043.1667a40fa37775839c3eb6215de0afe4@localhost>
Message-ID: <052.360d5dd4f5dcf88546d40b319353d06c@localhost>

#2030: GHC internal error: `m' is not in scope
----------------------+-----------------------------------------------------
 Reporter:  ToRA      |          Owner:                
     Type:  bug       |         Status:  new           
 Priority:  normal    |      Milestone:                
Component:  Compiler  |        Version:  6.8.2         
 Severity:  normal    |     Resolution:                
 Keywords:            |     Difficulty:  Unknown       
 Testcase:            |   Architecture:  x86_64 (amd64)
       Os:  Linux     |  
----------------------+-----------------------------------------------------
Changes (by ToRA):

 * cc: tora@zonetora.co.uk (added)

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/2030#comment:2>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Wed Jan  9 13:37:43 2008
From: trac at galois.com (GHC)
Date: Wed Jan  9 13:31:18 2008
Subject: [GHC] #2030: GHC internal error: `m' is not in scope
In-Reply-To: <043.1667a40fa37775839c3eb6215de0afe4@localhost>
References: <043.1667a40fa37775839c3eb6215de0afe4@localhost>
Message-ID: <052.839abdac1e278ab37adbe299b2350aab@localhost>

#2030: GHC internal error: `m' is not in scope
-------------------------------------+--------------------------------------
 Reporter:  ToRA                     |          Owner:                
     Type:  bug                      |         Status:  new           
 Priority:  normal                   |      Milestone:                
Component:  Compiler (Type checker)  |        Version:  6.8.2         
 Severity:  normal                   |     Resolution:                
 Keywords:                           |     Difficulty:  Unknown       
 Testcase:                           |   Architecture:  x86_64 (amd64)
       Os:  Linux                    |  
-------------------------------------+--------------------------------------
Comment (by ToRA):

 Further information.

 6.6.1 will compile it. Also brings down 6.8.1

 >ghc-6.8.1 -v -c /tmp/Bug.hs
 Glasgow Haskell Compiler, Version 6.8.1, for Haskell 98, stage 2 booted by
 GHC version 6.6.1
 Using package config file: /home/tora/lib/ghc-6.8.1/package.conf
 hiding package X11-1.2.3.1 to avoid conflict with later version X11-1.4.0
 wired-in package base mapped to base-3.0.0.0
 wired-in package rts mapped to rts-1.0
 wired-in package haskell98 mapped to haskell98-1.0.1.0
 wired-in package template-haskell mapped to template-haskell-2.2.0.0
 wired-in package ndp not found.
 Hsc static flags: -static
 Created temporary directory: /tmp/ghc2997_0
 *** Checking old interface for main:Bug:
 *** Parser:
 *** Renamer/typechecker:

 /tmp/Bug.hs:36:24:
     GHC internal error: `m' is not in scope
     In the type `m Safety'
     In the type `Alt -> m Safety'
     In the type signature for `isSafeAlt':
       isSafeAlt :: Alt -> m Safety
 *** Deleting temp files:
 Deleting: /tmp/ghc2997_0/ghc2997_0.s
 Warning: deleting non-existent /tmp/ghc2997_0/ghc2997_0.s
 *** Deleting temp dirs:
 Deleting: /tmp/ghc2997_0

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/2030#comment:4>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Wed Jan  9 15:22:26 2008
From: trac at galois.com (GHC)
Date: Wed Jan  9 15:16:01 2008
Subject: [GHC] #2030: GHC internal error: `m' is not in scope
In-Reply-To: <043.1667a40fa37775839c3eb6215de0afe4@localhost>
References: <043.1667a40fa37775839c3eb6215de0afe4@localhost>
Message-ID: <052.9c813b79fbc63a3ecff962e228082b0f@localhost>

#2030: GHC internal error: `m' is not in scope
-------------------------------------+--------------------------------------
 Reporter:  ToRA                     |          Owner:                
     Type:  bug                      |         Status:  new           
 Priority:  normal                   |      Milestone:                
Component:  Compiler (Type checker)  |        Version:  6.8.2         
 Severity:  normal                   |     Resolution:                
 Keywords:                           |     Difficulty:  Unknown       
 Testcase:                           |   Architecture:  x86_64 (amd64)
       Os:  Linux                    |  
-------------------------------------+--------------------------------------
Comment (by ToRA):

 If you remove the type signature it compiles / loads fine in ghci 6.8.2

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/2030#comment:5>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Wed Jan  9 16:26:06 2008
From: trac at galois.com (GHC)
Date: Wed Jan  9 16:19:41 2008
Subject: [GHC] #2029: Add --with-libedit flag to the readline package
In-Reply-To: <044.f95d970cfe3a09acd95facdbee2dd79a@localhost>
References: <044.f95d970cfe3a09acd95facdbee2dd79a@localhost>
Message-ID: <053.d79b3c72b61dd1ab10c3318ad705f3f8@localhost>

#2029: Add --with-libedit flag to the readline package
-------------------------------+--------------------------------------------
 Reporter:  judah              |          Owner:          
     Type:  proposal           |         Status:  new     
 Priority:  normal             |      Milestone:  Not GHC 
Component:  libraries (other)  |        Version:          
 Severity:  normal             |     Resolution:          
 Keywords:                     |     Difficulty:  Unknown 
 Testcase:                     |   Architecture:  Multiple
       Os:  Multiple           |  
-------------------------------+--------------------------------------------
Comment (by thorkilnaur):

 I would suggest creating an entirely new Haskell library (which rightly
 should be called "edit", but a better name should probably be found) for
 such Haskell bindings to the BSD edit library on Mac OS X. Apple's idea of
 pretending that "edit" is "readline" has caused quite some significant
 confusion over the years. I would not expect a Haskell readline library
 which is perhaps really the BSD edit library to be any less confusing.

 For example, I may wish to work specifically with both the BSD edit
 library and the GNU readline library though some Haskell binding, to
 compare them. Such a case would be difficult to handle with a Haskell
 readline library which is either BSD edit or GNU readline.

 I am aware that this loses the potential advantage that BSD edit
 functionality will be present for free, rather than no line editing
 capabilities, in some cases, such as GHCi. But I am convinced that this
 advantage will be outweighed heavily by the ensuing work needed to deal
 with these confusing scenarios.

 Any helpful magic, similar to your suggestions, for automatically
 selecting between BSD edit and GNU readline must then be implemented
 separately, perhaps as a library in itself.

 Best regards
 Thorkil

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/2029#comment:1>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Wed Jan  9 16:34:20 2008
From: trac at galois.com (GHC)
Date: Wed Jan  9 16:27:57 2008
Subject: [GHC] #2013: ghci crash on startup: R_X86_64_32S relocation out
 of range.
In-Reply-To: <044.2f007075e8a3e652be5aa7c77056c714@localhost>
References: <044.2f007075e8a3e652be5aa7c77056c714@localhost>
Message-ID: <053.1cddfd18b6d2cc1b1641270d4857a092@localhost>

#2013: ghci crash on startup: R_X86_64_32S relocation out of range.
---------------------+------------------------------------------------------
 Reporter:  mboes    |          Owner:                
     Type:  bug      |         Status:  new           
 Priority:  normal   |      Milestone:  6.8.3         
Component:  GHCi     |        Version:  6.9           
 Severity:  normal   |     Resolution:                
 Keywords:           |     Difficulty:  Unknown       
 Testcase:           |   Architecture:  x86_64 (amd64)
       Os:  FreeBSD  |  
---------------------+------------------------------------------------------
Comment (by mboes):

 Hi,

 I have a short patch for this, attached. I have a rather slow connection
 at the moment and downloading the stable darcs branch is going to be
 taking a few days at this rate so the patch is a unified diff relative to
 6.8.2 release, rather than a darcs patch. Sorry about that!

 On my system ghci never seems to be loaded with anything allocated in the
 1-2GB segment. This patch makes ghci load all objects starting from 1GB
 growing upwards, one after the other. Loading will fail if there is
 anything in the way, but I haven't seen this to be a problem on my machine
 and besides linking happens very early in the lifetime of a ghci process.
 The jump islands for symbols in shared libs loaded in high mem are
 allocated starting from the 2GB mark, growing downwards. Let me know if
 you'd like to see any revisions to this patch.

 Regards,

 Mathieu

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/2013#comment:10>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Thu Jan 10 04:26:46 2008
From: trac at galois.com (GHC)
Date: Thu Jan 10 04:20:25 2008
Subject: [GHC] #2013: ghci crash on startup: R_X86_64_32S relocation out
 of range.
In-Reply-To: <044.2f007075e8a3e652be5aa7c77056c714@localhost>
References: <044.2f007075e8a3e652be5aa7c77056c714@localhost>
Message-ID: <053.90772918d07f7e22e71c2854ce2cd02b@localhost>

#2013: ghci crash on startup: R_X86_64_32S relocation out of range.
---------------------+------------------------------------------------------
 Reporter:  mboes    |          Owner:                
     Type:  bug      |         Status:  new           
 Priority:  normal   |      Milestone:  6.8.3         
Component:  GHCi     |        Version:  6.9           
 Severity:  normal   |     Resolution:                
 Keywords:           |     Difficulty:  Unknown       
 Testcase:           |   Architecture:  x86_64 (amd64)
       Os:  FreeBSD  |  
---------------------+------------------------------------------------------
Comment (by simonmar):

 Thanks for the patch!  I'll take a look.

 Your patch will apply to 6.8.3, but in HEAD the previously mentioned patch
 "add PIC relocations for x86_64" has been applied, and the
 `x86_64_high_symbol()` hack has been replaced by the `symbol_extras`
 stuff.  If you were able to port your changes to the HEAD too, that would
 be great.  Currently the HEAD will not compile at all on x86_64 non-Linux.

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/2013#comment:11>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Thu Jan 10 05:40:00 2008
From: trac at galois.com (GHC)
Date: Thu Jan 10 05:33:43 2008
Subject: [GHC] #2013: ghci crash on startup: R_X86_64_32S relocation out
 of range.
In-Reply-To: <044.2f007075e8a3e652be5aa7c77056c714@localhost>
References: <044.2f007075e8a3e652be5aa7c77056c714@localhost>
Message-ID: <053.470f7f41aca6e0b1c0634ec382c11e13@localhost>

#2013: ghci crash on startup: R_X86_64_32S relocation out of range.
---------------------+------------------------------------------------------
 Reporter:  mboes    |          Owner:                
     Type:  bug      |         Status:  new           
 Priority:  normal   |      Milestone:  6.8.3         
Component:  GHCi     |        Version:  6.9           
 Severity:  normal   |     Resolution:                
 Keywords:           |     Difficulty:  Unknown       
 Testcase:           |   Architecture:  x86_64 (amd64)
       Os:  FreeBSD  |  
---------------------+------------------------------------------------------
Comment (by wb.kloke):

 I can confirm that the patch is good for use for most of the testsuite
 with my system. I updated my FreeBSD-7.0-amd64 binary dist with the patch
 applied, and the testsuite output.

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/2013#comment:12>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Thu Jan 10 06:44:52 2008
From: trac at galois.com (GHC)
Date: Thu Jan 10 06:38:25 2008
Subject: [GHC] #2030: GHC internal error: `m' is not in scope
In-Reply-To: <043.1667a40fa37775839c3eb6215de0afe4@localhost>
References: <043.1667a40fa37775839c3eb6215de0afe4@localhost>
Message-ID: <052.d4d5855ecaf6ebe9483581a7d786f0cc@localhost>

#2030: GHC internal error: `m' is not in scope
-------------------------------------+--------------------------------------
 Reporter:  ToRA                     |          Owner:  igloo         
     Type:  merge                    |         Status:  new           
 Priority:  normal                   |      Milestone:                
Component:  Compiler (Type checker)  |        Version:  6.8.2         
 Severity:  normal                   |     Resolution:                
 Keywords:                           |     Difficulty:  Unknown       
 Testcase:  tc242                    |   Architecture:  x86_64 (amd64)
       Os:  Linux                    |  
-------------------------------------+--------------------------------------
Changes (by simonpj):

  * testcase:  => tc242
  * owner:  => igloo
  * type:  bug => merge

Comment:

 Thanks.  The bug turns out to be that `-XScopedTypeVariables` should imply
 `-XRelaxedPolyRec`. If you add the latter flag you will be fine. I'll push
 a patch and some tests.

 Simon

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/2030#comment:6>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Thu Jan 10 07:05:08 2008
From: trac at galois.com (GHC)
Date: Thu Jan 10 06:58:49 2008
Subject: [GHC] #2031: relocation overflow
Message-ID: <045.02b5c8981d759aa3391df46bf05998bf@localhost>

#2031: relocation overflow
-------------------------+--------------------------------------------------
    Reporter:  maeder    |       Owner:         
        Type:  bug       |      Status:  new    
    Priority:  normal    |   Milestone:         
   Component:  Compiler  |     Version:  6.8.2  
    Severity:  normal    |    Keywords:         
  Difficulty:  Unknown   |    Testcase:         
Architecture:  powerpc   |          Os:  MacOS X
-------------------------+--------------------------------------------------
 I've created a statically linked ghc-6.8.2 for PPC Mac OS 10.4 (Tiger).
 http://www.dfki.de/sks/hets/mac/versions/ghc-6.8.2-powerpc-apple-darwin-
 static-libs.tar.bz2

 When linking our big hets binary after compilation with optimization I get
 millions (actually 34999 lines) of entries like:

 {{{
 /usr/bin/ld: PGIP/XMLparsing.o relocation overflow for relocation entry 63
 in section (__TEXT,__text) (displacement too large)
 ...
 /usr/bin/ld: SoftFOL/Sign.o relocation overflow for relocation entry 45280
 in section (__TEXT,__text) (displacement too large)
 collect2: ld returned 1 exit status
 make: *** [hets] Error 1
 }}}

 I had such messages before and got rid of them by rearranging code and
 imports (just by wild guesses, a strategy would be helpful). It is sort of
 a known (Apple PPC) deficiency (and I misuse this ticket to document it
 here).

 Linking works fine after compilation without optimization or when linking
 against GMP and GNUreadline frameworks using my other binary distribution.

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/2031>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Thu Jan 10 09:33:28 2008
From: trac at galois.com (GHC)
Date: Thu Jan 10 09:27:02 2008
Subject: [GHC] #1990: Add 'subsequences' and 'permutations' to Data.List
In-Reply-To: <045.c48177dd9f9efccb66b7d13826a2ad45@localhost>
References: <045.c48177dd9f9efccb66b7d13826a2ad45@localhost>
Message-ID: <054.7eee3e681414b14889836822aeb45990@localhost>

#1990: Add 'subsequences' and 'permutations' to Data.List
----------------------------+-----------------------------------------------
 Reporter:  twanvl          |          Owner:             
     Type:  proposal        |         Status:  new        
 Priority:  high            |      Milestone:  6.10 branch
Component:  libraries/base  |        Version:  6.8.1      
 Severity:  normal          |     Resolution:             
 Keywords:                  |     Difficulty:  Easy (1 hr)
 Testcase:                  |   Architecture:  Unknown    
       Os:  Unknown         |  
----------------------------+-----------------------------------------------
Changes (by simonmar):

  * priority:  normal => high
  * difficulty:  Unknown => Easy (1 hr)
  * milestone:  Not GHC => 6.10 branch

Comment:

 Deadline has passed, there were no complaints, apply this patch for 6.10.

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/1990#comment:1>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Thu Jan 10 09:45:03 2008
From: trac at galois.com (GHC)
Date: Thu Jan 10 09:38:47 2008
Subject: [GHC] #2029: Add --with-libedit flag to the readline package
In-Reply-To: <044.f95d970cfe3a09acd95facdbee2dd79a@localhost>
References: <044.f95d970cfe3a09acd95facdbee2dd79a@localhost>
Message-ID: <053.ef58688235e765dbc3d0fc97f2547610@localhost>

#2029: Add --with-libedit flag to the readline package
-------------------------------+--------------------------------------------
 Reporter:  judah              |          Owner:          
     Type:  proposal           |         Status:  new     
 Priority:  normal             |      Milestone:  Not GHC 
Component:  libraries (other)  |        Version:          
 Severity:  normal             |     Resolution:          
 Keywords:                     |     Difficulty:  Unknown 
 Testcase:                     |   Architecture:  Multiple
       Os:  Multiple           |  
-------------------------------+--------------------------------------------
Changes (by maeder):

 * cc: Christian.Maeder@dfki.de (added)

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/2029#comment:2>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Thu Jan 10 09:47:52 2008
From: trac at galois.com (GHC)
Date: Thu Jan 10 09:41:24 2008
Subject: [GHC] #2028: STM slightly conservative on write-only
 transactions
In-Reply-To: <048.c06b21d8ef59b6cc153a10d02c678d4e@localhost>
References: <048.c06b21d8ef59b6cc153a10d02c678d4e@localhost>
Message-ID: <057.d5179c5fea4c1374a30e8fef92f02d5f@localhost>

#2028: STM slightly conservative on write-only transactions
-----------------------+----------------------------------------------------
 Reporter:  JulesBean  |          Owner:         
     Type:  proposal   |         Status:  new    
 Priority:  normal     |      Milestone:         
Component:  Compiler   |        Version:  6.8.1  
 Severity:  normal     |     Resolution:         
 Keywords:             |     Difficulty:  Unknown
 Testcase:             |   Architecture:  Unknown
       Os:  Unknown    |  
-----------------------+----------------------------------------------------
Comment (by simonpj):

 Comment from Tim Harris:

 This suggestion is OK from the point of view of correctness.

 There are several special cases where we could allow transactions to
 commit when we currently treat them as conflicting.  E.g. any single-word
 transaction is OK.

 I've avoided dealing with too many of these in the absence of code we care
 about performing badly (it'll add complexity and might slow down the
 hopefully-common case of non-conflicting transactions).

 No strong arguments against adding this one though: we could probably use
 a special value in the old-val field to indicate no-previous-value so we
 won't get a space code.  We could also handle it specially in "retry" --
 we don't need to watch for updates to a `TVar` that has been written to
 but not read.

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/2028#comment:1>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Thu Jan 10 11:31:02 2008
From: trac at galois.com (GHC)
Date: Thu Jan 10 11:24:34 2008
Subject: [GHC] #2032: SCC annotations cause compile errors
Message-ID: <045.a900c6fee154313666c3d914e62d7fd9@localhost>

#2032: SCC annotations cause compile errors
-------------------------+--------------------------------------------------
    Reporter:  m4dc4p    |       Owner:         
        Type:  bug       |      Status:  new    
    Priority:  normal    |   Milestone:         
   Component:  Compiler  |     Version:  6.8.2  
    Severity:  normal    |    Keywords:         
  Difficulty:  Unknown   |    Testcase:         
Architecture:  Unknown   |          Os:  Windows
-------------------------+--------------------------------------------------
 The following program will not compile:

   bad s = take 10 . {-# SCC "foo" #-} drop 10 $ s

 It fails with the message

 {{{
     Couldn't match expected type `a -> [a1]'
            against inferred type `[a2]'
     In the second argument of `(.)', namely `(drop 10 $ s)'
     In the expression: take 10 . (drop 10 $ s)
     In the definition of `bad': bad s = take 10 . (drop 10 $ s)
 }}}

 However, if the SCC annotation is removed it compiles:

   good s = take 10 . drop 10 $ s

 Adding parentheses can also fix it:

   good2 s = take 10 . ({-# SCC "foo" #-} drop 10) $ s

 but it's still annoying that adding an annotation can cause compilation to
 fail.

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/2032>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Thu Jan 10 11:57:04 2008
From: trac at galois.com (GHC)
Date: Thu Jan 10 11:50:38 2008
Subject: [GHC] #2032: SCC annotations cause compile errors
In-Reply-To: <045.a900c6fee154313666c3d914e62d7fd9@localhost>
References: <045.a900c6fee154313666c3d914e62d7fd9@localhost>
Message-ID: <054.d85d683d91e1d27b7f9c2abba6bedd14@localhost>

#2032: SCC annotations cause compile errors
----------------------+-----------------------------------------------------
 Reporter:  m4dc4p    |          Owner:         
     Type:  bug       |         Status:  new    
 Priority:  normal    |      Milestone:         
Component:  Compiler  |        Version:  6.8.2  
 Severity:  normal    |     Resolution:         
 Keywords:            |     Difficulty:  Unknown
 Testcase:            |   Architecture:  Unknown
       Os:  Windows   |  
----------------------+-----------------------------------------------------
Comment (by simonpj):

 Tricky.  Do you expect it to parse as:
 {{{
 take 10 . ({-# SCC "foo" #-} (drop 10 $ s)
 }}}
 (ie SCC binds less tightly than anything); or
 {{{
 take 10 . ({-# SCC "foo" #-} (drop 10)) $ s
 }}}
 (ie SCC binds more tightly than $ but less tightly than appilcation); or
 {{{
 take 10 . ({-# SCC "foo" #-} drop) 10 $ s
 }}}
 (ie SCC binds more tightly than anything, including application).

 You expected the middle case.  GHC is parsing it as the first case.  It
 isn't clear (to me) which of the three is "right".

 As usual, the way to avoid parsing ambiguities is to add parens.

 Simon

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/2032#comment:1>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Thu Jan 10 12:20:52 2008
From: trac at galois.com (GHC)
Date: Thu Jan 10 12:14:32 2008
Subject: [GHC] #2032: SCC annotations cause compile errors
In-Reply-To: <045.a900c6fee154313666c3d914e62d7fd9@localhost>
References: <045.a900c6fee154313666c3d914e62d7fd9@localhost>
Message-ID: <054.7bdd17b251425586d8f3f2fe9b26be92@localhost>

#2032: SCC annotations cause compile errors
----------------------+-----------------------------------------------------
 Reporter:  m4dc4p    |          Owner:         
     Type:  bug       |         Status:  new    
 Priority:  normal    |      Milestone:         
Component:  Compiler  |        Version:  6.8.2  
 Severity:  normal    |     Resolution:         
 Keywords:            |     Difficulty:  Unknown
 Testcase:            |   Architecture:  Unknown
       Os:  Windows   |  
----------------------+-----------------------------------------------------
Comment (by m4dc4p):

 I see what you are saying, but what I really expect is that SCC annotation
 don't affect parsing at all. I think of them the same way as comments.

 That is, I would expect {{{good1}}}, {{{good2}}} and {{{bad}}} to compile
 as is. Controlling the cost attributions for the annotation seems to be a
 separate issue, and something that is rightly solved by parentheses.

 p.s. That's really good to know that they bind less tightly than anything
 - I've always wondered.

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/2032#comment:2>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Thu Jan 10 12:26:29 2008
From: trac at galois.com (GHC)
Date: Thu Jan 10 12:20:01 2008
Subject: [GHC] #2028: STM slightly conservative on write-only
 transactions
In-Reply-To: <048.c06b21d8ef59b6cc153a10d02c678d4e@localhost>
References: <048.c06b21d8ef59b6cc153a10d02c678d4e@localhost>
Message-ID: <057.d3532dbd0812fc9a7284062e3f8e783e@localhost>

#2028: STM slightly conservative on write-only transactions
-----------------------+----------------------------------------------------
 Reporter:  JulesBean  |          Owner:         
     Type:  proposal   |         Status:  new    
 Priority:  normal     |      Milestone:         
Component:  Compiler   |        Version:  6.8.1  
 Severity:  normal     |     Resolution:         
 Keywords:             |     Difficulty:  Unknown
 Testcase:             |   Architecture:  Unknown
       Os:  Unknown    |  
-----------------------+----------------------------------------------------
Comment (by Isaac Dupree):

 Probably I don't completely understand STM, but... if these happen at the
 same time, won't we potentially end up with an inconsistent state if no-
 one retries?

 {{{
 atomically $ mapM (\tv -> writeTVar tv 0) [tv1,tv2,tv3,tv4]
 }}}
 {{{
 atomically $ mapM (\tv -> writeTVar tv 1) [tv4,tv3,tv2,tv1]
 }}}

 (and don't single-word transactions depend on the hardware/architecture as
 for whether they are atomic?)

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/2028#comment:2>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Thu Jan 10 12:36:51 2008
From: trac at galois.com (GHC)
Date: Thu Jan 10 12:30:24 2008
Subject: [GHC] #2028: STM slightly conservative on write-only
 transactions
In-Reply-To: <048.c06b21d8ef59b6cc153a10d02c678d4e@localhost>
References: <048.c06b21d8ef59b6cc153a10d02c678d4e@localhost>
Message-ID: <057.00cb404039d0e9af8d316ab7b8563f59@localhost>

#2028: STM slightly conservative on write-only transactions
-----------------------+----------------------------------------------------
 Reporter:  JulesBean  |          Owner:         
     Type:  proposal   |         Status:  new    
 Priority:  normal     |      Milestone:         
Component:  Compiler   |        Version:  6.8.1  
 Severity:  normal     |     Resolution:         
 Keywords:             |     Difficulty:  Unknown
 Testcase:             |   Architecture:  Unknown
       Os:  Unknown    |  
-----------------------+----------------------------------------------------
Comment (by JulesBean):

 No.

 One them has to commit first. When it commits, it sets all the entries to
 something (say, 1). At this point, the other one has made no visible
 changes (all its changes are private, in its transaction log). Then, the
 other one commits, and it sets them all to 0.

 Committing is atomic.

 In the current situation what would happen is the first would commit, and
 then the second would say "erk! something has changed!" and not commit.

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/2028#comment:3>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Thu Jan 10 12:39:47 2008
From: trac at galois.com (GHC)
Date: Thu Jan 10 12:33:22 2008
Subject: [GHC] #2032: SCC annotations cause compile errors
In-Reply-To: <045.a900c6fee154313666c3d914e62d7fd9@localhost>
References: <045.a900c6fee154313666c3d914e62d7fd9@localhost>
Message-ID: <054.7410c4d5548cd6b26bd5ed4418954808@localhost>

#2032: SCC annotations cause compile errors
----------------------+-----------------------------------------------------
 Reporter:  m4dc4p    |          Owner:         
     Type:  bug       |         Status:  new    
 Priority:  normal    |      Milestone:         
Component:  Compiler  |        Version:  6.8.2  
 Severity:  normal    |     Resolution:         
 Keywords:            |     Difficulty:  Unknown
 Testcase:            |   Architecture:  Unknown
       Os:  Windows   |  
----------------------+-----------------------------------------------------
Comment (by Isaac Dupree):

 IMHO expression-pragmas should have a standard precedence that people will
 know what it is... I would tend towards "function application"
 {{{
 take 10 . {-# SCC "foo" #-} drop 10 $ s
 }}}
 becomes
 {{{
 take 10 . ({-# SCC "foo" #-} drop) 10 $ s
 }}}
 but
 {{{
 take 10 . drop {-# SCC "foo" #-} 10 $ s
 }}}
 becomes
 {{{
 take 10 . (drop {-# SCC "foo" #-}) 10 $ s
 }}}
 which is an error of course.  (except that pragmas shouldn't produce fatal
 errors, so it should be a warning. Isn't that how pragmas are supposed to
 work? Otherwise things tend to break between different compilers, e.g. I
 heard rumors about INLINE in `hbc`)

 Anyway with "function application" precedence it's just like the GHC-
 specific "inline"
 {{{
 take 10 . inline drop 10 $ s
 }}}
 ... why isn't it a pragma too? such as
 {{{
 take 10 . {-# INLINE #-} drop 10 $ s
 }}}

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/2032#comment:3>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Thu Jan 10 13:08:31 2008
From: trac at galois.com (GHC)
Date: Thu Jan 10 13:02:08 2008
Subject: [GHC] #1997: Stricter enumFrom instance for Integer,
 to match Int
In-Reply-To: <043.bda0d5ecfd811d8fda5e74a0019c2fae@localhost>
References: <043.bda0d5ecfd811d8fda5e74a0019c2fae@localhost>
Message-ID: <052.70599834e71185ec7db680a5c5fccff6@localhost>

#1997: Stricter enumFrom instance for Integer, to match Int
-----------------------------------+----------------------------------------
 Reporter:  dons                   |          Owner:             
     Type:  bug                    |         Status:  new        
 Priority:  normal                 |      Milestone:  6.10 branch
Component:  libraries/base         |        Version:  6.8.2      
 Severity:  normal                 |     Resolution:             
 Keywords:                         |     Difficulty:  Easy (1 hr)
 Testcase:  lib/should_run/enum04  |   Architecture:  Multiple   
       Os:  Multiple               |  
-----------------------------------+----------------------------------------
Comment (by dons):

 Similary, there are other list functions on numeric types that should be
 strict in the
 accumulator:

 {{{
 Prelude> sum [1..1000000]
 *** Exception: stack overflow
 }}}

 maximum/minimum have rules for this:

 {{{
   "maximumInt"     maximum = (strictMaximum :: [Int]     -> Int);
   "maximumInteger" maximum = (strictMaximum :: [Integer] -> Integer)
 }}}

 and 'sum' works with -O, but none of them work in GHCi -- it would be good
 if
 this could be made more robust.

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/1997#comment:5>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Fri Jan 11 04:08:37 2008
From: trac at galois.com (GHC)
Date: Fri Jan 11 04:02:09 2008
Subject: [GHC] #2032: SCC annotations cause compile errors
In-Reply-To: <045.a900c6fee154313666c3d914e62d7fd9@localhost>
References: <045.a900c6fee154313666c3d914e62d7fd9@localhost>
Message-ID: <054.c0bd71438f6f6619b7b752ee9a057d9d@localhost>

#2032: SCC annotations cause compile errors
----------------------+-----------------------------------------------------
 Reporter:  m4dc4p    |          Owner:         
     Type:  bug       |         Status:  closed 
 Priority:  normal    |      Milestone:         
Component:  Compiler  |        Version:  6.8.2  
 Severity:  normal    |     Resolution:  wontfix
 Keywords:            |     Difficulty:  Unknown
 Testcase:            |   Architecture:  Unknown
       Os:  Windows   |  
----------------------+-----------------------------------------------------
Changes (by simonmar):

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

Comment:

 Function application precedence would be inconvenient: usually you want
 SCC to extend "as far to the right as possible".  So right now SCC parses
 in the same way as `\x -> e`, that is is gobbles up as much `e` as it can.
 I think this makes sense for SCC, and I don't buy the argument that an SCC
 annotation should not affect the parse: pragmas that the compiler
 understands are part of the syntax.  Pragmas that the compiler does not
 understand are treated as comments, as they should be.

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/2032#comment:4>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Fri Jan 11 14:10:26 2008
From: trac at galois.com (GHC)
Date: Fri Jan 11 14:04:01 2008
Subject: [GHC] #2033: GHC-6.9 panics rather than parse error,
 related to view patterns.
Message-ID: <047.52dd94d8901a2e429a6ec81181a5f477@localhost>

#2033: GHC-6.9 panics rather than parse error, related to view patterns.
-------------------------+--------------------------------------------------
    Reporter:  apeacock  |       Owner:         
        Type:  bug       |      Status:  new    
    Priority:  normal    |   Milestone:         
   Component:  Compiler  |     Version:  6.9    
    Severity:  normal    |    Keywords:         
  Difficulty:  Unknown   |    Testcase:         
Architecture:  x86       |          Os:  Windows
-------------------------+--------------------------------------------------
 Try to compile the below program, ghc panics rather than giving a parse
 error (in the program I was trying to write, wrapper's argument should be
 a lambda function).

 main = do
   wrapper (_ -> putStrLn "_")

 wrapper :: (String -> IO ()) -> IO ()
 wrapper f = f ""

 Output:

 [1 of 1] Compiling Main             ( Test.hs, interpreted )
 : panic! (the 'impossible' happened)
   (GHC version 6.9.20071111 for i386-unknown-mingw32):
         rnExpr: unexpected expression: panic! (the 'impossible' happened)
   (GHC version 6.9.20071111 for i386-unknown-mingw32):
         hsSyn/HsExpr.lhs:(320,0)-(467,72): Non-exhaustive patterns in
 functi
 pr_expr

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/2033>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Fri Jan 11 14:13:05 2008
From: trac at galois.com (GHC)
Date: Fri Jan 11 14:06:38 2008
Subject: [GHC] #2033: GHC-6.9 panics rather than parse error,
 related to view patterns.
In-Reply-To: <047.52dd94d8901a2e429a6ec81181a5f477@localhost>
References: <047.52dd94d8901a2e429a6ec81181a5f477@localhost>
Message-ID: <056.3d52a3c04ef1a80d554fbbd5cec64219@localhost>

#2033: GHC-6.9 panics rather than parse error, related to view patterns.
----------------------+-----------------------------------------------------
 Reporter:  apeacock  |          Owner:         
     Type:  bug       |         Status:  new    
 Priority:  normal    |      Milestone:         
Component:  Compiler  |        Version:  6.9    
 Severity:  normal    |     Resolution:         
 Keywords:            |     Difficulty:  Unknown
 Testcase:            |   Architecture:  x86    
       Os:  Windows   |  
----------------------+-----------------------------------------------------
Comment (by apeacock):

 Sorry, hit submit rather than preview, here is the code again:
 {{{
 main = do
     wrapper (_ -> putStrLn "_")

 wrapper :: (String -> IO ()) -> IO ()
 wrapper f = f ""
 }}}
 Output

 {{{
 [1 of 1] Compiling Main             ( Test.hs, interpreted )
 : panic! (the 'impossible' happened)
   (GHC version 6.9.20071111 for i386-unknown-mingw32):
         rnExpr: unexpected expression: panic! (the 'impossible' happened)
   (GHC version 6.9.20071111 for i386-unknown-mingw32):
         hsSyn/HsExpr.lhs:(320,0)-(467,72): Non-exhaustive patterns in
 functi
 pr_expr
 }}}

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/2033#comment:1>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Sat Jan 12 08:01:13 2008
From: trac at galois.com (GHC)
Date: Sat Jan 12 07:54:45 2008
Subject: [GHC] #1349: Generalise the ! and UNPACK mechanism for data
 types, to unpack function arguments
In-Reply-To: <046.9dd17815048ce25749ab5bff260d2925@localhost>
References: <046.9dd17815048ce25749ab5bff260d2925@localhost>
Message-ID: <055.b87c42ea50ce587e6cb8e16034f0fd51@localhost>

#1349: Generalise the ! and UNPACK mechanism for data types, to unpack function
arguments
----------------------+-----------------------------------------------------
 Reporter:  simonpj   |          Owner:             
     Type:  task      |         Status:  new        
 Priority:  normal    |      Milestone:  6.10 branch
Component:  Compiler  |        Version:  6.6.1      
 Severity:  normal    |     Resolution:             
 Keywords:            |     Difficulty:  Unknown    
 Testcase:            |   Architecture:  Unknown    
       Os:  Unknown   |  
----------------------+-----------------------------------------------------
Comment (by Isaac Dupree):

 Replying to [comment:5 duncan]:
 > This feature request is not about distinguishing strictness in types as
 the above would indicate. It's about changing the strictness and data
 representation of data type constructors that have higher order
 components.

 I don't know what this feature request is "about". But I'll note that some
 people do want strictness in types other than data declarations, for
 example, http://article.gmane.org/gmane.comp.lang.haskell.cafe/34857

 also my comment about GADT syntax is #1768

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/1349#comment:6>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Sat Jan 12 11:08:08 2008
From: trac at galois.com (GHC)
Date: Sat Jan 12 11:01:35 2008
Subject: [GHC] #2027: ghc -e sometimes spills control characters into
 its output
In-Reply-To: <044.17b329c7bf8a300b55ac85b04d1b0204@localhost>
References: <044.17b329c7bf8a300b55ac85b04d1b0204@localhost>
Message-ID: <053.40b93fd8febb2349023ea0a27169089a@localhost>

#2027: ghc -e  sometimes spills control characters into its output
--------------------+-------------------------------------------------------
 Reporter:  int-e   |          Owner:  igloo      
     Type:  bug     |         Status:  new        
 Priority:  normal  |      Milestone:  6.8.3      
Component:  GHCi    |        Version:  6.8.2      
 Severity:  minor   |     Resolution:             
 Keywords:          |     Difficulty:  Easy (1 hr)
 Testcase:          |   Architecture:  Unknown    
       Os:  Linux   |  
--------------------+-------------------------------------------------------
Changes (by igloo):

  * owner:  => igloo
  * milestone:  => 6.8.3

Comment:

 Testsuite tests shouldn't be failing as we do
 {{{
 os.environ['TERM'] = 'vt100'
 }}}
 in `driver/runtests.py`.

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/2027#comment:3>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Sat Jan 12 12:07:48 2008
From: trac at galois.com (GHC)
Date: Sat Jan 12 12:01:23 2008
Subject: [GHC] #2021: let ghc find framework header files and link with
 frameworks located in $HOME/Library/Frameworks
In-Reply-To: <045.f644abcffe54149a52e1b357b6ba7b01@localhost>
References: <045.f644abcffe54149a52e1b357b6ba7b01@localhost>
Message-ID: <054.2ada0531f25d849e3c0359e86405f5d1@localhost>

#2021: let ghc find framework header files and link with frameworks located in
$HOME/Library/Frameworks
-----------------------------+----------------------------------------------
 Reporter:  maeder           |          Owner:             
     Type:  feature request  |         Status:  new        
 Priority:  normal           |      Milestone:  6.10 branch
Component:  Compiler         |        Version:  6.8.2      
 Severity:  normal           |     Resolution:             
 Keywords:                   |     Difficulty:  Easy (1 hr)
 Testcase:                   |   Architecture:  Multiple   
       Os:  MacOS X          |  
-----------------------------+----------------------------------------------
Changes (by igloo):

  * milestone:  => 6.10 branch

Comment:

 I'll put this in the 6.10 milestone for now; please shout if you think
 something should be done for 6.8.3.

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/2021#comment:4>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Sat Jan 12 12:14:16 2008
From: trac at galois.com (GHC)
Date: Sat Jan 12 12:07:41 2008
Subject: [GHC] #1996: Make "swap" a top-level function
In-Reply-To: <044.463e61047525d45b6d6387091eebf88f@localhost>
References: <044.463e61047525d45b6d6387091eebf88f@localhost>
Message-ID: <053.35d7dae56e8280be04b24a45e3e1d95c@localhost>

#1996: Make "swap" a top-level function
-----------------------------+----------------------------------------------
 Reporter:  guest            |          Owner:         
     Type:  feature request  |         Status:  closed 
 Priority:  normal           |      Milestone:         
Component:  Compiler         |        Version:  6.8.2  
 Severity:  normal           |     Resolution:  wontfix
 Keywords:                   |     Difficulty:  Unknown
 Testcase:                   |   Architecture:  Unknown
       Os:  Unknown          |  
-----------------------------+----------------------------------------------
Changes (by igloo):

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

Comment:

 Please follow http://www.haskell.org/haskellwiki/Library_submissions if
 you would like to propose this.


 Thanks

 Ian

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/1996#comment:2>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Sat Jan 12 12:22:26 2008
From: trac at galois.com (GHC)
Date: Sat Jan 12 12:15:55 2008
Subject: [GHC] #2033: GHC-6.9 panics rather than parse error,
 related to view patterns.
In-Reply-To: <047.52dd94d8901a2e429a6ec81181a5f477@localhost>
References: <047.52dd94d8901a2e429a6ec81181a5f477@localhost>
Message-ID: <056.616a74df4add2fe5291e382a6a2bbfa5@localhost>

#2033: GHC-6.9 panics rather than parse error, related to view patterns.
----------------------+-----------------------------------------------------
 Reporter:  apeacock  |          Owner:  igloo  
     Type:  bug       |         Status:  new    
 Priority:  normal    |      Milestone:         
Component:  Compiler  |        Version:  6.9    
 Severity:  normal    |     Resolution:         
 Keywords:            |     Difficulty:  Unknown
 Testcase:            |   Architecture:  x86    
       Os:  Windows   |  
----------------------+-----------------------------------------------------
Changes (by igloo):

  * owner:  => igloo

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/2033#comment:2>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Sat Jan 12 12:37:18 2008
From: trac at galois.com (GHC)
Date: Sat Jan 12 12:30:45 2008
Subject: [GHC] #2034: In FilePath, current directory should be ".", not ""
Message-ID: <044.ce5a2afddc700a95979f00cd58ea4c17@localhost>

#2034: In FilePath, current directory should be ".", not ""
----------------------------------+-----------------------------------------
    Reporter:  igloo              |       Owner:  neil       
        Type:  bug                |      Status:  new        
    Priority:  normal             |   Milestone:  6.10 branch
   Component:  libraries (other)  |     Version:  6.8.1      
    Severity:  normal             |    Keywords:             
  Difficulty:  Unknown            |    Testcase:             
Architecture:  Unknown            |          Os:  Unknown    
----------------------------------+-----------------------------------------
 !FilePath's "current directory" should be ".", not "". This affects a
 number of commands, e.g.
 {{{
 normalise "."       should be "."         not ""
 "." </> "foo"       should be "foo"       not "./foo"
 splitFileName "foo" should be (".","foo") not ("","foo")
 }}}
 Some discussion is in this thread:
 http://www.haskell.org/pipermail/libraries/2007-December/008743.html

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/2034>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Sat Jan 12 14:01:06 2008
From: trac at galois.com (GHC)
Date: Sat Jan 12 13:54:43 2008
Subject: [GHC] #2035: New version of getModificationTime
Message-ID: <047.0169c6cb10468bb00ce33015893eb084@localhost>

#2035: New version of getModificationTime
------------------------------------+---------------------------------------
    Reporter:  felixmar             |       Owner:         
        Type:  proposal             |      Status:  new    
    Priority:  normal               |   Milestone:         
   Component:  libraries/directory  |     Version:         
    Severity:  normal               |    Keywords:         
  Difficulty:  Unknown              |    Testcase:         
Architecture:  Unknown              |          Os:  Unknown
------------------------------------+---------------------------------------
 Function getModificationTime in System.Directory returns ClockTime.
 ClockTime is part of the old-time package. The (new) time package has
 UTCTime, so i propose a new version of getModificationTime that
 returns UTCTime instead.

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/2035>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Sat Jan 12 14:02:31 2008
From: trac at galois.com (GHC)
Date: Sat Jan 12 13:55:59 2008
Subject: [GHC] #2035: New version of getModificationTime
In-Reply-To: <047.0169c6cb10468bb00ce33015893eb084@localhost>
References: <047.0169c6cb10468bb00ce33015893eb084@localhost>
Message-ID: <056.85f004f746907804ca85cd40e24c74c9@localhost>

#2035: New version of getModificationTime
---------------------------------+------------------------------------------
 Reporter:  felixmar             |          Owner:         
     Type:  proposal             |         Status:  new    
 Priority:  normal               |      Milestone:         
Component:  libraries/directory  |        Version:         
 Severity:  normal               |     Resolution:         
 Keywords:                       |     Difficulty:  Unknown
 Testcase:                       |   Architecture:  Unknown
       Os:  Unknown              |  
---------------------------------+------------------------------------------
Comment (by felixmar):

 Mailing list discussion:
 http://article.gmane.org/gmane.comp.lang.haskell.libraries/8251

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/2035#comment:1>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Sat Jan 12 15:06:09 2008
From: trac at galois.com (GHC)
Date: Sat Jan 12 14:59:37 2008
Subject: [GHC] #1012: ghc panic with mutually recursive modules and
 template haskell
In-Reply-To: <044.e3ec0fd0938800cc6a7ce608eb8687c2@localhost>
References: <044.e3ec0fd0938800cc6a7ce608eb8687c2@localhost>
Message-ID: <053.d738317fe03e3fa4bcd683d66a6f1e36@localhost>

#1012: ghc panic with mutually recursive modules and template haskell
------------------------------+---------------------------------------------
 Reporter:  guest             |          Owner:          
     Type:  bug               |         Status:  reopened
 Priority:  normal            |      Milestone:  _|_     
Component:  Template Haskell  |        Version:  6.8.2   
 Severity:  normal            |     Resolution:          
 Keywords:                    |     Difficulty:  Unknown 
 Testcase:  TH_import_loop    |   Architecture:  Multiple
       Os:  Multiple          |  
------------------------------+---------------------------------------------
Changes (by igloo):

  * status:  closed => reopened
  * resolution:  fixed =>
  * milestone:  6.8 branch => _|_

Comment:

 I agree that it is still a bug, but I've put it back in the _|_ milestone
 as it's easy to work-around, and I assume that if it was trivial to fix
 then SPJ would have done so.

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/1012#comment:13>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Sat Jan 12 15:41:22 2008
From: trac at galois.com (GHC)
Date: Sat Jan 12 15:34:54 2008
Subject: [GHC] #2033: GHC-6.9 panics rather than parse error,
 related to view patterns.
In-Reply-To: <047.52dd94d8901a2e429a6ec81181a5f477@localhost>
References: <047.52dd94d8901a2e429a6ec81181a5f477@localhost>
Message-ID: <056.0ebf0d8854f51d2c9c2404773a2456e7@localhost>

#2033: GHC-6.9 panics rather than parse error, related to view patterns.
----------------------+-----------------------------------------------------
 Reporter:  apeacock  |          Owner:             
     Type:  bug       |         Status:  new        
 Priority:  normal    |      Milestone:  6.10 branch
Component:  Compiler  |        Version:  6.9        
 Severity:  normal    |     Resolution:             
 Keywords:            |     Difficulty:  Unknown    
 Testcase:            |   Architecture:  x86        
       Os:  Windows   |  
----------------------+-----------------------------------------------------
Changes (by igloo):

  * owner:  igloo =>
  * milestone:  => 6.10 branch

Comment:

 I've fixed half of this, so now we get:
 {{{
 ghc-6.9.20080112: panic! (the 'impossible' happened)
   (GHC version 6.9.20080112 for x86_64-unknown-linux):
    rnExpr: unexpected expression _ -> putStrLn{v} "_"
 }}}

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/2033#comment:3>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Sat Jan 12 16:05:54 2008
From: trac at galois.com (GHC)
Date: Sat Jan 12 15:59:33 2008
Subject: [GHC] #2036: Show for Double and Float doesn't use parenthesis for
 negative zero.
Message-ID: <047.9085fb42c7e7997d5332318ebe9470cc@localhost>

#2036: Show for Double and Float doesn't use parenthesis for negative zero.
-------------------------+--------------------------------------------------
    Reporter:  clanehin  |       Owner:                     
        Type:  bug       |      Status:  new                
    Priority:  normal    |   Component:  libraries/haskell98
     Version:  6.6.1     |    Severity:  minor              
    Keywords:            |    Testcase:                     
Architecture:  Multiple  |          Os:  Multiple           
-------------------------+--------------------------------------------------
 For any other negative number, show would use parenthesis.  This is
 visually disconcerting, and prevents the expression from being pasted back
 into ghci.

 {{{
 Prelude> Just (-0/1)
 Just -0.0
 }}}

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/2036>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Sat Jan 12 16:10:26 2008
From: trac at galois.com (GHC)
Date: Sat Jan 12 16:04:03 2008
Subject: [GHC] #2029: Add --with-libedit flag to the readline package
In-Reply-To: <044.f95d970cfe3a09acd95facdbee2dd79a@localhost>
References: <044.f95d970cfe3a09acd95facdbee2dd79a@localhost>
Message-ID: <053.da90066d00ae6f79594e820647352bff@localhost>

#2029: Add --with-libedit flag to the readline package
-------------------------------+--------------------------------------------
 Reporter:  judah              |          Owner:          
     Type:  proposal           |         Status:  closed  
 Priority:  normal             |      Milestone:  Not GHC 
Component:  libraries (other)  |        Version:          
 Severity:  normal             |     Resolution:  wontfix 
 Keywords:                     |     Difficulty:  Unknown 
 Testcase:                     |   Architecture:  Multiple
       Os:  Multiple           |  
-------------------------------+--------------------------------------------
Changes (by judah):

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

Comment:

 The consensus on the libraries list is that (as Thorkil says) it would be
 much better make a new package, `editline`, which would provide the
 readline APIs as a separate module.

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/2029#comment:3>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Sat Jan 12 17:07:37 2008
From: trac at galois.com (GHC)
Date: Sat Jan 12 17:01:05 2008
Subject: [GHC] #2037: Inner type declaration causes GHC panic
Message-ID: <049.24463fdf4b22ae6ae336fa57c94ec082@localhost>

#2037: Inner type declaration causes GHC panic
---------------------------+------------------------------------------------
    Reporter:  basvandijk  |       Owner:                         
        Type:  bug         |      Status:  new                    
    Priority:  normal      |   Component:  Compiler (Type checker)
     Version:  6.8.2       |    Severity:  blocker                
    Keywords:              |    Testcase:                         
Architecture:  x86         |          Os:  Linux                  
---------------------------+------------------------------------------------
 I get a GHC panic when compiling the attached module.

 Sorry for the big module but I wasn't able to isolate this to a single
 simple function.

 If I comment the ''inner'' type of 'unify' on line 112 the module compiles
 just fine. So it probably has to do with
 [http://www.haskell.org/ghc/docs/latest/html/users_guide/other-type-
 extensions.html#scoped-type-variables lexically-scoped type variables].

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/2037>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Sat Jan 12 17:12:17 2008
From: trac at galois.com (GHC)
Date: Sat Jan 12 17:05:44 2008
Subject: [GHC] #2037: Inner type declaration causes GHC panic
In-Reply-To: <049.24463fdf4b22ae6ae336fa57c94ec082@localhost>
References: <049.24463fdf4b22ae6ae336fa57c94ec082@localhost>
Message-ID: <058.98adc4f1196d708687c6aa30f6615801@localhost>

#2037: Inner type declaration causes GHC panic
----------------------------------------+-----------------------------------
    Reporter:  basvandijk               |        Owner:       
        Type:  bug                      |       Status:  new  
    Priority:  normal                   |    Milestone:       
   Component:  Compiler (Type checker)  |      Version:  6.8.2
    Severity:  blocker                  |   Resolution:       
    Keywords:                           |     Testcase:       
Architecture:  x86                      |           Os:  Linux
----------------------------------------+-----------------------------------
Changes (by basvandijk):

 * cc: v.dijk.bas@gmail.com (added)

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/2037#comment:1>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Sat Jan 12 17:23:05 2008
From: trac at galois.com (GHC)
Date: Sat Jan 12 17:16:31 2008
Subject: [GHC] #2009: --with-gmp-includes not honoured everywhere
In-Reply-To: <043.9d6531f8ee8ae49a921eb477aa624802@localhost>
References: <043.9d6531f8ee8ae49a921eb477aa624802@localhost>
Message-ID: <052.68c69ca36f61fb75396751ef9211bc18@localhost>

#2009: --with-gmp-includes not honoured everywhere
--------------------------+-------------------------------------------------
 Reporter:  kili          |          Owner:  igloo      
     Type:  bug           |         Status:  new        
 Priority:  normal        |      Milestone:  6.8.3      
Component:  Build System  |        Version:  6.8.2      
 Severity:  normal        |     Resolution:             
 Keywords:                |     Difficulty:  Easy (1 hr)
 Testcase:                |   Architecture:  Multiple   
       Os:  OpenBSD       |  
--------------------------+-------------------------------------------------
Changes (by igloo):

  * owner:  => igloo

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/2009#comment:2>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Sat Jan 12 17:26:00 2008
From: trac at galois.com (GHC)
Date: Sat Jan 12 17:19:28 2008
Subject: [GHC] #2037: Inner type declaration causes GHC panic
In-Reply-To: <049.24463fdf4b22ae6ae336fa57c94ec082@localhost>
References: <049.24463fdf4b22ae6ae336fa57c94ec082@localhost>
Message-ID: <058.7970e0ca287ac7283abadac2c4b42168@localhost>

#2037: Inner type declaration causes GHC panic
----------------------------------------+-----------------------------------
    Reporter:  basvandijk               |        Owner:       
        Type:  bug                      |       Status:  new  
    Priority:  normal                   |    Milestone:       
   Component:  Compiler (Type checker)  |      Version:  6.8.2
    Severity:  blocker                  |   Resolution:       
    Keywords:                           |     Testcase:       
Architecture:  x86                      |           Os:  Linux
----------------------------------------+-----------------------------------
Comment (by basvandijk):

 I just discovered a bug in my module:

 All the applications of 'union' in 'unify' have to be replaced by
 'unionWithKey f' like so:
 {{{
 unify :: k ->  Value k a -> Value k a -> Value k a
 unify x (NoValue   dl)      (NoValue dr)      = NoValue(unionWithKey f dl
 dr)
 unify x (NoValue   dl)      (AValue (dr, yr)) = AValue (unionWithKey f dl
 dr, yr)
 unify x (AValue   (dl, yl)) (NoValue dr)      = AValue (unionWithKey f dl
 dr, yl)
 unify x (AValue   (dl, yl)) (AValue (dr, yr)) = AValue (unionWithKey f dl
 dr, f x yl yr)
 }}}
 The interesting thing is that with this the module compiles just fine!

 Of course the orginal bug is still a bug. It probably has something to do
 with the interaction between the explicit type of 'unify' and the type of
 'union'. It also doesn't matter if I add a 'forall k a' to 'union'.

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/2037#comment:2>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Sat Jan 12 19:03:18 2008
From: trac at galois.com (GHC)
Date: Sat Jan 12 18:56:43 2008
Subject: [GHC] #2009: --with-gmp-includes not honoured everywhere
In-Reply-To: <043.9d6531f8ee8ae49a921eb477aa624802@localhost>
References: <043.9d6531f8ee8ae49a921eb477aa624802@localhost>
Message-ID: <052.c292a6b5132dea180c930d9ee186c689@localhost>

#2009: --with-gmp-includes not honoured everywhere
--------------------------+-------------------------------------------------
 Reporter:  kili          |          Owner:  igloo      
     Type:  merge         |         Status:  new        
 Priority:  normal        |      Milestone:  6.8.3      
Component:  Build System  |        Version:  6.8.2      
 Severity:  normal        |     Resolution:             
 Keywords:                |     Difficulty:  Easy (1 hr)
 Testcase:                |   Architecture:  Multiple   
       Os:  OpenBSD       |  
--------------------------+-------------------------------------------------
Changes (by igloo):

  * type:  bug => merge

Comment:

 Thanks for the patch! I've applied a slightly modified version to the
 HEAD:
 {{{
 Sat Jan 12 23:42:15 GMT 2008  Ian Lynagh <igloo@earth.li>
   * Add GMP_INCLUDE_DIRS in a couple of places
   Fixes the build on OpenBSD (trac #2009). Based on a patch from kili.
 }}}
 but it still needs merging to the 6.8 branch.

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/2009#comment:3>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Sat Jan 12 20:18:56 2008
From: trac at galois.com (GHC)
Date: Sat Jan 12 20:12:21 2008
Subject: [GHC] #2037: Inner type declaration causes GHC panic
In-Reply-To: <049.24463fdf4b22ae6ae336fa57c94ec082@localhost>
References: <049.24463fdf4b22ae6ae336fa57c94ec082@localhost>
Message-ID: <058.743e7cdbe401d66ce914d76cd6043b48@localhost>

#2037: Inner type declaration causes GHC panic
-------------------------------------+--------------------------------------
 Reporter:  basvandijk               |          Owner:           
     Type:  bug                      |         Status:  closed   
 Priority:  normal                   |      Milestone:           
Component:  Compiler (Type checker)  |        Version:  6.8.2    
 Severity:  blocker                  |     Resolution:  duplicate
 Keywords:                           |     Difficulty:  Unknown  
 Testcase:                           |   Architecture:  x86      
       Os:  Linux                    |  
-------------------------------------+--------------------------------------
Changes (by igloo):

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

Comment:

 Thanks for the report. This looks like a duplicate of #2030 to me. If you
 also use `-XRelaxedPolyRec` then the module is accepted, and the HEAD
 accepts it as-is.

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/2037#comment:3>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Sun Jan 13 07:01:22 2008
From: trac at galois.com (GHC)
Date: Sun Jan 13 06:54:47 2008
Subject: [GHC] #2034: In FilePath, current directory should be ".",
 not ""
In-Reply-To: <044.ce5a2afddc700a95979f00cd58ea4c17@localhost>
References: <044.ce5a2afddc700a95979f00cd58ea4c17@localhost>
Message-ID: <053.6ea392ef56cb2e02862fd5306ad37ae9@localhost>

#2034: In FilePath, current directory should be ".", not ""
-------------------------------+--------------------------------------------
 Reporter:  igloo              |          Owner:  neil       
     Type:  bug                |         Status:  new        
 Priority:  normal             |      Milestone:  6.10 branch
Component:  libraries (other)  |        Version:  6.8.1      
 Severity:  normal             |     Resolution:             
 Keywords:                     |     Difficulty:  Unknown    
 Testcase:                     |   Architecture:  Unknown    
       Os:  Unknown            |  
-------------------------------+--------------------------------------------
Comment (by NeilMitchell):

 I will tackle this later today.

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/2034#comment:1>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Sun Jan 13 09:07:35 2008
From: trac at galois.com (GHC)
Date: Sun Jan 13 09:00:59 2008
Subject: [GHC] #2038: System.Posix.Resource.setResourceLimit gives
 "setResourceLimit: invalid argument (Invalid argument)"
Message-ID: <045.9f2f177f681138fbf7d90d1273238fd5@localhost>

#2038: System.Posix.Resource.setResourceLimit gives "setResourceLimit: invalid
argument (Invalid argument)"
--------------------------------------+-------------------------------------
    Reporter:  slyfox                 |       Owner:          
        Type:  bug                    |      Status:  new     
    Priority:  normal                 |   Component:  Compiler
     Version:  6.8.1                  |    Severity:  major   
    Keywords:  regression, ffi, unix  |    Testcase:          
Architecture:  x86                    |          Os:  Linux   
--------------------------------------+-------------------------------------
 GHC-6.6.1 worked correctly in setResourceLimit,
 GHC-6.8.2 gives me an error:
 {{{
 $ ./m
 m: setResourceLimit: invalid argument (Invalid argument)
 }}}
 A little exploration (strange rlim_max value). Seems to be a bug
 in haskell -> C type conversion.
 {{{
 $ strace -etrace=setrlimit ./m
 setrlimit(RLIMIT_CPU, {rlim_cur=3, rlim_max=0}) = -1 EINVAL (Invalid
 argument)
 m: setResourceLimit: invalid argument (Invalid argument)
 }}}
 Code source:
 {{{
 import System.Exit              (exitWith, ExitCode(ExitSuccess))
 import System.IO                (putStrLn)
 import System.Posix.Resource

 rlimit = ResourceLimit 3

 f = do
     putStrLn "whoooooo"
     f
 main = do
     setResourceLimit ResourceCPUTime (ResourceLimits rlimit rlimit)
     r <- getResourceLimit ResourceCPUTime
     let (ResourceLimit s) = softLimit r
     let (ResourceLimit h) = hardLimit r
     putStrLn $ show s
     putStrLn $ show h
     f
     exitWith ExitSuccess
 }}}

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/2038>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Sun Jan 13 10:01:13 2008
From: trac at galois.com (GHC)
Date: Sun Jan 13 09:54:38 2008
Subject: [GHC] #2039: Using GHC 6.8.2 as a library does not work well under
 Windows in GHCi
Message-ID: <051.1396b5ecbcb18e529c703113b3b39dd0@localhost>

#2039: Using GHC 6.8.2 as a library does not work well under Windows  in GHCi
-------------------------------------------------------------+--------------
    Reporter:  PVerswyvelen                                  |       Owner:         
        Type:  bug                                           |      Status:  new    
    Priority:  normal                                        |   Component:  GHC API
     Version:  6.8.2                                         |    Severity:  major  
    Keywords:  GHC API GHCi runtime linker duplicate symbol  |    Testcase:         
Architecture:  x86                                           |          Os:  Windows
-------------------------------------------------------------+--------------
 When executing the following code with GHCi 6.8.2 under Windows

 {{{
 ----->8--------
 import DynFlags

 import GHC

 main = defaultErrorHandler defaultDynFlags $ do
   session <- newSession (Just "d:\\app\\ghc-6.8.2")
   flags <- getSessionDynFlags session
   (flags, _) <- parseDynamicFlags flags []
   GHC.defaultCleanupHandler flags $ do
     setSessionDynFlags session flags{ hscTarget=HscInterpreted }
     prelude <- findModule session (mkModuleName "Prelude") Nothing
     setContext session [] [prelude]
     runStmt session "let n = 2 + 2" RunToCompletion
     runStmt session "n"  RunToCompletion
 ----->8--------
 }}}


 You get the following error:


 {{{
 Loading package array-0.1.0.0 ... linking ... done.
 Loading package packedstring-0.1.0.0 ... linking ... done.
 Loading package containers-0.1.0.1 ... linking ... done.
 Loading package old-locale-1.0.0.0 ... linking ... done.
 Loading package old-time-1.0.0.0 ... linking ... done.
 Loading package filepath-1.1.0.0 ... linking ... done.
 Loading package directory-1.0.0.0 ... linking ... done.
 Loading package process-1.0.0.0 ... linking ... done.
 Loading package pretty-1.0.0.0 ... linking ... done.
 Loading package hpc-0.5.0.0 ... linking ... done.
 Loading package template-haskell ... linking ... done.
 Loading package Cabal-1.2.3.0 ... linking ... done.
 Loading package random-1.0.0.0 ... linking ... done.
 Loading package haskell98 ... linking ... done.
 Loading package bytestring-0.9.0.1 ... linking ... done.
 Loading package Win32-2.1.1.0 ... linking ... done.
 Loading package ghc-6.8.2 ... linking ... done.


 GHCi runtime linker: fatal error: I found a duplicate definition for
 symbol
    _forkOS_entry
 whilst processing object file
    d:/app/ghc-6.8.2/lib\base-3.0.1.0/HSbase-3.0.1.0.o
 This could be caused by:
    * Loading two different object files which export the same symbol
    * Specifying the same object file twice on the GHCi command line
    * An incorrect `package.conf' entry, causing some object to be
      loaded twice.
 GHCi cannot safely continue in this situation.  Exiting now.  Sorry.

 }}}

 It works fine under Linux. It also works when using GHC --make under
 Windows, however I do get errors when using hs-plugins under Windows,
 which seems related.

 I haven't tried with GHC 6.9 yet.

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/2039>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Sun Jan 13 12:51:42 2008
From: trac at galois.com (GHC)
Date: Sun Jan 13 12:45:17 2008
Subject: [GHC] #2040: GADT regression
Message-ID: <044.1338e8edb0c35965ed9c7ce0ba7c6cb7@localhost>

#2040: GADT regression
------------------------+---------------------------------------------------
    Reporter:  guest    |       Owner:                         
        Type:  bug      |      Status:  new                    
    Priority:  normal   |   Component:  Compiler (Type checker)
     Version:  6.8.2    |    Severity:  normal                 
    Keywords:  gadt     |    Testcase:                         
Architecture:  Unknown  |          Os:  Unknown                
------------------------+---------------------------------------------------
 The following compiles fine in 6.8.1 but does not in later versions of
 GHC.

 I'm not sure if this is related to #1823, since there type classes are not
 involved.

 A workaround is included below.

 {{{
 {-# OPTIONS_GHC -Wall -fglasgow-exts #-}
 module Bug where

 data Teq a b where Teq :: Teq a a

 class C a b where proof :: Teq a b

 data S a = S a

 data W b where
     -- This would make every version of GHC happy
     -- W :: (C a c , c ~ S b) => W a -> W c
     W :: C a (S b) => W a -> W (S b)

 foo :: W (S ()) -> W (S ()) -> ()
 foo (W (_ :: W a1)) (W (_ :: W a2)) =
   case proof :: Teq a1 (S ()) of
     Teq -> ()

 foo2 :: W (S ()) -> W (S ()) -> ()
 foo2 (W (_ :: W a1)) (W (_ :: W a2)) =
   case proof :: Teq a1 (S ()) of
     Teq -> case proof :: Teq a2 (S ()) of
              Teq ->  ()
 }}}

 Results:

 6.8.1 : OK

 6.8.2 : foo OK, foo2 FAIL
 {{{
 Bug.hs:23:16:
     Could not deduce (C a1 (S ())) from the context ()
       arising from a use of `proof' at Bug.hs:23:16-20
 }}}
 6.9.20080108 : FAIL
 {{{
 Bug.hs:16:7:
     Could not deduce (C a (S ()))
       from the context (S () ~ S b1, C a1 (S b1))
       arising from a use of `proof' at Bug.hs:16:7-11
 Bug.hs:21:7:
     Could not deduce (C a (S ()))
       from the context (S () ~ S b1, C a1 (S b1))
       arising from a use of `proof' at Bug.hs:21:7-11
 Bug.hs:22:16:
     Could not deduce (C a1 (S ())) from the context (S () ~ a)
       arising from a use of `proof' at Bug.hs:22:16-20
 }}}

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/2040>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Sun Jan 13 15:39:13 2008
From: trac at galois.com (GHC)
Date: Sun Jan 13 15:32:35 2008
Subject: [GHC] #1599: testsuite timeout doesn't kill subprocesses on
 Windows
In-Reply-To: <047.b1020b9504f2c2f7ec4496c2c9545397@localhost>
References: <047.b1020b9504f2c2f7ec4496c2c9545397@localhost>
Message-ID: <056.c8bdcdf128460df58f32b0ba9fc123be@localhost>

#1599: testsuite timeout doesn't kill subprocesses on Windows
------------------------+---------------------------------------------------
 Reporter:  simonmar    |          Owner:  igloo     
     Type:  bug         |         Status:  new       
 Priority:  normal      |      Milestone:  6.8 branch
Component:  Test Suite  |        Version:  6.6.1     
 Severity:  normal      |     Resolution:            
 Keywords:              |     Difficulty:  Unknown   
 Testcase:              |   Architecture:  x86       
       Os:  Windows     |  
------------------------+---------------------------------------------------
Comment (by igloo):

 OK, `q.hsc` does the business:
 {{{
 $ ./build.sh
 + hsc2hs q.hsc
 + ghc --make q.hs
 [1 of 1] Compiling Main             ( q.hs, q.o )
 Linking q.exe ...

 $ time ./q.exe 1 ./Foo
 start main
 wibble

 real    0m1.331s
 user    0m0.010s
 sys     0m0.000s

 $ time ./q.exe 5 ./Foo
 start main
 wibble
 flibble
 end main
 ('A',0)

 real    0m3.175s
 user    0m0.020s
 sys     0m0.010s
 }}}
 Now it just needs splitting into 2 and merging into the Win32 package and
 testsuite timeout program.

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/1599#comment:3>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Sun Jan 13 17:05:09 2008
From: trac at galois.com (GHC)
Date: Sun Jan 13 16:58:31 2008
Subject: [GHC] #2041: Allow splicing in concrete syntax
Message-ID: <044.42309534ba1bde34757106bdf2d7d6ae@localhost>

#2041: Allow splicing in concrete syntax
---------------------------------+------------------------------------------
    Reporter:  igloo             |       Owner:             
        Type:  bug               |      Status:  new        
    Priority:  normal            |   Milestone:  6.10 branch
   Component:  Template Haskell  |     Version:  6.8.2      
    Severity:  normal            |    Keywords:             
  Difficulty:  Unknown           |    Testcase:             
Architecture:  Unknown           |          Os:  Unknown    
---------------------------------+------------------------------------------
 Template Haskell tends to lag behind GHC extensions, so it might be nice
 to allow concrete syntax to be returned, e.g. something like
 {{{
 f = $( return (RawE "5 + 6") )
 }}}
 There wouldn't be any need to restrict it to the top level, e.g. this
 would also be allowed:
 {{{
 f = $( return (InfixE (IntE 5) '(+) (RawE "6")) )
 }}}

 One possible disadvantage is that it might result in TH languishing even
 further behind, as there is less incentive to fill in the gaps.

 Also, if a module splices in a raw expression from a TH library, what
 extensions should be enabled when parsing the string? Should we use the
 extensions enabled for the module, or should the `RawE` constructor
 specify the extensions to be used? We actually have this problem already,
 as (for example) when instances are spliced in we might need
 !OverlappingInstances enabled, so just using the extensions enabled for
 the module would be consistent.

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/2041>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Sun Jan 13 17:36:59 2008
From: trac at galois.com (GHC)
Date: Sun Jan 13 17:30:58 2008
Subject: [GHC] #1838: do not use getEnv "HOME",
 use System.Directory.getHomeDirectory
In-Reply-To: <044.7c14aad23d72fc1f99272ac17d7d5b67@localhost>
References: <044.7c14aad23d72fc1f99272ac17d7d5b67@localhost>
Message-ID: <053.6067049c9daada8a70debe9bf56d6ae0@localhost>

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

  * status:  reopened => new
  * owner:  igloo =>

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/1838#comment:5>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Mon Jan 14 00:00:43 2008
From: trac at galois.com (GHC)
Date: Sun Jan 13 23:54:05 2008
Subject: [GHC] #1976: System.Posix.User.getUserEntryForName: incorrect
 error for non-existent user
In-Reply-To: <044.0e0a9e8b94cd6721d8b146a9523f3918@localhost>
References: <044.0e0a9e8b94cd6721d8b146a9523f3918@localhost>
Message-ID: <053.0951caff4680a78683bc897048618247@localhost>

#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:  errno           |     Difficulty:  Easy (1 hr)   
 Testcase:                  |   Architecture:  x86_64 (amd64)
       Os:  Linux           |  
----------------------------+-----------------------------------------------
Changes (by tac-tics):

  * keywords:  => errno

Comment:

 The reason for this is that getUserEntryForName uses a POSIX function
 getpwnam_r for its underlying implementation. In the event the user isn't
 found, getpwnam_r doesn't actually mess with errno at all, but instead
 relies on its 5th parameter to indicate an error. getUserEntryForName
 correctly detects the error, but since neither it nor getpwnam_r sets
 errno, the text string it displays is Success instead of something more
 appropriate.

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/1976#comment:2>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Mon Jan 14 03:43:56 2008
From: trac at galois.com (GHC)
Date: Mon Jan 14 03:37:17 2008
Subject: [GHC] #2041: Allow splicing in concrete syntax
In-Reply-To: <044.42309534ba1bde34757106bdf2d7d6ae@localhost>
References: <044.42309534ba1bde34757106bdf2d7d6ae@localhost>
Message-ID: <053.0e6cd7f13c9b860a52487d193bde9c77@localhost>

#2041: Allow splicing in concrete syntax
------------------------------+---------------------------------------------
 Reporter:  igloo             |          Owner:             
     Type:  feature request   |         Status:  new        
 Priority:  normal            |      Milestone:  6.10 branch
Component:  Template Haskell  |        Version:  6.8.2      
 Severity:  normal            |     Resolution:             
 Keywords:                    |     Difficulty:  Unknown    
 Testcase:                    |   Architecture:  Unknown    
       Os:  Unknown           |  
------------------------------+---------------------------------------------
Changes (by simonpj):

  * type:  bug => feature request

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/2041#comment:1>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Mon Jan 14 03:56:54 2008
From: trac at galois.com (GHC)
Date: Mon Jan 14 03:50:22 2008
Subject: [GHC] #2033: GHC-6.9 panics rather than parse error,
 related to view patterns.
In-Reply-To: <047.52dd94d8901a2e429a6ec81181a5f477@localhost>
References: <047.52dd94d8901a2e429a6ec81181a5f477@localhost>
Message-ID: <056.36ceb9b7bb4de239f2bdf242947d3e1a@localhost>

#2033: GHC-6.9 panics rather than parse error, related to view patterns.
----------------------+-----------------------------------------------------
 Reporter:  apeacock  |          Owner:             
     Type:  bug       |         Status:  new        
 Priority:  normal    |      Milestone:  6.10 branch
Component:  Compiler  |        Version:  6.9        
 Severity:  normal    |     Resolution:             
 Keywords:            |     Difficulty:  Unknown    
 Testcase:            |   Architecture:  x86        
       Os:  Windows   |  
----------------------+-----------------------------------------------------
Comment (by simonpj):

 Ian, I guess you understand what is going on here?  Patterns are parsed as
 expressions, and then converted to patterns. The form (e -> p), the
 `EViewPat` constructor in `HsExpr`, is valid as a pattern, but not as as
 expression.  Just like `EWildPat`, `EAsPat`, `ELazyPat`.

 The renamer checks for these (line 280 of `RnExpr`), so it's just a qn of
 adding `EViewPat` there too.  The error message isn't fantastic, but it's
 better than a crash.

 I'll let you finish this since you've started.

 Simon

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/2033#comment:4>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Mon Jan 14 03:59:54 2008
From: trac at galois.com (GHC)
Date: Mon Jan 14 03:53:16 2008
Subject: [GHC] #2030: GHC internal error: `m' is not in scope
In-Reply-To: <043.1667a40fa37775839c3eb6215de0afe4@localhost>
References: <043.1667a40fa37775839c3eb6215de0afe4@localhost>
Message-ID: <052.eefb1bf01a558b0c715d0dad1201155f@localhost>

#2030: GHC internal error: `m' is not in scope
-------------------------------------+--------------------------------------
 Reporter:  ToRA                     |          Owner:  igloo         
     Type:  merge                    |         Status:  new           
 Priority:  normal                   |      Milestone:                
Component:  Compiler (Type checker)  |        Version:  6.8.2         
 Severity:  normal                   |     Resolution:                
 Keywords:                           |     Difficulty:  Unknown       
 Testcase:  tc242                    |   Architecture:  x86_64 (amd64)
       Os:  Linux                    |  
-------------------------------------+--------------------------------------
Comment (by simonpj):

 See also #2037

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/2030#comment:7>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Mon Jan 14 05:27:10 2008
From: trac at galois.com (GHC)
Date: Mon Jan 14 05:20:31 2008
Subject: [GHC] #2027: ghc -e sometimes spills control characters into
 its output
In-Reply-To: <044.17b329c7bf8a300b55ac85b04d1b0204@localhost>
References: <044.17b329c7bf8a300b55ac85b04d1b0204@localhost>
Message-ID: <053.4d566652d92c78ebb9bd7a6f51621655@localhost>

#2027: ghc -e  sometimes spills control characters into its output
--------------------+-------------------------------------------------------
 Reporter:  int-e   |          Owner:  igloo      
     Type:  bug     |         Status:  closed     
 Priority:  normal  |      Milestone:  6.8.3      
Component:  GHCi    |        Version:  6.8.2      
 Severity:  minor   |     Resolution:  fixed      
 Keywords:          |     Difficulty:  Easy (1 hr)
 Testcase:          |   Architecture:  Unknown    
       Os:  Linux   |  
--------------------+-------------------------------------------------------
Changes (by igloo):

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

Comment:

 Thanks for the report & patch! I've applied it to the HEAD and 6.8 branch.

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/2027#comment:4>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Mon Jan 14 05:34:13 2008
From: trac at galois.com (GHC)
Date: Mon Jan 14 05:27:33 2008
Subject: [GHC] #2030: GHC internal error: `m' is not in scope
In-Reply-To: <043.1667a40fa37775839c3eb6215de0afe4@localhost>
References: <043.1667a40fa37775839c3eb6215de0afe4@localhost>
Message-ID: <052.f79190e4aec70cfced966891daff5d97@localhost>

#2030: GHC internal error: `m' is not in scope
-------------------------------------+--------------------------------------
 Reporter:  ToRA                     |          Owner:  igloo         
     Type:  merge                    |         Status:  closed        
 Priority:  normal                   |      Milestone:  6.8.3         
Component:  Compiler (Type checker)  |        Version:  6.8.2         
 Severity:  normal                   |     Resolution:  fixed         
 Keywords:                           |     Difficulty:  Unknown       
 Testcase:  tc242                    |   Architecture:  x86_64 (amd64)
       Os:  Linux                    |  
-------------------------------------+--------------------------------------
Changes (by igloo):

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

Comment:

 Merged
 {{{
 Thu Jan 10 03:31:33 PST 2008  simonpj@microsoft.com
   * Fix 2030: make -XScopedTypeVariables imply -XRelaxedPolyRec
 }}}

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/2030#comment:8>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Mon Jan 14 05:35:07 2008
From: trac at galois.com (GHC)
Date: Mon Jan 14 05:28:30 2008
Subject: [GHC] #2009: --with-gmp-includes not honoured everywhere
In-Reply-To: <043.9d6531f8ee8ae49a921eb477aa624802@localhost>
References: <043.9d6531f8ee8ae49a921eb477aa624802@localhost>
Message-ID: <052.6d7f5de4b53b7721a20392f7ea56ec72@localhost>

#2009: --with-gmp-includes not honoured everywhere
--------------------------+-------------------------------------------------
 Reporter:  kili          |          Owner:  igloo      
     Type:  merge         |         Status:  closed     
 Priority:  normal        |      Milestone:  6.8.3      
Component:  Build System  |        Version:  6.8.2      
 Severity:  normal        |     Resolution:  fixed      
 Keywords:                |     Difficulty:  Easy (1 hr)
 Testcase:                |   Architecture:  Multiple   
       Os:  OpenBSD       |  
--------------------------+-------------------------------------------------
Changes (by igloo):

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

Comment:

 Merged

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/2009#comment:4>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Mon Jan 14 05:36:05 2008
From: trac at galois.com (GHC)
Date: Mon Jan 14 05:29:27 2008
Subject: [GHC] #2018: Interface file error with GADT and -O1
In-Reply-To: <053.c8166aa67d18eb09eef50518c042c0a1@localhost>
References: <053.c8166aa67d18eb09eef50518c042c0a1@localhost>
Message-ID: <062.4abb634c52fb9e8a293ff2716d460cfb@localhost>

#2018: Interface file error with GADT and -O1
----------------------------+-----------------------------------------------
 Reporter:  Ashley Yakeley  |          Owner:  igloo         
     Type:  merge           |         Status:  closed        
 Priority:  normal          |      Milestone:                
Component:  Compiler        |        Version:  6.8.2         
 Severity:  normal          |     Resolution:  fixed         
 Keywords:                  |     Difficulty:  Unknown       
 Testcase:  tc241           |   Architecture:  x86_64 (amd64)
       Os:  Linux           |  
----------------------------+-----------------------------------------------
Changes (by igloo):

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

Comment:

 Both merged

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/2018#comment:2>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Mon Jan 14 05:36:35 2008
From: trac at galois.com (GHC)
Date: Mon Jan 14 05:29:58 2008
Subject: [GHC] #2017: Normal Guards are internally spliced as Pattern
 Guards causing compiler warnings
In-Reply-To: <043.0257207c9ea5e0a53cd58c7799a3a94d@localhost>
References: <043.0257207c9ea5e0a53cd58c7799a3a94d@localhost>
Message-ID: <052.471763a90c3a2b642cafc1cc7e507973@localhost>

#2017: Normal Guards are internally spliced as Pattern Guards causing compiler
warnings
------------------------------+---------------------------------------------
 Reporter:  fons              |          Owner:  igloo  
     Type:  merge             |         Status:  closed 
 Priority:  normal            |      Milestone:         
Component:  Template Haskell  |        Version:  6.8.2  
 Severity:  normal            |     Resolution:  fixed  
 Keywords:                    |     Difficulty:  Unknown
 Testcase:  TH_spliceGuard    |   Architecture:  Unknown
       Os:  Unknown           |  
------------------------------+---------------------------------------------
Changes (by igloo):

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

Comment:

 Merged

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/2017#comment:2>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Mon Jan 14 05:38:20 2008
From: trac at galois.com (GHC)
Date: Mon Jan 14 05:31:40 2008
Subject: [GHC] #1887: internal error while running parallel program
In-Reply-To: <042.6e0c34c36411842a56980d14ccd17967@localhost>
References: <042.6e0c34c36411842a56980d14ccd17967@localhost>
Message-ID: <051.5bd37d91f44c744f51a3e20562b5aeae@localhost>

#1887: internal error while running parallel program
----------------------------------+-----------------------------------------
 Reporter:  mrd                   |          Owner:  simonmar      
     Type:  bug                   |         Status:  new           
 Priority:  normal                |      Milestone:  6.10 branch   
Component:  Runtime System        |        Version:  6.9           
 Severity:  normal                |     Resolution:                
 Keywords:  sanity error threads  |     Difficulty:  Unknown       
 Testcase:                        |   Architecture:  x86_64 (amd64)
       Os:  Linux                 |  
----------------------------------+-----------------------------------------
Changes (by simonmar):

  * milestone:  6.8.3 => 6.10 branch

Comment:

 no point looking at this on the branch, vectorization is only working on
 the HEAD.

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/1887#comment:4>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Mon Jan 14 05:42:51 2008
From: trac at galois.com (GHC)
Date: Mon Jan 14 05:36:15 2008
Subject: [GHC] #1955: Heap profiling on Windows doesn't work
In-Reply-To: <051.41700a7931b75f5016d260a75d133aed@localhost>
References: <051.41700a7931b75f5016d260a75d133aed@localhost>
Message-ID: <060.6bb78ce70c79a2c085c0cbd6097ecfe8@localhost>

#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:  Easy (1 hr)
 Testcase:                  |   Architecture:  Unknown    
       Os:  Windows         |  
----------------------------+-----------------------------------------------
Changes (by simonmar):

  * difficulty:  Unknown => Easy (1 hr)

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/1955#comment:2>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Mon Jan 14 05:51:38 2008
From: trac at galois.com (GHC)
Date: Mon Jan 14 05:45:07 2008
Subject: [GHC] #2021: let ghc find framework header files and link with
 frameworks located in $HOME/Library/Frameworks
In-Reply-To: <045.f644abcffe54149a52e1b357b6ba7b01@localhost>
References: <045.f644abcffe54149a52e1b357b6ba7b01@localhost>
Message-ID: <054.bbf0cba9d84cbf6fb7f7e2c4cddcd3d0@localhost>

#2021: let ghc find framework header files and link with frameworks located in
$HOME/Library/Frameworks
-----------------------------+----------------------------------------------
 Reporter:  maeder           |          Owner:             
     Type:  feature request  |         Status:  new        
 Priority:  normal           |      Milestone:  6.10 branch
Component:  Compiler         |        Version:  6.8.2      
 Severity:  normal           |     Resolution:             
 Keywords:                   |     Difficulty:  Easy (1 hr)
 Testcase:                   |   Architecture:  Multiple   
       Os:  MacOS X          |  
-----------------------------+----------------------------------------------
Comment (by maeder):

 Why not set a deadline say in two weeks time? It's only a matter of
 deciding to commit my `DriverPipeline.hs` version or not. And I see no
 disadvantages to do so.

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/2021#comment:5>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Mon Jan 14 11:36:19 2008
From: trac at galois.com (GHC)
Date: Mon Jan 14 11:29:42 2008
Subject: [GHC] #2042: Add concatMapM to Control.Monad
Message-ID: <045.29d0c149fb4003aa216c4f2f5995cca5@localhost>

#2042: Add concatMapM to Control.Monad
-------------------------+--------------------------------------------------
    Reporter:  twanvl    |       Owner:                
        Type:  proposal  |      Status:  new           
    Priority:  normal    |   Component:  libraries/base
     Version:  6.8.2     |    Severity:  normal        
    Keywords:            |    Testcase:                
Architecture:  Unknown   |          Os:  Unknown       
-------------------------+--------------------------------------------------
 I have written this function over and over again for different projects.
 Time to add it to the base libraries:

 {{{
 -- | The 'concatMapM' function generalizes 'concatMap' to arbitrary
 monads.
 concatMapM        :: (Monad m) => (a -> m [b]) -> [a] -> m [b]
 concatMapM f xs   =  liftM concat (mapM f xs)
 }}}

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/2042>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Mon Jan 14 12:18:26 2008
From: trac at galois.com (GHC)
Date: Mon Jan 14 12:11:56 2008
Subject: [GHC] #2021: let ghc find framework header files and link with
 frameworks located in $HOME/Library/Frameworks
In-Reply-To: <045.f644abcffe54149a52e1b357b6ba7b01@localhost>
References: <045.f644abcffe54149a52e1b357b6ba7b01@localhost>
Message-ID: <054.6f5d6f4a372d0d22dd67f56bd4120a95@localhost>

#2021: let ghc find framework header files and link with frameworks located in
$HOME/Library/Frameworks
-----------------------------+----------------------------------------------
 Reporter:  maeder           |          Owner:             
     Type:  feature request  |         Status:  new        
 Priority:  normal           |      Milestone:  6.10 branch
Component:  Compiler         |        Version:  6.8.2      
 Severity:  normal           |     Resolution:             
 Keywords:                   |     Difficulty:  Easy (1 hr)
 Testcase:                   |   Architecture:  Multiple   
       Os:  MacOS X          |  
-----------------------------+----------------------------------------------
Comment (by thorkilnaur):

 As mentioned earlier, searching for frameworks in $HOME/Library/Frameworks
 is different from the behaviour of  other Mac OS X tools like gcc and ld
 in similar situations. It is not supported by the description of
 frameworks in the Apple document referred to earlier. I believe that we
 should refrain from explicitly introducing such incompatible behaviour.

 For an example of the disadvantage that a user may experience, say that I
 at some point install some framework in $HOME/Library/Frameworks to be
 used in some other context than GHC. If this framework matches some
 framework which is actually used by my Haskell code, but behaves
 differently - it could be a different version - then I would experience
 changed behaviour of my Haskell code. This is the sort of confusion that
 may require real work to untangle.

 So it is my recommandation that we do not introduce this change.

 Best regards
 Thorkil

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/2021#comment:6>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Mon Jan 14 14:08:32 2008
From: trac at galois.com (GHC)
Date: Mon Jan 14 14:01:56 2008
Subject: [GHC] #2043: Debug build is broken by removal of FastTypes import
 in utils/Util.lhs
Message-ID: <048.fba227bd4278f1734e5b26533beb9fc7@localhost>

#2043: Debug build is broken by removal of FastTypes import in utils/Util.lhs
--------------------------+-------------------------------------------------
    Reporter:  gmainland  |       Owner:  igloo   
        Type:  bug        |      Status:  new     
    Priority:  normal     |   Component:  Compiler
     Version:  6.9        |    Severity:  major   
    Keywords:             |    Testcase:          
Architecture:  x86        |          Os:  FreeBSD 
--------------------------+-------------------------------------------------
 The following patch removed the FastTypes import in utils/Util.lhs which
 causes the debug build to break:

 * Fix warnings in utils/Util

 FastTypes was imported unconditionally before this change, but only used
 when DEBUG was defined. This was a source of warnings which the above
 patch was meant to fix. The solution is to only import FastTypes when
 DEBUG is defined, which is what the attached patch does.

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/2043>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Mon Jan 14 15:08:05 2008
From: trac at galois.com (GHC)
Date: Mon Jan 14 15:01:35 2008
Subject: [GHC] #2021: let ghc find framework header files and link with
 frameworks located in $HOME/Library/Frameworks
In-Reply-To: <045.f644abcffe54149a52e1b357b6ba7b01@localhost>
References: <045.f644abcffe54149a52e1b357b6ba7b01@localhost>
Message-ID: <054.a6365b9fd1b56772f60404583e02a295@localhost>

#2021: let ghc find framework header files and link with frameworks located in
$HOME/Library/Frameworks
-----------------------------+----------------------------------------------
 Reporter:  maeder           |          Owner:             
     Type:  feature request  |         Status:  new        
 Priority:  normal           |      Milestone:  6.10 branch
Component:  Compiler         |        Version:  6.8.2      
 Severity:  normal           |     Resolution:             
 Keywords:                   |     Difficulty:  Easy (1 hr)
 Testcase:                   |   Architecture:  Multiple   
       Os:  MacOS X          |  
-----------------------------+----------------------------------------------
Comment (by igloo):

 If you think a deadline will help focus discussion, and hopefully reach a
 concensus that either the patch should be applied or that it should not,
 then please do feel free to propose one. All I meant in my earlier comment
 was that the impression I had was that more discussion was needed.

 How does this bug/patch relate to this patch, already in the HEAD and 6.8
 branch, by the way?:
 {{{
 [Include ~/Library/Frameworks in the framework searchpath
 Ian Lynagh <igloo@earth.li>**20071217233457
  Patch from Christian Maeder
 ] {
 hunk ./compiler/ghci/Linker.lhs 1132
 -   = do    { mb_fwk <- findFile mk_fwk (extraPaths ++
 defaultFrameworkPaths)
 -   ; case mb_fwk of
 -       Just fwk_path -> loadDLL fwk_path
 -       Nothing   -> return (Just "not found") }
 -       -- Tried all our known library paths, but dlopen()
 -       -- has no built-in paths for frameworks: give up
 +   = do { either_dir <- Control.Exception.try getHomeDirectory
 +        ; let homeFrameworkPath = case either_dir of
 +                                  Left _ -> []
 +                                  Right dir -> [dir ++
 "/Library/Frameworks"]
 +              ps = extraPaths ++ homeFrameworkPath ++
 defaultFrameworkPaths
 +        ; mb_fwk <- findFile mk_fwk ps
 +        ; case mb_fwk of
 +            Just fwk_path -> loadDLL fwk_path
 +            Nothing       -> return (Just "not found") }
 +                -- Tried all our known library paths, but dlopen()
 +                -- has no built-in paths for frameworks: give up
 hunk ./compiler/ghci/Linker.lhs 1145
 -   -- sorry for the hardcoded paths, I hope they won't change anytime
 soon:
 +        -- sorry for the hardcoded paths, I hope they won't change
 anytime soon:
 }
 }}}

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/2021#comment:7>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Mon Jan 14 17:00:56 2008
From: trac at galois.com (GHC)
Date: Mon Jan 14 16:54:21 2008
Subject: [GHC] #2033: GHC-6.9 panics rather than parse error,
 related to view patterns.
In-Reply-To: <047.52dd94d8901a2e429a6ec81181a5f477@localhost>
References: <047.52dd94d8901a2e429a6ec81181a5f477@localhost>
Message-ID: <056.defb6ea82b3f49e436457b0bce0c605b@localhost>

#2033: GHC-6.9 panics rather than parse error, related to view patterns.
----------------------+-----------------------------------------------------
 Reporter:  apeacock  |          Owner:  igloo      
     Type:  bug       |         Status:  new        
 Priority:  normal    |      Milestone:  6.10 branch
Component:  Compiler  |        Version:  6.9        
 Severity:  normal    |     Resolution:             
 Keywords:            |     Difficulty:  Unknown    
 Testcase:            |   Architecture:  x86        
       Os:  Windows   |  
----------------------+-----------------------------------------------------
Changes (by igloo):

  * owner:  => igloo

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/2033#comment:5>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Mon Jan 14 17:39:33 2008
From: trac at galois.com (GHC)
Date: Mon Jan 14 17:32:52 2008
Subject: [GHC] #1312: runghc doesn't respect -main-is
In-Reply-To: <047.0ad50b74545f6e5e0f2d7fb1521d3937@localhost>
References: <047.0ad50b74545f6e5e0f2d7fb1521d3937@localhost>
Message-ID: <056.cb3c6cf0740e891793f9dbb3e4fe659c@localhost>

#1312: runghc doesn't respect -main-is
----------------------+-----------------------------------------------------
 Reporter:  simonmar  |          Owner:             
     Type:  bug       |         Status:  new        
 Priority:  normal    |      Milestone:  6.8.3      
Component:  Compiler  |        Version:  6.6.1      
 Severity:  minor     |     Resolution:             
 Keywords:            |     Difficulty:  Easy (1 hr)
 Testcase:            |   Architecture:  Multiple   
       Os:  Unknown   |  
----------------------+-----------------------------------------------------
Comment (by igloo):

 `:main` also always runs main, regardless of any `-main-is` flag,
 currently. Also, it parses arguments itself, so we would have to build
 strings in such a way that it would parse them correctly. Also, `ghc -e
 :main` doesn't seem to work at the moment.

 I propose changing `:main`'s behaviour, adding `:run` and adding `:set
 arg-style` so that things work like this:
 {{{
 :main arg1 arg2        -- runs main, with args ["arg1", "arg2"]
 :set -main-is foo
 :main arg1 arg2        -- runs foo, with args ["arg1", "arg2"]
 :run bar arg1 arg2     -- runs bar, with args ["arg1", "arg2"]
 :set arg-style haskell -- opposite is :set arg-style shell
 :main ["arg1", "arg2"] -- runs foo, with args ["arg1", "arg2"]
 }}}
 and changing ghc so that
 {{{
 ghc -e X -e Y
 }}}
 behaves more like
 {{{
 X
 Y
 }}}
 in ghci. Any opinions?

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/1312#comment:4>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Mon Jan 14 18:18:29 2008
From: trac at galois.com (GHC)
Date: Mon Jan 14 18:11:54 2008
Subject: [GHC] #2005: localhost on mac causes getnameinfo error in
 safari.
In-Reply-To: <043.2e0e6309ca162e2f7e3751b621e7afca@localhost>
References: <043.2e0e6309ca162e2f7e3751b621e7afca@localhost>
Message-ID: <052.2facde869690f2504b8003a54700030b@localhost>

#2005: localhost on mac causes getnameinfo error in safari.
------------------------------------+---------------------------------------
 Reporter:  alex                    |          Owner:         
     Type:  bug                     |         Status:  new    
 Priority:  normal                  |      Milestone:  Not GHC
Component:  libraries/network       |        Version:  6.8.2  
 Severity:  normal                  |     Resolution:         
 Keywords:  network localhost ipv6  |     Difficulty:  Unknown
 Testcase:                          |   Architecture:  x86    
       Os:  MacOS X                 |  
------------------------------------+---------------------------------------
Comment (by danb):

 Server.hs:
 {{{
 #!/usr/bin/env runghc
 module Main where
 import Network

 main = accept =<< listenOn (PortNumber 8000)
 }}}

 First, run the server:
 {{{
 $ ./Server.hs
 }}}

 Connect with IP, server just quits:
 {{{
 nc 127.0.0.1 8000
 }}}
 {{{
 $ ./Server.hs
 $
 }}}

 Connect with name, server dies:
 {{{
 nc localhost 8000
 }}}
 {{{
 $ ./Server.hs
 Server.hs: getNameInfo: does not exist (System error)

 $
 }}}

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/2005#comment:4>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Mon Jan 14 19:29:06 2008
From: trac at galois.com (GHC)
Date: Mon Jan 14 19:22:28 2008
Subject: [GHC] #1976: System.Posix.User.getUserEntryForName: incorrect
 error for non-existent user
In-Reply-To: <044.0e0a9e8b94cd6721d8b146a9523f3918@localhost>
References: <044.0e0a9e8b94cd6721d8b146a9523f3918@localhost>
Message-ID: <053.25d2a44877b2bf36edb84358fe3818f4@localhost>

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

  * owner:  => igloo

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/1976#comment:3>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Tue Jan 15 04:02:39 2008
From: trac at galois.com (GHC)
Date: Tue Jan 15 03:55:58 2008
Subject: [GHC] #1312: runghc doesn't respect -main-is
In-Reply-To: <047.0ad50b74545f6e5e0f2d7fb1521d3937@localhost>
References: <047.0ad50b74545f6e5e0f2d7fb1521d3937@localhost>
Message-ID: <056.6f15424cf9b53c906638ce72cd347263@localhost>

#1312: runghc doesn't respect -main-is
----------------------+-----------------------------------------------------
 Reporter:  simonmar  |          Owner:             
     Type:  bug       |         Status:  new        
 Priority:  normal    |      Milestone:  6.8.3      
Component:  Compiler  |        Version:  6.6.1      
 Severity:  minor     |     Resolution:             
 Keywords:            |     Difficulty:  Easy (1 hr)
 Testcase:            |   Architecture:  Multiple   
       Os:  Unknown   |  
----------------------+-----------------------------------------------------
Comment (by simonmar):

 Strange, I thought the whole point of `:main` was that it ran whatever
 `-main-is` was set to.  I must have been dreaming that.

 I'm not sure we need `set arg-style`, rather I'd like to see the argument
 parsing (currently in `Util.toArgs`) be the simple:

  * double-quoted strings are parsed using `read`
  * everything else is split up at whitespace

 It would be easy to construct the `:main` args: just `unwords . map show`.

 Didn't this come up in another context recently?

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/1312#comment:5>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Tue Jan 15 04:09:20 2008
From: trac at galois.com (GHC)
Date: Tue Jan 15 04:02:48 2008
Subject: [GHC] #2021: let ghc find framework header files and link with
 frameworks located in $HOME/Library/Frameworks
In-Reply-To: <045.f644abcffe54149a52e1b357b6ba7b01@localhost>
References: <045.f644abcffe54149a52e1b357b6ba7b01@localhost>
Message-ID: <054.7933dd58c0ff1f9dd54b7a0574f9b184@localhost>

#2021: let ghc find framework header files and link with frameworks located in
$HOME/Library/Frameworks
-----------------------------+----------------------------------------------
 Reporter:  maeder           |          Owner:             
     Type:  feature request  |         Status:  new        
 Priority:  normal           |      Milestone:  6.10 branch
Component:  Compiler         |        Version:  6.8.2      
 Severity:  normal           |     Resolution:             
 Keywords:                   |     Difficulty:  Easy (1 hr)
 Testcase:                   |   Architecture:  Multiple   
       Os:  MacOS X          |  
-----------------------------+----------------------------------------------
Comment (by maeder):

 Replying to [comment:7 igloo]:
 > How does this bug/patch relate to this patch, already in the HEAD and
 6.8 branch, by the way?:
 [...]
 > hunk ./compiler/ghci/Linker.lhs 1132
 > -   = do    { mb_fwk <- findFile mk_fwk (extraPaths ++
 defaultFrameworkPaths)
 > -   ; case mb_fwk of
 > -       Just fwk_path -> loadDLL fwk_path
 > -       Nothing   -> return (Just "not found") }
 > -       -- Tried all our known library paths, but dlopen()
 > -       -- has no built-in paths for frameworks: give up
 > +   = do { either_dir <- Control.Exception.try getHomeDirectory

 did not I use `IO.try`?

 The patch in `Linker.lhs` mimics (or tries to mimic) the behaviour of the
 dynamic linker and was not disputed. (see end of #1798)

 Indeed gcc and ld do not search the home directory for frameworks, I
 suppose mainly to avoid producing binaries depending on frameworks that
 are not generally available.

 Because GMP and GNUreadline frameworks are not generally available, it
 makes sense to extend ghc to also search the home directory when building
 and avoid the burden for developers to add appropriate options to ghc's
 command line manually.

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/2021#comment:8>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Tue Jan 15 06:11:40 2008
From: trac at galois.com (GHC)
Date: Tue Jan 15 06:05:07 2008
Subject: [GHC] #2021: let ghc find framework header files and link with
 frameworks located in $HOME/Library/Frameworks
In-Reply-To: <045.f644abcffe54149a52e1b357b6ba7b01@localhost>
References: <045.f644abcffe54149a52e1b357b6ba7b01@localhost>
Message-ID: <054.4d0ed1a517a1cf98af60f276110b0dfd@localhost>

#2021: let ghc find framework header files and link with frameworks located in
$HOME/Library/Frameworks
-----------------------------+----------------------------------------------
 Reporter:  maeder           |          Owner:             
     Type:  feature request  |         Status:  new        
 Priority:  normal           |      Milestone:  6.10 branch
Component:  Compiler         |        Version:  6.8.2      
 Severity:  normal           |     Resolution:             
 Keywords:                   |     Difficulty:  Easy (1 hr)
 Testcase:                   |   Architecture:  Multiple   
       Os:  MacOS X          |  
-----------------------------+----------------------------------------------
Comment (by maeder):

 An alternative location for the GMP and GNUreadline frameworks could be
 ghc's libdir (`ghc --print-libdir`) This would require to extend
 `Linker.lhs` and `DriverPipeline.hs` again.

 The frameworks would then be private to ghc:

 {{{
 otool -L lib/ghc-6.8.2/ghc-6.8.2
 lib/ghc-6.8.2/ghc-6.8.2:
         @executable_path/GMP.framework/Versions/A/GMP (compatibility
 version 8.0.0, current version 8.1.0)
         @executable_path/GNUreadline.framework/Versions/A/GNUreadline
 (compatibility version 5.0.0, current version 5.2.0)
         /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current
 version 88.3.9)
 }}}

 Binaries created with such an ghc still need (at least one of) the
 frameworks that may be found in the user's home directory by the dynamic
 linker at runtime.

 Also binaries could be created with private frameworks, but then such a
 binary is no longer a single file.

 P.S. Making a binary look for a private framework can be done using
 `install_name_tool`, i.e.

 {{{
 install_name_tool -change GMP.framework/Versions/A/GMP
 @executable_path/GMP.framework/Versions/A/GMP ghc-6.8.2
 }}}

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/2021#comment:9>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Tue Jan 15 06:21:30 2008
From: trac at galois.com (GHC)
Date: Tue Jan 15 06:14:54 2008
Subject: [GHC] #2044: "Can't unify" error in debugger
Message-ID: <044.9de84d1571c81bf2b4030ee1192776b2@localhost>

#2044: "Can't unify" error in debugger
-----------------------+----------------------------------------------------
    Reporter:  r6144   |       Owner:        
        Type:  bug     |      Status:  new   
    Priority:  normal  |   Component:  GHCi  
     Version:  6.8.2   |    Severity:  normal
    Keywords:          |    Testcase:        
Architecture:  x86     |          Os:  Linux 
-----------------------+----------------------------------------------------
 Debugging the attached array1.hs under GHCi gives the following error:

 {{{
 [haskell]$ ghci
 GHCi, version 6.8.2: http://www.haskell.org/ghc/  :? for help
 Loading package base ... linking ... done.
 Prelude> :load array1.hs
 [1 of 1] Compiling Main             ( array1.hs, interpreted )
 Ok, modules loaded: Main.
 *Main> :break rsRandomArray
 Breakpoint 0 activated at array1.hs:(31,0)-(42,79)
 *Main> main
 Loading package array-0.1.0.0 ... linking ... done.
 Loading package old-locale-1.0.0.0 ... linking ... done.
 Loading package old-time-1.0.0.0 ... linking ... done.
 Loading package random-1.0.0.0 ... linking ... done.
 Array 1: array Stopped at array1.hs:(31,0)-(42,79)
 _result :: ST s (UArray Idx Double) = _
 [array1.hs:(31,0)-(42,79)] *Main> :step
 Stopped at array1.hs:31:21-53
 ghc-6.8.2: panic! (the 'impossible' happened)
   (GHC version 6.8.2 for i386-unknown-linux):
         Can't unify

 Please report this as a GHC bug:  http://www.haskell.org/ghc/reportabug

 [array1.hs:31:21-53] *Main> :quit
 Leaving GHCi.
 }}}

 I'm running Fedora 8 with gcc version 4.1.2 20070925 (Red Hat 4.1.2-33)
 and ghc-6.8.2-2.fc8.

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/2044>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Tue Jan 15 06:57:54 2008
From: trac at galois.com (GHC)
Date: Tue Jan 15 06:51:10 2008
Subject: [GHC] #2045: Link error when compiling with -fhpc
Message-ID: <044.3e291c48a73368cfaa2c03d4b6685800@localhost>

#2045: Link error when compiling with -fhpc
------------------------+---------------------------------------------------
    Reporter:  guest    |       Owner:          
        Type:  bug      |      Status:  new     
    Priority:  normal   |   Component:  Compiler
     Version:  6.8.2    |    Severity:  normal  
    Keywords:           |    Testcase:          
Architecture:  Unknown  |          Os:  Unknown 
------------------------+---------------------------------------------------
 I've attached a version of Lava and simple program Main.hs.  Compiling
 without -fhpc works fine, but with -fhpc, gives a link error (Neil says
 it's trying to find the 74 element tupe and can't).

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/2045>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Tue Jan 15 08:06:55 2008
From: trac at galois.com (GHC)
Date: Tue Jan 15 08:00:12 2008
Subject: [GHC] #2045: Link error when compiling with -fhpc
In-Reply-To: <044.3e291c48a73368cfaa2c03d4b6685800@localhost>
References: <044.3e291c48a73368cfaa2c03d4b6685800@localhost>
Message-ID: <053.dd4f82455290a615a052411b034ca5b7@localhost>

#2045: Link error when compiling with -fhpc
-------------------------+--------------------------------------------------
    Reporter:  guest     |        Owner:         
        Type:  bug       |       Status:  new    
    Priority:  normal    |    Milestone:         
   Component:  Compiler  |      Version:  6.8.2  
    Severity:  normal    |   Resolution:         
    Keywords:            |     Testcase:         
Architecture:  Unknown   |           Os:  Unknown
-------------------------+--------------------------------------------------
Comment (by guest):

 Forgot to pase the exact error message:

 Linking gencirc ...
 ../Lava2000/Modules/Vhdl.o: In function `s13oq_info':
 (.text+0xbd5): undefined reference to `base_DataziTuple_Z74T_con_info'
 collect2: ld returned 1 exit status

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/2045#comment:1>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Tue Jan 15 09:56:06 2008
From: trac at galois.com (GHC)
Date: Tue Jan 15 09:49:27 2008
Subject: [GHC] #2046: Parse errors for mismatched brackets are awful
Message-ID: <051.7be25e7d35fa07157a1df63dc6e9cffc@localhost>

#2046: Parse errors for mismatched brackets are awful
--------------------------------+-------------------------------------------
    Reporter:  NeilMitchell     |       Owner:          
        Type:  feature request  |      Status:  new     
    Priority:  normal           |   Component:  Compiler
     Version:  6.6.1            |    Severity:  minor   
    Keywords:                   |    Testcase:          
Architecture:  Unknown          |          Os:  Unknown 
--------------------------------+-------------------------------------------
 {{{
 ghci> [foo
 <interactive>:1:4: parse error (possibly incorrect indentation)
 }}}

 The parser error messages for incorrect brackets are awful. A much better
 message would be:

 {{{
 ghci> [foo
 <interative>:1:1: bracket opened but not shut
 }}}

 i.e. refer to bracket issues, and say where the bracket started.

 I realise this may be difficult within the current parser, but a simple
 post-processor for syntax errors could perhaps detect such errors. Also,
 while the { character and reasonably be about indentation, the others are
 much less likely to be.

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/2046>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Tue Jan 15 10:28:38 2008
From: trac at galois.com (GHC)
Date: Tue Jan 15 10:22:06 2008
Subject: [GHC] #2033: GHC-6.9 panics rather than parse error,
 related to view patterns.
In-Reply-To: <047.52dd94d8901a2e429a6ec81181a5f477@localhost>
References: <047.52dd94d8901a2e429a6ec81181a5f477@localhost>
Message-ID: <056.ada554978fd191abab1c13d1ac87b433@localhost>

#2033: GHC-6.9 panics rather than parse error, related to view patterns.
-----------------------+----------------------------------------------------
 Reporter:  apeacock   |          Owner:  igloo      
     Type:  bug        |         Status:  closed     
 Priority:  normal     |      Milestone:  6.10 branch
Component:  Compiler   |        Version:  6.9        
 Severity:  normal     |     Resolution:  fixed      
 Keywords:             |     Difficulty:  Unknown    
 Testcase:  rnfail051  |   Architecture:  Multiple   
       Os:  Multiple   |  
-----------------------+----------------------------------------------------
Changes (by igloo):

  * testcase:  => rnfail051
  * status:  new => closed
  * os:  Windows => Multiple
  * resolution:  => fixed
  * architecture:  x86 => Multiple

Comment:

 Simon, yes, I had guessed that it ought to be rejected earlier, but hadn't
 looked for where yet. Now fixed - thanks for the pointer!

 Thanks
 Ian

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/2033#comment:6>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Tue Jan 15 10:39:00 2008
From: trac at galois.com (GHC)
Date: Tue Jan 15 10:32:33 2008
Subject: [GHC] #2043: Debug build is broken by removal of FastTypes
 import in utils/Util.lhs
In-Reply-To: <048.fba227bd4278f1734e5b26533beb9fc7@localhost>
References: <048.fba227bd4278f1734e5b26533beb9fc7@localhost>
Message-ID: <057.49ada11dfdf42b5573b55f7d06b147d7@localhost>

#2043: Debug build is broken by removal of FastTypes import in utils/Util.lhs
-----------------------+----------------------------------------------------
 Reporter:  gmainland  |          Owner:  igloo      
     Type:  bug        |         Status:  closed     
 Priority:  normal     |      Milestone:  6.10 branch
Component:  Compiler   |        Version:  6.9        
 Severity:  major      |     Resolution:  fixed      
 Keywords:             |     Difficulty:  Unknown    
 Testcase:             |   Architecture:  x86        
       Os:  FreeBSD    |  
-----------------------+----------------------------------------------------
Changes (by igloo):

  * status:  new => closed
  * difficulty:  => Unknown
  * resolution:  => fixed
  * milestone:  => 6.10 branch

Comment:

 Thanks for the patch! I've applied it.

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/2043#comment:1>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Tue Jan 15 10:45:11 2008
From: trac at galois.com (GHC)
Date: Tue Jan 15 10:38:30 2008
Subject: [GHC] #2047: ghc compiled program crashes with segfault when using
 -M and/or -c
Message-ID: <042.76ffc0b2217121d0a72a366715d60678@localhost>

#2047: ghc compiled program crashes with segfault when using -M and/or -c
----------------------------+-----------------------------------------------
    Reporter:  mte          |       Owner:                
        Type:  bug          |      Status:  new           
    Priority:  normal       |   Component:  Runtime System
     Version:  6.8.2        |    Severity:  critical      
    Keywords:  gc segfault  |    Testcase:                
Architecture:  x86          |          Os:  Windows       
----------------------------+-----------------------------------------------
 When running my program with limited heap size (-H128m) and/or using the
 compacting procedure (-c) in garbage collection, the program crashes with
 the following message:

 Segmentation fault/access violation in generated code

 It seems that the segfault occurs the first time the garbage collector
 runs as the log file generated with -S contains the headline only.

 The program runs fine without the -M and -c options.

 This problem is critical from my point of view as I cannot control what
 kind of data the customer will supply to the algorithm and I would the
 prefer the algorithm (then deployed as a DLL) to gracefully report a heap
 overflow instead of eating all the customer's terminal server's memory.

 Let me know how I can help to fix this bug.

 As the source code is proprietary, I cannot attach it here.

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/2047>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Tue Jan 15 11:17:24 2008
From: trac at galois.com (GHC)
Date: Tue Jan 15 11:10:49 2008
Subject: [GHC] #2021: let ghc find framework header files and link with
 frameworks located in $HOME/Library/Frameworks
In-Reply-To: <045.f644abcffe54149a52e1b357b6ba7b01@localhost>
References: <045.f644abcffe54149a52e1b357b6ba7b01@localhost>
Message-ID: <054.ef604278c542ca3f80649ac01a21605a@localhost>

#2021: let ghc find framework header files and link with frameworks located in
$HOME/Library/Frameworks
-----------------------------+----------------------------------------------
 Reporter:  maeder           |          Owner:             
     Type:  feature request  |         Status:  new        
 Priority:  normal           |      Milestone:  6.10 branch
Component:  Compiler         |        Version:  6.8.2      
 Severity:  normal           |     Resolution:             
 Keywords:                   |     Difficulty:  Easy (1 hr)
 Testcase:                   |   Architecture:  Multiple   
       Os:  MacOS X          |  
-----------------------------+----------------------------------------------
Comment (by maeder):

 It is still important to change `DriverPipline.hs` in order to find header
 files given by framework paths on the command line or in package.conf
 files!

 In order to omit searching the home directory change my above
 `getFrameworkPathOpts` to:

 {{{
 -- options to pass to gcc and ld on macs only
 getFrameworkPathOpts  :: DynFlags -> [PackageId] -> IO [String]
 getFrameworkPathOpts dflags pkgs = do
   ps <- getPackageFrameworkPath dflags pkgs
   return $ map ("-F" ++) $ ps ++ frameworkPaths dflags
 }}}

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/2021#comment:10>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Tue Jan 15 14:53:03 2008
From: trac at galois.com (GHC)
Date: Tue Jan 15 14:46:20 2008
Subject: [GHC] #2046: Parse errors for mismatched brackets are awful
In-Reply-To: <051.7be25e7d35fa07157a1df63dc6e9cffc@localhost>
References: <051.7be25e7d35fa07157a1df63dc6e9cffc@localhost>
Message-ID: <060.efc945e14244c2c8c73e789f8a1a01d6@localhost>

#2046: Parse errors for mismatched brackets are awful
--------------------------------+-------------------------------------------
    Reporter:  NeilMitchell     |        Owner:         
        Type:  feature request  |       Status:  new    
    Priority:  normal           |    Milestone:         
   Component:  Compiler         |      Version:  6.6.1  
    Severity:  minor            |   Resolution:         
    Keywords:                   |     Testcase:         
Architecture:  Unknown          |           Os:  Unknown
--------------------------------+-------------------------------------------
Comment (by tim):

 I agree with Neil. It has been a lifelong annoyance for me to not know
 whether that error message is *actually* due to incorrect indentation, or
 to mismatched brackets. I have no idea how hard it would be to improve
 this in the current parser, but from a user point of view, it can be
 enormously frustrating.

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/2046#comment:1>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Tue Jan 15 21:17:46 2008
From: trac at galois.com (GHC)
Date: Tue Jan 15 21:11:00 2008
Subject: [GHC] #2019: GADT record with polytype argument causes
 irrefutable pattern failure in basicTypes/MkId.lhs
In-Reply-To: <045.791b8f9a465ed91be02dc1a0633e357f@localhost>
References: <045.791b8f9a465ed91be02dc1a0633e357f@localhost>
Message-ID: <054.728f60a7e2589fd5857d4bcbbf0a4651@localhost>

#2019: GADT record with polytype argument causes irrefutable pattern failure in
basicTypes/MkId.lhs
---------------------------------------------+------------------------------
 Reporter:  japple                           |          Owner:  igloo  
     Type:  merge                            |         Status:  closed 
 Priority:  normal                           |      Milestone:  6.8.3  
Component:  Compiler                         |        Version:  6.8.2  
 Severity:  normal                           |     Resolution:  fixed  
 Keywords:                                   |     Difficulty:  Unknown
 Testcase:  tcfail195, tcfail196, tcfail197  |   Architecture:  x86    
       Os:  Linux                            |  
---------------------------------------------+------------------------------
Changes (by igloo):

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

Comment:

 I've set the tests to be skipped in the 6.8 branch.

 This patch:
 {{{
 Mon Jan  7 11:54:51 GMT 2008  simonpj@microsoft.com
   * Add -XImpredicativeTypes, and tighten up type-validity checking (cf
 Trac 2019)
 [...]
   Could be merged to 6.8 but no big deal.
 }}}
 doesn't merge cleanly, so I haven't merged it.

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/2019#comment:3>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Tue Jan 15 21:20:38 2008
From: trac at galois.com (GHC)
Date: Tue Jan 15 21:13:53 2008
Subject: [GHC] #1976: System.Posix.User.getUserEntryForName: incorrect
 error for non-existent user
In-Reply-To: <044.0e0a9e8b94cd6721d8b146a9523f3918@localhost>
References: <044.0e0a9e8b94cd6721d8b146a9523f3918@localhost>
Message-ID: <053.7b971a456be7b53ae7b5445ebe6ad5de@localhost>

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

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

Comment:

 Now fixed in both HEAD and 6.8 branch.

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/1976#comment:4>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Wed Jan 16 04:25:40 2008
From: trac at galois.com (GHC)
Date: Wed Jan 16 04:18:56 2008
Subject: [GHC] #2047: ghc compiled program crashes with segfault when
 using -M and/or -c
In-Reply-To: <042.76ffc0b2217121d0a72a366715d60678@localhost>
References: <042.76ffc0b2217121d0a72a366715d60678@localhost>
Message-ID: <051.a3780b07f2fbc7bc00620034f4750bb1@localhost>

#2047: ghc compiled program crashes with segfault when using -M and/or -c
----------------------------+-----------------------------------------------
 Reporter:  mte             |          Owner:         
     Type:  bug             |         Status:  new    
 Priority:  normal          |      Milestone:  6.8.3  
Component:  Runtime System  |        Version:  6.8.2  
 Severity:  critical        |     Resolution:         
 Keywords:  gc segfault     |     Difficulty:  Unknown
 Testcase:                  |   Architecture:  x86    
       Os:  Windows         |  
----------------------------+-----------------------------------------------
Changes (by simonmar):

  * difficulty:  => Unknown
  * milestone:  => 6.8.3

Comment:

 This certainly sounds like a bug in the compacting GC.  Without means to
 reproduce it though, it's impossible to diagnose.

 If you could reproduce the error in non-proprietary code, or somehow
 arrange to give me the code with a no-redistribution license, that would
 help a lot.

 If you need to use `-M` without the compacting GC, the workaround is to
 add `-c100`, which should disable the automatic compacting GC threshold.

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/2047#comment:1>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Wed Jan 16 04:32:52 2008
From: trac at galois.com (GHC)
Date: Wed Jan 16 04:26:16 2008
Subject: [GHC] #2046: Parse errors for mismatched brackets are awful
In-Reply-To: <051.7be25e7d35fa07157a1df63dc6e9cffc@localhost>
References: <051.7be25e7d35fa07157a1df63dc6e9cffc@localhost>
Message-ID: <060.125ad1bc486b051c46137e31fcf939cb@localhost>

#2046: Parse errors for mismatched brackets are awful
-------------------------------+--------------------------------------------
 Reporter:  NeilMitchell       |          Owner:           
     Type:  feature request    |         Status:  closed   
 Priority:  normal             |      Milestone:           
Component:  Compiler (Parser)  |        Version:  6.6.1    
 Severity:  minor              |     Resolution:  duplicate
 Keywords:                     |     Difficulty:  Unknown  
 Testcase:                     |   Architecture:  Unknown  
       Os:  Unknown            |  
-------------------------------+--------------------------------------------
Changes (by simonmar):

  * component:  Compiler => Compiler (Parser)
  * difficulty:  => Unknown
  * status:  new => closed
  * resolution:  => duplicate

Comment:

 This is a long-standing problem, see #459 :-)

 The "possibly incorrect indentation" message arises because the token the
 parser is looking at is one that was generated by layout.  I honestly
 don't know whether there's anything we can easily do to improve matters in
 the context of the current parser, but I suspect not.

 Anyway, I propose to look at it next time I'm in the area.

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/2046#comment:2>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Wed Jan 16 04:33:48 2008
From: trac at galois.com (GHC)
Date: Wed Jan 16 04:27:02 2008
Subject: [GHC] #459: Bad parse error message
In-Reply-To: <045.9adecc17314923c33323a1bd4204dfc1@localhost>
References: <045.9adecc17314923c33323a1bd4204dfc1@localhost>
Message-ID: <054.c5be6001a330351f3a5c45c7ec3ce9db@localhost>

#459: Bad parse error message
-------------------------------+--------------------------------------------
 Reporter:  nobody             |          Owner:  simonmar
     Type:  bug                |         Status:  new     
 Priority:  normal             |      Milestone:  _|_     
Component:  Compiler (Parser)  |        Version:  6.4.1   
 Severity:  minor              |     Resolution:  None    
 Keywords:                     |     Difficulty:  Unknown 
 Testcase:                     |   Architecture:  Unknown 
       Os:  Unknown            |  
-------------------------------+--------------------------------------------
Changes (by simonmar):

  * priority:  low => normal

Comment:

 See also #2046.  Raising priority based on feedback.

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/459#comment:4>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Wed Jan 16 05:25:18 2008
From: trac at galois.com (GHC)
Date: Wed Jan 16 05:18:42 2008
Subject: [GHC] #2021: let ghc find framework header files and link with
 frameworks located in $HOME/Library/Frameworks
In-Reply-To: <045.f644abcffe54149a52e1b357b6ba7b01@localhost>
References: <045.f644abcffe54149a52e1b357b6ba7b01@localhost>
Message-ID: <054.80d30861a753257d0759994fb0f1e022@localhost>

#2021: let ghc find framework header files and link with frameworks located in
$HOME/Library/Frameworks
-----------------------------+----------------------------------------------
 Reporter:  maeder           |          Owner:             
     Type:  feature request  |         Status:  new        
 Priority:  normal           |      Milestone:  6.10 branch
Component:  Compiler         |        Version:  6.8.2      
 Severity:  normal           |     Resolution:             
 Keywords:                   |     Difficulty:  Easy (1 hr)
 Testcase:                   |   Architecture:  Multiple   
       Os:  MacOS X          |  
-----------------------------+----------------------------------------------
Comment (by maeder):

 Check at least in my (recently attached) version that passes -F properly
 to gcc and ld for ghc-6.8.3, I've removed checking the home directory, so
 the above objections are no longer valid.

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/2021#comment:11>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Wed Jan 16 05:28:32 2008
From: trac at galois.com (GHC)
Date: Wed Jan 16 05:21:52 2008
Subject: [GHC] #2021: let ghc find framework header files and link with
 frameworks located in $HOME/Library/Frameworks
In-Reply-To: <045.f644abcffe54149a52e1b357b6ba7b01@localhost>
References: <045.f644abcffe54149a52e1b357b6ba7b01@localhost>
Message-ID: <054.e5cc6ba72c9faa95dd4dc3b203bec7d0@localhost>

#2021: let ghc find framework header files and link with frameworks located in
$HOME/Library/Frameworks
-----------------------------+----------------------------------------------
 Reporter:  maeder           |          Owner:             
     Type:  feature request  |         Status:  new        
 Priority:  normal           |      Milestone:  6.10 branch
Component:  Compiler         |        Version:  6.8.2      
 Severity:  normal           |     Resolution:             
 Keywords:                   |     Difficulty:  Easy (1 hr)
 Testcase:                   |   Architecture:  Multiple   
       Os:  MacOS X          |  
-----------------------------+----------------------------------------------
Comment (by maeder):

 Delete "and link with frameworks located in $HOME/Library/Frameworks" from
 the description of this ticket.

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/2021#comment:12>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Wed Jan 16 07:39:33 2008
From: trac at galois.com (GHC)
Date: Wed Jan 16 07:32:52 2008
Subject: [GHC] #2046: Parse errors for mismatched brackets are awful
In-Reply-To: <051.7be25e7d35fa07157a1df63dc6e9cffc@localhost>
References: <051.7be25e7d35fa07157a1df63dc6e9cffc@localhost>
Message-ID: <060.612c6cb0a06aa635d6612387f4989a30@localhost>

#2046: Parse errors for mismatched brackets are awful
-------------------------------+--------------------------------------------
 Reporter:  NeilMitchell       |          Owner:           
     Type:  feature request    |         Status:  closed   
 Priority:  normal             |      Milestone:           
Component:  Compiler (Parser)  |        Version:  6.6.1    
 Severity:  minor              |     Resolution:  duplicate
 Keywords:                     |     Difficulty:  Unknown  
 Testcase:                     |   Architecture:  Unknown  
       Os:  Unknown            |  
-------------------------------+--------------------------------------------
Comment (by NeilMitchell):

 A simple fix would be that if the parsing fails with a "possibly incorrect
 indentation" style warning, you rerun the lexer over the original file,
 without inserting symbols based on indentation. After you have this raw
 lexical stream, you do a simple scan with a bracket stack and check
 everything matches up. If it doesn't, you give a very precise error
 indicating exactly which bracket was not match. If it does, you fall back
 to the same situation we have now.

 Assuming the lexer is sufficiently modular, this should be easy (at a
 guess), and not complicate any other part of the compiler.

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/2046#comment:3>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Wed Jan 16 07:40:21 2008
From: trac at galois.com (GHC)
Date: Wed Jan 16 07:33:57 2008
Subject: [GHC] #2040: GADT regression
In-Reply-To: <044.1338e8edb0c35965ed9c7ce0ba7c6cb7@localhost>
References: <044.1338e8edb0c35965ed9c7ce0ba7c6cb7@localhost>
Message-ID: <053.e8d9ec9f828738b3f921d826b0df341a@localhost>

#2040: GADT regression
-------------------------------------+--------------------------------------
 Reporter:  guest                    |          Owner:  chak       
     Type:  bug                      |         Status:  new        
 Priority:  normal                   |      Milestone:  6.10 branch
Component:  Compiler (Type checker)  |        Version:  6.8.2      
 Severity:  normal                   |     Resolution:             
 Keywords:  gadt                     |     Difficulty:  Unknown    
 Testcase:                           |   Architecture:  Unknown    
       Os:  Unknown                  |  
-------------------------------------+--------------------------------------
Changes (by simonpj):

  * owner:  => chak
  * difficulty:  => Unknown
  * milestone:  => 6.10 branch

Comment:

 Thanks for a good report.

 Having looked at the code, I think it's quite surprising that 6.8.1 worked
 at all.  Just for the record (I don't expect users to understand this
 bit), the problem is this.  Here's a smaller version of the code,
 decorated with constraints:
 {{{
 foo2 :: W (S ()) -> W (S ()) -> ()
 foo2 (W (_ :: W a1))    -- C a1 b1, S () ~ S b1
      (W (_ :: W a2))    -- C a2 b2, S () ~ S b2
  =
   case {-# Needs C a1 (S ()) #-}
        proof :: Teq a1 (S ()) of
     Teq -> {-# Provides a1~S () #-}
               {-# Needs: C a2 (S ()) #-}
               (proof :: Teq a2 (S ()))
                            `seq` ()
 }}}
 The inner use of `proof` gives rise to a constraint `(C a2 (S ()))`.  This
 is wrapped in an implication constraint because of the enclosing case
 expression.  But the `tci_reft` of that implication constraint does not
 include the type refinements from the enclosing pattern matches.  So when
 `reduceImplication` makes that the current type refinement, we're missing
 the outer refinements.

 This is a clear bug in 6.8.2, since there is no use of type functions.  It
 would in principle be fixable in 6.8.3, but it's not completely trivial to
 do, so I'm disinclined to attempt it since we are rejigging the whole
 machinery for the HEAD.

 Meanwhile the HEAD falls over (which it should not) because the constraint
 simplifier is not deducing all the things it should.  This is Manuel's
 pigeon at the moment, so I'm assigning the bug to him.  In due course this
 program should join the test suite.

 Simon

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/2040#comment:1>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Wed Jan 16 07:46:18 2008
From: trac at galois.com (GHC)
Date: Wed Jan 16 07:39:34 2008
Subject: [GHC] #1012: ghc panic with mutually recursive modules and
 template haskell
In-Reply-To: <044.e3ec0fd0938800cc6a7ce608eb8687c2@localhost>
References: <044.e3ec0fd0938800cc6a7ce608eb8687c2@localhost>
Message-ID: <053.a0bf398e1ca2e16ff0f0490848a658d7@localhost>

#1012: ghc panic with mutually recursive modules and template haskell
------------------------------+---------------------------------------------
 Reporter:  guest             |          Owner:             
     Type:  bug               |         Status:  reopened   
 Priority:  normal            |      Milestone:  6.10 branch
Component:  Template Haskell  |        Version:  6.8.2      
 Severity:  normal            |     Resolution:             
 Keywords:                    |     Difficulty:  Unknown    
 Testcase:  TH_import_loop    |   Architecture:  Multiple   
       Os:  Multiple          |  
------------------------------+---------------------------------------------
Changes (by simonpj):

  * milestone:  _|_ => 6.10 branch

Comment:

 Fair enough. I have taken a little look at this, based on fons's
 suggestion "``every module M that depends on a module C in a cycle, but is
 not a member of that cycle, should have an implicit dependency on each of
 the modules C1.. Cn in the cycle.``". Yes, I think that would not be too
 hard to do.  There are two places to think about:

  * `ghc --make`: When deciding the up-sweep order, first do a SCC analysis
 finding strongly connected components of modules, and top-sort those
 components.  Then linearise each component. That gives a linear order that
 respects fons's suggestion.

  * `ghc -M`: similar story, but less neat.  We have to emit lots of extra
 dependencies in the `makefile`, so that M depends on C1..Cn.

 Not very hard, but more than an hours work.  Let's do it for 6.10.

 Simon

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/1012#comment:14>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Wed Jan 16 13:02:15 2008
From: trac at galois.com (GHC)
Date: Wed Jan 16 12:55:44 2008
Subject: [GHC] #2021: let ghc find framework header files and link with
 frameworks located in $HOME/Library/Frameworks
In-Reply-To: <045.f644abcffe54149a52e1b357b6ba7b01@localhost>
References: <045.f644abcffe54149a52e1b357b6ba7b01@localhost>
Message-ID: <054.9165f80ff9e8abf3eb558680ff311c09@localhost>

#2021: let ghc find framework header files and link with frameworks located in
$HOME/Library/Frameworks
-----------------------------+----------------------------------------------
 Reporter:  maeder           |          Owner:             
     Type:  feature request  |         Status:  new        
 Priority:  normal           |      Milestone:  6.10 branch
Component:  Compiler         |        Version:  6.8.2      
 Severity:  normal           |     Resolution:             
 Keywords:                   |     Difficulty:  Easy (1 hr)
 Testcase:                   |   Architecture:  Multiple   
       Os:  MacOS X          |  
-----------------------------+----------------------------------------------
Comment (by judah):

 Replying to [comment:11 maeder]:
 > Check at least in my (recently attached) version that passes -F properly
 to gcc and ld for ghc-6.8.3, I've removed checking the home directory, so
 the above objections are no longer valid.

 If I understand correctly, that latest version fixes bug #1975 (see that
 ticket for a test case).  For organization's sake, can we keep this ticket
 about adding `$HOME/Library/Frameworks`, and use #1975 to track that bug
 and its fixes?

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/2021#comment:13>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Wed Jan 16 14:03:46 2008
From: trac at galois.com (GHC)
Date: Wed Jan 16 13:57:14 2008
Subject: [GHC] #2021: let ghc find framework header files and link with
 frameworks located in $HOME/Library/Frameworks
In-Reply-To: <045.f644abcffe54149a52e1b357b6ba7b01@localhost>
References: <045.f644abcffe54149a52e1b357b6ba7b01@localhost>
Message-ID: <054.75d432430a53a49d9e0d8fe5f025e705@localhost>

#2021: let ghc find framework header files and link with frameworks located in
$HOME/Library/Frameworks
-----------------------------+----------------------------------------------
 Reporter:  maeder           |          Owner:             
     Type:  feature request  |         Status:  new        
 Priority:  normal           |      Milestone:  6.10 branch
Component:  Compiler         |        Version:  6.8.2      
 Severity:  normal           |     Resolution:             
 Keywords:                   |     Difficulty:  Easy (1 hr)
 Testcase:                   |   Architecture:  Multiple   
       Os:  MacOS X          |  
-----------------------------+----------------------------------------------
Comment (by maeder):

 I've missed #1975, so go ahead and fix it

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/2021#comment:14>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Wed Jan 16 17:33:21 2008
From: trac at galois.com (GHC)
Date: Wed Jan 16 17:26:37 2008
Subject: [GHC] #1826: unable to list source for <exception thrown>
 should never occur
In-Reply-To: <044.f94ec6280873c17dbdd2473c81e3b4a3@localhost>
References: <044.f94ec6280873c17dbdd2473c81e3b4a3@localhost>
Message-ID: <053.f80dc19539fcfcc914dd1dc2a794e126@localhost>

#1826: unable to list source for <exception thrown> should never occur
-----------------------------+----------------------------------------------
 Reporter:  guest            |          Owner:             
     Type:  feature request  |         Status:  new        
 Priority:  normal           |      Milestone:  6.8.3      
Component:  GHCi             |        Version:  6.8.1      
 Severity:  normal           |     Resolution:             
 Keywords:                   |     Difficulty:  Easy (1 hr)
 Testcase:                   |   Architecture:  Multiple   
       Os:  Multiple         |  
-----------------------------+----------------------------------------------
Comment (by igloo):

 I've improved the error, but I'm not sure how to tell if we are running
 with `:trace`; is there an easy way?

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/1826#comment:5>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Wed Jan 16 17:55:46 2008
From: trac at galois.com (GHC)
Date: Wed Jan 16 17:48:59 2008
Subject: [GHC] #2048: Add split and splitWith to Data.List
Message-ID: <045.7155003e42a360739f457ed29bf408d6@localhost>

#2048: Add split and splitWith to Data.List
-------------------------+--------------------------------------------------
    Reporter:  twanvl    |       Owner:                
        Type:  proposal  |      Status:  new           
    Priority:  normal    |   Component:  libraries/base
     Version:  6.8.2     |    Severity:  normal        
    Keywords:            |    Testcase:                
Architecture:  Unknown   |          Os:  Unknown       
-------------------------+--------------------------------------------------
 An often requested function is 'split', to split a list into parts
 delimited by some separator. ByteString has the functions split and
 splitWith for this purpose. I propose we add equivalents to Data.List.

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/2048>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Wed Jan 16 20:18:40 2008
From: trac at galois.com (GHC)
Date: Wed Jan 16 20:11:52 2008
Subject: [GHC] #2049: GHCi doesn't fully load previously broken modules
Message-ID: <042.e75e264362dd101a1f793da2344243d7@localhost>

#2049: GHCi doesn't fully load previously broken modules
------------------------+---------------------------------------------------
    Reporter:  ajd      |       Owner:         
        Type:  bug      |      Status:  new    
    Priority:  normal   |   Component:  GHCi   
     Version:  6.8.2    |    Severity:  normal 
    Keywords:           |    Testcase:         
Architecture:  Unknown  |          Os:  Unknown
------------------------+---------------------------------------------------
 Scenario:

 I have a project with three modules: Mod1, Mod2 and Mod3. Mod3 calls an
 undefined function and so shouldn't load. I call GHCi as

 ghci Mod3.hs

 The output looks like this:

  GHCi, version 6.8.2: http://www.haskell.org/ghc/  :? for help
  Loading package base ... linking ... done.
  [1 of 3] Compiling Mod1             ( Mod1.hs, interpreted )
  [2 of 3] Compiling Mod2             ( Mod2.hs, interpreted )
  [3 of 3] Compiling Mod3             ( Mod3.hs, interpreted )

  Mod3.hs:6:6: Not in scope: `foo'

  Mod3.hs:6:12: Not in scope: `barf'
  Failed, modules loaded: Mod2, Mod1.

 The problem comes when I edit the file using GHCi's :e command and then
 reload with :r. The output looks like this (which is strange in itself,
 because the modules are listed in the wrong order):

  *Mod2> :r
  [3 of 3] Compiling Mod3             ( Mod3.hs, interpreted )
  Ok, modules loaded: Mod2, Mod3, Mod1.

 The problem is this: when I call a function from Mod3 from the GHCi
 toplevel, I get a "not in scope" error. I can call the function as
 "Mod3.<function name>" but "Mod3" does not show up in GHCi's tab
 completion. I don't believe that this is the correct behavior.

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/2049>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Wed Jan 16 20:20:50 2008
From: trac at galois.com (GHC)
Date: Wed Jan 16 20:14:01 2008
Subject: [GHC] #2050: GHCi should keep a persistent history file
Message-ID: <042.e949aba920f4285accf4bf1e428e3654@localhost>

#2050: GHCi should keep a persistent history file
--------------------------------+-------------------------------------------
    Reporter:  ajd              |       Owner:         
        Type:  feature request  |      Status:  new    
    Priority:  normal           |   Component:  GHCi   
     Version:  6.8.2            |    Severity:  normal 
    Keywords:                   |    Testcase:         
Architecture:  Unknown          |          Os:  Unknown
--------------------------------+-------------------------------------------
 It would be nice if GHCi kept a persistent history of commands like bash
 does. This would be especially useful in testing: if one is trying to get
 a certain command to work, and the command is at all complicated, it is
 annoying to have to copy and paste or retype the command every time you
 want to see if the function works.

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/2050>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Wed Jan 16 20:23:31 2008
From: trac at galois.com (GHC)
Date: Wed Jan 16 20:16:43 2008
Subject: [GHC] #2050: GHCi should keep a persistent history file
In-Reply-To: <042.e949aba920f4285accf4bf1e428e3654@localhost>
References: <042.e949aba920f4285accf4bf1e428e3654@localhost>
Message-ID: <051.b6215ce11d645f53d44860c3464e3e7b@localhost>

#2050: GHCi should keep a persistent history file
--------------------------------+-------------------------------------------
    Reporter:  ajd              |        Owner:         
        Type:  feature request  |       Status:  new    
    Priority:  normal           |    Milestone:         
   Component:  GHCi             |      Version:  6.8.2  
    Severity:  normal           |   Resolution:         
    Keywords:                   |     Testcase:         
Architecture:  Unknown          |           Os:  Unknown
--------------------------------+-------------------------------------------
Changes (by Isaac Dupree):

 * cc: id@isaac.cedarswampstudios.org (added)

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/2050#comment:1>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Wed Jan 16 21:08:05 2008
From: trac at galois.com (GHC)
Date: Wed Jan 16 21:01:18 2008
Subject: [GHC] #2050: GHCi should keep a persistent history file
In-Reply-To: <042.e949aba920f4285accf4bf1e428e3654@localhost>
References: <042.e949aba920f4285accf4bf1e428e3654@localhost>
Message-ID: <051.b7785ab9668d6ab7aec690c5eabb08f7@localhost>

#2050: GHCi should keep a persistent history file
--------------------------------+-------------------------------------------
    Reporter:  ajd              |        Owner:         
        Type:  feature request  |       Status:  new    
    Priority:  normal           |    Milestone:         
   Component:  GHCi             |      Version:  6.8.2  
    Severity:  normal           |   Resolution:         
    Keywords:                   |     Testcase:         
Architecture:  Unknown          |           Os:  Unknown
--------------------------------+-------------------------------------------
Comment (by judah):

 I have also often wished for this.  The header `<readline/history.h>`
 provides the functions `read_history` and `write_history` which are also
 present in editline.  This task will be easy to implement if we add those
 to the readline and editline packages.  (Although, a pure Haskell
 implementation would probably also be pretty easy to write.)

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/2050#comment:2>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Wed Jan 16 21:13:18 2008
From: trac at galois.com (GHC)
Date: Wed Jan 16 21:06:30 2008
Subject: [GHC] #2050: GHCi should keep a persistent history file
In-Reply-To: <042.e949aba920f4285accf4bf1e428e3654@localhost>
References: <042.e949aba920f4285accf4bf1e428e3654@localhost>
Message-ID: <051.f799cc31b24cc9a87b6c61cdf5786438@localhost>

#2050: GHCi should keep a persistent history file
--------------------------------+-------------------------------------------
    Reporter:  ajd              |        Owner:  ajd    
        Type:  feature request  |       Status:  new    
    Priority:  normal           |    Milestone:         
   Component:  GHCi             |      Version:  6.8.2  
    Severity:  normal           |   Resolution:         
    Keywords:                   |     Testcase:         
Architecture:  Unknown          |           Os:  Unknown
--------------------------------+-------------------------------------------
Changes (by ajd):

  * owner:  => ajd

Comment:

 I think System.Posix.Readline already has a binding to those functions via
 the addHistory function. I just finished writing a simple implementation;
 I'll post a patch when it builds and tests.

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/2050#comment:3>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Thu Jan 17 04:03:29 2008
From: trac at galois.com (GHC)
Date: Thu Jan 17 03:56:44 2008
Subject: [GHC] #1826: unable to list source for <exception thrown>
 should never occur
In-Reply-To: <044.f94ec6280873c17dbdd2473c81e3b4a3@localhost>
References: <044.f94ec6280873c17dbdd2473c81e3b4a3@localhost>
Message-ID: <053.8bce37ee7b92c0b82501b4fe0f8bf025@localhost>

#1826: unable to list source for <exception thrown> should never occur
-----------------------------+----------------------------------------------
 Reporter:  guest            |          Owner:             
     Type:  feature request  |         Status:  new        
 Priority:  normal           |      Milestone:  6.8.3      
Component:  GHCi             |        Version:  6.8.1      
 Severity:  normal           |     Resolution:             
 Keywords:                   |     Difficulty:  Easy (1 hr)
 Testcase:                   |   Architecture:  Multiple   
       Os:  Multiple         |  
-----------------------------+----------------------------------------------
Comment (by simonmar):

 Perhaps by checking whether the history is empty?

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/1826#comment:6>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Thu Jan 17 10:24:36 2008
From: trac at galois.com (GHC)
Date: Thu Jan 17 10:24:39 2008
Subject: [GHC] #2051: -hide-package doesn't allow hiding uninstalled package
Message-ID: <053.fd935e025acfb737c5e2348105b5b118@localhost>

#2051: -hide-package doesn't allow hiding uninstalled package
--------------------------------+-------------------------------------------
    Reporter:  MagnusTherning   |       Owner:          
        Type:  feature request  |      Status:  new     
    Priority:  normal           |   Component:  Compiler
     Version:  6.8.2            |    Severity:  trivial 
    Keywords:                   |    Testcase:          
Architecture:  x86_64 (amd64)   |          Os:  Linux   
--------------------------------+-------------------------------------------
 The following behaviour seems a bit too strict:

 % ghc-pkg list dataenc[[BR]]
 /usr/lib/ghc-6.8.2/package.conf:[[BR]]
 % ghc --make -hide-package dataenc -isrc UT.hs[[BR]]
 ghc-6.8.2 : unknown package: dataenc

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/2051>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Thu Jan 17 10:37:10 2008
From: trac at galois.com (GHC)
Date: Thu Jan 17 10:37:15 2008
Subject: [GHC] #2024: Template Haskell doesn't work well with Lexically
 Scoped Type Variables
In-Reply-To: <043.ad4f76fd8928e0aaf2d125b91ef52e82@localhost>
References: <043.ad4f76fd8928e0aaf2d125b91ef52e82@localhost>
Message-ID: <052.7d58665726ac3f6cae4c0d357ec2605b@localhost>

#2024: Template Haskell doesn't work well with Lexically Scoped Type Variables
------------------------------+---------------------------------------------
 Reporter:  fons              |          Owner:  igloo  
     Type:  merge             |         Status:  new    
 Priority:  normal            |      Milestone:         
Component:  Template Haskell  |        Version:  6.8.2  
 Severity:  normal            |     Resolution:         
 Keywords:                    |     Difficulty:  Unknown
 Testcase:  TH_scopedTvs      |   Architecture:  Unknown
       Os:  Unknown           |  
------------------------------+---------------------------------------------
Changes (by simonpj):

  * testcase:  => TH_scopedTvs
  * owner:  => igloo
  * type:  bug => merge

Comment:

 Thanks.  Fixed by
 {{{
 Wed Jan 16 15:16:12 GMT 2008  simonpj@microsoft.com
   * Complain sensibly if you try to use scoped type variables in Template
 Haskell
 }}}

 Ian: pls merge this across.

 Simon

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/2024#comment:1>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Thu Jan 17 17:04:00 2008
From: trac at galois.com (GHC)
Date: Thu Jan 17 17:04:03 2008
Subject: [GHC] #1389: readline checks in configure.ac can probably be
 removed
In-Reply-To: <047.d6f3a7067b92adffac648351296fa875@localhost>
References: <047.d6f3a7067b92adffac648351296fa875@localhost>
Message-ID: <056.e3aa11c64bff4e47accef94db9a5c0cd@localhost>

#1389: readline checks in configure.ac can probably be removed
--------------------------+-------------------------------------------------
 Reporter:  simonmar      |          Owner:             
     Type:  task          |         Status:  new        
 Priority:  normal        |      Milestone:  6.10 branch
Component:  Build System  |        Version:  6.7        
 Severity:  normal        |     Resolution:             
 Keywords:                |     Difficulty:  Easy (1 hr)
 Testcase:                |   Architecture:  Unknown    
       Os:  Unknown       |  
--------------------------+-------------------------------------------------
Comment (by judah):

 I don't know much about bootstrapping.mk; can these checks be removed now?
 Doing so will make it simpler to build ghc against editline.

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/1389#comment:2>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Thu Jan 17 17:58:35 2008
From: trac at galois.com (GHC)
Date: Thu Jan 17 17:58:44 2008
Subject: [GHC] #789: BCOs can only have 64k instructions
In-Reply-To: <046.dd5b1d4a62c636e51e886c3d53bcf8d3@localhost>
References: <046.dd5b1d4a62c636e51e886c3d53bcf8d3@localhost>
Message-ID: <055.3f38e8b5892f369240ee0aa1cb321c2c@localhost>

#789: BCOs can only have 64k instructions
---------------------+------------------------------------------------------
 Reporter:  simonpj  |          Owner:         
     Type:  bug      |         Status:  new    
 Priority:  normal   |      Milestone:  _|_    
Component:  GHCi     |        Version:  6.8.2  
 Severity:  normal   |     Resolution:         
 Keywords:  BCO      |     Difficulty:  Unknown
 Testcase:           |   Architecture:  x86    
       Os:  Linux    |  
---------------------+------------------------------------------------------
Changes (by jsnx):

  * keywords:  => BCO
  * version:  6.4.2 => 6.8.2
  * os:  Unknown => Linux
  * architecture:  Unknown => x86

Comment:

 I try to build a Chinese dictionary with ~10000 entries in it, as a

     Data.Map.Map Char [([Char], [Char])]

 and when I try to load this module in GHCi, I get

     ghc-6.8.2: panic! (the 'impossible' happened)
       (GHC version 6.8.2 for i386-unknown-linux):
             linkBCO: >= 64k insns in BCO

 That's okay -- I guess I could just put the dictionary in SQLite -- but
 it'd be cool if I could make huge Haskell data structures statically or
 something.

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/789#comment:9>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Thu Jan 17 18:13:44 2008
From: trac at galois.com (GHC)
Date: Thu Jan 17 18:13:47 2008
Subject: [GHC] #789: BCOs can only have 64k instructions
In-Reply-To: <046.dd5b1d4a62c636e51e886c3d53bcf8d3@localhost>
References: <046.dd5b1d4a62c636e51e886c3d53bcf8d3@localhost>
Message-ID: <055.1dfc39a835060e52a98a791ba99b4253@localhost>

#789: BCOs can only have 64k instructions
---------------------+------------------------------------------------------
 Reporter:  simonpj  |          Owner:         
     Type:  bug      |         Status:  new    
 Priority:  normal   |      Milestone:  _|_    
Component:  GHCi     |        Version:  6.8.2  
 Severity:  normal   |     Resolution:         
 Keywords:  BCO      |     Difficulty:  Unknown
 Testcase:           |   Architecture:  x86    
       Os:  Linux    |  
---------------------+------------------------------------------------------
Comment (by dons):

 You'll get further here if you use a Map of ByteStrings. The bytestring
 literals will be unpacked at compile time, and the linker should then be
 able to handle them better.

 Using overloaded strings, you can even avoid having to insert 'pack' to
 build the bytestrings.
 see for example, this large static data, full of bytestrings,

 http://code.haskell.org/~dons/code/pcre-light/tests/Unit.hs

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/789#comment:10>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Thu Jan 17 18:35:37 2008
From: trac at galois.com (GHC)
Date: Thu Jan 17 18:35:47 2008
Subject: [GHC] #2052: hpc ignores files containing LINES pragmas that refer
 to .hsc files
Message-ID: <043.13a31077ae5ebb133355743a92fc5086@localhost>

#2052: hpc ignores files containing LINES pragmas that refer to .hsc files
----------------------------+-----------------------------------------------
    Reporter:  dons         |       Owner:  andy@galois.com
        Type:  bug          |      Status:  new            
    Priority:  normal       |   Component:  Code Coverage  
     Version:  6.8.2        |    Severity:  normal         
    Keywords:  hpc, hsc2hs  |    Testcase:                 
Architecture:  Multiple     |          Os:  Multiple       
----------------------------+-----------------------------------------------
 ghc -hpc generates no ticks for files containing LINE pragmas that point
 back to .hsc files. Removing the LINE pragmas, and ticks are generated.

 An example. This simple .hsc file:

 {{{
 main = print "hello, world"
 }}}

 Generates this A.hs file:

 {{{
 {-# LINE 1 "A.hsc" #-}
 main = print "hello, world"
 {-# LINE 2 "A.hsc" #-}
 }}}

 Compiling this with -fhpc, we see no ticks produced:

 {{{
 { AbsBinds [] [] [Main.main <= [] main_aif]

     Main.main :: GHC.IOBase.IO ()
     []
     { print_aie = System.IO.print @ [GHC.Base.Char] $dShow_ail
       main_aif = print_aie "hello, world" }
   :Main.main = GHC.TopHandler.runMainIO @ () Main.main
   $dShow_ail = GHC.Show.$f21 @ GHC.Base.Char $dShow_aiW
   $dShow_aiW = GHC.Show.$f18 }
 }}}

 Run this, and get the hpc report:

 {{{
 $ ./a.out
 "hello, world"

 $ hpc report a.out.tix
 100% expressions used (0/0)
 100% boolean coverage (0/0)
 }}}

 0/0 declarations.

 However, an identical file, without LINE pragmas, goes through just fine:

 {{{
 $ ghc -fhpc B.hs -ddump-hpc
 { AbsBinds [] [] [Main.main <= [] main_aif]
     Main.main :: GHC.IOBase.IO ()
     []
     { print_aie = System.IO.print @ [GHC.Base.Char] $dShow_ail
       -- tick id = (2, [])
       main_aif = tick<1>(print_aie (tick<0>("got you"))) }
   :Main.main = GHC.TopHandler.runMainIO @ () Main.main
   $dShow_ail = GHC.Show.$f21 @ GHC.Base.Char $dShow_aiW
   $dShow_aiW = GHC.Show.$f18 }
 }}}

 And the result has valid hpc .tix

 {{{
 $ hpc report a.out.tix
 100% expressions used (2/2)
 100% boolean coverage (0/0)
 }}}

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/2052>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Fri Jan 18 04:59:50 2008
From: trac at galois.com (GHC)
Date: Fri Jan 18 04:59:59 2008
Subject: [GHC] #1798: add better framework support to ghc
In-Reply-To: <044.b5679d7d83ed0889a808e90ca27e79a2@localhost>
References: <044.b5679d7d83ed0889a808e90ca27e79a2@localhost>
Message-ID: <053.72af6a9c1578ac369a60237593a2c716@localhost>

#1798: add better framework support to ghc
-----------------------------+----------------------------------------------
 Reporter:  guest            |          Owner:             
     Type:  feature request  |         Status:  closed     
 Priority:  normal           |      Milestone:  6.10 branch
Component:  Compiler         |        Version:  6.6.1      
 Severity:  normal           |     Resolution:  duplicate  
 Keywords:                   |     Difficulty:  Unknown    
 Testcase:                   |   Architecture:  Multiple   
       Os:  MacOS X          |  
-----------------------------+----------------------------------------------
Changes (by maeder):

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

Comment:

 let's discuss this further in #2021

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/1798#comment:8>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Fri Jan 18 05:04:06 2008
From: trac at galois.com (GHC)
Date: Fri Jan 18 05:04:10 2008
Subject: [GHC] #1395: let ./configure check for a GNUreadline framework
In-Reply-To: <052.068bc0f583c08a182f51a06ad4864715@localhost>
References: <052.068bc0f583c08a182f51a06ad4864715@localhost>
Message-ID: <061.8139af16cb56f4d2827dd9c393d89fa0@localhost>

#1395: let ./configure check for a GNUreadline framework
-----------------------------+----------------------------------------------
 Reporter:  maeder@tzi.de    |          Owner:             
     Type:  feature request  |         Status:  closed     
 Priority:  normal           |      Milestone:  6.8 branch 
Component:  Build System     |        Version:  6.8        
 Severity:  normal           |     Resolution:  fixed      
 Keywords:                   |     Difficulty:  Easy (1 hr)
 Testcase:                   |   Architecture:  Multiple   
       Os:  MacOS X          |  
-----------------------------+----------------------------------------------
Changes (by maeder):

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

Comment:

 ./configure checks for the GNUreadline framework so let's close this
 ticket
  (changes for frameworks in home dirs can be discussed elsewhere)

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/1395#comment:30>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Fri Jan 18 05:30:45 2008
From: trac at galois.com (GHC)
Date: Fri Jan 18 05:31:00 2008
Subject: [GHC] #2021: let ghc find framework header files and link with
 frameworks located in $HOME/Library/Frameworks
In-Reply-To: <045.f644abcffe54149a52e1b357b6ba7b01@localhost>
References: <045.f644abcffe54149a52e1b357b6ba7b01@localhost>
Message-ID: <054.46bb4f9c1f32b54ce8ea86c2fcafa4e5@localhost>

#2021: let ghc find framework header files and link with frameworks located in
$HOME/Library/Frameworks
-----------------------------+----------------------------------------------
 Reporter:  maeder           |          Owner:             
     Type:  feature request  |         Status:  new        
 Priority:  normal           |      Milestone:  6.10 branch
Component:  Compiler         |        Version:  6.8.2      
 Severity:  normal           |     Resolution:             
 Keywords:                   |     Difficulty:  Easy (1 hr)
 Testcase:                   |   Architecture:  Multiple   
       Os:  MacOS X          |  
-----------------------------+----------------------------------------------
Comment (by maeder):

 Summary:

 1. Binaries linked against frameworks always find (matching) frameworks in
 a user home directory since this is a feature of mac's dynamic linker.

 2. Once #1975 is committed ghc should find frameworks for compiling (i.e.
 inclusion of header files) and linking user code in a user home directory
 by passing the option "`-framework-path $HOME/Library/Frameworks`"

 3. To spare the above `-framework-path` option `DriverPipeline.hs` could
 be extended or the final ghc shell script generated by
 `driver/ghc/Makefile`

 4. In order to compile/bootstrap ghc from sources using local frameworks
 further additions to `configure.ac`, `readline/configure.ac` and
 `libraries/Makefile` (or to cabal) are necessary (see #1395):

 `-F$HOME/Library/Frameworks` need to be added to the configure files

 `--hsc2hs-options="-C -F$(HOME)/Library/Frameworks" should go into
 `libraries/Makefile`

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/2021#comment:15>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Fri Jan 18 09:40:17 2008
From: trac at galois.com (GHC)
Date: Fri Jan 18 09:40:16 2008
Subject: [GHC] #1839: need ghc-pkg dump feature
In-Reply-To: <045.e765af751a0d91f5b4a56c8391184f46@localhost>
References: <045.e765af751a0d91f5b4a56c8391184f46@localhost>
Message-ID: <054.a3c02b2ae73b3bce3f1f4f0d49140d91@localhost>

#1839: need ghc-pkg dump feature
-----------------------------+----------------------------------------------
 Reporter:  duncan           |          Owner:             
     Type:  feature request  |         Status:  new        
 Priority:  normal           |      Milestone:  6.10 branch
Component:  Compiler         |        Version:  6.8.1      
 Severity:  normal           |     Resolution:             
 Keywords:                   |     Difficulty:  Unknown    
 Testcase:                   |   Architecture:  Unknown    
       Os:  Unknown          |  
-----------------------------+----------------------------------------------
Comment (by duncan):

 I know we've made changes to ghc-pkg in the HEAD branch. I'd still very
 much like to see a simple dump feature included in ghc-pkg in time for
 ghc-6.8.3.

 Cabal does not need any complex query interface but it does at a minimum
 need to know what versions of what dependencies each existing package
 uses. This is necessary to avoid or at least detect problems where we
 build a package that uses two other packages that were built against
 different versions of another common package.

 The most common example in the wild at the moment is people adding
 bytestring-0.9.0.4 in addition to the bytestring-0.9.0.1 that came with
 ghc-6.8.2 and then half their packages are built against one version and
 half against the other and when we try to use packages built against
 different versions we get a type error about
 {{{bytestring-0.9.0.1:Data.ByteString.ByteString}}} not being the same as
 {{{bytestring-0.9.0.4:Data.ByteString.ByteString}}}.

 Cabal could and should detect this situation, and cabal-install should
 plan around it in its dependency resolution algorithm. However in both
 cases we require the dependency information of the existing installed
 packages.

 Not that many people are triping up over this just yet, but I think with
 more hackage automation we will. Especially with automated hackage QA
 where we want to build every version of every package to see if it works.

 As I say, I think we want this on the 6.8.3 timescale, rather than having
 to wait for 6.10. If this 'bulk' feature is going to go in for 6.8.3 then
 fine, otherwise I suggest the simple 'dump' command that I suggested
 originally.

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/1839#comment:7>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Fri Jan 18 14:11:07 2008
From: trac at galois.com (GHC)
Date: Fri Jan 18 14:11:07 2008
Subject: [GHC] #1839: need ghc-pkg dump feature
In-Reply-To: <045.e765af751a0d91f5b4a56c8391184f46@localhost>
References: <045.e765af751a0d91f5b4a56c8391184f46@localhost>
Message-ID: <054.e3456a8bdd0fb779ec00bef82fd05e89@localhost>

#1839: need ghc-pkg dump feature
-----------------------------+----------------------------------------------
 Reporter:  duncan           |          Owner:             
     Type:  feature request  |         Status:  new        
 Priority:  normal           |      Milestone:  6.10 branch
Component:  Compiler         |        Version:  6.8.1      
 Severity:  normal           |     Resolution:             
 Keywords:                   |     Difficulty:  Unknown    
 Testcase:                   |   Architecture:  Unknown    
       Os:  Unknown          |  
-----------------------------+----------------------------------------------
Comment (by claus):

 Replying to [comment:7 duncan]:
 > I know we've made changes to ghc-pkg in the HEAD branch. I'd still very
 much like to see a simple dump feature included in ghc-pkg in time for
 ghc-6.8.3.
 >
 > As I say, I think we want this on the 6.8.3 timescale, rather than
 having to wait for 6.10. If this 'bulk' feature is going to go in for
 6.8.3 then fine, otherwise I suggest the simple 'dump' command that I
 suggested originally.

 we had some more discussion in early december, and i sent my final version
 of the patch to cvs-ghc on 03/12/,

 http://www.haskell.org/pipermail/cvs-ghc/2007-December/040020.html

 simon has since confirmed that the patch looks fine, but could do with
 some refinements of configuration, for mingw location detection, and
 perhaps without the provision for restoring globbing.

 http://www.haskell.org/pipermail/cvs-ghc/2008-January/040407.html

 as i said in december, i leave those tweaks and decisions to the folks at
 ghc hq - as far as myself and functionality were concerned, the patch is
 done!-) there shouldn't be any need for a separate dump feature to get
 something soon.

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/1839#comment:8>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Fri Jan 18 15:09:16 2008
From: trac at galois.com (GHC)
Date: Fri Jan 18 15:09:21 2008
Subject: [GHC] #2038: System.Posix.Resource.setResourceLimit gives
 "setResourceLimit: invalid argument (Invalid argument)"
In-Reply-To: <045.9f2f177f681138fbf7d90d1273238fd5@localhost>
References: <045.9f2f177f681138fbf7d90d1273238fd5@localhost>
Message-ID: <054.4728c277136f828d46d2ca6385127693@localhost>

#2038: System.Posix.Resource.setResourceLimit gives "setResourceLimit: invalid
argument (Invalid argument)"
--------------------------------------+-------------------------------------
    Reporter:  slyfox                 |        Owner:       
        Type:  bug                    |       Status:  new  
    Priority:  normal                 |    Milestone:       
   Component:  Compiler               |      Version:  6.8.2
    Severity:  major                  |   Resolution:       
    Keywords:  regression, ffi, unix  |     Testcase:       
Architecture:  x86                    |           Os:  Linux
--------------------------------------+-------------------------------------
Changes (by slyfox):

  * version:  6.8.1 => 6.8.2

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/2038#comment:1>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Sat Jan 19 01:23:24 2008
From: trac at galois.com (GHC)
Date: Sat Jan 19 01:23:23 2008
Subject: [GHC] #2050: GHCi should keep a persistent history file
In-Reply-To: <042.e949aba920f4285accf4bf1e428e3654@localhost>
References: <042.e949aba920f4285accf4bf1e428e3654@localhost>
Message-ID: <051.4f6e73bb7b29d49fb07961f0fe60dafa@localhost>

#2050: GHCi should keep a persistent history file
--------------------------------+-------------------------------------------
    Reporter:  ajd              |        Owner:         
        Type:  feature request  |       Status:  new    
    Priority:  normal           |    Milestone:         
   Component:  GHCi             |      Version:  6.8.2  
    Severity:  normal           |   Resolution:         
    Keywords:                   |     Testcase:         
Architecture:  Unknown          |           Os:  Unknown
--------------------------------+-------------------------------------------
Changes (by ajd):

  * owner:  ajd =>

Comment:

 Judah, you were right, it was much easier to write the bindings for
 read_history and write_history. I wrote the bindings (basically a copy and
 paste from the add_history binding). I also wrote a simple patch to
 InteractiveUI.hs to implement the actually history tracking that seems to
 work correctly, I don't know if we need to check that the file exists or
 anything.

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/2050#comment:4>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From bugs at darcs.net  Sat Jan 19 01:39:33 2008
From: bugs at darcs.net (Mark Stosberg)
Date: Sat Jan 19 01:36:22 2008
Subject: [issue168] Internal ghc runtime error when annotating
Message-ID: <1200724773.27.0.684226901981.issue168@darcs.net>



I'm marking this as "wont-fix". Besides being "not-our-bug", we don't know the
version of the GHC compiler that had the bug, and there's a decent chance the
issue was fixed in a new GHC release, and no one else has commented on this
ticket in a year and a half. 

Please re-open if the issue is present with GHC 6.8.

----------
nosy: +beschmi, kowey, markstos
status: chatting -> wont-fix

__________________________________
Darcs bug tracker <bugs@darcs.net>
<http://bugs.darcs.net/issue168>
__________________________________
From trac at galois.com  Sat Jan 19 01:38:55 2008
From: trac at galois.com (GHC)
Date: Sat Jan 19 01:38:51 2008
Subject: [GHC] #2051: -hide-package doesn't allow hiding uninstalled
 package
In-Reply-To: <053.fd935e025acfb737c5e2348105b5b118@localhost>
References: <053.fd935e025acfb737c5e2348105b5b118@localhost>
Message-ID: <062.930e497745ca9edcab9594186f34131d@localhost>

#2051: -hide-package doesn't allow hiding uninstalled package
--------------------------------+-------------------------------------------
    Reporter:  MagnusTherning   |        Owner:       
        Type:  feature request  |       Status:  new  
    Priority:  normal           |    Milestone:       
   Component:  Compiler         |      Version:  6.8.2
    Severity:  trivial          |   Resolution:       
    Keywords:                   |     Testcase:       
Architecture:  x86_64 (amd64)   |           Os:  Linux
--------------------------------+-------------------------------------------
Comment (by ajd):

 I wrote a patch to "fix" this but I'm not sure it ought to be the correct
 behavior. According to the comments around the function in question,
 -ignore-package already has this behavior because it's supposed to be used
 as a just-in-case thing, they way you are trying to use -hide-package.
 Anyway, I'm attaching the patch and I'll leave it up to the powers that be
 to decide what to do about it.

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/2051#comment:1>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Sat Jan 19 02:03:54 2008
From: trac at galois.com (GHC)
Date: Sat Jan 19 02:03:51 2008
Subject: [GHC] #2053: Add read_history and write_history bindings to readline
Message-ID: <042.660e67c9ae82ef2f50c4766a74e43bc8@localhost>

#2053: Add read_history and write_history bindings to readline
-------------------------+--------------------------------------------------
    Reporter:  ajd       |       Owner:                   
        Type:  proposal  |      Status:  new              
    Priority:  normal    |   Component:  libraries (other)
     Version:  6.8.2     |    Severity:  normal           
    Keywords:            |    Testcase:                   
Architecture:  Unknown   |          Os:  Unknown          
-------------------------+--------------------------------------------------
 Add Haskell bindings for the GNU Readline functions read_history and
 write_history to the readline package. See #2050.

 Please send feedback to libraries@haskell.org by Saturday 26 January 2007.

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/2053>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Sat Jan 19 07:34:48 2008
From: trac at galois.com (GHC)
Date: Sat Jan 19 07:34:46 2008
Subject: [GHC] #2024: Template Haskell doesn't work well with Lexically
 Scoped Type Variables
In-Reply-To: <043.ad4f76fd8928e0aaf2d125b91ef52e82@localhost>
References: <043.ad4f76fd8928e0aaf2d125b91ef52e82@localhost>
Message-ID: <052.053410adbb1751ef1bb5a7e0ffe74fe3@localhost>

#2024: Template Haskell doesn't work well with Lexically Scoped Type Variables
------------------------------+---------------------------------------------
 Reporter:  fons              |          Owner:  igloo  
     Type:  merge             |         Status:  closed 
 Priority:  normal            |      Milestone:         
Component:  Template Haskell  |        Version:  6.8.2  
 Severity:  normal            |     Resolution:  fixed  
 Keywords:                    |     Difficulty:  Unknown
 Testcase:  TH_scopedTvs      |   Architecture:  Unknown
       Os:  Unknown           |  
------------------------------+---------------------------------------------
Changes (by igloo):

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

Comment:

 Merged

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/2024#comment:2>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Sat Jan 19 07:58:19 2008
From: trac at galois.com (GHC)
Date: Sat Jan 19 07:58:15 2008
Subject: [GHC] #2054: :history doesn't
Message-ID: <044.fb0075e819aa0a0bed0834f203038504@localhost>

#2054: :history doesn't
------------------------+---------------------------------------------------
    Reporter:  igloo    |       Owner:         
        Type:  bug      |      Status:  new    
    Priority:  normal   |   Milestone:  6.8.3  
   Component:  GHCi     |     Version:  6.8.2  
    Severity:  normal   |    Keywords:         
  Difficulty:  Unknown  |    Testcase:         
Architecture:  Unknown  |          Os:  Unknown
------------------------+---------------------------------------------------
 With this `q.hs`:
 {{{
 main :: IO ()
 main = error "foo"
 }}}
 if I `:trace main` then `:history` works:
 {{{
 $ ghci -v0 -fbreak-on-exception q.hs
 *Main> :trace main
 Stopped at <exception thrown>
 _exception :: e = GHC.IOBase.ErrorCall ('f' : _)
 [<exception thrown>] *Main> :history
 -1  : main (q.hs:3:7-17)
 <end of history>
 [<exception thrown>] *Main> :q
 }}}
 but if I first do just `main` first then it doesn't work:
 {{{
 $ ghci -v0 -fbreak-on-exception q.hs
 *Main> main
 Stopped at <exception thrown>
 _exception :: e = GHC.IOBase.ErrorCall ('f' : _)
 [<exception thrown>] *Main> :history
 Empty history. Perhaps you forgot to use :trace?
 [<exception thrown>] *Main> :trace main
 Stopped at <exception thrown>
 _exception :: e = GHC.IOBase.ErrorCall ('f' : _)
 ... [<exception thrown>] *Main> :history
 Empty history. Perhaps you forgot to use :trace?
 ... [<exception thrown>] *Main>
 }}}
 I assume that this isn't intentional, but confusion in which direction the
 history stack grows or something.

 This happens in 6.8.2, 6.8 branch and HEAD.

 The code in this patch:
 {{{
 Fri Jan 18 22:56:55 GMT 2008  Ian Lynagh <igloo@earth.li>
   * Improve the error when :list can't find any code to show
 }}}
 duplicates the problem when deciding whether or not to tell the user to
 rerun with `:trace`.

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/2054>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Sat Jan 19 07:58:58 2008
From: trac at galois.com (GHC)
Date: Sat Jan 19 07:58:54 2008
Subject: [GHC] #2054: :history doesn't work if :trace is not used
 initially
In-Reply-To: <044.fb0075e819aa0a0bed0834f203038504@localhost>
References: <044.fb0075e819aa0a0bed0834f203038504@localhost>
Message-ID: <053.d1c5acb021637e858e7954ae55b9b3b1@localhost>

#2054: :history doesn't work if :trace is not used initially
---------------------+------------------------------------------------------
 Reporter:  igloo    |          Owner:         
     Type:  bug      |         Status:  new    
 Priority:  normal   |      Milestone:  6.8.3  
Component:  GHCi     |        Version:  6.8.2  
 Severity:  normal   |     Resolution:         
 Keywords:           |     Difficulty:  Unknown
 Testcase:           |   Architecture:  Unknown
       Os:  Unknown  |  
---------------------+------------------------------------------------------
Changes (by igloo):

  * summary:  :history doesn't => :history doesn't work if :trace is not
              used initially

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/2054#comment:1>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Sat Jan 19 08:15:19 2008
From: trac at galois.com (GHC)
Date: Sat Jan 19 08:15:16 2008
Subject: [GHC] #2051: -hide-package doesn't allow hiding uninstalled
 package
In-Reply-To: <053.fd935e025acfb737c5e2348105b5b118@localhost>
References: <053.fd935e025acfb737c5e2348105b5b118@localhost>
Message-ID: <062.4cabff038f2abb134a2577c6c72170dd@localhost>

#2051: -hide-package doesn't allow hiding uninstalled package
--------------------------------+-------------------------------------------
    Reporter:  MagnusTherning   |        Owner:       
        Type:  feature request  |       Status:  new  
    Priority:  normal           |    Milestone:       
   Component:  Compiler         |      Version:  6.8.2
    Severity:  trivial          |   Resolution:       
    Keywords:                   |     Testcase:       
Architecture:  x86_64 (amd64)   |           Os:  Linux
--------------------------------+-------------------------------------------
Comment (by MagnusTherning):

 Replying to [comment:1 ajd]:
 > I wrote a patch to "fix" this but I'm not sure it ought to be the
 correct behavior. According to the comments around the function in
 question, -ignore-package already has this behavior because it's supposed
 to be used as a just-in-case thing, they way you are trying to use -hide-
 package. Anyway, I'm attaching the patch and I'll leave it up to the
 powers that be to decide what to do about it.

 Well, I find that I have to hide packages regularly since it allows me to
 have a module installed while I'm hacking on the next version of it.
 Without it my unit/quickcheck tests link to the installed version one by
 default.

 One option would be to keep the current behaviour as default, but allow
 overriding it e.g. by using '--force' (similar to how 'rm' has '-f').

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/2051#comment:2>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Sat Jan 19 08:22:19 2008
From: trac at galois.com (GHC)
Date: Sat Jan 19 08:22:17 2008
Subject: [GHC] #1826: unable to list source for <exception thrown>
 should never occur
In-Reply-To: <044.f94ec6280873c17dbdd2473c81e3b4a3@localhost>
References: <044.f94ec6280873c17dbdd2473c81e3b4a3@localhost>
Message-ID: <053.f9b90eff1cfa3ba0c31ea1751cbbd415@localhost>

#1826: unable to list source for <exception thrown> should never occur
-----------------------------+----------------------------------------------
 Reporter:  guest            |          Owner:             
     Type:  feature request  |         Status:  closed     
 Priority:  normal           |      Milestone:  6.8.3      
Component:  GHCi             |        Version:  6.8.1      
 Severity:  normal           |     Resolution:  fixed      
 Keywords:                   |     Difficulty:  Easy (1 hr)
 Testcase:                   |   Architecture:  Multiple   
       Os:  Multiple         |  
-----------------------------+----------------------------------------------
Changes (by igloo):

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

Comment:

 Thanks; now fixed in 6.8 branch and HEAD, modulo #2054.

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/1826#comment:7>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Sat Jan 19 08:30:39 2008
From: trac at galois.com (GHC)
Date: Sat Jan 19 08:30:37 2008
Subject: [GHC] #1975: GHC cc phase doesn't add -framework-path flags
In-Reply-To: <044.9dc1ed618d9eb76c898bf712da3b3fdb@localhost>
References: <044.9dc1ed618d9eb76c898bf712da3b3fdb@localhost>
Message-ID: <053.49477ca953472f7bae812372432aa99b@localhost>

#1975: GHC cc phase doesn't add -framework-path flags
----------------------+-----------------------------------------------------
 Reporter:  judah     |          Owner:  igloo      
     Type:  bug       |         Status:  new        
 Priority:  low       |      Milestone:  6.8.3      
Component:  Compiler  |        Version:  6.8.1      
 Severity:  minor     |     Resolution:             
 Keywords:            |     Difficulty:  Easy (1 hr)
 Testcase:            |   Architecture:  Multiple   
       Os:  MacOS X   |  
----------------------+-----------------------------------------------------
Changes (by igloo):

  * owner:  judah => igloo

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/1975#comment:1>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Sat Jan 19 09:45:18 2008
From: trac at galois.com (GHC)
Date: Sat Jan 19 09:45:14 2008
Subject: [GHC] #1312: runghc doesn't respect -main-is
In-Reply-To: <047.0ad50b74545f6e5e0f2d7fb1521d3937@localhost>
References: <047.0ad50b74545f6e5e0f2d7fb1521d3937@localhost>
Message-ID: <056.f65cae18323cb5454b2a16ce65dd6b4c@localhost>

#1312: runghc doesn't respect -main-is
----------------------+-----------------------------------------------------
 Reporter:  simonmar  |          Owner:  igloo      
     Type:  bug       |         Status:  new        
 Priority:  normal    |      Milestone:  6.8.3      
Component:  Compiler  |        Version:  6.6.1      
 Severity:  minor     |     Resolution:             
 Keywords:            |     Difficulty:  Easy (1 hr)
 Testcase:            |   Architecture:  Multiple   
       Os:  Unknown   |  
----------------------+-----------------------------------------------------
Changes (by igloo):

  * owner:  => igloo

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/1312#comment:6>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Sat Jan 19 10:29:40 2008
From: trac at galois.com (GHC)
Date: Sat Jan 19 10:29:36 2008
Subject: [GHC] #2055: Incorrect warning about qualified import
Message-ID: <045.978b49f7a0b20b3e110c31c474744c60@localhost>

#2055: Incorrect warning about qualified import
------------------------+---------------------------------------------------
    Reporter:  duncan   |       Owner:          
        Type:  bug      |      Status:  new     
    Priority:  normal   |   Component:  Compiler
     Version:  6.9      |    Severity:  normal  
    Keywords:           |    Testcase:          
Architecture:  Unknown  |          Os:  Unknown 
------------------------+---------------------------------------------------
 GHC HEAD failed to validate recently because of this warning (in
 combination with `-Werror`)

 {{{
 Distribution/Simple/Program.hs:222:24:
     Warning: This binding for `update' shadows the existing binding
                imported from Distribution.Compat.Map at
 Distribution/Simple/Program.hs:87:0-46
              In the definition of `updateUnconfiguredProgs'
 }}}

 The code it was warning about looks like

 {{{
 updateUnconfiguredProgs update conf =
   conf { unconfiguredProgs = update (unconfiguredProgs conf) }
 }}}

 So initially it looks sensible. However the only import of
 `Distribution.Compat.Map` in that module is from

 {{{
 import qualified Distribution.Compat.Map as Map
 }}}

 So actually there is no `update` in scope at all and thus there is no name
 shadowing. The warning is incorrect.

 This is a regression in ghc-6.9. The warning is not present with
 ghc-6.8.2.

 It should be possible to reproduce this problem using ghc's branch of the
 Cabal lib and by reverting the patch that is currently masking the
 incorrect warning:

 {{{
 Fri Jan 18 11:12:30 PST 2008  Ian Lynagh <igloo@earth.li>
   * Fix warnings in Cabal
 }}}

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/2055>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Sat Jan 19 10:29:46 2008
From: trac at galois.com (GHC)
Date: Sat Jan 19 10:29:42 2008
Subject: [GHC] #2056: Incorrect warning about unused import
Message-ID: <045.308d448dbc9a68c57eac297a9428cce0@localhost>

#2056: Incorrect warning about unused import
------------------------+---------------------------------------------------
    Reporter:  duncan   |       Owner:          
        Type:  bug      |      Status:  new     
    Priority:  normal   |   Component:  Compiler
     Version:  6.8.2    |    Severity:  normal  
    Keywords:           |    Testcase:          
Architecture:  Unknown  |          Os:  Unknown 
------------------------+---------------------------------------------------
 In [http://darcs.haskell.org/cabal-install/ cabal-install] in four modules
 we get an incorrect warning about an import that is unused when it is in
 fact used. It is also used directly or indirectly by exported functions.

 The warnings are all of the same form. Here is one:

 {{{
 Hackage/Install.hs:31:0:
     Warning: Module `Distribution.Simple.Compiler' is imported, but
 nothing from it is used,
                except perhaps instances visible in
 `Distribution.Simple.Compiler'
              To suppress this warning, use: import
 Distribution.Simple.Compiler()
 }}}

 We import from that module only once with

 {{{
 import Distribution.Simple.Compiler (Compiler, PackageDB)
 }}}

 Both the Compiler and PackageDB types are used in the type signature for
 `install` which is directly exported.

 {{{
 install :: Verbosity
         -> PackageDB
         -> [Repo]
         -> Compiler
         -> ProgramConfiguration
         -> Cabal.ConfigFlags
         -> [UnresolvedDependency]
         -> IO ()
 }}}

 The problem is not restricted to unused types. This import:

 {{{
 import Distribution.Compiler (CompilerFlavor(..), defaultCompilerFlavor)
 }}}

 gives us the following warning:

 {{{
 Hackage/Config.hs:33:0:
     Warning: Module `Distribution.Compiler' is imported, but nothing from
 it is used,
                except perhaps instances visible in `Distribution.Compiler'
              To suppress this warning, use: import Distribution.Compiler()
 }}}

 Which is used in a value

 {{{
 defaultCompiler :: CompilerFlavor
 defaultCompiler = fromMaybe GHC defaultCompilerFlavor
 }}}

 This value is used indirectly by an exported function.

 It is not obvious to me what is special about these imports that gives us
 these incorrect warnings. (Except that they have the module name
 "Compiler".)

 Initially this looks similar to ticket #1148, however that was diagnosed
 as being related to qualified imports. This does not appear to be the
 same.

 It should be possible to reproduce these using ghc-6.8.2 and the `cabal-
 install` code from darcs. http://darcs.haskell.org/cabal-install/

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/2056>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Sat Jan 19 10:52:30 2008
From: trac at galois.com (GHC)
Date: Sat Jan 19 10:52:25 2008
Subject: [GHC] #2056: Incorrect warning about unused import
In-Reply-To: <045.308d448dbc9a68c57eac297a9428cce0@localhost>
References: <045.308d448dbc9a68c57eac297a9428cce0@localhost>
Message-ID: <054.f20f91661a2307ea34997eaaff08b8f3@localhost>

#2056: Incorrect warning about unused import
----------------------+-----------------------------------------------------
 Reporter:  duncan    |          Owner:           
     Type:  bug       |         Status:  closed   
 Priority:  normal    |      Milestone:           
Component:  Compiler  |        Version:  6.8.2    
 Severity:  normal    |     Resolution:  duplicate
 Keywords:            |     Difficulty:  Unknown  
 Testcase:            |   Architecture:  Unknown  
       Os:  Unknown   |  
----------------------+-----------------------------------------------------
Changes (by igloo):

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

Comment:

 Thanks for the report. However, this looks the same as #1148 to me; you do
 {{{
 import qualified Distribution.Simple.Setup as Cabal
 }}}
 and `Distribution.Simple.Setup` exports `Compiler` and `PackageDB`.

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/2056#comment:1>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Sat Jan 19 11:16:47 2008
From: trac at galois.com (GHC)
Date: Sat Jan 19 11:16:43 2008
Subject: [GHC] #2056: Incorrect warning about unused import
In-Reply-To: <045.308d448dbc9a68c57eac297a9428cce0@localhost>
References: <045.308d448dbc9a68c57eac297a9428cce0@localhost>
Message-ID: <054.7a75a9ca1e7f816871cd73bd8dc8631f@localhost>

#2056: Incorrect warning about unused import
----------------------+-----------------------------------------------------
 Reporter:  duncan    |          Owner:           
     Type:  bug       |         Status:  closed   
 Priority:  normal    |      Milestone:           
Component:  Compiler  |        Version:  6.8.2    
 Severity:  normal    |     Resolution:  duplicate
 Keywords:            |     Difficulty:  Unknown  
 Testcase:            |   Architecture:  Unknown  
       Os:  Unknown   |  
----------------------+-----------------------------------------------------
Comment (by duncan):

 Yup. Quite right. I didn't spot that. That qualified import is there in
 each of the modules where we get that warning.

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/2056#comment:2>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Sat Jan 19 11:59:02 2008
From: trac at galois.com (GHC)
Date: Sat Jan 19 11:58:58 2008
Subject: [GHC] #2057: inconsistent .hi file error gets ignored
Message-ID: <045.e53c768183aca8a1a40fddc456cadee9@localhost>

#2057: inconsistent .hi file error gets ignored
------------------------+---------------------------------------------------
    Reporter:  duncan   |       Owner:          
        Type:  bug      |      Status:  new     
    Priority:  normal   |   Component:  Compiler
     Version:  6.8.2    |    Severity:  normal  
    Keywords:           |    Testcase:          
Architecture:  Unknown  |          Os:  Unknown 
------------------------+---------------------------------------------------
 {{{
 [20 of 20] Compiling Main             ( ./Main.hs, dist/build/cabal/cabal-
 tmp/Main.o )
 The interface for `main:Hackage.Config'
 Declaration for savedConfigToConfigFlags
 Unfolding of Hackage.Config.savedConfigToConfigFlags:
   Can't find interface-file declaration for variable
 Distribution.Simple.Setup.a401
     Probable cause: bug in .hi-boot file, or inconsistent .hi file
     Use -ddump-if-trace to get an idea of which file caused the error
 Linking dist/build/cabal/cabal ...
 dist/build/cabal/cabal-tmp/Hackage/Config.o: In function `sfsu_info':
 (.text+0x70cc): undefined reference to
 `Cabalzm1zi3zi3_DistributionziSimpleziSetup_a401_closure'
 dist/build/cabal/cabal-tmp/Hackage/Config.o: In function `rf7U_closure':
 (.data+0xf28): undefined reference to
 `Cabalzm1zi3zi3_DistributionziSimpleziSetup_a401_closure'
 collect2: ld returned 1 exit status
 }}}

 Now, the inconsistent .hi file was entirely my fault. However note that
 `ghc --make` did not stop at the error! It continued and tried to link.

 This is bad because sometimes linker errors are very long and a user might
 loose the real source of the error.

 The error gets raised in `iface/TcIface.lhs` by `importDecl`. The uses of
 that function look like they are translating the error into failure in
 other monads ok. It's not immediately obvious at what point in the
 propagation of this error it gets ignored and linking continues
 irrespective.

 It should not be too hard to reproduce I hope. Generating inconsistent .hi
 files is fairly easy to do. In this case I just built cabal-install
 against an existing Cabal. Then rebuilt and re-registered a slightly
 changed Cabal lib. Then did another build of cabal-install without
 cleaning first.

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/2057>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Sat Jan 19 12:17:37 2008
From: trac at galois.com (GHC)
Date: Sat Jan 19 12:17:33 2008
Subject: [GHC] #1839: need ghc-pkg dump feature
In-Reply-To: <045.e765af751a0d91f5b4a56c8391184f46@localhost>
References: <045.e765af751a0d91f5b4a56c8391184f46@localhost>
Message-ID: <054.1b31805a8fcd4943a681e015b16fe492@localhost>

#1839: need ghc-pkg dump feature
-----------------------------+----------------------------------------------
 Reporter:  duncan           |          Owner:         
     Type:  feature request  |         Status:  new    
 Priority:  normal           |      Milestone:  6.8.3  
Component:  Compiler         |        Version:  6.8.1  
 Severity:  normal           |     Resolution:         
 Keywords:                   |     Difficulty:  Unknown
 Testcase:                   |   Architecture:  Unknown
       Os:  Unknown          |  
-----------------------------+----------------------------------------------
Changes (by igloo):

  * milestone:  6.10 branch => 6.8.3

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/1839#comment:9>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Sat Jan 19 12:27:45 2008
From: trac at galois.com (GHC)
Date: Sat Jan 19 12:27:45 2008
Subject: [GHC] #1821: Parser or lexer mess-up
In-Reply-To: <046.cf097a693fa1ac0c5dfad7ed75735fe3@localhost>
References: <046.cf097a693fa1ac0c5dfad7ed75735fe3@localhost>
Message-ID: <055.62334d162776b5b444b32656de692fbb@localhost>

#1821: Parser or lexer mess-up
-----------------------+----------------------------------------------------
 Reporter:  simonpj    |          Owner:  igloo      
     Type:  bug        |         Status:  closed     
 Priority:  normal     |      Milestone:  6.10 branch
Component:  Compiler   |        Version:  6.9        
 Severity:  normal     |     Resolution:  fixed      
 Keywords:             |     Difficulty:  Unknown    
 Testcase:  read_1821  |   Architecture:  Unknown    
       Os:  Unknown    |  
-----------------------+----------------------------------------------------
Changes (by igloo):

  * testcase:  parser/should_compile/read062 => read_1821
  * status:  new => closed
  * resolution:  => fixed

Comment:

 Many thanks for the patch, dfranke! I've just applied it. Sorry for the
 delay.

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/1821#comment:5>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Sat Jan 19 15:22:05 2008
From: trac at galois.com (GHC)
Date: Sat Jan 19 15:22:00 2008
Subject: [GHC] #1975: GHC cc phase doesn't add -framework-path flags
In-Reply-To: <044.9dc1ed618d9eb76c898bf712da3b3fdb@localhost>
References: <044.9dc1ed618d9eb76c898bf712da3b3fdb@localhost>
Message-ID: <053.2a71afa16d7b20e0aa0ffe6c6581783f@localhost>

#1975: GHC cc phase doesn't add -framework-path flags
----------------------+-----------------------------------------------------
 Reporter:  judah     |          Owner:  igloo      
     Type:  bug       |         Status:  closed     
 Priority:  low       |      Milestone:  6.8.3      
Component:  Compiler  |        Version:  6.8.1      
 Severity:  minor     |     Resolution:  fixed      
 Keywords:            |     Difficulty:  Easy (1 hr)
 Testcase:            |   Architecture:  Multiple   
       Os:  MacOS X   |  
----------------------+-----------------------------------------------------
Changes (by igloo):

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

Comment:

 Patch applied to 6.8 and HEAD branches:
 {{{
 Wed Dec 12 12:12:45 PST 2007  judah.jacobson@gmail.com
   * Use -framework-path flags during the cc phase.  Fixes trac #1975.
 }}}

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/1975#comment:2>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Sat Jan 19 19:24:53 2008
From: trac at galois.com (GHC)
Date: Sat Jan 19 19:24:48 2008
Subject: [GHC] #2049: GHCi doesn't fully load previously broken modules
In-Reply-To: <042.e75e264362dd101a1f793da2344243d7@localhost>
References: <042.e75e264362dd101a1f793da2344243d7@localhost>
Message-ID: <051.18db5a9ceb0f05bcf9d8f6bfbd86a601@localhost>

#2049: GHCi doesn't fully load previously broken modules
------------------------+---------------------------------------------------
    Reporter:  ajd      |        Owner:         
        Type:  bug      |       Status:  new    
    Priority:  normal   |    Milestone:         
   Component:  GHCi     |      Version:  6.8.2  
    Severity:  normal   |   Resolution:         
    Keywords:           |     Testcase:         
Architecture:  Unknown  |           Os:  Unknown
------------------------+---------------------------------------------------
Changes (by ToRA):

 * cc: tora@zonetora.co.uk (added)

Comment:

 Similar behaviour also occurs when using :l to load in a broken file.

 I've attached a trace using GHCi.  The ****'d lines are lines where I
 think Bar should be in the module scope.  Seemingly using :m + forces ghci
 to remember the module across edits/breaks, but :l wipes out the memory,
 and if :l is used on a broken file, the module in the file isn't
 remembered on a load...

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/2049#comment:1>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Sat Jan 19 19:58:08 2008
From: trac at galois.com (GHC)
Date: Sat Jan 19 19:58:02 2008
Subject: [GHC] #1880: Unify flag descriptions to generate both docs and
 code
In-Reply-To: <047.a1f2675dc59d934ab527e6234630f65b@localhost>
References: <047.a1f2675dc59d934ab527e6234630f65b@localhost>
Message-ID: <056.d5972da3b5860d5489e9aa70dffdec38@localhost>

#1880: Unify flag descriptions to generate both docs and code
----------------------+-----------------------------------------------------
 Reporter:  simonmar  |          Owner:             
     Type:  task      |         Status:  new        
 Priority:  normal    |      Milestone:  6.10 branch
Component:  Compiler  |        Version:  6.8.1      
 Severity:  normal    |     Resolution:             
 Keywords:            |     Difficulty:  Unknown    
 Testcase:            |   Architecture:  Unknown    
       Os:  Unknown   |  
----------------------+-----------------------------------------------------
Comment (by ajd):

 Has anyone considered using System.Console.GetOpt for this? From my
 understanding, it would allow automatic generation of a --help message for
 the options. I think [http://www.gnu.org/software/help2man/ help2man]
 could generate the man page from that as well.

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/1880#comment:3>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Sun Jan 20 05:11:48 2008
From: trac at galois.com (GHC)
Date: Sun Jan 20 05:11:48 2008
Subject: [GHC] #2058: Ghci tab-completion cannot handle Unicode
Message-ID: <047.a8886855c87afec46dd99ad6a799741e@localhost>

#2058: Ghci tab-completion cannot handle Unicode
-------------------------+--------------------------------------------------
    Reporter:  desegnis  |       Owner:        
        Type:  bug       |      Status:  new   
    Priority:  normal    |   Component:  GHCi  
     Version:  6.9       |    Severity:  normal
    Keywords:            |    Testcase:        
Architecture:  Unknown   |          Os:  Linux 
-------------------------+--------------------------------------------------
 Ghci on *nix is capable of handling input Unicode identifiers encoded as
 UTF-8:

 {{{
 Prelude> let ?a?mman?a?o = "hmmm..."
 Prelude> let identifier_? = ()
 Prelude> let test_? = 1
 Prelude> let test_? = 2
 Prelude> ?a?mman?a?o
 "hmmm..."
 }}}

 However, there is no working tab completion for those identifiers:

 {{{
 Prelude> ?a<TAB><TAB><TAB>    -- Nothing happens
 Prelude> identifier_?         -- Tab-completed garbage
 Prelude> test_<TAB>           -- Unreadable alternatives
 }}}

 Since code input is interpreted as UTF-8, tab-completion output should be
 converted to UTF-8, too.

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/2058>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Sun Jan 20 06:22:19 2008
From: trac at galois.com (GHC)
Date: Sun Jan 20 06:22:24 2008
Subject: [GHC] #915: Implement list fusion using streams instead of
 foldr/build
In-Reply-To: <046.37416aee19ee095c9a6e98285b215b72@localhost>
References: <046.37416aee19ee095c9a6e98285b215b72@localhost>
Message-ID: <055.06263f66b0282b2f93e27d799d4381f7@localhost>

#915: Implement list fusion using streams instead of foldr/build
----------------------------+-----------------------------------------------
 Reporter:  simonpj         |          Owner:                    
     Type:  task            |         Status:  new               
 Priority:  normal          |      Milestone:  6.10 branch       
Component:  libraries/base  |        Version:  6.8               
 Severity:  normal          |     Resolution:                    
 Keywords:  fusion          |     Difficulty:  Project (> 1 week)
 Testcase:  N/A             |   Architecture:  Multiple          
       Os:  Unknown         |  
----------------------------+-----------------------------------------------
Changes (by tibbe):

 * cc: johan.tibell@gmail.com (added)

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/915#comment:10>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Sun Jan 20 06:25:13 2008
From: trac at galois.com (GHC)
Date: Sun Jan 20 06:25:08 2008
Subject: [GHC] #1498: Optimisation: eliminate unnecessary heap check in
 recursive function
In-Reply-To: <047.d854a286f40f24efedada1697ad637ee@localhost>
References: <047.d854a286f40f24efedada1697ad637ee@localhost>
Message-ID: <056.fbd7e3b702a9b2a607f702d1321f7e70@localhost>

#1498: Optimisation: eliminate unnecessary heap check in recursive function
----------------------+-----------------------------------------------------
 Reporter:  simonmar  |          Owner:                  
     Type:  task      |         Status:  new             
 Priority:  normal    |      Milestone:  6.10 branch     
Component:  Compiler  |        Version:  6.6.1           
 Severity:  normal    |     Resolution:                  
 Keywords:            |     Difficulty:  Moderate (1 day)
 Testcase:            |   Architecture:  Unknown         
       Os:  Unknown   |  
----------------------+-----------------------------------------------------
Changes (by tibbe):

 * cc: johan.tibell@gmail.com (added)

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/1498#comment:2>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From frederik at a5.repetae.net  Sun Jan 20 11:08:47 2008
From: frederik at a5.repetae.net (Frederik Eaton)
Date: Sun Jan 20 11:08:42 2008
Subject: [GHC] #1837: ghc-pkg should not accept unversioned depends
In-Reply-To: <045.5a240ed44745ae5d43f18d5941f21a30@localhost>
References: <045.5a240ed44745ae5d43f18d5941f21a30@localhost>
Message-ID: <20080120160847.GA11940@a5.repetae.net>

Hello,

I can't use Cabal on some of my projects, for various reasons that
I've discussed here earlier... However, I can have a cabal file to
describe the dependencies and so forth. Is there a way to generate a
proper package config using a cabal file? Or is there some other way
to do it so I get the right versions? I am now seeing the warning
message which was introduced by this bug fix, but don't know what to
do about it.

Thanks,

Frederik

On Tue, Nov 06, 2007 at 03:31:02PM -0000, GHC wrote:
> #1837: ghc-pkg should not accept unversioned depends
> -----------------------------+----------------------------------------------
>     Reporter:  duncan        |       Owner:          
>         Type:  bug           |      Status:  new     
>     Priority:  normal        |   Milestone:          
>    Component:  Build System  |     Version:  6.8.1   
>     Severity:  normal        |    Keywords:          
>   Difficulty:  Easy (1 hr)   |    Testcase:          
> Architecture:  Multiple      |          Os:  Multiple
> -----------------------------+----------------------------------------------
>  Historically ghc-pkg accepted a format where the "depends:" field did not
>  require version numbers. Then ghc would just resolve it to some installed
>  version. However now that ghc bakes in the version number to libraries
>  when it compiles them it really crucial that a package gets linked with
>  exactly the versions of packages it was built against. Allowing ghc-pkg to
>  accept unversioned depends and resolving them to some random installed
>  version is just asking for trouble.
> 
>  It's not too serious since Cabal always uses versioned depends, however I
>  just noticed that older autoconf/automake build systems do not.
> 
>  So, in summary allowing undersioned depends is just asking for trouble and
>  ghc-pkg should reject them.
> 
> -- 
> Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/1837>
> 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


-- 
http://ofb.net/~frederik/
From trac at galois.com  Sun Jan 20 11:43:03 2008
From: trac at galois.com (GHC)
Date: Sun Jan 20 11:42:55 2008
Subject: [GHC] #1599: testsuite timeout doesn't kill subprocesses on
 Windows
In-Reply-To: <047.b1020b9504f2c2f7ec4496c2c9545397@localhost>
References: <047.b1020b9504f2c2f7ec4496c2c9545397@localhost>
Message-ID: <056.bbe1601a1bc34263adde591730b60331@localhost>

#1599: testsuite timeout doesn't kill subprocesses on Windows
------------------------+---------------------------------------------------
 Reporter:  simonmar    |          Owner:  igloo     
     Type:  bug         |         Status:  closed    
 Priority:  normal      |      Milestone:  6.8 branch
Component:  Test Suite  |        Version:  6.6.1     
 Severity:  normal      |     Resolution:  fixed     
 Keywords:              |     Difficulty:  Unknown   
 Testcase:              |   Architecture:  x86       
       Os:  Windows     |  
------------------------+---------------------------------------------------
Changes (by igloo):

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

Comment:

 The timeout program in the testsuite now does this.

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/1599#comment:4>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From duncan.coutts at worc.ox.ac.uk  Sun Jan 20 12:06:10 2008
From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts)
Date: Sun Jan 20 12:06:09 2008
Subject: [GHC] #1837: ghc-pkg should not accept unversioned depends
In-Reply-To: <20080120160847.GA11940@a5.repetae.net>
References: <045.5a240ed44745ae5d43f18d5941f21a30@localhost>
	<20080120160847.GA11940@a5.repetae.net>
Message-ID: <1200848770.5639.325.camel@localhost>


On Sun, 2008-01-20 at 16:08 +0000, Frederik Eaton wrote:
> Hello,
> 
> I can't use Cabal on some of my projects, for various reasons that
> I've discussed here earlier... 

BTW, just so we do not loose track of those reasons could you double
check that all the problems and limitations you reported are described
accurately in the hackage trac. That'd be great.

http://hackage.haskell.org/trac/hackage/

In the cases where what you're trying to do does not quite chime with
the way Cabal works now it's probably best to describe what you're
actually trying to achieve as well as the immediate problem.

> However, I can have a cabal file to
> describe the dependencies and so forth. Is there a way to generate a
> proper package config using a cabal file? Or is there some other way
> to do it so I get the right versions? I am now seeing the warning
> message which was introduced by this bug fix, but don't know what to
> do about it.

Yes, you can:

cabal configure
cabal register --gen-pkg-config=foo.pkg
ghc-pkg register foo.pkg

So that does depend on being able to configure the package successfully.

If you don't use cabal-install yet replace "cabal" with "runghc
Setup.hs" in the above commands.

Duncan

From frederik at a5.repetae.net  Sun Jan 20 12:37:55 2008
From: frederik at a5.repetae.net (Frederik Eaton)
Date: Sun Jan 20 12:37:49 2008
Subject: [GHC] #1837: ghc-pkg should not accept unversioned depends
In-Reply-To: <1200848770.5639.325.camel@localhost>
References: <045.5a240ed44745ae5d43f18d5941f21a30@localhost>
	<20080120160847.GA11940@a5.repetae.net>
	<1200848770.5639.325.camel@localhost>
Message-ID: <20080120173755.GL11635@a5.repetae.net>

Hi Duncan,

Thanks, --gen-pkg-config works.

I don't know if Cabal will ever be suitable for me - I prefer to be
able to build specific targets, and to track dependencies to minimize
build time, and there is a tool for this called 'make' which is a lot
older, faster, and more stable which I prefer to use. Cabal does these
things well if one is not using too many derived files, or too many
languages other than Haskell, but those restrictions aren't compatible
with many of my projects (although for some it is fine!).

Best wishes,

Frederik

On Sun, Jan 20, 2008 at 05:06:10PM +0000, Duncan Coutts wrote:
> 
> On Sun, 2008-01-20 at 16:08 +0000, Frederik Eaton wrote:
> > Hello,
> > 
> > I can't use Cabal on some of my projects, for various reasons that
> > I've discussed here earlier... 
> 
> BTW, just so we do not loose track of those reasons could you double
> check that all the problems and limitations you reported are described
> accurately in the hackage trac. That'd be great.
> 
> http://hackage.haskell.org/trac/hackage/
> 
> In the cases where what you're trying to do does not quite chime with
> the way Cabal works now it's probably best to describe what you're
> actually trying to achieve as well as the immediate problem.
> 
> > However, I can have a cabal file to
> > describe the dependencies and so forth. Is there a way to generate a
> > proper package config using a cabal file? Or is there some other way
> > to do it so I get the right versions? I am now seeing the warning
> > message which was introduced by this bug fix, but don't know what to
> > do about it.
> 
> Yes, you can:
> 
> cabal configure
> cabal register --gen-pkg-config=foo.pkg
> ghc-pkg register foo.pkg
> 
> So that does depend on being able to configure the package successfully.
> 
> If you don't use cabal-install yet replace "cabal" with "runghc
> Setup.hs" in the above commands.
> 
> Duncan
> 

-- 
http://ofb.net/~frederik/
From duncan.coutts at worc.ox.ac.uk  Sun Jan 20 13:21:56 2008
From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts)
Date: Sun Jan 20 13:21:53 2008
Subject: [GHC] #1837: ghc-pkg should not accept unversioned depends
In-Reply-To: <20080120173755.GL11635@a5.repetae.net>
References: <045.5a240ed44745ae5d43f18d5941f21a30@localhost>
	<20080120160847.GA11940@a5.repetae.net>
	<1200848770.5639.325.camel@localhost>
	<20080120173755.GL11635@a5.repetae.net>
Message-ID: <1200853316.5639.336.camel@localhost>


On Sun, 2008-01-20 at 17:37 +0000, Frederik Eaton wrote:
> Hi Duncan,
> 
> Thanks, --gen-pkg-config works.
> 
> I don't know if Cabal will ever be suitable for me - I prefer to be
> able to build specific targets, and to track dependencies to minimize
> build time, and there is a tool for this called 'make' which is a lot
> older, faster, and more stable which I prefer to use.

http://hackage.haskell.org/trac/hackage/ticket/15

Yes, make style dependency analysis and incremental builds is the next
major feature we need for Cabal. Lots of other stuff that we want to do
depends on that (like building specific targets with minimal and
parallel rebuilds). It should also make it easier to integrate with
other build systems by adding rules in Setup.hs.

> Cabal does thesethings well if one is not using too many derived
> files, or too many languages other than Haskell, but those
> restrictions aren't compatible with many of my projects (although for
> some it is fine!).

So don't despair that it'll never work. Make sure your issues are
recorded so we can see features we can pick off once we have dep
tracking.

Duncan

From frederik at a5.repetae.net  Sun Jan 20 14:38:48 2008
From: frederik at a5.repetae.net (Frederik Eaton)
Date: Sun Jan 20 14:38:42 2008
Subject: [GHC] #1837: ghc-pkg should not accept unversioned depends
In-Reply-To: <1200853316.5639.336.camel@localhost>
References: <045.5a240ed44745ae5d43f18d5941f21a30@localhost>
	<20080120160847.GA11940@a5.repetae.net>
	<1200848770.5639.325.camel@localhost>
	<20080120173755.GL11635@a5.repetae.net>
	<1200853316.5639.336.camel@localhost>
Message-ID: <20080120193848.GM11635@a5.repetae.net>

On Sun, Jan 20, 2008 at 06:21:56PM +0000, Duncan Coutts wrote:
> 
> On Sun, 2008-01-20 at 17:37 +0000, Frederik Eaton wrote:
> > Hi Duncan,
> > 
> > Thanks, --gen-pkg-config works.
> > 
> > I don't know if Cabal will ever be suitable for me - I prefer to be
> > able to build specific targets, and to track dependencies to minimize
> > build time, and there is a tool for this called 'make' which is a lot
> > older, faster, and more stable which I prefer to use.
> 
> http://hackage.haskell.org/trac/hackage/ticket/15
> 
> Yes, make style dependency analysis and incremental builds is the next
> major feature we need for Cabal. Lots of other stuff that we want to do
> depends on that (like building specific targets with minimal and
> parallel rebuilds). It should also make it easier to integrate with
> other build systems by adding rules in Setup.hs.
> 
> > Cabal does thesethings well if one is not using too many derived
> > files, or too many languages other than Haskell, but those
> > restrictions aren't compatible with many of my projects (although for
> > some it is fine!).
> 
> So don't despair that it'll never work. Make sure your issues are
> recorded so we can see features we can pick off once we have dep
> tracking.

OK. Well, for me the best way to do dependency analysis would be to
allow users to specify a command which should be run on each source
file just *before* cabal/ghc checks its timestamp. In my case, this
command would be 'make'. So that way, if one source file is generated
from another, 'make' will bring it up to date, and cabal will see that
its timestamp has changed... (for efficiency, the command could be
given multiple file arguments at once). I've already suggested this
for ghc... It seems like it should be a simple change.

Frederik
From trac at galois.com  Sun Jan 20 19:11:54 2008
From: trac at galois.com (GHC)
Date: Sun Jan 20 19:11:46 2008
Subject: [GHC] #2059: Erroneous results in trigonometric functions
Message-ID: <056.3e619538850693ad9b65e875780ac3cb@localhost>

#2059: Erroneous results in trigonometric functions
----------------------------------+-----------------------------------------
    Reporter:  daniel.is.fischer  |       Owner:          
        Type:  bug                |      Status:  new     
    Priority:  normal             |   Component:  Compiler
     Version:  6.8.1              |    Severity:  normal  
    Keywords:                     |    Testcase:          
Architecture:  x86                |          Os:  Linux   
----------------------------------+-----------------------------------------
 For large inputs, sin, cos and tan return the input value:
 {{{GHCi, version 6.8.1: http://www.haskell.org/ghc/  :? for help
 Loading package base ... linking ... done.
 Prelude> sin 1e20
 1.0e20
 Prelude> cos 1e20
 1.0e20
 Prelude> cos 1e19
 1.0e19
 Prelude> cos 1e18
 0.11965025504785125
 Prelude> tan 1e19
 1.0e19}}}

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/2059>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Sun Jan 20 21:07:47 2008
From: trac at galois.com (GHC)
Date: Sun Jan 20 21:07:42 2008
Subject: [GHC] #2059: Erroneous results in trigonometric functions for >
 double-precision values
In-Reply-To: <056.3e619538850693ad9b65e875780ac3cb@localhost>
References: <056.3e619538850693ad9b65e875780ac3cb@localhost>
Message-ID: <065.623c93d0c32bdae14c6b650b6ef8d5d2@localhost>

#2059: Erroneous results in trigonometric functions for > double-precision values
----------------------------------+-----------------------------------------
    Reporter:  daniel.is.fischer  |        Owner:       
        Type:  feature request    |       Status:  new  
    Priority:  normal             |    Milestone:       
   Component:  Compiler           |      Version:  6.8.1
    Severity:  normal             |   Resolution:       
    Keywords:                     |     Testcase:       
Architecture:  x86                |           Os:  Linux
----------------------------------+-----------------------------------------
Changes (by ajd):

  * type:  bug => feature request
  * summary:  Erroneous results in trigonometric functions => Erroneous
              results in trigonometric functions for >
              double-precision values

Comment:

 The problem is that the Double type cannot store that much precision and
 so GHC can't calculate trig functions at all accurately. (This is actually
 documented, see [http://www.haskell.org/ghc/docs/latest/html/users_guide
 /wrong-compilee.html]. Since this is the way the compiler is documented to
 work, I'm changing the status to feature request.)

 From my understanding, in order to solve this, one would need to implement
 an arbitrary precision ''floating-point'' system in GHC (currently, we
 only have arbitrary precision ''integers'' through GMP). This ''could'' be
 done through something like MPFR, but I'm guessing that would be a huge
 job and potentially plagued with the same problems as GMP, as the latter
 is a dependency of the former.

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/2059#comment:1>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Mon Jan 21 02:17:42 2008
From: trac at galois.com (GHC)
Date: Mon Jan 21 02:17:37 2008
Subject: [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
In-Reply-To: <050.c31695132cb1b93380c95a8b6c208782@localhost>
References: <050.c31695132cb1b93380c95a8b6c208782@localhost>
Message-ID: <059.4015703a5393caeb4f6257923f721370@localhost>

#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:  thorkilnaur
     Type:  bug          |         Status:  new        
 Priority:  high         |      Milestone:  6.8.3      
Component:  Compiler     |        Version:  6.9        
 Severity:  normal       |     Resolution:             
 Keywords:               |     Difficulty:  Unknown    
 Testcase:               |   Architecture:  powerpc    
       Os:  MacOS X      |  
-------------------------+--------------------------------------------------
Comment (by thorkilnaur):

 Trying a few combinations of compiler options shows: With
 {{{
 SRC_HC_OPTS   = -H32m -O2
 GhcHcOpts     = -Rghc-timing
 GhcLibHcOpts  =
 GhcLibWays    =
 }}}
 in mk/build.mk, the build ends with:
 {{{
 ../../compiler/stage1/ghc-inplace -package-name unix-2.2 -hide-all-
 packages -split-objs -i -idist/build/autogen -idist/build -i. -Idist/build
 -Iinclude -#include "HsUnix.h" -#include "execvpe.h" -odir dist/build
 -hidir dist/build -stubdir dist/build -package base-3.0 -package
 directory-1.0 -O -XCPP -XForeignFunctionInterface -idist/build  -H32m -O2
 -c dist/build/System/Posix/Semaphore.hs -o
 dist/build/System/Posix/Semaphore.o  -ohi
 dist/build/System/Posix/Semaphore.hi
 collect2: ld terminated with signal 10 [Bus error]
 make[2]: *** [dist/build/System/Posix/Semaphore.o] Error 1
 make[1]: *** [make.library.unix] Error 2
 make: *** [stage1] Error 2
 }}}
 (The extra-packages are included in this build.) If I then change
 mk/build.mk to
 {{{
 SRC_HC_OPTS   = -H32m -O2
 GhcHcOpts     = -Rghc-timing
 GhcLibHcOpts  =
 GhcLibWays    =
 SplitObjs     = NO
 }}}
 the build ends with:
 {{{
 /usr/bin/ld -r -x -o HSghc.o  stage2/basicTypes/BasicTypes.o
 stage2/basicTypes/DataCon.o stage2/basicTypes/Demand.o
 stage2/basicTypes/Id.o stage2/basicTypes/IdInfo.o
 stage2/basicTypes/Literal.o stage2/basicTypes/MkId.o
 stage2/basicTypes/Module.o stage2/basicTypes/Name.o
 stage2/basicTypes/NameEnv.o stage2/basicTypes/NameSet.o
 stage2/basicTypes/NewDemand.o stage2/basicTypes/OccName.o
 stage2/basicTypes/RdrName.o stage2/basicTypes/SrcLoc.o
 stage2/basicTypes/UniqSupply.o stage2/basicTypes/Unique.o
 stage2/basicTypes/Var.o stage2/basicTypes/VarEnv.o
 stage2/basicTypes/VarSet.o stage2/cmm/CLabel.o stage2/cmm/Cmm.o
 stage2/cmm/CmmBrokenBlock.o stage2/cmm/CmmCPS.o stage2/cmm/CmmCPSGen.o
 stage2/cmm/CmmCPSZ.o stage2/cmm/CmmCallConv.o stage2/cmm/CmmContFlowOpt.o
 stage2/cmm/CmmCvt.o stage2/cmm/CmmExpr.o stage2/cmm/CmmInfo.o
 stage2/cmm/CmmLex.o stage2/cmm/CmmLint.o stage2/cmm/CmmLive.o
 stage2/cmm/CmmLiveZ.o stage2/cmm/CmmOpt.o stage2/cmm/CmmParse.o
 stage2/cmm/CmmProcPoint.o stage2/cmm/CmmProcPointZ.o
 stage2/cmm/CmmSpillReload.o stage2/cmm/CmmTx.o stage2/cmm/CmmUtils.o
 stage2/cmm/CmmZipUtil.o stage2/cmm/DFMonad.o stage2/cmm/Dataflow.o
 stage2/cmm/MachOp.o stage2/cmm/MkZipCfg.o stage2/cmm/MkZipCfgCmm.o
 stage2/cmm/OptimizationFuel.o stage2/cmm/PprC.o stage2/cmm/PprCmm.o
 stage2/cmm/PprCmmZ.o stage2/cmm/StackColor.o stage2/cmm/StackPlacements.o
 stage2/cmm/ZipCfg.o stage2/cmm/ZipCfgCmmRep.o stage2/cmm/ZipCfgExtras.o
 stage2/cmm/ZipDataflow0.o stage2/codeGen/Bitmap.o
 stage2/codeGen/CgBindery.o stage2/codeGen/CgCallConv.o
 stage2/codeGen/CgCase.o stage2/codeGen/CgClosure.o stage2/codeGen/CgCon.o
 stage2/codeGen/CgExpr.o stage2/codeGen/CgForeignCall.o
 stage2/codeGen/CgHeapery.o stage2/codeGen/CgHpc.o
 stage2/codeGen/CgInfoTbls.o stage2/codeGen/CgLetNoEscape.o
 stage2/codeGen/CgMonad.o stage2/codeGen/CgParallel.o
 stage2/codeGen/CgPrimOp.o stage2/codeGen/CgProf.o
 stage2/codeGen/CgStackery.o stage2/codeGen/CgTailCall.o
 stage2/codeGen/CgTicky.o stage2/codeGen/CgUtils.o
 stage2/codeGen/ClosureInfo.o stage2/codeGen/CodeGen.o
 stage2/codeGen/SMRep.o stage2/coreSyn/CoreFVs.o stage2/coreSyn/CoreLint.o
 stage2/coreSyn/CorePrep.o stage2/coreSyn/CoreSubst.o
 stage2/coreSyn/CoreSyn.o stage2/coreSyn/CoreTidy.o
 stage2/coreSyn/CoreUnfold.o stage2/coreSyn/CoreUtils.o
 stage2/coreSyn/ExternalCore.o stage2/coreSyn/MkExternalCore.o
 stage2/coreSyn/PprCore.o stage2/coreSyn/PprExternalCore.o
 stage2/cprAnalysis/CprAnalyse.o stage2/deSugar/Check.o
 stage2/deSugar/Coverage.o stage2/deSugar/Desugar.o
 stage2/deSugar/DsArrows.o stage2/deSugar/DsBinds.o
 stage2/deSugar/DsCCall.o stage2/deSugar/DsExpr.o
 stage2/deSugar/DsForeign.o stage2/deSugar/DsGRHSs.o
 stage2/deSugar/DsListComp.o stage2/deSugar/DsMeta.o
 stage2/deSugar/DsMonad.o stage2/deSugar/DsUtils.o stage2/deSugar/Match.o
 stage2/deSugar/MatchCon.o stage2/deSugar/MatchLit.o
 stage2/ghci/ByteCodeAsm.o stage2/ghci/ByteCodeFFI.o
 stage2/ghci/ByteCodeGen.o stage2/ghci/ByteCodeInstr.o
 stage2/ghci/ByteCodeItbls.o stage2/ghci/ByteCodeLink.o
 stage2/ghci/Debugger.o stage2/ghci/GhciMonad.o stage2/ghci/GhciTags.o
 stage2/ghci/InteractiveUI.o stage2/ghci/Linker.o stage2/ghci/ObjLink.o
 stage2/ghci/RtClosureInspect.o stage2/hsSyn/Convert.o
 stage2/hsSyn/HsBinds.o stage2/hsSyn/HsDecls.o stage2/hsSyn/HsDoc.o
 stage2/hsSyn/HsExpr.o stage2/hsSyn/HsImpExp.o stage2/hsSyn/HsLit.o
 stage2/hsSyn/HsPat.o stage2/hsSyn/HsSyn.o stage2/hsSyn/HsTypes.o
 stage2/hsSyn/HsUtils.o stage2/iface/BinIface.o stage2/iface/BuildTyCl.o
 stage2/iface/IfaceEnv.o stage2/iface/IfaceSyn.o stage2/iface/IfaceType.o
 stage2/iface/LoadIface.o stage2/iface/MkIface.o stage2/iface/TcIface.o
 stage2/main/BreakArray.o stage2/main/CmdLineParser.o
 stage2/main/CodeOutput.o stage2/main/Config.o stage2/main/Constants.o
 stage2/main/DriverMkDepend.o stage2/main/DriverPhases.o
 stage2/main/DriverPipeline.o stage2/main/DynFlags.o stage2/main/ErrUtils.o
 stage2/main/Finder.o stage2/main/GHC.o stage2/main/HeaderInfo.o
 stage2/main/HscMain.o stage2/main/HscStats.o stage2/main/HscTypes.o
 stage2/main/InteractiveEval.o stage2/main/PackageConfig.o
 stage2/main/Packages.o stage2/main/ParsePkgConf.o stage2/main/PprTyThing.o
 stage2/main/StaticFlags.o stage2/main/SysTools.o stage2/main/TidyPgm.o
 stage2/nativeGen/AsmCodeGen.o stage2/nativeGen/MachCodeGen.o
 stage2/nativeGen/MachInstrs.o stage2/nativeGen/MachRegs.o
 stage2/nativeGen/NCGMonad.o stage2/nativeGen/PositionIndependentCode.o
 stage2/nativeGen/PprMach.o stage2/nativeGen/RegAllocColor.o
 stage2/nativeGen/RegAllocInfo.o stage2/nativeGen/RegAllocLinear.o
 stage2/nativeGen/RegAllocStats.o stage2/nativeGen/RegArchBase.o
 stage2/nativeGen/RegArchX86.o stage2/nativeGen/RegCoalesce.o
 stage2/nativeGen/RegLiveness.o stage2/nativeGen/RegSpill.o
 stage2/nativeGen/RegSpillClean.o stage2/nativeGen/RegSpillCost.o
 stage2/ndpFlatten/FlattenInfo.o stage2/ndpFlatten/FlattenMonad.o
 stage2/ndpFlatten/Flattening.o stage2/ndpFlatten/NDPCoreUtils.o
 stage2/ndpFlatten/PArrAnal.o stage2/parser/Ctype.o
 stage2/parser/HaddockLex.o stage2/parser/HaddockParse.o
 stage2/parser/HaddockUtils.o stage2/parser/LexCore.o stage2/parser/Lexer.o
 stage2/parser/Parser.o stage2/parser/ParserCore.o
 stage2/parser/ParserCoreUtils.o stage2/parser/RdrHsSyn.o
 stage2/prelude/ForeignCall.o stage2/prelude/PrelInfo.o
 stage2/prelude/PrelNames.o stage2/prelude/PrelRules.o
 stage2/prelude/PrimOp.o stage2/prelude/TysPrim.o
 stage2/prelude/TysWiredIn.o stage2/profiling/CostCentre.o
 stage2/profiling/SCCfinal.o stage2/rename/RnBinds.o stage2/rename/RnEnv.o
 stage2/rename/RnExpr.o stage2/rename/RnHsDoc.o stage2/rename/RnHsSyn.o
 stage2/rename/RnNames.o stage2/rename/RnPat.o stage2/rename/RnSource.o
 stage2/rename/RnTypes.o stage2/simplCore/CSE.o stage2/simplCore/FloatIn.o
 stage2/simplCore/FloatOut.o stage2/simplCore/LiberateCase.o
 stage2/simplCore/OccurAnal.o stage2/simplCore/SAT.o
 stage2/simplCore/SATMonad.o stage2/simplCore/SetLevels.o
 stage2/simplCore/SimplCore.o stage2/simplCore/SimplEnv.o
 stage2/simplCore/SimplMonad.o stage2/simplCore/SimplUtils.o
 stage2/simplCore/Simplify.o stage2/simplStg/SRT.o
 stage2/simplStg/SimplStg.o stage2/simplStg/StgStats.o
 stage2/specialise/Rules.o stage2/specialise/SpecConstr.o
 stage2/specialise/Specialise.o stage2/stgSyn/CoreToStg.o
 stage2/stgSyn/StgLint.o stage2/stgSyn/StgSyn.o stage2/stranal/DmdAnal.o
 stage2/stranal/SaAbsInt.o stage2/stranal/SaLib.o
 stage2/stranal/StrictAnal.o stage2/stranal/WorkWrap.o
 stage2/stranal/WwLib.o stage2/typecheck/FamInst.o stage2/typecheck/Inst.o
 stage2/typecheck/TcArrows.o stage2/typecheck/TcBinds.o
 stage2/typecheck/TcClassDcl.o stage2/typecheck/TcDefaults.o
 stage2/typecheck/TcDeriv.o stage2/typecheck/TcEnv.o
 stage2/typecheck/TcExpr.o stage2/typecheck/TcForeign.o
 stage2/typecheck/TcGadt.o stage2/typecheck/TcGenDeriv.o
 stage2/typecheck/TcHsSyn.o stage2/typecheck/TcHsType.o
 stage2/typecheck/TcInstDcls.o stage2/typecheck/TcMType.o
 stage2/typecheck/TcMatches.o stage2/typecheck/TcPat.o
 stage2/typecheck/TcRnDriver.o stage2/typecheck/TcRnMonad.o
 stage2/typecheck/TcRnTypes.o stage2/typecheck/TcRules.o
 stage2/typecheck/TcSimplify.o stage2/typecheck/TcSplice.o
 stage2/typecheck/TcTyClsDecls.o stage2/typecheck/TcTyDecls.o
 stage2/typecheck/TcTyFuns.o stage2/typecheck/TcType.o
 stage2/typecheck/TcUnify.o stage2/types/Class.o stage2/types/Coercion.o
 stage2/types/FamInstEnv.o stage2/types/FunDeps.o stage2/types/Generics.o
 stage2/types/InstEnv.o stage2/types/TyCon.o stage2/types/Type.o
 stage2/types/TypeRep.o stage2/types/Unify.o stage2/utils/Bag.o
 stage2/utils/Binary.o stage2/utils/BufWrite.o stage2/utils/Digraph.o
 stage2/utils/Encoding.o stage2/utils/FastBool.o
 stage2/utils/FastFunctions.o stage2/utils/FastMutInt.o
 stage2/utils/FastString.o stage2/utils/FastTypes.o
 stage2/utils/FiniteMap.o stage2/utils/GraphBase.o
 stage2/utils/GraphColor.o stage2/utils/GraphOps.o stage2/utils/GraphPpr.o
 stage2/utils/IOEnv.o stage2/utils/Interval.o stage2/utils/ListSetOps.o
 stage2/utils/Maybes.o stage2/utils/OrdList.o stage2/utils/Outputable.o
 stage2/utils/Panic.o stage2/utils/Pretty.o stage2/utils/State.o
 stage2/utils/StringBuffer.o stage2/utils/UniqFM.o stage2/utils/UniqSet.o
 stage2/utils/Util.o stage2/vectorise/VectBuiltIn.o
 stage2/vectorise/VectCore.o stage2/vectorise/VectMonad.o
 stage2/vectorise/VectType.o stage2/vectorise/VectUtils.o
 stage2/vectorise/Vectorise.o stage2/parser/cutils.o
 make[2]: *** [HSghc.o] Bus error
 make[2]: *** Deleting file `HSghc.o'
 make[1]: *** [stage2] Error 2
 make: *** [bootstrap2] Error 2
 }}}
 Further, with
 {{{
 SRC_HC_OPTS   = -H32m -O2 -fvia-C
 GhcHcOpts     = -Rghc-timing
 GhcLibHcOpts  =
 GhcLibWays    =
 }}}
 in mk/build.mk, the result is
 {{{
 ../../compiler/stage1/ghc-inplace -package-name base-3.0 -hide-all-
 packages -split-objs -i -idist/build/autogen -idist/build -i. -Idist/build
 -Iinclude -#include "HsBase.h" -odir dist/build -hidir dist/build -stubdir
 dist/build -package rts-1.0 -O -fglasgow-exts -package-name base -XCPP
 -idist/build  -H32m -O2 -fvia-C  -c Foreign/C/Error.hs -o
 dist/build/Foreign/C/Error.o  -ohi dist/build/Foreign/C/Error.hi
 /tmp/ghc13816_0/ghc13816_0.split__1.s:unknown:Undefined local symbol
 L_strerror$UNIX2003$stub
 make[2]: *** [dist/build/Foreign/C/Error.o] Error 1
 make[1]: *** [make.library.base] Error 2
 make: *** [stage1] Error 2
 }}}
 This could well be the same problem reported in
 http://hackage.haskell.org/trac/ghc/ticket/2012.  And, finally
 {{{
 SRC_HC_OPTS   = -H32m -O2 -fvia-C
 GhcHcOpts     = -Rghc-timing
 GhcLibHcOpts  =
 GhcLibWays    =
 SplitObjs     = NO
 }}}
 ends with
 {{{
 /usr/bin/ld -r -x -o HSghc.o  stage2/basicTypes/BasicTypes.o
 stage2/basicTypes/DataCon.o stage2/basicTypes/Demand.o
 stage2/basicTypes/Id.o stage2/basicTypes/IdInfo.o
 stage2/basicTypes/Literal.o stage2/basicTypes/MkId.o
 stage2/basicTypes/Module.o stage2/basicTypes/Name.o
 stage2/basicTypes/NameEnv.o stage2/basicTypes/NameSet.o
 stage2/basicTypes/NewDemand.o stage2/basicTypes/OccName.o
 stage2/basicTypes/RdrName.o stage2/basicTypes/SrcLoc.o
 stage2/basicTypes/UniqSupply.o stage2/basicTypes/Unique.o
 stage2/basicTypes/Var.o stage2/basicTypes/VarEnv.o
 stage2/basicTypes/VarSet.o stage2/cmm/CLabel.o stage2/cmm/Cmm.o
 stage2/cmm/CmmBrokenBlock.o stage2/cmm/CmmCPS.o stage2/cmm/CmmCPSGen.o
 stage2/cmm/CmmCPSZ.o stage2/cmm/CmmCallConv.o stage2/cmm/CmmContFlowOpt.o
 stage2/cmm/CmmCvt.o stage2/cmm/CmmExpr.o stage2/cmm/CmmInfo.o
 stage2/cmm/CmmLex.o stage2/cmm/CmmLint.o stage2/cmm/CmmLive.o
 stage2/cmm/CmmLiveZ.o stage2/cmm/CmmOpt.o stage2/cmm/CmmParse.o
 stage2/cmm/CmmProcPoint.o stage2/cmm/CmmProcPointZ.o
 stage2/cmm/CmmSpillReload.o stage2/cmm/CmmTx.o stage2/cmm/CmmUtils.o
 stage2/cmm/CmmZipUtil.o stage2/cmm/DFMonad.o stage2/cmm/Dataflow.o
 stage2/cmm/MachOp.o stage2/cmm/MkZipCfg.o stage2/cmm/MkZipCfgCmm.o
 stage2/cmm/OptimizationFuel.o stage2/cmm/PprC.o stage2/cmm/PprCmm.o
 stage2/cmm/PprCmmZ.o stage2/cmm/StackColor.o stage2/cmm/StackPlacements.o
 stage2/cmm/ZipCfg.o stage2/cmm/ZipCfgCmmRep.o stage2/cmm/ZipCfgExtras.o
 stage2/cmm/ZipDataflow0.o stage2/codeGen/Bitmap.o
 stage2/codeGen/CgBindery.o stage2/codeGen/CgCallConv.o
 stage2/codeGen/CgCase.o stage2/codeGen/CgClosure.o stage2/codeGen/CgCon.o
 stage2/codeGen/CgExpr.o stage2/codeGen/CgForeignCall.o
 stage2/codeGen/CgHeapery.o stage2/codeGen/CgHpc.o
 stage2/codeGen/CgInfoTbls.o stage2/codeGen/CgLetNoEscape.o
 stage2/codeGen/CgMonad.o stage2/codeGen/CgParallel.o
 stage2/codeGen/CgPrimOp.o stage2/codeGen/CgProf.o
 stage2/codeGen/CgStackery.o stage2/codeGen/CgTailCall.o
 stage2/codeGen/CgTicky.o stage2/codeGen/CgUtils.o
 stage2/codeGen/ClosureInfo.o stage2/codeGen/CodeGen.o
 stage2/codeGen/SMRep.o stage2/coreSyn/CoreFVs.o stage2/coreSyn/CoreLint.o
 stage2/coreSyn/CorePrep.o stage2/coreSyn/CoreSubst.o
 stage2/coreSyn/CoreSyn.o stage2/coreSyn/CoreTidy.o
 stage2/coreSyn/CoreUnfold.o stage2/coreSyn/CoreUtils.o
 stage2/coreSyn/ExternalCore.o stage2/coreSyn/MkExternalCore.o
 stage2/coreSyn/PprCore.o stage2/coreSyn/PprExternalCore.o
 stage2/cprAnalysis/CprAnalyse.o stage2/deSugar/Check.o
 stage2/deSugar/Coverage.o stage2/deSugar/Desugar.o
 stage2/deSugar/DsArrows.o stage2/deSugar/DsBinds.o
 stage2/deSugar/DsCCall.o stage2/deSugar/DsExpr.o
 stage2/deSugar/DsForeign.o stage2/deSugar/DsGRHSs.o
 stage2/deSugar/DsListComp.o stage2/deSugar/DsMeta.o
 stage2/deSugar/DsMonad.o stage2/deSugar/DsUtils.o stage2/deSugar/Match.o
 stage2/deSugar/MatchCon.o stage2/deSugar/MatchLit.o
 stage2/ghci/ByteCodeAsm.o stage2/ghci/ByteCodeFFI.o
 stage2/ghci/ByteCodeGen.o stage2/ghci/ByteCodeInstr.o
 stage2/ghci/ByteCodeItbls.o stage2/ghci/ByteCodeLink.o
 stage2/ghci/Debugger.o stage2/ghci/GhciMonad.o stage2/ghci/GhciTags.o
 stage2/ghci/InteractiveUI.o stage2/ghci/Linker.o stage2/ghci/ObjLink.o
 stage2/ghci/RtClosureInspect.o stage2/hsSyn/Convert.o
 stage2/hsSyn/HsBinds.o stage2/hsSyn/HsDecls.o stage2/hsSyn/HsDoc.o
 stage2/hsSyn/HsExpr.o stage2/hsSyn/HsImpExp.o stage2/hsSyn/HsLit.o
 stage2/hsSyn/HsPat.o stage2/hsSyn/HsSyn.o stage2/hsSyn/HsTypes.o
 stage2/hsSyn/HsUtils.o stage2/iface/BinIface.o stage2/iface/BuildTyCl.o
 stage2/iface/IfaceEnv.o stage2/iface/IfaceSyn.o stage2/iface/IfaceType.o
 stage2/iface/LoadIface.o stage2/iface/MkIface.o stage2/iface/TcIface.o
 stage2/main/BreakArray.o stage2/main/CmdLineParser.o
 stage2/main/CodeOutput.o stage2/main/Config.o stage2/main/Constants.o
 stage2/main/DriverMkDepend.o stage2/main/DriverPhases.o
 stage2/main/DriverPipeline.o stage2/main/DynFlags.o stage2/main/ErrUtils.o
 stage2/main/Finder.o stage2/main/GHC.o stage2/main/HeaderInfo.o
 stage2/main/HscMain.o stage2/main/HscStats.o stage2/main/HscTypes.o
 stage2/main/InteractiveEval.o stage2/main/PackageConfig.o
 stage2/main/Packages.o stage2/main/ParsePkgConf.o stage2/main/PprTyThing.o
 stage2/main/StaticFlags.o stage2/main/SysTools.o stage2/main/TidyPgm.o
 stage2/nativeGen/AsmCodeGen.o stage2/nativeGen/MachCodeGen.o
 stage2/nativeGen/MachInstrs.o stage2/nativeGen/MachRegs.o
 stage2/nativeGen/NCGMonad.o stage2/nativeGen/PositionIndependentCode.o
 stage2/nativeGen/PprMach.o stage2/nativeGen/RegAllocColor.o
 stage2/nativeGen/RegAllocInfo.o stage2/nativeGen/RegAllocLinear.o
 stage2/nativeGen/RegAllocStats.o stage2/nativeGen/RegArchBase.o
 stage2/nativeGen/RegArchX86.o stage2/nativeGen/RegCoalesce.o
 stage2/nativeGen/RegLiveness.o stage2/nativeGen/RegSpill.o
 stage2/nativeGen/RegSpillClean.o stage2/nativeGen/RegSpillCost.o
 stage2/ndpFlatten/FlattenInfo.o stage2/ndpFlatten/FlattenMonad.o
 stage2/ndpFlatten/Flattening.o stage2/ndpFlatten/NDPCoreUtils.o
 stage2/ndpFlatten/PArrAnal.o stage2/parser/Ctype.o
 stage2/parser/HaddockLex.o stage2/parser/HaddockParse.o
 stage2/parser/HaddockUtils.o stage2/parser/LexCore.o stage2/parser/Lexer.o
 stage2/parser/Parser.o stage2/parser/ParserCore.o
 stage2/parser/ParserCoreUtils.o stage2/parser/RdrHsSyn.o
 stage2/prelude/ForeignCall.o stage2/prelude/PrelInfo.o
 stage2/prelude/PrelNames.o stage2/prelude/PrelRules.o
 stage2/prelude/PrimOp.o stage2/prelude/TysPrim.o
 stage2/prelude/TysWiredIn.o stage2/profiling/CostCentre.o
 stage2/profiling/SCCfinal.o stage2/rename/RnBinds.o stage2/rename/RnEnv.o
 stage2/rename/RnExpr.o stage2/rename/RnHsDoc.o stage2/rename/RnHsSyn.o
 stage2/rename/RnNames.o stage2/rename/RnPat.o stage2/rename/RnSource.o
 stage2/rename/RnTypes.o stage2/simplCore/CSE.o stage2/simplCore/FloatIn.o
 stage2/simplCore/FloatOut.o stage2/simplCore/LiberateCase.o
 stage2/simplCore/OccurAnal.o stage2/simplCore/SAT.o
 stage2/simplCore/SATMonad.o stage2/simplCore/SetLevels.o
 stage2/simplCore/SimplCore.o stage2/simplCore/SimplEnv.o
 stage2/simplCore/SimplMonad.o stage2/simplCore/SimplUtils.o
 stage2/simplCore/Simplify.o stage2/simplStg/SRT.o
 stage2/simplStg/SimplStg.o stage2/simplStg/StgStats.o
 stage2/specialise/Rules.o stage2/specialise/SpecConstr.o
 stage2/specialise/Specialise.o stage2/stgSyn/CoreToStg.o
 stage2/stgSyn/StgLint.o stage2/stgSyn/StgSyn.o stage2/stranal/DmdAnal.o
 stage2/stranal/SaAbsInt.o stage2/stranal/SaLib.o
 stage2/stranal/StrictAnal.o stage2/stranal/WorkWrap.o
 stage2/stranal/WwLib.o stage2/typecheck/FamInst.o stage2/typecheck/Inst.o
 stage2/typecheck/TcArrows.o stage2/typecheck/TcBinds.o
 stage2/typecheck/TcClassDcl.o stage2/typecheck/TcDefaults.o
 stage2/typecheck/TcDeriv.o stage2/typecheck/TcEnv.o
 stage2/typecheck/TcExpr.o stage2/typecheck/TcForeign.o
 stage2/typecheck/TcGadt.o stage2/typecheck/TcGenDeriv.o
 stage2/typecheck/TcHsSyn.o stage2/typecheck/TcHsType.o
 stage2/typecheck/TcInstDcls.o stage2/typecheck/TcMType.o
 stage2/typecheck/TcMatches.o stage2/typecheck/TcPat.o
 stage2/typecheck/TcRnDriver.o stage2/typecheck/TcRnMonad.o
 stage2/typecheck/TcRnTypes.o stage2/typecheck/TcRules.o
 stage2/typecheck/TcSimplify.o stage2/typecheck/TcSplice.o
 stage2/typecheck/TcTyClsDecls.o stage2/typecheck/TcTyDecls.o
 stage2/typecheck/TcTyFuns.o stage2/typecheck/TcType.o
 stage2/typecheck/TcUnify.o stage2/types/Class.o stage2/types/Coercion.o
 stage2/types/FamInstEnv.o stage2/types/FunDeps.o stage2/types/Generics.o
 stage2/types/InstEnv.o stage2/types/TyCon.o stage2/types/Type.o
 stage2/types/TypeRep.o stage2/types/Unify.o stage2/utils/Bag.o
 stage2/utils/Binary.o stage2/utils/BufWrite.o stage2/utils/Digraph.o
 stage2/utils/Encoding.o stage2/utils/FastBool.o
 stage2/utils/FastFunctions.o stage2/utils/FastMutInt.o
 stage2/utils/FastString.o stage2/utils/FastTypes.o
 stage2/utils/FiniteMap.o stage2/utils/GraphBase.o
 stage2/utils/GraphColor.o stage2/utils/GraphOps.o stage2/utils/GraphPpr.o
 stage2/utils/IOEnv.o stage2/utils/Interval.o stage2/utils/ListSetOps.o
 stage2/utils/Maybes.o stage2/utils/OrdList.o stage2/utils/Outputable.o
 stage2/utils/Panic.o stage2/utils/Pretty.o stage2/utils/State.o
 stage2/utils/StringBuffer.o stage2/utils/UniqFM.o stage2/utils/UniqSet.o
 stage2/utils/Util.o stage2/vectorise/VectBuiltIn.o
 stage2/vectorise/VectCore.o stage2/vectorise/VectMonad.o
 stage2/vectorise/VectType.o stage2/vectorise/VectUtils.o
 stage2/vectorise/Vectorise.o stage2/parser/cutils.o
 ld: scattered reloc r_address too large for inferred architecture ppc
 make[2]: *** [HSghc.o] Error 1
 make[1]: *** [stage2] Error 2
 make: *** [bootstrap2] Error 2
 }}}
 This has been reported earlier in
 http://hackage.haskell.org/trac/ghc/ticket/1843. I will assume that this
 is simply a different symptom of the same basic problem with the Apple
 linker, but if anyone sees this differently, feel free to report a
 separate bug.

 All in all, fairly entertaining.

 Some additional lines of work include:
  1. Actually debugging the Apple linker:
  http://www.haskell.org/pipermail/glasgow-haskell-
 users/2007-November/013489.html and
  http://www.haskell.org/pipermail/glasgow-haskell-
 users/2007-November/013447.html have some
  details about this. I have started an attempt to continue this, but I am
 not done yet. In
  any case, although I have requested a status on the issue reported to
 Apple, I have not
  heard anything, so it seems unlikely that we are going to see some sort
 of solution
  from that source anytime soon.
  2. Figuring out how to, possibly, generate different code that works
 around the linker
  problem. I don't feel particularly competent in this respect, a lot of
 study would be
  required for me to work on this effectively. So if some expert in these
 matters
  would be willing to give a few hints, whether such a line of work is
 likely to
  succeed, I would be very grateful.
  3. In particular, some better understanding of the difference between
 using
  {{{.const_data}}} and {{{.text}}} would be useful. And thereby some
 indication of
  whether the work-around patch the I attached makes sense at all.

 As always, additional ideas for investigating this problem are most
 welcome.

 Best regards
 Thorkil

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/1958#comment:11>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Mon Jan 21 05:18:54 2008
From: trac at galois.com (GHC)
Date: Mon Jan 21 05:18:44 2008
Subject: [GHC] #1735: unused binding changes program behaviour
In-Reply-To: <044.165e86ea1e61301d33d53cf154829fac@localhost>
References: <044.165e86ea1e61301d33d53cf154829fac@localhost>
Message-ID: <053.15de208d53fda5e9c254a2bdc56030ca@localhost>

#1735: unused binding changes program behaviour
----------------------+-----------------------------------------------------
 Reporter:  igloo     |          Owner:  simonpj
     Type:  bug       |         Status:  new    
 Priority:  normal    |      Milestone:  6.8.3  
Component:  Compiler  |        Version:  6.8    
 Severity:  normal    |     Resolution:         
 Keywords:            |     Difficulty:  Unknown
 Testcase:            |   Architecture:  Unknown
       Os:  Unknown   |  
----------------------+-----------------------------------------------------
Changes (by simonmar):

  * owner:  => simonpj

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/1735#comment:3>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Mon Jan 21 07:09:39 2008
From: trac at galois.com (GHC)
Date: Mon Jan 21 07:09:28 2008
Subject: [GHC] #2059: Erroneous results in trigonometric functions for >
 double-precision values
In-Reply-To: <056.3e619538850693ad9b65e875780ac3cb@localhost>
References: <056.3e619538850693ad9b65e875780ac3cb@localhost>
Message-ID: <065.832fbb8f3eb427708dafea39aa3fdfb3@localhost>

#2059: Erroneous results in trigonometric functions for > double-precision values
----------------------------------+-----------------------------------------
    Reporter:  daniel.is.fischer  |        Owner:       
        Type:  feature request    |       Status:  new  
    Priority:  normal             |    Milestone:       
   Component:  Compiler           |      Version:  6.8.1
    Severity:  normal             |   Resolution:       
    Keywords:                     |     Testcase:       
Architecture:  x86                |           Os:  Linux
----------------------------------+-----------------------------------------
Comment (by Frederik):

 I thought that the value of 'cos' and 'sin' should be between -1 and 1. Is
 1e20 really the closest we can afford to get to this interval? gcc does
 much better:
 {{{
 $ cat t.c
 #include <math.h>
 #include <stdio.h>

 int main() {
   printf("%lf\n",cos(1e20));
   return 0;
 }
 $ gcc t.c -lm
 $ ./a.out
 -0.664912
 }}}
 This answer may not be very meaningful, but at least it is in the proper
 range.

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/2059#comment:2>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Mon Jan 21 07:24:00 2008
From: trac at galois.com (GHC)
Date: Mon Jan 21 07:23:51 2008
Subject: [GHC] #2047: ghc compiled program crashes with segfault when
 using -M and/or -c
In-Reply-To: <042.76ffc0b2217121d0a72a366715d60678@localhost>
References: <042.76ffc0b2217121d0a72a366715d60678@localhost>
Message-ID: <051.f0a4dd6561fe96e34bdf43487815cfc6@localhost>

#2047: ghc compiled program crashes with segfault when using -M and/or -c
----------------------------+-----------------------------------------------
 Reporter:  mte             |          Owner:         
     Type:  bug             |         Status:  new    
 Priority:  normal          |      Milestone:  6.8.3  
Component:  Runtime System  |        Version:  6.8.2  
 Severity:  critical        |     Resolution:         
 Keywords:  gc segfault     |     Difficulty:  Unknown
 Testcase:                  |   Architecture:  x86    
       Os:  Windows         |  
----------------------------+-----------------------------------------------
Comment (by mte):

 Simon, I need a valid email address of yours. I tried to send the source
 code to simonmar at research.microsoft.com but the delivery failed.

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/2047#comment:2>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Mon Jan 21 07:27:00 2008
From: trac at galois.com (GHC)
Date: Mon Jan 21 07:26:50 2008
Subject: [GHC] #2047: ghc compiled program crashes with segfault when
 using -M and/or -c
In-Reply-To: <042.76ffc0b2217121d0a72a366715d60678@localhost>
References: <042.76ffc0b2217121d0a72a366715d60678@localhost>
Message-ID: <051.4f9c87a82bed8b01bbcd6f979935bb4d@localhost>

#2047: ghc compiled program crashes with segfault when using -M and/or -c
----------------------------+-----------------------------------------------
 Reporter:  mte             |          Owner:         
     Type:  bug             |         Status:  new    
 Priority:  normal          |      Milestone:  6.8.3  
Component:  Runtime System  |        Version:  6.8.2  
 Severity:  critical        |     Resolution:         
 Keywords:  gc segfault     |     Difficulty:  Unknown
 Testcase:                  |   Architecture:  x86    
       Os:  Windows         |  
----------------------------+-----------------------------------------------
Comment (by simonmar):

 You want [mailto:simonmar@microsoft.com].

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/2047#comment:3>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Mon Jan 21 07:29:57 2008
From: trac at galois.com (GHC)
Date: Mon Jan 21 07:29:47 2008
Subject: [GHC] #1839: need ghc-pkg dump feature
In-Reply-To: <045.e765af751a0d91f5b4a56c8391184f46@localhost>
References: <045.e765af751a0d91f5b4a56c8391184f46@localhost>
Message-ID: <054.80da6f198b972ad6986951a13e3f226f@localhost>

#1839: need ghc-pkg dump feature
-----------------------------+----------------------------------------------
 Reporter:  duncan           |          Owner:         
     Type:  feature request  |         Status:  new    
 Priority:  normal           |      Milestone:  6.8.3  
Component:  Compiler         |        Version:  6.8.1  
 Severity:  normal           |     Resolution:         
 Keywords:                   |     Difficulty:  Unknown
 Testcase:                   |   Architecture:  Unknown
       Os:  Unknown          |  
-----------------------------+----------------------------------------------
Comment (by simonmar):

 It seems that `CRT_noglob.o` can be generated by compiling

 {{{
 unsigned long _CRT_glob = 0;
 }}}

 so to avoid needing to find the location of MingW or to ship
 `CRT_noglob.o` with GHC, I'm going to just add this to `utils/ghc-pkg`.
 That seems the easiest solution to me.

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/1839#comment:10>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Mon Jan 21 07:44:42 2008
From: trac at galois.com (GHC)
Date: Mon Jan 21 07:44:32 2008
Subject: [GHC] #2055: Incorrect warning about qualified import
In-Reply-To: <045.978b49f7a0b20b3e110c31c474744c60@localhost>
References: <045.978b49f7a0b20b3e110c31c474744c60@localhost>
Message-ID: <054.16179cb89d6668565490286c268f1ade@localhost>

#2055: Incorrect warning about qualified import
----------------------+-----------------------------------------------------
 Reporter:  duncan    |          Owner:         
     Type:  bug       |         Status:  closed 
 Priority:  normal    |      Milestone:         
Component:  Compiler  |        Version:  6.9    
 Severity:  normal    |     Resolution:  fixed  
 Keywords:            |     Difficulty:  Unknown
 Testcase:  rn062     |   Architecture:  Unknown
       Os:  Unknown   |  
----------------------+-----------------------------------------------------
Changes (by simonpj):

  * testcase:  => rn062
  * difficulty:  => Unknown
  * status:  new => closed
  * resolution:  => fixed

Comment:

 Sorry, my fault. Fixed now.  No need to merge... it's HEAD only.

 Simon

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/2055#comment:1>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Mon Jan 21 08:12:26 2008
From: trac at galois.com (GHC)
Date: Mon Jan 21 08:12:17 2008
Subject: [GHC] #2054: :history doesn't work if :trace is not used
 initially
In-Reply-To: <044.fb0075e819aa0a0bed0834f203038504@localhost>
References: <044.fb0075e819aa0a0bed0834f203038504@localhost>
Message-ID: <053.b4e5ab6cacfd7963812b96e350b75e1a@localhost>

#2054: :history doesn't work if :trace is not used initially
---------------------+------------------------------------------------------
 Reporter:  igloo    |          Owner:         
     Type:  bug      |         Status:  closed 
 Priority:  normal   |      Milestone:  6.8.3  
Component:  GHCi     |        Version:  6.8.2  
 Severity:  normal   |     Resolution:  invalid
 Keywords:           |     Difficulty:  Unknown
 Testcase:           |   Architecture:  Unknown
       Os:  Unknown  |  
---------------------+------------------------------------------------------
Changes (by simonmar):

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

Comment:

 This is the correct result.  `main` is a CAF (see
 [http://www.haskell.org/haskellwiki/Constant_applicative_form]), so the
 breakpoint is only seen the first time it is evaluated.  This is, I claim,
 what you want: GHC is telling you that it didn't need to evaluate that
 breakpoint the second time.

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/2054#comment:2>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Mon Jan 21 08:20:53 2008
From: trac at galois.com (GHC)
Date: Mon Jan 21 08:20:45 2008
Subject: [GHC] #2057: inconsistent .hi file error gets ignored
In-Reply-To: <045.e53c768183aca8a1a40fddc456cadee9@localhost>
References: <045.e53c768183aca8a1a40fddc456cadee9@localhost>
Message-ID: <054.d5ab0c3f9fc4cf1f9c82910c41b6d6a6@localhost>

#2057: inconsistent .hi file error gets ignored
----------------------+-----------------------------------------------------
 Reporter:  duncan    |          Owner:         
     Type:  bug       |         Status:  new    
 Priority:  normal    |      Milestone:         
Component:  Compiler  |        Version:  6.8.2  
 Severity:  normal    |     Resolution:         
 Keywords:            |     Difficulty:  Unknown
 Testcase:            |   Architecture:  Unknown
       Os:  Unknown   |  
----------------------+-----------------------------------------------------
Changes (by simonmar):

  * difficulty:  => Unknown

Comment:

 I'm not sure that "fixing" this by having the compilation fail is the
 right thing to do.  GHC in one-shot mode is working on the assumption that
 the dependencies of the current module are up-to-date, and it is the
 user's responsibility to get that right.  Given this assumption, GHC
 buries the code that typechecks interface declarations into thunks that
 might be evaluated at any time, so to have one of these throw an exception
 might lead to any number of strange and hard-to-reproduce problems - we
 might be half-way through some IO operation, and who knows what will
 happen if we abort.

 Arguably you're getting strange and hard-to-reproduce problems anyway, and
 it might be better to fail earlier.  It just scares me a bit.

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/2057#comment:1>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From frederik at a5.repetae.net  Mon Jan 21 08:22:29 2008
From: frederik at a5.repetae.net (Frederik Eaton)
Date: Mon Jan 21 08:22:25 2008
Subject: Debian i386 packages: cgi, network
Message-ID: <20080121132229.GR11635@a5.repetae.net>

Hello Ian,

I've just noticed that there seem to be ghc-6.8.2 compatible packages
for some modules on Debian amd64 but not i386:

----------------
$ sudo apt-get install -t experimental libghc6-{cgi,network}-dev
...
The following packages have unmet dependencies:
  libghc6-cgi-dev: Depends: ghc6 (< 6.6.1+) but 6.8.2-1 is to be installed
  libghc6-network-dev: Depends: ghc6 (< 6.6.1+) but 6.8.2-1 is to be installed
----------------

I assume that the matter is in hand, but just wanted to give a
heads-up in case you didn't know.

Thanks,

Frederik
From trac at galois.com  Mon Jan 21 08:29:15 2008
From: trac at galois.com (GHC)
Date: Mon Jan 21 08:29:06 2008
Subject: [GHC] #1826: unable to list source for <exception thrown>
 should never occur
In-Reply-To: <044.f94ec6280873c17dbdd2473c81e3b4a3@localhost>
References: <044.f94ec6280873c17dbdd2473c81e3b4a3@localhost>
Message-ID: <053.64e3287703940b4adfcfee6d9da7b330@localhost>

#1826: unable to list source for <exception thrown> should never occur
-----------------------------+----------------------------------------------
 Reporter:  guest            |          Owner:             
     Type:  feature request  |         Status:  reopened   
 Priority:  low              |      Milestone:  6.8.3      
Component:  GHCi             |        Version:  6.8.1      
 Severity:  normal           |     Resolution:             
 Keywords:                   |     Difficulty:  Easy (1 hr)
 Testcase:                   |   Architecture:  Multiple   
       Os:  Multiple         |  
-----------------------------+----------------------------------------------
Changes (by igloo):

  * priority:  normal => low
  * status:  closed => reopened
  * resolution:  fixed =>

Comment:

 Ah, so actually the `:trace` detection doesn't work if you `:trace` an
 already evaluated CAF, so sometimes the error will tell you to use
 `:trace` when you already are doing.

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/1826#comment:8>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Mon Jan 21 09:24:25 2008
From: trac at galois.com (GHC)
Date: Mon Jan 21 09:24:15 2008
Subject: [GHC] #2059: Erroneous results in trigonometric functions for >
 double-precision values
In-Reply-To: <056.3e619538850693ad9b65e875780ac3cb@localhost>
References: <056.3e619538850693ad9b65e875780ac3cb@localhost>
Message-ID: <065.e324a6235fa4d7ad04e6f1a69c64651c@localhost>

#2059: Erroneous results in trigonometric functions for > double-precision values
----------------------------------+-----------------------------------------
    Reporter:  daniel.is.fischer  |        Owner:       
        Type:  feature request    |       Status:  new  
    Priority:  normal             |    Milestone:       
   Component:  Compiler           |      Version:  6.8.1
    Severity:  normal             |   Resolution:       
    Keywords:                     |     Testcase:       
Architecture:  x86                |           Os:  Linux
----------------------------------+-----------------------------------------
Comment (by daniel.is.fischer):

 I reported it because the behaviour was different up to 6.6.1, didn't
 expect it to be an intentional change (not that I'd rely on even the sign
 of the result for such large inputs).

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/2059#comment:3>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Mon Jan 21 10:02:16 2008
From: trac at galois.com (GHC)
Date: Mon Jan 21 10:02:06 2008
Subject: [GHC] #2059: Erroneous results in trigonometric functions for >
 double-precision values
In-Reply-To: <056.3e619538850693ad9b65e875780ac3cb@localhost>
References: <056.3e619538850693ad9b65e875780ac3cb@localhost>
Message-ID: <065.ab1faad0babdbd72d75d6b608d2f475f@localhost>

#2059: Erroneous results in trigonometric functions for > double-precision values
----------------------------------+-----------------------------------------
    Reporter:  daniel.is.fischer  |        Owner:       
        Type:  bug                |       Status:  new  
    Priority:  normal             |    Milestone:       
   Component:  Compiler           |      Version:  6.8.1
    Severity:  normal             |   Resolution:       
    Keywords:                     |     Testcase:       
Architecture:  x86                |           Os:  Linux
----------------------------------+-----------------------------------------
Changes (by Frederik):

  * type:  feature request => bug

Comment:

 I see that GHC 6.4.2 gives the same results as C
 {{{
 Prelude> cos(1e20)
 -0.6649117899070088
 }}}

 Ajd, I hope it is OK to change this back to a bug, it certainly seems more
 than a feature request...

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/2059#comment:4>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Tue Jan 22 09:14:16 2008
From: trac at galois.com (GHC)
Date: Tue Jan 22 09:14:42 2008
Subject: [GHC] #1838: do not use getEnv "HOME",
 use System.Directory.getHomeDirectory
In-Reply-To: <044.7c14aad23d72fc1f99272ac17d7d5b67@localhost>
References: <044.7c14aad23d72fc1f99272ac17d7d5b67@localhost>
Message-ID: <053.d09c79e25fcc1685533ed589e41634f5@localhost>

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

  * owner:  => simonmar

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/1838#comment:6>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Tue Jan 22 10:30:01 2008
From: trac at galois.com (GHC)
Date: Tue Jan 22 10:29:47 2008
Subject: [GHC] #1767: :show <setting> does not conform to documented
 specification
In-Reply-To: <044.e7adae11ca7979e3093e064a998ae30d@localhost>
References: <044.e7adae11ca7979e3093e064a998ae30d@localhost>
Message-ID: <053.6acd5cf1454e68cb2fbbb6d870417fd6@localhost>

#1767: :show <setting> does not conform to documented specification
---------------------+------------------------------------------------------
 Reporter:  guest    |          Owner:  simonmar
     Type:  bug      |         Status:  new     
 Priority:  normal   |      Milestone:  6.8.3   
Component:  GHCi     |        Version:  6.9     
 Severity:  normal   |     Resolution:          
 Keywords:           |     Difficulty:  Unknown 
 Testcase:           |   Architecture:  Unknown 
       Os:  Unknown  |  
---------------------+------------------------------------------------------
Changes (by simonmar):

  * owner:  => simonmar

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/1767#comment:4>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From Christian.Maeder at dfki.de  Tue Jan 22 10:55:58 2008
From: Christian.Maeder at dfki.de (Christian Maeder)
Date: Tue Jan 22 10:55:45 2008
Subject: Integrating editline with ghc
In-Reply-To: <20080122150542.6aa711dc.Malcolm.Wallace@cs.york.ac.uk>
References: <6d74b0d20801161305na9e0732m2a6bae7098ec531d@mail.gmail.com>	<478F1DB8.1080807@dfki.de>	<3089E693-CBAE-463B-97EC-328DAC4E36E5@cse.unsw.edu.au>	<47906B7A.6050407@dfki.de>	<6BD28026-7344-4A99-9E8D-A55C318BF10E@cse.unsw.edu.au>	<4795BCE9.6080205@dfki.de>	<2608b8a80801220340h1cb7d244m17e3eebf89c23c45@mail.gmail.com>	<4795E1C1.9020506@dfki.de>	<2608b8a80801220624g4f3b7f6m1bc6ebdbba48e3e5@mail.gmail.com>
	<20080122150542.6aa711dc.Malcolm.Wallace@cs.york.ac.uk>
Message-ID: <4796120E.8060101@dfki.de>

Malcolm Wallace wrote:
> I think I am persuaded that this is the most important goal: stability
> of the API and package interface, for existing clients of readline.  If
> individual projects would like to migrate from using readline to using
> editline, then those are the ones that should pay the small amount of
> pain (in using CPP, package configurations, etc) to manage the change.
> 
> Anyone else should be totally unaffected.

I would like to know from package maintainers if there packages can be
easily ported from libreadline to libedit.

The best indication for this would be if the package is also happy with
a restricted interface of readline (i.e. readline-compat) or requires
the full GNU readline.

At least testing this compatibility makes sense using a readline package
with a temporarily reduced interface (without the need to change the
packages depending on readline.)

Christian

From trac at galois.com  Tue Jan 22 11:14:31 2008
From: trac at galois.com (GHC)
Date: Tue Jan 22 11:14:17 2008
Subject: [GHC] #2049: GHCi doesn't fully load previously broken modules
In-Reply-To: <042.e75e264362dd101a1f793da2344243d7@localhost>
References: <042.e75e264362dd101a1f793da2344243d7@localhost>
Message-ID: <051.0976e1e141dd37383666df92ccd7924b@localhost>

#2049: GHCi doesn't fully load previously broken modules
---------------------+------------------------------------------------------
 Reporter:  ajd      |          Owner:  simonmar
     Type:  bug      |         Status:  new     
 Priority:  normal   |      Milestone:  6.8.3   
Component:  GHCi     |        Version:  6.8.2   
 Severity:  normal   |     Resolution:          
 Keywords:           |     Difficulty:  Unknown 
 Testcase:           |   Architecture:  Unknown 
       Os:  Unknown  |  
---------------------+------------------------------------------------------
Changes (by simonmar):

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

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/2049#comment:2>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Tue Jan 22 11:15:48 2008
From: trac at galois.com (GHC)
Date: Tue Jan 22 11:15:34 2008
Subject: [GHC] #2049: GHCi doesn't fully load previously broken modules
In-Reply-To: <042.e75e264362dd101a1f793da2344243d7@localhost>
References: <042.e75e264362dd101a1f793da2344243d7@localhost>
Message-ID: <051.726fe9dc36562ae2149426e18a0d7369@localhost>

#2049: GHCi doesn't fully load previously broken modules
---------------------+------------------------------------------------------
 Reporter:  ajd      |          Owner:  igloo  
     Type:  merge    |         Status:  new    
 Priority:  normal   |      Milestone:  6.8.3  
Component:  GHCi     |        Version:  6.8.2  
 Severity:  normal   |     Resolution:         
 Keywords:           |     Difficulty:  Unknown
 Testcase:           |   Architecture:  Unknown
       Os:  Unknown  |  
---------------------+------------------------------------------------------
Changes (by simonmar):

  * owner:  simonmar => igloo
  * type:  bug => merge

Comment:

 Fixed, to merge:

 {{{
 Mon Jan 21 06:59:35 PST 2008  Simon Marlow <simonmar@microsoft.com>
   * FIX #2049, another problem with the module context on :reload
 }}}

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/2049#comment:3>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Tue Jan 22 11:23:11 2008
From: trac at galois.com (GHC)
Date: Tue Jan 22 11:22:57 2008
Subject: [GHC] #1136: High memory use when compiling many let bindings.
In-Reply-To: <044.2f9aae100a9caba688d31e410efb3444@localhost>
References: <044.2f9aae100a9caba688d31e410efb3444@localhost>
Message-ID: <053.e4c0ceab60cae57de1d8713989bc3d0e@localhost>

#1136: High memory use when compiling many let bindings.
------------------------------------------+---------------------------------
 Reporter:  igloo                         |          Owner:         
     Type:  compile-time performance 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                       |  
------------------------------------------+---------------------------------
Comment (by igloo):

 J_mem_vs_time.png shows the memory use against time for J.hs, with
 different values of numa/numb. It doesn't look like there is a complexity
 problem, but the constant factor seems high, using about 10k per binding.
 J_heap_profile.png is the heap profile for the largest case (400/20000),
 and peak usage works out at about 5k per binding (the difference
 presumably being due to the copying GC). Typecheck-Rename stands out, but
 there are also a few other large space users.

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/1136#comment:7>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Tue Jan 22 11:24:03 2008
From: trac at galois.com (GHC)
Date: Tue Jan 22 11:23:49 2008
Subject: [GHC] #1839: need ghc-pkg dump feature
In-Reply-To: <045.e765af751a0d91f5b4a56c8391184f46@localhost>
References: <045.e765af751a0d91f5b4a56c8391184f46@localhost>
Message-ID: <054.d3cc014ca8c8443344078b48f536fe40@localhost>

#1839: need ghc-pkg dump feature
----------------------+-----------------------------------------------------
 Reporter:  duncan    |          Owner:  igloo  
     Type:  merge     |         Status:  new    
 Priority:  normal    |      Milestone:  6.8.3  
Component:  Compiler  |        Version:  6.8.1  
 Severity:  normal    |     Resolution:         
 Keywords:            |     Difficulty:  Unknown
 Testcase:            |   Architecture:  Unknown
       Os:  Unknown   |  
----------------------+-----------------------------------------------------
Changes (by simonmar):

  * owner:  => igloo
  * type:  feature request => merge

Comment:

 To merge:

 {{{
 Mon Jan 21 08:17:44 PST 2008  claus.reinke@talk21.com
   * FIX #1839, #1463, by supporting ghc-pkg bulk queries with substring
 matching
 Tue Jan 22 08:18:11 PST 2008  Simon Marlow <simonmar@microsoft.com>
   * This goes with the patch for #1839, #1463
 }}}

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/1839#comment:11>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Tue Jan 22 17:17:23 2008
From: trac at galois.com (GHC)
Date: Tue Jan 22 17:17:12 2008
Subject: [GHC] #2060: Unknown opcode 10904
Message-ID: <048.4f6ce482aa8df3efc85213e422c812ac@localhost>

#2060: Unknown opcode 10904
--------------------------+-------------------------------------------------
    Reporter:  ezrakilty  |       Owner:          
        Type:  bug        |      Status:  new     
    Priority:  normal     |   Component:  Compiler
     Version:  6.6        |    Severity:  normal  
    Keywords:             |    Testcase:          
Architecture:  x86        |          Os:  MacOS X 
--------------------------+-------------------------------------------------
 I got this error working with ghci just now. Contrary to what it says, I'm
 not on linux but on Mac OS X 10.4.11 (intel).

 {{{
     *Main> quickCheck prop_typecheck
     <interactive>: internal error: interpretBCO: unknown or unimplemented
 opcode     10904
         (GHC version 6.6 for i386_unknown_linux)
         Please report this as a GHC bug:
 http://www.haskell.org/ghc/reportabug
 }}}

 The text of the program follows.

 {{{
 import Foreign (unsafePerformIO)
 import List (nub)
 import System.Random (mkStdGen)
 import Test.QuickCheck

 data Term = Const | Var Int | Abs Term | Appl Term Term
             deriving (Show)
 data Type = Base | Type :->: Type
             deriving (Eq, Show)

 data TypeScheme = T Type | V Int | Arr TypeScheme TypeScheme
                   deriving (Eq, Show)

 eval env Const = Const
 eval env (Var x) | x < length env = env !! x
 eval env (Abs n) = Abs n
 eval env (Appl m n) = case eval env m of
                         Abs m' -> eval env' m'
                             where env' = eval env n : env
                         _ -> error "non-functional application"

 data Fresh a = Fr(Int -> (Int, a))

 instance Monad Fresh where
      return x = Fr(\ctr -> (ctr, x))
      (Fr m) >>= f = Fr(\x -> let (ctr, x') = m x in
                              let Fr f' = f x' in
                              f' ctr)

 fresh :: Fresh Int
 fresh = Fr(\ctr -> (ctr+1, ctr))

 runFresh (Fr f) = snd $ f 0

 arrowTy (s :->: t) = True
 arrowTy _ = False

 unify (T s) (T t) | s == t = Just[]
 unify (V x) t = Just [(x, t)]
 unify s (V y) = Just [(y, s)]
 unify (Arr s1 t1) (Arr s2 t2) =
     do subst1 <- unify s1 s2
        subst2 <- unify t1 t2
        Just (List.nub $ subst1 ++ subst2)

 applySubst :: (Int, TypeScheme) -> TypeScheme -> TypeScheme
 applySubst (x, xIm) (T ty) = T ty
 applySubst (x, xIm) (V y) | x == y = xIm
                           | otherwise = V y
 applySubst (x, xIm) (Arr s t) = Arr (applySubst (x, xIm) s)
                                     (applySubst (x, xIm) t)

 applySubsts :: [(Int, TypeScheme)] -> TypeScheme -> TypeScheme
 applySubsts substs ty = foldr (applySubst) ty substs

 typeCheck :: [TypeScheme] -> Term -> Fresh TypeScheme
 typeCheck env Const = return $ T Base
 typeCheck env (Var x) | x < length env = return (env !! x)
 typeCheck env (Abs n) =
     do xTy <- fresh
        nTy <- typeCheck (V xTy : env) n
        return (Arr (V xTy) nTy)
 typeCheck env (Appl m n) =
     do mTy <- typeCheck env m
        nTy <- typeCheck env n
        case mTy of
         Arr mArgTy mResTy ->
             case unify mArgTy nTy of
               Nothing -> error "unification failed"
               Just substn ->
                   return (applySubsts substn mResTy)
         _ ->  error "ill-typed application"

 typeGen :: Int -> Gen Type
 typeGen size = oneof $
     [return Base] ++
     if size <= 0 then [] else
         [do s <- typeGen (size-1)
             t <- typeGen (size-1)
             return $ s :->: t ]

 asList Nothing = []
 asList (Just x) = [x]

 oneofMaybe :: [Gen(Maybe a)] -> Gen (Maybe a)
 oneofMaybe [] = return Nothing
 oneofMaybe (x:xs) = do x' <- x
                        xs' <- oneofMaybe xs
                        case (x', xs') of
                          (Nothing, Nothing) -> return Nothing
                          _ -> oneof (map (return . Just) $
                                          asList x' ++ asList xs')

 typedTermGen :: [Type] -> Type -> Int -> Gen (Maybe Term)
 typedTermGen ctxt tau size = oneofMaybe (
     (case tau of
       Base -> [return $ Just Const]
       tau :->: tau' ->
           if size <= 0 then [] else
           [do n <- typedTermGen (tau:ctxt) tau' decSize
               return $ do n' <- n
                           Just(Abs n')]
     ) ++
     (if size <= 0 then [] else
     [do sigma <- typeGen decSize
 --        let sigma = (unsafePerformIO $ putStr $ show sigma') `seq`
 sigma'
         m <- typedTermGen ctxt (sigma :->: tau) decSize
         n <- typedTermGen ctxt (sigma) decSize
         return $ do m' <- m ; n' <- n; Just (Appl m' n')
     ]) ++
     [return$ Just (Var x) | (x, xType) <- zip [0..] ctxt, xType == tau]
     )
         where decSize = size-1

 -- graph a function over certain inputs
 graph f xs = [(x, f x) | x <- xs]

 make n g size = [generate size (System.Random.mkStdGen i) g | i<-[0..n]]

 prop_typecheck = forAll (sized (typedTermGen [] Base)) (\m ->
                     let m' = Maybe.fromJust m in
                     (runFresh (typeCheck [] m')) == Some (T Base))
 }}}

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/2060>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Tue Jan 22 18:29:44 2008
From: trac at galois.com (GHC)
Date: Tue Jan 22 18:29:31 2008
Subject: [GHC] #2061: ghc-pkg loops on mutually recursive package
 dependencies
Message-ID: <045.3213cbbf1af8002b48218d78ca64c138@localhost>

#2061: ghc-pkg loops on mutually recursive package dependencies
-------------------------------+--------------------------------------------
    Reporter:  trevor          |       Owner:        
        Type:  bug             |      Status:  new   
    Priority:  normal          |   Component:  None  
     Version:  6.8.2           |    Severity:  normal
    Keywords:                  |    Testcase:        
Architecture:  x86_64 (amd64)  |          Os:  Linux 
-------------------------------+--------------------------------------------
 If you have two packages installed, A and B, with a dependency from B to
 A, it is possible to create a cyclic dependency by then adding a
 dependency in A to B and reinstalling it.  The result is that ghc-pkg will
 loop, not detecting the cycle.

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/2061>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Tue Jan 22 19:19:40 2008
From: trac at galois.com (GHC)
Date: Tue Jan 22 19:19:28 2008
Subject: [GHC] #2060: Unknown opcode 10904
In-Reply-To: <048.4f6ce482aa8df3efc85213e422c812ac@localhost>
References: <048.4f6ce482aa8df3efc85213e422c812ac@localhost>
Message-ID: <057.8ef24f21e8b42b2bb20338bbe59ecc57@localhost>

#2060: Unknown opcode 10904
--------------------------+-------------------------------------------------
    Reporter:  ezrakilty  |        Owner:       
        Type:  bug        |       Status:  new  
    Priority:  normal     |    Milestone:       
   Component:  Compiler   |      Version:  6.6  
    Severity:  normal     |   Resolution:       
    Keywords:             |     Testcase:       
Architecture:  x86        |           Os:  Linux
--------------------------+-------------------------------------------------
Changes (by ezrakilty):

  * os:  MacOS X => Linux

Comment:

 Apologies: this error did in fact occur on a Linux setup, not MacOS X as I
 originally said.

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/2060#comment:1>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Tue Jan 22 20:34:52 2008
From: trac at galois.com (GHC)
Date: Tue Jan 22 20:34:37 2008
Subject: [GHC] #1312: runghc doesn't respect -main-is
In-Reply-To: <047.0ad50b74545f6e5e0f2d7fb1521d3937@localhost>
References: <047.0ad50b74545f6e5e0f2d7fb1521d3937@localhost>
Message-ID: <056.ff46fa6547ba7dd8dc13188abd782a82@localhost>

#1312: runghc doesn't respect -main-is
----------------------+-----------------------------------------------------
 Reporter:  simonmar  |          Owner:  igloo      
     Type:  bug       |         Status:  closed     
 Priority:  normal    |      Milestone:  6.8.3      
Component:  Compiler  |        Version:  6.6.1      
 Severity:  minor     |     Resolution:  fixed      
 Keywords:            |     Difficulty:  Easy (1 hr)
 Testcase:            |   Architecture:  Multiple   
       Os:  Unknown   |  
----------------------+-----------------------------------------------------
Changes (by igloo):

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

Comment:

 OK, this is now done in 6.8 and HEAD, but you need to escape the argument
 to `-main-is` so runghc doesn't think it's the module to load:
 {{{
 runghs -main-is --ghc-arg=foo bar.hs
 }}}
 Perhaps we should have
 {{{
 +GHC ... -GHC
 }}}
 or something, but that's a matter for another ticket!

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/1312#comment:7>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Wed Jan 23 05:34:45 2008
From: trac at galois.com (GHC)
Date: Wed Jan 23 05:34:30 2008
Subject: [GHC] #2060: Unknown opcode 10904
In-Reply-To: <048.4f6ce482aa8df3efc85213e422c812ac@localhost>
References: <048.4f6ce482aa8df3efc85213e422c812ac@localhost>
Message-ID: <057.8d1d51628d5eea06e393ed963485703a@localhost>

#2060: Unknown opcode 10904
-----------------------+----------------------------------------------------
 Reporter:  ezrakilty  |          Owner:           
     Type:  bug        |         Status:  closed   
 Priority:  normal     |      Milestone:           
Component:  Compiler   |        Version:  6.6      
 Severity:  normal     |     Resolution:  duplicate
 Keywords:             |     Difficulty:  Unknown  
 Testcase:             |   Architecture:  x86      
       Os:  Linux      |  
-----------------------+----------------------------------------------------
Changes (by simonmar):

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

Comment:

 Thanks for the report.  This was a bug in GHC 6.6 (see #1013), please
 upgrade to a later version to get the fix.

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/2060#comment:2>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Wed Jan 23 05:36:46 2008
From: trac at galois.com (GHC)
Date: Wed Jan 23 05:36:30 2008
Subject: [GHC] #2061: ghc-pkg loops on mutually recursive package
 dependencies
In-Reply-To: <045.3213cbbf1af8002b48218d78ca64c138@localhost>
References: <045.3213cbbf1af8002b48218d78ca64c138@localhost>
Message-ID: <054.0858e418509f8aac784477564e7e1c6f@localhost>

#2061: ghc-pkg loops on mutually recursive package dependencies
--------------------+-------------------------------------------------------
 Reporter:  trevor  |          Owner:                
     Type:  bug     |         Status:  closed        
 Priority:  normal  |      Milestone:                
Component:  None    |        Version:  6.8.2         
 Severity:  normal  |     Resolution:  duplicate     
 Keywords:          |     Difficulty:  Unknown       
 Testcase:          |   Architecture:  x86_64 (amd64)
       Os:  Linux   |  
--------------------+-------------------------------------------------------
Changes (by simonmar):

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

Comment:

 Thanks for the report, we already have a ticket for this one: #1750.

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/2061#comment:1>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Wed Jan 23 06:27:19 2008
From: trac at galois.com (GHC)
Date: Wed Jan 23 06:27:02 2008
Subject: [GHC] #1136: High memory use when compiling many let bindings.
In-Reply-To: <044.2f9aae100a9caba688d31e410efb3444@localhost>
References: <044.2f9aae100a9caba688d31e410efb3444@localhost>
Message-ID: <053.066fdb1f13203d4758931cbb42f8774a@localhost>

#1136: High memory use when compiling many let bindings.
------------------------------------------+---------------------------------
 Reporter:  igloo                         |          Owner:         
     Type:  compile-time performance 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                       |  
------------------------------------------+---------------------------------
Comment (by simonpj):

 Interesting.  I simplified it still more to a program of form:
 {{{
 a = let a0 = ()
     in let a1 = a0
         ...
     in let a10000 = a9999
 }}}
 and it still takes ages in the type checker, with a residency of 87M for
 10,000 bindings.  Splitting up the lets eliminates dependency analysis as
 the problem (in the type checker at least).

 Do you think you might do a little bit more profiling to see where the
 typechecker/renamers costs are coming, for this simpler program?

 Simon

 Could

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/1136#comment:8>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Wed Jan 23 08:10:04 2008
From: trac at galois.com (GHC)
Date: Wed Jan 23 08:09:50 2008
Subject: [GHC] #2062: hpc markup: Prelude.foldr1: empty list
Message-ID: <047.ee2d3737bf1ab623099bf786cc14a582@localhost>

#2062: hpc markup: Prelude.foldr1: empty list
-------------------------+--------------------------------------------------
    Reporter:  jedbrown  |       Owner:           
        Type:  bug       |      Status:  new      
    Priority:  normal    |   Component:  Profiling
     Version:  6.8.2     |    Severity:  normal   
    Keywords:  hpc       |    Testcase:           
Architecture:  x86       |          Os:  Linux    
-------------------------+--------------------------------------------------
 While testing code coverage for my new package, I noticed this.

 {{{
 $ ghc-6.8.2 -fhpc --make tests.hs -o tests
 $ ./tests 200
 flatten flatten          : OK, passed 200 tests.
 reshape flatten          : OK, passed 200 tests.
 rank                     : OK, passed 200 tests.
 shape size               : OK, passed 200 tests.
 size                     : OK, passed 200 tests.
 $ hpc markup tests --include carray
 Writing: hpc_index.html
 hpc: Prelude.foldr1: empty list
 $ hpc version
 hpc tools, version 0.6
 $ hpc markup tests --include nonexistent
 Writing: hpc_index.html
 hpc: Prelude.foldr1: empty list
 }}}

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/2062>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Wed Jan 23 08:34:01 2008
From: trac at galois.com (GHC)
Date: Wed Jan 23 08:33:44 2008
Subject: [GHC] #1767: :show <setting> does not conform to documented
 specification
In-Reply-To: <044.e7adae11ca7979e3093e064a998ae30d@localhost>
References: <044.e7adae11ca7979e3093e064a998ae30d@localhost>
Message-ID: <053.74ab0b5fd8b0646254db6b61ca362e4b@localhost>

#1767: :show <setting> does not conform to documented specification
---------------------+------------------------------------------------------
 Reporter:  guest    |          Owner:  igloo  
     Type:  merge    |         Status:  new    
 Priority:  normal   |      Milestone:  6.8.3  
Component:  GHCi     |        Version:  6.9    
 Severity:  normal   |     Resolution:         
 Keywords:           |     Difficulty:  Unknown
 Testcase:           |   Architecture:  Unknown
       Os:  Unknown  |  
---------------------+------------------------------------------------------
Changes (by simonmar):

  * owner:  simonmar => igloo
  * type:  bug => merge

Comment:

 To merge:

 {{{
 Tue Jan 22 15:29:43 GMT 2008  Simon Marlow <simonmar@microsoft.com>
   * FIX #1767 :show documentation claimed too much
 }}}

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/1767#comment:5>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Wed Jan 23 09:33:31 2008
From: trac at galois.com (GHC)
Date: Wed Jan 23 09:33:51 2008
Subject: [GHC] #1838: do not use getEnv "HOME",
 use System.Directory.getHomeDirectory
In-Reply-To: <044.7c14aad23d72fc1f99272ac17d7d5b67@localhost>
References: <044.7c14aad23d72fc1f99272ac17d7d5b67@localhost>
Message-ID: <053.a4b33fc73e9f45f84bde4553eefe2627@localhost>

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

  * owner:  simonmar => igloo
  * type:  bug => merge

Comment:

 To merge:

 {{{
   * FIX #1838, #1987: change where GHCi searches for config files
 }}}

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/1838#comment:7>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Wed Jan 23 09:34:10 2008
From: trac at galois.com (GHC)
Date: Wed Jan 23 09:34:01 2008
Subject: [GHC] #1987: GHCi's config file in <AppData>\ghc folder on
 Windows
In-Reply-To: <047.80a8b57d40878eeae0279f928cac66b2@localhost>
References: <047.80a8b57d40878eeae0279f928cac66b2@localhost>
Message-ID: <056.b00c2f0d4d6aaca3587db7171eabaad0@localhost>

#1987: GHCi's config file in <AppData>\ghc folder on Windows
-----------------------------+----------------------------------------------
 Reporter:  felixmar         |          Owner:             
     Type:  feature request  |         Status:  closed     
 Priority:  low              |      Milestone:  6.10 branch
Component:  GHCi             |        Version:  6.9        
 Severity:  normal           |     Resolution:  fixed      
 Keywords:                   |     Difficulty:  Unknown    
 Testcase:                   |   Architecture:  Unknown    
       Os:  Windows          |  
-----------------------------+----------------------------------------------
Changes (by simonmar):

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

Comment:

 See #1898

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/1987#comment:3>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Wed Jan 23 09:36:10 2008
From: trac at galois.com (GHC)
Date: Wed Jan 23 09:35:53 2008
Subject: [GHC] #1987: GHCi's config file in <AppData>\ghc folder on
 Windows
In-Reply-To: <047.80a8b57d40878eeae0279f928cac66b2@localhost>
References: <047.80a8b57d40878eeae0279f928cac66b2@localhost>
Message-ID: <056.838ed3793bd8e72ec572dd40f6d838c0@localhost>

#1987: GHCi's config file in <AppData>\ghc folder on Windows
-----------------------------+----------------------------------------------
 Reporter:  felixmar         |          Owner:             
     Type:  feature request  |         Status:  closed     
 Priority:  low              |      Milestone:  6.10 branch
Component:  GHCi             |        Version:  6.9        
 Severity:  normal           |     Resolution:  fixed      
 Keywords:                   |     Difficulty:  Unknown    
 Testcase:                   |   Architecture:  Unknown    
       Os:  Windows          |  
-----------------------------+----------------------------------------------
Changes (by simonmar):

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

Comment:

 See #1838

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/1987#comment:3>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Wed Jan 23 09:37:38 2008
From: trac at galois.com (GHC)
Date: Wed Jan 23 09:37:22 2008
Subject: [GHC] #998: Tab-completion of filenames does not work in GHCi
 6.6
In-Reply-To: <061.a0a29a0da74b1264616768b293fe2c41@localhost>
References: <061.a0a29a0da74b1264616768b293fe2c41@localhost>
Message-ID: <070.9810218fdc424bf92743eff2ad87590f@localhost>

#998: Tab-completion of filenames does not work in GHCi 6.6
------------------------------------+---------------------------------------
 Reporter:  dm.maillists@gmail.com  |          Owner:  igloo   
     Type:  merge                   |         Status:  new     
 Priority:  low                     |      Milestone:  6.8.3   
Component:  GHCi                    |        Version:  6.6     
 Severity:  minor                   |     Resolution:          
 Keywords:                          |     Difficulty:  Unknown 
 Testcase:                          |   Architecture:  Multiple
       Os:  Multiple                |  
------------------------------------+---------------------------------------
Changes (by simonmar):

  * owner:  simonmar => igloo
  * type:  bug => merge
  * milestone:  6.10 branch => 6.8.3

Comment:

 To merge:

 {{{
 Thu Jan 10 22:19:28 GMT 2008  judah.jacobson@gmail.com
   * Fix filename completion by adding trailing spaces/slashes manually.

 Wed Jan  9 00:36:06 GMT 2008  judah.jacobson@gmail.com
   * Use command-dependent word break characters for tab completion in
 ghci.  Fix
 es bug #998.
 }}}

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/998#comment:11>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Wed Jan 23 09:39:39 2008
From: trac at galois.com (GHC)
Date: Wed Jan 23 09:39:21 2008
Subject: [GHC] #1771: hFileSize gives negative values
In-Reply-To: <044.de7a3080a07f89d093c4293ba2bb2f42@localhost>
References: <044.de7a3080a07f89d093c4293ba2bb2f42@localhost>
Message-ID: <053.41c12e7b8d027dd7331c49b7ad1c6592@localhost>

#1771: hFileSize gives negative values
----------------------------+-----------------------------------------------
 Reporter:  guest           |          Owner:  igloo  
     Type:  merge           |         Status:  new    
 Priority:  normal          |      Milestone:  6.8.3  
Component:  libraries/base  |        Version:  6.6.1  
 Severity:  normal          |     Resolution:         
 Keywords:  hFileSize >2gb  |     Difficulty:  Unknown
 Testcase:                  |   Architecture:  x86    
       Os:  Windows         |  
----------------------------+-----------------------------------------------
Changes (by simonmar):

  * owner:  => igloo
  * type:  bug => merge

Comment:

 To merge (libraries/base patch):

 {{{
 Wed Jan 23 10:29:04 GMT Standard Time 2008  Simon Marlow
 <simonmar@microsoft.com>
   * Windows: large file support for hFileSize and hSeek (#1771)
 }}}

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/1771#comment:5>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Wed Jan 23 09:41:15 2008
From: trac at galois.com (GHC)
Date: Wed Jan 23 09:41:31 2008
Subject: [GHC] #1838: do not use getEnv "HOME",
 use System.Directory.getHomeDirectory
In-Reply-To: <044.7c14aad23d72fc1f99272ac17d7d5b67@localhost>
References: <044.7c14aad23d72fc1f99272ac17d7d5b67@localhost>
Message-ID: <053.bcbb7e451b550463d78f8734f47547c5@localhost>

#1838: do not use getEnv "HOME", use System.Directory.getHomeDirectory
---------------------+------------------------------------------------------
 Reporter:  guest    |          Owner:  igloo  
     Type:  merge    |         Status:  new    
 Priority:  high     |      Milestone:  6.8.3  
Component:  GHCi     |        Version:  6.8.2  
 Severity:  normal   |     Resolution:         
 Keywords:           |     Difficulty:  Unknown
 Testcase:           |   Architecture:  Unknown
       Os:  Windows  |  
---------------------+------------------------------------------------------
Comment (by simonmar):

 This patch to libraries/directory is also needed:

 {{{
 Tue Jan 22 16:59:14 GMT Standard Time 2008  Simon Marlow
 <simonmar@microsoft.com>
   * canonicalizePath should also do System.FilePath.normalise
 }}}

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/1838#comment:8>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Wed Jan 23 11:32:08 2008
From: trac at galois.com (GHC)
Date: Wed Jan 23 11:32:02 2008
Subject: [GHC] #1750: ghc-pkg stack overflow when mutually dependent
 packages installed
In-Reply-To: <046.c7f89c65ae4e20e638696f6bfcdd5355@localhost>
References: <046.c7f89c65ae4e20e638696f6bfcdd5355@localhost>
Message-ID: <055.a8160b6db7c39ae41c6d8848e3ba6c5e@localhost>

#1750: ghc-pkg stack overflow when mutually dependent packages installed
----------------------+-----------------------------------------------------
 Reporter:  greenrd   |          Owner:  simonmar   
     Type:  bug       |         Status:  new        
 Priority:  normal    |      Milestone:  6.8.3      
Component:  Compiler  |        Version:  6.7        
 Severity:  normal    |     Resolution:             
 Keywords:            |     Difficulty:  Easy (1 hr)
 Testcase:            |   Architecture:  Multiple   
       Os:  Multiple  |  
----------------------+-----------------------------------------------------
Changes (by simonmar):

  * owner:  => simonmar

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/1750#comment:3>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Wed Jan 23 11:58:46 2008
From: trac at galois.com (GHC)
Date: Wed Jan 23 11:58:30 2008
Subject: [GHC] #1936: When lazy IO blocks, it blocks the whole runtime
In-Reply-To: <044.f29c60445787d8d1c724ac2871ace0b4@localhost>
References: <044.f29c60445787d8d1c724ac2871ace0b4@localhost>
Message-ID: <053.83fe95d874a73a35adb1f42507ed605a@localhost>

#1936: When lazy IO blocks, it blocks the whole runtime
------------------------------------------+---------------------------------
 Reporter:  guest                         |          Owner:  simonmar
     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 simonmar):

  * owner:  => simonmar

Comment:

 I know why this is happening.

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/1936#comment:8>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Thu Jan 24 01:21:44 2008
From: trac at galois.com (GHC)
Date: Thu Jan 24 01:21:31 2008
Subject: [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
In-Reply-To: <050.c31695132cb1b93380c95a8b6c208782@localhost>
References: <050.c31695132cb1b93380c95a8b6c208782@localhost>
Message-ID: <059.ac0f53e668894eb0cd21e8bccb3ebb76@localhost>

#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:  thorkilnaur
     Type:  bug          |         Status:  new        
 Priority:  high         |      Milestone:  6.8.3      
Component:  Compiler     |        Version:  6.9        
 Severity:  normal       |     Resolution:             
 Keywords:               |     Difficulty:  Unknown    
 Testcase:               |   Architecture:  powerpc    
       Os:  MacOS X      |  
-------------------------+--------------------------------------------------
Comment (by thorkilnaur):

 Just for the record, using the mk/build.mk
 {{{
 GhcLibHcOpts=-O -fgenerics -fasm
 GhcStage1HcOpts=-O -fasm
 GhcStage2HcOpts=-O -fasm
 SplitObjs=NO
 GhcLibWays=
 HADDOCK_DOCS=YES
 }}}
 also used by the buildbots and the patch
 Work_around_PPC_Mac_OS_X_Leopard_ld_Bus_error_illustrative_only.dpatch
 that were attached a while ago, a recent stable branch GHC builds
 successfully. The stage=2 test summary is:
 {{{
 OVERALL SUMMARY for test run started at Wed Jan 23 17:49:47 CET 2008
     2078 total tests, which gave rise to
     6475 test cases, of which
        0 caused framework failures
     1098 were skipped

     5102 expected passes
      242 expected failures
        0 unexpected passes
       33 unexpected failures

 Unexpected failures:
    TH_fail(normal)
    divbyzero(normal,optc,optasm,ghci,threaded1,threaded2)
    ffi009(ghci)
    ghci024(ghci)
    hpc_raytrace(normal,optc,optasm,threaded1,threaded2)
    num012(normal,optc,optasm,ghci,threaded1,threaded2)
    openFile008(ghci)
    qq001(normal)
    qq002(normal)
    qq003(normal)
    qq004(normal)
    qq005(normal,optc,optasm,ghci,threaded1,threaded2)
    qq006(normal)
    signals002(ghci)
 }}}
 A recent head with the same patch applied also builds successfully with
 stage=2 test summary:
 {{{
 OVERALL SUMMARY for test run started at Wed Jan 23 09:48:22 CET 2008
     2075 total tests, which gave rise to
     6470 test cases, of which
        0 caused framework failures
     1001 were skipped

     5188 expected passes
      239 expected failures
        0 unexpected passes
       42 unexpected failures

 Unexpected failures:
    break017(ghci)
    divbyzero(normal,optc,optasm,ghci,threaded1,threaded2)
    dynamic001(normal,optc,optasm,ghci,threaded1,threaded2)
    dynamic002(normal,optc,optasm,ghci,threaded1,threaded2)
    ffi009(ghci)
    ghci024(ghci)
    hpc_raytrace(normal,optc,optasm,threaded1,threaded2)
    num012(normal,optc,optasm,ghci,threaded1,threaded2)
    openFile008(ghci)
    qq005(normal,optc,optasm,ghci,threaded1,threaded2)
    qq006(normal)
    recomp002(normal)
    signals002(ghci)
 }}}
 Best regards
 Thorkil

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/1958#comment:12>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Thu Jan 24 03:50:24 2008
From: trac at galois.com (GHC)
Date: Thu Jan 24 03:50:12 2008
Subject: [GHC] #1750: ghc-pkg stack overflow when mutually dependent
 packages installed
In-Reply-To: <046.c7f89c65ae4e20e638696f6bfcdd5355@localhost>
References: <046.c7f89c65ae4e20e638696f6bfcdd5355@localhost>
Message-ID: <055.5a64c07f8021f3fa5330c0b75216c121@localhost>

#1750: ghc-pkg stack overflow when mutually dependent packages installed
----------------------+-----------------------------------------------------
 Reporter:  greenrd   |          Owner:  igloo      
     Type:  merge     |         Status:  new        
 Priority:  normal    |      Milestone:  6.8.3      
Component:  Compiler  |        Version:  6.7        
 Severity:  normal    |     Resolution:             
 Keywords:            |     Difficulty:  Easy (1 hr)
 Testcase:            |   Architecture:  Multiple   
       Os:  Multiple  |  
----------------------+-----------------------------------------------------
Changes (by simonmar):

  * owner:  simonmar => igloo
  * type:  bug => merge

Comment:

 Fixed, to merge:

 {{{
 Wed Jan 23 16:06:35 GMT 2008  Simon Marlow <simonmar@microsoft.com>
   * FIX #1750: throw out mutually recursive groups of packages

 Wed Jan 23 16:07:03 GMT 2008  Simon Marlow <simonmar@microsoft.com>
   * FIX #1750: in isBrokenPackage, don't loop if the deps are recursive

 Wed Jan 23 16:31:45 GMT 2008  Simon Marlow <simonmar@microsoft.com>
   * Show CmdLineError exceptions as "<command line>: ..."
 }}}

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/1750#comment:4>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Thu Jan 24 04:34:42 2008
From: trac at galois.com (GHC)
Date: Thu Jan 24 04:34:23 2008
Subject: [GHC] #427: Random.StdGen slowness
In-Reply-To: <044.910d2f7eb299e5f5b612cc8fccf049ef@localhost>
References: <044.910d2f7eb299e5f5b612cc8fccf049ef@localhost>
Message-ID: <053.fdf1bea147d0c16e47b0a0cd06e14d1f@localhost>

#427: Random.StdGen slowness
------------------------------+---------------------------------------------
 Reporter:  remit             |          Owner:         
     Type:  bug               |         Status:  new    
 Priority:  low               |      Milestone:  _|_    
Component:  libraries/random  |        Version:  6.4.1  
 Severity:  normal            |     Resolution:  None   
 Keywords:                    |     Difficulty:  Unknown
 Testcase:                    |   Architecture:  Unknown
       Os:  Unknown           |  
------------------------------+---------------------------------------------
Changes (by simonmar):

  * status:  assigned => new
  * owner:  nobody =>
  * component:  libraries/base => libraries/random

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/427#comment:5>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Thu Jan 24 05:11:39 2008
From: trac at galois.com (GHC)
Date: Thu Jan 24 05:12:07 2008
Subject: [GHC] #482: 'Bug' when installing GHC 6.4.1
In-Reply-To: <045.df3b9749dff5dad7e59e147c0a95cce9@localhost>
References: <045.df3b9749dff5dad7e59e147c0a95cce9@localhost>
Message-ID: <054.02790a5a913ba11d30db30bd94447b27@localhost>

#482: 'Bug' when installing GHC 6.4.1
--------------------------+-------------------------------------------------
 Reporter:  nobody        |          Owner:  wolfgang
     Type:  bug           |         Status:  closed  
 Priority:  normal        |      Milestone:  _|_     
Component:  Build System  |        Version:  6.4.1   
 Severity:  normal        |     Resolution:  wontfix 
 Keywords:                |     Difficulty:  Unknown 
 Testcase:  N/A           |   Architecture:  powerpc 
       Os:  MacOS X       |  
--------------------------+-------------------------------------------------
Changes (by simonmar):

  * status:  assigned => closed
  * resolution:  None => wontfix

Comment:

 Closing, as this appears to be not our bug.

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/482#comment:6>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Thu Jan 24 05:23:41 2008
From: trac at galois.com (GHC)
Date: Thu Jan 24 05:23:21 2008
Subject: [GHC] #552: GHCi  :m  doesn't restore default decl
In-Reply-To: <046.8fe84617c76248de33d1df0f58763c7d@localhost>
References: <046.8fe84617c76248de33d1df0f58763c7d@localhost>
Message-ID: <055.7a28099ee0e1dc3f6d70c43e4967bd47@localhost>

#552: GHCi  :m  doesn't restore default decl
---------------------+------------------------------------------------------
 Reporter:  simonpj  |          Owner:  nobody  
     Type:  bug      |         Status:  assigned
 Priority:  lowest   |      Milestone:  _|_     
Component:  GHCi     |        Version:  5.00    
 Severity:  normal   |     Resolution:  None    
 Keywords:           |     Difficulty:  Unknown 
 Testcase:  ghci016  |   Architecture:  Unknown 
       Os:  Unknown  |  
---------------------+------------------------------------------------------
Changes (by simonmar):

  * component:  Driver => GHCi

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/552#comment:3>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Thu Jan 24 05:26:57 2008
From: trac at galois.com (GHC)
Date: Thu Jan 24 05:26:44 2008
Subject: [GHC] #631: GHCi doesn't work unregisterised
In-Reply-To: <058.77987f0da5513fbc618ea4c0e4ce6de9@localhost>
References: <058.77987f0da5513fbc618ea4c0e4ce6de9@localhost>
Message-ID: <067.d3244973950255d252b9d87473f577a7@localhost>

#631: GHCi doesn't work unregisterised
---------------------------------+------------------------------------------
 Reporter:  trentbuck@gmail.com  |          Owner:  simonmar  
     Type:  bug                  |         Status:  new       
 Priority:  normal               |      Milestone:  6.8 branch
Component:  GHCi                 |        Version:  6.4.1     
 Severity:  minor                |     Resolution:            
 Keywords:                       |     Difficulty:  Unknown   
 Testcase:                       |   Architecture:  Multiple  
       Os:  Multiple             |  
---------------------------------+------------------------------------------
Changes (by simonmar):

  * owner:  igloo => simonmar

Comment:

 I'm taking this: the remaining issue is only that GHCi does not support
 FFI when compiled unregisterised, which will be fixed by #793.

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/631#comment:14>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Thu Jan 24 08:01:56 2008
From: trac at galois.com (GHC)
Date: Thu Jan 24 08:01:37 2008
Subject: [GHC] #1936: When lazy IO blocks, it blocks the whole runtime
In-Reply-To: <044.f29c60445787d8d1c724ac2871ace0b4@localhost>
References: <044.f29c60445787d8d1c724ac2871ace0b4@localhost>
Message-ID: <053.26972b954128c9fcf6603d26a8f16947@localhost>

#1936: When lazy IO blocks, it blocks the whole runtime
------------------------------------------+---------------------------------
 Reporter:  guest                         |          Owner:  igloo   
     Type:  merge                         |         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 simonmar):

  * owner:  simonmar => igloo
  * type:  bug => merge

Comment:

 Fixed, to merge:

 {{{
 Thu Jan 24 01:22:03 PST 2008  Simon Marlow <simonmar@microsoft.com>
   * FIX #1936: hGetBufNonBlocking was blocking on stdin/stdout/stderr
 }}}

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/1936#comment:9>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Thu Jan 24 09:30:53 2008
From: trac at galois.com (GHC)
Date: Thu Jan 24 09:30:53 2008
Subject: [GHC] #740: Copyright information is wrong in some GHC source
 files
In-Reply-To: <044.e3018ba04e94127af296980fb94fc0de@localhost>
References: <044.e3018ba04e94127af296980fb94fc0de@localhost>
Message-ID: <053.534b284db58b0a00f7934204a9cc0ce1@localhost>

#740: Copyright information is wrong in some GHC source files
---------------------+------------------------------------------------------
 Reporter:  guest    |          Owner:         
     Type:  bug      |         Status:  new    
 Priority:  lowest   |      Milestone:  _|_    
Component:  Prelude  |        Version:  6.4.1  
 Severity:  trivial  |     Resolution:         
 Keywords:           |     Difficulty:  Unknown
 Testcase:  N/A      |   Architecture:  Unknown
       Os:  Unknown  |  
---------------------+------------------------------------------------------
Changes (by simonmar):

 * cc: lennart@augustsson.net (added)

Comment:

 Lennart - I was just doing some bug gardening, and thought I'd try to
 knock this one off.  The files that I'm aware of that contain your code
 are:

  * [http://darcs.haskell.org/packages/base/GHC/Float.lhs]
  * [http://darcs.haskell.org/ghc/rts/StgPrimFloat.c]

 do you know of any others?  Perhaps some of the `USE_REPORT_PRELUDE` stuff
 in `Data.List` was yours?

 Basically there was a lot of cross-pollination between hbc and ghc in the
 early days (or perhaps it was just one way :-).  Most of the actual cut-
 and-pasting was done I think by Will Partain, he might be the only person
 who remembers what happened...

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/740#comment:3>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Thu Jan 24 11:26:33 2008
From: trac at galois.com (GHC)
Date: Thu Jan 24 11:26:14 2008
Subject: [GHC] #1368: Use filepath in GHC
In-Reply-To: <047.a381327b834e9ffdb042b771b6c871a9@localhost>
References: <047.a381327b834e9ffdb042b771b6c871a9@localhost>
Message-ID: <056.58bf0340dcfc9b11f481b76181c65062@localhost>

#1368: Use filepath in GHC
----------------------+-----------------------------------------------------
 Reporter:  simonmar  |          Owner:  igloo      
     Type:  task      |         Status:  closed     
 Priority:  normal    |      Milestone:  6.10 branch
Component:  Compiler  |        Version:  6.7        
 Severity:  normal    |     Resolution:  fixed      
 Keywords:            |     Difficulty:  Easy (1 hr)
 Testcase:            |   Architecture:  Unknown    
       Os:  Unknown   |  
----------------------+-----------------------------------------------------
Changes (by igloo):

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

Comment:

 Now done in the HEAD.

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/1368#comment:2>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Thu Jan 24 11:42:05 2008
From: trac at galois.com (GHC)
Date: Thu Jan 24 11:41:56 2008
Subject: [GHC] #911: Better information about the location of exceptions
In-Reply-To: <047.5bb835b65ac998a6972669a4aed57bd0@localhost>
References: <047.5bb835b65ac998a6972669a4aed57bd0@localhost>
Message-ID: <056.b00698472fbdb9a1202294a65b1f4ab8@localhost>

#911: Better information about the location of exceptions
-----------------------------+----------------------------------------------
 Reporter:  simonmar         |          Owner:         
     Type:  feature request  |         Status:  closed 
 Priority:  normal           |      Milestone:  _|_    
Component:  Runtime System   |        Version:  6.4.2  
 Severity:  normal           |     Resolution:  fixed  
 Keywords:                   |     Difficulty:  Unknown
 Testcase:                   |   Architecture:  Unknown
       Os:  Unknown          |  
-----------------------------+----------------------------------------------
Changes (by simonmar):

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

Comment:

 The User's Guide has a section on "Debugging Exceptions".

 I also improved the entry in the FAQ about "head []" to point to the
 relevant part of the docs.

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/911#comment:3>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Thu Jan 24 11:46:27 2008
From: trac at galois.com (GHC)
Date: Thu Jan 24 11:46:07 2008
Subject: [GHC] #1205: ghci reports functions not in scope after loading
 a .hs, if there is a .o present
In-Reply-To: <044.bd60efe42aee3f1abdd3292b0526501b@localhost>
References: <044.bd60efe42aee3f1abdd3292b0526501b@localhost>
Message-ID: <053.5c97d0824e97fbf26b70166698329c1f@localhost>

#1205: ghci reports functions not in scope after loading a .hs, if there is a .o
present
-----------------------------+----------------------------------------------
 Reporter:  guest            |          Owner:             
     Type:  feature request  |         Status:  new        
 Priority:  high             |      Milestone:  6.10 branch
Component:  GHCi             |        Version:  6.6        
 Severity:  normal           |     Resolution:             
 Keywords:                   |     Difficulty:  Unknown    
 Testcase:                   |   Architecture:  Unknown    
       Os:  Unknown          |  
-----------------------------+----------------------------------------------
Changes (by simonmar):

  * priority:  normal => high
  * milestone:  _|_ => 6.10 branch

Comment:

 Bumping this as it is an oft-reported source of confusion.  We'll do
 something for 6.10.

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/1205#comment:6>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Thu Jan 24 11:50:30 2008
From: trac at galois.com (GHC)
Date: Thu Jan 24 11:50:08 2008
Subject: [GHC] #1409: Allow recursively dependent modules transparently
 (without .hs-boot or anything)
In-Reply-To: <051.8a467503f7e6e3ea87602b7d1c1e067f@localhost>
References: <051.8a467503f7e6e3ea87602b7d1c1e067f@localhost>
Message-ID: <060.23adca8199bdf6e1ecd010448f5ba417@localhost>

#1409: Allow recursively dependent modules transparently (without .hs-boot or
anything)
-----------------------------+----------------------------------------------
 Reporter:  Isaac Dupree     |          Owner:         
     Type:  feature request  |         Status:  new    
 Priority:  normal           |      Milestone:  _|_    
Component:  Compiler         |        Version:  6.6.1  
 Severity:  normal           |     Resolution:         
 Keywords:                   |     Difficulty:  Unknown
 Testcase:                   |   Architecture:  Unknown
       Os:  Unknown          |  
-----------------------------+----------------------------------------------
Changes (by simonmar):

  * milestone:  6.10 branch => _|_

Comment:

 We don't have any plans to do this, so remove it from the 6.10 milestone.
 Perhaps it could be done as part of some kind of support for module
 signatures?

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/1409#comment:3>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Thu Jan 24 14:00:11 2008
From: trac at galois.com (GHC)
Date: Thu Jan 24 13:59:56 2008
Subject: [GHC] #427: Random.StdGen slowness
In-Reply-To: <044.910d2f7eb299e5f5b612cc8fccf049ef@localhost>
References: <044.910d2f7eb299e5f5b612cc8fccf049ef@localhost>
Message-ID: <053.2f7cec145d7ac8a9e16f6214a32e935e@localhost>

#427: Random.StdGen slowness
------------------------------+---------------------------------------------
 Reporter:  remit             |          Owner:         
     Type:  bug               |         Status:  new    
 Priority:  low               |      Milestone:  _|_    
Component:  libraries/random  |        Version:  6.4.1  
 Severity:  normal            |     Resolution:  None   
 Keywords:                    |     Difficulty:  Unknown
 Testcase:                    |   Architecture:  Unknown
       Os:  Unknown           |  
------------------------------+---------------------------------------------
Changes (by dons):

 * cc: dons@galois.com (added)

Comment:

 The mersenne twister C lib is also some 60x faster. There's a binding to
 it here:

     http://hackage.haskell.org/cgi-bin/hackage-scripts/package/mersenne-
 random-0.1

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/427#comment:6>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Thu Jan 24 16:48:17 2008
From: trac at galois.com (GHC)
Date: Thu Jan 24 16:48:13 2008
Subject: [GHC] #740: Copyright information is wrong in some GHC source
 files
In-Reply-To: <044.e3018ba04e94127af296980fb94fc0de@localhost>
References: <044.e3018ba04e94127af296980fb94fc0de@localhost>
Message-ID: <053.7f085407f891b2b49929d1d38b2efebc@localhost>

#740: Copyright information is wrong in some GHC source files
---------------------+------------------------------------------------------
 Reporter:  guest    |          Owner:         
     Type:  bug      |         Status:  new    
 Priority:  lowest   |      Milestone:  _|_    
Component:  Prelude  |        Version:  6.4.1  
 Severity:  trivial  |     Resolution:         
 Keywords:           |     Difficulty:  Unknown
 Testcase:  N/A      |   Architecture:  Unknown
       Os:  Unknown  |  
---------------------+------------------------------------------------------
Comment (by tim):

 I think that as a general rule, it would be a good idea to be more careful
 about copyright assignment. This is a problem that affects lots and lots
 of open-source projects. The usual model is that when somebody commits a
 patch, they are assigning copyright to "the project" as a whole (whatever
 that might mean), but legally, this is questionable (at least from the
 perspective of US law, which is the only legal system I'm really familiar
 with.) I don't know what the right solution to this is, nor am I
 volunteering to be the one who tracks down all former contributors and
 makes sure they consent to assign copyright, I'm just pointing out that
 it's worth being careful about, especially as GHC becomes more widely
 used.

 -Tim

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/740#comment:4>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Thu Jan 24 18:18:41 2008
From: trac at galois.com (GHC)
Date: Thu Jan 24 18:18:40 2008
Subject: [GHC] #740: Copyright information is wrong in some GHC source
 files
In-Reply-To: <044.e3018ba04e94127af296980fb94fc0de@localhost>
References: <044.e3018ba04e94127af296980fb94fc0de@localhost>
Message-ID: <053.712b1134f56e0539c80e269658024b0b@localhost>

#740: Copyright information is wrong in some GHC source files
---------------------+------------------------------------------------------
 Reporter:  guest    |          Owner:         
     Type:  bug      |         Status:  new    
 Priority:  lowest   |      Milestone:  _|_    
Component:  Prelude  |        Version:  6.4.1  
 Severity:  trivial  |     Resolution:         
 Keywords:           |     Difficulty:  Unknown
 Testcase:  N/A      |   Architecture:  Unknown
       Os:  Unknown  |  
---------------------+------------------------------------------------------
Comment (by Isaac Dupree):

 no, that's only the usual model for FSF and proprietary GPL'd software.
 Most open-source software doesn't require copyright assignment, they just
 implicitly (though stated somewhere) require releasing contributions under
 the same license.  (This is trivial for licenses like GPL that don't allow
 releasing changes in any other way.)  Also the BSD-style license that GHC
 uses is pretty much liberal enough for everyone, GPL and proprietary
 people, so there probably will never be a need/desire to track down all
 contributors.

 It's still good bookkeeping to list the actual copyright owners, and
 possibly useful if we ever want to sue someone for violating the terms of
 the BSD license (unlikely though that seems)

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/740#comment:5>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Thu Jan 24 18:24:34 2008
From: trac at galois.com (GHC)
Date: Thu Jan 24 18:24:31 2008
Subject: [GHC] #740: Copyright information is wrong in some GHC source
 files
In-Reply-To: <044.e3018ba04e94127af296980fb94fc0de@localhost>
References: <044.e3018ba04e94127af296980fb94fc0de@localhost>
Message-ID: <053.223b56833aedc918892f20f1ddd893b9@localhost>

#740: Copyright information is wrong in some GHC source files
---------------------+------------------------------------------------------
 Reporter:  guest    |          Owner:         
     Type:  bug      |         Status:  new    
 Priority:  lowest   |      Milestone:  _|_    
Component:  Prelude  |        Version:  6.4.1  
 Severity:  trivial  |     Resolution:         
 Keywords:           |     Difficulty:  Unknown
 Testcase:  N/A      |   Architecture:  Unknown
       Os:  Unknown  |  
---------------------+------------------------------------------------------
Comment (by tim):

 At least under US law, however, the original author does retain copyright
 (as Lennart said in the original bug report) *unless* they explicitly
 enter into a contract that says that they give up copyright. The question
 is whether the act of committing (or submitting) a patch constitutes a
 contractual agreement to give up copyright (licensing one's work under the
 BSD license is a form of giving up copyright, as the BSD license, broad as
 it is, involves terms that are different than the terms that would apply
 if somebody retained all rights.)

 You say that the BSD license is "pretty much liberal enough for everyone",
 but I'm not that confident. I'm sure all GHC contributors are nice people
 who would never sue over their code being redistributed, but with the
 number of people on the contributors list, maybe it gets to be a risk to
 the project to assume that everyone is nice and the license is liberal
 enough.

 Disclaimer: I am not a lawyer, nor do I play one on TV.

 -Tim

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/740#comment:6>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Thu Jan 24 18:51:20 2008
From: trac at galois.com (GHC)
Date: Thu Jan 24 18:51:14 2008
Subject: [GHC] #740: Copyright information is wrong in some GHC source
 files
In-Reply-To: <044.e3018ba04e94127af296980fb94fc0de@localhost>
References: <044.e3018ba04e94127af296980fb94fc0de@localhost>
Message-ID: <053.15a3ed4f03f0f18562047fb7284e86f0@localhost>

#740: Copyright information is wrong in some GHC source files
---------------------+------------------------------------------------------
 Reporter:  guest    |          Owner:         
     Type:  bug      |         Status:  new    
 Priority:  lowest   |      Milestone:  _|_    
Component:  Prelude  |        Version:  6.4.1  
 Severity:  trivial  |     Resolution:         
 Keywords:           |     Difficulty:  Unknown
 Testcase:  N/A      |   Architecture:  Unknown
       Os:  Unknown  |  
---------------------+------------------------------------------------------
Comment (by Isaac Dupree):

 okay, there's a difference between assigning copyright to someone, and
 releasing something under a license less restrictive than the (U.S.)
 default.

 If the code is actually legally all BSD-licensed (no matter who owns the
 copyright; licenses are irrevocable by default), all users have to do is
 follow those simple terms, and they can't be sued. (well, not
 successfully, anyway.  But it's possible to sue anyone for anything or
 nothing at all in an attempt to cause financial harm.)  The risk is that
 some contributor didn't legally actually agree to using the BSD license
 (which is a less drastic step than handing over copyright to someone else;
 it doesn't require copyright transfer papers).  Does anyone know of any
 example in an open-source project where this risk actually happened /
 caused trouble?

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/740#comment:7>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Thu Jan 24 18:55:58 2008
From: trac at galois.com (GHC)
Date: Thu Jan 24 18:55:50 2008
Subject: [GHC] #740: Copyright information is wrong in some GHC source
 files
In-Reply-To: <044.e3018ba04e94127af296980fb94fc0de@localhost>
References: <044.e3018ba04e94127af296980fb94fc0de@localhost>
Message-ID: <053.0afc0496a39c8ee7f81caff37145ce0e@localhost>

#740: Copyright information is wrong in some GHC source files
---------------------+------------------------------------------------------
 Reporter:  guest    |          Owner:         
     Type:  bug      |         Status:  new    
 Priority:  lowest   |      Milestone:  _|_    
Component:  Prelude  |        Version:  6.4.1  
 Severity:  trivial  |     Resolution:         
 Keywords:           |     Difficulty:  Unknown
 Testcase:  N/A      |   Architecture:  Unknown
       Os:  Unknown  |  
---------------------+------------------------------------------------------
Comment (by tim):

 Isaac wrote: "The risk is that some contributor didn't legally actually
 agree to using the BSD license" -- exactly. Sorry I wasn't so clear
 before. What's ambiguous, legally, is just what it means for somebody to
 legally agree to using the BSD license.

 I don't know of any cases where this actually happened and caused legal
 problems for a project, but maybe someone else does. The point is, though,
 that in the absence of precedent (and AFAIK there is no case law about
 this), it *could* happen.

 -Tim

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/740#comment:8>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Thu Jan 24 19:09:31 2008
From: trac at galois.com (GHC)
Date: Thu Jan 24 19:09:20 2008
Subject: [GHC] #2063: Breackage on OpenBSD due to mmap remap
Message-ID: <043.15abf9ca319b437728a2421245ad0407@localhost>

#2063: Breackage on OpenBSD due to mmap remap
-------------------------+--------------------------------------------------
    Reporter:  dons      |       Owner:          
        Type:  bug       |      Status:  new     
    Priority:  normal    |   Component:  Compiler
     Version:  6.8.2     |    Severity:  normal  
    Keywords:  OpenBSD   |    Testcase:          
Architecture:  Multiple  |          Os:  OpenBSD 
-------------------------+--------------------------------------------------
 GHC head since the 6.8 split back in October, is broken on OpenBSD, due to
 changes in mmap use

 {{{
 Thu Oct 18 05:52:20 PDT 2007  Simon Marlow <simonmar <at> microsoft.com>

   * add PIC relocations for x86_64, and use a simpler hack in place of
 x86_64_high_symbol()

   This is Wolfgang Thaller's patch sent to cvs-ghc recently, with extra
   commentary by me.  It turns out that this patch is not just a cleanup,
   it is also necessary for GHCi to work on x86_64 with shared libraries,
   because previously lookupSymbol() was creating jump-table entries for
   all symbols looked up that resolved outside 2Gb, whereas Wolfgang's
   version only generates jump-table entries for 32-bit symbol references
   in object code that we load.
 }}}

 It appears to still be broken:

 {{{
 ../compiler/ghc-inplace -optc-O -optc-L/usr/local/lib
 -optc-I/usr/local/include -optc-Wall -optc-W -optc-Wstrict-prototypes
 -optc-Wmissing-prototypes -optc-Wmissing-declarations -optc-Winline -optc-
 Waggregate-return -optc-I../includes -optc-I. -optc-Iparallel -optc-Ism
 -optc-DCOMPILING_RTS -optc-fomit-frame-pointer -optc-I../gmp/gmpbuild
 -optc-fno-strict-aliasing -H128m -O2 -L/usr/local/lib -I/usr/local/include
 -optc-O2 -I../includes -I. -Iparallel -Ism -DCOMPILING_RTS -package-name
 rts -static -I../gmp/gmpbuild -I. -#include HCIncludes.h -optc-fno-stack-
 protector -dcmm-lint   -optc-O0  -H128m -O2 -L/usr/local/lib
 -I/usr/local/include -optc-O2 -I../includes -I. -Iparallel -Ism
 -DCOMPILING_RTS -package-name rts -static -I../gmp/gmpbuild -I. -#include
 HCIncludes.h -optc-fno-stack-protector -dcmm-lint  -c Main.c -o Main.o

 Linker.c:1599:10:
      #error ocAllocateSymbolExtras doesnt want USE_MMAP to be defined
 Linker.c: In function `ocAllocateSymbolExtras':

 Linker.c:1623:0:
      warning: implicit declaration of function `mremap'

 Linker.c:1623:0:
      error: `MREMAP_MAYMOVE' undeclared (first use in this function)

 Linker.c:1623:0:
      error: (Each undeclared identifier is reported only once

 Linker.c:1623:0:  error: for each function it appears in.)
 }}}

 originally reported on the mailing list,
 http://thread.gmane.org/gmane.comp.lang.haskell.cvs.ghc/24330

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/2063>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Thu Jan 24 19:15:56 2008
From: trac at galois.com (GHC)
Date: Thu Jan 24 19:15:49 2008
Subject: [GHC] #740: Copyright information is wrong in some GHC source
 files
In-Reply-To: <044.e3018ba04e94127af296980fb94fc0de@localhost>
References: <044.e3018ba04e94127af296980fb94fc0de@localhost>
Message-ID: <053.5583c7335ff5056f1d78e3f0a253f849@localhost>

#740: Copyright information is wrong in some GHC source files
---------------------+------------------------------------------------------
 Reporter:  guest    |          Owner:         
     Type:  bug      |         Status:  new    
 Priority:  lowest   |      Milestone:  _|_    
Component:  Prelude  |        Version:  6.4.1  
 Severity:  trivial  |     Resolution:         
 Keywords:           |     Difficulty:  Unknown
 Testcase:  N/A      |   Architecture:  Unknown
       Os:  Unknown  |  
---------------------+------------------------------------------------------
Comment (by claus):

 the ticket is about copyright/source attribution, the discussion is
 drifting towards licensing. i assumed it was clear that the ghc code base
 was bsd-style licensed (as in: "enjoy, but please don't bother us with
 legalese";-). since bsd isn't viral, it would be nice if there was a clear
 point of entry for newcomers stating that all contributors agree to ghc's
 default license (with the few documented exceptions).

 to see that it isn't about being nice, refer to the squeak relicensing
 experience - after over a year, they still haven't identified, let alone
 tracked down all contributors (some may have left this earth, others have
 just left the social and online circles in which they were known):

 http://www.squeak.org/SqueakLicense/

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/740#comment:9>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Thu Jan 24 19:24:25 2008
From: trac at galois.com (GHC)
Date: Thu Jan 24 19:24:29 2008
Subject: [GHC] #740: Copyright information is wrong in some GHC source
 files
In-Reply-To: <044.e3018ba04e94127af296980fb94fc0de@localhost>
References: <044.e3018ba04e94127af296980fb94fc0de@localhost>
Message-ID: <053.cea10a04f24ddb121c1a2ed91fe55007@localhost>

#740: Copyright information is wrong in some GHC source files
---------------------+------------------------------------------------------
 Reporter:  guest    |          Owner:         
     Type:  bug      |         Status:  new    
 Priority:  lowest   |      Milestone:  _|_    
Component:  Prelude  |        Version:  6.4.1  
 Severity:  trivial  |     Resolution:         
 Keywords:           |     Difficulty:  Unknown
 Testcase:  N/A      |   Architecture:  Unknown
       Os:  Unknown  |  
---------------------+------------------------------------------------------
Comment (by tim):

 Claus: I think it's hard to separate licensing from copyright attribution.
 I don't want to cause Yet Another Licensing Flamewar, but I think it ought
 to be taken more seriously than just "oh, we know that nobody is going to
 want to bother us about legal issues, since everyone's nice." Which you
 seem to agree on as well.

 I agree that there should be a clear point of entry. As a (minor)
 contributor, I was never asked to agree to the license (although I
 certainly do agree to it).

 -Tim

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/740#comment:10>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Fri Jan 25 04:21:30 2008
From: trac at galois.com (GHC)
Date: Fri Jan 25 04:21:09 2008
Subject: [GHC] #2063: Breackage on OpenBSD due to mmap remap
In-Reply-To: <043.15abf9ca319b437728a2421245ad0407@localhost>
References: <043.15abf9ca319b437728a2421245ad0407@localhost>
Message-ID: <052.d4d4a7fdb4977a21dd7042bb09b6cde9@localhost>

#2063: Breackage on OpenBSD due to mmap remap
----------------------+-----------------------------------------------------
 Reporter:  dons      |          Owner:                  
     Type:  bug       |         Status:  new             
 Priority:  high      |      Milestone:  6.10 branch     
Component:  Compiler  |        Version:  6.8.2           
 Severity:  normal    |     Resolution:                  
 Keywords:  OpenBSD   |     Difficulty:  Moderate (1 day)
 Testcase:            |   Architecture:  Multiple        
       Os:  OpenBSD   |  
----------------------+-----------------------------------------------------
Changes (by simonmar):

  * priority:  normal => high
  * difficulty:  => Moderate (1 day)
  * milestone:  => 6.10 branch

Comment:

 This is related to #2013.  There's a real bug here that was previously
 hidden: we use the `MAP_32BIT` flag to `mmap`, which is only supported on
 Linux.  Unfortunately we really need this flag.  There's a patch in #2013
 that works around it for FreeBSD by asking for memory at specific
 addresses, so the fix is somewhat fragile.  Furthermore, the fix needs to
 be ported to HEAD, where the code has changed due to the patch mentioned
 by dons above.

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/2063#comment:1>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Fri Jan 25 05:29:19 2008
From: trac at galois.com (GHC)
Date: Fri Jan 25 05:29:01 2008
Subject: [GHC] #784: defining type of returned value
In-Reply-To: <064.6807fb6112ba01925b58e2e8dab6434f@localhost>
References: <064.6807fb6112ba01925b58e2e8dab6434f@localhost>
Message-ID: <073.eddcea13ce1789480a0ed4396f93c6cc@localhost>

#784: defining type of returned value
---------------------------------------+------------------------------------
 Reporter:  Bulat.Ziganshin@gmail.com  |          Owner:         
     Type:  bug                        |         Status:  closed 
 Priority:  low                        |      Milestone:  _|_    
Component:  Compiler                   |        Version:  6.4.2  
 Severity:  normal                     |     Resolution:  fixed  
 Keywords:                             |     Difficulty:  Unknown
 Testcase:                             |   Architecture:  Unknown
       Os:  Unknown                    |  
---------------------------------------+------------------------------------
Changes (by simonmar):

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

Comment:

 This module now reports an error in 6.8.2:

 {{{
 784.hs:4:35: Not in scope: type variable `a'
 }}}

 So it appears to be fixed.

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/784#comment:4>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Fri Jan 25 05:37:49 2008
From: trac at galois.com (GHC)
Date: Fri Jan 25 05:37:28 2008
Subject: [GHC] #987: X11: foreign declarations use Haskell types instead
 of C ones
In-Reply-To: <043.511ea070127009112ed2a3053209575c@localhost>
References: <043.511ea070127009112ed2a3053209575c@localhost>
Message-ID: <052.01d409c14aa38464c86392e2d99b9e90@localhost>

#987: X11: foreign declarations use Haskell types instead of C ones
-------------------------------+--------------------------------------------
 Reporter:  ross               |          Owner:         
     Type:  bug                |         Status:  closed 
 Priority:  normal             |      Milestone:  Not GHC
Component:  libraries (other)  |        Version:  6.6    
 Severity:  normal             |     Resolution:  fixed  
 Keywords:                     |     Difficulty:  Unknown
 Testcase:  N/A                |   Architecture:  Unknown
       Os:  Unknown            |  
-------------------------------+--------------------------------------------
Changes (by simonmar):

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

Comment:

 I believe this was done last year.  The X11 package has the following
 patches:

 {{{
 Thu Mar 29 02:05:33 BST 2007  thedward@antejentacular.org
   * (X11.Graphics) More Int -> CInt cleanup ; Will break existing
 programs.

   This patch takes care of the rest of the Int usages.

   These changes break API compatibility. Existing programs will likely
   require (minor[1]) changes to compile once these changes are applied.

   [1]Mostly just switching from Int to CInt or using fromIntegral as
 appropriate

 Wed Mar 28 07:24:53 BST 2007  thedward@antejentacular.org
   * Changing Int to CInt and building with -D_XSERVER64 (when appropriate)

   I went through and weeded out all the Ints I could find, replacing them
   with CInts, adding fromIntegral calls as necessary.

   I modified configure.ac and X11.buildinfo.in to support detecting 64-bit
   systems. (inspired by the test in the xorg build).

   All these changes seem to make X11 much more useful on 64-bit systems.

   Most importantly, I've got xmonad up and running beautifully.
 }}}

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/987#comment:3>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Fri Jan 25 05:41:41 2008
From: trac at galois.com (GHC)
Date: Fri Jan 25 05:41:19 2008
Subject: [GHC] #459: Bad parse error message
In-Reply-To: <045.9adecc17314923c33323a1bd4204dfc1@localhost>
References: <045.9adecc17314923c33323a1bd4204dfc1@localhost>
Message-ID: <054.e24285bdc5831d126c5a6df6ed2c3d7a@localhost>

#459: Bad parse error message
-------------------------------+--------------------------------------------
 Reporter:  nobody             |          Owner:  simonmar
     Type:  bug                |         Status:  new     
 Priority:  normal             |      Milestone:  _|_     
Component:  Compiler (Parser)  |        Version:  6.4.1   
 Severity:  minor              |     Resolution:  None    
 Keywords:                     |     Difficulty:  Unknown 
 Testcase:                     |   Architecture:  Unknown 
       Os:  Unknown            |  
-------------------------------+--------------------------------------------
Comment (by simonmar):

 See also #984 and #999 for more poor parse-error messages.

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/459#comment:5>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Fri Jan 25 05:41:54 2008
From: trac at galois.com (GHC)
Date: Fri Jan 25 05:41:33 2008
Subject: [GHC] #984: Syntax error shows in the wrong position
In-Reply-To: <044.8e0ea27662525e56297a595011d4a1f1@localhost>
References: <044.8e0ea27662525e56297a595011d4a1f1@localhost>
Message-ID: <053.3f73b2729899c9cf029d205b8d2550f4@localhost>

#984: Syntax error shows in the wrong position
----------------------------------+-----------------------------------------
 Reporter:  guest                 |          Owner:          
     Type:  bug                   |         Status:  new     
 Priority:  low                   |      Milestone:  _|_     
Component:  Compiler (Parser)     |        Version:  6.4.2   
 Severity:  minor                 |     Resolution:          
 Keywords:  syntax parse case do  |     Difficulty:  Unknown 
 Testcase:  N/A                   |   Architecture:  Multiple
       Os:  Multiple              |  
----------------------------------+-----------------------------------------
Comment (by simonmar):

 See also #459

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/984#comment:4>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Fri Jan 25 05:42:23 2008
From: trac at galois.com (GHC)
Date: Fri Jan 25 05:42:02 2008
Subject: [GHC] #999: Misattributed parse error in do block
In-Reply-To: <057.38b4e5ace3d6beb45133f8b4750f80d2@localhost>
References: <057.38b4e5ace3d6beb45133f8b4750f80d2@localhost>
Message-ID: <066.1b2099265509dd7f0ef30a44cd25f726@localhost>

#999: Misattributed parse error in do block
--------------------------------+-------------------------------------------
 Reporter:  red5_2@hotmail.com  |          Owner:                  
     Type:  bug                 |         Status:  new             
 Priority:  low                 |      Milestone:  _|_             
Component:  Compiler (Parser)   |        Version:  6.4.2           
 Severity:  normal              |     Resolution:                  
 Keywords:                      |     Difficulty:  Moderate (1 day)
 Testcase:                      |   Architecture:  Unknown         
       Os:  Unknown             |  
--------------------------------+-------------------------------------------
Comment (by simonmar):

 See also #459

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/999#comment:3>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Fri Jan 25 05:44:31 2008
From: trac at galois.com (GHC)
Date: Fri Jan 25 05:44:11 2008
Subject: [GHC] #1015: regex001(ghci,threaded1) seg-faults under Solaris
In-Reply-To: <052.533384a70abd2d45f0347c9d49345eeb@localhost>
References: <052.533384a70abd2d45f0347c9d49345eeb@localhost>
Message-ID: <061.aa7557d1f93c55d3942235337badff9b@localhost>

#1015: regex001(ghci,threaded1) seg-faults under Solaris
---------------------------+------------------------------------------------
 Reporter:  maeder@tzi.de  |          Owner:          
     Type:  bug            |         Status:  new     
 Priority:  normal         |      Milestone:  _|_     
Component:  Compiler       |        Version:  6.6     
 Severity:  normal         |     Resolution:          
 Keywords:                 |     Difficulty:  Unknown 
 Testcase:                 |   Architecture:  Multiple
       Os:  Solaris        |  
---------------------------+------------------------------------------------
Comment (by simonmar):

 Christian - is this bug still relevant?

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/1015#comment:2>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From Christian.Maeder at dfki.de  Fri Jan 25 05:57:29 2008
From: Christian.Maeder at dfki.de (Christian Maeder)
Date: Fri Jan 25 05:57:10 2008
Subject: [GHC] #1015: regex001(ghci,threaded1) seg-faults under Solaris
In-Reply-To: <061.aa7557d1f93c55d3942235337badff9b@localhost>
References: <052.533384a70abd2d45f0347c9d49345eeb@localhost>
	<061.aa7557d1f93c55d3942235337badff9b@localhost>
Message-ID: <4799C099.1020400@dfki.de>

Hi Simon,

could you please supply a testsuite.tgz for ghc-6.8.2 so that I can test
it? (Or say how to easily get the testsuite only).

I hope ghc-6.8.2 is sufficient for testing.

Cheers Christian

see also
http://hackage.haskell.org/trac/ghc/ticket/2025


GHC wrote:
> #1015: regex001(ghci,threaded1) seg-faults under Solaris
> ---------------------------+------------------------------------------------
>  Reporter:  maeder@tzi.de  |          Owner:          
>      Type:  bug            |         Status:  new     
>  Priority:  normal         |      Milestone:  _|_     
> Component:  Compiler       |        Version:  6.6     
>  Severity:  normal         |     Resolution:          
>  Keywords:                 |     Difficulty:  Unknown 
>  Testcase:                 |   Architecture:  Multiple
>        Os:  Solaris        |  
> ---------------------------+------------------------------------------------
> Comment (by simonmar):
> 
>  Christian - is this bug still relevant?
> 
From trac at galois.com  Fri Jan 25 06:27:22 2008
From: trac at galois.com (GHC)
Date: Fri Jan 25 06:27:13 2008
Subject: [GHC] #740: Copyright information is wrong in some GHC source
 files
In-Reply-To: <044.e3018ba04e94127af296980fb94fc0de@localhost>
References: <044.e3018ba04e94127af296980fb94fc0de@localhost>
Message-ID: <053.b9bce5af8e34164b0218a85f47077496@localhost>

#740: Copyright information is wrong in some GHC source files
---------------------+------------------------------------------------------
 Reporter:  guest    |          Owner:         
     Type:  bug      |         Status:  new    
 Priority:  lowest   |      Milestone:  _|_    
Component:  Prelude  |        Version:  6.4.1  
 Severity:  trivial  |     Resolution:         
 Keywords:           |     Difficulty:  Unknown
 Testcase:  N/A      |   Architecture:  Unknown
       Os:  Unknown  |  
---------------------+------------------------------------------------------
Comment (by simonpj):

 If one of you felt up to drafting an "entry point" page, covering the
 points you raise, we could then direct people to it, eg from the
 [wiki:GettingStarted Getting started] page.

 Thanks!  Simon.

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/740#comment:11>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Fri Jan 25 10:19:39 2008
From: trac at galois.com (GHC)
Date: Fri Jan 25 10:19:33 2008
Subject: [GHC] #740: Copyright information is wrong in some GHC source
 files
In-Reply-To: <044.e3018ba04e94127af296980fb94fc0de@localhost>
References: <044.e3018ba04e94127af296980fb94fc0de@localhost>
Message-ID: <053.76fed0393b1df2ca30e02a6795ac1fa8@localhost>

#740: Copyright information is wrong in some GHC source files
---------------------+------------------------------------------------------
 Reporter:  guest    |          Owner:         
     Type:  bug      |         Status:  new    
 Priority:  lowest   |      Milestone:  _|_    
Component:  Prelude  |        Version:  6.4.1  
 Severity:  trivial  |     Resolution:         
 Keywords:           |     Difficulty:  Unknown
 Testcase:  N/A      |   Architecture:  Unknown
       Os:  Unknown  |  
---------------------+------------------------------------------------------
Comment (by simonmar):

 I created a page about [wiki:Licensing], but I haven't hooked it up
 anywhere yet.

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/740#comment:12>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Fri Jan 25 10:21:31 2008
From: trac at galois.com (GHC)
Date: Fri Jan 25 10:21:07 2008
Subject: [GHC] #2064: problems with duplicate modules
Message-ID: <047.fdf7f2c34537ee71076b19d77bccf5a5@localhost>

#2064: problems with duplicate modules
-------------------------+--------------------------------------------------
    Reporter:  Frederik  |       Owner:          
        Type:  bug       |      Status:  new     
    Priority:  normal    |   Component:  Compiler
     Version:  6.8.2     |    Severity:  normal  
    Keywords:            |    Testcase:          
Architecture:  Unknown   |          Os:  Unknown 
-------------------------+--------------------------------------------------
 Hello, I just noticed the following minor issue. I have a cabal file which
 isn't seen by cabal except for the configuration step and to install the
 package, which I do as:

 {{{
 runhaskell Setup.hs -v register --gen-pkg-config=.package-config
 ghc-pkg update .package-config --user
 }}}

 If I duplicate a module in the Exposed-modules list then

 1. cabal doesn't complain

 2. ghc-pkg doesn't complain

 3. ghci gives a very misleading message, e.g.:

 {{{
 Could not find module `Vector.Sparse':
   it was found in multiple packages: vectro-0.2 vectro-0.2
 }}}

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/2064>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Fri Jan 25 10:33:52 2008
From: trac at galois.com (GHC)
Date: Fri Jan 25 10:33:28 2008
Subject: [GHC] #2064: problems with duplicate modules
In-Reply-To: <047.fdf7f2c34537ee71076b19d77bccf5a5@localhost>
References: <047.fdf7f2c34537ee71076b19d77bccf5a5@localhost>
Message-ID: <056.92e957a538b441b4268a1cffe3e65bfd@localhost>

#2064: problems with duplicate modules
-------------------------+--------------------------------------------------
    Reporter:  Frederik  |        Owner:         
        Type:  bug       |       Status:  new    
    Priority:  normal    |    Milestone:         
   Component:  Compiler  |      Version:  6.8.2  
    Severity:  normal    |   Resolution:         
    Keywords:            |     Testcase:         
Architecture:  Unknown   |           Os:  Unknown
-------------------------+--------------------------------------------------
Comment (by duncan):

 Noted in Cabal trac:
 http://hackage.haskell.org/trac/hackage/ticket/191#comment:8

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/2064#comment:1>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Fri Jan 25 10:44:00 2008
From: trac at galois.com (GHC)
Date: Fri Jan 25 10:43:54 2008
Subject: [GHC] #740: Copyright information is wrong in some GHC source
 files
In-Reply-To: <044.e3018ba04e94127af296980fb94fc0de@localhost>
References: <044.e3018ba04e94127af296980fb94fc0de@localhost>
Message-ID: <053.6795b2360bd483d3e2aaab5f5c29d139@localhost>

#740: Copyright information is wrong in some GHC source files
---------------------+------------------------------------------------------
 Reporter:  guest    |          Owner:         
     Type:  bug      |         Status:  new    
 Priority:  lowest   |      Milestone:  _|_    
Component:  Prelude  |        Version:  6.4.1  
 Severity:  trivial  |     Resolution:         
 Keywords:           |     Difficulty:  Unknown
 Testcase:  N/A      |   Architecture:  Unknown
       Os:  Unknown  |  
---------------------+------------------------------------------------------
Comment (by guest):

 I'll look through the files and see which ones came from hbc.  As I said,
 I don't care that much, but sometimes it seems like people think
 everything Haskell comes from ghc, and missing attributions is one reason
 for this.

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/740#comment:13>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From simonmarhaskell at gmail.com  Fri Jan 25 11:05:49 2008
From: simonmarhaskell at gmail.com (Simon Marlow)
Date: Fri Jan 25 11:05:29 2008
Subject: [GHC] #1015: regex001(ghci,threaded1) seg-faults under Solaris
In-Reply-To: <4799C099.1020400@dfki.de>
References: <052.533384a70abd2d45f0347c9d49345eeb@localhost>
	<061.aa7557d1f93c55d3942235337badff9b@localhost>
	<4799C099.1020400@dfki.de>
Message-ID: <479A08DD.7080104@gmail.com>

Christian Maeder wrote:
> Hi Simon,
> 
> could you please supply a testsuite.tgz for ghc-6.8.2 so that I can test
> it? (Or say how to easily get the testsuite only).
>
> I hope ghc-6.8.2 is sufficient for testing.

A recent testsuite should be fine, that test hasn't changed in ages.  In 
the future, I'll try to make sure we tag the testsuite for each GHC release.

Cheers,	
	Simon

> Cheers Christian
> 
> see also
> http://hackage.haskell.org/trac/ghc/ticket/2025
> 
> 
> GHC wrote:
>> #1015: regex001(ghci,threaded1) seg-faults under Solaris
>> ---------------------------+------------------------------------------------
>>  Reporter:  maeder@tzi.de  |          Owner:          
>>      Type:  bug            |         Status:  new     
>>  Priority:  normal         |      Milestone:  _|_     
>> Component:  Compiler       |        Version:  6.6     
>>  Severity:  normal         |     Resolution:          
>>  Keywords:                 |     Difficulty:  Unknown 
>>  Testcase:                 |   Architecture:  Multiple
>>        Os:  Solaris        |  
>> ---------------------------+------------------------------------------------
>> Comment (by simonmar):
>>
>>  Christian - is this bug still relevant?
>>

From trac at galois.com  Fri Jan 25 12:02:38 2008
From: trac at galois.com (GHC)
Date: Fri Jan 25 12:02:24 2008
Subject: [GHC] #1015: regex001(ghci,threaded1) seg-faults under Solaris
In-Reply-To: <052.533384a70abd2d45f0347c9d49345eeb@localhost>
References: <052.533384a70abd2d45f0347c9d49345eeb@localhost>
Message-ID: <061.421a70e275faf785fad5eac30d0c2dc0@localhost>

#1015: regex001(ghci,threaded1) seg-faults under Solaris
---------------------------+------------------------------------------------
 Reporter:  maeder@tzi.de  |          Owner:          
     Type:  bug            |         Status:  new     
 Priority:  normal         |      Milestone:  _|_     
Component:  Compiler       |        Version:  6.6     
 Severity:  normal         |     Resolution:          
 Keywords:                 |     Difficulty:  Unknown 
 Testcase:                 |   Architecture:  Multiple
       Os:  Solaris        |  
---------------------------+------------------------------------------------
Comment (by maeder):

 Yes, I've just tested under sparc solaris:

 {{{
 =====> regex001(ghci)
 cd ./lib/Regex && '/local/home/maeder/ghc-6.8.2/compiler/stage2/ghc-
 inplace' -no-recomp -dcore-lint -dcmm-lint -Dsparc_sun_solaris2
 regex001.hs --interactive -v0 -package regex-posix  <regex001.genscript
 1>regex001.interp.stdout 2>regex001.interp.stderr
 Bus Error
 Wrong exit code (expected 0 , actual 138 )
 Stdout:
 *** framework failure for regex001(ghci) :
 Traceback (most recent call last):
   File "/home/ian/ghc/6.6-branch/ghc/testsuite/driver/testlib.py", line
 363, in do_test
     result = apply(func, [name,way] + args)
   File "/home/ian/ghc/6.6-branch/ghc/testsuite/driver/testlib.py", line
 509, in compile_and_run
     return compile_and_run_helper( name, way, extra_hc_opts, 0 )
   File "/home/ian/ghc/6.6-branch/ghc/testsuite/driver/testlib.py", line
 519, in compile_and_run_helper
     return interpreter_run( name, way, extra_hc_opts, 0, '' )
   File "/home/ian/ghc/6.6-branch/ghc/testsuite/driver/testlib.py", line
 736, in interpreter_run
     dump_stdout(name)
   File "/home/ian/ghc/6.6-branch/ghc/testsuite/driver/testlib.py", line
 880, in dump_stdout
     print read_no_crs(qualify(name, 'run.stdout'))
   File "/home/ian/ghc/6.6-branch/ghc/testsuite/driver/testlib.py", line
 899, in read_no_crs
     h = open(file)
 IOError: [Errno 2] No such file or directory:
 './lib/Regex/regex001.run.stdout'
 =====> regex001(threaded1)
 cd ./lib/Regex && '/local/home/maeder/ghc-6.8.2/compiler/stage2/ghc-
 inplace' -no-recomp -dcore-lint -dcmm-lint -Dsparc_sun_solaris2  -o
 regex001 regex001.hs -threaded -debug -package regex-posix
 >regex001.comp.stderr 2>&1
 cd ./lib/Regex && ./regex001    </dev/null >regex001.run.stdout
 2>regex001.run.stderr
 Segmentation Fault
 Wrong exit code (expected 0 , actual 139 )
 Stdout:

 Stderr:

 *** unexpected failure for regex001(threaded1)
 }}}

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/1015#comment:3>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Fri Jan 25 12:19:08 2008
From: trac at galois.com (GHC)
Date: Fri Jan 25 12:18:46 2008
Subject: [GHC] #1216: indexing 2d arrays is slow and leaky. why?
In-Reply-To: <044.7a2c34fb5e14ee065cc1b66e35e75915@localhost>
References: <044.7a2c34fb5e14ee065cc1b66e35e75915@localhost>
Message-ID: <053.284f32fc31097550302cd068440a7c31@localhost>

#1216: indexing 2d arrays is slow and leaky. why?
----------------------+-----------------------------------------------------
 Reporter:  claus     |          Owner:  simonpj
     Type:  bug       |         Status:  new    
 Priority:  normal    |      Milestone:  6.8.3  
Component:  Compiler  |        Version:  6.6    
 Severity:  normal    |     Resolution:         
 Keywords:            |     Difficulty:  Unknown
 Testcase:            |   Architecture:  Unknown
       Os:  Unknown   |  
----------------------+-----------------------------------------------------
Comment (by simonpj):

 A Friday afternoon, so I thought I'd look at this.  The problem is that
 `GHC.Arr.$windex1`, which is called from the inner loop has this inlining:
 {{{
 $windex1 :: GHC.Prim.Int# -> GHC.Prim.Int# -> GHC.Prim.Int# ->
 GHC.Base.Int
   {- Arity: 3 Strictness: LLL
      Unfolding: (\ ww :: GHC.Prim.Int# ww1 :: GHC.Prim.Int# ww2 ::
 GHC.Prim.Int# ->
                  case @ GHC.Base.Int GHC.Prim.<=# ww ww2 of wild {
                    GHC.Base.False
                    -> GHC.Arr.indexError2
                         (GHC.Base.I# ww, GHC.Base.I# ww1)
                         (GHC.Base.I# ww2)
                         GHC.Arr.lvl3
                    GHC.Base.True
                    -> case @ GHC.Base.Int GHC.Prim.<=# ww2 ww1 of wild1 {
                         GHC.Base.False
                         -> GHC.Arr.indexError2
                              (GHC.Base.I# ww, GHC.Base.I# ww1)
                              (GHC.Base.I# ww2)
                              GHC.Arr.lvl3
                         GHC.Base.True -> GHC.Base.I# (GHC.Prim.-# ww2 ww)
 } }) -}
 }}}
 Note the allocation of the `I#` box!  Why?  Becuase `GHC.Arr.indexError`
 is not marked as a bottoming function.  Why not?  Because it looks like
 this:
 {{{
 [Arity 1
  Str: DmdType L]
 GHC.Arr.indexError =
   \ (@ a_aRh) (@ b_aRi) ($dShow_aRD [ALWAYS Just L] :: GHC.Show.Show
 a_aRh) ->
     let {
       shows1_X1Am [ALWAYS Just L] :: a_aRh -> GHC.Show.ShowS
       [Str: DmdType {aRD->U(C(S)AA)}]
       shows1_X1Am = GHC.Show.shows @ a_aRh $dShow_aRD } in
     let {
       shows2_X1Ap [ALWAYS Just L] :: a_aRh -> GHC.Show.ShowS
       [Str: DmdType {aRD->U(C(S)AA)}]
       shows2_X1Ap = GHC.Show.shows @ a_aRh $dShow_aRD } in
     \ (rng_ah3 [ALWAYS Just L] :: (a_aRh, a_aRh))
       (i_ah5 [ALWAYS Just L] :: a_aRh)
       (tp_ah7 [ALWAYS Just S] :: GHC.Base.String) ->
       GHC.Err.error @ b_aRi (...stuff...)
 }}}
 Note the stupid arity and that the strictness analyser is not spotting the
 bottom result.

 I'll think about how to fix this stupidity.

 Simon

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/1216#comment:6>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Fri Jan 25 13:20:11 2008
From: trac at galois.com (GHC)
Date: Fri Jan 25 13:19:48 2008
Subject: [GHC] #987: X11: foreign declarations use Haskell types instead
 of C ones
In-Reply-To: <043.511ea070127009112ed2a3053209575c@localhost>
References: <043.511ea070127009112ed2a3053209575c@localhost>
Message-ID: <052.74a3778dd1ccd537c71133917555e6d5@localhost>

#987: X11: foreign declarations use Haskell types instead of C ones
-------------------------------+--------------------------------------------
 Reporter:  ross               |          Owner:         
     Type:  bug                |         Status:  closed 
 Priority:  normal             |      Milestone:  Not GHC
Component:  libraries (other)  |        Version:  6.6    
 Severity:  normal             |     Resolution:  fixed  
 Keywords:                     |     Difficulty:  Unknown
 Testcase:  N/A                |   Architecture:  Unknown
       Os:  Unknown            |  
-------------------------------+--------------------------------------------
Comment (by dons):

 This has been fixed, I can confirm. X11 is now 64 bit clean.

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/987#comment:4>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Fri Jan 25 17:15:41 2008
From: trac at galois.com (GHC)
Date: Fri Jan 25 17:15:25 2008
Subject: [GHC] #1015: regex001(ghci,threaded1) seg-faults under Solaris
In-Reply-To: <052.533384a70abd2d45f0347c9d49345eeb@localhost>
References: <052.533384a70abd2d45f0347c9d49345eeb@localhost>
Message-ID: <061.d23184637ad4992a8a2b2f233a66f6f5@localhost>

#1015: regex001(ghci,threaded1) seg-faults under Solaris
---------------------------+------------------------------------------------
 Reporter:  maeder@tzi.de  |          Owner:          
     Type:  bug            |         Status:  new     
 Priority:  normal         |      Milestone:  _|_     
Component:  Compiler       |        Version:  6.6     
 Severity:  normal         |     Resolution:          
 Keywords:                 |     Difficulty:  Unknown 
 Testcase:                 |   Architecture:  Multiple
       Os:  Solaris        |  
---------------------------+------------------------------------------------
Comment (by maeder):

 under x86 Solaris as well:

 {{{
 -bash-3.1$ ghc -no-recomp -lbfd -lintl -liberty -dcore-lint -dcmm-lint
 -Dsparc_sun_solaris2  -o regex001 regex001.hs -threaded -debug -package
 regex-posix
 -bash-3.1$ ./regex001
 Segmentation Fault
 }}}

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/1015#comment:4>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Sat Jan 26 14:37:48 2008
From: trac at galois.com (GHC)
Date: Sat Jan 26 14:37:22 2008
Subject: [GHC] #2065: QuickCheck: coarbitrary for Double and Float is broken.
Message-ID: <047.46288937485983cd4ba90be55ea2293b@localhost>

#2065: QuickCheck: coarbitrary for Double and Float is broken.
-------------------------+--------------------------------------------------
    Reporter:  jedbrown  |       Owner:                   
        Type:  bug       |      Status:  new              
    Priority:  normal    |   Component:  libraries (other)
     Version:  6.8.2     |    Severity:  normal           
    Keywords:            |    Testcase:                   
Architecture:  Multiple  |          Os:  Multiple         
-------------------------+--------------------------------------------------
 The `coarbitrary` definition for these types is incompatible with the way
 they are generated.  First, `decodeFloat` produces a pair `(Integer,
 Int)`, then the `Integer` is manipulated to be positive and then coerced
 to an `Int` using `fromInteger` and passed to variant.  Even 'simple'
 values of type `Double` and `Float` (as produced by `arbitrary`) can have
 huge significands.  In the case of Double, the resulting `Int` can be
 negative due to truncation.  This causes an exception when `variant` uses
 '(!!)' with a negative index.  Huge positive values are just as bad since
 they cause a space leak while evaluating `variant` with a huge index (and
 tend not to terminate due to memory constraints).  An obvious fix is to
 use the QuickCheck-2 approach.

 To reproduce, import Test.QuickCheck and Text.Show.Functions, then run:

 `verboseCheck ((\f a -> f a == f a) :: (Float -> Int) -> Float -> Bool)`

 This should pass a few tests before finding a space leak.

 `verboseCheck ((\f a -> f a == f a) :: (Double -> Int) -> Double -> Bool)`

 This should also pass a few, then it may find a space leak, or it may
 error with:

 `*** Exception: Prelude.(!!): negative index`

 Note that QuickCheck-2 has no problems here.

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/2065>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Sat Jan 26 16:10:40 2008
From: trac at galois.com (GHC)
Date: Sat Jan 26 16:10:13 2008
Subject: [GHC] #2062: hpc markup: Prelude.foldr1: empty list
In-Reply-To: <047.ee2d3737bf1ab623099bf786cc14a582@localhost>
References: <047.ee2d3737bf1ab623099bf786cc14a582@localhost>
Message-ID: <056.44702e5f3c83774ae1f96514e6caea1f@localhost>

#2062: hpc markup: Prelude.foldr1: empty list
--------------------------+-------------------------------------------------
    Reporter:  jedbrown   |        Owner:        
        Type:  bug        |       Status:  closed
    Priority:  normal     |    Milestone:        
   Component:  Profiling  |      Version:  6.8.2 
    Severity:  normal     |   Resolution:  fixed 
    Keywords:  hpc        |     Testcase:        
Architecture:  x86        |           Os:  Linux 
--------------------------+-------------------------------------------------
Changes (by AndyGill):

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

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/2062#comment:1>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Sat Jan 26 19:30:44 2008
From: trac at galois.com (GHC)
Date: Sat Jan 26 19:31:00 2008
Subject: [GHC] #2036: Show for Double and Float doesn't use parenthesis
 for negative zero.
In-Reply-To: <047.9085fb42c7e7997d5332318ebe9470cc@localhost>
References: <047.9085fb42c7e7997d5332318ebe9470cc@localhost>
Message-ID: <056.57dff2d7800ad6c3918c3d032d34f857@localhost>

#2036: Show for Double and Float doesn't use parenthesis for negative zero.
---------------------------------+------------------------------------------
 Reporter:  clanehin             |          Owner:             
     Type:  bug                  |         Status:  new        
 Priority:  normal               |      Milestone:  6.10 branch
Component:  libraries/haskell98  |        Version:  6.6.1      
 Severity:  minor                |     Resolution:             
 Keywords:                       |     Difficulty:  Unknown    
 Testcase:                       |   Architecture:  Multiple   
       Os:  Multiple             |  
---------------------------------+------------------------------------------
Changes (by igloo):

 * cc: Malcolm.Wallace@cs.york.ac.uk (added)
  * difficulty:  => Unknown
  * milestone:  => 6.10 branch

Comment:

 Thanks for the report.
 According to http://haskell.org/onlinereport/standard-prelude.html the
 Show instance for `Double` should be
 {{{
 instance  Show Double  where
     showsPrec p         = showFloat
 }}}
 i.e. it ignores `p`, so even `Just (-3 :: Double)` shouldn't have parens
 as far as I can see. I think this is just a bug in the Haskell report,
 though; CCing Malcolm.

 Either way, we should certainly be consistent in the negative zero case!

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/2036#comment:1>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Sat Jan 26 19:36:04 2008
From: trac at galois.com (GHC)
Date: Sat Jan 26 19:36:15 2008
Subject: [GHC] #2036: Show for Double and Float doesn't use parenthesis
 for negative zero.
In-Reply-To: <047.9085fb42c7e7997d5332318ebe9470cc@localhost>
References: <047.9085fb42c7e7997d5332318ebe9470cc@localhost>
Message-ID: <056.9f744c07662d21501360977e790a2a04@localhost>

#2036: Show for Double and Float doesn't use parenthesis for negative zero.
---------------------------------+------------------------------------------
 Reporter:  clanehin             |          Owner:          
     Type:  bug                  |         Status:  new     
 Priority:  normal               |      Milestone:  6.8.3   
Component:  libraries/haskell98  |        Version:  6.6.1   
 Severity:  minor                |     Resolution:          
 Keywords:                       |     Difficulty:  Unknown 
 Testcase:                       |   Architecture:  Multiple
       Os:  Multiple             |  
---------------------------------+------------------------------------------
Changes (by igloo):

  * milestone:  6.10 branch => 6.8.3

Comment:

 Actually, I think we ought to do this for 6.8.3.

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/2036#comment:2>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Sat Jan 26 19:41:36 2008
From: trac at galois.com (GHC)
Date: Sat Jan 26 19:41:09 2008
Subject: [GHC] #2038: System.Posix.Resource.setResourceLimit gives
 "setResourceLimit: invalid argument (Invalid argument)"
In-Reply-To: <045.9f2f177f681138fbf7d90d1273238fd5@localhost>
References: <045.9f2f177f681138fbf7d90d1273238fd5@localhost>
Message-ID: <054.6b8af6236a8760248fcf3afe1ffcfd70@localhost>

#2038: System.Posix.Resource.setResourceLimit gives "setResourceLimit: invalid
argument (Invalid argument)"
-----------------------------------+----------------------------------------
 Reporter:  slyfox                 |          Owner:         
     Type:  bug                    |         Status:  new    
 Priority:  high                   |      Milestone:  6.8.3  
Component:  Compiler               |        Version:  6.8.2  
 Severity:  major                  |     Resolution:         
 Keywords:  regression, ffi, unix  |     Difficulty:  Unknown
 Testcase:                         |   Architecture:  x86    
       Os:  Linux                  |  
-----------------------------------+----------------------------------------
Changes (by igloo):

  * priority:  normal => high
  * difficulty:  => Unknown
  * milestone:  => 6.8.3

Comment:

 Thanks for the report. I can reproduce this on x86/Linux, but not
 amd64/Linux.

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/2038#comment:2>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Sat Jan 26 19:43:01 2008
From: trac at galois.com (GHC)
Date: Sat Jan 26 19:42:33 2008
Subject: [GHC] #2039: Using GHC 6.8.2 as a library does not work well
 under Windows in GHCi
In-Reply-To: <051.1396b5ecbcb18e529c703113b3b39dd0@localhost>
References: <051.1396b5ecbcb18e529c703113b3b39dd0@localhost>
Message-ID: <060.7af7b9eeb13079137ea0211929a90af3@localhost>

#2039: Using GHC 6.8.2 as a library does not work well under Windows  in GHCi
----------------------------------------------------------+-----------------
 Reporter:  PVerswyvelen                                  |          Owner:         
     Type:  bug                                           |         Status:  new    
 Priority:  normal                                        |      Milestone:  6.8.3  
Component:  GHC API                                       |        Version:  6.8.2  
 Severity:  major                                         |     Resolution:         
 Keywords:  GHC API GHCi runtime linker duplicate symbol  |     Difficulty:  Unknown
 Testcase:                                                |   Architecture:  x86    
       Os:  Windows                                       |  
----------------------------------------------------------+-----------------
Changes (by igloo):

  * difficulty:  => Unknown
  * milestone:  => 6.8.3

Comment:

 Thanks for the report. We'll try to have a look for 6.8.3.

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/2039#comment:1>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Sat Jan 26 19:43:23 2008
From: trac at galois.com (GHC)
Date: Sat Jan 26 19:42:55 2008
Subject: [GHC] #2042: Add concatMapM to Control.Monad
In-Reply-To: <045.29d0c149fb4003aa216c4f2f5995cca5@localhost>
References: <045.29d0c149fb4003aa216c4f2f5995cca5@localhost>
Message-ID: <054.e857f3e319a210fba6e60ffc2c9a12f8@localhost>

#2042: Add concatMapM to Control.Monad
----------------------------+-----------------------------------------------
 Reporter:  twanvl          |          Owner:         
     Type:  proposal        |         Status:  new    
 Priority:  normal          |      Milestone:  Not GHC
Component:  libraries/base  |        Version:  6.8.2  
 Severity:  normal          |     Resolution:         
 Keywords:                  |     Difficulty:  Unknown
 Testcase:                  |   Architecture:  Unknown
       Os:  Unknown         |  
----------------------------+-----------------------------------------------
Changes (by igloo):

  * difficulty:  => Unknown
  * milestone:  => Not GHC

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/2042#comment:1>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Sun Jan 27 03:25:03 2008
From: trac at galois.com (GHC)
Date: Sun Jan 27 03:24:37 2008
Subject: [GHC] #1993: "RegAllocLinear.getStackSlotFor: out of stack
 slots" when compiling SHA1.hs in darcs
In-Reply-To: <047.e84806530b859709e5179210f10fbc2c@localhost>
References: <047.e84806530b859709e5179210f10fbc2c@localhost>
Message-ID: <056.f0bedab327fc1ea2acf811b36b1e74f6@localhost>

#1993: "RegAllocLinear.getStackSlotFor: out of stack slots" when compiling SHA1.hs
in darcs
----------------------------+-----------------------------------------------
 Reporter:  apstrand        |          Owner:             
     Type:  bug             |         Status:  new        
 Priority:  normal          |      Milestone:  6.10 branch
Component:  Compiler (NCG)  |        Version:  6.8.2      
 Severity:  normal          |     Resolution:             
 Keywords:                  |     Difficulty:  Unknown    
 Testcase:                  |   Architecture:  x86        
       Os:  Windows         |  
----------------------------+-----------------------------------------------
Comment (by alatter):

 using the attached file:

 {{{$ ghc -O -funbox-strict-fields -prof -funfolding-use-threshold20 -c
 SHA1.lhs -fregs-graph +RTS -K10M
 ghc-6.9.20080126: panic! (the 'impossible' happened)
   (GHC version 6.9.20080126 for i386-unknown-linux):
         regSpill: out of spill slots!
        regs to spill = 814
        slots left    = 677

 Please report this as a GHC bug:  http://www.haskell.org/ghc/reportabug}}}

 The {{{+RTS -K10M}}} is needed to prevent stack overflow.

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/1993#comment:5>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Sun Jan 27 10:32:59 2008
From: trac at galois.com (GHC)
Date: Sun Jan 27 10:32:31 2008
Subject: [GHC] #2066: Building 6.9 with 6.4.1 fails
Message-ID: <043.7f13a3423ee9fec021c7bc30d46308ff@localhost>

#2066: Building 6.9 with 6.4.1 fails
------------------------+---------------------------------------------------
    Reporter:  pejo     |       Owner:          
        Type:  bug      |      Status:  new     
    Priority:  normal   |   Component:  Compiler
     Version:  6.9      |    Severity:  minor   
    Keywords:           |    Testcase:          
Architecture:  Unknown  |          Os:  Unknown 
------------------------+---------------------------------------------------
 Building GHC 6.9 (20080126 snapshot) with 6.4.1 fails on ./utils/ghc-
 pkg/Main.hs, since Data.List did not have isInfixOf.

 If 6.9 is not supposed to build with 6.4, there is a bug in configure.ac
 which tests for 6.4 or newer.

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/2066>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Sun Jan 27 18:06:50 2008
From: trac at galois.com (GHC)
Date: Sun Jan 27 18:06:21 2008
Subject: [GHC] #2067: ALUT fails to build on Mac OS X
Message-ID: <044.9bc97f7b0dfe54927240854201c62c44@localhost>

#2067: ALUT fails to build on Mac OS X
----------------------------+-----------------------------------------------
    Reporter:  guest        |       Owner:              
        Type:  bug          |      Status:  new         
    Priority:  normal       |   Component:  Build System
     Version:  6.8.2        |    Severity:  normal      
    Keywords:  ALUT, build  |    Testcase:              
Architecture:  x86          |          Os:  MacOS X     
----------------------------+-----------------------------------------------
 `Sound.ALUT` (2.1.0.0) does not build on Mac OS X: It misses the C header
 file `OpenAL/alut.h`.

 After some googling I think that the reason is that Apple removed(!) this
 file from the OpenAL framework, see
 http://developer.apple.com/qa/qa2006/qa1504.html .

 `Sound.OpenAL` builds fine, but seems to be unusable without ALUT.
 Also, Christian Maeder's binary distribution of GHC 6.8.2 for Mac OS X
 10.4 (Tiger) Intel seems to miss the Sound.ALUT library (but contains
 Sound.OpenGL); I would guess that the reason is the same.

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/2067>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Sun Jan 27 18:26:33 2008
From: trac at galois.com (GHC)
Date: Sun Jan 27 18:26:03 2008
Subject: [GHC] #2002: problems with very large (list) literals
In-Reply-To: <051.64c621f5afc3e8cbd43368bfecf19488@localhost>
References: <051.64c621f5afc3e8cbd43368bfecf19488@localhost>
Message-ID: <060.b730a7c64f2a0f832aef543edc9bee2c@localhost>

#2002: problems with very large (list) literals
------------------------------------------+---------------------------------
 Reporter:  Isaac Dupree                  |          Owner:         
     Type:  compile-time performance bug  |         Status:  new    
 Priority:  high                          |      Milestone:  6.8.3  
Component:  Compiler                      |        Version:  6.8.2  
 Severity:  normal                        |     Resolution:         
 Keywords:                                |     Difficulty:  Unknown
 Testcase:                                |   Architecture:  x86    
       Os:  Linux                         |  
------------------------------------------+---------------------------------
Comment (by guest):

 I also had experiences with large literal lists. The source files were
 about 300k-500k, the list sizes are probably somewhere in the 20000-30000
 range (definitely less than 100000). I used both 6.6.1 and 6.8.2, both
 takes incredibly long time (10 minutes is not unheard of, on a 2ghz
 machine with 768mb ram), and sometimes fails spontaneously (usually memory
 allocation problems, if I recall it correctly).

 I should note though that a significant part of the compilation time is
 spent by gcc, not ghc (no idea about the exact ratio).

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/2002#comment:4>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Mon Jan 28 06:21:30 2008
From: trac at galois.com (GHC)
Date: Mon Jan 28 06:20:58 2008
Subject: [GHC] #2066: Building 6.9 with 6.4.1 fails
In-Reply-To: <043.7f13a3423ee9fec021c7bc30d46308ff@localhost>
References: <043.7f13a3423ee9fec021c7bc30d46308ff@localhost>
Message-ID: <052.e8ab3eb587e4568d820c2f8208d739c6@localhost>

#2066: Building 6.9 with 6.4.1 fails
----------------------+-----------------------------------------------------
 Reporter:  pejo      |          Owner:             
     Type:  bug       |         Status:  new        
 Priority:  high      |      Milestone:  6.10 branch
Component:  Compiler  |        Version:  6.9        
 Severity:  minor     |     Resolution:             
 Keywords:            |     Difficulty:  Easy (1 hr)
 Testcase:            |   Architecture:  Unknown    
       Os:  Unknown   |  
----------------------+-----------------------------------------------------
Changes (by simonmar):

  * priority:  normal => high
  * difficulty:  => Easy (1 hr)
  * milestone:  => 6.10 branch

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/2066#comment:1>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Mon Jan 28 07:15:39 2008
From: trac at galois.com (GHC)
Date: Mon Jan 28 07:15:06 2008
Subject: [GHC] #2068: need better exception names for fgl
Message-ID: <047.e3f6170318938c8777e7bf908f91dee1@localhost>

#2068: need better exception names for fgl
--------------------------------+-------------------------------------------
    Reporter:  Frederik         |       Owner:                   
        Type:  feature request  |      Status:  new              
    Priority:  normal           |   Component:  libraries (other)
     Version:  6.8.2            |    Severity:  normal           
    Keywords:                   |    Testcase:                   
Architecture:  Unknown          |          Os:  Unknown          
--------------------------------+-------------------------------------------
 Every once in a while, due to bugs in my code, when using fgl I see
 exceptions such as "Edge Exception, Node: 30". I think it would be better
 if messages like this in the library could be more informative, such as
 "Invalid node 439 in edge from node 30" or "Duplicate node 30" etc. Given
 that there is a problem with the graph, and given that graphs are made of
 nodes and edges, it is a good bet that the problem has something to do
 with a node or an edge, so saying "Node Exception" or "Edge Exception"
 doesn't provide users with very much information.

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/2068>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Mon Jan 28 12:13:23 2008
From: trac at galois.com (GHC)
Date: Mon Jan 28 12:12:56 2008
Subject: [GHC] #2069: GHC crashes when both -shared and --make flags are
 specified
Message-ID: <049.a76d3ffa368ec969b89faebab8692341@localhost>

#2069: GHC crashes when both -shared and --make flags are specified
---------------------------+------------------------------------------------
    Reporter:  bchallenor  |       Owner:          
        Type:  bug         |      Status:  new     
    Priority:  normal      |   Component:  Compiler
     Version:  6.8.1       |    Severity:  normal  
    Keywords:              |    Testcase:          
Architecture:  x86         |          Os:  Windows 
---------------------------+------------------------------------------------
 I'm not even sure if you're meant to be able to do this, but I wanted to
 build a DLL without manually specifying the files, so I tried to do the
 build and the archiving in one step.

 But I get a panic:

 >ghc -shared --make LibFunslang
 ghc: panic! (the 'impossible' happened)
   (GHC version 6.8.1 for i386-unknown-mingw32):
         main/DriverPipeline.hs:(270,0)-(337,23): Non-exhaustive patterns
 in func
 tion link

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/2069>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Mon Jan 28 15:52:36 2008
From: trac at galois.com (GHC)
Date: Mon Jan 28 15:52:02 2008
Subject: [GHC] #2070: Record field selectors are not optimized
Message-ID: <045.8e094bc4214e699ba9a0f23a87d8a407@localhost>

#2070: Record field selectors are not optimized
------------------------+---------------------------------------------------
    Reporter:  twanvl   |       Owner:          
        Type:  bug      |      Status:  new     
    Priority:  normal   |   Component:  Compiler
     Version:  6.9      |    Severity:  normal  
    Keywords:           |    Testcase:          
Architecture:  Unknown  |          Os:  Unknown 
------------------------+---------------------------------------------------
 It seems that record field selectors are not optimized. Usually this
 doesn't matter, but when there are unpacked fields this leaves suboptimal
 code. The equivalent code using the data type constructor ''is''
 optimized.

 For example:
 {{{
 module Test where

 data Test = Test { getR :: {-# UNPACK #-} !Int }
 getC (Test a) = a
 }}}

 Generates the following core (with -O2 -ddump-simpl):

 {{{
 Test.getR :: Test.Test -> GHC.Base.Int
 [RecSel]
 [Arity 1
  NoCafRefs
  Str: DmdType U(L)m]
 Test.getR =
   \ (tpl_B1 :: Test.Test) ->
     case tpl_B1 of tpl1_B2 { Test.Test rb_B4 ->
     let {
       ipv_B3 [Just S] :: GHC.Base.Int
       [Str: DmdType m]
       ipv_B3 = GHC.Base.I# rb_B4
     } in  ipv_B3
     }

 Test.getC :: Test.Test -> GHC.Base.Int
 [GlobalId]
 [Arity 1
  NoCafRefs
  Str: DmdType U(L)m]
 Test.getC =
   \ (ds_d5Q :: Test.Test) ->
     case ds_d5Q of wild_B1 { Test.Test rb_d5S -> GHC.Base.I# rb_d5S }
 }}}

 After further investigation, it seems that `getR` is not passed through
 the optimizer at all, earlier simplifier passes (-ddump-simpl-iterations,
 -ddump-cse, -ddump-occur-anal) do not include the function.

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/2070>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Mon Jan 28 22:53:37 2008
From: trac at galois.com (GHC)
Date: Mon Jan 28 22:54:47 2008
Subject: [GHC] #2071: hp2ps does not handle SCCs with spaces in the
 identifiers
Message-ID: <043.db084f3257628fb450a2954b1e1b4fcc@localhost>

#2071: hp2ps does not handle SCCs with spaces in the identifiers
-------------------------+--------------------------------------------------
    Reporter:  benl      |       Owner:           
        Type:  bug       |      Status:  new      
    Priority:  normal    |   Component:  Profiling
     Version:  6.8.2     |    Severity:  normal   
    Keywords:            |    Testcase:           
Architecture:  Multiple  |          Os:  Multiple 
-------------------------+--------------------------------------------------
 If the source program defines a SCC with a space in the identifier, then
 it compiles ok but hp2ps falls over with a non-informative "integer must
 follow identifier" when trying to parse the resulting .hp file.

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/2071>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Tue Jan 29 11:24:17 2008
From: trac at galois.com (GHC)
Date: Tue Jan 29 11:23:51 2008
Subject: [GHC] #1717: ghc-6.8 configure does not recognise 32bit
 userland on ppc64
In-Reply-To: <059.9ba98474c2b63eccc55349ae913ba846@localhost>
References: <059.9ba98474c2b63eccc55349ae913ba846@localhost>
Message-ID: <068.e15e6852cc4d3dc7b4503f46e59eb976@localhost>

#1717: ghc-6.8 configure does not recognise 32bit userland on ppc64
----------------------------------+-----------------------------------------
 Reporter:  kahl@cas.mcmaster.ca  |          Owner:             
     Type:  bug                   |         Status:  reopened   
 Priority:  normal                |      Milestone:  6.8.3      
Component:  Build System          |        Version:  6.8        
 Severity:  normal                |     Resolution:             
 Keywords:                        |     Difficulty:  Easy (1 hr)
 Testcase:  normal build          |   Architecture:  powerpc64  
       Os:  Linux                 |  
----------------------------------+-----------------------------------------
Changes (by simonmar):

  * priority:  low => normal
  * difficulty:  Unknown => Easy (1 hr)
  * status:  closed => reopened
  * resolution:  wontfix =>
  * milestone:  6.8.2 => 6.8.3

Comment:

 Re-opening.  It seems there are Linux/x86-64 installations that have the
 same behaviour: `uname -m` reports x86-64, but gcc and tools generate x86
 binaries.

 Plan: detect when this has happened and bail out in configure, perhaps
 suggesting the use of `linux32`.

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/1717#comment:13>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Tue Jan 29 17:55:47 2008
From: trac at galois.com (GHC)
Date: Tue Jan 29 17:55:11 2008
Subject: [GHC] #2072: freebsd/amd64: don't know how to mangle assembly
 language
Message-ID: <046.3e104ec5c02d771b814fafeb449f23f1@localhost>

#2072: freebsd/amd64: don't know how to mangle assembly language
-------------------------------+--------------------------------------------
    Reporter:  newsham         |       Owner:          
        Type:  bug             |      Status:  new     
    Priority:  normal          |   Component:  Compiler
     Version:  6.8.2           |    Severity:  normal  
    Keywords:  ghc-asm         |    Testcase:          
Architecture:  x86_64 (amd64)  |          Os:  FreeBSD 
-------------------------------+--------------------------------------------
 Trying to build the zlib package I ran across this error:
 ghc-asm: don't know how to mangle assembly language for: x86_64-unknown-
 freebsd

 I'm running ghc-6.8.2 on FreeBSD 6.2-STABLE / amd64.  I built from sources
 today
 using the FreeBSD/amd64 linking patch that I found in the bug Trac (which
 fixes relocation so that ghci works).

 newsham@hpsux$ ghc --version
 The Glorious Glasgow Haskell Compilation System, version 6.8.2
 newsham@hpsux$ gcc --version
 gcc (GCC) 3.4.6 [FreeBSD] 20060305
 Copyright (C) 2006 Free Software Foundation, Inc.
 This is free software; see the source for copying conditions.  There is NO
 warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR
 PURPOSE.
 newsham@hpsux$ uname -a
 FreeBSD hpsux.x0d99.com 6.2-STABLE FreeBSD 6.2-STABLE #1: Fri Aug  3
 18:39:42 HST 2007
 root@hpsux.x0d99.com:/usr/src/sys/amd64/compile/THENEWSH  amd64

 I can provide further information if necessary.

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/2072>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Tue Jan 29 18:08:42 2008
From: trac at galois.com (GHC)
Date: Tue Jan 29 18:08:06 2008
Subject: [GHC] #2072: freebsd/amd64: don't know how to mangle assembly
 language
In-Reply-To: <046.3e104ec5c02d771b814fafeb449f23f1@localhost>
References: <046.3e104ec5c02d771b814fafeb449f23f1@localhost>
Message-ID: <055.2063c7e0da30e0b9d489e81945d85652@localhost>

#2072: freebsd/amd64: don't know how to mangle assembly language
-------------------------------+--------------------------------------------
    Reporter:  newsham         |        Owner:         
        Type:  bug             |       Status:  new    
    Priority:  normal          |    Milestone:         
   Component:  Compiler        |      Version:  6.8.2  
    Severity:  normal          |   Resolution:         
    Keywords:  ghc-asm         |     Testcase:         
Architecture:  x86_64 (amd64)  |           Os:  FreeBSD
-------------------------------+--------------------------------------------
Comment (by newsham):

 Removing -fvia-C from zlib's cabal file made the issue go away.

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/2072#comment:1>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Tue Jan 29 19:17:24 2008
From: trac at galois.com (GHC)
Date: Tue Jan 29 19:16:47 2008
Subject: [GHC] #2072: freebsd/amd64: don't know how to mangle assembly
 language
In-Reply-To: <046.3e104ec5c02d771b814fafeb449f23f1@localhost>
References: <046.3e104ec5c02d771b814fafeb449f23f1@localhost>
Message-ID: <055.6f5ee1239b10803d3dc1bd72bc13f16b@localhost>

#2072: freebsd/amd64: don't know how to mangle assembly language
-------------------------------+--------------------------------------------
    Reporter:  newsham         |        Owner:         
        Type:  bug             |       Status:  new    
    Priority:  normal          |    Milestone:         
   Component:  Compiler        |      Version:  6.8.2  
    Severity:  normal          |   Resolution:         
    Keywords:  ghc-asm         |     Testcase:         
Architecture:  x86_64 (amd64)  |           Os:  FreeBSD
-------------------------------+--------------------------------------------
Comment (by newsham):

 Looks like an easy fix for this one.  In
 driver/mangler/ghc-asm.prl add freebsd to line 219 to get:

     } elsif ( $TargetPlatform =~ /^x86_64-.*-(linux|openbsd|freebsd)$/m )
 {
                                                            ^^^^^^^^^

 zlib now builds as-is.

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/2072#comment:2>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Tue Jan 29 23:19:08 2008
From: trac at galois.com (GHC)
Date: Tue Jan 29 23:18:37 2008
Subject: [GHC] #1717: ghc-6.8 configure does not recognise 32bit
 userland on ppc64
In-Reply-To: <059.9ba98474c2b63eccc55349ae913ba846@localhost>
References: <059.9ba98474c2b63eccc55349ae913ba846@localhost>
Message-ID: <068.bea466b1df1da3918c2c17a3cfe42f44@localhost>

#1717: ghc-6.8 configure does not recognise 32bit userland on ppc64
----------------------------------+-----------------------------------------
 Reporter:  kahl@cas.mcmaster.ca  |          Owner:             
     Type:  bug                   |         Status:  reopened   
 Priority:  normal                |      Milestone:  6.8.3      
Component:  Build System          |        Version:  6.8        
 Severity:  normal                |     Resolution:             
 Keywords:                        |     Difficulty:  Easy (1 hr)
 Testcase:  normal build          |   Architecture:  powerpc64  
       Os:  Linux                 |  
----------------------------------+-----------------------------------------
Comment (by wkahl):

 Since {{{linux32}}} only acts on {{{uname -m}}}, and {{{uname -m}}} is not
 the right question to ask anyway, I would rather suggest chosing an
 appropriate {{{--build}}} setting ? this way at least the end user uses an
 appropriate interface.

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/1717#comment:14>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Wed Jan 30 03:57:32 2008
From: trac at galois.com (GHC)
Date: Wed Jan 30 03:57:04 2008
Subject: [GHC] #1717: ghc-6.8 configure does not recognise 32bit
 userland on ppc64
In-Reply-To: <059.9ba98474c2b63eccc55349ae913ba846@localhost>
References: <059.9ba98474c2b63eccc55349ae913ba846@localhost>
Message-ID: <068.6729f509dc04b672ee0fc4601084b78e@localhost>

#1717: ghc-6.8 configure does not recognise 32bit userland on ppc64
----------------------------------+-----------------------------------------
 Reporter:  kahl@cas.mcmaster.ca  |          Owner:             
     Type:  bug                   |         Status:  reopened   
 Priority:  normal                |      Milestone:  6.8.3      
Component:  Build System          |        Version:  6.8        
 Severity:  normal                |     Resolution:             
 Keywords:                        |     Difficulty:  Easy (1 hr)
 Testcase:  normal build          |   Architecture:  powerpc64  
       Os:  Linux                 |  
----------------------------------+-----------------------------------------
Comment (by simonmar):

 We want to do the right thing here, but I'm not sure it's as simple as you
 say.

 If there's a mismatch between `uname -m` and the kind of binaries that gcc
 produces, then who's to say which one is "right"?  You might have
 forgotten to point the build at the correct gcc, or you might have
 forgotten to use `linux32`.  We could guess that you wanted a 32-bit build
 and do that, but we might be wrong.  The best we can do is spot the
 inconsistency and ask the user to resolve it.

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/1717#comment:15>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Wed Jan 30 04:59:34 2008
From: trac at galois.com (GHC)
Date: Wed Jan 30 04:59:30 2008
Subject: [GHC] #740: Copyright information is wrong in some GHC source
 files
In-Reply-To: <044.e3018ba04e94127af296980fb94fc0de@localhost>
References: <044.e3018ba04e94127af296980fb94fc0de@localhost>
Message-ID: <053.3564cea9faeea223dc4373a98bf03c00@localhost>

#740: Copyright information is wrong in some GHC source files
---------------------+------------------------------------------------------
 Reporter:  guest    |          Owner:         
     Type:  bug      |         Status:  new    
 Priority:  lowest   |      Milestone:  _|_    
Component:  Prelude  |        Version:  6.4.1  
 Severity:  trivial  |     Resolution:         
 Keywords:           |     Difficulty:  Unknown
 Testcase:  N/A      |   Architecture:  Unknown
       Os:  Unknown  |  
---------------------+------------------------------------------------------
Comment (by chak):

 I agree with Tim that the current situation appears to be legally awkward.
 It as a disadvantage of the BSD3 license (as opposed to the GPL) that the
 license does not force contributors to agree to the license by the act of
 contributing.  Hence, it might be a good idea to explicitly ask everybody
 whether they agree to submit all patches under BSD3 before handing them a
 commit bit - and save that email ;)  The same question should be asked to
 everybody who sends major patches by email (whatever major is here).

 Independent of this, the copyright information in many source files of GHC
 and the libraries is simply wrong.  Any major author of source code is
 '''automatically''' a joint copyright holder - independent of whether
 there is an appropriate attribution in the file (or anywhere else).  It's
 the act of creation that makes you a copyright owner (not the act of
 claiming copyright).  Concerning the practice of assigning the copyright
 to another entity, this is a rather questionable practice as the legal
 systems of some countries (e.g., Germany) do not allow copyright transfers
 (only the transfer of "usage rights").

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/740#comment:14>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Wed Jan 30 08:33:51 2008
From: trac at galois.com (GHC)
Date: Wed Jan 30 08:33:13 2008
Subject: [GHC] #2072: freebsd/amd64: don't know how to mangle assembly
 language
In-Reply-To: <046.3e104ec5c02d771b814fafeb449f23f1@localhost>
References: <046.3e104ec5c02d771b814fafeb449f23f1@localhost>
Message-ID: <055.666e168266ac4a187bc1590552617f1a@localhost>

#2072: freebsd/amd64: don't know how to mangle assembly language
----------------------+-----------------------------------------------------
 Reporter:  newsham   |          Owner:                
     Type:  bug       |         Status:  new           
 Priority:  high      |      Milestone:  6.8.3         
Component:  Compiler  |        Version:  6.8.2         
 Severity:  normal    |     Resolution:                
 Keywords:  ghc-asm   |     Difficulty:  Easy (1 hr)   
 Testcase:            |   Architecture:  x86_64 (amd64)
       Os:  FreeBSD   |  
----------------------+-----------------------------------------------------
Changes (by simonmar):

  * priority:  normal => high
  * difficulty:  => Easy (1 hr)
  * milestone:  => 6.8.3

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/2072#comment:3>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Wed Jan 30 20:52:35 2008
From: trac at galois.com (GHC)
Date: Wed Jan 30 20:51:55 2008
Subject: [GHC] #2067: ALUT fails to build on Mac OS X
In-Reply-To: <044.9bc97f7b0dfe54927240854201c62c44@localhost>
References: <044.9bc97f7b0dfe54927240854201c62c44@localhost>
Message-ID: <053.7e32d194b2af8fe767ed91c173b79097@localhost>

#2067: ALUT fails to build on Mac OS X
--------------------------+-------------------------------------------------
 Reporter:  guest         |          Owner:         
     Type:  bug           |         Status:  closed 
 Priority:  normal        |      Milestone:         
Component:  Build System  |        Version:  6.8.2  
 Severity:  normal        |     Resolution:  invalid
 Keywords:  ALUT, build   |     Difficulty:  Unknown
 Testcase:                |   Architecture:  x86    
       Os:  MacOS X       |  
--------------------------+-------------------------------------------------
Changes (by igloo):

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

Comment:

 In order to build ALUT, you need the C ALUT library. It sounds like this
 is no longer installed by default on OS X, so you will have to install it
 yourself if you want to build the Haskell ALUT bindings.

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/2067#comment:1>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Thu Jan 31 11:56:29 2008
From: trac at galois.com (GHC)
Date: Thu Jan 31 11:55:51 2008
Subject: [GHC] #1773: Add Compositor class as superclass of Arrow,
 in Control.Compositor
In-Reply-To: <044.78ae3c60c642371e90fdd909551e1ac9@localhost>
References: <044.78ae3c60c642371e90fdd909551e1ac9@localhost>
Message-ID: <053.e73a9cf926e1924b0d47d0e83f16204b@localhost>

#1773: Add Compositor class as superclass of Arrow, in Control.Compositor
----------------------------+-----------------------------------------------
 Reporter:  guest           |          Owner:         
     Type:  proposal        |         Status:  closed 
 Priority:  normal          |      Milestone:  Not GHC
Component:  libraries/base  |        Version:  6.6.1  
 Severity:  normal          |     Resolution:  fixed  
 Keywords:                  |     Difficulty:  Unknown
 Testcase:                  |   Architecture:  Unknown
       Os:  Unknown         |  
----------------------------+-----------------------------------------------
Comment (by desegnis):

 Is the question allowed how packages relying on the old Arrow interface
 should handle the changing situation?  Will they be #ifdef'ing on the
 version of base?

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/1773#comment:3>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
From trac at galois.com  Thu Jan 31 15:52:16 2008
From: trac at galois.com (GHC)
Date: Thu Jan 31 15:51:44 2008
Subject: [GHC] #2073: ghci records empty input lines in readline history
Message-ID: <045.754f0911fd9e82aafab4d99a7c2d2f12@localhost>

#2073: ghci records empty input lines in readline history
----------------------------------+-----------------------------------------
    Reporter:  Eelis-             |       Owner:         
        Type:  bug                |      Status:  new    
    Priority:  normal             |   Component:  GHCi   
     Version:  6.8.2              |    Severity:  minor  
    Keywords:  readline, history  |    Testcase:         
Architecture:  Unknown            |          Os:  Unknown
----------------------------------+-----------------------------------------
 Ghci records empty input lines in the readline history. This appears to be
 a regression compared to 6.6.1.

 (To reproduce, start ghci, enter "3", press <enter>, press <enter> again,
 and then press <up-arrow> once. You'll get an empty line, while you should
 get "3" again.)

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/2073>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler