RE: [commit: ghc] master: Remove -fno-warn-amp sledgehammers for validate (6074c5d)
There is much more to change, right? * The code in the compiler that implements -fwarn-amp * Actually making Applicative a superclass of monad Simon | -Original Message- | From: ghc-commits [mailto:ghc-commits-boun...@haskell.org] On Behalf Of | g...@git.haskell.org | Sent: 20 April 2014 07:02 | To: ghc-comm...@haskell.org | Subject: [commit: ghc] master: Remove -fno-warn-amp sledgehammers for | validate (6074c5d) | | Repository : ssh://g...@git.haskell.org/ghc | | On branch : master | Link : | http://ghc.haskell.org/trac/ghc/changeset/6074c5da7f48f10e9b3b88d14607e | c4955735931/ghc | | --- | | commit 6074c5da7f48f10e9b3b88d14607ec4955735931 | Author: Austin Seipp aus...@well-typed.com | Date: Sun Apr 20 01:00:44 2014 -0500 | | Remove -fno-warn-amp sledgehammers for validate | | GHC should now fully compliant with respect to the Applicative | Monad | proposal (including all upstream libraries), and does not need to | suppress this warning anymore. | | Signed-off-by: Austin Seipp aus...@well-typed.com | | | --- | | 6074c5da7f48f10e9b3b88d14607ec4955735931 | mk/validate-settings.mk |2 -- | 1 file changed, 2 deletions(-) | | diff --git a/mk/validate-settings.mk b/mk/validate-settings.mk index | 8797bf9..cac938d 100644 | --- a/mk/validate-settings.mk | +++ b/mk/validate-settings.mk | @@ -32,7 +32,6 @@ SRC_HC_OPTS += $(WERROR) -Wall | | GhcStage1HcOpts += -fwarn-tabs | GhcStage2HcOpts += -fwarn-tabs | -GhcStage2HcOpts += -fno-warn-amp # Temporary sledgehammer until we | sync upstream. | | utils/hpc_dist-install_EXTRA_HC_OPTS += -fwarn-tabs | | @@ -46,7 +45,6 @@ GhcStage2HcOpts += -O -dcore-lint # running of the | tests, and faster building of the utils to be installed | | GhcLibHcOpts+= -O -dcore-lint | -GhcLibHcOpts+= -fno-warn-amp # Temporary sledgehammer until we | sync upstream. | | # We define DefaultFastGhcLibWays in this style so that the value is | # correct even if the user alters DYNAMIC_GHC_PROGRAMS. | | ___ | ghc-commits mailing list | ghc-comm...@haskell.org | http://www.haskell.org/mailman/listinfo/ghc-commits ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
RE: [commit: ghc] master: Deprecate the AMP warnings. (3608f65)
I think we can go further: we can remove the code that implements -fwarn-amp. I agree that the flag itself should remain for a cycle, deprecated, as a no-op. Simon | -Original Message- | From: ghc-commits [mailto:ghc-commits-boun...@haskell.org] On Behalf Of | g...@git.haskell.org | Sent: 20 April 2014 22:56 | To: ghc-comm...@haskell.org | Subject: [commit: ghc] master: Deprecate the AMP warnings. (3608f65) | | Repository : ssh://g...@git.haskell.org/ghc | | On branch : master | Link : | http://ghc.haskell.org/trac/ghc/changeset/3608f657d55b7ea7dd711556a4faf | 6a15c509163/ghc | | --- | | commit 3608f657d55b7ea7dd711556a4faf6a15c509163 | Author: Austin Seipp aus...@well-typed.com | Date: Sun Apr 20 01:10:15 2014 -0500 | | Deprecate the AMP warnings. | | Now that we're in development mode, Applicative will soon be a | superclass of Monad in HEAD. So let's go ahead and deprecate the | -fno-warn-amp flag, remove the checks, and tweak a few tests | | Signed-off-by: Austin Seipp aus...@well-typed.com | | | --- | | 3608f657d55b7ea7dd711556a4faf6a15c509163 | compiler/main/DynFlags.hs |4 +- | compiler/typecheck/TcRnDriver.lhs | 215 +--- | | docs/users_guide/flags.xml |2 +- | .../tests/ghci.debugger/scripts/break006.stderr|4 +- | .../tests/ghci.debugger/scripts/print019.stderr|2 +- | .../should_fail/overloadedlistsfail01.stderr |2 +- | testsuite/tests/rename/should_compile/T7145b.hs|3 - | .../tests/rename/should_compile/T7145b.stderr |2 +- | .../tests/simplCore/should_compile/spec001.hs |3 +- | .../tests/typecheck/should_compile/holes2.stderr |2 +- | testsuite/tests/typecheck/should_fail/T5095.stderr |2 - | .../tests/typecheck/should_fail/tcfail072.stderr |2 +- | .../tests/typecheck/should_fail/tcfail133.stderr |2 +- | .../tests/typecheck/should_fail/tcfail181.stderr |1 - | 14 files changed, 14 insertions(+), 232 deletions(-) | | Diff suppressed because of size. To see it, use: | | git diff-tree --root --patch-with-stat --no-color --find-copies- | harder --ignore-space-at-eol --cc | 3608f657d55b7ea7dd711556a4faf6a15c509163 | ___ | ghc-commits mailing list | ghc-comm...@haskell.org | http://www.haskell.org/mailman/listinfo/ghc-commits ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: [commit: ghc] master: Remove -fno-warn-amp sledgehammers for validate (6074c5d)
Yes the first part is done - see 3608f657d5 I removed the validate bandages first, so I could make sure that everything worked properly with -fno-warn-amp *legitimately* on and not deprecated. I then removed it afterwords in 3608f657d5 and replaced it with a deprecation notice. That means HEAD should now be 100% ready to actually make Applicative a superclass of Monad, the changes require shuffling around a bit of stuff in base though, I think. On Mon, Apr 21, 2014 at 2:47 AM, Simon Peyton Jones simo...@microsoft.com wrote: There is much more to change, right? * The code in the compiler that implements -fwarn-amp * Actually making Applicative a superclass of monad Simon | -Original Message- | From: ghc-commits [mailto:ghc-commits-boun...@haskell.org] On Behalf Of | g...@git.haskell.org | Sent: 20 April 2014 07:02 | To: ghc-comm...@haskell.org | Subject: [commit: ghc] master: Remove -fno-warn-amp sledgehammers for | validate (6074c5d) | | Repository : ssh://g...@git.haskell.org/ghc | | On branch : master | Link : | http://ghc.haskell.org/trac/ghc/changeset/6074c5da7f48f10e9b3b88d14607e | c4955735931/ghc | | --- | | commit 6074c5da7f48f10e9b3b88d14607ec4955735931 | Author: Austin Seipp aus...@well-typed.com | Date: Sun Apr 20 01:00:44 2014 -0500 | | Remove -fno-warn-amp sledgehammers for validate | | GHC should now fully compliant with respect to the Applicative | Monad | proposal (including all upstream libraries), and does not need to | suppress this warning anymore. | | Signed-off-by: Austin Seipp aus...@well-typed.com | | | --- | | 6074c5da7f48f10e9b3b88d14607ec4955735931 | mk/validate-settings.mk |2 -- | 1 file changed, 2 deletions(-) | | diff --git a/mk/validate-settings.mk b/mk/validate-settings.mk index | 8797bf9..cac938d 100644 | --- a/mk/validate-settings.mk | +++ b/mk/validate-settings.mk | @@ -32,7 +32,6 @@ SRC_HC_OPTS += $(WERROR) -Wall | | GhcStage1HcOpts += -fwarn-tabs | GhcStage2HcOpts += -fwarn-tabs | -GhcStage2HcOpts += -fno-warn-amp # Temporary sledgehammer until we | sync upstream. | | utils/hpc_dist-install_EXTRA_HC_OPTS += -fwarn-tabs | | @@ -46,7 +45,6 @@ GhcStage2HcOpts += -O -dcore-lint # running of the | tests, and faster building of the utils to be installed | | GhcLibHcOpts+= -O -dcore-lint | -GhcLibHcOpts+= -fno-warn-amp # Temporary sledgehammer until we | sync upstream. | | # We define DefaultFastGhcLibWays in this style so that the value is | # correct even if the user alters DYNAMIC_GHC_PROGRAMS. | | ___ | ghc-commits mailing list | ghc-comm...@haskell.org | http://www.haskell.org/mailman/listinfo/ghc-commits ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/ ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: [commit: ghc] master: Deprecate the AMP warnings. (3608f65)
Yep that's done, it's all removed from TcRnDriver. I think I missed some of the lingering wired-in-names in PrelNames though, now that I look at it... On Mon, Apr 21, 2014 at 2:51 AM, Simon Peyton Jones simo...@microsoft.com wrote: I think we can go further: we can remove the code that implements -fwarn-amp. I agree that the flag itself should remain for a cycle, deprecated, as a no-op. Simon | -Original Message- | From: ghc-commits [mailto:ghc-commits-boun...@haskell.org] On Behalf Of | g...@git.haskell.org | Sent: 20 April 2014 22:56 | To: ghc-comm...@haskell.org | Subject: [commit: ghc] master: Deprecate the AMP warnings. (3608f65) | | Repository : ssh://g...@git.haskell.org/ghc | | On branch : master | Link : | http://ghc.haskell.org/trac/ghc/changeset/3608f657d55b7ea7dd711556a4faf | 6a15c509163/ghc | | --- | | commit 3608f657d55b7ea7dd711556a4faf6a15c509163 | Author: Austin Seipp aus...@well-typed.com | Date: Sun Apr 20 01:10:15 2014 -0500 | | Deprecate the AMP warnings. | | Now that we're in development mode, Applicative will soon be a | superclass of Monad in HEAD. So let's go ahead and deprecate the | -fno-warn-amp flag, remove the checks, and tweak a few tests | | Signed-off-by: Austin Seipp aus...@well-typed.com | | | --- | | 3608f657d55b7ea7dd711556a4faf6a15c509163 | compiler/main/DynFlags.hs |4 +- | compiler/typecheck/TcRnDriver.lhs | 215 +--- | | docs/users_guide/flags.xml |2 +- | .../tests/ghci.debugger/scripts/break006.stderr|4 +- | .../tests/ghci.debugger/scripts/print019.stderr|2 +- | .../should_fail/overloadedlistsfail01.stderr |2 +- | testsuite/tests/rename/should_compile/T7145b.hs|3 - | .../tests/rename/should_compile/T7145b.stderr |2 +- | .../tests/simplCore/should_compile/spec001.hs |3 +- | .../tests/typecheck/should_compile/holes2.stderr |2 +- | testsuite/tests/typecheck/should_fail/T5095.stderr |2 - | .../tests/typecheck/should_fail/tcfail072.stderr |2 +- | .../tests/typecheck/should_fail/tcfail133.stderr |2 +- | .../tests/typecheck/should_fail/tcfail181.stderr |1 - | 14 files changed, 14 insertions(+), 232 deletions(-) | | Diff suppressed because of size. To see it, use: | | git diff-tree --root --patch-with-stat --no-color --find-copies- | harder --ignore-space-at-eol --cc | 3608f657d55b7ea7dd711556a4faf6a15c509163 | ___ | ghc-commits mailing list | ghc-comm...@haskell.org | http://www.haskell.org/mailman/listinfo/ghc-commits ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/ ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
RE: Strange behaviour in my signum
Alexander
Thanks for working on this.
I suggest you add your draft patches and comments to the ticket #7858.
Otherwise there is a terrible danger that they'll get lost.
Simon
| -Original Message-
| From: ghc-devs [mailto:ghc-devs-boun...@haskell.org] On Behalf Of
| Alexander Berntsen
| Sent: 19 April 2014 19:02
| To: ghc-devs@haskell.org
| Subject: Strange behaviour in my signum
|
| I started preparing patches for #7858. My abs patch works well, my
| signum patch not at all.
|
| The gist of the bug is that abs and signum return erroneous values for
| for the input -0.0. abs (-0.0 :: Float) should return 0.0, not -0.0. My
| patch fixes this. For signum the situation is reverse. My patch does
| *not* fix this.
|
| It does not work using GHC nor GHCi (GHCi -ddump-simpl demonstrated
| below). The code for my signum is correct, as may be demonstrated by
| putting
|
| signumFix x
| | x == 0.0 = x
| | isNaN x = x
| | x 0.0 = 1
| | otherwise = negate 1
|
| in a file signumfix.hs and :l signumfix.hs into GHCi. signumFix (-0.0
| ::
| Float) should now return -0.0, where signum returns 0.0 with the same
| argument.
|
| Following this email come the patches. Please review the second patch.
| If you can spot what I am doing wrong, I would be grateful.
|
|
|
|
| Prelude abs (-0.0 :: Float)
|
| Simplified expression let {
| it_aqt :: GHC.Types.Float
| [LclId,
|Str=DmdType,
|Unf=Unf{Src=vanilla, TopLvl=False, Arity=0, Value=False,
|ConLike=False, WorkFree=False, Expandable=False,
|Guidance=IF_ARGS [] 70 0}]
| it_aqt =
| GHC.Num.abs
| @ GHC.Types.Float
| GHC.Float.$fNumFloat
| (GHC.Num.negate
| @ GHC.Types.Float
| GHC.Float.$fNumFloat
| (GHC.Types.F# (__float 0.0))) } in GHC.Base.thenIO
| @ ()
| @ [()]
| (System.IO.print @ GHC.Types.Float GHC.Float.$fShowFloat it_aqt)
| (GHC.Base.returnIO
| @ [()]
| (GHC.Types.:
| @ ()
| (it_aqt
| `cast` (UnivCo representational GHC.Types.Float ()
| :: GHC.Types.Float ~# ()))
| (GHC.Types.[] @ (
|
|
| 0.0
|
|
|
|
| Prelude signum (-0.0 :: Float)
|
| Simplified expression let {
| it_aKQ :: GHC.Types.Float
| [LclId,
|Str=DmdType,
|Unf=Unf{Src=vanilla, TopLvl=False, Arity=0, Value=False,
|ConLike=False, WorkFree=False, Expandable=False,
|Guidance=IF_ARGS [] 70 0}]
| it_aKQ =
| GHC.Num.signum
| @ GHC.Types.Float
| GHC.Float.$fNumFloat
| (GHC.Num.negate
| @ GHC.Types.Float
| GHC.Float.$fNumFloat
| (GHC.Types.F# (__float 0.0))) } in GHC.Base.thenIO
| @ ()
| @ [()]
| (System.IO.print @ GHC.Types.Float GHC.Float.$fShowFloat it_aKQ)
| (GHC.Base.returnIO
| @ [()]
| (GHC.Types.:
| @ ()
| (it_aKQ
| `cast` (UnivCo representational GHC.Types.Float ()
| :: GHC.Types.Float ~# ()))
| (GHC.Types.[] @ (
|
|
| 0.0
|
| Alexander Berntsen (2):
| Make Prelude.abs handle -0.0 correctly (#7858)
| Make Prelude.signum handle -0.0 correctly (#7858)
|
| libraries/base/GHC/Float.lhs | 28 ++--
| libraries/base/changelog.md | 2 ++
| 2 files changed, 20 insertions(+), 10 deletions(-)
|
| --
| 1.8.3.2
|
| ___
| 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: HEADS-UP: Folding in base, integer-{gmp, single}, ghc-prim, and haskell-template into ghc.git
| As there were no objections, I went on and implemented the change, so | as of | | | http://git.haskell.org/ghc.git/commit/41f5b7e3e0648302b9c5dc485917a391d | 21d15a1 | | the repositories mentioned above are now part of ghc.git, and the same | procedure applies as when we folded-in testsuite some time ago. Great! But what, specifically, is the same procedure? That is, if I have an existing tree, what steps do I take to upgrade? Never underestimate how stupid I am with git. Thanks Simon ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
RE: Validate Failures
| The T8333 failure is due to it reading my .ghci file, thus getting | additional output. Is there a way to automatically check that all tests | that use the --interactive flag also use -ignore-dot-ghci like the | ghci tests do, or must one wait for validate failures due to that and | add it then? Could we not pass -ignore-dot-ghci to every test-invocation, whether in ghci tests or not? Maybe someone can make a patch to do that? Simon ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
OverloadedRecordFields merge
Hello all, As some of you might have seen last week, my colleague Adam took the time to get his OverloadedRecordFields back up to date with regards to HEAD. I'm now wondering: when should we pull the trigger? I am inclined to say 'soon'. In particular, the ORF changes are rather large, and Adam has hinted to me it touches a lot of components of e.g. name resolution. A large change with some fairly big impacts, in other words. I think it is perhaps best to merge soon - so that it does not get out of date and cause undue burden to Adam, but also so that we have maximal amounts of time to sort out issues in the long haul that it might expose. Simon - I believe you reviewed Adam's work in the past, yes? I am wondering what you think we should do here. I am more than willing to defer to you and let you do the merge after another review. On the other hand, if you already did review it and feel confident after a look or two, I'm more than willing to take over sometime this week. Adam - since you emailed us last week, Herbert went ahead and merged 'base' into GHC's repository. This does not invalidate the changes you gave us, it just means the two commits can be collapsed into one. Also, the performance failures seem like minor anomalies, but I have not yet directly built the ORF branch to confirm this. You're free to rebase yourself, or I can likely handle it without much issue soon. If anyone else has opinions here - please speak up, I'm all ears. For those reading, Adam's implementation is available in current form here: - https://github.com/adamgundry/ghc - https://github.com/adamgundry/packages-base - https://github.com/adamgundry/haddock -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/ ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: OverloadedRecordFields merge
On 04/21/2014 03:12 PM, Austin Seipp wrote: Hello all, As some of you might have seen last week, my colleague Adam took the time to get his OverloadedRecordFields back up to date with regards to HEAD. I'm now wondering: when should we pull the trigger? I am inclined to say 'soon'. In particular, the ORF changes are rather large, and Adam has hinted to me it touches a lot of components of e.g. name resolution. A large change with some fairly big impacts, in other words. I think it is perhaps best to merge soon - so that it does not get out of date and cause undue burden to Adam, but also so that we have maximal amounts of time to sort out issues in the long haul that it might expose. Simon - I believe you reviewed Adam's work in the past, yes? I am wondering what you think we should do here. I am more than willing to defer to you and let you do the merge after another review. On the other hand, if you already did review it and feel confident after a look or two, I'm more than willing to take over sometime this week. Adam - since you emailed us last week, Herbert went ahead and merged 'base' into GHC's repository. This does not invalidate the changes you gave us, it just means the two commits can be collapsed into one. Also, the performance failures seem like minor anomalies, but I have not yet directly built the ORF branch to confirm this. You're free to rebase yourself, or I can likely handle it without much issue soon. If anyone else has opinions here - please speak up, I'm all ears. For those reading, Adam's implementation is available in current form here: - https://github.com/adamgundry/ghc - https://github.com/adamgundry/packages-base - https://github.com/adamgundry/haddock I see a change to the Haddock interface file but the interface file version was not bumped (top of the file) which means that Haddock will try to read old interface file versions which will fail (I think). I would try myself but my system currently isn't really in appropriate state, perhaps I manage to do so later. It'd be great if we could default that to empty Map if we can't read it in but I don't think we can do that with existing binary (but we should be able to with the future CBOR stuff). Other than that, the Haddock patch looks good but again, I can not try it myself at the moment. I have to say I'm quite excited for overloaded records. -- Mateusz K. ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Automating Windows setup for development
This is really cool, thanks! If you wouldn't mind, perhaps that page should be updated (the MSYS2 page) to point to your Powershell script. That would be really useful and make it much easier to find for people who don't follow the mailing list. On Mon, Apr 21, 2014 at 8:03 PM, Niklas Larsson metanik...@gmail.com wrote: Hi! I have made a Powershell script that sets up a GHC build environment on Windows from scratch. It's at https://github.com/melted/getghc. It largely follows the instructions at https://ghc.haskell.org/trac/ghc/wiki/Building/Preparation/Windows/MSYS2. It has no dependencies aside from Powershell 3.0. The reason I made it was to make it easier to set up a build bot on a clean machine. But it's probably generally useful for people who want to develop GHC on Windows. Usage: - Put the script in an empty directory - Run it - Hope for the best Potential problems: - If Python 2.7 is already installed and not on the path, the script wont install it, and msys wont pick up the path. Solution: Add the path to python in the control panel. - Powershell wont run unsigned scripts by default. The error message will give a hint how to disable that. I will add a signed version as soon as I can figure out how. Niklas ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/ ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: update latest user manual
This is fixed, thanks Richard. I just forgot to update the symlink. On Mon, Apr 21, 2014 at 1:18 PM, Richard Eisenberg e...@cis.upenn.edu wrote: Hi devs, I’m not sure who is responsible for this (Austin? Herbert?), but http://www.haskell.org/ghc/docs/latest/html/users_guide/index.html links to v7.8.1, though 7.8.2 is available. We should update. Thanks, Richard ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/ ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
