- ghc-devs - Haskell.org

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

Contributing Examples to the Documentation
by Sunjay Varma 05 Jan '17

05 Jan '17

Hi, I'm considering contributing examples to the documentation. I wanted to start with something like Data.List because it is one of the modules I end up using the most. I think a few examples for each function would help users understand them better. I find myself referring back to books like learn you a haskell because I don't remember exactly what I'm supposed to do with a function. Doing one module seems like a good start and hopefully we can have some other people begin to add their own examples too. Is this a worthwhile contribution? I haven't contributed before and so I think it's prudent to ask before I add something no one wants. Are there any examples of modules with good code examples that I should use as a reference? I want to include both the code and output of the example as if the user was running ghci. Are there any guidelines for contributing documentation? When I say Data.List, I really mean Data.Foldable and Data.Traversable since that is where the functions are actually implemented. I noticed the GitHub repo said that Pull Requests were okay for easy to review documentation changes. Can I open a pull request there or should I follow another process? Please let me know when you can. I don't have an exact timeline for when this will be done, but hopefully I'll have something in the next few weeks. I don't anticipate that it will take long once I sit down to do it. I've always complained about a lack of examples and never done anything about it. Hopefully I can practice what I preach and contribute some in order to make the documentation a little better for everyone. Thanks for helping to make this language so great! Sunjay

6 9

FW: Lightweight Concurrency Branch
by Simon Peyton Jones 04 Jan '17

04 Jan '17

Reply from KC… see below. Simon From: KC Sivaramakrishnan [mailto:sk826@cam.ac.uk] Sent: 04 January 2017 11:29 To: Simon Peyton Jones <simonpj(a)microsoft.com> Cc: Daniel Bennet <daniel.bennet83(a)gmail.com>; ghc-devs(a)haskell.org; KC (sk826(a)hermes.cam.ac.uk) <sk826(a)hermes.cam.ac.uk> Subject: Re: Lightweight Concurrency Branch Hi Simon, David, Indeed as Simon mentioned it, the work was never finished. The implementation is(was) at a stage where we can run some small non-trivial benchmarks (Section 7 of the JFP paper). The interactions with FFI, MVars, STM, asynchronous exceptions worked well (though we most probably do things a little differently now), until we encountered interaction with blackholes mechanism. The crux of the problem is that the blackholing mechanism interacts with the scheduler and if the scheduler functionality itself is written in Haskell, then we have the potential for a deadlock. Some of the details are presented in Section 6.5, but we never got around to a clean solution that I could get working properly. Hence the reason for not formalizing it completely in the paper, and I am sure there are some edge cases that I hadn't thought about. This is a particularly tricky issue, and the current design unfortunately does not lend itself to a clean solution. Although the asynchronous exception mechanism interaction was not formalized, it works well and passes the tests. Not much effort was put in to make the implementation go particularly fast. While the performance was comparable on average, but varied quite a bit on edge cases; some of the results in the paper show this. If one were to revive the project, I would suggest starting from the design, using the existing code as a prototype, but write code from scratch; pleasantly there isn't much new code in this branch. The project does need substantial amount of work to make it upstream with the newer RTS mechanisms. I am very happy to provide more details and eager to assist with the work, but my time commitments mean that I cannot lead this effort. Kind Regards, KC On Wed, Jan 4, 2017 at 10:38 AM, Simon Peyton Jones <simonpj(a)microsoft.com<mailto:simonpj@microsoft.com>> wrote: David KC never finished work on this stuff. I’m copying him because I’m sure he’d be happy to help. KC: can you summarise where you left it? I think it’s very interesting work, and has the potential to make GHC’s RTS much more malleable, by moving more of it into Haskell libraries instead of deeply-magic C code. But it’s not easy, because we are reluctant to lose performance, and because there are interactions with STM, weak pointers, foreign function calls, etc. I think it’d require a bit of commitment to make a go of it. Simon From: ghc-devs [mailto:ghc-devs-bounces@haskell.org<mailto:ghc-devs-bounces@haskell.org>] On Behalf Of Daniel Bennet Sent: 28 December 2016 17:23 To: ghc-devs(a)haskell.org<mailto:ghc-devs@haskell.org> Subject: Lightweight Concurrency Branch The lightweight concurrency branch is highly interesting and relevant to my interests, however, the ghc-lwc2 branch hasn't been updated in several years even though it's listed as an active branch at https://ghc.haskell.org/trac/ghc/wiki/ActiveBranches The wiki page for the work hasn't been updated in almost two years either, https://ghc.haskell.org/trac/ghc/wiki/LightweightConcurrency Relevant papers: Composable Scheduler Activations for Haskell (2014) https://timharris.uk/papers/2014-composable-tr.pdf<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftimharris.…> Composable Scheduler Activations for Haskell (2016) http://kcsrk.info/papers/schedact_jfp16.pdf<https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fkcsrk.info%…> What remains for integrating this branch into GHC?

2 1