|
|
# Release plans for GHC 7.8
|
|
|
|
|
|
## Timeline
|
|
|
|
|
|
|
|
|
See recent ghc-devs posting [ GHC 7.8 Release Status & Schedule](http://permalink.gmane.org/gmane.comp.lang.haskell.ghc.devel/2569) for latest timeline.
|
|
|
|
|
|
## Tickets
|
|
|
|
|
|
|
|
|
We would like to fix all of the [ high and highest priority tickets in the 7.8.1 milestone](http://ghc.haskell.org/trac/ghc/query?priority=highest&priority=high&status=infoneeded&status=merge&status=new&status=patch&milestone=7.8.1&col=id&col=summary&col=status&col=type&col=priority&col=milestone&col=component&order=priority), but there are currently a lot of them so this seems optimistic. Please feel free to take a ticket and help us!
|
|
|
|
|
|
*Note that anything not listed here is off Austin's radar.*
|
|
|
|
|
|
## Completed new features
|
|
|
|
|
|
|
|
|
The features already completed are documented in the release notes:
|
|
|
[docs/users_guide/7.8.1-notes.xml](/trac/ghc/browser/ghc/docs/users_guide/7.8.1-notes.xml)
|
|
|
|
|
|
## Pending new features
|
|
|
## Pending things to completion
|
|
|
|
|
|
- Austin Seipp needs to upload the primops compatibility package for 7.8. This is is easy: mostly a copy of `compiler/utils/ExtsCompat64.hs` into a Cabal package. See also [ the compatibility module page](http://www.haskell.org/haskellwiki/Compatibility_Modules).
|
|
|
|
|
|
- Austin also still has a lingering patch for [\#7602](https://gitlab.haskell.org//ghc/ghc/issues/7602) to fix a large OS X performance regression, but it's still not merged. The basic gist is that the patch as written works for OS X 10.8. But in OS X 10.9 the TLS implementation changed, invalidating it, so some investigation is needed.
|
|
|
|
|
|
The following **new** features are planned for 7.8 **but have not yet made it**. They are at varying degrees of completeness, and may not all make it in.
|
|
|
- `-XTemplateHaskell` should now imply `-dynamic-too`, based on the discussions in [\#8180](https://gitlab.haskell.org//ghc/ghc/issues/8180). Austin is attempting to fix this by switching it on during module loading but it doesn't quite work yet.
|
|
|
|
|
|
- Austin Seipp needs to upload the primops compatibility package for 7.8. This is mostly a copy of `compiler/utils/ExtsCompat64.hs` into a Cabal package. See also [ the compatibility module page](http://www.haskell.org/haskellwiki/Compatibility_Modules). **In progress**.
|
|
|
- **Pattern synonyms will make it**! Austin will merge them Real Soon Now, after making sure there's documentation, Haddock works, and the T's are crossed and I's dotted.
|
|
|
|
|
|
- Austin Seipp needs to merge a patch from Ben Gamari to fix LLVM + dynamic linking.
|
|
|
- **New Haddock parser** will hopefully go in, but isn't guaranteed yet. Austin will work with Mateusz to try and get it in ASAP.
|
|
|
|
|
|
- Austin also still has a lingering patch for [\#7602](https://gitlab.haskell.org//ghc/ghc/issues/7602) to fix a large OS X performance regression, but it's still not merged. This is because the thread-local storage implementation changed in OS X Mavericks, requiring more investigation.
|
|
|
## The Windows Conundrum
|
|
|
|
|
|
- Dynamic GHCi ([\#3658](https://gitlab.haskell.org//ghc/ghc/issues/3658)). This is working in HEAD, and enabled if `DYNAMIC_GHC_PROGRAMS=YES`, which causes GHC itself to be built dynamically. Currently it's enabled by default if dynamic libraries are supported, except for FreeBSD and Windows.
|
|
|
On FreeBSD the reason it's disabled is due to a bug in FreeBSD's rtld. This has been fixed, but we're waiting for the fix to make it into releases. This might be in time for 7.8, but certainly will be for 7.10. See [\#7819](https://gitlab.haskell.org//ghc/ghc/issues/7819).
|
|
|
On Windows, there are a couple of build time annoyances: `-dynamic-too` doesn't work on Windows ([\#8228](https://gitlab.haskell.org//ghc/ghc/issues/8228)), and linking takes a very long time when dynamic linking is used ([\#8229](https://gitlab.haskell.org//ghc/ghc/issues/8229)). There's no technical reason why it couldn't be enabled, though.
|
|
|
On Windows, there are a few problems:
|
|
|
|
|
|
- `-dynamic-too` doesn't work on Windows ([\#8228](https://gitlab.haskell.org//ghc/ghc/issues/8228))
|
|
|
- Because of [\#8228](https://gitlab.haskell.org//ghc/ghc/issues/8228), GHC is a bit nerfed in using lots of RAM - see the discussion in [\#7134](https://gitlab.haskell.org//ghc/ghc/issues/7134). We should fix `-dynamic-too` to knock out two birds with one stone (fix [\#7134](https://gitlab.haskell.org//ghc/ghc/issues/7134) and enable using lots of RAM.)
|
|
|
|
|
|
(Related but not critical: we have too many DLL symbols, and are very close to the limit ([\#5987](https://gitlab.haskell.org//ghc/ghc/issues/5987)). Linking also takes a long time ([\#8229](https://gitlab.haskell.org//ghc/ghc/issues/8229)))
|
|
|
The plan is/was to use dynamic GHCi on as many platforms as possible in 7.8, and to remove support for non-dynamic-ghci in HEAD soon after. See discussion in [\#8039](https://gitlab.haskell.org//ghc/ghc/issues/8039), however.
|
|
|
|
|
|
- Windows is becoming increasingly weird. It seems that with `./validate` settings, a 32bit GHC built using the MSYS2 instructions mysteriously segfaults inside the stage2 compiler. But a 64bit GHC seems to work OK. But then as Austin was writing this it broke mysteriously, seemingly with no intervention.
|
|
|
|
|
|
- Also, it seems as if `-dynamic` actually is broken in some weird way on Windows. During my (Austin) investigation into [\#8228](https://gitlab.haskell.org//ghc/ghc/issues/8228), compiling a simple dynamic executable seems to result in segfaults. The most bizarre part is the `.exe` generated with `-dynamic` seems to depend on both `libHSrts.dll` and `libHSrts_thr.dll`! Without either in a place where the Windows linker can find it, the executable fails to start. Austin believes this is possibly the culprit (symbols may somehow get confused based on loading order,) but he doesn't know why `-dynamic` on windows seems to cause a dependency on both the threaded and non-threaded runtime. |