GHC issueshttps://gitlab.haskell.org/ghc/ghc/-/issues2019-07-07T19:12:46Zhttps://gitlab.haskell.org/ghc/ghc/-/issues/1586trace output ordering in HEAD incorrectly2019-07-07T19:12:46Ziampure@gmail.comtrace output ordering in HEAD incorrectlyI don't have a test case, but it appears that the Debug.Trace.trace output is ordered incorrectly. By incorrectly, I mean that it does not follow evaluation order. I suspect it will come up in every non-trivial use of it. In GHC-6.6.1 th...I don't have a test case, but it appears that the Debug.Trace.trace output is ordered incorrectly. By incorrectly, I mean that it does not follow evaluation order. I suspect it will come up in every non-trivial use of it. In GHC-6.6.1 the output order was correct (modulo that the size of output was not equal during runs (but there is another report for that already)).
In a program I have
```
runFoo $ do
() <- trace "hi" (return ())
() <- trace "there" (return ())
return ()
```
prints:
```
there
hi
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.7 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | Unknown |
| Architecture | Unknown |
</details>
<!-- {"blocked_by":[],"summary":"trace output ordering in HEAD incorrectly","status":"New","operating_system":"Unknown","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.7","keywords":[],"differentials":[],"test_case":"","architecture":"Unknown","cc":[""],"type":"Bug","description":"I don't have a test case, but it appears that the Debug.Trace.trace output is ordered incorrectly. By incorrectly, I mean that it does not follow evaluation order. I suspect it will come up in every non-trivial use of it. In GHC-6.6.1 the output order was correct (modulo that the size of output was not equal during runs (but there is another report for that already)). \r\n\r\nIn a program I have \r\n{{{\r\nrunFoo $ do\r\n () <- trace \"hi\" (return ())\r\n () <- trace \"there\" (return ())\r\n return ()\r\n}}}\r\n\r\nprints:\r\n{{{ \r\nthere\r\nhi\r\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/1587":i (->)" doesn't work2019-07-07T19:12:46ZSamuel Bronson":i (->)" doesn't work```
Prelude> :i (->)
<interactive>:1:1: parse error on input `->'
```
I hope that's clear enough for you ;-).
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ ...```
Prelude> :i (->)
<interactive>:1:1: parse error on input `->'
```
I hope that's clear enough for you ;-).
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.6 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | GHCi |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | Unknown |
| Architecture | Unknown |
</details>
<!-- {"blocked_by":[],"summary":"\":i (->)\" doesn't work","status":"New","operating_system":"Unknown","component":"GHCi","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.6","keywords":[],"differentials":[],"test_case":"","architecture":"Unknown","cc":[""],"type":"Bug","description":"{{{\r\nPrelude> :i (->)\r\n<interactive>:1:1: parse error on input `->'\r\n}}}\r\n\r\nI hope that's clear enough for you ;-).","type_of_failure":"OtherFailure","blocking":[]} -->6.8.1Ian Lynagh <igloo@earth.li>Ian Lynagh <igloo@earth.li>https://gitlab.haskell.org/ghc/ghc/-/issues/1588unrequested generalized newtype deriving?2019-07-07T19:12:45ZSamuel Bronsonunrequested generalized newtype deriving?Consider the two type definitions:
```
newtype MaybeT m a = MaybeT { runMaybeT :: m (Maybe a) } deriving Eq
data MaybeT' m a = MaybeT' { runMaybeT' :: m (Maybe a) } deriving Eq
```
Why is it that the former compiles, with no flag...Consider the two type definitions:
```
newtype MaybeT m a = MaybeT { runMaybeT :: m (Maybe a) } deriving Eq
data MaybeT' m a = MaybeT' { runMaybeT' :: m (Maybe a) } deriving Eq
```
Why is it that the former compiles, with no flags of any kind, but the latter does not? It seems like generalized newtype deriving is happening when unrequested and undesired...
(I'm trying to figure out how Derive should derive Eq, and compiler bugs don't help much ;-)
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.6 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | Unknown |
| Architecture | Unknown |
</details>
<!-- {"blocked_by":[],"summary":"unrequested generalized newtype deriving?","status":"New","operating_system":"Unknown","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.6","keywords":[],"differentials":[],"test_case":"","architecture":"Unknown","cc":[""],"type":"Bug","description":"Consider the two type definitions:\r\n\r\n{{{\r\nnewtype MaybeT m a = MaybeT { runMaybeT :: m (Maybe a) } deriving Eq\r\ndata MaybeT' m a = MaybeT' { runMaybeT' :: m (Maybe a) } deriving Eq\r\n}}}\r\n\r\nWhy is it that the former compiles, with no flags of any kind, but the latter does not? It seems like generalized newtype deriving is happening when unrequested and undesired...\r\n\r\n(I'm trying to figure out how Derive should derive Eq, and compiler bugs don't help much ;-)","type_of_failure":"OtherFailure","blocking":[]} -->6.8.1Ian Lynagh <igloo@earth.li>Ian Lynagh <igloo@earth.li>https://gitlab.haskell.org/ghc/ghc/-/issues/1591runghc, ghc rts or base implements unintuitive shell escaping in Windows2019-07-07T19:12:44Zeivuokkorunghc, ghc rts or base implements unintuitive shell escaping in WindowsParameters passed to script via runghc get malformed unintuitively.
```
Commandline "C:\Program Files\" "C:\Program Files\"
should give ["c:\\Program Files\\", "c:\\Program Files\\"]
but gives ["c:\\Program Files\" c:\\Program","Files\...Parameters passed to script via runghc get malformed unintuitively.
```
Commandline "C:\Program Files\" "C:\Program Files\"
should give ["c:\\Program Files\\", "c:\\Program Files\\"]
but gives ["c:\\Program Files\" c:\\Program","Files\""]
```
On Windows Vista, ghc is from Neil's installer:
```
C:\Users\eivuokko\Documents\source\cabal2wix>copy con test.hs
module Main where
import System.Environment
main = getArgs >>= print
^Z
1 file(s) copied.
C:\Users\eivuokko\Documents\source\cabal2wix>runghc test "c:\Program Files\" "c:
\Program Files\"
["c:\\Program Files\" c:\\Program","Files\""]
C:\Users\eivuokko\Documents\source\cabal2wix>ghc --version
The Glorious Glasgow Haskell Compilation System, version 6.6.1
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.6.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | Unknown |
| Architecture | Unknown |
</details>
<!-- {"blocked_by":[],"summary":"runghc, ghc rts or base implements unintuitive shell escaping in Windows","status":"New","operating_system":"Unknown","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.6.1","keywords":[],"differentials":[],"test_case":"","architecture":"Unknown","cc":[""],"type":"Bug","description":"Parameters passed to script via runghc get malformed unintuitively.\r\n\r\n{{{\r\nCommandline \"C:\\Program Files\\\" \"C:\\Program Files\\\" \r\nshould give [\"c:\\\\Program Files\\\\\", \"c:\\\\Program Files\\\\\"]\r\nbut gives [\"c:\\\\Program Files\\\" c:\\\\Program\",\"Files\\\"\"]\r\n}}}\r\n\r\nOn Windows Vista, ghc is from Neil's installer:\r\n\r\n{{{\r\nC:\\Users\\eivuokko\\Documents\\source\\cabal2wix>copy con test.hs\r\nmodule Main where\r\nimport System.Environment\r\nmain = getArgs >>= print\r\n^Z\r\n 1 file(s) copied.\r\n\r\nC:\\Users\\eivuokko\\Documents\\source\\cabal2wix>runghc test \"c:\\Program Files\\\" \"c:\r\n\\Program Files\\\"\r\n[\"c:\\\\Program Files\\\" c:\\\\Program\",\"Files\\\"\"]\r\n\r\nC:\\Users\\eivuokko\\Documents\\source\\cabal2wix>ghc --version\r\nThe Glorious Glasgow Haskell Compilation System, version 6.6.1\r\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->6.8.1https://gitlab.haskell.org/ghc/ghc/-/issues/1593Improve runInteractiveProcess error message when working directory does not e...2019-07-07T19:12:44Ztomasz.zielonka@gmail.comImprove runInteractiveProcess error message when working directory does not existExample code:
```
import System.Process
main = do
(_, _, _, commhand) <-
runInteractiveProcess "echo" ["something"] (Just "/no/such/dir") Nothing
exitCode <- waitForProcess commhand
print exitCode
```
T...Example code:
```
import System.Process
main = do
(_, _, _, commhand) <-
runInteractiveProcess "echo" ["something"] (Just "/no/such/dir") Nothing
exitCode <- waitForProcess commhand
print exitCode
```
This happens on Linux with both 6.6 and the latest HEAD snapshot.
I think the problem is in C code, in libraries/base/cbits/runProcess.c (6.6).
Below are the important code fragments. Search for BUG HERE for a bug location.
```
ProcHandle
runInteractiveProcess (char *const args[],
char *workingDirectory, char **environment,
int *pfdStdInput, int *pfdStdOutput, int *pfdStdError)
{
...
switch(pid = fork())
{
...
case 0:
{
pPrPr_disableITimers();
if (workingDirectory) {
if (chdir (workingDirectory) < 0) {
// BUG HERE:
// Calling return here is bad idea here. This code
// is run in the child process and returning makes the
// child act as if it was the parent - strange things will
// happen!
return -1;
}
}
...
/* the child */
if (environment) {
execvpe(args[0], args, environment);
} else {
execvp(args[0], args);
}
}
_exit(127);
default:
...
```
I thought about sending a patch, but I'm not sure what the fix should be. Doing "_exit(SOMETHING)" instead of return seems to be better then returning, but I don't know what SOMETHING should be, and maybe there is a better solution.
I think I've seen the same problem in another run\*Process function in this C file.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | --------------------------------------- |
| Version | 6.7 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | libraries (other) |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | marig1@wp.pl, tomasz.zielonka@gmail.com |
| Operating system | Unknown |
| Architecture | Unknown |
</details>
<!-- {"blocked_by":[],"summary":"runInteractiveProcess misbehaves when it gets invalid (eg. non-existent) working directory parameter","status":"New","operating_system":"Unknown","component":"libraries (other)","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.7","keywords":[],"differentials":[],"test_case":"","architecture":"Unknown","cc":["marig1@wp.pl","tomasz.zielonka@gmail.com"],"type":"Bug","description":"Example code:\r\n\r\n{{{\r\n import System.Process\r\n\r\n main = do\r\n (_, _, _, commhand) <-\r\n runInteractiveProcess \"echo\" [\"something\"] (Just \"/no/such/dir\") Nothing\r\n exitCode <- waitForProcess commhand\r\n print exitCode\r\n}}}\r\n\r\nThis happens on Linux with both 6.6 and the latest HEAD snapshot.\r\n\r\nI think the problem is in C code, in libraries/base/cbits/runProcess.c (6.6).\r\nBelow are the important code fragments. Search for BUG HERE for a bug location.\r\n\r\n{{{\r\nProcHandle\r\nrunInteractiveProcess (char *const args[],\r\n char *workingDirectory, char **environment,\r\n int *pfdStdInput, int *pfdStdOutput, int *pfdStdError)\r\n{\r\n ...\r\n\r\n switch(pid = fork())\r\n {\r\n ...\r\n\r\n case 0:\r\n {\r\n pPrPr_disableITimers();\r\n\r\n if (workingDirectory) {\r\n if (chdir (workingDirectory) < 0) {\r\n // BUG HERE:\r\n // Calling return here is bad idea here. This code\r\n // is run in the child process and returning makes the\r\n // child act as if it was the parent - strange things will\r\n // happen!\r\n return -1;\r\n }\r\n }\r\n\r\n ...\r\n\r\n /* the child */\r\n if (environment) {\r\n execvpe(args[0], args, environment);\r\n } else {\r\n execvp(args[0], args);\r\n }\r\n }\r\n _exit(127);\r\n\r\n default:\r\n ...\r\n}}}\r\n\r\nI thought about sending a patch, but I'm not sure what the fix should be. Doing \"_exit(SOMETHING)\" instead of return seems to be better then returning, but I don't know what SOMETHING should be, and maybe there is a better solution.\r\n\r\nI think I've seen the same problem in another run*Process function in this C file.","type_of_failure":"OtherFailure","blocking":[]} -->Simon MarlowSimon Marlowhttps://gitlab.haskell.org/ghc/ghc/-/issues/1594Better QuickCheck/HUnit integration2019-07-07T19:12:44ZIan Lynagh <igloo@earth.li>Better QuickCheck/HUnit integrationDaniel Burrows \<dburrows\@debian.org\> in
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=355215
requests:
Quickcheck and HUnit are both great tools for testing software, but it
seems to be rather difficult to make them work together....Daniel Burrows \<dburrows\@debian.org\> in
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=355215
requests:
Quickcheck and HUnit are both great tools for testing software, but it
seems to be rather difficult to make them work together. In particular,
since the signature of all the quickCheck interface functions is some
variant on
```
Testable a => a -> IO ()
```
the only way to find out whether a test succeeded or failed is to read
the terminal output. It would be ideal if !QuickCheck could generate HUnit
assertion failures when a test failed (maybe by expanding the Config
structure with "failure hooks"), but even just changing its signature
to either
```
Testable a => a -> IO Bool
```
returning True for success, or (slightly more ambitiously)
```
Testable a => a -> IO (Maybe String)
```
returning Nothing for success and an error message otherwise would be
enough to get basic integration working.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ----------------- |
| Version | 6.6.1 |
| Type | FeatureRequest |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | libraries (other) |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | Unknown |
| Architecture | Unknown |
</details>
<!-- {"blocked_by":[],"summary":"Better QuickCheck/HUnit integration","status":"New","operating_system":"Unknown","component":"libraries (other)","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.6.1","keywords":[],"differentials":[],"test_case":"","architecture":"Unknown","cc":[""],"type":"FeatureRequest","description":"Daniel Burrows <dburrows@debian.org> in\r\nhttp://bugs.debian.org/cgi-bin/bugreport.cgi?bug=355215\r\nrequests:\r\n\r\nQuickcheck and HUnit are both great tools for testing software, but it\r\nseems to be rather difficult to make them work together. In particular,\r\nsince the signature of all the quickCheck interface functions is some\r\nvariant on\r\n{{{\r\nTestable a => a -> IO ()\r\n}}}\r\nthe only way to find out whether a test succeeded or failed is to read\r\nthe terminal output. It would be ideal if !QuickCheck could generate HUnit\r\nassertion failures when a test failed (maybe by expanding the Config\r\nstructure with \"failure hooks\"), but even just changing its signature\r\nto either\r\n{{{\r\nTestable a => a -> IO Bool\r\n}}}\r\nreturning True for success, or (slightly more ambitiously)\r\n{{{\r\nTestable a => a -> IO (Maybe String)\r\n}}}\r\nreturning Nothing for success and an error message otherwise would be\r\nenough to get basic integration working.","type_of_failure":"OtherFailure","blocking":[]} -->Not GHChttps://gitlab.haskell.org/ghc/ghc/-/issues/1595duplicate "not in scope" error when giving multiple vars type-signatures at once2019-07-07T19:12:43ZIsaac Dupreeduplicate "not in scope" error when giving multiple vars type-signatures at once(bug in 6.6.1 and 6.7)
```
a, b :: Integer -> Tpyo
a = undefined
b = undefined
```
results in
```
gw.hs:2:19: Not in scope: type constructor or class `Tpyo'
gw.hs:2:19: Not in scope: type constructor or class `Tpyo'
```
Expected res...(bug in 6.6.1 and 6.7)
```
a, b :: Integer -> Tpyo
a = undefined
b = undefined
```
results in
```
gw.hs:2:19: Not in scope: type constructor or class `Tpyo'
gw.hs:2:19: Not in scope: type constructor or class `Tpyo'
```
Expected result: only one of the same error per location in file of mistake, not one per function being defined.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.6.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | Unknown |
| Architecture | Unknown |
</details>
<!-- {"blocked_by":[],"summary":"duplicate \"not in scope\" error when giving multiple vars type-signatures at once","status":"New","operating_system":"Unknown","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.6.1","keywords":[],"differentials":[],"test_case":"","architecture":"Unknown","cc":[""],"type":"Bug","description":"(bug in 6.6.1 and 6.7)\r\n\r\n{{{\r\na, b :: Integer -> Tpyo\r\na = undefined\r\nb = undefined\r\n}}}\r\nresults in\r\n{{{\r\n\r\ngw.hs:2:19: Not in scope: type constructor or class `Tpyo'\r\n\r\ngw.hs:2:19: Not in scope: type constructor or class `Tpyo'\r\n}}}\r\n\r\nExpected result: only one of the same error per location in file of mistake, not one per function being defined.","type_of_failure":"OtherFailure","blocking":[]} -->7.2.1Michal TerepetaMichal Terepetahttps://gitlab.haskell.org/ghc/ghc/-/issues/1596ghc-pkg --define-name is undocumented2019-07-07T19:12:42Zeivuokkoghc-pkg --define-name is undocumentedIn ghc 6.6.1 ghc-pkg --define-name is undocumented, except getting mentioned in ghc-pkg usage output.
Is it meant to be stable interface?
<details><summary>Trac metadata</summary>
| Trac field | Value |
| --------...In ghc 6.6.1 ghc-pkg --define-name is undocumented, except getting mentioned in ghc-pkg usage output.
Is it meant to be stable interface?
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 6.6.1 |
| Type | FeatureRequest |
| TypeOfFailure | OtherFailure |
| Priority | low |
| Resolution | Unresolved |
| Component | Documentation |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | Unknown |
| Architecture | Unknown |
</details>
<!-- {"blocked_by":[],"summary":"ghc-pkg --define-name is undocumented","status":"New","operating_system":"Unknown","component":"Documentation","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.6.1","keywords":[],"differentials":[],"test_case":"","architecture":"Unknown","cc":[""],"type":"FeatureRequest","description":"In ghc 6.6.1 ghc-pkg --define-name is undocumented, except getting mentioned in ghc-pkg usage output.\r\n\r\nIs it meant to be stable interface?","type_of_failure":"OtherFailure","blocking":[]} -->6.8.2Ian Lynagh <igloo@earth.li>Ian Lynagh <igloo@earth.li>https://gitlab.haskell.org/ghc/ghc/-/issues/1597OpenGL: Bindings for GLE library?2019-07-07T19:12:42ZIan Lynagh <igloo@earth.li>OpenGL: Bindings for GLE library?In http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=419125
Josh Triplett \<josh\@freedesktop.org\> writes:
In addition to the GL and GLU bindings currently provided, I'd really like
bindings to the OpenGL Tubing and Extrusion library, G...In http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=419125
Josh Triplett \<josh\@freedesktop.org\> writes:
In addition to the GL and GLU bindings currently provided, I'd really like
bindings to the OpenGL Tubing and Extrusion library, GLE.
http://linas.org/gle/ , packages libgle3 and libgle3-dev.
A GLE binding would need to make use of some of the internal Haskell modules
of haskell-opengl that don't ship in the binary package in order to provide a
compatible interface, so unless haskell-opengl changed to supply these, a GLE
binding would need to build as part of haskell-opengl.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ----------------- |
| Version | 6.6.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | libraries (other) |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | Unknown |
| Architecture | Unknown |
</details>
<!-- {"blocked_by":[],"summary":"OpenGL: Bindings for GLE library?","status":"New","operating_system":"Unknown","component":"libraries (other)","related":[],"milestone":"Not GHC","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.6.1","keywords":[],"differentials":[],"test_case":"","architecture":"Unknown","cc":[""],"type":"Bug","description":"In http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=419125\r\nJosh Triplett <josh@freedesktop.org> writes:\r\n\r\nIn addition to the GL and GLU bindings currently provided, I'd really like\r\nbindings to the OpenGL Tubing and Extrusion library, GLE.\r\nhttp://linas.org/gle/ , packages libgle3 and libgle3-dev.\r\n\r\nA GLE binding would need to make use of some of the internal Haskell modules\r\nof haskell-opengl that don't ship in the binary package in order to provide a\r\ncompatible interface, so unless haskell-opengl changed to supply these, a GLE\r\nbinding would need to build as part of haskell-opengl.","type_of_failure":"OtherFailure","blocking":[]} -->Not GHChttps://gitlab.haskell.org/ghc/ghc/-/issues/1598Could instances of Typeable, Data be added?2019-07-07T19:12:41ZIan Lynagh <igloo@earth.li>Could instances of Typeable, Data be added?In http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=426612
Mark Carroll \<mark\@ixod.org\> writes:
Could some of the data structures, such as Data.Time.Calendar.Day and
Data.Time.LocalTime.TimeOfDay, be made instances of Typeable and Da...In http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=426612
Mark Carroll \<mark\@ixod.org\> writes:
Could some of the data structures, such as Data.Time.Calendar.Day and
Data.Time.LocalTime.TimeOfDay, be made instances of Typeable and Data
so that they can be used with Data.Generics, etc.?
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ----------------- |
| Version | 6.6.1 |
| Type | FeatureRequest |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | libraries (other) |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | Unknown |
| Architecture | Unknown |
</details>
<!-- {"blocked_by":[],"summary":"Could instances of Typeable, Data be added?","status":"New","operating_system":"Unknown","component":"libraries (other)","related":[],"milestone":"Not GHC","resolution":"Unresolved","owner":{"tag":"OwnedBy","contents":"ashley@semantic.org"},"version":"6.6.1","keywords":[],"differentials":[],"test_case":"","architecture":"Unknown","cc":[""],"type":"FeatureRequest","description":"In http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=426612\r\nMark Carroll <mark@ixod.org> writes:\r\n\r\nCould some of the data structures, such as Data.Time.Calendar.Day and\r\nData.Time.LocalTime.TimeOfDay, be made instances of Typeable and Data\r\nso that they can be used with Data.Generics, etc.?","type_of_failure":"OtherFailure","blocking":[]} -->Not GHCAshley Yakeley <ashley@semantic.org>Ashley Yakeley <ashley@semantic.org>https://gitlab.haskell.org/ghc/ghc/-/issues/1599testsuite timeout doesn't kill subprocesses on Windows2019-07-07T19:12:41ZSimon Marlowtestsuite timeout doesn't kill subprocesses on WindowsThe timeout program doesn't kill subprocesses on Windows, which means for example that if GHCi hangs, timeout only kills ghc-inplace and not the GHC binary itself. The hung GHC process prevents the build tree from being removed, and stop...The timeout program doesn't kill subprocesses on Windows, which means for example that if GHCi hangs, timeout only kills ghc-inplace and not the GHC binary itself. The hung GHC process prevents the build tree from being removed, and stops future buildbots from running.
I just came across this Python code which allegedly does both timeout and subprocess-killing on Windows:
[http://benjamin.smedbergs.us/blog/2006-12-11/killableprocesspy/](http://benjamin.smedbergs.us/blog/2006-12-11/killableprocesspy/)
This could be either used directly (it's Mozilla-licensed) or we could adapt the idea for our timeout program.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.6.1 |
| 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":"testsuite timeout doesn't kill subprocesses on Windows","status":"New","operating_system":"","component":"Test Suite","related":[],"milestone":"6.8 branch","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.6.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"The timeout program doesn't kill subprocesses on Windows, which means for example that if GHCi hangs, timeout only kills ghc-inplace and not the GHC binary itself. The hung GHC process prevents the build tree from being removed, and stops future buildbots from running.\r\n\r\nI just came across this Python code which allegedly does both timeout and subprocess-killing on Windows:\r\n\r\n[http://benjamin.smedbergs.us/blog/2006-12-11/killableprocesspy/]\r\n\r\nThis could be either used directly (it's Mozilla-licensed) or we could adapt the idea for our timeout program.","type_of_failure":"OtherFailure","blocking":[]} -->6.8 branchIan Lynagh <igloo@earth.li>Ian Lynagh <igloo@earth.li>https://gitlab.haskell.org/ghc/ghc/-/issues/1601ghc-6.6.1: internal error: evacuate: strange closure type 76002019-07-07T19:12:40Zguestghc-6.6.1: internal error: evacuate: strange closure type 7600I tried to compile the Kaya compiler with GHC.
GHC crashed with an internal error and told me
to file a bug report:
```
...
[20 of 28] Compiling InfGadgets ( InfGadgets.hs, InfGadgets.o )
[21 of 28] Compiling Inference ( In...I tried to compile the Kaya compiler with GHC.
GHC crashed with an internal error and told me
to file a bug report:
```
...
[20 of 28] Compiling InfGadgets ( InfGadgets.hs, InfGadgets.o )
[21 of 28] Compiling Inference ( Inference.hs, Inference.o )
ghc-6.6.1: internal error: evacuate: strange closure type 7600
(GHC version 6.6.1 for i386_unknown_linux)
```
My OS is Fedora Core 6, Kaya-Version is 0.2.6
You can reach me at oliver-at-firstfloor.org6.8.1https://gitlab.haskell.org/ghc/ghc/-/issues/1602GHC.Handle.fdToHandle' locks regular files2019-07-07T19:12:40ZbosGHC.Handle.fdToHandle' locks regular filesThe code in GHC.Handle.fdToHandle' locks a regular file. This violates POSIX file semantics, because it means that a process can't open the same file twice simultaneously. The locking should be removed.
<details><summary>Trac metadata</...The code in GHC.Handle.fdToHandle' locks a regular file. This violates POSIX file semantics, because it means that a process can't open the same file twice simultaneously. The locking should be removed.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 6.6.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Runtime System |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | Unknown |
| Architecture | Unknown |
</details>
<!-- {"blocked_by":[],"summary":"GHC.Handle.fdToHandle' locks regular files","status":"New","operating_system":"Unknown","component":"Runtime System","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.6.1","keywords":[],"differentials":[],"test_case":"","architecture":"Unknown","cc":[""],"type":"Bug","description":"The code in GHC.Handle.fdToHandle' locks a regular file. This violates POSIX file semantics, because it means that a process can't open the same file twice simultaneously. The locking should be removed.","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/1604Coarse-grained recompilation checking2019-07-07T19:12:40ZSimon MarlowCoarse-grained recompilation checkingGHC's recompilation checker is very clever: it tracks changes at the level of an individual function or type, and only recompiles a module when the entities it actually depends on have changed.
However, there are some drawbacks to doing...GHC's recompilation checker is very clever: it tracks changes at the level of an individual function or type, and only recompiles a module when the entities it actually depends on have changed.
However, there are some drawbacks to doing this:
- It is complicated and hard to get right
- It adds extra information to .hi files
- It takes time to check the dependencies (probably not much, though)
Furthermore,
- we have virtually no tests for it
- when it goes wrong, the bug is very hard to reproduce, which means that
failures are often not reported.
So we propose:
- Simplify the recompilation checker so that it tracks changes at the level of a
module only. This will cause more recompilation, but it will be much easier
to get right and to test.
- As an intermediate step, we could implement both schemes and generate some output
to indicate when they give different results.
See [Commentary/Compiler/RecompilationAvoidance](commentary/compiler/recompilation-avoidance) for more discussion.6.10 branchhttps://gitlab.haskell.org/ghc/ghc/-/issues/1605hppa port -- gmp handed misaligned memory2019-07-07T19:12:39Zguesthppa port -- gmp handed misaligned memoryGMP compiled for hppa 2.0n uses 8 byte data by default. hppa \*requires\* that 8 byte data be aligned on an 8 byte boundary. However GHC only aligns allocated memory to a 4 byte boundary. This causes GHC to crash. Currently the workaroun...GMP compiled for hppa 2.0n uses 8 byte data by default. hppa \*requires\* that 8 byte data be aligned on an 8 byte boundary. However GHC only aligns allocated memory to a 4 byte boundary. This causes GHC to crash. Currently the workaround is to recompile GMP to use 32 bit data, but this is probably a performance hit.
Joe Buehler
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 6.6.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Runtime System |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"hppa port -- gmp handed misaligned memory","status":"New","operating_system":"","component":"Runtime System","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.6.1","keywords":["GMP"],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"GMP compiled for hppa 2.0n uses 8 byte data by default. hppa *requires* that 8 byte data be aligned on an 8 byte boundary. However GHC only aligns allocated memory to a 4 byte boundary. This causes GHC to crash. Currently the workaround is to recompile GMP to use 32 bit data, but this is probably a performance hit.\r\n\r\nJoe Buehler","type_of_failure":"OtherFailure","blocking":[]} -->7.6.2https://gitlab.haskell.org/ghc/ghc/-/issues/1606excessively long, redundant, compile-error-message contexts2019-07-07T19:12:39ZIsaac Dupreeexcessively long, redundant, compile-error-message contextsThis is one single error message, with no good reason to go over, say, 24 lines...
(I thought there was a related bug report about long do-blocks in error messages, but I couldn't find it.)
```
IntegerInTermsOfInt.hs:2233:5:
Couldn...This is one single error message, with no good reason to go over, say, 24 lines...
(I thought there was a related bug report about long do-blocks in error messages, but I couldn't find it.)
```
IntegerInTermsOfInt.hs:2233:5:
Couldn't match expected type `DInt -> DInt -> DInt -> [DInt]'
against inferred type `[DInt]'
In the expression:
let
n1 = isNegativeInteger i1
n2 = isNegativeInteger i2
nf = n1 `signOp` n2
rs1 = signRep n1
rs2 = signRep n2
rsf = signRep nf
lowBits = pred intLargeBase
highBits = complement lowBits
repair = if nf then (\ d -> ...) else (\ d -> ...)
fi (d1 : ds1) (d2 : ds2)
= prepend df dsf
where
df = repair (((d1) `op` (d2)))
dsf = f ds1
ds2
(signRep ((dNat (0)) > d1))
(signRep ((dNat (0)) > d2))
(signRep ((dNat (0)) > df))
fi (ds1@(_ : _)) [] = endOpWithNat ds1
fi [] (ds2@(_ : _)) = endOpWithNat ds2
fi [] [] = []
f (d1 : ds1) (d2 : ds2) s1 s2 sf
= prepend df dsf
where
df = repair (((d1 + s1) `op` (d2 + s2)) - sf)
dsf = f ds1 ds2 (sr s1 d1) (sr s2 d2) (sr sf df)
f (ds1@(_ : _)) [] s1 s2 sf = f1 ds1 s1 s2 sf
f [] (ds2@(_ : _)) s1 s2 sf = f1 ds2 s2 s1 sf
f [] [] s1 s2 sf = f0 s1 s2 sf
f1 i s1 s2 sf
| s1 == sf = if isZero s2 then endOpWithNat i else endOpWithNeg i
f1 [] s1 s2 sf = f0 s1 s2 sf
f1 (d1 : ds1) s1 s2 sf
= prepend df dsf
where
df = repair (((d1 + s1) `op` (s2)) - sf)
dsf = f1 ds1 (sr s1 d1) (s2) (sr sf df)
f0 s1 s2 sf
= fromDInt df
where
df = repair (((s1) `op` (s2)) - sf)
in fi i1 i2 (dNat (0)) (dNat (0)) (dNat (0))
In a lambda abstraction:
\ i1 i2
-> let
n1 = isNegativeInteger i1
n2 = isNegativeInteger i2
nf = n1 `signOp` n2
rs1 = signRep n1
rs2 = signRep n2
rsf = signRep nf
lowBits = pred intLargeBase
highBits = complement lowBits
repair = if ... then ... else ...
fi (d1 : ds1) (d2 : ds2)
= prepend df dsf
where
df = ...
dsf = ...
fi (ds1@(_ : _)) [] = endOpWithNat ds1
fi [] (ds2@(_ : _)) = endOpWithNat ds2
fi [] [] = []
f (d1 : ds1) (d2 : ds2) s1 s2 sf
= prepend df dsf
where
df = ...
dsf = ...
f (ds1@(_ : _)) [] s1 s2 sf = f1 ds1 s1 s2 sf
f [] (ds2@(_ : _)) s1 s2 sf = f1 ds2 s2 s1 sf
f [] [] s1 s2 sf = f0 s1 s2 sf
f1 i s1 s2 sf | s1 == sf = if ... then ... else ...
f1 [] s1 s2 sf = f0 s1 s2 sf
f1 (d1 : ds1) s1 s2 sf
= prepend df dsf
where
df = ...
dsf = ...
f0 s1 s2 sf
= fromDInt df
where
df = ...
in fi i1 i2 (dNat (0)) (dNat (0)) (dNat (0))
In the expression:
\ i1 i2
-> let
n1 = ...
n2 = ...
nf = ...
rs1 = ...
rs2 = ...
rsf = ...
lowBits = ...
highBits = ...
repair = ...
fi (d1 : ds1) (d2 : ds2)
= ...
where
df = ...
dsf = ...
fi (ds1@(_ : _)) [] = ...
fi [] (ds2@(_ : _)) = ...
fi [] [] = ...
f (d1 : ds1) (d2 : ds2) s1 s2 sf
= ...
where
df = ...
dsf = ...
f (ds1@(_ : _)) [] s1 s2 sf = ...
f [] (ds2@(_ : _)) s1 s2 sf = ...
f [] [] s1 s2 sf = ...
f1 i s1 s2 sf | s1 == sf = ...
f1 [] s1 s2 sf = ...
f1 (d1 : ds1) s1 s2 sf
= ...
where
df = ...
dsf = ...
f0 s1 s2 sf
= ...
where
df = ...
in fi i1 i2 (dNat (0)) (dNat (0)) (dNat (0))
```
Possibly the pretty-printer needs to know how to replace a long stretch of layout-expressions that aren't relevant to, or even very close to, the error, with "`...`". Maybe something like (assuming I haven't misinterpreted where the error is coming from) :
```
In the expression:
let
n1 = isNegativeInteger i1
...
f0 s1 s2 sf
= fromDInt df
where
df = repair (((s1) `op` (s2)) - sf)
in fi i1 i2 (dNat (0)) (dNat (0)) (dNat (0))
```
Maybe if the contexts are greater than a certain length, GHC shouldn't print three of them, just two or one, also?
Also the "In a lambda abstraction" and the following "In the expression" appear to be followed by the same thing, except with more parts replaced with "`...`" in the "expression". This is part of a function definition `tcBinOpInteger op signOp endOpWithNat endOpWithNeg = \i1 i2 -> let` so, in this case, there _is no_ larger expression than the lambda abstraction...
By the way, the error's reported location was the "fi" right after the let's "in", and my coding mistake was that I shouldn't have been passing the three "zero" arguments. That was not helped at all in this case by thinking about those contexts... I can look at my own code! It would help if the part referred to by the error message's location was highlighted somehow (though that seems hard to do with plain text?)
Tested in 6.6.1 and 6.7.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.6.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | Unknown |
| Architecture | Unknown |
</details>
<!-- {"blocked_by":[],"summary":"excessively long, redundant, compile-error-message contexts","status":"New","operating_system":"Unknown","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.6.1","keywords":[],"differentials":[],"test_case":"","architecture":"Unknown","cc":[""],"type":"Bug","description":"This is one single error message, with no good reason to go over, say, 24 lines...\r\n\r\n(I thought there was a related bug report about long do-blocks in error messages, but I couldn't find it.)\r\n\r\n{{{\r\nIntegerInTermsOfInt.hs:2233:5:\r\n Couldn't match expected type `DInt -> DInt -> DInt -> [DInt]'\r\n against inferred type `[DInt]'\r\n In the expression:\r\n let\r\n n1 = isNegativeInteger i1\r\n n2 = isNegativeInteger i2\r\n nf = n1 `signOp` n2\r\n rs1 = signRep n1\r\n rs2 = signRep n2\r\n rsf = signRep nf\r\n lowBits = pred intLargeBase\r\n highBits = complement lowBits\r\n repair = if nf then (\\ d -> ...) else (\\ d -> ...)\r\n fi (d1 : ds1) (d2 : ds2)\r\n = prepend df dsf\r\n where\r\n df = repair (((d1) `op` (d2)))\r\n dsf = f ds1\r\n ds2\r\n (signRep ((dNat (0)) > d1))\r\n (signRep ((dNat (0)) > d2))\r\n (signRep ((dNat (0)) > df))\r\n fi (ds1@(_ : _)) [] = endOpWithNat ds1\r\n fi [] (ds2@(_ : _)) = endOpWithNat ds2\r\n fi [] [] = []\r\n f (d1 : ds1) (d2 : ds2) s1 s2 sf\r\n = prepend df dsf\r\n where\r\n df = repair (((d1 + s1) `op` (d2 + s2)) - sf)\r\n dsf = f ds1 ds2 (sr s1 d1) (sr s2 d2) (sr sf df)\r\n f (ds1@(_ : _)) [] s1 s2 sf = f1 ds1 s1 s2 sf\r\n f [] (ds2@(_ : _)) s1 s2 sf = f1 ds2 s2 s1 sf\r\n f [] [] s1 s2 sf = f0 s1 s2 sf\r\n f1 i s1 s2 sf\r\n | s1 == sf = if isZero s2 then endOpWithNat i else endOpWithNeg i\r\n f1 [] s1 s2 sf = f0 s1 s2 sf\r\n f1 (d1 : ds1) s1 s2 sf\r\n = prepend df dsf\r\n where\r\n df = repair (((d1 + s1) `op` (s2)) - sf)\r\n dsf = f1 ds1 (sr s1 d1) (s2) (sr sf df)\r\n f0 s1 s2 sf\r\n = fromDInt df\r\n where\r\n df = repair (((s1) `op` (s2)) - sf)\r\n in fi i1 i2 (dNat (0)) (dNat (0)) (dNat (0))\r\n In a lambda abstraction:\r\n \\ i1 i2\r\n -> let\r\n n1 = isNegativeInteger i1\r\n n2 = isNegativeInteger i2\r\n nf = n1 `signOp` n2\r\n rs1 = signRep n1\r\n rs2 = signRep n2\r\n rsf = signRep nf\r\n lowBits = pred intLargeBase\r\n highBits = complement lowBits\r\n repair = if ... then ... else ...\r\n fi (d1 : ds1) (d2 : ds2)\r\n = prepend df dsf\r\n where\r\n df = ...\r\n dsf = ...\r\n fi (ds1@(_ : _)) [] = endOpWithNat ds1\r\n fi [] (ds2@(_ : _)) = endOpWithNat ds2\r\n fi [] [] = []\r\n f (d1 : ds1) (d2 : ds2) s1 s2 sf\r\n = prepend df dsf\r\n where\r\n df = ...\r\n dsf = ...\r\n f (ds1@(_ : _)) [] s1 s2 sf = f1 ds1 s1 s2 sf\r\n f [] (ds2@(_ : _)) s1 s2 sf = f1 ds2 s2 s1 sf\r\n f [] [] s1 s2 sf = f0 s1 s2 sf\r\n f1 i s1 s2 sf | s1 == sf = if ... then ... else ...\r\n f1 [] s1 s2 sf = f0 s1 s2 sf\r\n f1 (d1 : ds1) s1 s2 sf\r\n = prepend df dsf\r\n where\r\n df = ...\r\n dsf = ...\r\n f0 s1 s2 sf\r\n = fromDInt df\r\n where\r\n df = ...\r\n in fi i1 i2 (dNat (0)) (dNat (0)) (dNat (0))\r\n In the expression:\r\n \\ i1 i2\r\n -> let\r\n n1 = ...\r\n n2 = ...\r\n nf = ...\r\n rs1 = ...\r\n rs2 = ...\r\n rsf = ...\r\n lowBits = ...\r\n highBits = ...\r\n repair = ...\r\n fi (d1 : ds1) (d2 : ds2)\r\n = ...\r\n where\r\n df = ...\r\n dsf = ...\r\n fi (ds1@(_ : _)) [] = ...\r\n fi [] (ds2@(_ : _)) = ...\r\n fi [] [] = ...\r\n f (d1 : ds1) (d2 : ds2) s1 s2 sf\r\n = ...\r\n where\r\n df = ...\r\n dsf = ...\r\n f (ds1@(_ : _)) [] s1 s2 sf = ...\r\n f [] (ds2@(_ : _)) s1 s2 sf = ...\r\n f [] [] s1 s2 sf = ...\r\n f1 i s1 s2 sf | s1 == sf = ...\r\n f1 [] s1 s2 sf = ...\r\n f1 (d1 : ds1) s1 s2 sf\r\n = ...\r\n where\r\n df = ...\r\n dsf = ...\r\n f0 s1 s2 sf\r\n = ...\r\n where\r\n df = ...\r\n in fi i1 i2 (dNat (0)) (dNat (0)) (dNat (0))\r\n}}}\r\n\r\nPossibly the pretty-printer needs to know how to replace a long stretch of layout-expressions that aren't relevant to, or even very close to, the error, with \"`...`\". Maybe something like (assuming I haven't misinterpreted where the error is coming from) :\r\n\r\n{{{\r\n In the expression:\r\n let\r\n n1 = isNegativeInteger i1\r\n ...\r\n f0 s1 s2 sf\r\n = fromDInt df\r\n where\r\n df = repair (((s1) `op` (s2)) - sf)\r\n in fi i1 i2 (dNat (0)) (dNat (0)) (dNat (0))\r\n}}}\r\n\r\nMaybe if the contexts are greater than a certain length, GHC shouldn't print three of them, just two or one, also?\r\n\r\nAlso the \"In a lambda abstraction\" and the following \"In the expression\" appear to be followed by the same thing, except with more parts replaced with \"`...`\" in the \"expression\". This is part of a function definition {{{tcBinOpInteger op signOp endOpWithNat endOpWithNeg = \\i1 i2 -> let}}} so, in this case, there _is no_ larger expression than the lambda abstraction...\r\n\r\nBy the way, the error's reported location was the \"fi\" right after the let's \"in\", and my coding mistake was that I shouldn't have been passing the three \"zero\" arguments. That was not helped at all in this case by thinking about those contexts... I can look at my own code! It would help if the part referred to by the error message's location was highlighted somehow (though that seems hard to do with plain text?)\r\n\r\nTested in 6.6.1 and 6.7.","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/1607seq can make code slower2019-07-07T19:12:38ZSimon Peyton Jonesseq can make code slowerAdrian Hey produced a program that goes a little slower when he added "!" annotations to his data constructors. This was a surprise to me, but I understand why now. This bug report just captures the problem so that I don't forget about i...Adrian Hey produced a program that goes a little slower when he added "!" annotations to his data constructors. This was a surprise to me, but I understand why now. This bug report just captures the problem so that I don't forget about it. I'm treating it as a "bug" because it really is a performance bug.
The problem turns out to be this. In the attached code, `genPush` looks like this:
```
put E = Z E e0 E
put (N l e r) = putN l e r
put (Z l e r) = putZ l e r
put (P l e r) = putP l e r
```
With a strict data type, we know that 'r' is evaluated, but `putN` (although strict) does not know that its argument is evaluated, so it does an extra and unnecessary eval.
There are two difficulties. First, most of the time we don’t want to require that a strict function gets an evaluated argument. E.g. map is strict, but it does its own 'case' on the list arg, and we don't want the caller to have to do that too. What we're trying to catch is the calls to 'seq' when the caller already knows that.
If we could spot these cases, then we could w/w the function to expose the 'seq' to the caller. I'm not sure how we'd explain to the callee that the arg was definitely evaluated.
How to spot the cases? We want to spot function bodies that only 'seq' their argument without doing a proper case or function applications. Sounds like enriching the demand domain (again!).
Simon
The attached code demonstrates the problem. There are two versions of AVL routines..
AVL.hs (no strictness annotation in data type, explicit seqs instead) StrictAVL.hs (uses strictness annotation instead of seqs)
Running BUILD.BAT generates 2 executables..
```
Lazy.exe which uses AVL.hs
Strict.exe which uses StrictAVL.hs
```
These test the execution times of the `genWriteFast` and genPush functions defined in modules `AVL.hs` and `StrictAVL.hs` respectively.
For genWriteFast the two tests give virtually identical times (as expected). But for some reason the version of `genPush` using strictness annotation instead of explicit seqs seems to take about 15% longer.
The size of the object file seems a bit bigger too.
The fact that `genWriteFast` times are the same seems to indicate that my original hypothesis is wrong, but there's something strange about the `genPush` from `StrictAVL.hs`.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.6.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | Unknown |
| Architecture | Unknown |
</details>
<!-- {"blocked_by":[],"summary":"seq can make code slower","status":"New","operating_system":"Unknown","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.6.1","keywords":[],"differentials":[],"test_case":"","architecture":"Unknown","cc":[""],"type":"Bug","description":"Adrian Hey produced a program that goes a little slower when he added \"!\" annotations to his data constructors. This was a surprise to me, but I understand why now. This bug report just captures the problem so that I don't forget about it. I'm treating it as a \"bug\" because it really is a performance bug.\r\n\r\nThe problem turns out to be this. In the attached code, `genPush` looks like this:\r\n{{{\r\n put E = Z E e0 E\r\n put (N l e r) = putN l e r\r\n put (Z l e r) = putZ l e r\r\n put (P l e r) = putP l e r\r\n}}}\r\nWith a strict data type, we know that 'r' is evaluated, but `putN` (although strict) does not know that its argument is evaluated, so it does an extra and unnecessary eval.\r\n\r\nThere are two difficulties. First, most of the time we don’t want to require that a strict function gets an evaluated argument. E.g. map is strict, but it does its own 'case' on the list arg, and we don't want the caller to have to do that too. What we're trying to catch is the calls to 'seq' when the caller already knows that.\r\n\r\nIf we could spot these cases, then we could w/w the function to expose the 'seq' to the caller. I'm not sure how we'd explain to the callee that the arg was definitely evaluated. \r\n\r\nHow to spot the cases? We want to spot function bodies that only 'seq' their argument without doing a proper case or function applications. Sounds like enriching the demand domain (again!).\r\n\r\nSimon\r\n\r\nThe attached code demonstrates the problem. There are two versions of AVL routines..\r\n\r\nAVL.hs (no strictness annotation in data type, explicit seqs instead) StrictAVL.hs (uses strictness annotation instead of seqs)\r\n\r\nRunning BUILD.BAT generates 2 executables..\r\n{{{\r\nLazy.exe which uses AVL.hs\r\nStrict.exe which uses StrictAVL.hs\r\n}}}\r\nThese test the execution times of the `genWriteFast` and genPush functions defined in modules `AVL.hs` and `StrictAVL.hs` respectively.\r\n\r\nFor genWriteFast the two tests give virtually identical times (as expected). But for some reason the version of `genPush` using strictness annotation instead of explicit seqs seems to take about 15% longer.\r\n\r\nThe size of the object file seems a bit bigger too.\r\n\r\nThe fact that `genWriteFast` times are the same seems to indicate that my original hypothesis is wrong, but there's something strange about the `genPush` from `StrictAVL.hs`.","type_of_failure":"OtherFailure","blocking":[]} -->7.2.1Ian Lynagh <igloo@earth.li>Ian Lynagh <igloo@earth.li>https://gitlab.haskell.org/ghc/ghc/-/issues/1608Newtype deriving error messages coming out too late2019-07-07T19:12:38ZSimon Peyton JonesNewtype deriving error messages coming out too lateConsider this
```
newtype Ego a = Ego a deriving (Ord)
f :: Ord a => Ego a -> Ego a -> Bool
f e1 e2 = e1 < e2
```
GHC 6.7 reports an error like this:
```
Could not deduce (Eq (Ego a)) from the context (Ord a)
arising from a...Consider this
```
newtype Ego a = Ego a deriving (Ord)
f :: Ord a => Ego a -> Ego a -> Bool
f e1 e2 = e1 < e2
```
GHC 6.7 reports an error like this:
```
Could not deduce (Eq (Ego a)) from the context (Ord a)
arising from a use of `<' at Foo10.hs:6:10-16
In the expression: e1 < e2
In the definition of `f': f e1 e2 = e1 < e2
```
This error should have come when you gave the instance decl. The reason is that GHC's newtype deriving is generating an instance like
```
instance Eq (Ego a) => Ord (Ego a)
```
It would make more sense to report the missing instance for Eq right there, rather than abstracting over it.
Thanks to Dougal Stanton for pointing this out: http://www.haskell.org/pipermail/haskell-cafe/2007-August/030224.html
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ----------------------- |
| Version | 6.6.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler (Type checker) |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | Unknown |
| Architecture | Unknown |
</details>
<!-- {"blocked_by":[],"summary":"Newtype deriving error messages coming out too late","status":"New","operating_system":"Unknown","component":"Compiler (Type checker)","related":[],"milestone":"6.10 branch","resolution":"Unresolved","owner":{"tag":"OwnedBy","contents":"simonpj"},"version":"6.6.1","keywords":[],"differentials":[],"test_case":"","architecture":"Unknown","cc":[""],"type":"Bug","description":"Consider this\r\n{{{\r\nnewtype Ego a = Ego a deriving (Ord)\r\n\r\nf :: Ord a => Ego a -> Ego a -> Bool\r\nf e1 e2 = e1 < e2\r\n}}}\r\nGHC 6.7 reports an error like this:\r\n{{{\r\n Could not deduce (Eq (Ego a)) from the context (Ord a)\r\n arising from a use of `<' at Foo10.hs:6:10-16\r\n In the expression: e1 < e2\r\n In the definition of `f': f e1 e2 = e1 < e2\r\n}}}\r\nThis error should have come when you gave the instance decl. The reason is that GHC's newtype deriving is generating an instance like\r\n{{{\r\ninstance Eq (Ego a) => Ord (Ego a)\r\n}}}\r\nIt would make more sense to report the missing instance for Eq right there, rather than abstracting over it.\r\n\r\nThanks to Dougal Stanton for pointing this out: http://www.haskell.org/pipermail/haskell-cafe/2007-August/030224.html","type_of_failure":"OtherFailure","blocking":[]} -->6.10 branchSimon Peyton JonesSimon Peyton Joneshttps://gitlab.haskell.org/ghc/ghc/-/issues/1609spurious gcc warnings with non-english language setting2019-07-07T19:12:38Zchris@chr-breitkopf.despurious gcc warnings with non-english language settingIn Changeset 13765 the warning about a call-clobbered register was filtered out.
This does not work when using a non-english language setting:
$ echo $LANG
de_DE.UTF-8
$ ghc -O -c Test.hs
1. ..
/usr/lib64/ghc-6.6.1/include/Regs.h:220...In Changeset 13765 the warning about a call-clobbered register was filtered out.
This does not work when using a non-english language setting:
$ echo $LANG
de_DE.UTF-8
$ ghc -O -c Test.hs
1. ..
/usr/lib64/ghc-6.6.1/include/Regs.h:220:0:
> Warnung: für Ruf vorgesehenes Register wurde für globale Registervariable verwendet
1. ..
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.6.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | low |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"spurious gcc warnings with non-english language setting","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.6.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"In Changeset 13765 the warning about a call-clobbered register was filtered out.\r\n\r\nThis does not work when using a non-english language setting:\r\n\r\n$ echo $LANG\r\nde_DE.UTF-8\r\n$ ghc -O -c Test.hs\r\n...\r\n/usr/lib64/ghc-6.6.1/include/Regs.h:220:0:\r\n Warnung: für Ruf vorgesehenes Register wurde für globale Registervariable verwendet\r\n...","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/1610Make arrays safer2019-07-07T19:12:38ZIan Lynagh <igloo@earth.li>Make arrays saferThis is a proposal to make arrays safer (e.g. see #1046).
This is a divergence from Haskell 98.
The patches:
- Add (numElements :: Ix i =\> a i e -\> Int) to IArray class
- Array types get an extra field for numElements, e.g.
`
...This is a proposal to make arrays safer (e.g. see #1046).
This is a divergence from Haskell 98.
The patches:
- Add (numElements :: Ix i =\> a i e -\> Int) to IArray class
- Array types get an extra field for numElements, e.g.
`
-data UArray i e = UArray !i !i ByteArray#
+data UArray i e = UArray !i !i !Int ByteArray#
`
This is a cache of rangeSize(l,u)
- Add safeRangeSize (always returns \>= 0)
- Add safeIndex (use unsafeIndex (no Ix inRange check), but check index \< numElements)
- unsafeForeignPtrToStorableArray gained an (Ix i) context
- Use the new functions in various places
Suggested deadline: 24 Aug 2007.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ----------------- |
| Version | 6.6.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | high |
| Resolution | Unresolved |
| Component | libraries (other) |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | Unknown |
| Architecture | Unknown |
</details>
<!-- {"blocked_by":[],"summary":"Make arrays safer","status":"New","operating_system":"Unknown","component":"libraries (other)","related":[],"milestone":"6.8 branch","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.6.1","keywords":[],"differentials":[],"test_case":"","architecture":"Unknown","cc":[""],"type":"Bug","description":"This is a proposal to make arrays safer (e.g. see #1046).\r\n\r\nThis is a divergence from Haskell 98.\r\n\r\nThe patches:\r\n\r\n * Add (numElements :: Ix i => a i e -> Int) to IArray class\r\n * Array types get an extra field for numElements, e.g.\r\n {{{\r\n -data UArray i e = UArray !i !i ByteArray#\r\n +data UArray i e = UArray !i !i !Int ByteArray#\r\n }}}\r\n This is a cache of rangeSize(l,u)\r\n * Add safeRangeSize (always returns >= 0)\r\n * Add safeIndex (use unsafeIndex (no Ix inRange check), but check index < numElements)\r\n * unsafeForeignPtrToStorableArray gained an (Ix i) context\r\n * Use the new functions in various places\r\n\r\nSuggested deadline: 24 Aug 2007.","type_of_failure":"OtherFailure","blocking":[]} -->6.8.1Ian Lynagh <igloo@earth.li>Ian Lynagh <igloo@earth.li>