- ghc-tickets - Haskell.org

[GHC] #11021: Document best practices for bringing up Sphinx on Windows
by GHC 02 Nov '15

02 Nov '15

#11021: Document best practices for bringing up Sphinx on Windows -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: task | Status: new Priority: normal | Milestone: 8.0.1 Component: Documentation | Version: 7.11 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- The Sphinx documentation tool that we now use to generate the users guide is unfortunately a bit tricky to get working on Windows. See, for instance, https://mail.haskell.org/pipermail/ghc- devs/2015-October/010199.html We need to improve this situation or at very least document how users can build documentation on Windows. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11021> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 12

[GHC] #11030: D757 (emit Typeable at type definition site) regresses T3294 max_bytes_used by factor of two
by GHC 02 Nov '15

02 Nov '15

#11030: D757 (emit Typeable at type definition site) regresses T3294 max_bytes_used by factor of two -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.11 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Compile-time Unknown/Multiple | performance bug Test Case: T3294 | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I noticed that D757 caused max_bytes_allocated to go from 45MBytes to 96MBytes while updating the testsuite. This may be expected but I want to ensure I look into this since the test defines only one type (albeit with many fields) and a `Show` instance so we wouldn't necessarily expect this test to regress by this amount. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11030> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #11017: ApiAnnotations: BooleanFormula is not properly Located
by GHC 01 Nov '15

01 Nov '15

#11017: ApiAnnotations: BooleanFormula is not properly Located -------------------------------------+------------------------------------- Reporter: alanz | Owner: alanz Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.2 Keywords: | Operating System: Unknown/Multiple ApiAnnotations | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- At the moment `BooleanFormula` is defined as {{{#!hs data BooleanFormula a = Var a | And [BooleanFormula a] | Or [BooleanFormula a] deriving (Eq, Data, Typeable, Functor, Foldable, Traversable) }}} An API Annotation can only be attached to an item of the form `Located a`. Replace this with a properly `Located` version, and attach the appropriate API Annotations to it -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11017> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #11043: Bump `ghc-prim` to 0.5.0.0
by GHC 01 Nov '15

01 Nov '15

#11043: Bump `ghc-prim` to 0.5.0.0 -------------------------------------+------------------------------------- Reporter: hvr | Owner: Type: task | Status: new Priority: high | Milestone: 8.0.1 Component: | Version: 7.11 libraries/base | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11043> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #10877: x86_64: dll-split: out of memory (requested 1099512676352 bytes)
by GHC 01 Nov '15

01 Nov '15

#10877: x86_64: dll-split: out of memory (requested 1099512676352 bytes) -------------------------------------+------------------------------------- Reporter: | Owner: RyanGlScott | Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 Keywords: | Operating System: Linux Architecture: x86_64 | Type of failure: Building GHC (amd64) | failed Test Case: | Blocked By: Blocking: | Related Tickets: #10682 Differential Revisions: | -------------------------------------+------------------------------------- Attempting to build GHC on an x86_64 Linux machine fails for me: {{{ $ make ===--- building phase 0 make --no-print-directory -f ghc.mk phase=0 phase_0_builds make[1]: Nothing to be done for `phase_0_builds'. ===--- building phase 1 make --no-print-directory -f ghc.mk phase=1 phase_1_builds make[1]: Nothing to be done for `phase_1_builds'. ===--- building final phase make --no-print-directory -f ghc.mk phase=final all inplace/bin/dll-split compiler/stage2/build/.depend-v-dyn.haskell "DynFlags" "Annotations ApiAnnotation Avail Bag BasicTypes Binary BooleanFormula BreakArray BufWrite Class CmdLineParser CmmType CoAxiom ConLike Coercion Config Constants CoreArity CoreFVs CoreSubst CoreSyn CoreTidy CoreUnfold CoreUtils CoreSeq CoreStats CostCentre Ctype DataCon Demand Digraph DriverPhases DynFlags Encoding ErrUtils Exception FamInstEnv FastFunctions FastMutInt FastString Fingerprint FiniteMap ForeignCall Hooks HsBinds HsDecls HsDoc HsExpr HsImpExp HsLit PlaceHolder HsPat HsSyn HsTypes HsUtils HscTypes IOEnv Id IdInfo IfaceSyn IfaceType InstEnv Kind Lexeme Lexer ListSetOps Literal Maybes MkCore MkId Module MonadUtils Name NameEnv NameSet OccName OccurAnal OptCoercion OrdList Outputable PackageConfig Packages Pair Panic PatSyn PipelineMonad Platform PlatformConstants PprCore PrelNames PrelRules Pretty PrimOp RdrName Rules Serialized SrcLoc StaticFlags StringBuffer TcEvidence TcRnTypes TcType TrieMap TyCon Type TypeRep TysPrim TysWiredIn Unify UniqFM UniqSet UniqSupply Unique Util Var VarEnv VarSet Bitmap BlockId ByteCodeAsm ByteCodeInstr ByteCodeItbls CLabel Cmm CmmCallConv CmmExpr CmmInfo CmmMachOp CmmNode CmmSwitch CmmUtils CodeGen.Platform CodeGen.Platform.ARM CodeGen.Platform.ARM64 CodeGen.Platform.NoRegs CodeGen.Platform.PPC CodeGen.Platform.PPC_Darwin CodeGen.Platform.SPARC CodeGen.Platform.X86 CodeGen.Platform.X86_64 Hoopl Hoopl.Dataflow InteractiveEvalTypes MkGraph PprCmm PprCmmDecl PprCmmExpr Reg RegClass SMRep StgCmmArgRep StgCmmClosure StgCmmEnv StgCmmLayout StgCmmMonad StgCmmProf StgCmmTicky StgCmmUtils StgSyn Stream" dll-split: out of memory (requested 1099512676352 bytes) make[1]: *** [compiler/stage2/dll-split.stamp] Error 1 make: *** [all] Error 2 }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10877> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 17

[GHC] #10917: Provide a utility to check API Annotations
by GHC 01 Nov '15

01 Nov '15

#10917: Provide a utility to check API Annotations -------------------------------------+------------------------------------- Reporter: alanz | Owner: alanz Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.2 Keywords: | Operating System: Unknown/Multiple ApiAnnotations | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | -------------------------------------+------------------------------------- At the moment it is difficult for GHC developers to know if they have broken the API Annotations. Provide a utility that can be used as a test to show up errors in the API Annotations. This is to be based on the current tests for ghc-api/annotations which can parse a file using the just-built GHC API, and check that no annotations are disconnected from the ParsedSource in the output. In addition, it should be able to dump the annotations to a file, so a new feature developer can check that all changes to the parser do provide annotations. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10917> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 9

Re: [GHC] #3242: ghci: can't load .so/.DLL for: m (addDLL: could not load DLL)
by GHC 01 Nov '15

01 Nov '15

#3242: ghci: can't load .so/.DLL for: m (addDLL: could not load DLL) ---------------------------------+----------------------------- Reporter: jeffz1 | Owner: Phyx- Type: bug | Status: new Priority: high | Milestone: 8.0.1 Component: GHCi | Version: 7.4.1 Resolution: | Keywords: Operating System: Windows | Architecture: x86 Type of failure: None/Unknown | Test Case: Blocked By: 3658 | Blocking: Related Tickets: #7097 | Differential Rev(s): Wiki Page: | ---------------------------------+----------------------------- Comment (by Phyx-): Yup, `findSysDll` on Windows will try to see if `assumeDll` would be loading anything. on other platforms it just does a `no-op` -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/3242#comment:42> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #3242: ghci: can't load .so/.DLL for: m (addDLL: could not load DLL)
by GHC 31 Oct '15

31 Oct '15

#3242: ghci: can't load .so/.DLL for: m (addDLL: could not load DLL) ---------------------------------+----------------------------- Reporter: jeffz1 | Owner: Phyx- Type: bug | Status: new Priority: high | Milestone: 8.0.1 Component: GHCi | Version: 7.4.1 Resolution: | Keywords: Operating System: Windows | Architecture: x86 Type of failure: None/Unknown | Test Case: Blocked By: 3658 | Blocking: Related Tickets: #7097 | Differential Rev(s): Wiki Page: | ---------------------------------+----------------------------- Comment (by Kludgy): Great insight! I'm really looking forward to this patch. I presume `findSysDll` is the new function? Replying to [comment:40 Phyx-]: > It seems the issue is caused by `findArchive` being unable to find any archives that are shipped using the in-place `GCC`. > - It works on Linux because `findArchive` would search the standard Linux include path. > - It works during compilation because `GCC` can find it's own libraries (we explicitly tell it where to look for libraries using the `gcc` wrapper around `realgcc`) > > So fixing the issue means using `searchForLibUsingGcc` in `findArchive` as well, which will then find the correct file. > > The reason for the error as it is, is because if we can't locate the library using any of the methods we have, we assume it is a system dll, or something on the system search path. e.g. if trying to load `kernel32.dll`. > > There is a slight issue in that the `GHCi` code (incorrectly) favors `static archives` over `dynamic` ones > > {{{ > findDll `orElse` > findArchive `orElse` > tryGcc `orElse` > tryGccPrefixed `orElse` > assumeDll > }}} > > This has the unwanted effect of when `kernel32` is specific as a lib, it will try to load `kernel32.a` instead of `kernel32.dll`. > > To solve this I have added another search function that is able to search the Windows search paths using `SearchPath` in order to find if it is a dll on the system search path. > > The new search order is: > > {{{ > findDll `orElse` > findSysDll `orElse` > tryGcc `orElse` > findArchive `orElse` > assumeDll > }}} > > (`tryGccPrefixed` was rolled into `tryGcc` so it is no longer needed at top level) > > This seems to be working well, it is dependent on another patch of mine so have to push that one through before this one. But patch coming soon. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/3242#comment:41> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #11038: No more unsafePerformIO.com
by GHC 31 Oct '15

31 Oct '15

#11038: No more unsafePerformIO.com -------------------------------------+------------------------------------- Reporter: | Owner: doismellburning | Type: bug | Status: new Priority: normal | Milestone: Component: Code Coverage | Version: 7.10.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Documentation Unknown/Multiple | bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- According to https://wiki.haskell.org/Haskell_program_coverage > The latest version is version 0.4 and can be found at: http://projects.unsafePerformIO.com/hpc That's no longer the case given unsafeperformio.com doesn't resolve any more! If I knew what URL to use, I'd attempt to change it myself ;) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11038> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

Re: [GHC] #3242: ghci: can't load .so/.DLL for: m (addDLL: could not load DLL)
by GHC 31 Oct '15

31 Oct '15

#3242: ghci: can't load .so/.DLL for: m (addDLL: could not load DLL) ---------------------------------+----------------------------- Reporter: jeffz1 | Owner: Phyx- Type: bug | Status: new Priority: high | Milestone: 8.0.1 Component: GHCi | Version: 7.4.1 Resolution: | Keywords: Operating System: Windows | Architecture: x86 Type of failure: None/Unknown | Test Case: Blocked By: 3658 | Blocking: Related Tickets: #7097 | Differential Rev(s): Wiki Page: | ---------------------------------+----------------------------- Comment (by Phyx-): It seems the issue is caused by `findArchive` being unable to find any archives that are shipped using the in-place `GCC`. - It works on Linux because `findArchive` would search the standard Linux include path. - It works during compilation because `GCC` can find it's own libraries (we explicitly tell it where to look for libraries using the `gcc` wrapper around `realgcc`) So fixing the issue means using `searchForLibUsingGcc` in `findArchive` as well, which will then find the correct file. The reason for the error as it is, is because if we can't locate the library using any of the methods we have, we assume it is a system dll, or something on the system search path. e.g. if trying to load `kernel32.dll`. There is a slight issue in that the `GHCi` code (incorrectly) favors `static archives` over `dynamic` ones {{{ findDll `orElse` findArchive `orElse` tryGcc `orElse` tryGccPrefixed `orElse` assumeDll }}} This has the unwanted effect of when `kernel32` is specific as a lib, it will try to load `kernel32.a` instead of `kernel32.dll`. To solve this I have added another search function that is able to search the Windows search paths using `SearchPath` in order to find if it is a dll on the system search path. The new search order is: {{{ findDll `orElse` findSysDll `orElse` tryGcc `orElse` findArchive `orElse` assumeDll }}} (`tryGccPrefixed` was rolled into `tryGcc` so it is no longer needed at top level) This seems to be working well, it is dependent on another patch of mine so have to push that one through before this one. But patch coming soon. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/3242#comment:40> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0