RE: OverloadedRecordFields
Adam I'm very happy to hear that... good stuff. I'm under water with ICFP submissions (deadline Sat). Moreover I think it is clearly too later to put this into 7.8; RC1 is out and I expect RC2 any day. So I suggest we plan to merge after 7.8 is out. Are the wiki pages up to date? Records/OverloadedRecordFields Records/OverloadedRecordFields/Implementation Records/OverloadedRecordFields/Plan The first does not point to the latter two; "Plan" may mean "Design"... I feel some rationalisation may make sense Simon | -----Original Message----- | From: Adam Gundry [mailto:adam@well-typed.com] | Sent: 24 February 2014 08:37 | To: Simon Peyton Jones | Subject: Re: OverloadedRecordFields | | Hi Simon, | | My OverloadedRecordFields branches[1,2,3] are up to date with HEAD as of | last Saturday. Validate on linux x86_64 reports only one failure, the | haddock.Cabal perf test, which might well be due to my Haddock changes, | and I will investigate. I'm not sure how to run the Haddock test suite? | | I am keen to get the code reviewed and into HEAD as soon as is | convenient, but I'm aware these are substantial changes, and don't want | to rush things. In particular, I would understand if you'd rather hold | them back until after the 7.8 final release. | | How would you like to proceed? | | Adam | | [1] https://github.com/adamgundry/ghc | [2] https://github.com/adamgundry/packages-base | [3] https://github.com/adamgundry/haddock | | | On 17/01/14 10:55, Simon Peyton Jones wrote: | > Yes that sounds ok, thanks. I'd prefer to have a write-up of what | goes wrong with the 2-parameter story, so that we don't forget. | > | > Simon | > | > | -----Original Message----- | > | From: Adam Gundry [mailto:adam@well-typed.com] | > | Sent: 17 January 2014 10:15 | > | To: Simon Peyton Jones | > | Subject: OverloadedRecordFields | > | | > | Hi Simon, | > | | > | I'm conscious that things have gone off the boil a little wrt | > | OverloadedRecordFields, partially as a consequence of the delayed | > | 7.8 release but also my lack of time for other projects since | > | starting work for Well-Typed. With that in mind, I'd like to propose | > | a plan to get back on track: | > | | > | 1. Revert to the three-parameter story, where we have | > | | > | t ~ FldTy r f => Has r f t | > | | > | rather than | > | | > | Has r f. | > | | > | The two-parameter version generates significantly worse error | > | messages, and there are some other unresolved problems, so I'm not | > | sure it is worth the minor simplification. | > | | > | 2. Roll back some of the refactoring that I've struggled to get | > | right (in particular, trying to make the generated FldTy/UpdTy | > | axioms implicitTyThings). We can always revisit this in the future | though. | > | | > | 3. Merge HEAD into my branch: I suspect this will be a bit painful | > | by now, but presumably with 7.8 imminent there won't be many major | > | changes coming for a while? | > | | > | 4. Review the proposed changes with you and fix any show-stopping | > | problems. | > | | > | 5. Merge into HEAD after 7.8 is released. | > | | > | Does this sound plausible? I'm happy to Skype if you like. | > | | > | Cheers, | > | | > | Adam | > | | > | P.S. I'm not sure if Andrew Kennedy has mentioned it to you, but | > | Neil Ghani has got me some funding to work with them both on units | > | of measure for Haskell. We are still sorting out the details, but I | > | hope it might be possible to work on some kind of plugin mechanism | > | for GHC's constraint solver, along the lines that Iavor has been | > | investigating, if that would be of interest? | > | | > | -- | > | Adam Gundry, Haskell Consultant | > | Well-Typed LLP, http://www.well-typed.com/ | > | | | -- | Adam Gundry, Haskell Consultant | Well-Typed LLP, http://www.well-typed.com/
Simon, On 25/02/14 16:18, Simon Peyton Jones wrote:
I'm very happy to hear that... good stuff.
I'm under water with ICFP submissions (deadline Sat). Moreover I think it is clearly too later to put this into 7.8; RC1 is out and I expect RC2 any day.
So I suggest we plan to merge after 7.8 is out.
Right. I wasn't suggesting to put OverloadedRecordFields in 7.8, just the 7.9 master branch! But given the potential need to backport fixes from master to the 7.8 branch, I think it makes sense to wait.
Are the wiki pages up to date? Records/OverloadedRecordFields Records/OverloadedRecordFields/Implementation Records/OverloadedRecordFields/Plan
The first does not point to the latter two; "Plan" may mean "Design"... I feel some rationalisation may make sense
They are up to date but I'll go over them and tidy them up. Alas, it doesn't look like Trac supports redirects... Adam
| -----Original Message----- | From: Adam Gundry [mailto:adam@well-typed.com] | Sent: 24 February 2014 08:37 | To: Simon Peyton Jones | Subject: Re: OverloadedRecordFields | | Hi Simon, | | My OverloadedRecordFields branches[1,2,3] are up to date with HEAD as of | last Saturday. Validate on linux x86_64 reports only one failure, the | haddock.Cabal perf test, which might well be due to my Haddock changes, | and I will investigate. I'm not sure how to run the Haddock test suite? | | I am keen to get the code reviewed and into HEAD as soon as is | convenient, but I'm aware these are substantial changes, and don't want | to rush things. In particular, I would understand if you'd rather hold | them back until after the 7.8 final release. | | How would you like to proceed? | | Adam | | [1] https://github.com/adamgundry/ghc | [2] https://github.com/adamgundry/packages-base | [3] https://github.com/adamgundry/haddock | | | On 17/01/14 10:55, Simon Peyton Jones wrote: | > Yes that sounds ok, thanks. I'd prefer to have a write-up of what | goes wrong with the 2-parameter story, so that we don't forget. | > | > Simon | > | > | -----Original Message----- | > | From: Adam Gundry [mailto:adam@well-typed.com] | > | Sent: 17 January 2014 10:15 | > | To: Simon Peyton Jones | > | Subject: OverloadedRecordFields | > | | > | Hi Simon, | > | | > | I'm conscious that things have gone off the boil a little wrt | > | OverloadedRecordFields, partially as a consequence of the delayed | > | 7.8 release but also my lack of time for other projects since | > | starting work for Well-Typed. With that in mind, I'd like to propose | > | a plan to get back on track: | > | | > | 1. Revert to the three-parameter story, where we have | > | | > | t ~ FldTy r f => Has r f t | > | | > | rather than | > | | > | Has r f. | > | | > | The two-parameter version generates significantly worse error | > | messages, and there are some other unresolved problems, so I'm not | > | sure it is worth the minor simplification. | > | | > | 2. Roll back some of the refactoring that I've struggled to get | > | right (in particular, trying to make the generated FldTy/UpdTy | > | axioms implicitTyThings). We can always revisit this in the future | though. | > | | > | 3. Merge HEAD into my branch: I suspect this will be a bit painful | > | by now, but presumably with 7.8 imminent there won't be many major | > | changes coming for a while? | > | | > | 4. Review the proposed changes with you and fix any show-stopping | > | problems. | > | | > | 5. Merge into HEAD after 7.8 is released. | > | | > | Does this sound plausible? I'm happy to Skype if you like. | > | | > | Cheers, | > | | > | Adam
-- Adam Gundry, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/
On 2014-02-25 at 18:42:03 +0100, Adam Gundry wrote: [...]
They are up to date but I'll go over them and tidy them up. Alas, it doesn't look like Trac supports redirects...
actually, it does, but the plugin was just missing; see https://ghc.haskell.org/trac/ghc/wiki/WikiMacros#Description for more details
On 25/02/14 16:18, Simon Peyton Jones wrote:
Adam
I'm very happy to hear that... good stuff.
I'm under water with ICFP submissions (deadline Sat). Moreover I think it is clearly too later to put this into 7.8; RC1 is out and I expect RC2 any day.
So I suggest we plan to merge after 7.8 is out.
Are the wiki pages up to date? Records/OverloadedRecordFields Records/OverloadedRecordFields/Implementation Records/OverloadedRecordFields/Plan
The first does not point to the latter two; "Plan" may mean "Design"... I feel some rationalisation may make sense
Simon
| -----Original Message----- | From: Adam Gundry [mailto:adam@well-typed.com] | Sent: 24 February 2014 08:37 | To: Simon Peyton Jones | Subject: Re: OverloadedRecordFields | | Hi Simon, | | My OverloadedRecordFields branches[1,2,3] are up to date with HEAD as of | last Saturday. Validate on linux x86_64 reports only one failure, the | haddock.Cabal perf test, which might well be due to my Haddock changes, | and I will investigate. I'm not sure how to run the Haddock test suite?
Hi Adam, I'm seeing that perf failure even without any of your changes. Perhaps you could try validating without your changes to confirm that the perf failure happens anyway? There are two Haddock test-suites of interest: tests ran by GHC to make sure that appropriate files parse (I updated these just yesterday so please make sure you're up to date) and Haddock's own test-suite to make sure that the output we produce is correct. To run Haddock's own tests, you can use ‘cabal test’. You'll need QuickCheck and hspec for this. Alternatively, to only run the tests ensuring our XHtml output is as expected, you can run ‘cabal test html-test’. This skips the comment parser tests (which shouldn't be relevant to you) but also doesn't force you to install the test dependencies I mentioned. I haven't checked your branch yet but I ask that you add appropriate test cases in html-test. See the README in the directory for help. You might want to check the accept.lhs file to help you doing this. Lastly, note that we have been pushed something into Haddock every day since Saturday so make sure you're up to date. I'll also be pushing something today I think. Thanks
| | I am keen to get the code reviewed and into HEAD as soon as is | convenient, but I'm aware these are substantial changes, and don't want | to rush things. In particular, I would understand if you'd rather hold | them back until after the 7.8 final release. | | How would you like to proceed? | | Adam | | [1] https://github.com/adamgundry/ghc | [2] https://github.com/adamgundry/packages-base | [3] https://github.com/adamgundry/haddock | | | On 17/01/14 10:55, Simon Peyton Jones wrote: | > Yes that sounds ok, thanks. I'd prefer to have a write-up of what | goes wrong with the 2-parameter story, so that we don't forget. | > | > Simon | > | > | -----Original Message----- | > | From: Adam Gundry [mailto:adam@well-typed.com] | > | Sent: 17 January 2014 10:15 | > | To: Simon Peyton Jones | > | Subject: OverloadedRecordFields | > | | > | Hi Simon, | > | | > | I'm conscious that things have gone off the boil a little wrt | > | OverloadedRecordFields, partially as a consequence of the delayed | > | 7.8 release but also my lack of time for other projects since | > | starting work for Well-Typed. With that in mind, I'd like to propose | > | a plan to get back on track: | > | | > | 1. Revert to the three-parameter story, where we have | > | | > | t ~ FldTy r f => Has r f t | > | | > | rather than | > | | > | Has r f. | > | | > | The two-parameter version generates significantly worse error | > | messages, and there are some other unresolved problems, so I'm not | > | sure it is worth the minor simplification. | > | | > | 2. Roll back some of the refactoring that I've struggled to get | > | right (in particular, trying to make the generated FldTy/UpdTy | > | axioms implicitTyThings). We can always revisit this in the future | though. | > | | > | 3. Merge HEAD into my branch: I suspect this will be a bit painful | > | by now, but presumably with 7.8 imminent there won't be many major | > | changes coming for a while? | > | | > | 4. Review the proposed changes with you and fix any show-stopping | > | problems. | > | | > | 5. Merge into HEAD after 7.8 is released. | > | | > | Does this sound plausible? I'm happy to Skype if you like. | > | | > | Cheers, | > | | > | Adam | > | | > | P.S. I'm not sure if Andrew Kennedy has mentioned it to you, but | > | Neil Ghani has got me some funding to work with them both on units | > | of measure for Haskell. We are still sorting out the details, but I | > | hope it might be possible to work on some kind of plugin mechanism | > | for GHC's constraint solver, along the lines that Iavor has been | > | investigating, if that would be of interest? | > | | > | -- | > | Adam Gundry, Haskell Consultant | > | Well-Typed LLP, http://www.well-typed.com/ | > | | | -- | Adam Gundry, 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
-- Mateusz K.
Hi folks, Apropos of nothing, I will be talking about OverloadedRecordFields in London on Monday 28th April at 6:30pm: https://skillsmatter.com/meetups/6345-overloaded-record-fields-for-haskell I've updated my OverloadedRecordFields branches to HEAD as of today. Validate on linux x86_64 is currently failing with a few perf failures, but several appear to be intermittently present on master (see below for details). How worried should I be about these? I'd like to get this reviewed/merged as soon as possible because the changes are quite wide-ranging so they tend to bitrot quickly. The code is in the following three repositories: https://github.com/adamgundry/ghc https://github.com/adamgundry/packages-base https://github.com/adamgundry/haddock The overloaded-record-fields branches have the history (rather messy, I'm afraid) and the orf-squashed branches have everything squashed into one commit per branch. More general information is on the wiki: https://ghc.haskell.org/trac/ghc/wiki/Records/OverloadedRecordFields Cheers, Adam The perf failures on my branch are: perf/compiler T1969 [stat not good enough] (normal) perf/compiler T3064 [stat not good enough] (normal) perf/compiler T5030 [stat not good enough] (normal) perf/compiler T5837 [stat not good enough] (normal) perf/compiler T6048 [stat not good enough] (optasm) perf/haddock haddock.Cabal [stat not good enough] (normal) perf/haddock haddock.base [stat not good enough] (normal) perf/haddock haddock.compiler [stat not good enough] (normal) Those on master are: perf/compiler T1969 [stat not good enough] (normal) perf/compiler T3064 [stat not good enough] (normal) perf/compiler T5837 [stat not good enough] (normal) perf/compiler T6048 [stat not good enough] (optasm) perf/haddock haddock.Cabal [stat not good enough] (normal) Details of failures on my branch: =====> haddock.base(normal) 201 of 3977 [0, 0, 0] bytes allocated value is too high: Expected bytes allocated: 7128342344 +/-5% Lower bound bytes allocated: 6771925226 Upper bound bytes allocated: 7484759462 Actual bytes allocated: 7638726640 *** unexpected failure for haddock.base(normal) =====> haddock.Cabal(normal) 202 of 3977 [0, 1, 0] max_bytes_used value is too high: Expected max_bytes_used: 95356616 +/-15% Lower bound max_bytes_used: 81053123 Upper bound max_bytes_used: 109660109 Actual max_bytes_used: 131046008 peak_megabytes_allocated value is too high: Expected peak_megabytes_allocated: 278 +/-10% Lower bound peak_megabytes_allocated: 250 Upper bound peak_megabytes_allocated: 306 Actual peak_megabytes_allocated: 326 bytes allocated value is too high: Expected bytes allocated: 3979151552 +/-5% Lower bound bytes allocated: 3780193974 Upper bound bytes allocated: 4178109130 Actual bytes allocated: 4752508984 *** unexpected failure for haddock.Cabal(normal) =====> haddock.compiler(normal) 203 of 3977 [0, 2, 0] bytes allocated value is too high: Expected bytes allocated: 28708374824 +/-10% Lower bound bytes allocated: 25837537341 Upper bound bytes allocated: 31579212307 Actual bytes allocated: 32010912664 *** unexpected failure for haddock.compiler(normal) =====> T1969(normal) 204 of 3977 [0, 3, 0] cd ./perf/compiler && '/home/adam/Documents/Strathclyde/Code/GHC/ghc-validate/bindisttest/install dir/bin/ghc' -fforce-recomp -dno-debug-output -no-user-package-db -rtsopts -fno-ghci-history -c T1969.hs +RTS -V0 -tT1969.comp.stats --machine-readable -RTS -dcore-lint -static >T1969.comp.stderr 2>&1 max_bytes_used value is too high: Expected max_bytes_used: 11000000 +/-20% Lower bound max_bytes_used: 8800000 Upper bound max_bytes_used: 13200000 Actual max_bytes_used: 13787248 *** unexpected failure for T1969(normal) =====> T3064(normal) 207 of 3977 [0, 4, 0] cd ./perf/compiler && '/home/adam/Documents/Strathclyde/Code/GHC/ghc-validate/bindisttest/install dir/bin/ghc' -fforce-recomp -dno-debug-output -no-user-package-db -rtsopts -fno-ghci-history -c T3064.hs +RTS -V0 -tT3064.comp.stats --machine-readable -RTS >T3064.comp.stderr 2>&1 bytes allocated value is too high: Expected bytes allocated: 308422280 +/-5% Lower bound bytes allocated: 293001166 Upper bound bytes allocated: 323843394 Actual bytes allocated: 351270952 *** unexpected failure for T3064(normal) =====> T5030(normal) 209 of 3977 [0, 5, 0] cd ./perf/compiler && '/home/adam/Documents/Strathclyde/Code/GHC/ghc-validate/bindisttest/install dir/bin/ghc' -fforce-recomp -dno-debug-output -no-user-package-db -rtsopts -fno-ghci-history -c T5030.hs -fcontext-stack=300 +RTS -V0 -tT5030.comp.stats --machine-readable -RTS >T5030.comp.stderr 2>&1 =====> T5631(normal) 210 of 3977 [0, 5, 0] cd ./perf/compiler && '/home/adam/Documents/Strathclyde/Code/GHC/ghc-validate/bindisttest/install dir/bin/ghc' -fforce-recomp -dno-debug-output -no-user-package-db -rtsopts -fno-ghci-history -c T5631.hs +RTS -V0 -tT5631.comp.stats --machine-readable -RTS >T5631.comp.stderr 2>&1 bytes allocated value is too high: Expected bytes allocated: 397672152 +/-10% Lower bound bytes allocated: 357904936 Upper bound bytes allocated: 437439368 Actual bytes allocated: 474229448 *** unexpected failure for T5030(normal) =====> T5837(normal) 216 of 3977 [0, 6, 0] cd ./perf/compiler && '/home/adam/Documents/Strathclyde/Code/GHC/ghc-validate/bindisttest/install dir/bin/ghc' -fforce-recomp -dno-debug-output -no-user-package-db -rtsopts -fno-ghci-history -c T5837.hs -ftype-function-depth=50 +RTS -V0 -tT5837.comp.stats --machine-readable -RTS >T5837.comp.stderr 2>&1 bytes allocated value is too high: Expected bytes allocated: 86795752 +/-10% Lower bound bytes allocated: 78116176 Upper bound bytes allocated: 95475328 Actual bytes allocated: 96210584 *** unexpected failure for T5837(normal) =====> T6048(optasm) 217 of 3977 [0, 7, 0] cd ./perf/compiler && '/home/adam/Documents/Strathclyde/Code/GHC/ghc-validate/bindisttest/install dir/bin/ghc' -fforce-recomp -dno-debug-output -no-user-package-db -rtsopts -fno-ghci-history -c T6048.hs -O -fasm +RTS -V0 -tT6048.comp.stats --machine-readable -RTS >T6048.comp.stderr 2>&1 bytes allocated value is too high: Expected bytes allocated: 110646312 +/-10% Lower bound bytes allocated: 99581680 Upper bound bytes allocated: 121710944 Actual bytes allocated: 125707864 *** unexpected failure for T6048(optasm) Details of failures on master: =====> haddock.Cabal(normal) 202 of 3954 [0, 0, 0] bytes allocated value is too high: Expected bytes allocated: 3979151552 +/-5% Lower bound bytes allocated: 3780193974 Upper bound bytes allocated: 4178109130 Actual bytes allocated: 4212057304 *** unexpected failure for haddock.Cabal(normal) =====> T1969(normal) 204 of 3954 [0, 1, 0] cd ./perf/compiler && '/home/adam/Documents/Strathclyde/Code/GHC/ghc-validate-master/bindisttest/install dir/bin/ghc' -fforce-recomp -dno-debug-output -no-user-package-db -rtsopts -fno-ghci-history -c T1969.hs +RTS -V0 -tT1969.comp.stats --machine-readable -RTS -dcore-lint -static >T1969.comp.stderr 2>&1 max_bytes_used value is too high: Expected max_bytes_used: 11000000 +/-20% Lower bound max_bytes_used: 8800000 Upper bound max_bytes_used: 13200000 Actual max_bytes_used: 13662736 *** unexpected failure for T1969(normal) =====> T3064(normal) 207 of 3954 [0, 2, 0] cd ./perf/compiler && '/home/adam/Documents/Strathclyde/Code/GHC/ghc-validate-master/bindisttest/install dir/bin/ghc' -fforce-recomp -dno-debug-output -no-user-package-db -rtsopts -fno-ghci-history -c T3064.hs +RTS -V0 -tT3064.comp.stats --machine-readable -RTS >T3064.comp.stderr 2>&1 =====> T4007(normal) 208 of 3954 [0, 2, 0] cd ./perf/compiler && $MAKE -s --no-print-directory T4007
T4007.run.stdout 2>T4007.run.stderr bytes allocated value is too high: Expected bytes allocated: 308422280 +/-5% Lower bound bytes allocated: 293001166 Upper bound bytes allocated: 323843394 Actual bytes allocated: 331042056 *** unexpected failure for T3064(normal)
=====> T5837(normal) 216 of 3954 [0, 3, 0] cd ./perf/compiler && '/home/adam/Documents/Strathclyde/Code/GHC/ghc-validate-master/bindisttest/install dir/bin/ghc' -fforce-recomp -dno-debug-output -no-user-package-db -rtsopts -fno-ghci-history -c T5837.hs -ftype-function-depth=50 +RTS -V0 -tT5837.comp.stats --machine-readable -RTS >T5837.comp.stderr 2>&1 bytes allocated value is too high: Expected bytes allocated: 86795752 +/-10% Lower bound bytes allocated: 78116176 Upper bound bytes allocated: 95475328 Actual bytes allocated: 95994280 *** unexpected failure for T5837(normal) =====> T6048(optasm) 217 of 3954 [0, 4, 0] cd ./perf/compiler && '/home/adam/Documents/Strathclyde/Code/GHC/ghc-validate-master/bindisttest/install dir/bin/ghc' -fforce-recomp -dno-debug-output -no-user-package-db -rtsopts -fno-ghci-history -c T6048.hs -O -fasm +RTS -V0 -tT6048.comp.stats --machine-readable -RTS >T6048.comp.stderr 2>&1 bytes allocated value is too high: Expected bytes allocated: 110646312 +/-10% Lower bound bytes allocated: 99581680 Upper bound bytes allocated: 121710944 Actual bytes allocated: 124431616 *** unexpected failure for T6048(optasm) On 25/02/14 16:18, Simon Peyton Jones wrote:
Adam
I'm very happy to hear that... good stuff.
I'm under water with ICFP submissions (deadline Sat). Moreover I think it is clearly too later to put this into 7.8; RC1 is out and I expect RC2 any day.
So I suggest we plan to merge after 7.8 is out.
Are the wiki pages up to date? Records/OverloadedRecordFields Records/OverloadedRecordFields/Implementation Records/OverloadedRecordFields/Plan
The first does not point to the latter two; "Plan" may mean "Design"... I feel some rationalisation may make sense
Simon
| -----Original Message----- | From: Adam Gundry [mailto:adam@well-typed.com] | Sent: 24 February 2014 08:37 | To: Simon Peyton Jones | Subject: Re: OverloadedRecordFields | | Hi Simon, | | My OverloadedRecordFields branches[1,2,3] are up to date with HEAD as of | last Saturday. Validate on linux x86_64 reports only one failure, the | haddock.Cabal perf test, which might well be due to my Haddock changes, | and I will investigate. I'm not sure how to run the Haddock test suite? | | I am keen to get the code reviewed and into HEAD as soon as is | convenient, but I'm aware these are substantial changes, and don't want | to rush things. In particular, I would understand if you'd rather hold | them back until after the 7.8 final release. | | How would you like to proceed? | | Adam | | [1] https://github.com/adamgundry/ghc | [2] https://github.com/adamgundry/packages-base | [3] https://github.com/adamgundry/haddock
-- Adam Gundry, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/
participants (4)
-
Adam Gundry -
Herbert Valerio Riedel -
Mateusz Kowalczyk -
Simon Peyton Jones