Right way to turn off dynamic linking in build.mk
Some times when I play around with GHC I'd like to turn off dynamic linking to make GHC compile faster. I'm not sure what the right way to do this in build.mk. It's made confusing by the conditional statements in that file: GhcLibWays = $(if $(filter $(DYNAMIC_GHC_PROGRAMS),YES),v dyn,v) This line make me worry that if I don't put DYNAMIC_GHC_PROGRAMS = NO in the right place in build.mk it wont take. There's also this one: ifeq $(PlatformSupportsSharedLibs) YES GhcLibWays += dyn endif Seeing this makes me wonder if DYNAMIC_GHC_PROGRAMS = NO DYNAMIC_BY_DEFAULT = NO is enough or if the build system still sniffs out the fact that my platform supports dynamic linking. Could someone please give an authoritative answer to how to turn off dynamic linking? -- Johan ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: [Diffusion] [Build Failed] rGHC726ea08a6e58: Amend TcPluginM interface
On 18/12/14 09:25, Phabricator wrote: Harbormaster failed to build B2694: rGHC726ea08a6e58: Amend TcPluginM interface! Sigh. It seems perf/compiler T3294 is failing on Harbormaster, but it validated fine locally on x86_64. I doubt my commit is responsible, and suspect this is just a wobbly test, but it's hard to know without the full build log. Is there a way to get full logs for failing Harbormaster builds? They seem to be uploaded only if the build succeeds. Thanks, Adam USERS adamgundry (Author) GHC - Driver (Auditor) GHC - Type checker/inferencer (Auditor) COMMIT https://phabricator.haskell.org/rGHC726ea08a6e58 EMAIL PREFERENCES https://phabricator.haskell.org/settings/panel/emailpreferences/ To: adamgundry, GHC - Driver, GHC - Type checker/inferencer -- Adam Gundry, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/ ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
RE: are patterns synonyms definable in GHCI?
File a Trac ticket! From: ghc-devs [mailto:ghc-devs-boun...@haskell.org] On Behalf Of Carter Schonwald Sent: 18 December 2014 06:15 To: ghc-devs@haskell.org Subject: are patterns synonyms definable in GHCI? Hey all, I was trying to define some pattern synonyms in ghci recently, and that doesnt seem to work. Is that something slated to be fix in 7.10 or something? ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
RE: Understanding DsMeta module
| Thanks. That helps but I still don't understand why the calls are | delegated to template-haskell library. Couldn't all of this be done | locally? No. If you have f :: Int - Q Exp then f is a function that, when run, produces a data structure that is the syntax tree (in the data type of Language.Haskell.TH) of some expression. Later, in some other module entirely, you may call f, thus foo = $(f 5) Now GHC dynamically links the module that defines f, executes f's code, which returns a syntax tree (in the data type of Language.Haskell.TH). This is converted to HsSyn and replaces the $(f 5). So the code for f must be code that, when executed, produces a data structure. The business of DsMeta is to produce such code. If, once you grok this, you'd like to add a page to the GHC Commentary, to explain it, that would be great. It does take a while to get your head around. Simon | -Original Message- | From: ghc-devs [mailto:ghc-devs-boun...@haskell.org] On Behalf Of Jan | Stolarek | Sent: 17 December 2014 19:34 | To: Richard Eisenberg | Cc: ghc-devs@haskell.org | Subject: Re: Understanding DsMeta module | | Thanks. That helps but I still don't understand why the calls are | delegated to template-haskell library. Couldn't all of this be done | locally? | | Janek | | Dnia środa, 17 grudnia 2014, Richard Eisenberg napisał: | On Dec 17, 2014, at 12:29 PM, Jan Stolarek jan.stola...@p.lodz.pl | wrote: |Why not implement repPlainTV like this: ? | |repPlainTV :: Core TH.Name - DsM (Core TH.TyVarBndr) repPlainTV |(MkC nm) = return $ MkC (TH.PlainTV nm) | | In short, that's ill typed. We have | |newtype Core a = MkC CoreExpr | | The idea behind this type is that its (phantom) type parameter | tracks | the type of the expression stored within. Of course, the thing | within | is always just a core expression. TH.PlainTV takes a TH.Name and | produces a TH.TyVarBndr. But, nm is a CoreExpr and MkC is expecting | a | CoreExpr, so your suggestion wouldn't type check. | | The higher-level answer is that you're mixing levels. The goal in | DsMeta is | *not* to create the TH AST. It's to create *core expressions* that | create the TH AST. | | Does this help? | | Richard | | | ___ | ghc-devs mailing list | ghc-devs@haskell.org | http://www.haskell.org/mailman/listinfo/ghc-devs ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
RE: Status updates
Sergei Thank you for all these. I believe I have (finally) nailed them all! Simon | -Original Message- | From: ghc-devs [mailto:ghc-devs-boun...@haskell.org] On Behalf Of | Sergei Trofimovich | Sent: 09 September 2014 18:32 | To: ghc-devs@haskell.org | Subject: Re: Status updates | | On Tue, 9 Sep 2014 08:34:03 -0500 | Austin Seipp aus...@well-typed.com wrote: | |- Sergei spent some time filing bugs that we should fix in the | testsuite, because they fail --slow validate. I believe these are | two | of them: | | - https://ghc.haskell.org/trac/ghc/ticket/9567 | - https://ghc.haskell.org/trac/ghc/ticket/9566 | | Yeah, I believe the complete list for --slow is only 5 failures: | | https://ghc.haskell.org/trac/ghc/ticket/9565 - dead loop in simplifier | https://ghc.haskell.org/trac/ghc/ticket/9424 - debugged ghc does not | unload Show instances after data redefinition (or not :]) | https://ghc.haskell.org/trac/ghc/ticket/9426 - something similar with | redefinition in ghci | https://ghc.haskell.org/trac/ghc/ticket/9566 - corelint error in | simplifier | https://ghc.haskell.org/trac/ghc/ticket/9567 - another corelint error | in simplifier | | -- | |Sergei ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: are patterns synonyms definable in GHCI?
On Thu, 18 Dec 2014, Carter Schonwald wrote: Hey all,I was trying to define some pattern synonyms in ghci recently, and that doesnt seem to work. Is that something slated to be fix in 7.10 or something? I thought GHCi accepts things that would be valid in a 'do' section? So e.g. x = () doesn't work in GHCi, but let x = () does. Pattern synonyms don't work for the exact same reason: they are not valid inside a 'do' block. ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
RE: are patterns synonyms definable in GHCI?
But GHCi does support data type declarations ghci data T = A | B so presumably it ought also to support pattern synonym declarations. Simon | -Original Message- | From: ghc-devs [mailto:ghc-devs-boun...@haskell.org] On Behalf Of Dr. | ERDI Gergo | Sent: 18 December 2014 10:52 | To: Carter Schonwald | Cc: ghc-devs@haskell.org | Subject: Re: are patterns synonyms definable in GHCI? | | On Thu, 18 Dec 2014, Carter Schonwald wrote: | | Hey all,I was trying to define some pattern synonyms in ghci | recently, | and that doesnt seem to work. Is that something slated to be fix in | 7.10 or something? | | I thought GHCi accepts things that would be valid in a 'do' section? | So e.g. | | x = () | | doesn't work in GHCi, but | | let x = () | | does. | | Pattern synonyms don't work for the exact same reason: they are not | valid inside a 'do' block. | ___ | ghc-devs mailing list | ghc-devs@haskell.org | http://www.haskell.org/mailman/listinfo/ghc-devs ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: are patterns synonyms definable in GHCI?
ghci also accepts a number of other things. You can define data types, type synonyms, classes, instances, so pattern synonyms would seem to fall into scope. On Thu, Dec 18, 2014 at 5:51 AM, Dr. ERDI Gergo ge...@erdi.hu wrote: On Thu, 18 Dec 2014, Carter Schonwald wrote: Hey all,I was trying to define some pattern synonyms in ghci recently, and that doesnt seem to work. Is that something slated to be fix in 7.10 or something? I thought GHCi accepts things that would be valid in a 'do' section? So e.g. x = () doesn't work in GHCi, but let x = () does. Pattern synonyms don't work for the exact same reason: they are not valid inside a 'do' block. ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: are patterns synonyms definable in GHCI?
On 18/12/14 12:51, Dr. ERDI Gergo wrote: On Thu, 18 Dec 2014, Carter Schonwald wrote: Hey all,I was trying to define some pattern synonyms in ghci recently, and that doesnt seem to work. Is that something slated to be fix in 7.10 or something? I thought GHCi accepts things that would be valid in a 'do' section? So e.g. x = () doesn't work in GHCi, but let x = () does. Pattern synonyms don't work for the exact same reason: they are not valid inside a 'do' block. That's not true. Since 7.6, IIRC, you can define data types and instances in ghci. See also https://ghc.haskell.org/trac/ghc/ticket/7253 Roman ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Can we rename completion to autocomplete
Bump. Any decisions on this one? If not then I'll move that folder somewhere else because it's getting in the way. Janek ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Can we rename completion to autocomplete
I'd say just move it under utils/. We really need to organize the top-folder more, but that's for another day. On Thu, Dec 18, 2014 at 11:18 AM, Jan Stolarek jan.stola...@p.lodz.pl wrote: Bump. Any decisions on this one? If not then I'll move that folder somewhere else because it's getting in the way. Janek ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/ ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
RFC: Remove -fwarn-unticked-promoted-constructors from -Wall
We recently got a new warning -fwarn-unticked-promoted-constructors (see #9778 and D534). This warning is enabled with -Wall but I think that this is not a good idea. I strongly propose to remove it with -Wall. Rationale: 1. I feel that ticks add unnecessary noise: prDictOfPReprInstTyCon :: Type - CoAxiom 'Unbranched - [Type] - VM CoreExpr To me it feels awkward to have Unbranched with a tick but CoreExpr without a tick (both are types after all). Moreover, ticks also trip many syntax highlighters, which further degrades code readability. 2. I've been refactoring some of GHC code to use promoted types instead of empty data types (see CoAxiom.BranchList). This would have been a fairly local change, except that I have to add ticks in every place that mentiones promoted types. That's a Royal Pain and a good example how this warning can get in people's way. Janek ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: RFC: Remove -fwarn-unticked-promoted-constructors from -Wall
For what it's worth, I don't have a strong feeling either way here. Arguments in favor of keeping -fwarn-unticked-promoted-constructors in -Wall: 1. It's weird having GHC look in one namespace (types) and then look in another (terms) only when the first one fails. In other scenarios, ambiguity is an error. 2. If I have my way (https://ghc.haskell.org/trac/ghc/wiki/DependentHaskell), this problem will only get worse. 3. Whenever presenting code involving promoted constructors, I put the tick marks in everywhere, as I think it makes the code easier to understand. 4. There is an easy workaround: type Unbranched = 'Unbranched Arguments against keeping -fwarn-unticked-promoted-constructors in -Wall: 1,2. As Janek. 3. If you've made a mistake around using a type where a promoted data constructor is meant, or vice versa, it's very likely you have an error in your code. This will lead to a perhaps-obscure, perhaps-confusing error message instead of a nice clean warning, which is suppressed when there are errors. Adding this all up, I can't really decide which is best. Richard On Dec 18, 2014, at 12:26 PM, Jan Stolarek jan.stola...@p.lodz.pl wrote: We recently got a new warning -fwarn-unticked-promoted-constructors (see #9778 and D534). This warning is enabled with -Wall but I think that this is not a good idea. I strongly propose to remove it with -Wall. Rationale: 1. I feel that ticks add unnecessary noise: prDictOfPReprInstTyCon :: Type - CoAxiom 'Unbranched - [Type] - VM CoreExpr To me it feels awkward to have Unbranched with a tick but CoreExpr without a tick (both are types after all). Moreover, ticks also trip many syntax highlighters, which further degrades code readability. 2. I've been refactoring some of GHC code to use promoted types instead of empty data types (see CoAxiom.BranchList). This would have been a fairly local change, except that I have to add ticks in every place that mentiones promoted types. That's a Royal Pain and a good example how this warning can get in people's way. Janek ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Random holiday fun: Vote for buildbot naming conventions!
dont forget you can vote for more than one! On Thu, Dec 18, 2014 at 12:08 AM, Austin Seipp aus...@well-typed.com wrote: Hi *, Everyone has been working hard getting things ready for the branch/RC later this week - and that's really appreciated! As always, GHC wouldn't be what it is without you. But it's the holidays - that's stressful for some, and real time consuming for others. So to keep things light and a little interesting, and if you have a minute as an experiment, I'd like to ask you all something: What naming conventions should we use for GHC buildbots? We've been adding more bots recently, and we've just gotten hold of some new hardware this week. Currently, GHC buildbots don't have any reserved name or identifier, or DNS entries. I'd like to change that - we mostly refer to them by IP, but this is annoying A) to remember and B) to tell other people. We'll likely begin to lease out these machines to developers so they can test and debug - meaning they'll be mentioned more. I'd like to propose a theme for naming buildbots - this theme would be used to populate DNS entries under the *.ghc.haskell.org domain. The question is: what naming convention do we use? So I created a poll for this. You can see that poll and vote for your favorite options on Phabricator: - https://phabricator.haskell.org/V3 It's an approval vote rather than a plurality; so feel free to select multiple choices. The winner with the most votes will get selected. Note: the selection of options is relatively random and pre-selected; there is an upper limit on the number of choices - 10 max - so I merely picked some categories I thought would work and be generic enough. I imagine this vote will be open for about a week or so. I'd like it if developers could vote on their favorites, or simply leave comments on the vote for further suggestion - we could institute a vote with better names. Thanks all - and be sure to have happy holidays. P.S I did not know RFC 1178 existed before today. Seems like there's one for everything... -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/ ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: GHC Weekly News - 2014/12/16
Austin Seipp wrote: - This week, Austin managed to secure two sponsors for GHC/Haskell.org. We've been given a wonderful set of ARM buildbots (running in the cloud!) and a new, incredibly powerful POWER8 machine to use (with over 170 hardware threads available, for scalability testing). Hooray for our friends at Online.net and RunAbove.com for helping us out! Austin, Any chance you could tell us a little more about these machines, in particular the Arm machines? Cheers, Erik -- -- Erik de Castro Lopo http://www.mega-nerd.com/ ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
