GHC issueshttps://gitlab.haskell.org/ghc/ghc/-/issues2019-07-07T18:38:03Zhttps://gitlab.haskell.org/ghc/ghc/-/issues/9984Show, Read, Eq, Ord instances for Control.Applicative.Const2019-07-07T18:38:03ZFumiaki KinoshitaShow, Read, Eq, Ord instances for Control.Applicative.ConstAs mentioned in https://www.haskell.org/pipermail/libraries/2013-October/021531.html, the following instances can be derived clearly:
- `Show a => Show (Const a b)`
- `Read a => Read (Const a b)`
- `Eq a => Eq (Const a b)`
- `Ord a => O...As mentioned in https://www.haskell.org/pipermail/libraries/2013-October/021531.html, the following instances can be derived clearly:
- `Show a => Show (Const a b)`
- `Read a => Read (Const a b)`
- `Eq a => Eq (Const a b)`
- `Ord a => Ord (Const a b)`
The absence of these instances makes debugging harder.
I suggest handcrafted Show/Read instances for neat representation.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 7.8.4 |
| Type | FeatureRequest |
| TypeOfFailure | OtherFailure |
| Priority | low |
| Resolution | Unresolved |
| Component | libraries/base |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | ekmett, hvr |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Show, Read, Eq, Ord instances for Control.Applicative.Const","status":"New","operating_system":"","component":"libraries/base","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.8.4","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":["ekmett","hvr"],"type":"FeatureRequest","description":"As mentioned in https://www.haskell.org/pipermail/libraries/2013-October/021531.html, the following instances can be derived clearly:\r\n\r\n* `Show a => Show (Const a b)`\r\n* `Read a => Read (Const a b)`\r\n* `Eq a => Eq (Const a b)`\r\n* `Ord a => Ord (Const a b)`\r\n\r\nThe absence of these instances makes debugging harder.\r\n\r\nI suggest handcrafted Show/Read instances for neat representation.","type_of_failure":"OtherFailure","blocking":[]} -->7.10.1https://gitlab.haskell.org/ghc/ghc/-/issues/9807Only test for bug #9439 when llvm is installed2019-07-07T18:38:58ZihmccreeryOnly test for bug #9439 when llvm is installedWhen running `./configure` to build GHC, and `opt` is not found, the current output is:
> \<no location info\>:
> Warning: Couldn't figure out LLVM version!
> Make sure you have installed LLVM
> ghc: could not execute: opt
> failed to c...When running `./configure` to build GHC, and `opt` is not found, the current output is:
> \<no location info\>:
> Warning: Couldn't figure out LLVM version!
> Make sure you have installed LLVM
> ghc: could not execute: opt
> failed to compile
When I first saw this, I thought that this was causing the entire compiler build to fail. To clarify that this isn't a critical error, should it be something more like:
> checking for llvm... no
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ---------------- |
| Version | 7.8.3 |
| Type | FeatureRequest |
| TypeOfFailure | DocumentationBug |
| Priority | low |
| Resolution | Unresolved |
| Component | Build System |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Clarify warning if LLVM is not found by configure","status":"New","operating_system":"","component":"Build System","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.8.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"FeatureRequest","description":"When running `./configure` to build GHC, and `opt` is not found, the current output is:\r\n\r\n> <no location info>:\r\n> Warning: Couldn't figure out LLVM version!\r\n> Make sure you have installed LLVM\r\n> ghc: could not execute: opt\r\n> failed to compile\r\n\r\nWhen I first saw this, I thought that this was causing the entire compiler build to fail. To clarify that this isn't a critical error, should it be something more like:\r\n\r\n> checking for llvm... no","type_of_failure":"DocumentationBug","blocking":[]} -->7.10.1https://gitlab.haskell.org/ghc/ghc/-/issues/9619HPC Code Coverage complains when two exactly the same mix files are on the path2019-07-07T18:39:47ZKasperHPC Code Coverage complains when two exactly the same mix files are on the pathCabal's --enable-library-coverage flag generates the .mix files in the dist/mix directory that cabal creates during compilation. I have two test suites, integration tests and unit tests. Those test suites calll tests for moduleA in modul...Cabal's --enable-library-coverage flag generates the .mix files in the dist/mix directory that cabal creates during compilation. I have two test suites, integration tests and unit tests. Those test suites calll tests for moduleA in moduleATest. Unfortunately, in a first version, the integration tests and unit tests for moduleA were both present in moduleATest. Therefore, the unit test suite (in UnitTests.hs) and the integration test suite (in IntegrationTests.hs) both 'use' the moduleATest by linking in tests from that module. This leads to cabal generating a directory integration-tests and a directory unit-tests with .mix files, but the moduleATest.mix file is present in both directories. When performing hpc sum and hpc markup to get the total result of the test runs I need to specify the directories where the mix files are present (so dist/hpc/mix/unit-tests and dist/hpc/mix/integration-tests) and it will then complain that it finds moduleATest.mix file twice.
This issue is not present when using the -fhpc flag, as the directory structure with integration-tests and unit-tests is not present in the .hpc directory at that moment. That being said, I don't think it's a cabal issue as it's more or less expected what they're doing, generating the mix files necessary to instrument integration-tests and unit-tests separately.
Priority put to lowest because I can work around it by diving moduleATest up in moduleATest and moduleAIntegrationTest, which is saner in the end anyway. But I guess somebody will come up with a use case where a split up isn't possible, in the future.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------- |
| Version | 7.8.3 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | lowest |
| Resolution | Unresolved |
| Component | Code Coverage |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"HPC Code Coverage complains when two exactly the same mix files are on the path","status":"New","operating_system":"","component":"Code Coverage","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.8.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Cabal's --enable-library-coverage flag generates the .mix files in the dist/mix directory that cabal creates during compilation. I have two test suites, integration tests and unit tests. Those test suites calll tests for moduleA in moduleATest. Unfortunately, in a first version, the integration tests and unit tests for moduleA were both present in moduleATest. Therefore, the unit test suite (in UnitTests.hs) and the integration test suite (in IntegrationTests.hs) both 'use' the moduleATest by linking in tests from that module. This leads to cabal generating a directory integration-tests and a directory unit-tests with .mix files, but the moduleATest.mix file is present in both directories. When performing hpc sum and hpc markup to get the total result of the test runs I need to specify the directories where the mix files are present (so dist/hpc/mix/unit-tests and dist/hpc/mix/integration-tests) and it will then complain that it finds moduleATest.mix file twice.\r\n\r\n\r\nThis issue is not present when using the -fhpc flag, as the directory structure with integration-tests and unit-tests is not present in the .hpc directory at that moment. That being said, I don't think it's a cabal issue as it's more or less expected what they're doing, generating the mix files necessary to instrument integration-tests and unit-tests separately. \r\n\r\nPriority put to lowest because I can work around it by diving moduleATest up in moduleATest and moduleAIntegrationTest, which is saner in the end anyway. But I guess somebody will come up with a use case where a split up isn't possible, in the future.","type_of_failure":"OtherFailure","blocking":[]} -->7.10.1https://gitlab.haskell.org/ghc/ghc/-/issues/9449GHC.Prim documentation says "Safe Inferred"2019-07-07T18:40:21ZRichard Eisenbergrae@richarde.devGHC.Prim documentation says "Safe Inferred"The Haddock docs for GHC.Prim (for example, [here](http://haddocks.fpcomplete.com/fp/7.7/20131212-1/ghc-prim/GHC-Prim.html)) says that it is Safe-Inferred. This is very bogus.
When testing, I was (happily) unable to import `GHC.Prim` in...The Haddock docs for GHC.Prim (for example, [here](http://haddocks.fpcomplete.com/fp/7.7/20131212-1/ghc-prim/GHC-Prim.html)) says that it is Safe-Inferred. This is very bogus.
When testing, I was (happily) unable to import `GHC.Prim` into a `Safe` module, so I think this is just a documentation bug.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------- |
| Version | 7.8.2 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | low |
| Resolution | Unresolved |
| Component | Documentation |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"GHC.Prim documentation says \"Safe Inferred\"","status":"New","operating_system":"","component":"Documentation","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.8.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"The Haddock docs for GHC.Prim (for example, [http://haddocks.fpcomplete.com/fp/7.7/20131212-1/ghc-prim/GHC-Prim.html here]) says that it is Safe-Inferred. This is very bogus.\r\n\r\nWhen testing, I was (happily) unable to import `GHC.Prim` into a `Safe` module, so I think this is just a documentation bug.","type_of_failure":"OtherFailure","blocking":[]} -->7.10.1thoughtpolicethoughtpolicehttps://gitlab.haskell.org/ghc/ghc/-/issues/9317Add PolyKinds extension to Data.Monoid2019-07-07T18:40:55ZbernalexAdd PolyKinds extension to Data.MonoidPolyKinds got lost in 1d1ff77aaa09efaddc8cfe0dcf92d6763297cf11. See discussion here: \<http://www.haskell.org/pipermail/libraries/2014-July/023261.html\>.
<details><summary>Trac metadata</summary>
| Trac field | Value ...PolyKinds got lost in 1d1ff77aaa09efaddc8cfe0dcf92d6763297cf11. See discussion here: \<http://www.haskell.org/pipermail/libraries/2014-July/023261.html\>.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 7.8.2 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | low |
| Resolution | Unresolved |
| Component | libraries/base |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | ekmett, hvr |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Add PolyKinds extension to Data.Monoid","status":"New","operating_system":"","component":"libraries/base","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.8.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":["ekmett","hvr"],"type":"Bug","description":"PolyKinds got lost in 1d1ff77aaa09efaddc8cfe0dcf92d6763297cf11. See discussion here: <http://www.haskell.org/pipermail/libraries/2014-July/023261.html>.","type_of_failure":"OtherFailure","blocking":[]} -->7.10.1https://gitlab.haskell.org/ghc/ghc/-/issues/9067Optimize clearNursery by short-circuiting when we get to currentNursery2019-07-07T18:42:04ZEdward Z. YangOptimize clearNursery by short-circuiting when we get to currentNurseryThis is a note to myself so I don't forget about this. Essentially, we can do something like this (this particular patch variant untested):
```
diff --git a/rts/sm/Storage.c b/rts/sm/Storage.c
index 36776b9..0311042 100644
--- a/rts/sm/...This is a note to myself so I don't forget about this. Essentially, we can do something like this (this particular patch variant untested):
```
diff --git a/rts/sm/Storage.c b/rts/sm/Storage.c
index 36776b9..0311042 100644
--- a/rts/sm/Storage.c
+++ b/rts/sm/Storage.c
@@ -598,6 +598,11 @@ clearNursery (Capability *cap)
ASSERT(bd->gen_no == 0);
ASSERT(bd->gen == g0);
IF_DEBUG(sanity,memset(bd->start, 0xaa, BLOCK_SIZE));
+ if (bd == cap->r.rCurrentNursery) {
+ IF_DEBUG(sanity, for (bd = bd->link; bd; bd = bd->link)
+ ASSERT(bd->free == bd->start));
+ break;
+ }
}
}
}
```
This is due to invariants about how we manage the currentNursery pointer. But we need a note about it, and I need to test it more carefully. This optimization probably doesn't help too much on normal GHC, but when I have lots of nurseries it helps quite a bit.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 7.9 |
| Type | Task |
| TypeOfFailure | OtherFailure |
| Priority | low |
| Resolution | Unresolved |
| Component | Runtime System |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | simonmar |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Optimize clearNursery by short-circuiting when we get to currentNursery","status":"New","operating_system":"","component":"Runtime System","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"OwnedBy","contents":"ezyang"},"version":"7.9","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":["simonmar"],"type":"Task","description":"This is a note to myself so I don't forget about this. Essentially, we can do something like this (this particular patch variant untested):\r\n\r\n{{{\r\ndiff --git a/rts/sm/Storage.c b/rts/sm/Storage.c\r\nindex 36776b9..0311042 100644\r\n--- a/rts/sm/Storage.c\r\n+++ b/rts/sm/Storage.c\r\n@@ -598,6 +598,11 @@ clearNursery (Capability *cap)\r\n ASSERT(bd->gen_no == 0);\r\n ASSERT(bd->gen == g0);\r\n IF_DEBUG(sanity,memset(bd->start, 0xaa, BLOCK_SIZE));\r\n+ if (bd == cap->r.rCurrentNursery) {\r\n+ IF_DEBUG(sanity, for (bd = bd->link; bd; bd = bd->link)\r\n+ ASSERT(bd->free == bd->start));\r\n+ break;\r\n+ }\r\n }\r\n }\r\n }\r\n}}}\r\n\r\nThis is due to invariants about how we manage the currentNursery pointer. But we need a note about it, and I need to test it more carefully. This optimization probably doesn't help too much on normal GHC, but when I have lots of nurseries it helps quite a bit.","type_of_failure":"OtherFailure","blocking":[]} -->7.10.1Edward Z. YangEdward Z. Yanghttps://gitlab.haskell.org/ghc/ghc/-/issues/9057Remove /usr/bin/… references2019-07-07T18:42:07ZMateusz KowalczykRemove /usr/bin/… referencesThe use of /usr/bin/perl in sync-all makes it difficult to work with on distros which don't store binaries in /usr/bin, such as NixOS.
A more portable solution would be to use /usr/bin/env perl. It'd be very nice if someone turned such ...The use of /usr/bin/perl in sync-all makes it difficult to work with on distros which don't store binaries in /usr/bin, such as NixOS.
A more portable solution would be to use /usr/bin/env perl. It'd be very nice if someone turned such shebangs to use env rather than direct reference.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 7.8.2 |
| Type | Task |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Build System |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Remove /usr/bin/… references","status":"New","operating_system":"","component":"Build System","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.8.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Task","description":"The use of /usr/bin/perl in sync-all makes it difficult to work with on distros which don't store binaries in /usr/bin, such as NixOS. \r\n\r\nA more portable solution would be to use /usr/bin/env perl. It'd be very nice if someone turned such shebangs to use env rather than direct reference.","type_of_failure":"OtherFailure","blocking":[]} -->7.10.1https://gitlab.haskell.org/ghc/ghc/-/issues/8873/cygdrive/c/Program Files (x86)/Haskell Platform/2013.2.0.0/bin/ghcii-7.6.3.s...2019-07-07T18:43:00Zconfigurator/cygdrive/c/Program Files (x86)/Haskell Platform/2013.2.0.0/bin/ghcii-7.6.3.sh/../ghc: No such file or directoryThe paths used in the `ghcii.sh` scripts to start `ghc --interactive`
are incorrectly built using `"$0"/..`, which causes the message:
```
/cygdrive/c/Program Files (x86)/Haskell Platform/2013.2.0.0/bin/ghcii-7.6.3.sh: line 2: /cygdriv...The paths used in the `ghcii.sh` scripts to start `ghc --interactive`
are incorrectly built using `"$0"/..`, which causes the message:
```
/cygdrive/c/Program Files (x86)/Haskell Platform/2013.2.0.0/bin/ghcii-7.6.3.sh: line 2: /cygdrive/c/Program Files (x86)/Haskell Platform/2013.2.0.0/bin/ghcii-7.6.3.sh/../ghc: No such file or directory
/cygdrive/c/Program Files (x86)/Haskell Platform/2013.2.0.0/bin/ghcii-7.6.3.sh: line 2: exec: /cygdrive/c/Program Files (x86)/Haskell Platform/2013.2.0.0/bin/ghcii-7.6.3.sh/../ghc: cannot execute: No such file or directory
```
I believe using `"$(dirname "$0")"` would be a portable solution that works under both cygwin and Linux versions of bash.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 7.6.3 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | low |
| Resolution | Unresolved |
| Component | GHCi |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | hvr |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"/cygdrive/c/Program Files (x86)/Haskell Platform/2013.2.0.0/bin/ghcii-7.6.3.sh/../ghc: No such file or directory","status":"New","operating_system":"","component":"GHCi","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.6.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":["hvr"],"type":"Bug","description":"The paths used in the {{{ghcii.sh}}} scripts to start {{{ghc --interactive}}}\r\n are incorrectly built using {{{\"$0\"/..}}}, which causes the message:\r\n\r\n{{{\r\n/cygdrive/c/Program Files (x86)/Haskell Platform/2013.2.0.0/bin/ghcii-7.6.3.sh: line 2: /cygdrive/c/Program Files (x86)/Haskell Platform/2013.2.0.0/bin/ghcii-7.6.3.sh/../ghc: No such file or directory\r\n/cygdrive/c/Program Files (x86)/Haskell Platform/2013.2.0.0/bin/ghcii-7.6.3.sh: line 2: exec: /cygdrive/c/Program Files (x86)/Haskell Platform/2013.2.0.0/bin/ghcii-7.6.3.sh/../ghc: cannot execute: No such file or directory\r\n}}}\r\n\r\nI believe using {{{\"$(dirname \"$0\")\"}}} would be a portable solution that works under both cygwin and Linux versions of bash.","type_of_failure":"OtherFailure","blocking":[]} -->7.10.1https://gitlab.haskell.org/ghc/ghc/-/issues/8861Use commas to separate thousands when printing memory stats2019-07-07T18:43:03ZErlendHUse commas to separate thousands when printing memory statsIn GHCi, by enabling printing of timing/memory stats after each evaluation (`:set +s`), the memory stats is printed in bytes. When this number is quite large, it's hard to see – at a glance – how much memory was used.
It would be nicer i...In GHCi, by enabling printing of timing/memory stats after each evaluation (`:set +s`), the memory stats is printed in bytes. When this number is quite large, it's hard to see – at a glance – how much memory was used.
It would be nicer if this was printed as “1,200,000 bytes” instead of “1200000 bytes” as is the case now.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 7.6.3 |
| Type | FeatureRequest |
| TypeOfFailure | OtherFailure |
| Priority | lowest |
| Resolution | Unresolved |
| Component | GHCi |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | hvr |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Use commas to separate thousands when printing memory stats","status":"New","operating_system":"","component":"GHCi","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.6.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":["hvr"],"type":"FeatureRequest","description":"In GHCi, by enabling printing of timing/memory stats after each evaluation (`:set +s`), the memory stats is printed in bytes. When this number is quite large, it's hard to see – at a glance – how much memory was used.\r\nIt would be nicer if this was printed as “1,200,000 bytes” instead of “1200000 bytes” as is the case now.","type_of_failure":"OtherFailure","blocking":[]} -->7.10.1https://gitlab.haskell.org/ghc/ghc/-/issues/8742Reuse scavenge_small_bitmap2019-07-07T18:43:41ZTarraschReuse scavenge_small_bitmapHi, I've found that the `scavenge_small_bitmap` is in-lined at two places. I added this patch to remove code duplication.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ...Hi, I've found that the `scavenge_small_bitmap` is in-lined at two places. I added this patch to remove code duplication.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 7.6.3 |
| Type | Task |
| TypeOfFailure | OtherFailure |
| Priority | lowest |
| Resolution | Unresolved |
| Component | Runtime System |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | simonmar |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Reuse scavenge_small_bitmap","status":"New","operating_system":"","component":"Runtime System","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"OwnedBy","contents":"simonmar"},"version":"7.6.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":["simonmar"],"type":"Task","description":"Hi, I've found that the `scavenge_small_bitmap` is in-lined at two places. I added this patch to remove code duplication.","type_of_failure":"OtherFailure","blocking":[]} -->7.10.1TarraschTarraschhttps://gitlab.haskell.org/ghc/ghc/-/issues/7863Verbosity level for quieter Template Haskell2019-07-07T18:47:46ZdolioVerbosity level for quieter Template HaskellIn projects with large numbers of dependencies, use of template haskell can cause very large amounts of output that aren't particularly interesting. However, it seems that the only verbosity level that quiets template haskell output is -...In projects with large numbers of dependencies, use of template haskell can cause very large amounts of output that aren't particularly interesting. However, it seems that the only verbosity level that quiets template haskell output is -v0, which also turns off normal indications of build progress. It would be pleasant to have a way to turn off template haskell loading messages while retaining the rest of -v1 output.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ---------------- |
| Version | 7.6.3 |
| Type | FeatureRequest |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Template Haskell |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Verbosity level for quieter Template Haskell","status":"New","operating_system":"","component":"Template Haskell","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.6.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"FeatureRequest","description":"In projects with large numbers of dependencies, use of template haskell can cause very large amounts of output that aren't particularly interesting. However, it seems that the only verbosity level that quiets template haskell output is -v0, which also turns off normal indications of build progress. It would be pleasant to have a way to turn off template haskell loading messages while retaining the rest of -v1 output.","type_of_failure":"OtherFailure","blocking":[]} -->7.10.1Herbert Valerio Riedelhvr@gnu.orgHerbert Valerio Riedelhvr@gnu.orghttps://gitlab.haskell.org/ghc/ghc/-/issues/5608Fix T3807 for Mac OS X 10.52019-07-07T18:54:29ZthorkilnaurFix T3807 for Mac OS X 10.5Attached patch fixes (http://darcs.haskell.org/ghcBuilder/builders/tn23/479/11.html):
```
=====> T3807(normal) 591 of 3083 [0, 0, 1]
cd ./dynlibs && $MAKE --no-print-directory -s T3807 </dev/null >T3807.run.stdout 2>T3807.run.stderr
Wro...Attached patch fixes (http://darcs.haskell.org/ghcBuilder/builders/tn23/479/11.html):
```
=====> T3807(normal) 591 of 3083 [0, 0, 1]
cd ./dynlibs && $MAKE --no-print-directory -s T3807 </dev/null >T3807.run.stdout 2>T3807.run.stderr
Wrong exit code (expected 0 , actual 2 )
Stdout:
Failed to open shared library: dlopen(./T3807test.so, 10): Symbol not found: ___gmp_set_memory_functions
Referenced from: /Users/thorkilnaur/tn/builders/GHCBuilder/tn23/builder/tempbuild/build/bindisttest/install dir/lib/ghc-7.3.20111106/integer-gmp-0.3.0.0/libHSinteger-gmp-0.3.0.0-ghc7.3.20111106.dylib
Expected in: dynamic lookup
Stderr:
make[3]: *** [T3807] Error 1
*** unexpected failure for T3807(normal)
```
Validates on
```
$ uname -a
Darwin thorkil-naurs-intel-mac-mini.local 9.8.0 Darwin Kernel Version 9.8.0: Wed Jul 15 16:55:01 PDT 2009; root:xnu-1228.15.4~1/RELEASE_I386 i386
$ ghc --version
The Glorious Glasgow Haskell Compilation System, version 6.12.3
$
```
and
```
$ uname -a
Linux tn24 2.6.32-34-generic #77-Ubuntu SMP Tue Sep 13 19:40:53 UTC 2011 i686 GNU/Linux
$ ghc --version
The Glorious Glasgow Haskell Compilation System, version 6.12.3
$
```
Best regards
Thorkil
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 7.3 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Test Suite |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Fix T3807 for Mac OS X 10.5","status":"New","operating_system":"","component":"Test Suite","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Attached patch fixes (http://darcs.haskell.org/ghcBuilder/builders/tn23/479/11.html):\r\n{{{\r\n=====> T3807(normal) 591 of 3083 [0, 0, 1]\r\ncd ./dynlibs && $MAKE --no-print-directory -s T3807 </dev/null >T3807.run.stdout 2>T3807.run.stderr\r\nWrong exit code (expected 0 , actual 2 )\r\nStdout:\r\nFailed to open shared library: dlopen(./T3807test.so, 10): Symbol not found: ___gmp_set_memory_functions\r\nReferenced from: /Users/thorkilnaur/tn/builders/GHCBuilder/tn23/builder/tempbuild/build/bindisttest/install dir/lib/ghc-7.3.20111106/integer-gmp-0.3.0.0/libHSinteger-gmp-0.3.0.0-ghc7.3.20111106.dylib\r\nExpected in: dynamic lookup\r\nStderr:\r\nmake[3]: *** [T3807] Error 1\r\n*** unexpected failure for T3807(normal)\r\n}}}\r\nValidates on\r\n{{{\r\n$ uname -a\r\nDarwin thorkil-naurs-intel-mac-mini.local 9.8.0 Darwin Kernel Version 9.8.0: Wed Jul 15 16:55:01 PDT 2009; root:xnu-1228.15.4~1/RELEASE_I386 i386\r\n$ ghc --version\r\nThe Glorious Glasgow Haskell Compilation System, version 6.12.3\r\n$ \r\n}}}\r\nand\r\n{{{\r\n$ uname -a\r\nLinux tn24 2.6.32-34-generic #77-Ubuntu SMP Tue Sep 13 19:40:53 UTC 2011 i686 GNU/Linux\r\n$ ghc --version\r\nThe Glorious Glasgow Haskell Compilation System, version 6.12.3\r\n$ \r\n}}}\r\nBest regards\r\nThorkil","type_of_failure":"OtherFailure","blocking":[]} -->7.10.1https://gitlab.haskell.org/ghc/ghc/-/issues/5248Infer type context in a type signature2019-07-07T18:56:12ZgidynInfer type context in a type signatureIf I have code such as
```
class Foo f where
foo :: a -> f a
data Bar f a = Foo f => Bar {bar :: f a}
instance Foo (Bar f) where
foo a = Bar (foo a)
```
GHC will demand `Foo f =>` on the instance declaration, even though this...If I have code such as
```
class Foo f where
foo :: a -> f a
data Bar f a = Foo f => Bar {bar :: f a}
instance Foo (Bar f) where
foo a = Bar (foo a)
```
GHC will demand `Foo f =>` on the instance declaration, even though this can be inferred from the definition of Bar.
I understand *why* this is happening, but it should not be necessary to repeat information already given. Some code violates DRY dozens of times because of this limitation.7.10.1https://gitlab.haskell.org/ghc/ghc/-/issues/5190TinyCoreLinux extension2019-07-07T18:56:29Zjosemaria.alkalaTinyCoreLinux extensionI am trying to create a GHC package for TinyCoreLinux http://www.tinycorelinux.com (this is a 10Mbytes linux distribution)
I have downloaded the general binary:
http://haskell.org/ghc/dist/7.0.3/ghc-7.0.3-i386-unknown-linux.tar.bz2
Whe...I am trying to create a GHC package for TinyCoreLinux http://www.tinycorelinux.com (this is a 10Mbytes linux distribution)
I have downloaded the general binary:
http://haskell.org/ghc/dist/7.0.3/ghc-7.0.3-i386-unknown-linux.tar.bz2
When I execute: ./configure, I get:
checking for path to top of build tree... ghc-pwd: mkTextEncoding: invalid argument (Invalid argument)
configure: error: cannot determine current directory
As a disclaimer, I am not a developer!
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ----------------- |
| Version | 7.0.3 |
| Type | Bug |
| TypeOfFailure | BuildingGhcFailed |
| Priority | normal |
| Resolution | Unresolved |
| Component | Build System |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"TinyCoreLinux extension","status":"New","operating_system":"","component":"Build System","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.0.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"I am trying to create a GHC package for TinyCoreLinux http://www.tinycorelinux.com (this is a 10Mbytes linux distribution)\r\n\r\nI have downloaded the general binary:\r\nhttp://haskell.org/ghc/dist/7.0.3/ghc-7.0.3-i386-unknown-linux.tar.bz2\r\n\r\nWhen I execute: ./configure, I get:\r\nchecking for path to top of build tree... ghc-pwd: mkTextEncoding: invalid argument (Invalid argument)\r\nconfigure: error: cannot determine current directory\r\n\r\nAs a disclaimer, I am not a developer!","type_of_failure":"BuildingGhcFailed","blocking":[]} -->7.10.1https://gitlab.haskell.org/ghc/ghc/-/issues/4921report ambiguous type variables more consistently2019-07-07T18:57:55ZSaizanreport ambiguous type variables more consistently```
{-# LANGUAGE MultiParamTypeClasses #-}
module Amb where ...```
{-# LANGUAGE MultiParamTypeClasses #-}
module Amb where
class C a b where
f :: (a,b)
instance C Int Char where
f = undefined
{-
x = fst f
/home/saizan/snippets/Amb.hs:7:8:
Ambiguous type variables `a', `b' in the constraint:
`C a b'
arising from a use of `f' at /home/saizan/snippets/Amb.hs:7:8
Possible cause: the monomorphism restriction applied to the following:
x :: a (bound at /home/saizan/snippets/Amb.hs:7:0)
Probable fix: give these definition(s) an explicit type signature
or use -XNoMonomorphismRestriction
Failed, modules loaded: none.
-}
{-
y = fst f :: Int
/home/saizan/snippets/Amb.hs:21:8:
No instance for (C Int b)
arising from a use of `f' at /home/saizan/snippets/Amb.hs:21:8
Possible fix: add an instance declaration for (C Int b)
In the first argument of `fst', namely `f'
In the expression: fst f :: Int
In the definition of `y': y = fst f :: Int
Failed, modules loaded: none.
-}
```
Both x and y have the same problem, there isn't enough type information to let the typechecker decide on an instance, so it seems they should produce similar error messages.
In particular, the error for y is quite confusing since it can be reasonably interpreted as saying there's no type b for which there's an instance C Int b, which in fact is not true, so i think explicitly mentioning the ambiguity like in the first message would help many to understand the problem better.
I can see though that an "instance C Int b" could make sense, more often than C a b, so maybe "Possible fix: add an instance declaration for (C Int b)" should be conserved, even if it still has the problem of expressing that the second argument needs to be a variable.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 7.0.1 |
| Type | FeatureRequest |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"report ambiguous type variables more consistently","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.0.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"FeatureRequest","description":"{{{\r\n{-# LANGUAGE MultiParamTypeClasses #-} \r\nmodule Amb where \r\n \r\nclass C a b where \r\n f :: (a,b) \r\n \r\ninstance C Int Char where \r\n f = undefined \r\n \r\n{- \r\nx = fst f \r\n/home/saizan/snippets/Amb.hs:7:8: \r\n Ambiguous type variables `a', `b' in the constraint: \r\n `C a b' \r\n arising from a use of `f' at /home/saizan/snippets/Amb.hs:7:8 \r\n Possible cause: the monomorphism restriction applied to the following: \r\n x :: a (bound at /home/saizan/snippets/Amb.hs:7:0) \r\n Probable fix: give these definition(s) an explicit type signature \r\n or use -XNoMonomorphismRestriction \r\nFailed, modules loaded: none. \r\n-} \r\n \r\n{- \r\ny = fst f :: Int \r\n \r\n/home/saizan/snippets/Amb.hs:21:8: \r\n No instance for (C Int b) \r\n arising from a use of `f' at /home/saizan/snippets/Amb.hs:21:8 \r\n Possible fix: add an instance declaration for (C Int b) \r\n In the first argument of `fst', namely `f' \r\n In the expression: fst f :: Int \r\n In the definition of `y': y = fst f :: Int \r\nFailed, modules loaded: none. \r\n-}\r\n}}}\r\n\r\nBoth x and y have the same problem, there isn't enough type information to let the typechecker decide on an instance, so it seems they should produce similar error messages.\r\n\r\nIn particular, the error for y is quite confusing since it can be reasonably interpreted as saying there's no type b for which there's an instance C Int b, which in fact is not true, so i think explicitly mentioning the ambiguity like in the first message would help many to understand the problem better.\r\n\r\nI can see though that an \"instance C Int b\" could make sense, more often than C a b, so maybe \"Possible fix: add an instance declaration for (C Int b)\" should be conserved, even if it still has the problem of expressing that the second argument needs to be a variable.","type_of_failure":"OtherFailure","blocking":[]} -->7.10.1https://gitlab.haskell.org/ghc/ghc/-/issues/4896Deriving Data does not work for attached code2019-07-07T18:58:00ZmitarDeriving Data does not work for attached codeI get the following error when I try to derive `Data` for the attached code:
```
Main.hs:17:66:
Couldn't match expected type `Bar (D a b)'
with actual type `t' a1 b1'
Expected type: Maybe (c (Bar (D a b)))
...I get the following error when I try to derive `Data` for the attached code:
```
Main.hs:17:66:
Couldn't match expected type `Bar (D a b)'
with actual type `t' a1 b1'
Expected type: Maybe (c (Bar (D a b)))
Actual type: Maybe (c (t' a1 b1))
In the expression: gcast2 f
In an equation for `dataCast2': dataCast2 f = gcast2 f
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ---------------- |
| Version | 7.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | mmitar@gmail.com |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Deriving Data does not work for attached code","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":["mmitar@gmail.com"],"type":"Bug","description":"I get the following error when I try to derive `Data` for the attached code:\r\n\r\n{{{\r\nMain.hs:17:66:\r\n Couldn't match expected type `Bar (D a b)'\r\n with actual type `t' a1 b1'\r\n Expected type: Maybe (c (Bar (D a b)))\r\n Actual type: Maybe (c (t' a1 b1))\r\n In the expression: gcast2 f\r\n In an equation for `dataCast2': dataCast2 f = gcast2 f\r\n}}}\r\n","type_of_failure":"OtherFailure","blocking":[]} -->7.10.1https://gitlab.haskell.org/ghc/ghc/-/issues/4366in-tree GMP build problem with shared libraries2020-02-07T13:07:19ZSimon Marlowin-tree GMP build problem with shared librariesReported by Vivian McPhail \<haskell.vivian.mcphail\@gmail.com\> on glasgow-haskell-users:
```
Trying to build rc1 from source
linux x86_64
BuildFlavour = perf
It seems that the -fPIC flag is set, but an error still occurs (
/usr/bin/...Reported by Vivian McPhail \<haskell.vivian.mcphail\@gmail.com\> on glasgow-haskell-users:
```
Trying to build rc1 from source
linux x86_64
BuildFlavour = perf
It seems that the -fPIC flag is set, but an error still occurs (
/usr/bin/ld: libraries/integer-gmp/gmp/objs/abs.o: relocation R_X86_64_32 against `.text' can not be used when making a shared object; recompile with -fPIC
)
"inplace/bin/ghc-stage1" -fPIC -dynamic -O -H64m -package-name base-4.3.0.0 -hide-all-packages -i -ilibraries/base/. -ilibraries/base/dist-install/build -ilibraries/base/dist-install/build/autogen -Ilibraries/base/dist-install/build -Ilibraries/base/dist-install/build/autogen -Ilibraries/base/include -optP-DOPTIMISE_INTEGER_GCD_LCM -optP-include -optPlibraries/base/dist-install/build/autogen/cabal_macros.h -package ghc-prim-0.2.0.0 -package integer-gmp-0.2.0.2 -package rts-1.0 -package-name base -XMagicHash -XExistentialQuantification -XRank2Types -XScopedTypeVariables -XUnboxedTuples -XForeignFunctionInterface -XUnliftedFFITypes -XDeriveDataTypeable -XGeneralizedNewtypeDeriving -XFlexibleInstances -XStandaloneDeriving -XPatternGuards -XEmptyDataDecls -XNoImplicitPrelude -XCPP -no-user-package-conf -rtsopts -O2 -XGenerics -fno-warn-deprecated-flags -odir libraries/base/dist-install/build -hidir libraries/base/dist-install/build -stubdir libraries/base/dist-install/build -hisuf dyn_hi -osuf dyn_o -hcsuf dyn_hc -c libraries/base/./Data/Typeable.hs-boot -o libraries/base/dist-install/build/Data/Typeable.dyn_o-boot
/usr/bin/ld: libraries/integer-gmp/gmp/objs/abs.o: relocation R_X86_64_32 against `.text' can not be used when making a shared object; recompile with -fPIC
libraries/integer-gmp/gmp/objs/abs.o: could not read symbols: Bad value
collect2: ld returned 1 exit status
make[1]: *** [libraries/integer-gmp/dist-install/build/libHSinteger-gmp-0.2.0.2-ghc7.0.0.20100924.so] Error 1
make[1]: *** Waiting for unfinished jobs....
make: *** [all] Error 2
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.13 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Build System |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"in-tree GMP build problem with shared libraries","status":"New","operating_system":"","component":"Build System","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.13","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Reported by Vivian McPhail <haskell.vivian.mcphail@gmail.com> on glasgow-haskell-users:\r\n\r\n{{{\r\nTrying to build rc1 from source\r\n\r\nlinux x86_64\r\nBuildFlavour = perf\r\n\r\nIt seems that the -fPIC flag is set, but an error still occurs (\r\n/usr/bin/ld: libraries/integer-gmp/gmp/objs/abs.o: relocation R_X86_64_32 against `.text' can not be used when making a shared object; recompile with -fPIC\r\n)\r\n\r\n\"inplace/bin/ghc-stage1\" -fPIC -dynamic -O -H64m -package-name base-4.3.0.0 -hide-all-packages -i -ilibraries/base/. -ilibraries/base/dist-install/build -ilibraries/base/dist-install/build/autogen -Ilibraries/base/dist-install/build -Ilibraries/base/dist-install/build/autogen -Ilibraries/base/include -optP-DOPTIMISE_INTEGER_GCD_LCM -optP-include -optPlibraries/base/dist-install/build/autogen/cabal_macros.h -package ghc-prim-0.2.0.0 -package integer-gmp-0.2.0.2 -package rts-1.0 -package-name base -XMagicHash -XExistentialQuantification -XRank2Types -XScopedTypeVariables -XUnboxedTuples -XForeignFunctionInterface -XUnliftedFFITypes -XDeriveDataTypeable -XGeneralizedNewtypeDeriving -XFlexibleInstances -XStandaloneDeriving -XPatternGuards -XEmptyDataDecls -XNoImplicitPrelude -XCPP -no-user-package-conf -rtsopts -O2 -XGenerics -fno-warn-deprecated-flags -odir libraries/base/dist-install/build -hidir libraries/base/dist-install/build -stubdir libraries/base/dist-install/build -hisuf dyn_hi -osuf dyn_o -hcsuf dyn_hc -c libraries/base/./Data/Typeable.hs-boot -o libraries/base/dist-install/build/Data/Typeable.dyn_o-boot\r\n/usr/bin/ld: libraries/integer-gmp/gmp/objs/abs.o: relocation R_X86_64_32 against `.text' can not be used when making a shared object; recompile with -fPIC\r\nlibraries/integer-gmp/gmp/objs/abs.o: could not read symbols: Bad value\r\ncollect2: ld returned 1 exit status\r\nmake[1]: *** [libraries/integer-gmp/dist-install/build/libHSinteger-gmp-0.2.0.2-ghc7.0.0.20100924.so] Error 1\r\nmake[1]: *** Waiting for unfinished jobs....\r\nmake: *** [all] Error 2\r\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->7.10.1https://gitlab.haskell.org/ghc/ghc/-/issues/4218System.Random is way too lazy2019-07-07T19:00:04ZEyalLotemSystem.Random is way too lazyrandomRs is too lazy, generates lists of large lazy-state thunks, rather than lists of strict values.
Test program is attached.
Also, randomIO is too lazy, and builds up huge thunks. Using (randomIO \>\>= evaluate) is fine, however.
F...randomRs is too lazy, generates lists of large lazy-state thunks, rather than lists of strict values.
Test program is attached.
Also, randomIO is too lazy, and builds up huge thunks. Using (randomIO \>\>= evaluate) is fine, however.
Fails with stack overflow:
```
rs <- replicateM 1000000 evaluate :: IO [Int]
print $ last rs
```
Works:
```
rs <- replicateM 1000000 (evaluate =<< randomIO) :: IO [Int]
print $ last rs
```7.10.1https://gitlab.haskell.org/ghc/ghc/-/issues/3859Problems with toClockTime on NetBSD2019-07-07T19:01:49ZIan Lynagh <igloo@earth.li>Problems with toClockTime on NetBSDhttp://bugs.darcs.net/msg8960 (part of http://bugs.darcs.net/issue1524) says:
```
Got it: reproducing the crash (tough on such a slow machine where rebuilding
these things is quite the process, yay me):
<patch author='zooko@zooko.com'...http://bugs.darcs.net/msg8960 (part of http://bugs.darcs.net/issue1524) says:
```
Got it: reproducing the crash (tough on such a slow machine where rebuilding
these things is quite the process, yay me):
<patch author='zooko@zooko.com' date='20090308025039' local_date='Making
friendly CalendarTime {ctYear = 2009, ctMonth = March, ctDay = 8, ctHour = 2,
ctMin = 50, ctSec = 39, ctPicosec = 0, ctWDay = Sunday, ctYDay = 0, ctTZName =
"GMT", ctTZ = 0, ctIsDST = False}
Plugging that into your first requested program:
import System.Time
-- this is one line
main = print . toClockTime $ CalendarTime 2009 March 8 2 50 39 0 Sunday 0 "GMT"
0 False
... returns:
t: user error (Time.toClockTime: invalid input)
So.. This suggests to me there are two problems. First, the toClockTime
function has trouble with certain input.
This fails:
-- this is one line
main = print . toClockTime $ CalendarTime 2009 March 8 2 59 59 1000 Thursday
280 "BST" 3600 True
This succeeds:
-- this is one line
main = print . toClockTime $ CalendarTime 2009 March 8 3 0 0 0 Thursday 280
"BST" 3600 True
Weird huh?
And then clearly, the second problem appears to be the conversion of the
datestamp in the following partial log entry:
<patch author='zooko@zooko.com' date='20090308025039' local_date='Making
friendly CalendarTime {ctYear = 2009, ctMonth = March, ctDay = 8, ctHour = 2,
ctMin = 50, ctSec = 39, ctPicosec = 0, ctWDay = Sunday, ctYDay = 0, ctTZName =
"GMT", ctTZ = 0, ctIsDST = False}
(This is with a modified darcs with the printf-equivalent in it.)
This is suspiciously near to the DST switchover. If you need a zdump of my
current DST timings, I can provide the pre-zic entries.
Is there perhaps a DST switchover assumption in that logic?
Let me know if you'd like me to delve further. Hopefully this is enough to make
the problem clear to you darcs folks.
```
This really needs to be looked at by someone with access to NetBSD (or perhaps some similar OS).
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.12.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Problems with toClockTime on NetBSD","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"6.12.2","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.12.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"http://bugs.darcs.net/msg8960 (part of http://bugs.darcs.net/issue1524) says:\r\n{{{\r\nGot it: reproducing the crash (tough on such a slow machine where rebuilding \r\nthese things is quite the process, yay me):\r\n\r\n<patch author='zooko@zooko.com' date='20090308025039' local_date='Making \r\nfriendly CalendarTime {ctYear = 2009, ctMonth = March, ctDay = 8, ctHour = 2, \r\nctMin = 50, ctSec = 39, ctPicosec = 0, ctWDay = Sunday, ctYDay = 0, ctTZName = \r\n\"GMT\", ctTZ = 0, ctIsDST = False}\r\n\r\nPlugging that into your first requested program:\r\n\r\nimport System.Time\r\n\r\n-- this is one line\r\nmain = print . toClockTime $ CalendarTime 2009 March 8 2 50 39 0 Sunday 0 \"GMT\" \r\n0 False\r\n\r\n... returns:\r\n\r\nt: user error (Time.toClockTime: invalid input)\r\n\r\nSo.. This suggests to me there are two problems. First, the toClockTime \r\nfunction has trouble with certain input.\r\n\r\nThis fails:\r\n-- this is one line\r\nmain = print . toClockTime $ CalendarTime 2009 March 8 2 59 59 1000 Thursday \r\n280 \"BST\" 3600 True\r\n\r\nThis succeeds:\r\n-- this is one line\r\nmain = print . toClockTime $ CalendarTime 2009 March 8 3 0 0 0 Thursday 280 \r\n\"BST\" 3600 True\r\n\r\nWeird huh?\r\n\r\nAnd then clearly, the second problem appears to be the conversion of the \r\ndatestamp in the following partial log entry:\r\n\r\n<patch author='zooko@zooko.com' date='20090308025039' local_date='Making \r\nfriendly CalendarTime {ctYear = 2009, ctMonth = March, ctDay = 8, ctHour = 2, \r\nctMin = 50, ctSec = 39, ctPicosec = 0, ctWDay = Sunday, ctYDay = 0, ctTZName = \r\n\"GMT\", ctTZ = 0, ctIsDST = False}\r\n\r\n(This is with a modified darcs with the printf-equivalent in it.)\r\n\r\nThis is suspiciously near to the DST switchover. If you need a zdump of my \r\ncurrent DST timings, I can provide the pre-zic entries.\r\n\r\nIs there perhaps a DST switchover assumption in that logic?\r\n\r\nLet me know if you'd like me to delve further. Hopefully this is enough to make \r\nthe problem clear to you darcs folks.\r\n}}}\r\n\r\nThis really needs to be looked at by someone with access to NetBSD (or perhaps some similar OS).\r\n","type_of_failure":"OtherFailure","blocking":[]} -->7.10.1https://gitlab.haskell.org/ghc/ghc/-/issues/3771haddock: internal error: evacuate: strange closure type 192692019-07-07T19:02:15Zdbuenohaddock: internal error: evacuate: strange closure type 19269Here are the last few lines of `make` output
```
"rm" -f libraries/unix/dist-install/build/libHSunix-2.4.0.0_p.a
(echo libraries/unix/dist-install/build/cbits/HsUnix.p_o libraries/unix/dist-install/build/cbits/execvpe.p_o libraries/un...Here are the last few lines of `make` output
```
"rm" -f libraries/unix/dist-install/build/libHSunix-2.4.0.0_p.a
(echo libraries/unix/dist-install/build/cbits/HsUnix.p_o libraries/unix/dist-install/build/cbits/execvpe.p_o libraries/unix/dist-install/build/cbits/dirUtils.p_o `/usr/bin/find libraries/unix/dist-install/build -name "*_stub.p_o" -print`; /usr/bin/find libraries/unix/dist-install/build/System/Posix_p_o_split libraries/unix/dist-install/build/System/Posix/DynamicLinker/Module_p_o_split libraries/unix/dist-install/build/System/Posix/DynamicLinker/Prim_p_o_split libraries/unix/dist-install/build/System/Posix/Directory_p_o_split libraries/unix/dist-install/build/System/Posix/DynamicLinker_p_o_split libraries/unix/dist-install/build/System/Posix/Env_p_o_split libraries/unix/dist-install/build/System/Posix/Error_p_o_split libraries/unix/dist-install/build/System/Posix/Files_p_o_split libraries/unix/dist-install/build/System/Posix/IO_p_o_split libraries/unix/dist-install/build/System/Posix/Process_p_o_split libraries/unix/dist-install/build/System/Posix/Process/Internals_p_o_split libraries/unix/dist-install/build/System/Posix/Resource_p_o_split libraries/unix/dist-install/build/System/Posix/Temp_p_o_split libraries/unix/dist-install/build/System/Posix/Terminal_p_o_split libraries/unix/dist-install/build/System/Posix/Time_p_o_split libraries/unix/dist-install/build/System/Posix/Unistd_p_o_split libraries/unix/dist-install/build/System/Posix/User_p_o_split libraries/unix/dist-install/build/System/Posix/Signals_p_o_split libraries/unix/dist-install/build/System/Posix/Signals/Exts_p_o_split libraries/unix/dist-install/build/System/Posix/Semaphore_p_o_split libraries/unix/dist-install/build/System/Posix/SharedMem_p_o_split -name '*.p_o' -print) | "xargs" "/usr/bin/ar" clqs libraries/unix/dist-install/build/libHSunix-2.4.0.0_p.a
"inplace/bin/mkdirhier" libraries/unix/dist-install/doc/html/unix/
"inplace/bin/ghc-cabal" haddock dist-install libraries/unix --with-haddock=/Users/dbueno/Downloads/ghc-6.12.1/inplace/bin/haddock --with-ghc=/Users/dbueno/Downloads/ghc-6.12.1/inplace/bin/ghc-stage2
Running Haddock for unix-2.4.0.0...
Preprocessing library unix-2.4.0.0...
Warning: The documentation for the following packages are not installed. No
links will be generated to these packages: ffi-1.0, rts-1.0
haddock: internal error: evacuate: strange closure type 19269
(GHC version 6.12.1 for powerpc_apple_darwin)
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
make[1]: *** [libraries/unix/dist-install/doc/html/unix/unix.haddock] Error 6
make: *** [all] Error 2
```
I did the following to build:
```
./configure --prefix=/usr/local/ghc-6.12.4
make
```
I'm on `Darwin power-mac-g5.local 9.7.0 Darwin Kernel Version 9.7.0: Tue Mar 31 22:54:29 PDT 2009; root:xnu-1228.12.14~1/RELEASE_PPC Power Macintosh`.
What other information do you need?
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.12.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | powerpc64 |
</details>
<!-- {"blocked_by":[],"summary":"haddock: internal error: evacuate: strange closure type 19269","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.12.1","keywords":[],"differentials":[],"test_case":"","architecture":"powerpc64","cc":[""],"type":"Bug","description":"Here are the last few lines of `make` output\r\n{{{\r\n\"rm\" -f libraries/unix/dist-install/build/libHSunix-2.4.0.0_p.a\r\n(echo libraries/unix/dist-install/build/cbits/HsUnix.p_o libraries/unix/dist-install/build/cbits/execvpe.p_o libraries/unix/dist-install/build/cbits/dirUtils.p_o `/usr/bin/find libraries/unix/dist-install/build -name \"*_stub.p_o\" -print`; /usr/bin/find libraries/unix/dist-install/build/System/Posix_p_o_split libraries/unix/dist-install/build/System/Posix/DynamicLinker/Module_p_o_split libraries/unix/dist-install/build/System/Posix/DynamicLinker/Prim_p_o_split libraries/unix/dist-install/build/System/Posix/Directory_p_o_split libraries/unix/dist-install/build/System/Posix/DynamicLinker_p_o_split libraries/unix/dist-install/build/System/Posix/Env_p_o_split libraries/unix/dist-install/build/System/Posix/Error_p_o_split libraries/unix/dist-install/build/System/Posix/Files_p_o_split libraries/unix/dist-install/build/System/Posix/IO_p_o_split libraries/unix/dist-install/build/System/Posix/Process_p_o_split libraries/unix/dist-install/build/System/Posix/Process/Internals_p_o_split libraries/unix/dist-install/build/System/Posix/Resource_p_o_split libraries/unix/dist-install/build/System/Posix/Temp_p_o_split libraries/unix/dist-install/build/System/Posix/Terminal_p_o_split libraries/unix/dist-install/build/System/Posix/Time_p_o_split libraries/unix/dist-install/build/System/Posix/Unistd_p_o_split libraries/unix/dist-install/build/System/Posix/User_p_o_split libraries/unix/dist-install/build/System/Posix/Signals_p_o_split libraries/unix/dist-install/build/System/Posix/Signals/Exts_p_o_split libraries/unix/dist-install/build/System/Posix/Semaphore_p_o_split libraries/unix/dist-install/build/System/Posix/SharedMem_p_o_split -name '*.p_o' -print) | \"xargs\" \"/usr/bin/ar\" clqs libraries/unix/dist-install/build/libHSunix-2.4.0.0_p.a\r\n\"inplace/bin/mkdirhier\" libraries/unix/dist-install/doc/html/unix/\r\n\"inplace/bin/ghc-cabal\" haddock dist-install libraries/unix --with-haddock=/Users/dbueno/Downloads/ghc-6.12.1/inplace/bin/haddock --with-ghc=/Users/dbueno/Downloads/ghc-6.12.1/inplace/bin/ghc-stage2 \r\nRunning Haddock for unix-2.4.0.0...\r\nPreprocessing library unix-2.4.0.0...\r\nWarning: The documentation for the following packages are not installed. No\r\nlinks will be generated to these packages: ffi-1.0, rts-1.0\r\nhaddock: internal error: evacuate: strange closure type 19269\r\n (GHC version 6.12.1 for powerpc_apple_darwin)\r\n Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug\r\nmake[1]: *** [libraries/unix/dist-install/doc/html/unix/unix.haddock] Error 6\r\nmake: *** [all] Error 2\r\n}}}\r\nI did the following to build:\r\n{{{\r\n./configure --prefix=/usr/local/ghc-6.12.4\r\nmake\r\n}}}\r\n\r\nI'm on `Darwin power-mac-g5.local 9.7.0 Darwin Kernel Version 9.7.0: Tue Mar 31 22:54:29 PDT 2009; root:xnu-1228.12.14~1/RELEASE_PPC Power Macintosh`.\r\n\r\nWhat other information do you need?","type_of_failure":"OtherFailure","blocking":[]} -->7.10.1