October 2014 - ghc-tickets

[GHC] #8683: add "cpp program" and "cpp program options" to settings file
by GHC 14 Oct '14

14 Oct '14

#8683: add "cpp program" and "cpp program options" to settings file ------------------------------------+------------------------------------- Reporter: carter | Owner: Type: feature request | Status: new Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.7 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- so theres a pretty clear consensus that we need to move away from using our c compiler for CPP, so should we add that info to the settings file? I propose adding the following fields to the settings file: "use c compiler cpp", which can have either "YES" or "NO". If "YES", the settings file indicated C compiler is used unless the c compiler selection is overrided by ghc at runtime via -pgmc or -pgmp(p?) if "NO", then the "cpp program" and "cpp program options" fields would be used, unless overridden by -pgmp there'd be some associated patched in the compiler/main/DriverPipeline.hs too i think, but relatively minimal. this would make it much easier to distributed a GHC with its own CPP tool that works -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8683> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 69

Re: [GHC] #1473: isSpace is too slow
by GHC 13 Oct '14

13 Oct '14

#1473: isSpace is too slow -------------------------------------+------------------------------------- Reporter: igloo | Owner: ekmett Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Core | Version: 6.6.1 Libraries | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by dfeuer): * cc: core-libraries-committee@… (added) * milestone: ⊥ => 7.10.1 Comment: There are some very simple things to do about this, pending a full fix. In particular, as Carter noted, just making sure low codepoints never call out to C should help a lot. Using an unsigned comparison to check the contiguous range should be good too. I think we can probably improve things some more once we've figured out what to do about #9661. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/1473#comment:9> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] Batch modify: #9125, #5987, #7298, #7411, #7478, #7521, #7567, #7602, #7651, #7919, #8228, #8276, #8701, #8736, #8935, #8974, #9007, #9186, #9314, #9345, #9575, #5757, #7028, #7143, #7305, #7475, #7655, #7665, #7695, #8362, #8951, #8975, #8976, #8981, #9034, #9046, #9100, #9237, #9238, #9316, #9371, #9372, #9390, #9415, #9523, #9537, #9620, #8303
by GHC 13 Oct '14

13 Oct '14

Batch modification to #9125, #5987, #7298, #7411, #7478, #7521, #7567, #7602, #7651, #7919, #8228, #8276, #8701, #8736, #8935, #8974, #9007, #9186, #9314, #9345, #9575, #5757, #7028, #7143, #7305, #7475, #7655, #7665, #7695, #8362, #8951, #8975, #8976, #8981, #9034, #9046, #9100, #9237, #9238, #9316, #9371, #9372, #9390, #9415, #9523, #9537, #9620, #8303 by thoughtpolice: milestone to 7.10.1 Comment: Moving (in bulk) to 7.10.4 -- Tickets URL: <http://ghc.haskell.org/trac/ghc/query?id=9125%2C5987%2C7298%2C7411%2C7478%2…> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #8025: "During interactive linking, GHCi couldn't find the following symbol" typechecker error with TemplateHaskell involved
by GHC 13 Oct '14

13 Oct '14

#8025: "During interactive linking, GHCi couldn't find the following symbol" typechecker error with TemplateHaskell involved -------------------------------------+------------------------------------- Reporter: mojojojo | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 (Type checker) | Keywords: Resolution: | Architecture: x86 Operating System: MacOS X | Difficulty: Unknown Type of failure: Incorrect | Blocked By: warning at compile-time | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by GregWeber): This issue is being seen while running: cabal install yesod-core https://github.com/yesodweb/yesod/issues/721 I am using ghc 7.8.3 on Ubuntu linux from this Dockerfile: zsol/haskell- platform-2014.2.0.0 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8025#comment:2> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #5793: make nofib awesome
by GHC 12 Oct '14

12 Oct '14

#5793: make nofib awesome -------------------------------------+------------------------------------- Reporter: dterei | Owner: dterei Type: task | Status: new Priority: normal | Milestone: ⊥ Component: NoFib | Version: benchmark suite | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: 9571 Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by NeilMitchell): Reflecting on why this ticket didn't go anywhere, perhaps the scope is too broad. Rather than "make nofib awesome" maybe we need a few separate tickets - the one to switch nofib to Shake just requires integrating the code that is already written. The other issues such as criterion/stabilizer and changing the set of benchmarks might do best being tackled as individual pieces. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5793#comment:32> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #9680: Autogenerated lib/include/HsTimeConfig.h is checked in
by GHC 12 Oct '14

12 Oct '14

#9680: Autogenerated lib/include/HsTimeConfig.h is checked in -------------------------------------+------------------------------------- Reporter: gintas | Owner: Type: bug | Status: new Priority: low | Milestone: Component: Build System | Version: 7.9 Keywords: | Operating System: Windows Architecture: Unknown/Multiple | Type of failure: Difficulty: Easy (less than 1 | None/Unknown hour) | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- lib/include/HsTimeConfig.h appears to be generated by the build process, but it's checked into the depot. After I run make it shows up as modified under git status, preventing "arc diff" etc. I am building on Windows, but I don't think this is OS-specific. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9680> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #9604: Python test runner assumes native Python on Windows
by GHC 11 Oct '14

11 Oct '14

#9604: Python test runner assumes native Python on Windows -------------------------------------+------------------------------------- Reporter: gintas | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 7.8.2 Keywords: | Operating System: Windows Architecture: Unknown/Multiple | Type of failure: Building Difficulty: Unknown | GHC failed Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- runtests.py assumes that ctypes.windll is always available when running on Windows, but that is in fact only available when using a native Windows Python, but not the mingw/msys Python. The code causes a crash over a trivial issue of setting the terminal to UTF-8 mode. See attached patch for a fix. (The second patch is a cleanup.) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9604> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

Re: [GHC] #5793: make nofib awesome
by GHC 11 Oct '14

11 Oct '14

#5793: make nofib awesome -------------------------------------+------------------------------------- Reporter: dterei | Owner: dterei Type: task | Status: new Priority: normal | Milestone: ⊥ Component: NoFib | Version: benchmark suite | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: 9571 Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by hvr): Somewhat related, there's a new serious attempt at [wiki:Building/Shake Shaking up GHC] -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5793#comment:31> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #6018: Injective type families
by GHC 11 Oct '14

11 Oct '14

#6018: Injective type families -------------------------------------+------------------------------------- Reporter: lunaris | Owner: jstolarek Type: feature | Status: new request | Milestone: 7.10.1 Priority: normal | Version: 7.4.1 Component: Compiler | Keywords: TypeFamilies, Resolution: | Injective Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: #4259 Test Case: | Blocking: | Differential Revisions: Phab:D202 | -------------------------------------+------------------------------------- Comment (by jstolarek): Replying to [comment:79 goldfire]: > I'm ambivalent on this design decision (that the variables have to be in the same order in the annotation). I suppose it simplifies the implementation. I guess my argument about simpler implementation is not that important. I mean the code is quite simple in both cases. It's more like a choice between linear and quadratic algorithm. I'd went for linear, even if it adds an extra restriction on the user code. > Yes, Simon's comment above is correct -- I was just wrong about the `isDecomposableTyCon` thing. OK. Reverting :-) > What works perfectly fine? Not the code you wrote above, because it contains a not-currently-parsed injectivity annotation. I tried it without the injectivity annotation, and it does indeed work. Yes, that's what I meant. > But not because of injectivity, at all: it's because GHC is clever enough to figure out that `F` is just an identity function Right. Still, I wondering how this works. I mean there are probably no special cases in the typechecker that try to guess whether a type family is an identity function? > Fair warning: 1000 lines of `-ddump-tc-trace` isn't long at all! :) I imagine, given that my source file was 8 lines of code. Still, it's a bit steep learning curve. Replying to [comment:80 goldfire]: > Under the singletons work, we gave a different kind to non-injective functions Ah, right. Replying to [wiki:InjectiveTypeFamilies wiki comments]: > I believe this would also have to check that all variables mentioned in the LHS are mentioned in the RHS. Or, following along with Simon's idea in comment:76:ticket:6018, those variables that appear in the injectivity annotation must be mentioned in the RHS. I haven't thought about that. I believe you're right. > We have to be careful with the word overlap here. I think we want "overlaps" to be "is subsumed by". I don't see the difference between "overlaps" and "is subsumed by". :-( Now, in 4c I wrote: > if unification [of the RHSs] succeeds and there are type variables involved we substitute unified type variables on the LHS and check whether this LHS overlaps with any of the previous equations. If it does we proceed to the next equation You replied with this: > you want to know of the equation at hand is reachable, given the LHS substitution. Even if it is reachable, the (substituted) LHS may coincide with the LHS of the earlier equation whose RHS unified with the current RHS. I don't see the difference between your version and mine. > Even subtler, it's possible that certain values for type variables are excluded if the current LHS is reachable (for example, some variable a couldn't be Int, because if a were Int, then a previous equation would have triggered). Perhaps these exclusions can also be taken into account. Hm... can you give an example where this would be useful? > '''RAE:''' But it seems that, under this treatment, any self-recursion would automatically lead to a conclusion of "not injective", just like any other use of a type family. For example: > > {{{#!hs > type family IdNat n where > IdNat Z = Z > IdNat (S n) = S (IdNat n) > }}} > > `IdNat` is injective. But, following the algorithm above, GHC would see the recursive use of `IdNat`, not know whether `IdNat` is injective, and then give up, concluding "not injective". Is there a case where the special treatment of self-recursion leads to a conclusion of "injective"? '''End RAE''' This example is just like my `NatToMaybe`. My idea here was that RHSs of these two equations won't unify - first returns `Z`, second returns `S something`. These are distinct constructors that have no chance of being unified. (I assumed that we are able to detect that.) There are no calls to type families other than self-recursion and so we can declare `IdNat` to be injective. I admit I am not 100% certain that allowing self- recursion is safe. It's just that I was unable to come up with an example that would show that my algorithm: a:) declares injective function to be non-injective; b) declares a non-injective function to be injective. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/6018#comment:82> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #5793: make nofib awesome
by GHC 11 Oct '14

11 Oct '14

#5793: make nofib awesome -------------------------------------+------------------------------------- Reporter: dterei | Owner: dterei Type: task | Status: new Priority: normal | Milestone: ⊥ Component: NoFib | Version: benchmark suite | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: 9571 Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by rwbarton): We should consider incorporating something along the lines of [https://github.com/ccurtsinger/stabilizer Stabilizer] in order to reduce the magnitude of the effects seen in #8279. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5793#comment:30> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0