January 2017 - ghc-devs

Navigating GHC proposals
by Simon Peyton Jones 09 Jan '17

09 Jan '17

Once I am looking the rendered form of a GHC proposal, eg https://github.com/ghc-proposals/ghc-proposals/blob/rae/constraint-vs-type/… how can I find my way to the “conversation” for that proposal, so I can comment on it? https://github.com/ghc-proposals/ghc-proposals/pull/32 Once more, I am lost in a maze of twisty little Githup passages. I clearly have not yet internalised an accurate model of what Github is thinking Thanks Simon

4 6

Phabricator upgrade underway
by Ben Gamari 09 Jan '17

09 Jan '17

Hello everyone, I'll be bringing down Phabricator for an upgrade in a few minutes. I'll let you know when things are back up. Cheers, - Ben

1 1

Lexical error in string continuation
by Harendra Kumar 07 Jan '17

07 Jan '17

Hi devs, I am making a change in runghc on the ghc master branch. When compiling the following code (edited/new code in utils/runghc): 208 splitGhcNonGhcArgs :: [String] -> IO ([String], [String]) 209 splitGhcNonGhcArgs args = do 210 let (ghc, other) = break notAFlag args 211 when (hasUnescapedGhcArgs ghc) $ 212 hPutStrLn stderr "yy\ 213 \ xx" I get an error because of the string continuation at line 212. If I put the backslashes on the same line I do not get any error. I have more string continuations in the same file and they all work fine. This snippet works fine with ghc-7.10.3/ghc-8.0.1 when compiled separately. Here is the error message that I get: utils/runghc/Main.hs:212:56: error: lexical error in string/character literal at character 'x' | 212 | hPutStrLn stderr "yy\ | ^ utils/runghc/ghc.mk:30: recipe for target 'utils/runghc/dist-install/build/Main.dyn_o' failed make[2]: *** [utils/runghc/dist-install/build/Main.dyn_o] Error 1 Makefile:122: recipe for target 'all_utils/runghc' failed make[1]: *** [all_utils/runghc] Error 2 make[1]: Leaving directory '/vol/hosts/cueball/workspace/play/ghc' ../../mk/sub-makefile.mk:50: recipe for target 'all' failed make: *** [all] Error 2 Any help will be appreciated. I can send the modified file if anyone wants to reproduce/debug. -harendra

1 1

GHC API 7.10 -> 8.0.1 (unusable due to missing or recursive dependencies)
by A.M. 07 Jan '17

07 Jan '17

Hello, I am migrating a use of the GHC API from GHC 7.10 to GHC 8.0.1 and have hit an issue whereby importing pre-compiled libraries spits out: package testhsscript-0.1-CQQKGzp5pWwBmTnAldv1Hk is unusable due to missing or recursive dependencies: Glob-0.7.13-2PN6d9dpHzz7DHotD0T0wu base-4.9.0.0 though these packages are indeed in the sandbox and listed with ExposePackage in the packageFlags. To be clear, a variant of this code worked as expected under GHC 7.10. I have created a simplified test case to demonstrate the issue: https://github.com/agentm/testhsscript Here is the meat of the problem: * lib/Test.hs - contains a module importing Glob with some functions of no consequence https://github.com/agentm/testhsscript/blob/master/lib/Test.hs * test.hs includes the GHC API call to load the precompiled Test module from the cabal sandbox https://github.com/agentm/testhsscript/blob/master/test.hs * cabal file has two targets: Library and executable "test"- the executable uses the GHC API to load the pacakge "testhsscript" https://github.com/agentm/testhsscript/blob/master/testhsscript.cabal For reference, here is the GHC API invocation which works under GHC 7.10: https://github.com/agentm/project-m36/blob/master/src/lib/ProjectM36/AtomFu… I suspect I am missing something basic that has changed in GHC 8 and would very much appreciate any tips. Here is the failing result of attempting to load the testhsscript package: Setting up HscEnv Using binary package database: /home/agentm/Dev/testhsscript/.cabal-sandbox/x86_64-linux-ghc-8.0.1-packages.conf.d/package.cache Using binary package database: /opt/ghc/8.0.1/lib/ghc-8.0.1/package.conf.d/package.cache loading package database /home/agentm/Dev/testhsscript/.cabal-sandbox/x86_64-linux-ghc-8.0.1-packages.conf.d package testhsscript-0.1-CQQKGzp5pWwBmTnAldv1Hk is unusable due to missing or recursive dependencies: Glob-0.7.13-2PN6d9dpHzz7DHotD0T0wu base-4.9.0.0 package Glob-0.7.13-2PN6d9dpHzz7DHotD0T0wu is unusable due to missing or recursive dependencies: base-4.9.0.0 containers-0.5.7.1 directory-1.2.6.2 dlist-0.8.0.2-GWAMmbX9rLg3tqrbOizHGv filepath-1.4.1.0 transformers-0.5.2.0 transformers-compat-0.5.1.4-G5tKvPrwhggJRvSwXNMs1N package ghc-paths-0.1.0.9-GIOnKzk0HmEBZ77Q1HsThK is unusable due to missing or recursive dependencies: base-4.9.0.0 package mtl-2.2.1-6qsR1PHUy5lL47Hpoa4jCM is unusable due to missing or recursive dependencies: base-4.9.0.0 transformers-0.5.2.0 package dlist-0.8.0.2-GWAMmbX9rLg3tqrbOizHGv is unusable due to missing or recursive dependencies: base-4.9.0.0 deepseq-1.4.2.0 package transformers-compat-0.5.1.4-G5tKvPrwhggJRvSwXNMs1N is unusable due to missing or recursive dependencies: base-4.9.0.0 ghc-prim-0.5.0.0 transformers-0.5.2.0 loading package database /opt/ghc/8.0.1/lib/ghc-8.0.1/package.conf.d test: <command line>: cannot satisfy dlist: dlist-0.8.0.2-GWAMmbX9rLg3tqrbOizHGv is unusable due to missing or recursive dependencies: base-4.9.0.0 deepseq-1.4.2.0 (use -v for more information) Cheers, M

2 3

Re: [GHC] #13035: GHC enters a loop when partial type signatures and advanced type level code mix
by Phyx 06 Jan '17

06 Jan '17

Ah, great thanks! On Fri, 6 Jan 2017, 20:32 GHC, <ghc-devs(a)haskell.org> wrote: > #13035: GHC enters a loop when partial type signatures and advanced type > level code > mix > -------------------------------------+------------------------------------- > Reporter: xcmw | Owner: > Type: bug | Status: merge > Priority: normal | Milestone: 8.0.3 > Component: Compiler | Version: 8.0.1 > Resolution: | Keywords: > Operating System: Unknown/Multiple | Architecture: > | Unknown/Multiple > Type of failure: None/Unknown | Test Case: > | perf/compiler/T13035 > Blocked By: | Blocking: > Related Tickets: | Differential Rev(s): > Wiki Page: | > -------------------------------------+------------------------------------- > > Comment (by RyanGlScott): > > I believe mpickering fixed in in f3c7cf9b89cad7f326682b23d9f3908ebf0f8f9d > and 54227a45352903e951b81153f798162264f02ad9. > > -- > Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13035#comment:8> > GHC <http://www.haskell.org/ghc/> > The Glasgow Haskell Compiler >

1 0

RE: [commit: ghc] master: Actually add the right file for T13035 stderr (54227a4)
by Simon Peyton Jones 06 Jan '17

06 Jan '17

Thanks. Sorry about failing to add that file simon | -----Original Message----- | From: ghc-commits [mailto:ghc-commits-bounces@haskell.org] On Behalf Of | git(a)git.haskell.org | Sent: 06 January 2017 17:18 | To: ghc-commits(a)haskell.org | Subject: [commit: ghc] master: Actually add the right file for T13035 stderr | (54227a4) | | Repository : ssh://git@git.haskell.org/ghc | | On branch : master | Link : | https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fghc.haskell. | org%2Ftrac%2Fghc%2Fchangeset%2F54227a45352903e951b81153f798162264f02ad9%2Fgh | c&data=02%7C01%7Csimonpj%40microsoft.com%7C86bd120363964482265708d43657ea8d% | 7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636193198616484576&sdata=rsqX9O | 5K9ga2Aym%2BF%2BsWCA1vpaD7yJRDoWDfxPbCvVk%3D&reserved=0 | | >--------------------------------------------------------------- | | commit 54227a45352903e951b81153f798162264f02ad9 | Author: Matthew Pickering <matthewtpickering(a)gmail.com> | Date: Fri Jan 6 17:15:35 2017 +0000 | | Actually add the right file for T13035 stderr | | | >--------------------------------------------------------------- | | 54227a45352903e951b81153f798162264f02ad9 | testsuite/tests/perf/compiler/T13035.stderr | 5 ++++- | 1 file changed, 4 insertions(+), 1 deletion(-) | | diff --git a/testsuite/tests/perf/compiler/T13035.stderr | b/testsuite/tests/perf/compiler/T13035.stderr | index ae02c1f..52836d7 100644 | --- a/testsuite/tests/perf/compiler/T13035.stderr | +++ b/testsuite/tests/perf/compiler/T13035.stderr | @@ -1 +1,4 @@ | -compilation IS NOT required | + | +T13035.hs:141:28: warning: [-Wpartial-type-signatures (in -Wdefault)] | + • Found type wildcard ‘_’ standing for ‘'['Author]’ | + • In the type signature: g :: MyRec RecipeFormatter _ | | _______________________________________________ | ghc-commits mailing list | ghc-commits(a)haskell.org | https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmail.haskell | .org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc- | commits&data=02%7C01%7Csimonpj%40microsoft.com%7C86bd120363964482265708d4365 | 7ea8d%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636193198616484576&sdata= | zDIxHu4g5rU8jgEedgGvPWHoM8jRG%2FaQCKrHrAgvIcs%3D&reserved=0

1 0

Github repos for boot libraries
by Erik de Castro Lopo 05 Jan '17

05 Jan '17

Hi all, Currently if I go to the Github mirror for a boot library like transformers: https://github.com/ghc/packages-transformers I see the text: Mirror of packages-transformers repository. DO NOT SUBMIT PULL REQUESTS HERE This may well be true, but it is far less that useful, because although it tells me I can't submit I pull request, It doesn't tell me what I should do to get my issue addressed. Would it be possible to get these messages updated for all of these mirrored repos? Thanks, Erik -- ---------------------------------------------------------------------- Erik de Castro Lopo http://www.mega-nerd.com/

3 2

OpenSearch with GHC manual
by Sylvain Henry 05 Jan '17

05 Jan '17

Hi, Search engines often reference old versions of the GHC user guide. For instance with Google and the request "ghc unboxed tuples" I get the manual for 7.0.3, 5.04.1 and 6.8.2 as first results. With DuckDuckGo I get 6.12.3 and then "latest" versions of the manual. So I have made a custom search engine for the latest manual (using OpenSearch spec). You can install it from the following page: http://haskus.fr/ghc/index.html like any other search engine. Sphinx supports automatic generation of OpenSearch spec: http://www.sphinx-doc.org/en/1.4.8/config.html#confval-html_use_opensearch Maybe we should use this to make the search engine easier to find and use. As a side note, would it be possible to have a nicer URI for the latest doc? Currently it is: https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/index.html Something like https://haskell.org/ghc/doc/index.html would be better IMO. Sylvain

2 1

Backpack status for 8.2
by Ben Gamari 05 Jan '17

05 Jan '17

Hi Edward, I am currently trying to get an idea of what work remains outstanding for the 8.2.1. How is Backpack coming along? Would a freeze around the end of January be enough time to get most of the larger items ticked off? It would be great if there were a list (perhaps a tracking ticket on Trac?) where we could collect and track the progress of the remaining tasks. Cheers, - Ben

1 0

Large tuple strategy
by Reid Barton 05 Jan '17

05 Jan '17

Hi all, https://phabricator.haskell.org/D2899 proposes adding Generic instances for large tuples (up to size 62). Currently GHC only provides Generic instances for tuples of size up to 7. There's been some concern about the effect that all these instances will have on compilation time for anyone who uses Generics, even if they don't actually use the new instances. There was a suggestion to move these new instances to a separate module, but as these instances would then be orphans, I believe GHC would have to read the interface file for that module anyways once Generic comes into scope, which would defeat the purpose of the split. It occurred to me that rather than moving just these instances to a new module, we could move the large tuples themselves to a new module Data.LargeTuple and put the instances there. The Prelude would reexport the large tuples, so there would be no user-visible change. According to my experiments, GHC should never have to read the Data.LargeTuple interface file unless a program actually mentions a large tuple type, which is presumably rare. We could then also extend the existing instances for Eq, Show, etc., which are currently only provided through 15-tuples. A nontrivial aspect of this change is that tuples are wired-in types, and they currently all live in the ghc-prim package. I'm actually not sure why they need to be wired-in rather than ordinary types with a funny-looking name. In any case I need to look into this further, but the difficulties here don't seem to be insurmountable. Does this seem like a reasonable plan? Anything important I have missed? Regards, Reid Barton

3 3