How to get notifications when a build fails?
Hi devs, Is there any way to make Phab email you when a revision you've submitted fails to build? I looked through the settings but couldn't find anything that seems to fit the bill. Thanks! Eric ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Deprecating functions
I agree with Johan. I do think it makes sense to remove deprecated/replaced functions, but only after N+2 cycles. On 06:18, Fri, Jan 9, 2015 Richard Eisenberg e...@cis.upenn.edu wrote: On Jan 9, 2015, at 5:37 AM, Jan Stolarek jan.stola...@p.lodz.pl wrote: Especially that we're talking about internal TH module - I'll be surprised if there are more than 10 users. As I understand it, TH.Lib is not an internal module. Though I, personally, have never found the functions there to suit my needs as a user, I think the functions exported from there are the go-to place for lots of people using TH. For example, Ollie Charles's recent blog post on TH (https://ocharles.org.uk/blog/guest-posts/2014-12-22- template-haskell.html), written by Sean Westfall, uses functions exported from TH.Lib. I'm rather ambivalent on the deprecate vs. remove vs. hide vs. leave alone debate, but I do think we should treat TH.Lib as a fully public module as we're debating. Richard ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Shipping core libraries with debug symbols
I've been building the RTS with debug symbols for our internal GHC build at FB, because it makes investigating problems a lot easier. I should probably upstream this patch. Shipping libraries with debug symbols should be fine, as long as they can be stripped - Peter, does stripping remove everything that -g creates? Cheers, Simon On 02/01/2015 23:18, Johan Tibell wrote: Hi! We are now able to generate DWARF debug info, by passing -g to GHC. This will allow for better debugging (e.g. using GDB) and profiling (e.g. using Linux perf events). To make this feature more user accessible we need to ship debug info for the core libraries (and perhaps the RTS). The reason we need to ship debug info is that it's difficult, or impossible in the case of base, for the user to rebuild these libraries.The question is, how do we do this well? I don't think our way solution works very well. It causes us to recompile too much and GHC doesn't know which ways have been built or not. I believe other compilers, e.g. GCC, ship debug symbols in separate files (https://packages.debian.org/sid/libc-dbg) that e.g. GDB can then look up. -- Johan ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
RE: warn-redundant-constraints present as errors
Alan’s point is a bug – I will fix. Konstantine’s point is reasonable. we could easily say Language/Haskell/Refact/Utils/TypeUtils.hs:3045:7: Error: blah blah (the bit in red is the new bit) But I’m not sure that everyone else would want that. If a consensus forms it would be easy to excecute I suppose there could be yet another flag to control it (!) Simon From: Konstantine Rybnikov [mailto:k...@k-bx.com] Sent: 09 January 2015 09:19 To: Alan Kim Zimmerman Cc: ghc-devs@haskell.org; Simon Peyton Jones Subject: Re: warn-redundant-constraints present as errors On a slightly unrelated note I should say it would be great to have errors contain word Error:. This is especially nice to have because when you build with -j your error that stops compilation gets lost somewhere in the middle of many warnings (which my projects have, unfortunately). On Thu, Jan 8, 2015 at 11:45 PM, Alan Kim Zimmerman alan.z...@gmail.commailto:alan.z...@gmail.com wrote: This is a great feature, here is some feedback My syntax highlighter in emacs expects warnings to have the word warning in them. So for the two warnings reported below, the first is highlighted as an error, and the second as a warning Language/Haskell/Refact/Utils/TypeUtils.hs:3036:17: Redundant constraint: SYB.Data t In the type signature for: duplicateDecl :: SYB.Data t = [GHC.LHsBind GHC.Name] - t - GHC.Name - GHC.Name - RefactGhc [GHC.LHsBind GHC.Name] Language/Haskell/Refact/Utils/TypeUtils.hs:3045:7: Warning: Defined but not used: ‘toks This is in a ghci session, and the file loads without problems, so it is indeed a warning. Can we perhaps add the word Warning to the output for Redundant constraints? I also had a situation where it asked me to remove a whole lot of constraints from different functions, I did them in batches, so did not remove them all from the file at once, and at some point I had to add at least one of them back, albeit based on an error message. Regards Alan ___ ghc-devs mailing list ghc-devs@haskell.orgmailto:ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Deprecating functions
We could file a tracking bug against the 7.14 milestone. Just curious, is there a way to keep these functions for backwards compat in 7.14 or is that unfeasible? On Fri, Jan 9, 2015 at 10:22 AM, Jan Stolarek jan.stola...@p.lodz.pl wrote: I want to deprecate some Template Haskell functions in GHC 7.12 and then remove them in GHC 7.14 (or whatever version that comes after 7.12). Do we have any workflow for remembering these kind of things? I was thinking about adding a conditional error: #if __GLASGOW_HASKELL__ 712 #error Remove functions foo bar from TH #endif Is this a good way of doing this? Or should I do it differently? Janek ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Deprecating functions
I agree. You'll get rid of the redundancy in the library by removing it but you're users will have to live with (...) That's why I want to deprecate them first and give users one release cycle to switch to new functions. I assumed that's enough but we could make this two or three release cycles. The reall question is how to remember that we should remove this at some point? Janek ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: warn-redundant-constraints present as errors
I think using the words error and warning makes sense. For example, this is
how Clang (LLVM) does it:
format-strings.c:91:13: warning: '.*' specified field precision is missing
a matching 'int' argument
printf(%.*d);
^
t.c:7:39: error: invalid operands to binary expression ('int' and 'struct
A')
return y + func(y ? ((SomeA.X + 40) + SomeA) / 42 + SomeA.X : SomeA.X);
~~ ^ ~
(Also note how lovely it is to have a caret pointing at the error.)
On Fri, Jan 9, 2015 at 10:39 AM, Simon Peyton Jones simo...@microsoft.com
wrote:
Alan’s point is a bug – I will fix.
Konstantine’s point is reasonable. we could easily say
Language/Haskell/Refact/Utils/TypeUtils.hs:3045:7: Error:
blah blah
(the bit in red is the new bit)
But I’m not sure that everyone else would want that. If a consensus
forms it would be easy to excecute
I suppose there could be yet another flag to control it (!)
Simon
*From:* Konstantine Rybnikov [mailto:k...@k-bx.com]
*Sent:* 09 January 2015 09:19
*To:* Alan Kim Zimmerman
*Cc:* ghc-devs@haskell.org; Simon Peyton Jones
*Subject:* Re: warn-redundant-constraints present as errors
On a slightly unrelated note I should say it would be great to have errors
contain word Error:. This is especially nice to have because when you
build with -j your error that stops compilation gets lost somewhere in
the middle of many warnings (which my projects have, unfortunately).
On Thu, Jan 8, 2015 at 11:45 PM, Alan Kim Zimmerman alan.z...@gmail.com
wrote:
This is a great feature, here is some feedback
My syntax highlighter in emacs expects warnings to have the word warning
in them.
So for the two warnings reported below, the first is highlighted as an
error, and the second as a warning
Language/Haskell/Refact/Utils/TypeUtils.hs:3036:17:
Redundant constraint: SYB.Data t
In the type signature for:
duplicateDecl :: SYB.Data t =
[GHC.LHsBind GHC.Name]
- t - GHC.Name - GHC.Name - RefactGhc
[GHC.LHsBind GHC.Name]
Language/Haskell/Refact/Utils/TypeUtils.hs:3045:7: Warning:
Defined but not used: ‘toks
This is in a ghci session, and the file loads without problems, so it
is indeed a warning.
Can we perhaps add the word Warning to the output for Redundant
constraints?
I also had a situation where it asked me to remove a whole lot of
constraints from different functions, I did them in batches, so did not
remove them all from the file at once, and at some point I had to add at
least one of them back, albeit based on an error message.
Regards
Alan
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Deprecating functions
On 2015-01-09 at 11:09:07 +0100, Roman Cheplyaka wrote: [...] Just curious, is there a way to keep these functions for backwards compat in 7.14 or is that unfeasible? They could stay, technically that's not a problem. But I'm adding new functions that can do the same thing (and more), so we have redundancy. Can you hide them in the haddock but leave in the module, so that we don't break existing code? Why hide them? DEPRECATEd entities have the deprecation-message shown in discouraging red letters (including any hyperlinks to their replacements) in the generated Haddock documentation... ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Deprecating functions
On Fri, Jan 9, 2015 at 11:09 AM, Roman Cheplyaka r...@ro-che.info wrote: On 09/01/15 12:02, Jan Stolarek wrote: We could file a tracking bug against the 7.14 milestone. I was considering that but we don't have 7.14 milestone yet. Just curious, is there a way to keep these functions for backwards compat in 7.14 or is that unfeasible? They could stay, technically that's not a problem. But I'm adding new functions that can do the same thing (and more), so we have redundancy. Can you hide them in the haddock but leave in the module, so that we don't break existing code? I agree. You'll get rid of the redundancy in the library by removing it but you're users will have to live with #if MIN_VERSION_template_haskell(X,Y,X) -- new way #else -- old way #endif for 3+ years (which is typically how many GHC versions popular libraries try to support). ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Deprecating functions
On Fri, Jan 9, 2015 at 11:13 AM, Herbert Valerio Riedel hvrie...@gmail.com wrote: Why hide them? DEPRECATEd entities have the deprecation-message shown in discouraging red letters (including any hyperlinks to their replacements) in the generated Haddock documentation... I think Java's (!) policy for deprecation is good: Deprecation is (mostly) for functions that are error prone or otherwise dangerous. Unless the cost of keeping the function is large, removing functions should be avoided. The docs can point to the newer functions, but DEPRECATION pragmas will just add noise to users' compiles. ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Deprecating functions
On 2015-01-09 at 11:18:02 +0100, Jan Stolarek wrote: The reall question is how to remember that we should remove this at some point? This affects all exposed libraries; I think it's enough to simply make this part of the release-procedure at some point in the release-cycle, to actively scan all DEPRECATIONs, and decide for each whether to kill them or let them live for another cycle. It simplifies things though, if it's obvious when a deprecation was declared so one doesn't have to `git blame` for it. Many deprecations already have a comment attached like deprecated in GHC x.y ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Deprecating functions
I want to deprecate some Template Haskell functions in GHC 7.12 and then remove them in GHC 7.14 (or whatever version that comes after 7.12). Do we have any workflow for remembering these kind of things? I was thinking about adding a conditional error: #if __GLASGOW_HASKELL__ 712 #error Remove functions foo bar from TH #endif Is this a good way of doing this? Or should I do it differently? Janek ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Deprecating functions
We could file a tracking bug against the 7.14 milestone. I was considering that but we don't have 7.14 milestone yet. Just curious, is there a way to keep these functions for backwards compat in 7.14 or is that unfeasible? They could stay, technically that's not a problem. But I'm adding new functions that can do the same thing (and more), so we have redundancy. Janek On Fri, Jan 9, 2015 at 10:22 AM, Jan Stolarek jan.stola...@p.lodz.pl wrote: I want to deprecate some Template Haskell functions in GHC 7.12 and then remove them in GHC 7.14 (or whatever version that comes after 7.12). Do we have any workflow for remembering these kind of things? I was thinking about adding a conditional error: #if __GLASGOW_HASKELL__ 712 #error Remove functions foo bar from TH #endif Is this a good way of doing this? Or should I do it differently? Janek ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Deprecating functions
On 2015-01-09 11:25, Herbert Valerio Riedel wrote: On 2015-01-09 at 11:18:02 +0100, Jan Stolarek wrote: The reall question is how to remember that we should remove this at some point? This affects all exposed libraries; I think it's enough to simply make this part of the release-procedure at some point in the release-cycle, to actively scan all DEPRECATIONs, and decide for each whether to kill them or let them live for another cycle. It simplifies things though, if it's obvious when a deprecation was declared so one doesn't have to `git blame` for it. Many deprecations already have a comment attached like deprecated in GHC x.y I think Google's Guava library for Java does a great job at this. In the documentation is says something like: *Deprecated*: Use xxx instead. This class is scheduled for removal in June 2016. Then one just needs to add a Remove all scheduled deprecations to the do-a-release checklist. ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Shipping core libraries with debug symbols
Could we get this for 7.10 so our debug info story is more well-rounded? On Fri, Jan 9, 2015 at 5:11 PM, Simon Marlow marlo...@gmail.com wrote: I've been building the RTS with debug symbols for our internal GHC build at FB, because it makes investigating problems a lot easier. I should probably upstream this patch. Shipping libraries with debug symbols should be fine, as long as they can be stripped - Peter, does stripping remove everything that -g creates? Cheers, Simon On 02/01/2015 23:18, Johan Tibell wrote: Hi! We are now able to generate DWARF debug info, by passing -g to GHC. This will allow for better debugging (e.g. using GDB) and profiling (e.g. using Linux perf events). To make this feature more user accessible we need to ship debug info for the core libraries (and perhaps the RTS). The reason we need to ship debug info is that it's difficult, or impossible in the case of base, for the user to rebuild these libraries.The question is, how do we do this well? I don't think our way solution works very well. It causes us to recompile too much and GHC doesn't know which ways have been built or not. I believe other compilers, e.g. GCC, ship debug symbols in separate files (https://packages.debian.org/sid/libc-dbg) that e.g. GDB can then look up. -- Johan ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Shipping core libraries with debug symbols
Yes - strip will catch everything. Greetings, Peter On 09/01/2015 17:11, Simon Marlow wrote: I've been building the RTS with debug symbols for our internal GHC build at FB, because it makes investigating problems a lot easier. I should probably upstream this patch. Shipping libraries with debug symbols should be fine, as long as they can be stripped - Peter, does stripping remove everything that -g creates? Cheers, Simon On 02/01/2015 23:18, Johan Tibell wrote: Hi! We are now able to generate DWARF debug info, by passing -g to GHC. This will allow for better debugging (e.g. using GDB) and profiling (e.g. using Linux perf events). To make this feature more user accessible we need to ship debug info for the core libraries (and perhaps the RTS). The reason we need to ship debug info is that it's difficult, or impossible in the case of base, for the user to rebuild these libraries.The question is, how do we do this well? I don't think our way solution works very well. It causes us to recompile too much and GHC doesn't know which ways have been built or not. I believe other compilers, e.g. GCC, ship debug symbols in separate files (https://packages.debian.org/sid/libc-dbg) that e.g. GDB can then look up. -- Johan ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
pef T3294
perf/compiler T3294 [stat not good enough] (normal) This test is failing on Phab all the time now. but it doesn't fail on my machine, so I can't see what's wrong. Could someone look? Simion ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Milestones
I took the liberty of pushing back the milestones for a few tickets that looked unlikely to be acted on for 7.10.1, based on a combination of severity, recent activity, and perceived intrusiveness. If anyone objects, please move them back. #9314: Each object file in a static archive file (.a) is loaded into its own mmap()ed page #8440: Get rid of the remaining static flags #8634: Relax functional dependency coherence check (liberal coverage condition) David ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: warn-redundant-constraints present as errors
On a slightly unrelated note I should say it would be great to have errors contain word Error:. This is especially nice to have because when you build with -j your error that stops compilation gets lost somewhere in the middle of many warnings (which my projects have, unfortunately). On Thu, Jan 8, 2015 at 11:45 PM, Alan Kim Zimmerman alan.z...@gmail.com wrote: This is a great feature, here is some feedback My syntax highlighter in emacs expects warnings to have the word warning in them. So for the two warnings reported below, the first is highlighted as an error, and the second as a warning Language/Haskell/Refact/Utils/TypeUtils.hs:3036:17: Redundant constraint: SYB.Data t In the type signature for: duplicateDecl :: SYB.Data t = [GHC.LHsBind GHC.Name] - t - GHC.Name - GHC.Name - RefactGhc [GHC.LHsBind GHC.Name] Language/Haskell/Refact/Utils/TypeUtils.hs:3045:7: Warning: Defined but not used: ‘toks This is in a ghci session, and the file loads without problems, so it is indeed a warning. Can we perhaps add the word Warning to the output for Redundant constraints? I also had a situation where it asked me to remove a whole lot of constraints from different functions, I did them in batches, so did not remove them all from the file at once, and at some point I had to add at least one of them back, albeit based on an error message. Regards Alan ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Deprecating functions
On 09/01/15 12:02, Jan Stolarek wrote: We could file a tracking bug against the 7.14 milestone. I was considering that but we don't have 7.14 milestone yet. Just curious, is there a way to keep these functions for backwards compat in 7.14 or is that unfeasible? They could stay, technically that's not a problem. But I'm adding new functions that can do the same thing (and more), so we have redundancy. Can you hide them in the haddock but leave in the module, so that we don't break existing code? Roman ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
RE: warn-redundant-constraints present as errors
I’ve fixed this From: Alan Kim Zimmerman [mailto:alan.z...@gmail.com] Sent: 08 January 2015 21:46 To: ghc-devs@haskell.org; Simon Peyton Jones Subject: warn-redundant-constraints present as errors This is a great feature, here is some feedback My syntax highlighter in emacs expects warnings to have the word warning in them. So for the two warnings reported below, the first is highlighted as an error, and the second as a warning Language/Haskell/Refact/Utils/TypeUtils.hs:3036:17: Redundant constraint: SYB.Data t In the type signature for: duplicateDecl :: SYB.Data t = [GHC.LHsBind GHC.Name] - t - GHC.Name - GHC.Name - RefactGhc [GHC.LHsBind GHC.Name] Language/Haskell/Refact/Utils/TypeUtils.hs:3045:7: Warning: Defined but not used: ‘toks This is in a ghci session, and the file loads without problems, so it is indeed a warning. Can we perhaps add the word Warning to the output for Redundant constraints? I also had a situation where it asked me to remove a whole lot of constraints from different functions, I did them in batches, so did not remove them all from the file at once, and at some point I had to add at least one of them back, albeit based on an error message. Regards Alan ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
RE: warn-redundant-constraints present as errors
If you remove the constraint from duplicateDecl, then I get Redundant constraint: SYB.Data t In the type signature for: definingSigsNames :: SYB.Data t = [GHC.Name] - t - [GHC.LSig GHC.Name] which is 100% correct: defininingSigssNames doesn’t use its SYB.Data t constraint Simon From: Alan Kim Zimmerman [mailto:alan.z...@gmail.com] Sent: 09 January 2015 11:22 To: Simon Peyton Jones Cc: ghc-devs@haskell.org Subject: Re: warn-redundant-constraints present as errors Thanks. I've found a case where it warns of a redundant constraint, but if I remove the constraint I get an error saying the constraint is required import qualified GHC as GHC import qualified Data.Generics as SYB duplicateDecl :: (SYB.Data t) = -- The constraint being warned against *** [GHC.LHsBind GHC.Name] -- ^ The declaration list -t -- ^ Any signatures are in here -GHC.Name -- ^ The identifier whose definition is to be duplicated -GHC.Name -- ^ The new name (possibly qualified) -IO [GHC.LHsBind GHC.Name] -- ^ The result duplicateDecl decls sigs n newFunName = do let sspan = undefined newSpan - case typeSig of [] - return sspan _ - do let Just sspanSig = getSrcSpan typeSig toksSig - getToksForSpan sspanSig let [(GHC.L sspanSig' _)] = typeSig return sspanSig' undefined where typeSig = definingSigsNames [n] sigs -- |Find those type signatures for the specified GHC.Names. definingSigsNames :: (SYB.Data t) = [GHC.Name] -- ^ The specified identifiers. -t-- ^ A collection of declarations. -[GHC.LSig GHC.Name] -- ^ The result. definingSigsNames pns ds = def ds where def = undefined getSrcSpan = undefined getToksForSpan = undefined On Fri, Jan 9, 2015 at 1:08 PM, Simon Peyton Jones simo...@microsoft.commailto:simo...@microsoft.com wrote: I’ve fixed this From: Alan Kim Zimmerman [mailto:alan.z...@gmail.commailto:alan.z...@gmail.com] Sent: 08 January 2015 21:46 To: ghc-devs@haskell.orgmailto:ghc-devs@haskell.org; Simon Peyton Jones Subject: warn-redundant-constraints present as errors This is a great feature, here is some feedback My syntax highlighter in emacs expects warnings to have the word warning in them. So for the two warnings reported below, the first is highlighted as an error, and the second as a warning Language/Haskell/Refact/Utils/TypeUtils.hs:3036:17: Redundant constraint: SYB.Data t In the type signature for: duplicateDecl :: SYB.Data t = [GHC.LHsBind GHC.Name] - t - GHC.Name - GHC.Name - RefactGhc [GHC.LHsBind GHC.Name] Language/Haskell/Refact/Utils/TypeUtils.hs:3045:7: Warning: Defined but not used: ‘toks This is in a ghci session, and the file loads without problems, so it is indeed a warning. Can we perhaps add the word Warning to the output for Redundant constraints? I also had a situation where it asked me to remove a whole lot of constraints from different functions, I did them in batches, so did not remove them all from the file at once, and at some point I had to add at least one of them back, albeit based on an error message. Regards Alan ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
RE: warn-redundant-constraints present as errors
Now I get Foo1.hs:39:8: Not in scope: ‘SYB.everythingStaged’ Foo1.hs:39:29: Not in scope: data constructor ‘SYB.Renamer’ Do you think you could open a ticket with a reproducible test case? That would be helpful Simon From: Alan Kim Zimmerman [mailto:alan.z...@gmail.com] Sent: 09 January 2015 11:54 To: Simon Peyton Jones Cc: ghc-devs@haskell.org Subject: Re: warn-redundant-constraints present as errors In the original definingSigsNames requires the constraint, I left that out to simplify the example, as the movement of the warning to an error still happens. Original definingSigsNames -- -- |Find those type signatures for the specified GHC.Names. definingSigsNames :: (SYB.Data t) = [GHC.Name] -- ^ The specified identifiers. -t-- ^ A collection of declarations. -[GHC.LSig GHC.Name] -- ^ The result. definingSigsNames pns ds = def ds where def decl = SYB.everythingStaged SYB.Renamer (++) [] ([] `SYB.mkQ` inSig) decl where inSig :: (GHC.LSig GHC.Name) - [GHC.LSig GHC.Name] inSig (GHC.L l (GHC.TypeSig ns t p)) | defines' ns /= [] = [(GHC.L l (GHC.TypeSig (defines' ns) t p))] inSig _ = [] defines' (p::[GHC.Located GHC.Name]) = filter (\(GHC.L _ n) - n `elem` pns) p -- On Fri, Jan 9, 2015 at 1:48 PM, Simon Peyton Jones simo...@microsoft.commailto:simo...@microsoft.com wrote: If you remove the constraint from duplicateDecl, then I get Redundant constraint: SYB.Data t In the type signature for: definingSigsNames :: SYB.Data t = [GHC.Name] - t - [GHC.LSig GHC.Name] which is 100% correct: defininingSigssNames doesn’t use its SYB.Data t constraint Simon From: Alan Kim Zimmerman [mailto:alan.z...@gmail.commailto:alan.z...@gmail.com] Sent: 09 January 2015 11:22 To: Simon Peyton Jones Cc: ghc-devs@haskell.orgmailto:ghc-devs@haskell.org Subject: Re: warn-redundant-constraints present as errors Thanks. I've found a case where it warns of a redundant constraint, but if I remove the constraint I get an error saying the constraint is required import qualified GHC as GHC import qualified Data.Generics as SYB duplicateDecl :: (SYB.Data t) = -- The constraint being warned against *** [GHC.LHsBind GHC.Name] -- ^ The declaration list -t -- ^ Any signatures are in here -GHC.Name -- ^ The identifier whose definition is to be duplicated -GHC.Name -- ^ The new name (possibly qualified) -IO [GHC.LHsBind GHC.Name] -- ^ The result duplicateDecl decls sigs n newFunName = do let sspan = undefined newSpan - case typeSig of [] - return sspan _ - do let Just sspanSig = getSrcSpan typeSig toksSig - getToksForSpan sspanSig let [(GHC.L sspanSig' _)] = typeSig return sspanSig' undefined where typeSig = definingSigsNames [n] sigs -- |Find those type signatures for the specified GHC.Names. definingSigsNames :: (SYB.Data t) = [GHC.Name] -- ^ The specified identifiers. -t-- ^ A collection of declarations. -[GHC.LSig GHC.Name] -- ^ The result. definingSigsNames pns ds = def ds where def = undefined getSrcSpan = undefined getToksForSpan = undefined On Fri, Jan 9, 2015 at 1:08 PM, Simon Peyton Jones simo...@microsoft.commailto:simo...@microsoft.com wrote: I’ve fixed this From: Alan Kim Zimmerman [mailto:alan.z...@gmail.commailto:alan.z...@gmail.com] Sent: 08 January 2015 21:46 To: ghc-devs@haskell.orgmailto:ghc-devs@haskell.org; Simon Peyton Jones Subject: warn-redundant-constraints present as errors This is a great feature, here is some feedback My syntax highlighter in emacs expects warnings to have the word warning in them. So for the two warnings reported below, the first is highlighted as an error, and the second as a warning Language/Haskell/Refact/Utils/TypeUtils.hs:3036:17: Redundant constraint: SYB.Data t In the type signature for: duplicateDecl :: SYB.Data t = [GHC.LHsBind GHC.Name] - t - GHC.Name - GHC.Name - RefactGhc [GHC.LHsBind GHC.Name] Language/Haskell/Refact/Utils/TypeUtils.hs:3045:7: Warning: Defined but not used: ‘toks This is in a ghci session, and the file loads without problems, so it is indeed a warning. Can we perhaps add the word Warning to the output for Redundant constraints? I also had a situation where it asked me to remove a whole lot of constraints from different functions, I did them in batches, so did not remove them all from the file at once, and at some point I had to add at least one of them back, albeit based on an error message. Regards Alan ___ ghc-devs mailing list ghc-devs@haskell.org
Re: Deprecating functions
On Jan 9, 2015, at 5:37 AM, Jan Stolarek jan.stola...@p.lodz.pl wrote: Especially that we're talking about internal TH module - I'll be surprised if there are more than 10 users. As I understand it, TH.Lib is not an internal module. Though I, personally, have never found the functions there to suit my needs as a user, I think the functions exported from there are the go-to place for lots of people using TH. For example, Ollie Charles's recent blog post on TH (https://ocharles.org.uk/blog/guest-posts/2014-12-22-template-haskell.html), written by Sean Westfall, uses functions exported from TH.Lib. I'm rather ambivalent on the deprecate vs. remove vs. hide vs. leave alone debate, but I do think we should treat TH.Lib as a fully public module as we're debating. Richard ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: warn-redundant-constraints present as errors
See https://ghc.haskell.org/trac/ghc/ticket/9973, my original file did not in fact exhibit the bug. On Fri, Jan 9, 2015 at 2:18 PM, Simon Peyton Jones simo...@microsoft.com wrote: Now I get Foo1.hs:39:8: Not in scope: ‘SYB.everythingStaged’ Foo1.hs:39:29: Not in scope: data constructor ‘SYB.Renamer’ Do you think you could open a ticket with a reproducible test case? That would be helpful Simon *From:* Alan Kim Zimmerman [mailto:alan.z...@gmail.com] *Sent:* 09 January 2015 11:54 *To:* Simon Peyton Jones *Cc:* ghc-devs@haskell.org *Subject:* Re: warn-redundant-constraints present as errors In the original definingSigsNames requires the constraint, I left that out to simplify the example, as the movement of the warning to an error still happens. Original definingSigsNames -- -- |Find those type signatures for the specified GHC.Names. definingSigsNames :: (SYB.Data t) = [GHC.Name] -- ^ The specified identifiers. -t-- ^ A collection of declarations. -[GHC.LSig GHC.Name] -- ^ The result. definingSigsNames pns ds = def ds where def decl = SYB.everythingStaged SYB.Renamer (++) [] ([] `SYB.mkQ` inSig) decl where inSig :: (GHC.LSig GHC.Name) - [GHC.LSig GHC.Name] inSig (GHC.L l (GHC.TypeSig ns t p)) | defines' ns /= [] = [(GHC.L l (GHC.TypeSig (defines' ns) t p))] inSig _ = [] defines' (p::[GHC.Located GHC.Name]) = filter (\(GHC.L _ n) - n `elem` pns) p -- On Fri, Jan 9, 2015 at 1:48 PM, Simon Peyton Jones simo...@microsoft.com wrote: If you remove the constraint from duplicateDecl, then I get Redundant constraint: SYB.Data t In the type signature for: definingSigsNames :: SYB.Data t = [GHC.Name] - t - [GHC.LSig GHC.Name] which is 100% correct: defininingSigssNames doesn’t use its SYB.Data t constraint Simon *From:* Alan Kim Zimmerman [mailto:alan.z...@gmail.com] *Sent:* 09 January 2015 11:22 *To:* Simon Peyton Jones *Cc:* ghc-devs@haskell.org *Subject:* Re: warn-redundant-constraints present as errors Thanks. I've found a case where it warns of a redundant constraint, but if I remove the constraint I get an error saying the constraint is required import qualified GHC as GHC import qualified Data.Generics as SYB duplicateDecl :: (SYB.Data t) = -- The constraint being warned against *** [GHC.LHsBind GHC.Name] -- ^ The declaration list -t -- ^ Any signatures are in here -GHC.Name -- ^ The identifier whose definition is to be duplicated -GHC.Name -- ^ The new name (possibly qualified) -IO [GHC.LHsBind GHC.Name] -- ^ The result duplicateDecl decls sigs n newFunName = do let sspan = undefined newSpan - case typeSig of [] - return sspan _ - do let Just sspanSig = getSrcSpan typeSig toksSig - getToksForSpan sspanSig let [(GHC.L sspanSig' _)] = typeSig return sspanSig' undefined where typeSig = definingSigsNames [n] sigs -- |Find those type signatures for the specified GHC.Names. definingSigsNames :: (SYB.Data t) = [GHC.Name] -- ^ The specified identifiers. -t-- ^ A collection of declarations. -[GHC.LSig GHC.Name] -- ^ The result. definingSigsNames pns ds = def ds where def = undefined getSrcSpan = undefined getToksForSpan = undefined On Fri, Jan 9, 2015 at 1:08 PM, Simon Peyton Jones simo...@microsoft.com wrote: I’ve fixed this *From:* Alan Kim Zimmerman [mailto:alan.z...@gmail.com] *Sent:* 08 January 2015 21:46 *To:* ghc-devs@haskell.org; Simon Peyton Jones *Subject:* warn-redundant-constraints present as errors This is a great feature, here is some feedback My syntax highlighter in emacs expects warnings to have the word warning in them. So for the two warnings reported below, the first is highlighted as an error, and the second as a warning Language/Haskell/Refact/Utils/TypeUtils.hs:3036:17: Redundant constraint: SYB.Data t In the type signature for: duplicateDecl :: SYB.Data t = [GHC.LHsBind GHC.Name] - t - GHC.Name - GHC.Name - RefactGhc [GHC.LHsBind GHC.Name] Language/Haskell/Refact/Utils/TypeUtils.hs:3045:7: Warning: Defined but not used: ‘toks This is in a ghci session, and the file loads without problems, so it is indeed a warning. Can we perhaps add the word Warning to the output for Redundant constraints? I also had a situation where it asked me to remove a whole lot of constraints from different functions, I did them in batches, so did not remove them all from the file at once, and at some
Re: Deprecating functions
On Fri, Jan 9, 2015 at 11:18 AM, Jan Stolarek jan.stola...@p.lodz.pl wrote: I agree. You'll get rid of the redundancy in the library by removing it but you're users will have to live with (...) That's why I want to deprecate them first and give users one release cycle to switch to new functions. I assumed that's enough but we could make this two or three release cycles. The reall question is how to remember that we should remove this at some point? If we want to avoid the CPP we need warning to be in major version X if that's when the old function is deprecated and the new one is added and the actual removal in X+2. At that point I'd just consider keeping the function and avoid the hassle. :) ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Deprecating functions
I think Java's (!) policy for deprecation is good I think it's not. It keeps the library code a mess and many times I have seen users using functions that have been deprecated for years just because it's easier to suppress a warning than change the code. I don't want Haskell to go down that path and I'm strongly in favour of removing these functions. Especially that we're talking about internal TH module - I'll be surprised if there are more than 10 users. Janek ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
RE: seq#: do we actually need it as a primitive?
I was wrong. See https://ghc.haskell.org/trac/ghc/ticket/5129#comment:17 which I have just added. Simon | -Original Message- | From: Simon Peyton Jones | Sent: 08 January 2015 15:05 | To: 'Roman Cheplyaka'; Edward Z. Yang; David Feuer | Cc: ghc-devs | Subject: RE: seq#: do we actually need it as a primitive? | | No (2) would not suffer from #5129. Think of | |type IO a = State# - (State#, a) |return x = \s - (s, x) |(=) m k s = case m s of (s, r) - k r s | | (it's a newtype actually, but this will do here). | | (2) says | | = \x - (return $! x) = return | = \x. \s. case return $! x s of (s1, r) - return r s1 | = \x\s. x `seq` case (s,x) of (s1, r) - return r s1 | = \x\s. x `seq` (s,x) | | which is fine. ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Deprecating functions
On Fri, Jan 9, 2015 at 11:37 AM, Jan Stolarek jan.stola...@p.lodz.pl wrote: I think Java's (!) policy for deprecation is good I think it's not. It keeps the library code a mess and many times I have seen users using functions that have been deprecated for years just because it's easier to suppress a warning than change the code. I don't want Haskell to go down that path and I'm strongly in favour of removing these functions. Especially that we're talking about internal TH module - I'll be surprised if there are more than 10 users. It also keeps Java having users. ;) More seriously, we who maintain the core libraries spend too much time dealing with breakages due to continuously moving libraries when we could spend time on building upwards to make Haskell a better platform for building applications. *In practice* our code is worse because of these continuous breakages (as it's full with hard to maintain CPP), not better. ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
RE: Redundant constraints
| I've fixed some of the warnings in transformers, but there are still | 14 of them, triggered by Applicative becoming a superclass of Monad. In GHC's own source code I did this #if __GLASGOW_HASKELL__ 710 -- Pre-AMP change runGhcT :: (ExceptionMonad m, Functor m) = #else runGhcT :: (ExceptionMonad m) = #endif | I think some of the changes already made are of this sort, exposing | details of the GHC implementation, e.g. the changes to the public | interface of Array and Ratio. For example, it's probably reasonable | to remove the Ix constraint from Data.Array.bounds, but the portable | reference implementation of Data.Array.elems requires Ix, even though | the GHC implementation doesn't. Similarly a portable implementation | of the Functor instance for Array i requires Ix, but the GHC | implementation doesn't. Fair enough. If the Core Libraries Committee wants to add some of these constraints back in, that's fine with me. They just need a comment to explain. (We have a trick, now in the user manual, for how to add a redundant constraint without triggering a complaint.) Simon ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: warn-redundant-constraints present as errors
Thanks. I've found a case where it warns of a redundant constraint, but if I remove the constraint I get an error saying the constraint is required import qualified GHC as GHC import qualified Data.Generics as SYB duplicateDecl :: (SYB.Data t) = -- The constraint being warned against *** [GHC.LHsBind GHC.Name] -- ^ The declaration list -t -- ^ Any signatures are in here -GHC.Name -- ^ The identifier whose definition is to be duplicated -GHC.Name -- ^ The new name (possibly qualified) -IO [GHC.LHsBind GHC.Name] -- ^ The result duplicateDecl decls sigs n newFunName = do let sspan = undefined newSpan - case typeSig of [] - return sspan _ - do let Just sspanSig = getSrcSpan typeSig toksSig - getToksForSpan sspanSig let [(GHC.L sspanSig' _)] = typeSig return sspanSig' undefined where typeSig = definingSigsNames [n] sigs -- |Find those type signatures for the specified GHC.Names. definingSigsNames :: (SYB.Data t) = [GHC.Name] -- ^ The specified identifiers. -t-- ^ A collection of declarations. -[GHC.LSig GHC.Name] -- ^ The result. definingSigsNames pns ds = def ds where def = undefined getSrcSpan = undefined getToksForSpan = undefined On Fri, Jan 9, 2015 at 1:08 PM, Simon Peyton Jones simo...@microsoft.com wrote: I’ve fixed this *From:* Alan Kim Zimmerman [mailto:alan.z...@gmail.com] *Sent:* 08 January 2015 21:46 *To:* ghc-devs@haskell.org; Simon Peyton Jones *Subject:* warn-redundant-constraints present as errors This is a great feature, here is some feedback My syntax highlighter in emacs expects warnings to have the word warning in them. So for the two warnings reported below, the first is highlighted as an error, and the second as a warning Language/Haskell/Refact/Utils/TypeUtils.hs:3036:17: Redundant constraint: SYB.Data t In the type signature for: duplicateDecl :: SYB.Data t = [GHC.LHsBind GHC.Name] - t - GHC.Name - GHC.Name - RefactGhc [GHC.LHsBind GHC.Name] Language/Haskell/Refact/Utils/TypeUtils.hs:3045:7: Warning: Defined but not used: ‘toks This is in a ghci session, and the file loads without problems, so it is indeed a warning. Can we perhaps add the word Warning to the output for Redundant constraints? I also had a situation where it asked me to remove a whole lot of constraints from different functions, I did them in batches, so did not remove them all from the file at once, and at some point I had to add at least one of them back, albeit based on an error message. Regards Alan ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: warn-redundant-constraints present as errors
In the original definingSigsNames requires the constraint, I left that out to simplify the example, as the movement of the warning to an error still happens. Original definingSigsNames -- -- |Find those type signatures for the specified GHC.Names. definingSigsNames :: (SYB.Data t) = [GHC.Name] -- ^ The specified identifiers. -t-- ^ A collection of declarations. -[GHC.LSig GHC.Name] -- ^ The result. definingSigsNames pns ds = def ds where def decl = SYB.everythingStaged SYB.Renamer (++) [] ([] `SYB.mkQ` inSig) decl where inSig :: (GHC.LSig GHC.Name) - [GHC.LSig GHC.Name] inSig (GHC.L l (GHC.TypeSig ns t p)) | defines' ns /= [] = [(GHC.L l (GHC.TypeSig (defines' ns) t p))] inSig _ = [] defines' (p::[GHC.Located GHC.Name]) = filter (\(GHC.L _ n) - n `elem` pns) p -- On Fri, Jan 9, 2015 at 1:48 PM, Simon Peyton Jones simo...@microsoft.com wrote: If you remove the constraint from duplicateDecl, then I get Redundant constraint: SYB.Data t In the type signature for: definingSigsNames :: SYB.Data t = [GHC.Name] - t - [GHC.LSig GHC.Name] which is 100% correct: defininingSigssNames doesn’t use its SYB.Data t constraint Simon *From:* Alan Kim Zimmerman [mailto:alan.z...@gmail.com] *Sent:* 09 January 2015 11:22 *To:* Simon Peyton Jones *Cc:* ghc-devs@haskell.org *Subject:* Re: warn-redundant-constraints present as errors Thanks. I've found a case where it warns of a redundant constraint, but if I remove the constraint I get an error saying the constraint is required import qualified GHC as GHC import qualified Data.Generics as SYB duplicateDecl :: (SYB.Data t) = -- The constraint being warned against *** [GHC.LHsBind GHC.Name] -- ^ The declaration list -t -- ^ Any signatures are in here -GHC.Name -- ^ The identifier whose definition is to be duplicated -GHC.Name -- ^ The new name (possibly qualified) -IO [GHC.LHsBind GHC.Name] -- ^ The result duplicateDecl decls sigs n newFunName = do let sspan = undefined newSpan - case typeSig of [] - return sspan _ - do let Just sspanSig = getSrcSpan typeSig toksSig - getToksForSpan sspanSig let [(GHC.L sspanSig' _)] = typeSig return sspanSig' undefined where typeSig = definingSigsNames [n] sigs -- |Find those type signatures for the specified GHC.Names. definingSigsNames :: (SYB.Data t) = [GHC.Name] -- ^ The specified identifiers. -t-- ^ A collection of declarations. -[GHC.LSig GHC.Name] -- ^ The result. definingSigsNames pns ds = def ds where def = undefined getSrcSpan = undefined getToksForSpan = undefined On Fri, Jan 9, 2015 at 1:08 PM, Simon Peyton Jones simo...@microsoft.com wrote: I’ve fixed this *From:* Alan Kim Zimmerman [mailto:alan.z...@gmail.com] *Sent:* 08 January 2015 21:46 *To:* ghc-devs@haskell.org; Simon Peyton Jones *Subject:* warn-redundant-constraints present as errors This is a great feature, here is some feedback My syntax highlighter in emacs expects warnings to have the word warning in them. So for the two warnings reported below, the first is highlighted as an error, and the second as a warning Language/Haskell/Refact/Utils/TypeUtils.hs:3036:17: Redundant constraint: SYB.Data t In the type signature for: duplicateDecl :: SYB.Data t = [GHC.LHsBind GHC.Name] - t - GHC.Name - GHC.Name - RefactGhc [GHC.LHsBind GHC.Name] Language/Haskell/Refact/Utils/TypeUtils.hs:3045:7: Warning: Defined but not used: ‘toks This is in a ghci session, and the file loads without problems, so it is indeed a warning. Can we perhaps add the word Warning to the output for Redundant constraints? I also had a situation where it asked me to remove a whole lot of constraints from different functions, I did them in batches, so did not remove them all from the file at once, and at some point I had to add at least one of them back, albeit based on an error message. Regards Alan ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
