Haskell.org
Sign In Sign Up
Manage this list Sign In Sign Up

Keyboard Shortcuts

Thread View

  • j: Next unread message
  • k: Previous unread message
  • j a: Jump to all threads
  • j l: Jump to MailingList overview

ghc-tickets

Thread Start a new thread
Download
Threads by month
  • ----- 2025 -----
  • July
  • June
  • May
  • April
  • March
  • February
  • January
  • ----- 2024 -----
  • December
  • November
  • October
  • September
  • August
  • July
  • June
  • May
  • April
  • March
  • February
  • January
  • ----- 2023 -----
  • December
  • November
  • October
  • September
  • August
  • July
  • June
  • May
  • April
  • March
  • February
  • January
  • ----- 2022 -----
  • December
  • November
  • October
  • September
  • August
  • July
  • June
  • May
  • April
  • March
  • February
  • January
  • ----- 2021 -----
  • December
  • November
  • October
  • September
  • August
  • July
  • June
  • May
  • April
  • March
  • February
  • January
  • ----- 2020 -----
  • December
  • November
  • October
  • September
  • August
  • July
  • June
  • May
  • April
  • March
  • February
  • January
  • ----- 2019 -----
  • December
  • November
  • October
  • September
  • August
  • July
  • June
  • May
  • April
  • March
  • February
  • January
  • ----- 2018 -----
  • December
  • November
  • October
  • September
  • August
  • July
  • June
  • May
  • April
  • March
  • February
  • January
  • ----- 2017 -----
  • December
  • November
  • October
  • September
  • August
  • July
  • June
  • May
  • April
  • March
  • February
  • January
  • ----- 2016 -----
  • December
  • November
  • October
  • September
  • August
  • July
  • June
  • May
  • April
  • March
  • February
  • January
  • ----- 2015 -----
  • December
  • November
  • October
  • September
  • August
  • July
  • June
  • May
  • April
  • March
  • February
  • January
  • ----- 2014 -----
  • December
  • November
  • October
  • September
  • August
  • July
  • June
  • May
  • April
  • March
  • February
  • January
  • ----- 2013 -----
  • December
  • November
  • October
  • September
  • August
  • July
  • June
  • May
  • April
  • March
  • February
  • January
ghc-tickets@haskell.org

August 2015

  • 1 participants
  • 1064 discussions
Re: [GHC] #3379: GHC should use the standard binary package
by GHC 24 Aug '15

24 Aug '15
#3379: GHC should use the standard binary package -------------------------------------+------------------------------------- Reporter: igloo | Owner: Type: task | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 6.10.4 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thomie): * cc: kolmodin, jstolarek (added) Comment: The binary package received a portable implementation of `instance Binary Integer` in the following commit: https://github.com/kolmodin/binary/commit/2109b28f4d3919dbedcf42c97e5147116… GHC's version looks like this: {{{ instance Binary Integer where -- XXX This is hideous put_ bh i = put_ bh (show i) get bh = do str <- get bh case reads str of [(i, "")] -> return i _ -> fail ("Binary Integer: got " ++ show str) }}} As mentioned in Phab:D1165, `compiler/utils/Binary.hs` contains also a commented out implementation of `instance Binary Integer`. It is supposedly more efficient than the one in the `binary` package (but not portable?). This should all be cleared and cleaned up. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/3379#comment:10> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler
1 0
0 0
Re: [GHC] #1830: Automatic derivation of Lift
by GHC 24 Aug '15

24 Aug '15
#1830: Automatic derivation of Lift -------------------------------------+------------------------------------- Reporter: guest | Owner: | RyanGlScott Type: feature request | Status: new Priority: normal | Milestone: ⊥ Component: Template Haskell | Version: 6.8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: Phab:D1168 -------------------------------------+------------------------------------- Comment (by RyanGlScott): Replying to [comment:10 goldfire]: > What's wrong with using `th-lift`? Type inference. `th-lift` is fundamentally limited in that it cannot infer the correct instance context for complex data structures such as {{{#!hs data Nested f a = Nested (f a) deriving Lift -- instance Lift (f a) => Lift (Nested f a) where ... }}} or {{{#!hs data R a = R a instance (Show a, Lift a) => Lift (R a) where ... data Restricted a = Restricted (R a) deriving Lift -- instance (Show a, Lift a) => Lift (Restricted a) where ... }}} Granted, this could be improved if `th-lift` were changed to allow something like this: {{{#!hs instance (Show a, Lift a) => Lift (Restricted a) where lift = $(makeLift ''Restricted) }}} But a `deriving` statement is infinitely more aesthetically pleasing, in my opinion. > But that argument falls flat here, because users are clearly already using TH! Well, they're using the `template-haskell` library, but not necessarily the `TemplateHaskell` extension. Users may want to define `Lift` instances for data types without actually using the `TemplateHaskell` extension (as doing so precludes a library from being built on a stage-1 compiler). Having access to `DeriveLift` allows a library to be built with `Lift` support on GHC stage 1 and 2, and then downstream packages that depend on the library can decide if they want to actually utilize the `Lift` instances by means of the `TemplateHaskell` extension. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/1830#comment:11> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler
1 0
0 0
Re: [GHC] #1830: Automatic derivation of Lift
by GHC 24 Aug '15

24 Aug '15
#1830: Automatic derivation of Lift -------------------------------------+------------------------------------- Reporter: guest | Owner: | RyanGlScott Type: feature request | Status: new Priority: normal | Milestone: ⊥ Component: Template Haskell | Version: 6.8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: Phab:D1168 -------------------------------------+------------------------------------- Comment (by goldfire): Thanks for taking this on, Ryan, but I'm unconvinced that GHC needs built- in support here. What's wrong with using `th-lift`? I mean, I agree that in theory, `DeriveLift` would be nice, but it's Yet Another Thing. If something can be done well outside of GHC, I think it should be. A common argument here is that if a feature is built-in (as opposed to requiring TH), then users don't have to use TH. But that argument falls flat here, because users are clearly already using TH! -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/1830#comment:10> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler
1 0
0 0
Re: [GHC] #4243: Make a proper options parser for the RTS
by GHC 24 Aug '15

24 Aug '15
#4243: Make a proper options parser for the RTS -------------------------------------+------------------------------------- Reporter: igloo | Owner: Type: task | Status: new Priority: normal | Milestone: 7.12.1 Component: Runtime System | Version: 6.13 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: 7535 Related Tickets: #9839 | Differential Revisions: -------------------------------------+------------------------------------- Comment (by bgamari): osa1, I think for the sake of simplicity it would be best to avoid going down that road. The RTS really just needs to work, even if Haskell-land is broken (e.g. as is often the case when debugging RTS bugs or bringing up new platforms). -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/4243#comment:17> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler
1 0
0 0
Re: [GHC] #1830: Automatic derivation of Lift
by GHC 24 Aug '15

24 Aug '15
#1830: Automatic derivation of Lift -------------------------------------+------------------------------------- Reporter: guest | Owner: | RyanGlScott Type: feature request | Status: new Priority: normal | Milestone: ⊥ Component: Template Haskell | Version: 6.8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: Phab:D1168 -------------------------------------+------------------------------------- Comment (by rwbarton): > What should we do if someone attempts to derive `Lift` on a datatype with no constructors? Since `lift` then has type `Void -> Q Exp`, I would be inclined to define it as `absurd`, i.e., an empty case. I don't see the point of turning it into a runtime error when `lift (error "foo")` is a splice-time error for an inhabited type. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/1830#comment:9> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler
1 0
0 0
Re: [GHC] #1830: Automatic derivation of Lift
by GHC 24 Aug '15

24 Aug '15
#1830: Automatic derivation of Lift -------------------------------------+------------------------------------- Reporter: guest | Owner: | RyanGlScott Type: feature request | Status: new Priority: normal | Milestone: ⊥ Component: Template Haskell | Version: 6.8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: Phab:D1168 -------------------------------------+------------------------------------- Changes (by RyanGlScott): * owner: => RyanGlScott * differential: => Phab:D1168 Comment: I have a differential ( Phab:D1168 ) submitted which implements this feature, but I would like some feedback. I'll copy over my questions from the Phabricator page: 1. What should we do if someone attempts to derive `Lift` on a datatype with no constructors? I (somewhat arbitrarily) chose it to generate code like this: {{{#!hs data Void deriving Lift instance Lift Void where lift _ = appE (varE 'error) (litE (stringL "Void lift")) }}} but {{{lift _ = error "Void lift"}}} would also work. 2. How should primitive data types be handled? I adapted the approach `Show` takes, which has special cases for `Char#`, `Float#`, `Double#`, `Int#`, and `Word#`. Note that `template-haskell` also has a `StringPrimL` constructor, so we could handle `Addr#` as well, but there's not currently a function of type `String -> [Word8]` in `base` that I could use in conjunction with it ([http://haddock.stackage.org/lts-3.2/ghc-7.10.2/SMRep.html#v:stringToWord8s there is in] `ghc`, but I'm not sure if it's verboten to put GHC internals in derived code). -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/1830#comment:8> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler
1 0
0 0
Re: [GHC] #7830: Error: operand out of range
by GHC 22 Aug '15

22 Aug '15
#7830: Error: operand out of range -------------------------------------+------------------------------------- Reporter: erikd | Owner: Type: bug | Status: new Priority: highest | Milestone: 7.8.1 Component: Compiler | Version: 7.8.1-rc1 Resolution: | Keywords: Operating System: Linux | Architecture: powerpc Type of failure: Installing GHC | Test Case: failed | Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by erikd): That's interesting. Git HEAD started displaying this build failure in my Jenkin instance about a week ago but I haven't had a chance to look at it yet. Weird thing is that the Git 7.10 branch build in my Jenkin instance is not failing. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7830#comment:20> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler
1 0
0 0
[GHC] #10786: ghci panic if {-# OPTIONS_GHC -O2 #-}
by GHC 22 Aug '15

22 Aug '15
#10786: ghci panic if {-# OPTIONS_GHC -O2 #-} -----------------------------------------+------------------------------- Reporter: rhovland | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.10.2 Keywords: | Operating System: Linux Architecture: x86_64 (amd64) | Type of failure: GHCi crash Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -----------------------------------------+------------------------------- any file with the pragma OPTIONS_GHC -O2 causes ghci to panic, say something 'impossible' happened, and says to file a bug report. previous ghci ignored this pragma (I think). at any rate, it didn't panic. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10786> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler
1 1
0 0
Re: [GHC] #7830: Error: operand out of range
by GHC 22 Aug '15

22 Aug '15
#7830: Error: operand out of range -------------------------------------+------------------------------------- Reporter: erikd | Owner: Type: bug | Status: new Priority: highest | Milestone: 7.8.1 Component: Compiler | Version: 7.8.1-rc1 Resolution: | Keywords: Operating System: Linux | Architecture: powerpc Type of failure: Installing GHC | Test Case: failed | Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by nomeata): * status: closed => new * resolution: fixed => Comment: It seems that has resurfaced in 7.10, when compiling uuagc on powerpc: {{{ /tmp/ghcf6f1_0/ghc_153.s: Assembler messages: /tmp/ghcf6f1_0/ghc_153.s:81276:0: Error: operand out of range (0x0000000000008000 is not between 0xffffffffffff8000 and 0x0000000000007fff) /tmp/ghcf6f1_0/ghc_153.s:81278:0: Error: operand out of range (0x0000000000008008 is not between 0xffffffffffff8000 and 0x0000000000007fff) }}} Erik, would you mind having a look? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7830#comment:19> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler
1 0
0 0
[GHC] #10637: Cannot suppress "Warning: {-# SOURCE #-} unnecessary in import of ‘A’"
by GHC 21 Aug '15

21 Aug '15
#10637: Cannot suppress "Warning: {-# SOURCE #-} unnecessary in import of ‘A’" -----------------------------------------+--------------------------------- Reporter: phischu | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Keywords: | Operating System: Linux Architecture: x86_64 (amd64) | Type of failure: None/Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -----------------------------------------+--------------------------------- Consider the following three files: {{{#!hs -- A.hs module A where }}} {{{#!hs -- A.hs-boot module A where }}} {{{#!hs -- B.hs module B where import {-# SOURCE #-} A }}} When compiling these three files GHC emits a warning and rightly so: {{{ >ghc B.hs B.hs:3:23: Warning: {-# SOURCE #-} unnecessary in import of ‘A’ [1 of 3] Compiling A[boot] ( A.hs-boot, A.o-boot ) [2 of 3] Compiling A ( A.hs, A.o ) [3 of 3] Compiling B ( B.hs, B.o ) }}} When on the other hand compiling with `-w` I expect the warning to go away but it doesn't. {{{ >ghc -w B.hs B.hs:3:23: Warning: {-# SOURCE #-} unnecessary in import of ‘A’ [1 of 3] Compiling A[boot] ( A.hs-boot, A.o-boot ) [2 of 3] Compiling A ( A.hs, A.o ) [3 of 3] Compiling B ( B.hs, B.o ) }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10637> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler
1 6
0 0
  • ← Newer
  • 1
  • ...
  • 88
  • 89
  • 90
  • 91
  • 92
  • 93
  • 94
  • ...
  • 107
  • Older →

HyperKitty Powered by HyperKitty version 1.3.9.