GHC issueshttps://gitlab.haskell.org/ghc/ghc/-/issues2024-01-08T08:09:07Zhttps://gitlab.haskell.org/ghc/ghc/-/issues/2143Yhc's sort is faster than GHC's2024-01-08T08:09:07ZNeil MitchellYhc's sort is faster than GHC'sThe sort code in the Yhc libraries is faster than GHC. In some cases its asymptotically better. Some benchmarks have shown a doubling in performance. I know why this is, but will need to make sure the code is as good as it can be, check ...The sort code in the Yhc libraries is faster than GHC. In some cases its asymptotically better. Some benchmarks have shown a doubling in performance. I know why this is, but will need to make sure the code is as good as it can be, check all the benchmarks agree etc.
Original work by Ian: http://www.haskell.org/pipermail/glasgow-haskell-users/2002-May/003376.html
I will track this down and aim for a libraries proposal in a month or so.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 6.8.2 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | libraries/base |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | Unknown |
| Architecture | Unknown |
</details>
<!-- {"blocked_by":[],"summary":"Yhc's sort is faster than GHC's","status":"New","operating_system":"Unknown","component":"libraries/base","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"OwnedBy","contents":"NeilMitchell"},"version":"6.8.2","keywords":[],"differentials":[],"test_case":"","architecture":"Unknown","cc":[""],"type":"Bug","description":"The sort code in the Yhc libraries is faster than GHC. In some cases its asymptotically better. Some benchmarks have shown a doubling in performance. I know why this is, but will need to make sure the code is as good as it can be, check all the benchmarks agree etc.\r\n\r\nOriginal work by Ian: http://www.haskell.org/pipermail/glasgow-haskell-users/2002-May/003376.html\r\n\r\nI will track this down and aim for a libraries proposal in a month or so.","type_of_failure":"OtherFailure","blocking":[]} -->Not GHCIan Lynagh <igloo@earth.li>Ian Lynagh <igloo@earth.li>https://gitlab.haskell.org/ghc/ghc/-/issues/4025template-haskell Use named fields in Info2023-06-11T15:26:38Zaavogttemplate-haskell Use named fields in Info## Problem
The meaning of the fields for constructors of Language.Haskell.TH.Syntax.Info must be guessed.
See #1576
## Proposed Change
Naming the fields for each constructor helps reduce this confusion. Compare documentations:
**New...## Problem
The meaning of the fields for constructors of Language.Haskell.TH.Syntax.Info must be guessed.
See #1576
## Proposed Change
Naming the fields for each constructor helps reduce this confusion. Compare documentations:
**New**
http://code.haskell.org/\~aavogt/libraries/template-haskell/Language-Haskell-TH-Syntax.html\#t%3AInfo
**Old**
http://www.haskell.org/ghc/docs/latest/html/libraries/template-haskell-2.4.0.1/Language-Haskell-TH-Syntax.html\#t%3AInfo
## Issues
The Show instance changes (no Read).
Namespace conflicts.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 6.12.2 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | libraries/base |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"template-haskell Use named fields in Info","status":"New","operating_system":"","component":"libraries/base","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.12.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"\r\n== Problem ==\r\n\r\n\r\nThe meaning of the fields for constructors of Language.Haskell.TH.Syntax.Info must be guessed.\r\n\r\nSee #1576\r\n\r\n\r\n== Proposed Change ==\r\n\r\nNaming the fields for each constructor helps reduce this confusion. Compare documentations:\r\n\r\n\r\n'''New'''\r\n\r\nhttp://code.haskell.org/~aavogt/libraries/template-haskell/Language-Haskell-TH-Syntax.html#t%3AInfo\r\n\r\n'''Old'''\r\n\r\nhttp://www.haskell.org/ghc/docs/latest/html/libraries/template-haskell-2.4.0.1/Language-Haskell-TH-Syntax.html#t%3AInfo\r\n\r\n\r\n\r\n== Issues ==\r\n\r\nThe Show instance changes (no Read).\r\n\r\nNamespace conflicts.","type_of_failure":"OtherFailure","blocking":[]} -->Not GHChttps://gitlab.haskell.org/ghc/ghc/-/issues/4282Proposal: make Data.List.intersperse and intercalate less strict2021-08-05T16:39:49Zdaniel.is.fischerProposal: make Data.List.intersperse and intercalate less strictIt is proposed that `intersperse` and `intercalate` be changed to be less strict.
Period of discussion: Two weeks, until 30 Sep. 2010.
A patch is attached to this ticket. See also the [mailing list discussion thread](http://www.haskell...It is proposed that `intersperse` and `intercalate` be changed to be less strict.
Period of discussion: Two weeks, until 30 Sep. 2010.
A patch is attached to this ticket. See also the [mailing list discussion thread](http://www.haskell.org/pipermail/libraries/2010-September/014293.html).
This change is in keeping with the spirit of the Haskell98 List module, which is for list functions to be as lazy as possible (unless there are good reasons otherwise). There are use cases where the current overly-strict versions are problematic. In addition, the more lazy versions are slightly more efficient.
current implementation:
```
intersperse :: a -> [a] -> [a]
intersperse _ [] = []
intersperse _ [x] = [x]
intersperse sep (x:xs) = x : sep : intersperse sep xs
```
current strictness properties:
```
intersperse _ _|_ = _|_
intersperse _ (x :_|_) = _|_
intersperse sep (x:y:_|_) = x : sep : _|_
```
proposed implementation:
```
intersperse :: a -> [a] -> [a]
intersperse _ [] = []
intersperse sep (x:xs) = x : go xs
where
go [] = []
go (y:ys) = sep : y : go ys
```
strictness properties after change:
```
intersperse _ _|_ = _|_
intersperse _ (x:_|_) = x : _|_
intersperse sep (x:y:_|_) = x : sep : y : _|_
```
current and proposed implementation of `intercalate`:
```
intercalate :: [a] -> [[a]] -> [a]
intercalate sep xss = concat (intersperse sep xss)
```
current strictness properties:
```
intercalate _ _|_ = _|_
intercalate _ (xs:_|_) = _|_
intercalate sep (xs:ys:_|_) = xs ++ sep ++ _|_
```
strictness properties after proposed change to `intersperse`:
```
intercalate _ _|_ = _|_
intercalate _ (xs:_|_) = xs ++ _|_
intercalate sep (xs:ys:_|_) = xs ++ sep ++ ys ++ _|_
```Not GHChttps://gitlab.haskell.org/ghc/ghc/-/issues/4095add Applicative instance for Either2021-02-09T17:14:58ZRoss Patersonr.paterson@city.ac.ukadd Applicative instance for EitherThe proposal is to add this instance to Control.Applicative:
```
instance Applicative (Either e) where
pure = Right
Left e <*> _ = Left e
Right f <*> r = fmap f r
```
This is not the only possible inst...The proposal is to add this instance to Control.Applicative:
```
instance Applicative (Either e) where
pure = Right
Left e <*> _ = Left e
Right f <*> r = fmap f r
```
This is not the only possible instance for Either, but this one is compatible with the usual Monad instance.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 6.12.2 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | libraries/base |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"add Applicative instance for Either","status":"New","operating_system":"","component":"libraries/base","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.12.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"The proposal is to add this instance to Control.Applicative:\r\n{{{\r\ninstance Applicative (Either e) where\r\n pure = Right\r\n Left e <*> _ = Left e\r\n Right f <*> r = fmap f r\r\n}}}\r\nThis is not the only possible instance for Either, but this one is compatible with the usual Monad instance.","type_of_failure":"OtherFailure","blocking":[]} -->Not GHChttps://gitlab.haskell.org/ghc/ghc/-/issues/1590Libraries proposal: Add System.Info.isWindows2019-09-16T11:13:41ZneilLibraries proposal: Add System.Info.isWindowsCurrently the recognised way to test if your application is being run on Windows is:
```
import System.Info
.... = os == "mingw"
```
This is wrong on so many levels!
\# The return result of os is NOT an operating system
\# The result...Currently the recognised way to test if your application is being run on Windows is:
```
import System.Info
.... = os == "mingw"
```
This is wrong on so many levels!
\# The return result of os is NOT an operating system
\# The result mingw does not imply that mingw is installed
\# String comparisons are not very safe, a typo stops this working
\# In GHC this comparison will take place at runtime, even though its a constant
Since nearly all uses of System.Info.os are to check if the operating system is Windows, adding an explicit isWindows function would simplify things.
Proposal:
Add System.Info.isWindows :: Bool
This value should return True on all Windows systems (Win 1.0 ... Vista), and False on all other systems.
Deadline:
2 weeks from the end of discussion. Please discuss on the libraries@ mailing list.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------------- |
| Version | |
| Type | FeatureRequest |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | libraries/base |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | ndmitchell@gmail.com |
| Operating system | Unknown |
| Architecture | Unknown |
</details>
<!-- {"blocked_by":[],"summary":"Libraries proposal: Add System.Info.isWindows","status":"New","operating_system":"Unknown","component":"libraries/base","related":[],"milestone":"Not GHC","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"","keywords":[],"differentials":[],"test_case":"","architecture":"Unknown","cc":["ndmitchell@gmail.com"],"type":"FeatureRequest","description":"Currently the recognised way to test if your application is being run on Windows is:\r\n\r\n{{{\r\nimport System.Info\r\n\r\n.... = os == \"mingw\"\r\n}}}\r\n\r\nThis is wrong on so many levels!\r\n\r\n# The return result of os is NOT an operating system\r\n# The result mingw does not imply that mingw is installed\r\n# String comparisons are not very safe, a typo stops this working\r\n# In GHC this comparison will take place at runtime, even though its a constant\r\n\r\nSince nearly all uses of System.Info.os are to check if the operating system is Windows, adding an explicit isWindows function would simplify things.\r\n\r\nProposal:\r\n\r\nAdd System.Info.isWindows :: Bool\r\n\r\nThis value should return True on all Windows systems (Win 1.0 ... Vista), and False on all other systems.\r\n\r\nDeadline:\r\n\r\n2 weeks from the end of discussion. Please discuss on the libraries@ mailing list.","type_of_failure":"OtherFailure","blocking":[]} -->Not GHChttps://gitlab.haskell.org/ghc/ghc/-/issues/309ObjectIO-Lib: Problem scrolling compund control2019-07-07T19:18:32ZbrasselObjectIO-Lib: Problem scrolling compund control```
Problem 1:
When using the ObjectIO library, setting the view
domain of a compund control does not correctly adjust
the min/max settings of the corresponding scroll-sliders.
Problem 2:
When trying to work around this bug, it turns ou...```
Problem 1:
When using the ObjectIO library, setting the view
domain of a compund control does not correctly adjust
the min/max settings of the corresponding scroll-sliders.
Problem 2:
When trying to work around this bug, it turns out that
you can only set the scroll function for Horizontal
scrolling but not for Vertical scrolling.
Do you need an example programs for the bugs?
```Not GHCkrasimirkrasimirhttps://gitlab.haskell.org/ghc/ghc/-/issues/408OpenAL needs -pthread2019-07-07T19:18:07ZvolkersfOpenAL needs -pthread```
On FreeBSD (and maybe NetBSD as well), OpenAL needs -pthread in
CFLAGS/LDFLAGS:
configure:2352: gcc -o conftest -I/usr/local/include -L/usr/local/lib
conftest.c -lopenal >&5
/usr/local/lib/libopenal.so: undefined reference to...```
On FreeBSD (and maybe NetBSD as well), OpenAL needs -pthread in
CFLAGS/LDFLAGS:
configure:2352: gcc -o conftest -I/usr/local/include -L/usr/local/lib
conftest.c -lopenal >&5
/usr/local/lib/libopenal.so: undefined reference to `pthread_create'
/usr/local/lib/libopenal.so: undefined reference to `pthread_attr_init'
/usr/local/lib/libopenal.so: undefined reference to `pthread_exit'
This should best be solved during configure instead of setting this
globally. Also, this probably needs to be propagated into OpenAL.
cabal for linking a resulting application (although already the RTS
should pull in -pthread).
```Not GHCpannepannehttps://gitlab.haskell.org/ghc/ghc/-/issues/471Windows HGL Thread problems2019-07-07T19:17:50ZmjthomasWindows HGL Thread problems```
With CVS HEAD (19 October 2005 Australian morning)
the following minimal modifications to the HGL library
give a runtime error in the "GTest.exe" example program:
=======================================
...
handleEvent: Before get...```
With CVS HEAD (19 October 2005 Australian morning)
the following minimal modifications to the HGL library
give a runtime error in the "GTest.exe" example program:
=======================================
...
handleEvent: Before getMessage.
handleEvent: Before yield.
GTest.exe: internal error: resumeThread: thread not
found
Please report this as a bug to glasgow-haskell-
bugs@haskell.org,
or http://www.sourceforge.net/projects/ghc/
=======================================
Without those two putStrLn () calls, none of the three
example programs "GTests.exe", "Tests.exe"
or "HelloWorld.exe" displays a Window.
With those two putStrLn () calls, all three example
programs present their windows and both "Tests.exe"
and "HelloWorld.exe" appear to run perfectly (although
note that I have not seen them running at all other than
in these tests).
Cheers
Mike Thomas
=========================================
==========================
RCS
file: /home/cvs/root/fptools/libraries/HGL/Graphics/HGL/
Win32/WND.hs,v
retrieving revision 1.9
diff -r1.9 WND.hs
130a131
> putStrLn "handleEvent: Before yield."
133a135
> putStrLn "handleEvent: Before getMessage."
```Not GHChttps://gitlab.haskell.org/ghc/ghc/-/issues/476HUnit treats failures as errors2019-07-07T19:17:49ZstefanheimannHUnit treats failures as errors```
HUnit treats a failure in a testcase as an error. I
attached a patch that fixes the problem. I tested the
patch with ghc and hugs.
``````
HUnit treats a failure in a testcase as an error. I
attached a patch that fixes the problem. I tested the
patch with ghc and hugs.
```Not GHCrichardg@richardg.namerichardg@richardg.namehttps://gitlab.haskell.org/ghc/ghc/-/issues/590hsc2hs: quoting of macro arguments containing commas2019-07-07T19:17:44ZDimitry Golubovsky <golubovsky@gmail.com>hsc2hs: quoting of macro arguments containing commas```
I came across the following issue in hsc2hs:
when requesting a size of a C structure with #size (or similarly this
may apply to #peek, #poke, #offset macros), and the structure is
declared "anonymously", and contains multiple field ...```
I came across the following issue in hsc2hs:
when requesting a size of a C structure with #size (or similarly this
may apply to #peek, #poke, #offset macros), and the structure is
declared "anonymously", and contains multiple field declaration of the
same type such as:
struct {int ab,cd;}
then #size(struct {int ab,cd;}) will result in
hsc_size(struct {int ab,cd;})
which will fail because of the comma inside the structure makes the
macro recognize 2 arguments instead of 1.
GCC's preprocessor allows variadic macros defined like
#define __quote__(x...) x
If hsc_size is called:
hsc_size(__quote__(struct {int ab,cd;}))
then error does not occur.
Similarly:
hsc_peek(__quote__(struct {int ab,cd;}),cd)
because __quote__ is scanned first, and its result is treated as a
single argument.
I looked through cpp.info, but could not find any other way to quote
macro arguments.
Is it possible to update hsc2hs (Main.hs I believe) to emit macro
calls involving C types in the way described above?
i. e. #size(t) becomes hsc_size(__quote__(t)),
#peek(t,f) becomes hsc_peek(__quote__(t),f) etc.
when hsc2hs generates the C file from a hsc source.
PS I am working with hsc2hs from the GHC 6.2.2 distribution. I
couldn't find such fixes in the changelog since then.
I believe, the person maintaining hsc2hs might be able to implement
these fixes faster than if I tried.
PPS This will work with GCC, but I am not sure abouth other compilers
(like Microsoft C)
--
Dimitry Golubovsky
Anywhere on the Web
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.4.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | None |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"hsc2hs: quoting of macro arguments containing commas","status":"New","operating_system":"","component":"None","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.4.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"{{{\r\nI came across the following issue in hsc2hs:\r\n\r\nwhen requesting a size of a C structure with #size (or similarly this\r\nmay apply to #peek, #poke, #offset macros), and the structure is\r\ndeclared \"anonymously\", and contains multiple field declaration of the\r\nsame type such as:\r\n\r\nstruct {int ab,cd;}\r\n\r\nthen #size(struct {int ab,cd;}) will result in\r\n\r\nhsc_size(struct {int ab,cd;})\r\n\r\nwhich will fail because of the comma inside the structure makes the\r\nmacro recognize 2 arguments instead of 1.\r\n\r\nGCC's preprocessor allows variadic macros defined like\r\n\r\n#define __quote__(x...) x\r\n\r\nIf hsc_size is called:\r\n\r\nhsc_size(__quote__(struct {int ab,cd;}))\r\n\r\nthen error does not occur.\r\n\r\nSimilarly:\r\n\r\nhsc_peek(__quote__(struct {int ab,cd;}),cd)\r\n\r\nbecause __quote__ is scanned first, and its result is treated as a\r\nsingle argument.\r\n\r\nI looked through cpp.info, but could not find any other way to quote\r\nmacro arguments.\r\n\r\nIs it possible to update hsc2hs (Main.hs I believe) to emit macro\r\ncalls involving C types in the way described above?\r\n\r\ni. e. #size(t) becomes hsc_size(__quote__(t)),\r\n#peek(t,f) becomes hsc_peek(__quote__(t),f) etc.\r\n\r\nwhen hsc2hs generates the C file from a hsc source.\r\n\r\nPS I am working with hsc2hs from the GHC 6.2.2 distribution. I\r\ncouldn't find such fixes in the changelog since then.\r\n\r\nI believe, the person maintaining hsc2hs might be able to implement\r\nthese fixes faster than if I tried.\r\n\r\nPPS This will work with GCC, but I am not sure abouth other compilers\r\n(like Microsoft C)\r\n\r\n-- \r\nDimitry Golubovsky\r\n\r\nAnywhere on the Web\r\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->Not GHCIan Lynagh <igloo@earth.li>Ian Lynagh <igloo@earth.li>https://gitlab.haskell.org/ghc/ghc/-/issues/666Collection hierarchy proposal2019-07-07T19:17:31ZjpbernardyCollection hierarchy proposalWell, i am as user of libraries just wants consistency of using
different data structures for the same tasks. for example, i want to
have one indexing operator instead of !, !! and find. so, it's my
hope-list:
1. all collections are div...Well, i am as user of libraries just wants consistency of using
different data structures for the same tasks. for example, i want to
have one indexing operator instead of !, !! and find. so, it's my
hope-list:
1. all collections are divided into 3-4 classes: arrays/lists, maps and sets. arrays/lists have sequential indexes in some range while maps have sparse indexes. also each class have an Updatable subclass
1. collections in one class can be collected to each other with one (better universal) operator, such as:
```
let list = cvt array
let tree = cvt map
}}}
3. collections can be converted to/from Updatable subclass with help of usual freeze/thaw operators
4. all operations which are currently implemented in Data.List, Array.*, Map, Set, HashTable modules must be bound to one of these classes, with duplicates (such as !/!!) removed. now i see the following class hierarchy:
{{{
Collection (map, size, values)
SetLike (union, diff)
Set
Map
Indexed (indexes, !)
Map
Sequential (reverse, head)
Array
List (tail)
```
i give in parentheses examples of operations which are supported on each level of hierarchy
this will give possibility to write datastructure-independent algorithms and easily convert data to the data type which are best for each part of the program, smthg like:
```
a :: Map Int String <- read str
algorithm1 a
let b :: Hash Int String <- cvt a
algorithm2 b
c :: HashTable Int String <- thaw b
algorithm3 c
```Not GHCjpbernardyjpbernardyhttps://gitlab.haskell.org/ghc/ghc/-/issues/667Efficient Map <-> Set conversions2019-07-07T19:17:31ZjpbernardyEfficient Map <-> Set conversionsWe should be able to convert a Set into a Map without re-computation of the tree Shape. (initially proposed by John Meacham)We should be able to convert a Set into a Map without re-computation of the tree Shape. (initially proposed by John Meacham)Not GHCjpbernardyjpbernardyhttps://gitlab.haskell.org/ghc/ghc/-/issues/691Make the testsuite standalone2019-07-07T19:17:24ZSimon MarlowMake the testsuite standaloneThe testsuite uses very little from the fptools framework, and could quite easily be made standalone. This would have a few benefits:
- People could download it from darcs without having a GHC source tree, add tests
and submit them u...The testsuite uses very little from the fptools framework, and could quite easily be made standalone. This would have a few benefits:
- People could download it from darcs without having a GHC source tree, add tests
and submit them using 'darcs send', or attach the darcs patch to a bug report.
- It would be a step in the right direction towards making the test suite more
compiler-independent
- We could ask people to grab a testsuite and do 'make fast', as a quick
verification of their GHC installation.
- Might this be a good framework for building a set of Haskell' conformance
tests?
When this is done, we should also have a wiki page for the testsuite describing how to get it and use it.
A nice little project for someone?
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.4.1 |
| Type | Task |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Test Suite |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | Unknown |
| Architecture | Unknown |
</details>
<!-- {"blocked_by":[],"summary":"Make the testsuite standalone","status":"New","operating_system":"Unknown","component":"Test Suite","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.4.1","keywords":[],"differentials":[],"test_case":"","architecture":"Unknown","cc":[""],"type":"Task","description":"The testsuite uses very little from the fptools framework, and could quite easily be made standalone. This would have a few benefits:\r\n\r\n * People could download it from darcs without having a GHC source tree, add tests\r\n and submit them using 'darcs send', or attach the darcs patch to a bug report.\r\n\r\n * It would be a step in the right direction towards making the test suite more\r\n compiler-independent\r\n\r\n * We could ask people to grab a testsuite and do 'make fast', as a quick\r\n verification of their GHC installation.\r\n\r\n * Might this be a good framework for building a set of Haskell' conformance\r\n tests?\r\n\r\nWhen this is done, we should also have a wiki page for the testsuite describing how to get it and use it.\r\n\r\nA nice little project for someone?","type_of_failure":"OtherFailure","blocking":[]} -->Not GHChttps://gitlab.haskell.org/ghc/ghc/-/issues/692Incorporate programs from the shootout in nofib2019-07-07T19:17:24ZSimon MarlowIncorporate programs from the shootout in nofibWe should have all the shootout benchmarks in nofib. They should probably go in a separate category, since most of them use GHC-specific features.
<details><summary>Trac metadata</summary>
| Trac field | Value ...We should have all the shootout benchmarks in nofib. They should probably go in a separate category, since most of them use GHC-specific features.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | --------------------- |
| Version | 6.4.1 |
| Type | Task |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | NoFib benchmark suite |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | Unknown |
| Architecture | Unknown |
</details>
<!-- {"blocked_by":[],"summary":"Incorporate programs from the shootout in nofib","status":"New","operating_system":"Unknown","component":"NoFib benchmark suite","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.4.1","keywords":[],"differentials":[],"test_case":"","architecture":"Unknown","cc":[""],"type":"Task","description":"We should have all the shootout benchmarks in nofib. They should probably go in a separate category, since most of them use GHC-specific features.","type_of_failure":"OtherFailure","blocking":[]} -->Not GHChttps://gitlab.haskell.org/ghc/ghc/-/issues/720Map/Set range function2019-07-07T19:17:17ZjpbernardyMap/Set range functionData.Map seems to lack a way to perform range queries
like "fetch all elements between keys low and high".
The naive implementation is easy:
```
range :: Ord k => k -> k -> Map.Map k v -> [(k,v)]
range low high = toList . fst . split hi...Data.Map seems to lack a way to perform range queries
like "fetch all elements between keys low and high".
The naive implementation is easy:
```
range :: Ord k => k -> k -> Map.Map k v -> [(k,v)]
range low high = toList . fst . split high . snd . split low
```
But this is not very fast for larger maps. Maybe
this operation could be provided in Data.Map?Not GHChttps://gitlab.haskell.org/ghc/ghc/-/issues/722Adrian Hey's StringMap library in the collections package.2019-07-07T19:17:16ZjpbernardyAdrian Hey's StringMap library in the collections package.- Bring Adrian Hey's StringMap to a higher level of completeness, so it can be made an instance of the Map class.
- Add an abstraction layer, as close a possible to Data.Map, so it can be a drop-in replacement in most cases.- Bring Adrian Hey's StringMap to a higher level of completeness, so it can be made an instance of the Map class.
- Add an abstraction layer, as close a possible to Data.Map, so it can be a drop-in replacement in most cases.Not GHCAdrian Hey (if he accepts)Adrian Hey (if he accepts)https://gitlab.haskell.org/ghc/ghc/-/issues/742HGL broken on Windows2019-07-07T19:17:10ZguestHGL broken on WindowsThe following program (example from "The Haskell School of Expression") runs very slowly, often taking a couple of minutes to create a window:
```
import Graphics.SOE
main = runGraphics (
do w <- openWindow "Hello" (300,300)
draw...The following program (example from "The Haskell School of Expression") runs very slowly, often taking a couple of minutes to create a window:
```
import Graphics.SOE
main = runGraphics (
do w <- openWindow "Hello" (300,300)
drawInWindow w (text(100,200) "Hello world!")
k <- getKey w
closeWindow w
)
```
Using: GHC 6.4.1 release (msi installer).
System: Windows 2000 sp4, 5.00.2195
GCC: 3.4.2 (mingw-special)
make:
```
C:\Documents and Settings\Administrator\My Documents\progging_projects\Haskell>ghc --make -v -dcore-lint main.hs
Glasgow Haskell Compiler, Version 6.4.1, for Haskell 98, compiled by GHC version 6.4
Using package config file: C:\ghc\ghc-6.4.1\package.conf
Hsc static flags: -static
*** Chasing dependencies:
Chasing modules from: main.hs
Stable modules:
*** Compiling Main ( main.hs, main.o ):
compile: input file main.hs
*** Checking old interface for Main:
Skipping Main ( main.hs, main.o )
*** Deleting temp files
Deleting: C:/DOCUME~1/ADMINI~1/LOCALS~1/Temp/ghc2064.s
Warning: deleting non-existent C:/DOCUME~1/ADMINI~1/LOCALS~1/Temp/ghc2064.s
Upsweep completely successful.
*** Deleting temp files
Deleting:
link: linkables are ...
LinkableM (Mon Apr 10 00:14:25 Eastern Daylight Time 2006) Main
[DotO main.o]
Linking ...
*** Linker
C:\ghc\ghc-6.4.1\gcc -BC:\ghc\ghc-6.4.1\gcc-lib/ -v -o main.exe -DDONT_WANT_WIN32_DLL_SUPPORT main.o -LC:/ghc/ghc-6.4.1
-LC:/ghc/ghc-6.4.1/gcc-lib -lHSHGL -lHSWin32 -lHSWin32_cbits -luser32 -lgdi32 -lwinmm -lkernel32 -ladvapi32 -lHSbase -lH
Sbase_cbits -lwsock32 -lmsvcrt -lkernel32 -luser32 -lshell32 -lHSrts -lm -lgmp -lwsock32 -u _GHCziBase_Izh_static_info -
u _GHCziBase_Czh_static_info -u _GHCziFloat_Fzh_static_info -u _GHCziFloat_Dzh_static_info -u _GHCziPtr_Ptr_static_info
-u _GHCziWord_Wzh_static_info -u _GHCziInt_I8zh_static_info -u _GHCziInt_I16zh_static_info -u _GHCziInt_I32zh_static_inf
o -u _GHCziInt_I64zh_static_info -u _GHCziWord_W8zh_static_info -u _GHCziWord_W16zh_static_info -u _GHCziWord_W32zh_stat
ic_info -u _GHCziWord_W64zh_static_info -u _GHCziStable_StablePtr_static_info -u _GHCziBase_Izh_con_info -u _GHCziBase_C
zh_con_info -u _GHCziFloat_Fzh_con_info -u _GHCziFloat_Dzh_con_info -u _GHCziPtr_Ptr_con_info -u _GHCziPtr_FunPtr_con_in
fo -u _GHCziStable_StablePtr_con_info -u _GHCziBase_False_closure -u _GHCziBase_True_closure -u _GHCziPack_unpackCString
_closure -u _GHCziIOBase_stackOverflow_closure -u _GHCziIOBase_heapOverflow_closure -u _GHCziIOBase_NonTermination_closu
re -u _GHCziIOBase_BlockedOnDeadMVar_closure -u _GHCziIOBase_BlockedIndefinitely_closure -u _GHCziIOBase_Deadlock_closur
e -u _GHCziWeak_runFinalizzerBatch_closure -u ___stginit_Prelude
Reading specs from C:/ghc/ghc-6.4.1/gcc-lib/specs
Configured with: ../gcc/configure --with-gcc --with-gnu-ld --with-gnu-as --host=mingw32 --target=mingw32 --prefix=/mingw
--enable-threads --disable-nls --enable-languages=c,c++,f77,ada,objc,java --disable-win32-registry --disable-shared --e
nable-sjlj-exceptions --enable-libgcj --disable-java-awt --without-x --enable-java-gc=boehm --disable-libgcj-debug --ena
ble-interpreter --enable-hash-synchronization --enable-libstdcxx-debug
Thread model: win32
gcc version 3.4.2 (mingw-special)
C:/ghc/ghc-6.4.1/gcc-lib/collect2.exe -Bdynamic -o main.exe -u _GHCziBase_Izh_static_info -u _GHCziBase_Czh_static_info
-u _GHCziFloat_Fzh_static_info -u _GHCziFloat_Dzh_static_info -u _GHCziPtr_Ptr_static_info -u _GHCziWord_Wzh_static_inf
o -u _GHCziInt_I8zh_static_info -u _GHCziInt_I16zh_static_info -u _GHCziInt_I32zh_static_info -u _GHCziInt_I64zh_static_
info -u _GHCziWord_W8zh_static_info -u _GHCziWord_W16zh_static_info -u _GHCziWord_W32zh_static_info -u _GHCziWord_W64zh_
static_info -u _GHCziStable_StablePtr_static_info -u _GHCziBase_Izh_con_info -u _GHCziBase_Czh_con_info -u _GHCziFloat_F
zh_con_info -u _GHCziFloat_Dzh_con_info -u _GHCziPtr_Ptr_con_info -u _GHCziPtr_FunPtr_con_info -u _GHCziStable_StablePtr
_con_info -u _GHCziBase_False_closure -u _GHCziBase_True_closure -u _GHCziPack_unpackCString_closure -u _GHCziIOBase_sta
ckOverflow_closure -u _GHCziIOBase_heapOverflow_closure -u _GHCziIOBase_NonTermination_closure -u _GHCziIOBase_BlockedOn
DeadMVar_closure -u _GHCziIOBase_BlockedIndefinitely_closure -u _GHCziIOBase_Deadlock_closure -u _GHCziWeak_runFinalizze
rBatch_closure -u ___stginit_Prelude C:/ghc/ghc-6.4.1/gcc-lib/crt2.o C:/ghc/ghc-6.4.1/gcc-lib/crtbegin.o -LC:/ghc/ghc-6.
4.1 -LC:/ghc/ghc-6.4.1/gcc-lib -LC:/ghc/ghc-6.4.1/gcc-lib -L/mingw/lib/gcc/mingw32/3.4.2 -L/mingw/lib/gcc/mingw32/3.4.2/
../../../../mingw32/lib -L/mingw/lib -L/mingw/lib/gcc/mingw32/3.4.2/../../.. main.o -lHSHGL -lHSWin32 -lHSWin32_cbits -l
user32 -lgdi32 -lwinmm -lkernel32 -ladvapi32 -lHSbase -lHSbase_cbits -lwsock32 -lmsvcrt -lkernel32 -luser32 -lshell32 -l
HSrts -lm -lgmp -lwsock32 -lmingw32 -lgcc -lmoldname -lmingwex -lmsvcrt -luser32 -lkernel32 -ladvapi32 -lshell32 -lmingw
32 -lgcc -lmoldname -lmingwex -lmsvcrt C:/ghc/ghc-6.4.1/gcc-lib/crtend.o
link: done
```Not GHChttps://gitlab.haskell.org/ghc/ghc/-/issues/808Move the GHC Commentary to the wiki2019-07-07T19:16:49ZSimon MarlowMove the GHC Commentary to the wikiThere's a bunch of invaluable documentation on the innards of GHC in the [Commentary](http://www.cse.unsw.edu.au/~chak/haskell/ghc/comm/). However, it isn't easy to edit: the commentary is in HTML checked into the darcs repository. It wo...There's a bunch of invaluable documentation on the innards of GHC in the [Commentary](http://www.cse.unsw.edu.au/~chak/haskell/ghc/comm/). However, it isn't easy to edit: the commentary is in HTML checked into the darcs repository. It would be better if this material was on the wiki, so we can have all the developer docs in one place.
This does mean converting the HTML into wiki, so probably an script of some kind would be the easiest way to do it.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------- |
| Version | 6.4.1 |
| Type | Task |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Documentation |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | Unknown |
| Architecture | Unknown |
</details>
<!-- {"blocked_by":[],"summary":"Move the GHC Commentary to the wiki","status":"New","operating_system":"Unknown","component":"Documentation","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.4.1","keywords":[],"differentials":[],"test_case":"","architecture":"Unknown","cc":[""],"type":"Task","description":"There's a bunch of invaluable documentation on the innards of GHC in the [http://www.cse.unsw.edu.au/~chak/haskell/ghc/comm/ Commentary]. However, it isn't easy to edit: the commentary is in HTML checked into the darcs repository. It would be better if this material was on the wiki, so we can have all the developer docs in one place.\r\n\r\nThis does mean converting the HTML into wiki, so probably an script of some kind would be the easiest way to do it.","type_of_failure":"OtherFailure","blocking":[]} -->Not GHChttps://gitlab.haskell.org/ghc/ghc/-/issues/974Add partitionEithers, lefts, rights to Data.Either2019-07-07T19:16:03ZguestAdd partitionEithers, lefts, rights to Data.EitherThis proposal would add basic functionality to `Either` similar to that for `Maybe`. The `splitEithers` function of type `[Either a b] -> ([a],[b])` is unique; however, it seems to be a widely useful function.
<details><summary>Trac met...This proposal would add basic functionality to `Either` similar to that for `Maybe`. The `splitEithers` function of type `[Either a b] -> ([a],[b])` is unique; however, it seems to be a widely useful function.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 6.6 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | libraries/base |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | Unknown |
| Architecture | Unknown |
</details>
<!-- {"blocked_by":[],"summary":"Add isLeft, isRight, fromLeft, fromRight, and splitEithers to Data.Either","status":"New","operating_system":"Unknown","component":"libraries/base","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.6","keywords":[],"differentials":[],"test_case":"","architecture":"Unknown","cc":[""],"type":"Bug","description":"This proposal would add basic functionality to `Either` similar to that for `Maybe`. The `splitEithers` function of type `[Either a b] -> ([a],[b])` is unique; however, it seems to be a widely useful function.","type_of_failure":"OtherFailure","blocking":[]} -->Not GHCIan Lynagh <igloo@earth.li>Ian Lynagh <igloo@earth.li>https://gitlab.haskell.org/ghc/ghc/-/issues/987X11: foreign declarations use Haskell types instead of C ones2019-07-07T19:15:59ZRoss Patersonr.paterson@city.ac.ukX11: foreign declarations use Haskell types instead of C onesSven Panne writes: Strictly speaking, the majority of types are wrong: an `Int` is not a `CInt`, and the binding will fail on platforms where the actual representation is different. There should be a general code review of all the types ...Sven Panne writes: Strictly speaking, the majority of types are wrong: an `Int` is not a `CInt`, and the binding will fail on platforms where the actual representation is different. There should be a general code review of all the types in the `foreign import`s.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ----------------- |
| Version | 6.6 |
| 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":"X11: foreign declarations use Haskell types instead of C ones","status":"New","operating_system":"Unknown","component":"libraries (other)","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.6","keywords":[],"differentials":[],"test_case":"","architecture":"Unknown","cc":[""],"type":"Bug","description":"Sven Panne writes: Strictly speaking, the majority of types are wrong: an `Int` is not a `CInt`, and the binding will fail on platforms where the actual representation is different. There should be a general code review of all the types in the `foreign import`s.","type_of_failure":"OtherFailure","blocking":[]} -->Not GHC