- ghc-devs - Haskell.org

Forcing a linking error?
by Erik de Castro Lopo 14 Aug '15

14 Aug '15

Dear ghc-devs, There is a commonly used library which has at least one function that when compiled into a program, requires the threaded run time system. Without the threaded runtime, the program just hangs. One kludgy solution to this problem is to have the function check for Control.Concurrent.rtsSupportsBoundThreads being true and throwing an error if its not. However, it would be much nicer if this could be turned into a link time error. Anyone have any ideas how this might be done? Cheers, Eri -- ---------------------------------------------------------------------- Erik de Castro Lopo http://www.mega-nerd.com/

3 2

Re: [GHC] #9868: ghc: panic! Dynamic linker not initialised
by Matthew Pickering 12 Aug '15

12 Aug '15

I can't reproduce this with 7.10.2. On Wed, Aug 12, 2015 at 4:54 PM, GHC <ghc-devs(a)haskell.org> wrote: > #9868: ghc: panic! Dynamic linker not initialised > -------------------------------------+------------------------------------- > Reporter: Jamedjo | Owner: > Type: bug | Status: infoneeded > Priority: normal | Milestone: > Component: Compiler | Version: 7.8.3 > Resolution: | Keywords: > Operating System: MacOS X | Architecture: x86_64 > Type of failure: Compile-time | (amd64) > crash | Test Case: > Blocked By: | Blocking: > Related Tickets: | Differential Revisions: > -------------------------------------+------------------------------------- > Changes (by bgamari): > > * status: new => infoneeded > > > Comment: > > I'm not really sure what we can do with this bug as is as there isn't > enough information here to reproduce the crash. Moreover, it looks two of > the issues reported here are distinct from the panic which apparently > provoked the ticket. > > Could those affected by this see if they can reproduce the issue on GHC > 7.10.2 and if so provide a detailed set of steps to reproduce the issue? > > -- > Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9868#comment:3> > GHC <http://www.haskell.org/ghc/> > The Glasgow Haskell Compiler

1 0

Type checker error messages question
by Jack Bowman 09 Aug '15

09 Aug '15

Hi all, I'm new to the GHC codebase and am looking to contribute. I started trying to implement https://ghc.haskell.org/trac/ghc/ticket/9173 , "better type error messages". I'm having some difficulty and was hoping someone more experienced could point me in the right direction. Part of the proposed change is that the "inferred:" line lists both the expression ("Just 5") and its type ("Maybe a0"). That's good because it's more clear that way. Currently those are in different parts of the error message. The function misMatchMsg (TcErrors.hs) creates the text "couldn't match expected type...". The text "In the second argument of..." is created by funAppCtxt (TcExpr.hs) during type checking. Bringing these together seems tricky. When we're generating a message like "couldn't match expected type..." I don't see how to access the expression text, like the "LHsExpr Name"s available to funAppCtxt. Is there an easy way to get that? We have the constraint and the two types, but I don't think those include this info. It seems fundamental to the error messages that the context ("in the _ argument..., in the expression ...") is built up as *text* while we do type checking, which means it's hard to customize when building the final error message. Please let me know if I'm missing something. There's a lot of type checker state that I might be misunderstanding. Thanks,Jack

2 1

Re: ghc-devs Digest, Vol 144, Issue 13
by Darren Grant 09 Aug '15

09 Aug '15

The Windows Task Force roster is here: https://ghc.haskell.org/trac/ghc/wiki/WindowsTaskForce A couple months ago I was looking into some of the linker issues (one manifestation of which was failure to link in mingw under TH phases as in #10672), but I was sadly unable to make much headway. I'm still interested in cracking this as Windows is my primary development platform, but new leads are required. Eventually, I may just seek a ground-up understanding of linkers in Windows and mingw. If anyone else has leads, please let me know if I can help. Cheers, Darren On Sun, Aug 9, 2015 at 5:00 AM, <ghc-devs-request(a)haskell.org> wrote: > Send ghc-devs mailing list submissions to > ghc-devs(a)haskell.org > > To subscribe or unsubscribe via the World Wide Web, visit > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > or, via email, send a message with subject or body 'help' to > ghc-devs-request(a)haskell.org > > You can reach the person managing the list at > ghc-devs-owner(a)haskell.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of ghc-devs digest..." > > > Today's Topics: > > 1. Linking issue on Windows: #10672 (Richard Eisenberg) > 2. Re: Linking issue on Windows: #10672 (John Wiegley) > 3. Type checker error messages question (Jack Bowman) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Sat, 8 Aug 2015 14:23:31 -0400 > From: Richard Eisenberg <eir(a)cis.upenn.edu> > To: ghc-devs Devs <ghc-devs(a)haskell.org> > Subject: Linking issue on Windows: #10672 > Message-ID: <8839B562-9A83-4137-A0D6-5DC15137C9C6(a)cis.upenn.edu> > Content-Type: text/plain; charset=us-ascii > > Hi devs, > > Bug #10672 was posted two weeks ago and has not received any response. It > concerns linking issues on Windows with Template Haskell. This is very far > out of my depth, but I don't recognize the name of the poster (lukexi), and > so it would be great to let that person know we've received the report and > have at least triaged it. Who are the Windows task force? I can't seem to > find that listed on https://ghc.haskell.org/trac/ghc/wiki/TeamGHC, but > perhaps there's a better place to look. > > If you have any idea of what's going on, would you mind at least > commenting on the bug? > > Thanks! > Richard > Template Haskell czar but linking buffoon and Windows ignoramus > > ------------------------------ > > Message: 2 > Date: Sat, 08 Aug 2015 12:35:25 -0700 > From: "John Wiegley" <johnw(a)newartisans.com> > To: Richard Eisenberg <eir(a)cis.upenn.edu> > Cc: ghc-devs Devs <ghc-devs(a)haskell.org> > Subject: Re: Linking issue on Windows: #10672 > Message-ID: <m2d1yxshdu.fsf(a)newartisans.com> > Content-Type: text/plain > > >>>>> Richard Eisenberg <eir(a)cis.upenn.edu> writes: > > > If you have any idea of what's going on, would you mind at least > commenting > > on the bug? > > I would also like to know who knows what about which linking platforms we > support. > > John > > > ------------------------------ > > Message: 3 > Date: Sat, 8 Aug 2015 22:56:00 -0400 > From: Jack Bowman <johnrbowman(a)gmail.com> > To: ghc-devs(a)haskell.org > Subject: Type checker error messages question > Message-ID: > < > CACcVNgUgbw9WLocN7dFM5Wewh8WbG4d81MwNmZQhcSedoSJEVQ(a)mail.gmail.com> > Content-Type: text/plain; charset="utf-8" > > Hi all, > I'm new to the GHC codebase and am looking to contribute. I started trying > to implement https://ghc.haskell.org/trac/ghc/ticket/9173 , "better type > error messages". I'm having some difficulty and was hoping someone more > experienced could point me in the right direction. > Part of the proposed change is that the "inferred:" line lists both the > expression ("Just 5") and its type ("Maybe a0"). That's good because it's > more clear that way. Currently those are in different parts of the error > message. The function misMatchMsg (TcErrors.hs) creates the text "couldn't > match expected type...". The text "In the second argument of..." is created > by funAppCtxt (TcExpr.hs) during type checking. Bringing these together > seems tricky. When we're generating a message like "couldn't match expected > type..." I don't see how to access the expression text, like the "LHsExpr > Name"s available to funAppCtxt. Is there an easy way to get that? We have > the constraint and the two types, but I don't think those include this > info. > It seems fundamental to the error messages that the context ("in the _ > argument..., in the expression ...") is built up as *text* while we do type > checking, which means it's hard to customize when building the final error > message. > Please let me know if I'm missing something. There's a lot of type checker > state that I might be misunderstanding. > Thanks,Jack >

1 0

Linking issue on Windows: #10672
by Richard Eisenberg 08 Aug '15

08 Aug '15

Hi devs, Bug #10672 was posted two weeks ago and has not received any response. It concerns linking issues on Windows with Template Haskell. This is very far out of my depth, but I don't recognize the name of the poster (lukexi), and so it would be great to let that person know we've received the report and have at least triaged it. Who are the Windows task force? I can't seem to find that listed on https://ghc.haskell.org/trac/ghc/wiki/TeamGHC, but perhaps there's a better place to look. If you have any idea of what's going on, would you mind at least commenting on the bug? Thanks! Richard Template Haskell czar but linking buffoon and Windows ignoramus

2 1

Simon away
by Simon Peyton Jones 07 Aug '15

07 Aug '15

Friends, I'm going to be on holiday for 2 weeks. Back in action on 24 August. Simon

1 0

Master is not validating
by Simon Peyton Jones 06 Aug '15

06 Aug '15

| Indeed it appears that there is trouble on the `master` branch at the | moment. I'll be looking into this. I find it difficult to interpret Phab results. Eg https://phabricator.haskell.org/B5172 says both "failed" and "passed". Also the build logs displayed eg here https://phabricator.haskell.org/harbormaster/build/5394/?l=0 are truncated so you can't see what the exact failure was. But from the latter I'm guessing that the problem is: - I added a new warning - And I think validate uses -Wall and fails if any warning happens (which seems a bit brutal) The warnings are, I think legitimate. But I certainly don't want them to break the build. How to fix? * Remove -fwarn-all-missed-specialisations from -Wall. * Or add -fno-warn-all-missed-specialisations to validate I don't have a strong opinion. Can you do one or t'other? -fwarn-all-missed-specialisations says that there are overloaded functions being called without being specialised. That's quite interesting, and it's the kind of thing you'd like to see with "all warnings". But it's also perfectly reasonable to say "that's fine, I don't care that overloaded functions are being called". Are there any other warnings that -Wall does not include? That is, do we expect -Wall to mean "all" or just "nearly all"? I have no strong opinion. Apologies for causing this fuss. Simon | -----Original Message----- | From: noreply(a)phabricator.haskell.org | [mailto:noreply@phabricator.haskell.org] | Sent: 06 August 2015 10:56 | To: Simon Peyton Jones | Subject: [Differential] [Requested Changes To] D1133: Make derived | names deterministic | | bgamari requested changes to this revision. | bgamari added a comment. | This revision now requires changes to proceed. | | Indeed it appears that there is trouble on the `master` branch at the | moment. I'll be looking into this. | | The idea here looks reasonable, but what effect does this have on the | size of the build artifacts (e.g. object and interface files). It | seems like the names may grow substantially with this change. Could | you characterize this? | | Also, I would really like to see some haddocks on the top-level | bindings that are introduced here. | | | REPOSITORY | rGHC Glasgow Haskell Compiler | | REVISION DETAIL | https://phabricator.haskell.org/D1133 | | EMAIL PREFERENCES | https://phabricator.haskell.org/settings/panel/emailpreferences/ | | To: niteria, simonmar, simonpj, austin, bgamari | Cc: thomie

2 2

Strange Changelog.md formatting on Hackage
by Sven Panne 06 Aug '15

06 Aug '15

The formatting of https://hackage.haskell.org/package/StateVar-1.1.0.1/changelog is garbled, while the corresponding GitHub page https://github.com/haskell-opengl/StateVar/blob/master/CHANGELOG.md looks OK. Can somebody give me a hint why this happens? https://hackage.haskell.org/package/lens-4.12.3/changelog e.g. looks nice, but the markdown seems to be similar. Cheers, S.

2 2

Recent performance regressions
by Joachim Breitner 06 Aug '15

06 Aug '15

Dear Developers, yesterday, there were three commits showing up at https://perf.haskell.org/ghc/: https://perf.haskell.org/ghc/#revision/60297486fddd5c9695e2263c2ae46fa9 0f0feb9e 60297486fddd5c9695e2263c2ae46fa90f0feb9e Author: Ben Gamari <bgamari.foss(a)gmail.com> Drop custom mapM impl for [] nofib/allocs/cryptarithm2 + 64.55% nofib/allocs/k-nucleotide - 5.03% nofib/time/fannkuch-redux - 3.62% Did someone forget to run nofib here, or is this serious drop in performance in one case expected and something we condone? In that case, it should have been clearly noted in the commit message! https://perf.haskell.org/ghc/#revision/b12dba7829742de98a483645142c7962 b9dd9f3f b12dba7829742de98a483645142c7962b9dd9f3f Author: RyanGlScott <ryan.gl.scott(a)gmail.com> Make Exception datatypes into newtypes nofib/time/cryptarithm1 + 7.22% If you look at the graph, this is quite reproducible: https://perf.haskell.org/ghc/#graph/nofib/time/cryptarithm1;hl=b12dba78 29742de98a483645142c7962b9dd9f3f but I have no idea how that change could have that effect. Maybe some weird cache effect due to binary sizes or different code layout? It would be great to understand that! https://perf.haskell.org/ghc/#revision/22bbc1cf209d44b8bb8897ae7a35f9eb af411b10 commit 22bbc1cf209d44b8bb8897ae7a35f9ebaf411b10 Author: Takano Akio <aljee(a)hyper.cx> Make sure that `all`, `any`, `and`, and `or` fuse (#9848) nofib/allocs/circsim - 4.02% nofib/allocs/multiplier - 8.70% At least I do not only have bad news... Greetings, Joachim -- Joachim “nomeata” Breitner mail(a)joachim-breitner.de • http://www.joachim-breitner.de/ Jabber: nomeata(a)joachim-breitner.de • GPG-Key: 0xF0FBF51F Debian Developer: nomeata(a)debian.org

1 0

arc diff problems
by Edward Z. Yang 05 Aug '15

05 Aug '15

Hello friends, I too am having Arcanist problems (my libphutil and arcanist are at the latest head). Here's my error: [ezyang@hs01 ghc-quick]$ arc diff HEAD~ You have untracked files in this working copy. Working copy: /home/hs01/ezyang/ghc-quick/ Untracked changes in working copy: (To ignore these changes, add them to ".git/info/exclude".) testsuite/tests/driver/T9938 testsuite/tests/driver/T9938B testsuite/tests/driver/dynamicToo/dynamicToo001/d testsuite/tests/driver/dynamicToo/dynamicToo001/s testsuite/tests/driver/dynamicToo/dynamicToo005/A005.dyn_o-boot Ignore these untracked files and continue? [y/N] y Exception Field "testPlan" occurs twice in commit message! (Run with `--trace` for a full exception trace.) Here is the commit message in question: commit 80ef08619c315e35e439e50724afc5d3b3203895 Author: Edward Z. Yang <ezyang(a)cs.stanford.edu> Date: Fri Jul 24 15:13:49 2015 -0700 Unify hsig and hs-boot; add preliminary "hs-boot" merging. This patch drops the file level distinction between hs-boot and hsig; we figure out which one we are compiling based on whether or not there is a corresponding hs file lying around. To make the "import A" syntax continue to work for bare hs-boot files, we also introduce hs-boot merging, which takes an A.hi-boot and converts it to an A.hi when there is no A.hs file in scope. This will be generalized in Backpack to merge multiple A.hi files together; which means we can jettison the "load multiple interface files" functionality. This works automatically for --make, but for one-shot compilation we need a new mode: ghc --merge-requirements A will generate an A.hi/A.o from a local A.hi-boot file; Backpack will extend this mechanism further. Has Haddock submodule update to deal with change in msHsFilePath behavior. - This commit drops support for the hsig extension. Can we support it? It's annoying because the finder code is written with the assumption that where there's an hs-boot file, there's always an hs file too. To support hsig, you'd have to probe two locations. Easier to just not support it. - #10333 affects us, modifying an hs-boot still doesn't trigger recomp. - See compiler/main/Finder.hs: this diff is very skeevy, but it seems to work. - This code cunningly doesn't drop hs-boot files from the "drop hs-boot files" module graph, if they don't have a corresponding hs file. I have no idea if this actually is useful. Signed-off-by: Edward Z. Yang <ezyang(a)cs.stanford.edu> Test Plan: validate Reviewers: simonpj, austin, bgamari, spinda Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D1098 It doesn't work even if I delete "Test Plan". Edward

1 2