From klebinger.andreas at gmx.at Sat Sep 1 10:13:06 2018 From: klebinger.andreas at gmx.at (Andreas Klebinger) Date: Sat, 01 Sep 2018 12:13:06 +0200 Subject: Compile times: Average vs worst case runtime In-Reply-To: <5B886961.3030603@gmx.at> References: <5B882489.3060305@gmx.at> <5B886961.3030603@gmx.at> Message-ID: <5B8A6632.9010108@gmx.at> I've looked further into this. The bad news is the ratio is likely not a useful indicator for compile time. The good news is I spent the last day and a half profiling and optimizing the code and found the major reason why performance degraded so fast. There was a certain pattern which had complexity of O(blocks * branches) which now should be O(blocks * log branches) with negligibly increased memory usage. The worst cases I know (a function with 1500 guards compiled with -O0) is now only about 3% slower than the old algorithm. Which seems reasonable. I will check how this affects compile time for regular code and rerun benchmarks to make sure I've not introduced regressions. But if it holds up we should at least enable it at O1/O2. Depending how compile times are for regular code maybe for -O0 as well. Cheers Andreas Andreas Klebinger schrieb: > > Simon Peyton Jones schrieb: >> Good work. >> >> | However it will also be possible to fall back to the old behavior to >> | avoid the large compile times for modules known to trigger this >> | edge case. >> >> Not for specific modules, I hope; rather fall back when the number of >> cases becomes large, or something like that? That'd be fine. > As it stands it's a regular flag and hence per Module (just like > worker wrapper or similar) and user controlled. > In the code example I have in my head it was a large case that get's > desugared to a larger chain of if/elseif/elseif/..../else. > So it's not strictly large cases but usually it is. > > I actually didn't consider doing a "dynamic" fall back so far. That's > a great idea! > If we are lucky we can use the ratio of edges to blocks, and fall back > to the old one if we are above a certain function size and ratio. > With the threshold in turn depending on the optimization level. > > But not sure if that's good design as we then end up with cases where > performance suddenly gets 5% worse if > people add a constructor or code get's slightly larger for some reason. >> >> The only other potential worry is how tricky/understandable is your >> patch. Hopefully it's not hard. > I hope so, the algorithm itself isn't that complicated to some of the > stuff in GHC and I tried to document it well. > But it's also far from being trivial code. >> >> | 1. Always since on average both compile and runtime is faster. >> | 2. -O1/O2 since users often use this when performance matters. >> | 3. -O2 since users expect compilation times to blow up with it? >> | 4. Never as users experience compile time slowdowns when they hit >> these >> | edge cases. >> >> Well, if you can robustly fall back in edge cases, you'll never hit >> the blow-ups. So then (1) would be fine would it not? > Guess I will have to see how well the edge/block ratio correlates with > compile time blowups. If we can use that to rule out the really bad > cases then (1) should be fine. > If not I will have to come back to the question. > > Cheers > Andreas >> >> Simon >> >> >> >> >> | -----Original Message----- >> | From: ghc-devs On Behalf Of Andreas >> | Klebinger >> | Sent: 30 August 2018 18:08 >> | To: ghc-devs at haskell.org >> | Subject: Compile times: Average vs worst case runtime >> | >> | Hello Devs, >> | >> | I developed a patch improving on GHC's code layout during GSoC: >> | https://ghc.haskell.org/trac/ghc/ticket/15124 >> | The gains are pretty nice with most library benchmarks showing >> | improvments in the 1-2% range or more. >> | >> | Even compile times went down comparing head vs stage2 built with, and >> | using my patch! >> | Making compilation of nofib overall faster by 0.5-1% depending on the >> | exact setup. >> | >> | Now the bad news: >> | In some cases the algorithm has bad big O performance, in practice >> this >> | seems to be code with >> | things like cases with 200+ alternatives. Where these cases also >> | represent most of the code compiled. >> | >> | The worst case I saw was doubled compile time in a Module which only >> | consisted of a 500 deep if/else chain only selecting >> | an value. >> | >> | While there are some small optimizations possible to improve on this I >> | don't expect to make these edge cases much faster overall. >> | However it will also be possible to fall back to the old behavior to >> | avoid the large compile times for modules known to trigger this >> | edge case. >> | >> | Which brings me to my main question: When should we use the new code >> | layout. >> | 1. Always since on average both compile and runtime is faster. >> | 2. -O1/O2 since users often use this when performance matters. >> | 3. -O2 since users expect compilation times to blow up with it? >> | 4. Never as users experience compile time slowdowns when they hit >> these >> | edge cases. >> | >> | I'm would prefer 2. 3. 1. 4. in that order but I wonder what the wider >> | community is thinking. >> | >> | Cheers >> | Andreas >> | _______________________________________________ >> | ghc-devs mailing list >> | ghc-devs at haskell.org >> | http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > From klebinger.andreas at gmx.at Sun Sep 2 13:44:56 2018 From: klebinger.andreas at gmx.at (Andreas Klebinger) Date: Sun, 02 Sep 2018 15:44:56 +0200 Subject: CI failures on OSX Message-ID: <5B8BE958.3050606@gmx.at> Hello devs, OSX CI seems to have testsuite failures since at least 44ba66527ae2 (but likely caused by something else) and started sometime after 966aa7818222 going by the Phab history. So seems to have been caused by one of the commits on Aug 22. Could anyone with an Mac take a look there? Cheers Andreas -------------- next part -------------- An HTML attachment was scrubbed... URL: From cheng.shao at tweag.io Sun Sep 2 14:06:35 2018 From: cheng.shao at tweag.io (Shao, Cheng) Date: Sun, 2 Sep 2018 22:06:35 +0800 Subject: cc1plus.exe of bundled mingw-w64 segfaults Message-ID: Hi folks, I'm building a Haskell/C++ hybrid project with a recent revision of ghc on Windows, and noticed that cc1plus.exe always segfaults. The same code builds fine on AppVeyor however and currently I have no clue why it ceases to work on my machine. Is anyone else experiencing a similar problem? I'm not sure if it's worth a trac ticket. Using cc1plus.exe from a newer version of mingw-w64-x86_64-gcc works on my machine, but weird linker errors arise when I attempt to use the newer gcc toolchain to override the bundled one. Is there a way to manually specify mingw-w64 tarball version/urls when configuring ghc? I notice there's an "--enable-distro-toolchain" flag, does it work with building a bindist? Thank you. Regards, Shao Cheng From cheng.shao at tweag.io Sun Sep 2 19:36:11 2018 From: cheng.shao at tweag.io (Shao, Cheng) Date: Mon, 3 Sep 2018 03:36:11 +0800 Subject: cc1plus.exe of bundled mingw-w64 segfaults In-Reply-To: References: Message-ID: I managed to build a ghc bindist which bundles gcc 8.2.0, and cc1plus.exe works as intended now. However, I'm getting linker errors like: ``` ghc.EXE: unable to load package `ghc-prim-0.5.3' ghc.EXE: | C:\Users\Think\AppData\Local\Programs\stack\x86_64-windows\ghc-8.7.20180902\mingw\x86_64-w64-mingw32\lib\libmingw32.a: unknown symbol `__acrt_iob_func' ghc.EXE: | C:\Users\Think\AppData\Local\Programs\stack\x86_64-windows\ghc-8.7.20180902\mingw\x86_64-w64-mingw32\lib\libmingwex.a: unknown symbol `__mingw_raise_matherr' ghc.EXE: | C:\Users\Think\AppData\Local\Programs\stack\x86_64-windows\ghc-8.7.20180902\lib\ghc-prim-0.5.3\HSghc-prim-0.5.3.o: unknown symbol `exp' ``` I checked ghc-prim.cabal, but saw that on Windows ghc-prim already links with libmingw32.a/libmingwex.a, which is supposed to provide `__mingw_raise_matherr`, etc. Is there any other library to link, or something else has gone wrong? Thank you. __ On Sun, Sep 2, 2018 at 10:06 PM, Shao, Cheng wrote: > Hi folks, > > I'm building a Haskell/C++ hybrid project with a recent revision of > ghc on Windows, and noticed that cc1plus.exe always segfaults. The > same code builds fine on AppVeyor however and currently I have no clue > why it ceases to work on my machine. Is anyone else experiencing a > similar problem? I'm not sure if it's worth a trac ticket. > > Using cc1plus.exe from a newer version of mingw-w64-x86_64-gcc works > on my machine, but weird linker errors arise when I attempt to use the > newer gcc toolchain to override the bundled one. Is there a way to > manually specify mingw-w64 tarball version/urls when configuring ghc? > I notice there's an "--enable-distro-toolchain" flag, does it work > with building a bindist? Thank you. > > Regards, > Shao Cheng From simonpj at microsoft.com Mon Sep 3 12:54:42 2018 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Mon, 3 Sep 2018 12:54:42 +0000 Subject: [commit: ghc] master: make iToBase62's inner loop stricter in one of its arguments (ed78951) In-Reply-To: <20180902211616.1E07D3A8E4@ghc.haskell.org> References: <20180902211616.1E07D3A8E4@ghc.haskell.org> Message-ID: Alp, Is this related to #15570. If so, it'd be good to make that connection. S | -----Original Message----- | From: ghc-commits On Behalf Of | git at git.haskell.org | Sent: 02 September 2018 22:16 | To: ghc-commits at haskell.org | Subject: [commit: ghc] master: make iToBase62's inner loop stricter in | one of its arguments (ed78951) | | Repository : ssh://git at git.haskell.org/ghc | | On branch : master | Link : | https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fghc.haske | ll.org%2Ftrac%2Fghc%2Fchangeset%2Fed789516e201e4fad771e5588da47a62e53b42b | 8%2Fghc&data=02%7C01%7Csimonpj%40microsoft.com%7Cea714d654b04488aada9 | 08d6111955e2%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636715197856324 | 232&sdata=3Oo7y3FCIzEZVAWc%2FPl6ZXwji2QM2CWWAI3UfHqxDn0%3D&reserv | ed=0 | | >--------------------------------------------------------------- | | commit ed789516e201e4fad771e5588da47a62e53b42b8 | Author: Alp Mestanogullari | Date: Sun Sep 2 22:06:55 2018 +0200 | | make iToBase62's inner loop stricter in one of its arguments | | Summary: | hadrian's support for dynamic ways is currently broken (see | hadrian#641 [1]). | The stage 1 GHCs that hadrian produces end up producing bad code for | the `iToBase62` function after a few optimisation passes. | | In the case where `quotRem` returns (overflowError, 0), | GHC isn't careful enough to realise q is _|_ and happily inlines, | distributes and floats code around until we end up trying to access | index `minBound :: Int` of an array of 62 chars, as a result of | inlining | the definition of `quotRem` for Ints, in particular the minBound | branch [2]. | | I will separately look into reproducing the bad transformation on a | small | self-contained example and filling a ticket. | | [1]: | https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.c | om%2Fsnowleopard%2Fhadrian%2Fissues%2F641&data=02%7C01%7Csimonpj%40mi | crosoft.com%7Cea714d654b04488aada908d6111955e2%7C72f988bf86f141af91ab2d7c | d011db47%7C1%7C0%7C636715197856324232&sdata=a7dM0YbraOY69xKhJcwVuQqBn | 3n3nTdVuMFNjie6iHA%3D&reserved=0 | [2]: | https://git.haskell.org/ghc.git/blob/HEAD:/libraries/base/GHC/Real.hs#l36 | 6 | | Test Plan: fixes hadrian#641 | | Reviewers: bgamari, tdammers | | Reviewed By: tdammers | | Subscribers: tdammers, rwbarton, carter | | Differential Revision: https://phabricator.haskell.org/D5106 | | | >--------------------------------------------------------------- | | ed789516e201e4fad771e5588da47a62e53b42b8 | compiler/basicTypes/Unique.hs | 2 +- | 1 file changed, 1 insertion(+), 1 deletion(-) | | diff --git a/compiler/basicTypes/Unique.hs | b/compiler/basicTypes/Unique.hs index 4a709d2..b5c0fce 100644 | --- a/compiler/basicTypes/Unique.hs | +++ b/compiler/basicTypes/Unique.hs | @@ -325,7 +325,7 @@ iToBase62 n_ | go n cs | n < 62 | = let !c = chooseChar62 n in c : cs | | otherwise | - = go q (c : cs) where (q, r) = quotRem n 62 | + = go q (c : cs) where (!q, r) = quotRem n 62 | !c = chooseChar62 r | | chooseChar62 :: Int -> Char | | _______________________________________________ | ghc-commits mailing list | ghc-commits at haskell.org | https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmail.hask | ell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc- | commits&data=02%7C01%7Csimonpj%40microsoft.com%7Cea714d654b04488aada9 | 08d6111955e2%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636715197856324 | 232&sdata=5oKSdyvdcyJlPR%2FtNUNuptlsFuv9jJA%2FVmc7AOid5mc%3D&rese | rved=0 From david.feuer at gmail.com Mon Sep 3 17:00:39 2018 From: david.feuer at gmail.com (David Feuer) Date: Mon, 3 Sep 2018 13:00:39 -0400 Subject: Unpacking coercions Message-ID: I had an idea for how we might be able to unpack coercions in a limited and conservative way that doesn't get into the general problems of unpacking constraints. Would this make sense? 1. Move the definition of Coercion from Data.Type.Coercion to GHC.Magic 2. Magically change the type of the Coercion constructor from Coercion :: Coercible a b => Coercion a b to Coercion :: a ~R# b => Coercion a b Now a strict Coercion field will unpack to nothing. -------------- next part -------------- An HTML attachment was scrubbed... URL: From dominique.devriese at cs.kuleuven.be Tue Sep 4 09:07:44 2018 From: dominique.devriese at cs.kuleuven.be (Dominique Devriese) Date: Tue, 4 Sep 2018 11:07:44 +0200 Subject: Call for Presentations on Secure Compilation (PriSC Workshop @ POPL'19) Message-ID: (apologies if you receive multiple copies of this announcement) ======================================================================= Call for Presentations on Secure Compilation (PriSC Workshop @ POPL'19) ======================================================================= The emerging field of secure compilation aims to preserve security properties of programs when they have been compiled to low-level languages such as assembly, where high-level abstractions don’t exist, and unsafe, unexpected interactions with libraries, other programs, the operating system and even the hardware are possible. For unsafe source languages like C, secure compilation requires careful handling of undefined source-language behavior (like buffer overflows and double frees). Formally, secure compilation aims to protect high-level language abstractions in compiled code, even against adversarial low-level contexts, thus enabling sound reasoning about security in the source language. A complementary goal is to keep the compiled code efficient, often leveraging new hardware security features and advances in compiler design. Other necessary components are identifying and formalizing properties that secure compilers must possess, devising efficient security mechanisms (both software and hardware), and developing effective verification and proof techniques. Research in the field thus puts together advances in compiler design, programming languages, systems security, verification, and computer architecture. ============================================================= 3rd Workshop on Principles of Secure Compilation (PriSC 2019) ============================================================= The Workshop on Principles of Secure Compilation (PriSC) is a relatively new, informal 1-day workshop without any proceedings. The goal is to bring together researchers interested in secure compilation and to identify interesting research directions and open challenges. The 3rd edition of PriSC will be held in Lisbon, together with the ACM SIGPLAN-SIGACT Symposium on Principles of Programming Languages (POPL), 2019. The exact date will be either January 13 or January 19 (to be decided by the POPL organizers). More information is available at http://popl19.sigplan.org/track/prisc-2019 Important Dates * Presentation proposal submission deadline: 17 October 2018, AoE * Presentation proposal notification: 10 November 2018 * PriSC Workshop takes place: either Sunday, 13 January 2019 or Saturday 19 January 2019 (to be decided by the POPL organizers) ================================================= Presentation Proposals and Attending the Workshop ================================================= Anyone interested in presenting at the workshop should submit an extended abstract (up to 2 pages, details below) covering past, ongoing, or future work. Any topic that could be of interest to secure compilation is in scope. Secure compilation should be interpreted very broadly to include any work in security, programming languages, architecture, systems or their combination that can be leveraged to preserve security properties of programs when they are compiled or to eliminate low-level vulnerabilities. Presentations that provide a useful outside view or challenge the community are also welcome. This includes presentations on new attack vectors such as microarchitectural side-channels, whose defenses could benefit from compiler techniques. Specific topics of interest include but are not limited to: * attacker models for secure compiler chains. * secure compiler properties: fully abstract compilation and similar properties, memory safety, control-flow integrity, preservation of safety, information flow and other (hyper-)properties against adversarial contexts, secure multi-language interoperability. * secure interaction between different programming languages: foreign function interfaces, gradual types, securely combining different memory management strategies. * enforcement mechanisms and low-level security primitives: static checking, program verification, typed assembly languages, reference monitoring, program rewriting, software-based isolation/hiding techniques (SFI, crypto-based, randomization-based, OS/hypervisor-based), security-oriented architectural features such as Intel’s SGX, MPX and MPK, capability machines, side-channel defenses, object capabilities. * experimental evaluation and applications of secure compilers. * proof methods relevant to compilation: (bi)simulation, logical relations, game semantics, trace semantics, multi-language semantics, embedded interpreters. * formal verification of secure compilation chains (protection mechanisms, compilers, linkers, loaders), machine-checked proofs, translation validation, property-based testing. ============================================ Guidelines for Submitting Extended Abstracts ============================================ Extended abstracts should be submitted in PDF format and not exceed 2 pages. They should be formatted in two-column layout, 10pt font, and be printable on A4 and US Letter sized paper. We recommend using the new acmart LaTeX style in sigplan mode: http://www.sigplan.org/sites/default/files/acmart/current/acmart-sigplanproc.zip Submissions are not anonymous and should provide sufficient detail to be assessed by the program committee. Presentation at the workshop does not preclude publication elsewhere. Please submit your extended abstracts at https://prisc19.hotcrp.com/. ============================ Contact and More Information ============================ For questions please contact the workshop chairs, Dominique Devriese ( dominique.devriese at cs.kuleuven.be) and Deepak Garg (dg at mpi-sws.org). To make sure you receive such announcements in the future please subscribe to the following low-traffic mailing list: https://lists.gforge.inria.fr/mailman/listinfo/prisc-announce -------------- next part -------------- An HTML attachment was scrubbed... URL: From ryan.gl.scott at gmail.com Tue Sep 4 13:01:46 2018 From: ryan.gl.scott at gmail.com (Ryan Scott) Date: Tue, 4 Sep 2018 09:01:46 -0400 Subject: Unpacking coercions Message-ID: If we can gain some performance from this, then I'm generally supportive of this idea. I'm still of the belief that we could teach GHC to unpack boxed equality constraints, but your idea would definitely be the simpler one to implement. Ryan S. -------------- next part -------------- An HTML attachment was scrubbed... URL: From matthewtpickering at gmail.com Tue Sep 4 14:18:47 2018 From: matthewtpickering at gmail.com (Matthew Pickering) Date: Tue, 4 Sep 2018 15:18:47 +0100 Subject: Is combining StaticPointers and TemplateHaskell safe? Message-ID: I can implement a function which acts like `lift` using static pointers in the following way: ``` liftS :: StaticPtr a -> Q (TExp a) liftS sp = let sk = staticKey sp in [|| deRefStaticPtr (fromJust (unsafePerformIO (unsafeLookupStaticPtr sk))) ||] ``` The question, is this safe in general? It seems to me that this referencing should be safe because I could have achieved the same without quoting using `deRefStaticPtr` directly. The only reason I have to use the `unsafeLookup` function is because `StaticPtr` is not an instance of `Lift`. However, it's a bit annoying that this lookup has to be deferred to runtime, would it be acceptable to add an extra field to `StaticPtr a` which contained a `TExp a` value? Then the implementation of `liftS` just extracts this value from the `StaticPtr`. Using `static` is preferable to using `lift` in many situations as `Lift` is implemented using a type class it can't lift things such as 1. functions and 2. top-level identifiers. Further to this, it's annoying to have to incur a `Lift a` constraint when trying to lift `Nothing`. `static` has none of these problems. Cheers, Matt From simonpj at microsoft.com Tue Sep 4 15:37:05 2018 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Tue, 4 Sep 2018 15:37:05 +0000 Subject: Unpacking coercions In-Reply-To: References: Message-ID: It would be good to have a clear problem statement, plus an example of a program that runs more slowly than it “should”. Simon From: ghc-devs On Behalf Of Ryan Scott Sent: 04 September 2018 14:02 To: ghc-devs at haskell.org Subject: Re: Unpacking coercions If we can gain some performance from this, then I'm generally supportive of this idea. I'm still of the belief that we could teach GHC to unpack boxed equality constraints, but your idea would definitely be the simpler one to implement. Ryan S. -------------- next part -------------- An HTML attachment was scrubbed... URL: From simonpj at microsoft.com Tue Sep 4 15:48:36 2018 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Tue, 4 Sep 2018 15:48:36 +0000 Subject: Hadrian In-Reply-To: References: Message-ID: Very confusingly https://github.com/snowleopard/hadrian/blob/master/doc/user-settings.md#verbose-command-lines speaks about verboseCommmands PLURAL, whereas it should say verboseCommand SINGLUAR. Moreover, what is the language things you can say (i.e. where is it documented). The "//" business, and what patterns can occur. What things other than "//" can you have? What about 'input' etc? Simon | -----Original Message----- | From: Andrey Mokhov | Sent: 30 August 2018 12:26 | To: Simon Peyton Jones ; Alp Mestanogullari | | Cc: ghc-devs | Subject: RE: Hadrian | | Simon, | | If you want to see all command lines, you can pass '--verbose' or '-V' | flag to Hadrian and it will then print out everything it does. | | But you can also choose which particular command lines to print in | UserSettings, see: | | https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.c | om%2Fsnowleopard%2Fhadrian%2Fblob%2Fmaster%2Fdoc%2Fuser- | settings.md%23verbose-command- | lines&data=02%7C01%7Csimonpj%40microsoft.com%7C0c6118a504f74269efd508 | d60e6b4fe7%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C63671225140342623 | 1&sdata=tMYhmIGMeVbBYjAtxWQTY5%2F4Kyfc4m981N4OTowGkbQ%3D&reserved | =0 | | So, you can do: | | verboseCommand = input "//GHC/Real.hs" | | Or, alternatively, | | verboseCommand = output "//GHC/Real.hi" | | Both should produce the same result (in theory). | | In general, we have the following documents on Hadrian: | | The README: | https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.c | om%2Fsnowleopard%2Fhadrian%2Fblob%2Fmaster%2FREADME.md&data=02%7C01%7 | Csimonpj%40microsoft.com%7C0c6118a504f74269efd508d60e6b4fe7%7C72f988bf86f | 141af91ab2d7cd011db47%7C1%7C0%7C636712251403426231&sdata=7WigmQG7lbDd | eyhYCSaKOQEb0eeZcn0iXAbAKdwZ5A4%3D&reserved=0 | How to use UserSettings: | https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.c | om%2Fsnowleopard%2Fhadrian%2Fblob%2Fmaster%2Fdoc%2Fuser- | settings.md&data=02%7C01%7Csimonpj%40microsoft.com%7C0c6118a504f74269 | efd508d60e6b4fe7%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C63671225140 | 3426231&sdata=tRu2lO%2F6TNV3ao5tzNKO%2FAHJMWsxKX%2BqExHn78nuCvU%3D&am | p;reserved=0 | An overview of build flavours: | https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.c | om%2Fsnowleopard%2Fhadrian%2Fblob%2Fmaster%2Fdoc%2Fflavours.md&data=0 | 2%7C01%7Csimonpj%40microsoft.com%7C0c6118a504f74269efd508d60e6b4fe7%7C72f | 988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636712251403426231&sdata=Esye | DdAKLV9DC3PUwkqsuQ4zGoOYKcaJeEov1BAH8lU%3D&reserved=0 | | I hope the more Hadrian gets used, the more complete the documentation | will become. | | Cheers, | Andrey | | From: Simon Peyton Jones [mailto:simonpj at microsoft.com] | Sent: 30 August 2018 12:19 | To: Simon Peyton Jones ; Alp Mestanogullari | ; Andrey Mokhov | Cc: ghc-devs | Subject: RE: Hadrian | | Sigh.  As an inconvenient workaround, I tried adding {-# OPTIONS_GHC - | dverbose-core2core #-} to GHC.Real, and then doing |         cabal new-run hadrian -- -c -j4 --flavour=quick --directory=".." | in hadrian/ | That did recompile GHC.Real - but all the debug output disappeared! | I tried adding {-# OPTIONS_GHC -ddebug-output #-} as well, but that | didn't work. | I'm stuck - any ideas? | Simon | | From: ghc-devs On Behalf Of Simon Peyton | Jones via ghc-devs | Sent: 30 August 2018 12:12 | To: Alp Mestanogullari ; Andrey Mokhov | | Cc: ghc-devs | Subject: Hadrian | | Alp, Andrey | The old build system printed out every command line; and I often copy- | paste that info to build single modules. | Eg currently, when trying to understand #15570 I see a suspicious | GHC.Real.hi.  So I want to manually recompile GHC.Real (from base), | adding some debug flags.  How can I get the right command line to do that | from the build log? | Where is the "how to use Hadrian" wiki page?  I know you've been writing | one. | Simon From facundo.dominguez at tweag.io Tue Sep 4 15:48:50 2018 From: facundo.dominguez at tweag.io (=?UTF-8?Q?Facundo_Dom=C3=ADnguez?=) Date: Tue, 4 Sep 2018 12:48:50 -0300 Subject: Is combining StaticPointers and TemplateHaskell safe? In-Reply-To: References: Message-ID: Hello, > The question, is this safe in general? It looks like it would work as long as the meta expression is spliced in the library where the static form is defined, or in a library depending on it. > would it be acceptable to add an extra field to `StaticPtr a` which contained a `TExp a` value? That could work. It would produce a copy of the value though, rather than giving the value in the SPT. Best, Facundo On Tue, Sep 4, 2018 at 11:18 AM Matthew Pickering wrote: > > I can implement a function which acts like `lift` using static > pointers in the following way: > > ``` > liftS :: StaticPtr a -> Q (TExp a) > liftS sp = > let sk = staticKey sp > in [|| deRefStaticPtr (fromJust (unsafePerformIO > (unsafeLookupStaticPtr sk))) ||] > ``` > > The question, is this safe in general? It seems to me that this > referencing should be safe because > I could have achieved the same without quoting using `deRefStaticPtr` > directly. The only reason I have to use the `unsafeLookup` function is > because `StaticPtr` is not an instance of `Lift`. > > However, it's a bit annoying that this lookup has to be deferred to > runtime, would it be acceptable to add an extra field to `StaticPtr a` > which contained a `TExp a` value? Then the implementation of `liftS` > just extracts this value from the `StaticPtr`. > > Using `static` is preferable to using `lift` in many situations as > `Lift` is implemented using a type class it can't lift things such as > 1. functions and 2. top-level identifiers. Further to this, it's > annoying to have to incur a `Lift a` constraint when trying to lift > `Nothing`. `static` has none of these problems. > > Cheers, > > Matt > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs From ryan.gl.scott at gmail.com Tue Sep 4 16:15:10 2018 From: ryan.gl.scott at gmail.com (Ryan Scott) Date: Tue, 4 Sep 2018 12:15:10 -0400 Subject: Unpacking coercions Message-ID: In case this wasn't clear, the context of this discussion in this GHC proposal [1], where David is trying to work around the fact that data types with existential Coercible constraints do not support unpacking. (By "unpacking", I mean putting an {-# UNPACK #-} pragma in front of a field of that type does what you would expect.) An example program which demonstrates the performance issue can be found here [2]. That comment concerns unboxed equality vs. boxed equality, but the same unpacking problems that affect boxed equality also affect Coercible. Ryan S. ----- [1] https://github.com/ghc-proposals/ghc-proposals/pull/116 [2] https://github.com/ghc-proposals/ghc-proposals/pull/116#issuecomment-382346662 -------------- next part -------------- An HTML attachment was scrubbed... URL: From andrey.mokhov at newcastle.ac.uk Tue Sep 4 17:48:42 2018 From: andrey.mokhov at newcastle.ac.uk (Andrey Mokhov) Date: Tue, 4 Sep 2018 17:48:42 +0000 Subject: Hadrian In-Reply-To: References: Message-ID: Thanks Simon, I fixed the "verboseCommands" typo. Regarding various available predicates: indeed, we don't currently have a comprehensive description -- I've opened an issue for this and will hopefully fix it soon. In the meanwhile, there are a few examples of predicates in the rest of the doc/user-settings.md document, for example here: https://github.com/snowleopard/hadrian/blob/master/doc/user-settings.md#command-line-arguments. The `input` and `output` predicates accept Shake's `FilePattern` as parameters -- see the documentation for it here: https://hackage.haskell.org/package/shake-0.16.4/docs/Development-Shake.html#v:-63--61--61- Cheers, Andrey -----Original Message----- From: Simon Peyton Jones [mailto:simonpj at microsoft.com] Sent: 04 September 2018 16:49 To: Andrey Mokhov ; Alp Mestanogullari Cc: ghc-devs Subject: RE: Hadrian Very confusingly https://github.com/snowleopard/hadrian/blob/master/doc/user-settings.md#verbose-command-lines speaks about verboseCommmands PLURAL, whereas it should say verboseCommand SINGLUAR. Moreover, what is the language things you can say (i.e. where is it documented). The "//" business, and what patterns can occur. What things other than "//" can you have? What about 'input' etc? Simon | -----Original Message----- | From: Andrey Mokhov | Sent: 30 August 2018 12:26 | To: Simon Peyton Jones ; Alp Mestanogullari | | Cc: ghc-devs | Subject: RE: Hadrian | | Simon, | | If you want to see all command lines, you can pass '--verbose' or '-V' | flag to Hadrian and it will then print out everything it does. | | But you can also choose which particular command lines to print in | UserSettings, see: | | https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.c | om%2Fsnowleopard%2Fhadrian%2Fblob%2Fmaster%2Fdoc%2Fuser- | settings.md%23verbose-command- | lines&data=02%7C01%7Csimonpj%40microsoft.com%7C0c6118a504f74269efd508 | d60e6b4fe7%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C63671225140342623 | 1&sdata=tMYhmIGMeVbBYjAtxWQTY5%2F4Kyfc4m981N4OTowGkbQ%3D&reserved | =0 | | So, you can do: | | verboseCommand = input "//GHC/Real.hs" | | Or, alternatively, | | verboseCommand = output "//GHC/Real.hi" | | Both should produce the same result (in theory). | | In general, we have the following documents on Hadrian: | | The README: | https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.c | om%2Fsnowleopard%2Fhadrian%2Fblob%2Fmaster%2FREADME.md&data=02%7C01%7 | Csimonpj%40microsoft.com%7C0c6118a504f74269efd508d60e6b4fe7%7C72f988bf86f | 141af91ab2d7cd011db47%7C1%7C0%7C636712251403426231&sdata=7WigmQG7lbDd | eyhYCSaKOQEb0eeZcn0iXAbAKdwZ5A4%3D&reserved=0 | How to use UserSettings: | https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.c | om%2Fsnowleopard%2Fhadrian%2Fblob%2Fmaster%2Fdoc%2Fuser- | settings.md&data=02%7C01%7Csimonpj%40microsoft.com%7C0c6118a504f74269 | efd508d60e6b4fe7%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C63671225140 | 3426231&sdata=tRu2lO%2F6TNV3ao5tzNKO%2FAHJMWsxKX%2BqExHn78nuCvU%3D&am | p;reserved=0 | An overview of build flavours: | https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.c | om%2Fsnowleopard%2Fhadrian%2Fblob%2Fmaster%2Fdoc%2Fflavours.md&data=0 | 2%7C01%7Csimonpj%40microsoft.com%7C0c6118a504f74269efd508d60e6b4fe7%7C72f | 988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636712251403426231&sdata=Esye | DdAKLV9DC3PUwkqsuQ4zGoOYKcaJeEov1BAH8lU%3D&reserved=0 | | I hope the more Hadrian gets used, the more complete the documentation | will become. | | Cheers, | Andrey | | From: Simon Peyton Jones [mailto:simonpj at microsoft.com] | Sent: 30 August 2018 12:19 | To: Simon Peyton Jones ; Alp Mestanogullari | ; Andrey Mokhov | Cc: ghc-devs | Subject: RE: Hadrian | | Sigh.  As an inconvenient workaround, I tried adding {-# OPTIONS_GHC - | dverbose-core2core #-} to GHC.Real, and then doing |         cabal new-run hadrian -- -c -j4 --flavour=quick --directory=".." | in hadrian/ | That did recompile GHC.Real - but all the debug output disappeared! | I tried adding {-# OPTIONS_GHC -ddebug-output #-} as well, but that | didn't work. | I'm stuck - any ideas? | Simon | | From: ghc-devs On Behalf Of Simon Peyton | Jones via ghc-devs | Sent: 30 August 2018 12:12 | To: Alp Mestanogullari ; Andrey Mokhov | | Cc: ghc-devs | Subject: Hadrian | | Alp, Andrey | The old build system printed out every command line; and I often copy- | paste that info to build single modules. | Eg currently, when trying to understand #15570 I see a suspicious | GHC.Real.hi.  So I want to manually recompile GHC.Real (from base), | adding some debug flags.  How can I get the right command line to do that | from the build log? | Where is the "how to use Hadrian" wiki page?  I know you've been writing | one. | Simon From simonpj at microsoft.com Tue Sep 4 21:17:26 2018 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Tue, 4 Sep 2018 21:17:26 +0000 Subject: Hadrian In-Reply-To: References: Message-ID: Thanks! It's helpful to tell me, but more helpful still to augment the "How to use Hadrian" documentation, as you suggest. Simon | -----Original Message----- | From: Andrey Mokhov | Sent: 04 September 2018 18:49 | To: Simon Peyton Jones ; Alp Mestanogullari | | Cc: ghc-devs | Subject: RE: Hadrian | | Thanks Simon, | | I fixed the "verboseCommands" typo. | | Regarding various available predicates: indeed, we don't currently have | a comprehensive description -- I've opened an issue for this and will | hopefully fix it soon. | | In the meanwhile, there are a few examples of predicates in the rest of | the doc/user-settings.md document, for example here: | https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub. | com%2Fsnowleopard%2Fhadrian%2Fblob%2Fmaster%2Fdoc%2Fuser- | settings.md%23command-line- | arguments&data=02%7C01%7Csimonpj%40microsoft.com%7C4fb0515ae2e04363f | 28508d6128ea983%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C63671680127 | 5286560&sdata=mIM3eLPQOMc28uBN4kvA9q%2Fq3Z7aKud0fGme9c7Zk0c%3D&r | eserved=0. | | The `input` and `output` predicates accept Shake's `FilePattern` as | parameters -- see the documentation for it here: | | https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fhackage | .haskell.org%2Fpackage%2Fshake-0.16.4%2Fdocs%2FDevelopment- | Shake.html%23v%3A-63--61--61- | &data=02%7C01%7Csimonpj%40microsoft.com%7C4fb0515ae2e04363f28508d612 | 8ea983%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636716801275296568&a | mp;sdata=Lr9Q6ufGeauZt%2BxX4nmNC7gQkbfPvg%2Fa8gSTNEmB6AU%3D&reserved | =0 | | Cheers, | Andrey | | -----Original Message----- | From: Simon Peyton Jones [mailto:simonpj at microsoft.com] | Sent: 04 September 2018 16:49 | To: Andrey Mokhov ; Alp Mestanogullari | | Cc: ghc-devs | Subject: RE: Hadrian | | Very confusingly | https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub. | com%2Fsnowleopard%2Fhadrian%2Fblob%2Fmaster%2Fdoc%2Fuser- | settings.md%23verbose-command- | lines&data=02%7C01%7Csimonpj%40microsoft.com%7C4fb0515ae2e04363f2850 | 8d6128ea983%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636716801275296 | 568&sdata=6HmXCIghQhkAK1prpzhnCJa9bLUlcZwmsxdEJmULEVY%3D&reserve | d=0 | | speaks about verboseCommmands PLURAL, whereas it should say | verboseCommand SINGLUAR. | | Moreover, what is the language things you can say (i.e. where is it | documented). The "//" business, and what patterns can occur. What | things other than "//" can you have? What about 'input' etc? | | Simon | | | -----Original Message----- | | From: Andrey Mokhov | | Sent: 30 August 2018 12:26 | | To: Simon Peyton Jones ; Alp Mestanogullari | | | | Cc: ghc-devs | | Subject: RE: Hadrian | | | | Simon, | | | | If you want to see all command lines, you can pass '--verbose' or '- | V' | | flag to Hadrian and it will then print out everything it does. | | | | But you can also choose which particular command lines to print in | | UserSettings, see: | | | | | https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub. | c | | om%2Fsnowleopard%2Fhadrian%2Fblob%2Fmaster%2Fdoc%2Fuser- | | settings.md%23verbose-command- | | | lines&data=02%7C01%7Csimonpj%40microsoft.com%7C0c6118a504f74269efd50 | 8 | | | d60e6b4fe7%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6367122514034262 | 3 | | | 1&sdata=tMYhmIGMeVbBYjAtxWQTY5%2F4Kyfc4m981N4OTowGkbQ%3D&reserve | d | | =0 | | | | So, you can do: | | | | verboseCommand = input "//GHC/Real.hs" | | | | Or, alternatively, | | | | verboseCommand = output "//GHC/Real.hi" | | | | Both should produce the same result (in theory). | | | | In general, we have the following documents on Hadrian: | | | | The README: | | | https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub. | c | | | om%2Fsnowleopard%2Fhadrian%2Fblob%2Fmaster%2FREADME.md&data=02%7C01% | 7 | | | Csimonpj%40microsoft.com%7C0c6118a504f74269efd508d60e6b4fe7%7C72f988bf86 | f | | | 141af91ab2d7cd011db47%7C1%7C0%7C636712251403426231&sdata=7WigmQG7lbD | d | | eyhYCSaKOQEb0eeZcn0iXAbAKdwZ5A4%3D&reserved=0 | | How to use UserSettings: | | | https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub. | c | | om%2Fsnowleopard%2Fhadrian%2Fblob%2Fmaster%2Fdoc%2Fuser- | | | settings.md&data=02%7C01%7Csimonpj%40microsoft.com%7C0c6118a504f7426 | 9 | | | efd508d60e6b4fe7%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6367122514 | 0 | | | 3426231&sdata=tRu2lO%2F6TNV3ao5tzNKO%2FAHJMWsxKX%2BqExHn78nuCvU%3D&a | m | | p;reserved=0 | | An overview of build flavours: | | | https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub. | c | | | om%2Fsnowleopard%2Fhadrian%2Fblob%2Fmaster%2Fdoc%2Fflavours.md&data= | 0 | | | 2%7C01%7Csimonpj%40microsoft.com%7C0c6118a504f74269efd508d60e6b4fe7%7C72 | f | | | 988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636712251403426231&sdata=Esy | e | | DdAKLV9DC3PUwkqsuQ4zGoOYKcaJeEov1BAH8lU%3D&reserved=0 | | | | I hope the more Hadrian gets used, the more complete the | documentation | | will become. | | | | Cheers, | | Andrey | | | | From: Simon Peyton Jones [mailto:simonpj at microsoft.com] | | Sent: 30 August 2018 12:19 | | To: Simon Peyton Jones ; Alp Mestanogullari | | ; Andrey Mokhov | | Cc: ghc-devs | | Subject: RE: Hadrian | | | | Sigh.  As an inconvenient workaround, I tried adding {-# OPTIONS_GHC | - | | dverbose-core2core #-} to GHC.Real, and then doing | |         cabal new-run hadrian -- -c -j4 --flavour=quick -- | directory=".." | | in hadrian/ | | That did recompile GHC.Real - but all the debug output disappeared! | | I tried adding {-# OPTIONS_GHC -ddebug-output #-} as well, but that | | didn't work. | | I'm stuck - any ideas? | | Simon | | | | From: ghc-devs On Behalf Of Simon | Peyton | | Jones via ghc-devs | | Sent: 30 August 2018 12:12 | | To: Alp Mestanogullari ; Andrey Mokhov | | | | Cc: ghc-devs | | Subject: Hadrian | | | | Alp, Andrey | | The old build system printed out every command line; and I often | copy- | | paste that info to build single modules. | | Eg currently, when trying to understand #15570 I see a suspicious | | GHC.Real.hi.  So I want to manually recompile GHC.Real (from base), | | adding some debug flags.  How can I get the right command line to do | that | | from the build log? | | Where is the "how to use Hadrian" wiki page?  I know you've been | writing | | one. | | Simon From simonpj at microsoft.com Tue Sep 4 22:10:59 2018 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Tue, 4 Sep 2018 22:10:59 +0000 Subject: Unpacking coercions In-Reply-To: References: Message-ID: Ah yes thanks. As I suggest on that thread, I’d really like (someone) to try the “let’s make all evidence strict” idea. I think it could be a perf win all round. And if so, we’d get what David wants for free. Simon From: ghc-devs On Behalf Of Ryan Scott Sent: 04 September 2018 17:15 To: ghc-devs at haskell.org Subject: Re: Unpacking coercions In case this wasn't clear, the context of this discussion in this GHC proposal [1], where David is trying to work around the fact that data types with existential Coercible constraints do not support unpacking. (By "unpacking", I mean putting an {-# UNPACK #-} pragma in front of a field of that type does what you would expect.) An example program which demonstrates the performance issue can be found here [2]. That comment concerns unboxed equality vs. boxed equality, but the same unpacking problems that affect boxed equality also affect Coercible. Ryan S. ----- [1] https://github.com/ghc-proposals/ghc-proposals/pull/116 [2] https://github.com/ghc-proposals/ghc-proposals/pull/116#issuecomment-382346662 -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.feuer at gmail.com Tue Sep 4 23:22:55 2018 From: david.feuer at gmail.com (David Feuer) Date: Tue, 4 Sep 2018 19:22:55 -0400 Subject: ForeignPtr representation Message-ID: I'm trying, and failing, to understand why ForeignPtr is defined the way it is. It all seems rather complicated and redundant. I was thinking we might want to switch to something simpler and more explicit, like this: data ForeignPtr a = ForeignPtr { fptr :: !(Ptr a) -- What we point to froot :: MutableByteArray# RealWorld fwk :: MutVar# RealWorld Any -- The finalizers } froot represents the object the ForeignPtr points into. When created by one of the malloc variants, this will actually be the allocated byte array. Otherwise, it will be a 0-length array. fwk should be seen as having type fwk :: MutVar# RealWorld (Weak# (MutableByteArray# RealWorld)) but we can't express that directly right now. fwk is keyed on froot, and in the malloc case also points to it, to prevent it from being freed prematurely. It seems that this representation requires a couple extra primitive features from Weak#. I think that's okay: Weak# already has some primitive features designed to support ForeignPtr. 1. An operation to add a Haskell finalizer to a Weak#, similar to the one that adds a C finalizer. 2. A way to deal with mixed finalizers: either make the finalizer-adding primops report distinguishable failure on mixing or arrange to run the C finalizers after any Haskell finalizers (since C finalizers are much more likely to actually invalidate the pointer). 3. A documented guarantee about the order in which the finalizers attached to a particular Weak# run, compatible with the ForeignPtr documentation. -------------- next part -------------- An HTML attachment was scrubbed... URL: From simonpj at microsoft.com Tue Sep 4 23:40:02 2018 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Tue, 4 Sep 2018 23:40:02 +0000 Subject: ForeignPtr representation In-Reply-To: References: Message-ID: Interesting. Can you summarise how ForeignPtr is defined right now? And point to any documentation about the specification of ForeignPtr, or Notes about its implementation? So that we can compare with what your proposal. What’s the connection with weak pointers? Simon From: ghc-devs On Behalf Of David Feuer Sent: 05 September 2018 00:23 To: ghc-devs Subject: ForeignPtr representation I'm trying, and failing, to understand why ForeignPtr is defined the way it is. It all seems rather complicated and redundant. I was thinking we might want to switch to something simpler and more explicit, like this: data ForeignPtr a = ForeignPtr { fptr :: !(Ptr a) -- What we point to froot :: MutableByteArray# RealWorld fwk :: MutVar# RealWorld Any -- The finalizers } froot represents the object the ForeignPtr points into. When created by one of the malloc variants, this will actually be the allocated byte array. Otherwise, it will be a 0-length array. fwk should be seen as having type fwk :: MutVar# RealWorld (Weak# (MutableByteArray# RealWorld)) but we can't express that directly right now. fwk is keyed on froot, and in the malloc case also points to it, to prevent it from being freed prematurely. It seems that this representation requires a couple extra primitive features from Weak#. I think that's okay: Weak# already has some primitive features designed to support ForeignPtr. 1. An operation to add a Haskell finalizer to a Weak#, similar to the one that adds a C finalizer. 2. A way to deal with mixed finalizers: either make the finalizer-adding primops report distinguishable failure on mixing or arrange to run the C finalizers after any Haskell finalizers (since C finalizers are much more likely to actually invalidate the pointer). 3. A documented guarantee about the order in which the finalizers attached to a particular Weak# run, compatible with the ForeignPtr documentation. -------------- next part -------------- An HTML attachment was scrubbed... URL: From m at tweag.io Wed Sep 5 13:46:09 2018 From: m at tweag.io (Boespflug, Mathieu) Date: Wed, 5 Sep 2018 15:46:09 +0200 Subject: Goals for GHC 8.8 In-Reply-To: <8736v7ms34.fsf@smart-cactus.org> References: <87wosknaub.fsf@smart-cactus.org> <1534857692.2717.56.camel@jeltsch.info> <87h8jnn5iy.fsf@smart-cactus.org> <8736v7ms34.fsf@smart-cactus.org> Message-ID: Hi Ben, yes - as for the implementation of the linear types extension, we're aiming for the submission of a Diff before the 8.8 branch is cut. (If the Committee has given the green light by then, of course.) Best, -- Mathieu Boespflug Founder at http://tweag.io. On Tue, 21 Aug 2018 at 21:34, Ben Gamari wrote: > Mathieu Boespflug writes: > > > The proposal would need to be accepted by the GHC Steering Committee > first > > before that happens. > > > Absolutely; I just wasn't sure whether you were considering pushing for > merge in the event that it was accepted. > > Cheers, > > - Ben > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From arnaud.spiwack at tweag.io Wed Sep 5 14:01:34 2018 From: arnaud.spiwack at tweag.io (Spiwack, Arnaud) Date: Wed, 5 Sep 2018 16:01:34 +0200 Subject: Rational for the special case in mkWWcpr_help Message-ID: Dear all, The function mkWWcpr_help, which creates a wrapper and a worker after strictness analysis, has a special case when there is a single result of unlifted type: Wrapper: case (..call worker..) of x -> C x Worker: case ( ..body.. ) of C x -> x But I don't understand how it is different from using (# #) as would result from the general case: Wrapper: case (..call worker..) of (# x #) -> C x Worker: case ( ..body.. ) of C x -> (# x #) That is, my understanding of the latter is that it would yield the exact same code. I'm obviously missing something, I'd love to know what. Best, Arnaud -------------- next part -------------- An HTML attachment was scrubbed... URL: From ryan.gl.scott at gmail.com Wed Sep 5 14:07:31 2018 From: ryan.gl.scott at gmail.com (Ryan Scott) Date: Wed, 5 Sep 2018 10:07:31 -0400 Subject: Does tyCoVarsOfTypesList guarantee a particular order? Message-ID: tyCoVarsOfTypesList guarantees that it returns its answer in a deterministic order. For the longest time, I must have assumed that this order was left to right. However, it appears that my assumption was wrong! This can be demonstrated with this program: module Main where import Name import TyCoRep import TysPrim import Var main :: IO () main = do putStrLn "(1)" print $ map (getOccString . tyVarName) $ tyCoVarsOfTypesList [TyVarTy alphaTyVar, TyVarTy betaTyVar] putStrLn "(2)" print $ map (getOccString . tyVarName) $ tyCoVarsOfTypesList [TyVarTy alphaTyVar, TyVarTy betaTyVar, TyVarTy alphaTyVar] This gives the following output: (1) ["a","b"] (2) ["b","a"] The first one makes total sense to me. The second, one however, does not. If the free variables of that list were returned in left-to-right order (or even right-to-left order!), then (2) should give the same answer as (1). Instead, it lists "b" _before_ "a", which I find incredibly baffling. To explain why I care so much about this, we're currently trying to improve Haddock's logic for choosing when to put explicit `forall`s in front of types [1]. Our litmus test is this: if the order in which a user wrote the `forall`d variables differs from the order in which the free variables of the body would normally occur, then have Haddock display an explicit forall. I would have assumed that tyCoVarsOfTypesList [2] would be enough to determine the "normal" order of the free variables, but as the example above proves, this sometimes gives unexpected orderings when there are multiple occurrences of the same variable. We are currently having to work around this issue [1] by implementing our own custom versions of tyCoFVsOfType and friends that accumulate variables in reverse order (and then reversing the list at the end!) to get the order we expect. This feels incredibly wasteful to me, so I'd like to know if there's a better way. In particular: 1. Is this behavior of tyCoVarsOfTypesList expected? 2. If not, should we change it? Ryan S. ----- [1] See https://github.com/haskell/haddock/pull/931 [2] Actually, I would use tyCoVarsOfTypesWellScoped, but dependency order doesn't come into play in the example I gave above. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ryan.gl.scott at gmail.com Wed Sep 5 14:14:33 2018 From: ryan.gl.scott at gmail.com (Ryan Scott) Date: Wed, 5 Sep 2018 10:14:33 -0400 Subject: Unpacking coercions Message-ID: These aren't mutually exclusive ideas. While I'm sure there's many ways we could solve this problem, David's idea has the distinct advantage of being dead simple. I'd rather not block his vision on some other large refactor that may never materialize. (And if it _does_ materialize, we could revert any wiring-in of Coercible quite easily.) Ryan S. -------------- next part -------------- An HTML attachment was scrubbed... URL: From simonpj at microsoft.com Wed Sep 5 14:20:34 2018 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Wed, 5 Sep 2018 14:20:34 +0000 Subject: Unpacking coercions In-Reply-To: References: Message-ID: Simple is good. But what is this dead simple idea? Perhaps: https://github.com/ghc-proposals/ghc-proposals/pull/116 But that proposal lists several possible alternatives. Which one did you mean? And all of them are language changes. Making evidence strict would require no language changes to solve the original problem. Maybe this thread belongs with the proposal, unless I’m misunderstanding. Simon From: ghc-devs On Behalf Of Ryan Scott Sent: 05 September 2018 15:15 To: ghc-devs at haskell.org Subject: Re: Unpacking coercions These aren't mutually exclusive ideas. While I'm sure there's many ways we could solve this problem, David's idea has the distinct advantage of being dead simple. I'd rather not block his vision on some other large refactor that may never materialize. (And if it _does_ materialize, we could revert any wiring-in of Coercible quite easily.) Ryan S. -------------- next part -------------- An HTML attachment was scrubbed... URL: From omeragacan at gmail.com Wed Sep 5 14:23:22 2018 From: omeragacan at gmail.com (=?UTF-8?Q?=C3=96mer_Sinan_A=C4=9Facan?=) Date: Wed, 5 Sep 2018 17:23:22 +0300 Subject: Running GHC 7.10.2 on Ubuntu 18.04 ? Message-ID: Hi, I'm trying to use GHC 7.10.2 (the Debian 8 bindist from haskell.org) on Ubuntu 18.04. It's currently failing with linker errors when I compile `main = return ()`: /usr/bin/x86_64-linux-gnu-ld: /home/omer/ghc_bins/ghc-7.10.3-bin/lib/ghc-7.10.3/base_HQfYBxpPvuw8OunzQu6JGM/libHSbase-4.8.2.0-HQfYBxpPvuw8OunzQu6JGM.a(Base__5.o): relocation R_X86_64_32S against `.text' can not be used when making a PIE object; recompile with -fPIC /usr/bin/x86_64-linux-gnu-ld: /home/omer/ghc_bins/ghc-7.10.3-bin/lib/ghc-7.10.3/base_HQfYBxpPvuw8OunzQu6JGM/libHSbase-4.8.2.0-HQfYBxpPvuw8OunzQu6JGM.a(Base__125.o): relocation R_X86_64_32S against `.text' can not be used when making a PIE object; recompile with -fPIC /usr/bin/x86_64-linux-gnu-ld: /home/omer/ghc_bins/ghc-7.10.3-bin/lib/ghc-7.10.3/base_HQfYBxpPvuw8OunzQu6JGM/libHSbase-4.8.2.0-HQfYBxpPvuw8OunzQu6JGM.a(Signal__13.o): relocation R_X86_64_32S against `.text' can not be used when making a PIE object; recompile with -fPIC /usr/bin/x86_64-linux-gnu-ld: /home/omer/ghc_bins/ghc-7.10.3-bin/lib/ghc-7.10.3/base_HQfYBxpPvuw8OunzQu6JGM/libHSbase-4.8.2.0-HQfYBxpPvuw8OunzQu6JGM.a(Sync__199.o): relocation R_X86_64_32S against `.text' can not be used when making a PIE object; recompile with -fPIC /usr/bin/x86_64-linux-gnu-ld: /home/omer/ghc_bins/ghc-7.10.3-bin/lib/ghc-7.10.3/base_HQfYBxpPvuw8OunzQu6JGM/libHSbase-4.8.2.0-HQfYBxpPvuw8OunzQu6JGM.a(Exception__170.o): relocation R_X86_64_32S against symbol `stg_bh_upd_frame_info' can not be used when making a PIE object; recompile with -fPIC I'm getting about 700 of these. Does anyone know a way to make GHC 7.10.2 work on Ubuntu 18.04? Not sure if related but the ld version is ~ $ /usr/bin/x86_64-linux-gnu-ld --version GNU ld (GNU Binutils for Ubuntu) 2.30 Copyright (C) 2018 Free Software Foundation, Inc. This program is free software; you may redistribute it under the terms of the GNU General Public License version 3 or (at your option) a later version. This program has absolutely no warranty. Thanks, Ömer From simonpj at microsoft.com Wed Sep 5 14:25:55 2018 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Wed, 5 Sep 2018 14:25:55 +0000 Subject: Does tyCoVarsOfTypesList guarantee a particular order? In-Reply-To: References: Message-ID: The left to right ordering is guaranteed by RnTypes.extract functions. See Note [Ordering of implicit variables] I don’t think tyCoVarsOfTypesList makes any guarantees. But it probably *could*. If you look at FV.hs, you’ll see that it works right-to-left, putting ‘x’ on the front of the accumulating list the first time it encounters it. So in tyCoVarsOfTypes [a,b] we push b onto the list, then a. Result a:b:[] In in tyCoVarsOfTypes [a,b,a] we push a on the list (the rightmost occurrence), then b, then we ignore the next occurrence of a. Result: b:a:[]. You could add new guarantees I suppose. But they aren’t there right now. Simon From: ghc-devs On Behalf Of Ryan Scott Sent: 05 September 2018 15:08 To: ghc-devs at haskell.org Subject: Does tyCoVarsOfTypesList guarantee a particular order? tyCoVarsOfTypesList guarantees that it returns its answer in a deterministic order. For the longest time, I must have assumed that this order was left to right. However, it appears that my assumption was wrong! This can be demonstrated with this program: module Main where import Name import TyCoRep import TysPrim import Var main :: IO () main = do putStrLn "(1)" print $ map (getOccString . tyVarName) $ tyCoVarsOfTypesList [TyVarTy alphaTyVar, TyVarTy betaTyVar] putStrLn "(2)" print $ map (getOccString . tyVarName) $ tyCoVarsOfTypesList [TyVarTy alphaTyVar, TyVarTy betaTyVar, TyVarTy alphaTyVar] This gives the following output: (1) ["a","b"] (2) ["b","a"] The first one makes total sense to me. The second, one however, does not. If the free variables of that list were returned in left-to-right order (or even right-to-left order!), then (2) should give the same answer as (1). Instead, it lists "b" _before_ "a", which I find incredibly baffling. To explain why I care so much about this, we're currently trying to improve Haddock's logic for choosing when to put explicit `forall`s in front of types [1]. Our litmus test is this: if the order in which a user wrote the `forall`d variables differs from the order in which the free variables of the body would normally occur, then have Haddock display an explicit forall. I would have assumed that tyCoVarsOfTypesList [2] would be enough to determine the "normal" order of the free variables, but as the example above proves, this sometimes gives unexpected orderings when there are multiple occurrences of the same variable. We are currently having to work around this issue [1] by implementing our own custom versions of tyCoFVsOfType and friends that accumulate variables in reverse order (and then reversing the list at the end!) to get the order we expect. This feels incredibly wasteful to me, so I'd like to know if there's a better way. In particular: 1. Is this behavior of tyCoVarsOfTypesList expected? 2. If not, should we change it? Ryan S. ----- [1] See https://github.com/haskell/haddock/pull/931 [2] Actually, I would use tyCoVarsOfTypesWellScoped, but dependency order doesn't come into play in the example I gave above. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ryan.gl.scott at gmail.com Wed Sep 5 14:26:07 2018 From: ryan.gl.scott at gmail.com (Ryan Scott) Date: Wed, 5 Sep 2018 10:26:07 -0400 Subject: Unpacking coercions In-Reply-To: References: Message-ID: > Simple is good. But what is this dead simple idea? I'm referring to David's first e-mail on this thread: https://mail.haskell.org/pipermail/ghc-devs/2018-September/016191.html All that would take is putting Coercion in TysWiredIn, and moving Coercion from Data.Type.Coercion to somewhere in ghc-prim. > Maybe this thread belongs with the proposal, unless I’m misunderstanding. I think the intention is to have that proposal (which proposes a language change) be superseded by this idea (which does not change the language). Ryan S. On Wed, Sep 5, 2018 at 10:20 AM, Simon Peyton Jones wrote: > Simple is good. But what is this dead simple idea? > > > > Perhaps: https://github.com/ghc-proposals/ghc-proposals/pull/116 > > But that proposal lists several possible alternatives. Which one did you > mean? > > > > And all of them are language changes. Making evidence strict would require > no language changes to solve the original problem. > > > > Maybe this thread belongs with the proposal, unless I’m misunderstanding. > > > > Simon > > > > *From:* ghc-devs *On Behalf Of *Ryan Scott > *Sent:* 05 September 2018 15:15 > *To:* ghc-devs at haskell.org > *Subject:* Re: Unpacking coercions > > > > These aren't mutually exclusive ideas. While I'm sure there's many ways we > could solve this problem, David's idea has the distinct advantage of being > dead simple. I'd rather not block his vision on some other large refactor > that may never materialize. (And if it _does_ materialize, we could revert > any wiring-in of Coercible quite easily.) > > > > Ryan S. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From simonpj at microsoft.com Wed Sep 5 14:33:31 2018 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Wed, 5 Sep 2018 14:33:31 +0000 Subject: Rational for the special case in mkWWcpr_help In-Reply-To: References: Message-ID: I think it would yield the same code in the end. Maybe it was just seeking to avoid unnecessary clutter in a particularly common case (eg returning I# x). Seems to have been introduce in commit 731f53de7930c38b5023a871146bd0ec066edf3a Author: simonpj Fri Sep 17 09:15:44 1999 +0000 Simon From: ghc-devs On Behalf Of Spiwack, Arnaud Sent: 05 September 2018 15:02 To: ghc-devs at haskell.org Subject: Rational for the special case in mkWWcpr_help Dear all, The function mkWWcpr_help, which creates a wrapper and a worker after strictness analysis, has a special case when there is a single result of unlifted type: Wrapper: case (..call worker..) of x -> C x Worker: case ( ..body.. ) of C x -> x But I don't understand how it is different from using (# #) as would result from the general case: Wrapper: case (..call worker..) of (# x #) -> C x Worker: case ( ..body.. ) of C x -> (# x #) That is, my understanding of the latter is that it would yield the exact same code. I'm obviously missing something, I'd love to know what. Best, Arnaud -------------- next part -------------- An HTML attachment was scrubbed... URL: From ryan.gl.scott at gmail.com Wed Sep 5 14:34:42 2018 From: ryan.gl.scott at gmail.com (Ryan Scott) Date: Wed, 5 Sep 2018 10:34:42 -0400 Subject: Running GHC 7.10.2 on Ubuntu 18.04 ? Message-ID: This is likely caused by an old GHC bug that interacts poorly with newer version of binutils (I can't remember the exact bug, unfortunately). I personally use hvr's Ubuntu PPA [1] whenever installing GHC on Ubuntu. This PPA backports patches to old versions of GHC to keep them working with newer versions of binutils, and I can confirm that the version of GHC 7.10.2 offered from here works well with Ubuntu 18.04. Ryan S. ----- [1] https://launchpad.net/~hvr/+archive/ubuntu/ghc -------------- next part -------------- An HTML attachment was scrubbed... URL: From vanessa.mchale at iohk.io Wed Sep 5 14:35:07 2018 From: vanessa.mchale at iohk.io (Vanessa McHale) Date: Wed, 5 Sep 2018 09:35:07 -0500 Subject: Running GHC 7.10.2 on Ubuntu 18.04 ? In-Reply-To: References: Message-ID: GHC 7.10.3 works fine for me when I use the hvr ppa https://launchpad.net/~hvr/+archive/ubuntu/ghc On 09/05/2018 09:23 AM, Ömer Sinan Ağacan wrote: > Hi, > > I'm trying to use GHC 7.10.2 (the Debian 8 bindist from haskell.org) on Ubuntu > 18.04. It's currently failing with linker errors when I compile `main = return > ()`: > > /usr/bin/x86_64-linux-gnu-ld: > /home/omer/ghc_bins/ghc-7.10.3-bin/lib/ghc-7.10.3/base_HQfYBxpPvuw8OunzQu6JGM/libHSbase-4.8.2.0-HQfYBxpPvuw8OunzQu6JGM.a(Base__5.o): > relocation R_X86_64_32S against `.text' can not be used when making a > PIE object; recompile with -fPIC > /usr/bin/x86_64-linux-gnu-ld: > /home/omer/ghc_bins/ghc-7.10.3-bin/lib/ghc-7.10.3/base_HQfYBxpPvuw8OunzQu6JGM/libHSbase-4.8.2.0-HQfYBxpPvuw8OunzQu6JGM.a(Base__125.o): > relocation R_X86_64_32S against `.text' can not be used when making a > PIE object; recompile with -fPIC > /usr/bin/x86_64-linux-gnu-ld: > /home/omer/ghc_bins/ghc-7.10.3-bin/lib/ghc-7.10.3/base_HQfYBxpPvuw8OunzQu6JGM/libHSbase-4.8.2.0-HQfYBxpPvuw8OunzQu6JGM.a(Signal__13.o): > relocation R_X86_64_32S against `.text' can not be used when making a > PIE object; recompile with -fPIC > /usr/bin/x86_64-linux-gnu-ld: > /home/omer/ghc_bins/ghc-7.10.3-bin/lib/ghc-7.10.3/base_HQfYBxpPvuw8OunzQu6JGM/libHSbase-4.8.2.0-HQfYBxpPvuw8OunzQu6JGM.a(Sync__199.o): > relocation R_X86_64_32S against `.text' can not be used when making a > PIE object; recompile with -fPIC > /usr/bin/x86_64-linux-gnu-ld: > /home/omer/ghc_bins/ghc-7.10.3-bin/lib/ghc-7.10.3/base_HQfYBxpPvuw8OunzQu6JGM/libHSbase-4.8.2.0-HQfYBxpPvuw8OunzQu6JGM.a(Exception__170.o): > relocation R_X86_64_32S against symbol `stg_bh_upd_frame_info' can not > be used when making a PIE object; recompile with -fPIC > > I'm getting about 700 of these. Does anyone know a way to make GHC 7.10.2 work > on Ubuntu 18.04? Not sure if related but the ld version is > > ~ $ /usr/bin/x86_64-linux-gnu-ld --version > GNU ld (GNU Binutils for Ubuntu) 2.30 > Copyright (C) 2018 Free Software Foundation, Inc. > This program is free software; you may redistribute it under the terms of > the GNU General Public License version 3 or (at your option) a > later version. > This program has absolutely no warranty. > > Thanks, > > Ömer > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs -- *Vanessa McHale* Functional Compiler Engineer | Chicago, IL Website: www.iohk.io Twitter: @vamchale PGP Key ID: 4209B7B5 Input Output Twitter Github LinkedIn This e-mail and any file transmitted with it are confidential and intended solely for the use of the recipient(s) to whom it is addressed. Dissemination, distribution, and/or copying of the transmission by anyone other than the intended recipient(s) is prohibited. If you have received this transmission in error please notify IOHK immediately and delete it from your system. E-mail transmissions cannot be guaranteed to be secure or error free. We do not accept liability for any loss, damage, or error arising from this transmission -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: OpenPGP digital signature URL: From omeragacan at gmail.com Wed Sep 5 14:42:25 2018 From: omeragacan at gmail.com (=?UTF-8?Q?=C3=96mer_Sinan_A=C4=9Facan?=) Date: Wed, 5 Sep 2018 17:42:25 +0300 Subject: Running GHC 7.10.2 on Ubuntu 18.04 ? In-Reply-To: References: Message-ID: Thanks, that worked! Ömer Vanessa McHale , 5 Eyl 2018 Çar, 17:35 tarihinde şunu yazdı: > GHC 7.10.3 works fine for me when I use the hvr ppa > https://launchpad.net/~hvr/+archive/ubuntu/ghc > > On 09/05/2018 09:23 AM, Ömer Sinan Ağacan wrote: > > Hi, > > I'm trying to use GHC 7.10.2 (the Debian 8 bindist from haskell.org) on Ubuntu > 18.04. It's currently failing with linker errors when I compile `main = return > ()`: > > /usr/bin/x86_64-linux-gnu-ld: > /home/omer/ghc_bins/ghc-7.10.3-bin/lib/ghc-7.10.3/base_HQfYBxpPvuw8OunzQu6JGM/libHSbase-4.8.2.0-HQfYBxpPvuw8OunzQu6JGM.a(Base__5.o): > relocation R_X86_64_32S against `.text' can not be used when making a > PIE object; recompile with -fPIC > /usr/bin/x86_64-linux-gnu-ld: > /home/omer/ghc_bins/ghc-7.10.3-bin/lib/ghc-7.10.3/base_HQfYBxpPvuw8OunzQu6JGM/libHSbase-4.8.2.0-HQfYBxpPvuw8OunzQu6JGM.a(Base__125.o): > relocation R_X86_64_32S against `.text' can not be used when making a > PIE object; recompile with -fPIC > /usr/bin/x86_64-linux-gnu-ld: > /home/omer/ghc_bins/ghc-7.10.3-bin/lib/ghc-7.10.3/base_HQfYBxpPvuw8OunzQu6JGM/libHSbase-4.8.2.0-HQfYBxpPvuw8OunzQu6JGM.a(Signal__13.o): > relocation R_X86_64_32S against `.text' can not be used when making a > PIE object; recompile with -fPIC > /usr/bin/x86_64-linux-gnu-ld: > /home/omer/ghc_bins/ghc-7.10.3-bin/lib/ghc-7.10.3/base_HQfYBxpPvuw8OunzQu6JGM/libHSbase-4.8.2.0-HQfYBxpPvuw8OunzQu6JGM.a(Sync__199.o): > relocation R_X86_64_32S against `.text' can not be used when making a > PIE object; recompile with -fPIC > /usr/bin/x86_64-linux-gnu-ld: > /home/omer/ghc_bins/ghc-7.10.3-bin/lib/ghc-7.10.3/base_HQfYBxpPvuw8OunzQu6JGM/libHSbase-4.8.2.0-HQfYBxpPvuw8OunzQu6JGM.a(Exception__170.o): > relocation R_X86_64_32S against symbol `stg_bh_upd_frame_info' can not > be used when making a PIE object; recompile with -fPIC > > I'm getting about 700 of these. Does anyone know a way to make GHC 7.10.2 work > on Ubuntu 18.04? Not sure if related but the ld version is > > ~ $ /usr/bin/x86_64-linux-gnu-ld --version > GNU ld (GNU Binutils for Ubuntu) 2.30 > Copyright (C) 2018 Free Software Foundation, Inc. > This program is free software; you may redistribute it under the terms of > the GNU General Public License version 3 or (at your option) a > later version. > This program has absolutely no warranty. > > Thanks, > > Ömer > _______________________________________________ > ghc-devs mailing listghc-devs at haskell.orghttp://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > > > -- > > > > *Vanessa McHale* > Functional Compiler Engineer | Chicago, IL > > Website: www.iohk.io > Twitter: @vamchale > PGP Key ID: 4209B7B5 > > [image: Input Output] > > [image: Twitter] [image: Github] > [image: LinkedIn] > > > > This e-mail and any file transmitted with it are confidential and intended > solely for the use of the recipient(s) to whom it is addressed. > Dissemination, distribution, and/or copying of the transmission by anyone > other than the intended recipient(s) is prohibited. If you have received > this transmission in error please notify IOHK immediately and delete it > from your system. E-mail transmissions cannot be guaranteed to be secure or > error free. We do not accept liability for any loss, damage, or error > arising from this transmission > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > -------------- next part -------------- An HTML attachment was scrubbed... URL: From simonpj at microsoft.com Wed Sep 5 14:45:43 2018 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Wed, 5 Sep 2018 14:45:43 +0000 Subject: Unpacking coercions In-Reply-To: References: Message-ID: I think the intention is to have that proposal (which proposes a language change) be superseded by this idea (which does not change the language). Oh, I did not know that. I’ll ignore the proposal for now, in that case. All that would take is putting Coercion in TysWiredIn, and moving Coercion from Data.Type.Coercion to somewhere in ghc-prim. I don’t think it’s quite as simple as that. Yes, we can wire it into the compiler; but we still need a module that defines the info table, curried data constructor etc for the type. And we have no way to do that. We could utterly lie and say data Coercion a b where Coercion :: Coercion a a That would generate the right bits in in the .o file, and we’d totally ignore the .hi file. Gruesome but I think it would work. But rather than all this circumlocution, why don’t we just make it possible to write ~# and ~R# directly. Even if we dodge the need right now, it’ll surely come back. If that is lexically tiresome, we could I suppose provide builtin-aliases for them, as if we had type NomEq# = (~#) type ReprEq# = (~R#) Simon From: Ryan Scott Sent: 05 September 2018 15:26 To: Simon Peyton Jones Cc: ghc-devs at haskell.org Subject: Re: Unpacking coercions > Simple is good. But what is this dead simple idea? I'm referring to David's first e-mail on this thread: https://mail.haskell.org/pipermail/ghc-devs/2018-September/016191.html All that would take is putting Coercion in TysWiredIn, and moving Coercion from Data.Type.Coercion to somewhere in ghc-prim. > Maybe this thread belongs with the proposal, unless I’m misunderstanding. I think the intention is to have that proposal (which proposes a language change) be superseded by this idea (which does not change the language). Ryan S. On Wed, Sep 5, 2018 at 10:20 AM, Simon Peyton Jones > wrote: Simple is good. But what is this dead simple idea? Perhaps: https://github.com/ghc-proposals/ghc-proposals/pull/116 But that proposal lists several possible alternatives. Which one did you mean? And all of them are language changes. Making evidence strict would require no language changes to solve the original problem. Maybe this thread belongs with the proposal, unless I’m misunderstanding. Simon From: ghc-devs > On Behalf Of Ryan Scott Sent: 05 September 2018 15:15 To: ghc-devs at haskell.org Subject: Re: Unpacking coercions These aren't mutually exclusive ideas. While I'm sure there's many ways we could solve this problem, David's idea has the distinct advantage of being dead simple. I'd rather not block his vision on some other large refactor that may never materialize. (And if it _does_ materialize, we could revert any wiring-in of Coercible quite easily.) Ryan S. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ryan.gl.scott at gmail.com Wed Sep 5 14:54:15 2018 From: ryan.gl.scott at gmail.com (Ryan Scott) Date: Wed, 5 Sep 2018 10:54:15 -0400 Subject: Unpacking coercions In-Reply-To: References: Message-ID: > We could utterly lie and say > > data Coercion a b where > > Coercion :: Coercion a a > > > > That would generate the right bits in in the .o file, and we’d totally ignore the .hi file. Gruesome but I think it would work. This was precisely what I had in mind. We already perform this trick for several things defined in ghc-prim (e.g., the (~) and (~~) classes), so this would just be another example of that. > But rather than all this circumlocution, why don’t we just make it possible to write ~# and ~R# directly. Even if we dodge the need right now, it’ll surely come back. Hah, the reason David is suggesting his idea in the first place is to avoid having to do this! My understanding is that making it possible to write (~#) and (~R#) directly would involve quite a number of complications, as Richard's wiki entry on the subject [1] demonstrates. That's not to say that I wouldn't like to see that happen some day. But a mere mortal like myself couldn't possibly implement this, whereas David's idea is actually within reach. Ryan S. ----- [1] https://ghc.haskell.org/trac/ghc/wiki/DependentHaskell/Internal#Liftedvs.Unliftedequality On Wed, Sep 5, 2018 at 10:45 AM, Simon Peyton Jones wrote: > I think the intention is to have that proposal (which proposes a language > change) be superseded by this idea (which does not change the language). > > Oh, I did not know that. I’ll ignore the proposal for now, in that case. > > > > All that would take is putting Coercion in TysWiredIn, and moving Coercion > from Data.Type.Coercion to somewhere in ghc-prim. > > > > I don’t think it’s quite as simple as that. Yes, we can wire it into the > compiler; but we still need a module that defines the info table, curried > data constructor etc for the type. And we have no way to do that. > > > > We could utterly lie and say > > data Coercion a b where > > Coercion :: Coercion a a > > > > That would generate the right bits in in the .o file, and we’d totally > ignore the .hi file. Gruesome but I think it would work. > > > > > > But rather than all this circumlocution, why don’t we just make it > possible to write ~# and ~R# directly. Even if we dodge the need right > now, it’ll surely come back. > > > > If that is lexically tiresome, we could I suppose provide builtin-aliases > for them, as if we had > > type NomEq# = (~#) > > type ReprEq# = (~R#) > > > > Simon > > > > *From:* Ryan Scott > *Sent:* 05 September 2018 15:26 > *To:* Simon Peyton Jones > *Cc:* ghc-devs at haskell.org > *Subject:* Re: Unpacking coercions > > > > > Simple is good. But what is this dead simple idea? > > > > I'm referring to David's first e-mail on this thread: > https://mail.haskell.org/pipermail/ghc-devs/2018-September/016191.html > > > > All that would take is putting Coercion in TysWiredIn, and moving Coercion > from Data.Type.Coercion to somewhere in ghc-prim. > > > > > Maybe this thread belongs with the proposal, unless I’m > misunderstanding. > > > > I think the intention is to have that proposal (which proposes a language > change) be superseded by this idea (which does not change the language). > > > > Ryan S. > > > > > > On Wed, Sep 5, 2018 at 10:20 AM, Simon Peyton Jones > wrote: > > Simple is good. But what is this dead simple idea? > > > > Perhaps: https://github.com/ghc-proposals/ghc-proposals/pull/116 > > > But that proposal lists several possible alternatives. Which one did you > mean? > > > > And all of them are language changes. Making evidence strict would require > no language changes to solve the original problem. > > > > Maybe this thread belongs with the proposal, unless I’m misunderstanding. > > > > Simon > > > > *From:* ghc-devs *On Behalf Of *Ryan Scott > *Sent:* 05 September 2018 15:15 > *To:* ghc-devs at haskell.org > *Subject:* Re: Unpacking coercions > > > > These aren't mutually exclusive ideas. While I'm sure there's many ways we > could solve this problem, David's idea has the distinct advantage of being > dead simple. I'd rather not block his vision on some other large refactor > that may never materialize. (And if it _does_ materialize, we could revert > any wiring-in of Coercible quite easily.) > > > > Ryan S. > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rae at cs.brynmawr.edu Wed Sep 5 15:25:30 2018 From: rae at cs.brynmawr.edu (Richard Eisenberg) Date: Wed, 5 Sep 2018 11:25:30 -0400 Subject: Unpacking coercions In-Reply-To: References: Message-ID: <7C1F27AE-24F1-4C06-A0DB-C3A5868AC6BF@cs.brynmawr.edu> I don't think that wiki reference is really about this problem. Instead, I think that we'd need Constraint# to be able to offer users ~# and ~R#. The problem, then, is that there is no answer to this question: Constraint is to Type as Constraint# is to what? Currently, if ~# and ~R# are the only two generators of Constraint#, then Constraint# is like TYPE (TupleRep '[]). But I think wiring that in would be short-sighted. Instead, this road leads to CONSTRAINT :: RuntimeRep -> Type, which is like TYPE. Today's Constraint would be CONSTRAINT LiftedRep. And we would have (~#), (~R#) :: forall k1 k2. k1 -> k2 -> CONSTRAINT (TupleRep '[]). In the Glorious Future, we'll have CONSTRAINT ~R TYPE, but we're not there yet. This all feel like the Right Answer to me, but it's unclear if we should start down this road before we have roles in kinds. Richard > On Sep 5, 2018, at 10:54 AM, Ryan Scott wrote: > > > We could utterly lie and say > > > > data Coercion a b where > > > > Coercion :: Coercion a a > > > > > > > > That would generate the right bits in in the .o file, and we’d totally ignore the .hi file. Gruesome but I think it would work. > > This was precisely what I had in mind. We already perform this trick for several things defined in ghc-prim (e.g., the (~) and (~~) classes), so this would just be another example of that. > > > But rather than all this circumlocution, why don’t we just make it possible to write ~# and ~R# directly. Even if we dodge the need right now, it’ll surely come back. > > Hah, the reason David is suggesting his idea in the first place is to avoid having to do this! My understanding is that making it possible to write (~#) and (~R#) directly would involve quite a number of complications, as Richard's wiki entry on the subject [1] demonstrates. > > That's not to say that I wouldn't like to see that happen some day. But a mere mortal like myself couldn't possibly implement this, whereas David's idea is actually within reach. > > Ryan S. > ----- > [1] https://ghc.haskell.org/trac/ghc/wiki/DependentHaskell/Internal#Liftedvs.Unliftedequality > > On Wed, Sep 5, 2018 at 10:45 AM, Simon Peyton Jones > wrote: > I think the intention is to have that proposal (which proposes a language change) be superseded by this idea (which does not change the language). > > Oh, I did not know that. I’ll ignore the proposal for now, in that case. > > > > All that would take is putting Coercion in TysWiredIn, and moving Coercion from Data.Type.Coercion to somewhere in ghc-prim. > > > > I don’t think it’s quite as simple as that. Yes, we can wire it into the compiler; but we still need a module that defines the info table, curried data constructor etc for the type. And we have no way to do that. > > > > We could utterly lie and say > > data Coercion a b where > > Coercion :: Coercion a a > > > > That would generate the right bits in in the .o file, and we’d totally ignore the .hi file. Gruesome but I think it would work. > > > > > > But rather than all this circumlocution, why don’t we just make it possible to write ~# and ~R# directly. Even if we dodge the need right now, it’ll surely come back. > > > > If that is lexically tiresome, we could I suppose provide builtin-aliases for them, as if we had > > type NomEq# = (~#) > > type ReprEq# = (~R#) > > > > Simon > > > > From: Ryan Scott > > Sent: 05 September 2018 15:26 > To: Simon Peyton Jones > > Cc: ghc-devs at haskell.org > Subject: Re: Unpacking coercions > > > > > Simple is good. But what is this dead simple idea? > > > > I'm referring to David's first e-mail on this thread: https://mail.haskell.org/pipermail/ghc-devs/2018-September/016191.html > > > All that would take is putting Coercion in TysWiredIn, and moving Coercion from Data.Type.Coercion to somewhere in ghc-prim. > > > > > Maybe this thread belongs with the proposal, unless I’m misunderstanding. > > > > I think the intention is to have that proposal (which proposes a language change) be superseded by this idea (which does not change the language). > > > > Ryan S. > > > > > > On Wed, Sep 5, 2018 at 10:20 AM, Simon Peyton Jones > wrote: > > Simple is good. But what is this dead simple idea? > > > > Perhaps: https://github.com/ghc-proposals/ghc-proposals/pull/116 > But that proposal lists several possible alternatives. Which one did you mean? > > > > And all of them are language changes. Making evidence strict would require no language changes to solve the original problem. > > > > Maybe this thread belongs with the proposal, unless I’m misunderstanding. > > > > Simon > > > > From: ghc-devs > On Behalf Of Ryan Scott > Sent: 05 September 2018 15:15 > To: ghc-devs at haskell.org > Subject: Re: Unpacking coercions > > > > These aren't mutually exclusive ideas. While I'm sure there's many ways we could solve this problem, David's idea has the distinct advantage of being dead simple. I'd rather not block his vision on some other large refactor that may never materialize. (And if it _does_ materialize, we could revert any wiring-in of Coercible quite easily.) > > > > Ryan S. > > > > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs -------------- next part -------------- An HTML attachment was scrubbed... URL: From simonpj at microsoft.com Wed Sep 5 21:24:28 2018 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Wed, 5 Sep 2018 21:24:28 +0000 Subject: Unpacking coercions In-Reply-To: <7C1F27AE-24F1-4C06-A0DB-C3A5868AC6BF@cs.brynmawr.edu> References: <7C1F27AE-24F1-4C06-A0DB-C3A5868AC6BF@cs.brynmawr.edu> Message-ID: OK – a good thread. From it I have learned * What the goal is * That exposing (~#) and (~R#) is not just lexically tricky; it’s deeper than that (Richard’s note below). * That there is a viable, implementation plan; not a thing of beauty perhaps, but ok if carefully documented Sounds good to me! My suggestion, if someone is motivated enough to pursue this: * write a wiki page to summarise the above points * plus a ticket to track progress * implement the design Happy to help review. Sorry to have been slow to understand. Simon From: Richard Eisenberg Sent: 05 September 2018 16:26 To: Ryan Scott Cc: Simon Peyton Jones ; ghc-devs at haskell.org Subject: Re: Unpacking coercions I don't think that wiki reference is really about this problem. Instead, I think that we'd need Constraint# to be able to offer users ~# and ~R#. The problem, then, is that there is no answer to this question: Constraint is to Type as Constraint# is to what? Currently, if ~# and ~R# are the only two generators of Constraint#, then Constraint# is like TYPE (TupleRep '[]). But I think wiring that in would be short-sighted. Instead, this road leads to CONSTRAINT :: RuntimeRep -> Type, which is like TYPE. Today's Constraint would be CONSTRAINT LiftedRep. And we would have (~#), (~R#) :: forall k1 k2. k1 -> k2 -> CONSTRAINT (TupleRep '[]). In the Glorious Future, we'll have CONSTRAINT ~R TYPE, but we're not there yet. This all feel like the Right Answer to me, but it's unclear if we should start down this road before we have roles in kinds. Richard On Sep 5, 2018, at 10:54 AM, Ryan Scott > wrote: > We could utterly lie and say > > data Coercion a b where > > Coercion :: Coercion a a > > > > That would generate the right bits in in the .o file, and we’d totally ignore the .hi file. Gruesome but I think it would work. This was precisely what I had in mind. We already perform this trick for several things defined in ghc-prim (e.g., the (~) and (~~) classes), so this would just be another example of that. > But rather than all this circumlocution, why don’t we just make it possible to write ~# and ~R# directly. Even if we dodge the need right now, it’ll surely come back. Hah, the reason David is suggesting his idea in the first place is to avoid having to do this! My understanding is that making it possible to write (~#) and (~R#) directly would involve quite a number of complications, as Richard's wiki entry on the subject [1] demonstrates. That's not to say that I wouldn't like to see that happen some day. But a mere mortal like myself couldn't possibly implement this, whereas David's idea is actually within reach. Ryan S. ----- [1] https://ghc.haskell.org/trac/ghc/wiki/DependentHaskell/Internal#Liftedvs.Unliftedequality On Wed, Sep 5, 2018 at 10:45 AM, Simon Peyton Jones > wrote: I think the intention is to have that proposal (which proposes a language change) be superseded by this idea (which does not change the language). Oh, I did not know that. I’ll ignore the proposal for now, in that case. All that would take is putting Coercion in TysWiredIn, and moving Coercion from Data.Type.Coercion to somewhere in ghc-prim. I don’t think it’s quite as simple as that. Yes, we can wire it into the compiler; but we still need a module that defines the info table, curried data constructor etc for the type. And we have no way to do that. We could utterly lie and say data Coercion a b where Coercion :: Coercion a a That would generate the right bits in in the .o file, and we’d totally ignore the .hi file. Gruesome but I think it would work. But rather than all this circumlocution, why don’t we just make it possible to write ~# and ~R# directly. Even if we dodge the need right now, it’ll surely come back. If that is lexically tiresome, we could I suppose provide builtin-aliases for them, as if we had type NomEq# = (~#) type ReprEq# = (~R#) Simon From: Ryan Scott > Sent: 05 September 2018 15:26 To: Simon Peyton Jones > Cc: ghc-devs at haskell.org Subject: Re: Unpacking coercions > Simple is good. But what is this dead simple idea? I'm referring to David's first e-mail on this thread: https://mail.haskell.org/pipermail/ghc-devs/2018-September/016191.html All that would take is putting Coercion in TysWiredIn, and moving Coercion from Data.Type.Coercion to somewhere in ghc-prim. > Maybe this thread belongs with the proposal, unless I’m misunderstanding. I think the intention is to have that proposal (which proposes a language change) be superseded by this idea (which does not change the language). Ryan S. On Wed, Sep 5, 2018 at 10:20 AM, Simon Peyton Jones > wrote: Simple is good. But what is this dead simple idea? Perhaps: https://github.com/ghc-proposals/ghc-proposals/pull/116 But that proposal lists several possible alternatives. Which one did you mean? And all of them are language changes. Making evidence strict would require no language changes to solve the original problem. Maybe this thread belongs with the proposal, unless I’m misunderstanding. Simon From: ghc-devs > On Behalf Of Ryan Scott Sent: 05 September 2018 15:15 To: ghc-devs at haskell.org Subject: Re: Unpacking coercions These aren't mutually exclusive ideas. While I'm sure there's many ways we could solve this problem, David's idea has the distinct advantage of being dead simple. I'd rather not block his vision on some other large refactor that may never materialize. (And if it _does_ materialize, we could revert any wiring-in of Coercible quite easily.) Ryan S. _______________________________________________ ghc-devs mailing list ghc-devs at haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs -------------- next part -------------- An HTML attachment was scrubbed... URL: From marlowsd at gmail.com Thu Sep 6 07:15:15 2018 From: marlowsd at gmail.com (Simon Marlow) Date: Thu, 6 Sep 2018 08:15:15 +0100 Subject: ForeignPtr representation In-Reply-To: References: Message-ID: Wouldn't this mean that unpacking a ForeignPtr is one word longer than it is now? That would have a big impact on ByteString. What do you think is redundant in the current representation? Cheers Simon On Wed, 5 Sep 2018 at 00:23, David Feuer wrote: > I'm trying, and failing, to understand why ForeignPtr is defined the way > it is. It all seems rather complicated and redundant. I was thinking we > might want to switch to something simpler and more explicit, like this: > > data ForeignPtr a = ForeignPtr { > fptr :: !(Ptr a) -- What we point to > froot :: MutableByteArray# RealWorld > fwk :: MutVar# RealWorld Any -- The finalizers > } > > froot represents the object the ForeignPtr points into. When created by > one of the malloc variants, this will actually be the allocated byte array. > Otherwise, it will be a 0-length array. > > fwk should be seen as having type > > fwk :: MutVar# RealWorld (Weak# (MutableByteArray# RealWorld)) > > but we can't express that directly right now. fwk is keyed on froot, and > in the malloc case also points to it, to prevent it from being freed > prematurely. > > It seems that this representation requires a couple extra primitive > features from Weak#. I think that's okay: Weak# already has some primitive > features designed to support ForeignPtr. > > 1. An operation to add a Haskell finalizer to a Weak#, similar to the one > that adds a C finalizer. > > 2. A way to deal with mixed finalizers: either make the finalizer-adding > primops report distinguishable failure on mixing or arrange to run the C > finalizers after any Haskell finalizers (since C finalizers are much more > likely to actually invalidate the pointer). > > 3. A documented guarantee about the order in which the finalizers attached > to a particular Weak# run, compatible with the ForeignPtr documentation. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.feuer at gmail.com Thu Sep 6 08:41:04 2018 From: david.feuer at gmail.com (David Feuer) Date: Thu, 6 Sep 2018 04:41:04 -0400 Subject: ForeignPtr representation In-Reply-To: References: Message-ID: I realized that the current representation is kind of balanced on a knife edge, efficiency-wise. There's probably no way to make one thing faster without slowing down another: there are just too many things a ForeignPtr could be trying to represent. On Thu, Sep 6, 2018, 3:15 AM Simon Marlow wrote: > Wouldn't this mean that unpacking a ForeignPtr is one word longer than it > is now? That would have a big impact on ByteString. > > What do you think is redundant in the current representation? > > Cheers > Simon > > On Wed, 5 Sep 2018 at 00:23, David Feuer wrote: > >> I'm trying, and failing, to understand why ForeignPtr is defined the way >> it is. It all seems rather complicated and redundant. I was thinking we >> might want to switch to something simpler and more explicit, like this: >> >> data ForeignPtr a = ForeignPtr { >> fptr :: !(Ptr a) -- What we point to >> froot :: MutableByteArray# RealWorld >> fwk :: MutVar# RealWorld Any -- The finalizers >> } >> >> froot represents the object the ForeignPtr points into. When created by >> one of the malloc variants, this will actually be the allocated byte array. >> Otherwise, it will be a 0-length array. >> >> fwk should be seen as having type >> >> fwk :: MutVar# RealWorld (Weak# (MutableByteArray# RealWorld)) >> >> but we can't express that directly right now. fwk is keyed on froot, and >> in the malloc case also points to it, to prevent it from being freed >> prematurely. >> >> It seems that this representation requires a couple extra primitive >> features from Weak#. I think that's okay: Weak# already has some primitive >> features designed to support ForeignPtr. >> >> 1. An operation to add a Haskell finalizer to a Weak#, similar to the one >> that adds a C finalizer. >> >> 2. A way to deal with mixed finalizers: either make the finalizer-adding >> primops report distinguishable failure on mixing or arrange to run the C >> finalizers after any Haskell finalizers (since C finalizers are much more >> likely to actually invalidate the pointer). >> >> 3. A documented guarantee about the order in which the finalizers >> attached to a particular Weak# run, compatible with the ForeignPtr >> documentation. >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From juhpetersen at gmail.com Tue Sep 11 09:41:43 2018 From: juhpetersen at gmail.com (Jens Petersen) Date: Tue, 11 Sep 2018 18:41:43 +0900 Subject: [ANNOUNCE] GHC 8.6.1-beta1 available In-Reply-To: <87y3ddprbw.fsf@smart-cactus.org> References: <87y3ddprbw.fsf@smart-cactus.org> Message-ID: On Sat, 11 Aug 2018 at 11:31, Ben Gamari wrote: > The GHC development team is very pleased to announce the first beta > leading up to GHC 8.6.1 release. Thank you! I have built it for Fedora and RHEL 7 in my Copr repo last week: https://copr.fedorainfracloud.org/coprs/petersen/ghc-8.6.1/ I was away last month, and I am sending this belatedly. From davide at well-typed.com Thu Sep 13 08:24:54 2018 From: davide at well-typed.com (David Eichmann) Date: Thu, 13 Sep 2018 09:24:54 +0100 Subject: Feedback request: GHC performance test-suite Message-ID: <75171465-522b-68d4-dfdf-cbadb6a2235b@well-typed.com> Hello all, I've recently resumed some work started by Jared Weakly on the GHC test suite. This specifically regards performance tests. The work aims to, among some other things, reduce manual work and to log performance test results from our CI server. The proposed change is described in more detail on this wiki page: https://ghc.haskell.org/trac/ghc/wiki/Performance/Tests. I'd appreciate any feedback or questions on this. Thank you and have a great day, David Eichmann -- David Eichmann, Haskell Consultant Well-Typed LLP, http://www.well-typed.com Registered in England & Wales, OC335890 118 Wymering Mansions, Wymering Road, London W9 2NF, England From omeragacan at gmail.com Thu Sep 13 12:25:06 2018 From: omeragacan at gmail.com (=?UTF-8?Q?=C3=96mer_Sinan_A=C4=9Facan?=) Date: Thu, 13 Sep 2018 15:25:06 +0300 Subject: Feedback request: GHC performance test-suite In-Reply-To: <75171465-522b-68d4-dfdf-cbadb6a2235b@well-typed.com> References: <75171465-522b-68d4-dfdf-cbadb6a2235b@well-typed.com> Message-ID: Thanks for doing this. I think it's great that someone's working on the test suite. About storing in git notes: what is the format here? If I want to see numbers for a given commit does `git notes show ` show me all the numbers at that commit or only the differences from previous commit? Do we have an example note to look at to get an idea of what the format is? I think it'd be better if we could make a more concrete plan about the "drifting" problem mentioned in the future work before merging this. I don't know what are the plans here (how much time will be spent on this work) but that future work may never happen, so perhaps for the time being we want to keep the reference values (not sure where to keep them though) to avoid making some programs run 20x slower in a few years. I think it'd also be better if we could highlight this change more in the proposal as I think it's an important one. Ömer David Eichmann , 13 Eyl 2018 Per, 11:25 tarihinde şunu yazdı: > > Hello all, > > I've recently resumed some work started by Jared Weakly on the GHC test > suite. This specifically regards performance tests. The work aims to, > among some other things, reduce manual work and to log performance test > results from our CI server. The proposed change is described in more > detail on this wiki page: > https://ghc.haskell.org/trac/ghc/wiki/Performance/Tests. I'd appreciate > any feedback or questions on this. > > Thank you and have a great day, > David Eichmann > > -- > David Eichmann, Haskell Consultant > Well-Typed LLP, http://www.well-typed.com > > Registered in England & Wales, OC335890 > 118 Wymering Mansions, Wymering Road, London W9 2NF, England > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs From davide at well-typed.com Thu Sep 13 15:21:40 2018 From: davide at well-typed.com (David Eichmann) Date: Thu, 13 Sep 2018 16:21:40 +0100 Subject: Feedback request: GHC performance test-suite In-Reply-To: References: <75171465-522b-68d4-dfdf-cbadb6a2235b@well-typed.com> Message-ID: <78d62912-ac24-22c0-015b-7f4debb6ee3e@well-typed.com> Thanks for the feedback, Ömer. I've added a Git Notes Format section. I've also moved the drift issue into the "Remaining Work" section and gave it its own subsection. I think a solution to this is not obvious, but I agree that we could benefit from a plan here. - David On 13/09/18 13:25, Ömer Sinan Ağacan wrote: > Thanks for doing this. I think it's great that someone's working on the test > suite. > > About storing in git notes: what is the format here? If I want to see numbers > for a given commit does `git notes show ` show me all the numbers at > that commit or only the differences from previous commit? Do we have an example > note to look at to get an idea of what the format is? > > I think it'd be better if we could make a more concrete plan about the > "drifting" problem mentioned in the future work before merging this. I don't > know what are the plans here (how much time will be spent on this work) but that > future work may never happen, so perhaps for the time being we want to keep the > reference values (not sure where to keep them though) to avoid making some > programs run 20x slower in a few years. I think it'd also be better if we could > highlight this change more in the proposal as I think it's an important one. > > Ömer > > David Eichmann , 13 Eyl 2018 Per, 11:25 > tarihinde şunu yazdı: >> Hello all, >> >> I've recently resumed some work started by Jared Weakly on the GHC test >> suite. This specifically regards performance tests. The work aims to, >> among some other things, reduce manual work and to log performance test >> results from our CI server. The proposed change is described in more >> detail on this wiki page: >> https://ghc.haskell.org/trac/ghc/wiki/Performance/Tests. I'd appreciate >> any feedback or questions on this. >> >> Thank you and have a great day, >> David Eichmann >> >> -- >> David Eichmann, Haskell Consultant >> Well-Typed LLP, http://www.well-typed.com >> >> Registered in England & Wales, OC335890 >> 118 Wymering Mansions, Wymering Road, London W9 2NF, England >> >> _______________________________________________ >> ghc-devs mailing list >> ghc-devs at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs -- David Eichmann, Haskell Consultant Well-Typed LLP, http://www.well-typed.com Registered in England & Wales, OC335890 118 Wymering Mansions, Wymering Road, London W9 2NF, England -------------- next part -------------- An HTML attachment was scrubbed... URL: From simonpj at microsoft.com Fri Sep 14 08:01:25 2018 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Fri, 14 Sep 2018 08:01:25 +0000 Subject: [commit: ghc] master: Fix build (9912cdf) In-Reply-To: <20180913210345.274BB3A8E4@ghc.haskell.org> References: <20180913210345.274BB3A8E4@ghc.haskell.org> Message-ID: Sorry about this, my fault. I had -Wwarn in my build.mk. I'll remove it! Thanks for fixing Krzysztof Simon | -----Original Message----- | From: ghc-commits On Behalf Of | git at git.haskell.org | Sent: 13 September 2018 22:04 | To: ghc-commits at haskell.org | Subject: [commit: ghc] master: Fix build (9912cdf) | | Repository : ssh://git at git.haskell.org/ghc | | On branch : master | Link : | https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fghc.haske | ll.org%2Ftrac%2Fghc%2Fchangeset%2F9912cdf6dbb24a9d0188edc722ed6d9d8a3e0a1 | b%2Fghc&data=02%7C01%7Csimonpj%40microsoft.com%7C9952204b82734765e23d | 08d619bc6940%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636724694337978 | 889&sdata=867WGIQemLsbDnnOOy2jbFTidWY1opz26386sZLDSas%3D&reserved | =0 | | >--------------------------------------------------------------- | | commit 9912cdf6dbb24a9d0188edc722ed6d9d8a3e0a1b | Author: Krzysztof Gogolewski | Date: Thu Sep 13 22:52:05 2018 +0200 | | Fix build | | | >--------------------------------------------------------------- | | 9912cdf6dbb24a9d0188edc722ed6d9d8a3e0a1b | compiler/typecheck/TcValidity.hs | 1 - | 1 file changed, 1 deletion(-) | | diff --git a/compiler/typecheck/TcValidity.hs | b/compiler/typecheck/TcValidity.hs | index 351d0e1..df54dc2 100644 | --- a/compiler/typecheck/TcValidity.hs | +++ b/compiler/typecheck/TcValidity.hs | @@ -57,7 +57,6 @@ import Util | import ListSetOps | import SrcLoc | import Outputable | -import Module | import Bag ( emptyBag ) | import Unique ( mkAlphaTyVarUnique ) | import qualified GHC.LanguageExtensions as LangExt | | _______________________________________________ | ghc-commits mailing list | ghc-commits at haskell.org | https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmail.hask | ell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc- | commits&data=02%7C01%7Csimonpj%40microsoft.com%7C9952204b82734765e23d | 08d619bc6940%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636724694337978 | 889&sdata=57N0FGleYkiz03HRAKYxf5VVU1lqpJIreaAqcRdIvSs%3D&reserved | =0 From simonpj at microsoft.com Fri Sep 14 15:57:06 2018 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Fri, 14 Sep 2018 15:57:06 +0000 Subject: GHC state of play at HIW, in 10 days time Message-ID: GHC devs I'm going to give the traditional "state of play in GHC" at the Haskell Implementors Meeting. If you have an opinion, can you say what you'd like to see in it? My current list of topics is below. Please say what else should be there, and who else should be credited. Most of the work is done by people other than me!! Simon * A Backpack segment (given by Edward) * A DevOps segment (given by Ben) * TypeInType * Zillions of fixes * Substantial internal changes: e.g. * making flattening homogeneous; * making equality homogeneous, coercion quantification (thanks Ningning) * what else? * Small but significant language proposals: * Visible dependent quantification * Top-level kind signatures * Visible kind application * what else? * New and ongoing developments in GHC * Better exhaustiveness checking (thank you Ryan) * Quantified constraints * Linear types * Trees That Grow * Deriving via * Performance, performance, performance * Hadrian... soon, soon, soon! -------------- next part -------------- An HTML attachment was scrubbed... URL: From lonetiger at gmail.com Sat Sep 15 14:32:33 2018 From: lonetiger at gmail.com (Phyx) Date: Sat, 15 Sep 2018 15:32:33 +0100 Subject: constant pooling in GHC Message-ID: Hi All, I'm hoping someone here can save me some time. I'm working on something that relies on constants in the same translation unit being pooled before assembly. I've noticed GHC does some const pooling at -O1 , but this doesn't seem to be very consistent, which leads me to believe this is a byproduct of another optimization rather than an explicit thing. I couldn't find anything obvious in the sources, so does GHC intentionally do constant pooling already? Or do I need a new pass to guarantee it. Thanks, Tamar -------------- next part -------------- An HTML attachment was scrubbed... URL: From simonpj at microsoft.com Mon Sep 17 11:46:46 2018 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Mon, 17 Sep 2018 11:46:46 +0000 Subject: Redundant import warnings Message-ID: Edward Can you perhaps bring the core libraries committee to consensus on this (I think minor) issue, and we can then get on with implementing it? Many thanks -- hope to se you at ICFP. Simon | -----Original Message----- | From: haskell-core-libraries at googlegroups.com On Behalf Of GHC | Sent: 17 September 2018 01:49 | Subject: [core libraries] Re: [GHC] #13064: Incorrect redudant imports | warning | | #13064: Incorrect redudant imports warning | -------------------------------------+---------------------------------- | --- | Reporter: phadej | Owner: (none) | Type: bug | Status: new | Priority: low | Milestone: 8.8.1 | Component: Compiler | Version: 8.0.1 | Resolution: | Keywords: | Operating System: Unknown/Multiple | Architecture: | Type of failure: Incorrect | Unknown/Multiple | error/warning at compile-time | Test Case: | Blocked By: | Blocking: | Related Tickets: #15393 | Differential Rev(s): | Wiki Page: | | -------------------------------------+---------------------------------- | --- | | Comment (by RyanGlScott): | | To follow up on my proposed experiment (in comment:29), I built about | 143 | commonly used Hackage libraries using the `wip/T13064` GHC branch. Of | those 143, I noticed new warnings being emitted in 31 of them (~22%): | | {{{ | - adjunctions-4.4 | - aeson-1.4.0.0 | - ansi-wl-pprint-0.6.8.2 | - asn1-encoding-0.9.5 | - async-2.2.1 | - attoparsec-0.13.2.2 | - blaze-builder-0.4.1.0 | - cassava-0.5.1.0 | - conduit-1.3.0.3 | - cookie-0.4.4 | - foundation-0.0.21 | - Glob-0.9.2 | - haskell-src-exts-1.20.2 | - hspec-core-2.5.6 | - lens-4.17 | - math-functions-0.3.0.2 | - memory-0.14.16 | - microstache-1.0.1.1 | - mono-traversable-1.0.9.0 | - network-2.8.0.0 | - primitive-0.6.4.0 | - resourcet-1.2.1 | - scientific-0.3.6.2 | - tasty-1.1.0.3 | - th-orphans-0.13.6 | - unordered-containers-0.2.9.0 | - uuid-types-1.0.3 | - x509-1.7.4 | - x509-store-1.6.6 | - x509-system-1.6.6 | - yaml-0.10.1.1 | }}} | | I still advocate adopting this change, but it is worth noting that a | non- | trivial number of existing libraries will need to be updated in order | to | accommodate the new warnings. | | -- | Ticket URL: | | GHC | | The Glasgow Haskell Compiler | | -- | You received this message because you are subscribed to the Google | Groups "haskell-core-libraries" group. | To unsubscribe from this group and stop receiving emails from it, send | an email to haskell-core-libraries+unsubscribe at googlegroups.com. | For more options, visit | https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgroups. | google.com%2Fd%2Foptout&data=02%7C01%7Csimonpj%40microsoft.com%7C24e | 789bc20ae453ead6408d61c374eb2%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0 | %7C636727421200703644&sdata=mvmddMlq2QoOaxTDZTcwv8wiMlv8VtKOYyggrrAD | 2gA%3D&reserved=0. From chessai1996 at gmail.com Tue Sep 18 15:07:24 2018 From: chessai1996 at gmail.com (Daniel Cartwright) Date: Tue, 18 Sep 2018 11:07:24 -0400 Subject: touch# primitive Message-ID: in GHC.Prim, there is a primitive 'touch#'. It seems that it is used to keep pointers alive, and takes something of any runtime representation, and a State# RealWorld, but there's really no documentation on it, so my idea of what it does is just a guess. Can anyone explain what exactly it does? -------------- next part -------------- An HTML attachment was scrubbed... URL: From benl at ouroborus.net Tue Sep 18 20:54:25 2018 From: benl at ouroborus.net (Ben Lippmeier) Date: Wed, 19 Sep 2018 06:54:25 +1000 Subject: touch# primitive In-Reply-To: References: Message-ID: <900F80E4-82A0-4ACA-BB99-7432DAC08441@ouroborus.net> > On 19 Sep 2018, at 1:07 am, Daniel Cartwright wrote: > > in GHC.Prim, there is a primitive 'touch#'. It seems that it is used to keep pointers alive, and takes something of any runtime representation, and a State# RealWorld, but there's really no documentation on it, so my idea of what it does is just a guess. Can anyone explain what exactly it does? It’s used to place a dependency on a computed value, to prevent the GHC simplifier from moving the binding that computes it around. This is sometimes helpful when writing array fusion systems. I mentioned it briefly in http://benl.ouroborus.net/papers/2011-stencil/stencil-haskell2011.pdf Cheers, Ben. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben at smart-cactus.org Wed Sep 19 14:00:02 2018 From: ben at smart-cactus.org (Ben Gamari) Date: Wed, 19 Sep 2018 10:00:02 -0400 Subject: touch# primitive In-Reply-To: References: Message-ID: <87sh2537vl.fsf@smart-cactus.org> Daniel Cartwright writes: > in GHC.Prim, there is a primitive 'touch#'. It seems that it is used to > keep pointers alive, and takes something of any runtime representation, and > a State# RealWorld, but there's really no documentation on it, so my idea > of what it does is just a guess. Can anyone explain what exactly it does? Technically I think touch# is only useful when applied to something with pointer runtime representation. However, you otherwise have nailed it. Note, however, that touch# isn't entirely water-tight since the simplifier can (at least as of GHC 8.2) transform your program in ways that break the liveness guarantee provided by touch#; see #14346 for an example. We have proposed a new primop, with#, to fix this (see #14375). Cheers, - Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 487 bytes Desc: not available URL: From david.feuer at gmail.com Thu Sep 20 08:31:51 2018 From: david.feuer at gmail.com (David Feuer) Date: Thu, 20 Sep 2018 04:31:51 -0400 Subject: Heap allocation in the RTS Message-ID: I'm working on re-implementing the stable name system. For the new design, it seems much cleaner to allocate stable names in lookupStableName (in rts/StableName.c) rather than in the C-- code that calls it. But I haven't seen RTS code that does heap allocation. Is it possible? If so, how do I do it? -------------- next part -------------- An HTML attachment was scrubbed... URL: From omeragacan at gmail.com Thu Sep 20 09:16:14 2018 From: omeragacan at gmail.com (=?UTF-8?Q?=C3=96mer_Sinan_A=C4=9Facan?=) Date: Thu, 20 Sep 2018 12:16:14 +0300 Subject: Heap allocation in the RTS In-Reply-To: References: Message-ID: Have you seen Storage.c:allocateMightFail ? Ömer David Feuer , 20 Eyl 2018 Per, 11:32 tarihinde şunu yazdı: > > I'm working on re-implementing the stable name system. For the new design, it seems much cleaner to allocate stable names in lookupStableName (in rts/StableName.c) rather than in the C-- code that calls it. But I haven't seen RTS code that does heap allocation. Is it possible? If so, how do I do it? > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs From david.feuer at gmail.com Thu Sep 20 09:26:34 2018 From: david.feuer at gmail.com (David Feuer) Date: Thu, 20 Sep 2018 05:26:34 -0400 Subject: Heap allocation in the RTS In-Reply-To: References: Message-ID: Aha! Okay. How do I get the current capability to pass to that? I guess I should probably perform a heap check before calling lookupSta bleName for simplicity, at least to start. On Thu, Sep 20, 2018, 5:16 AM Ömer Sinan Ağacan wrote: > Have you seen Storage.c:allocateMightFail ? > > Ömer > > > David Feuer , 20 Eyl 2018 Per, 11:32 tarihinde > şunu yazdı: > > > > I'm working on re-implementing the stable name system. For the new > design, it seems much cleaner to allocate stable names in lookupStableName > (in rts/StableName.c) rather than in the C-- code that calls it. But I > haven't seen RTS code that does heap allocation. Is it possible? If so, how > do I do it? > > _______________________________________________ > > ghc-devs mailing list > > ghc-devs at haskell.org > > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > -------------- next part -------------- An HTML attachment was scrubbed... URL: From omeragacan at gmail.com Thu Sep 20 09:30:23 2018 From: omeragacan at gmail.com (=?UTF-8?Q?=C3=96mer_Sinan_A=C4=9Facan?=) Date: Thu, 20 Sep 2018 12:30:23 +0300 Subject: Heap allocation in the RTS In-Reply-To: References: Message-ID: allocateMightFail does the heap check for you and returns NULL. For the current capability you can use MyCapability() in Cmm and pass the value to the RTS function you're implementing. Ömer David Feuer , 20 Eyl 2018 Per, 12:26 tarihinde şunu yazdı: > > Aha! Okay. How do I get the current capability to pass to that? I guess I should probably perform a heap check before calling lookupSta bleName for simplicity, at least to start. > > On Thu, Sep 20, 2018, 5:16 AM Ömer Sinan Ağacan wrote: >> >> Have you seen Storage.c:allocateMightFail ? >> >> Ömer >> >> >> David Feuer , 20 Eyl 2018 Per, 11:32 tarihinde >> şunu yazdı: >> > >> > I'm working on re-implementing the stable name system. For the new design, it seems much cleaner to allocate stable names in lookupStableName (in rts/StableName.c) rather than in the C-- code that calls it. But I haven't seen RTS code that does heap allocation. Is it possible? If so, how do I do it? >> > _______________________________________________ >> > ghc-devs mailing list >> > ghc-devs at haskell.org >> > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs From david.feuer at gmail.com Thu Sep 20 09:33:48 2018 From: david.feuer at gmail.com (David Feuer) Date: Thu, 20 Sep 2018 05:33:48 -0400 Subject: Heap allocation in the RTS In-Reply-To: References: Message-ID: If it returns NULL, then I need to back off what I'm doing and trigger a GC. How do I do the latter? On Thu, Sep 20, 2018, 5:31 AM Ömer Sinan Ağacan wrote: > allocateMightFail does the heap check for you and returns NULL. For the > current > capability you can use MyCapability() in Cmm and pass the value to the RTS > function you're implementing. > > Ömer > > David Feuer , 20 Eyl 2018 Per, 12:26 tarihinde > şunu yazdı: > > > > Aha! Okay. How do I get the current capability to pass to that? I guess > I should probably perform a heap check before calling lookupSta bleName for > simplicity, at least to start. > > > > On Thu, Sep 20, 2018, 5:16 AM Ömer Sinan Ağacan > wrote: > >> > >> Have you seen Storage.c:allocateMightFail ? > >> > >> Ömer > >> > >> > >> David Feuer , 20 Eyl 2018 Per, 11:32 tarihinde > >> şunu yazdı: > >> > > >> > I'm working on re-implementing the stable name system. For the new > design, it seems much cleaner to allocate stable names in lookupStableName > (in rts/StableName.c) rather than in the C-- code that calls it. But I > haven't seen RTS code that does heap allocation. Is it possible? If so, how > do I do it? > >> > _______________________________________________ > >> > ghc-devs mailing list > >> > ghc-devs at haskell.org > >> > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > -------------- next part -------------- An HTML attachment was scrubbed... URL: From omeragacan at gmail.com Thu Sep 20 09:42:21 2018 From: omeragacan at gmail.com (=?UTF-8?Q?=C3=96mer_Sinan_A=C4=9Facan?=) Date: Thu, 20 Sep 2018 12:42:21 +0300 Subject: Heap allocation in the RTS In-Reply-To: References: Message-ID: allocateMightFail allocates new nursery blocks as long as you don't hit the heap limit, so it returns NULL less often than you might think. In particular, it doesn't return NULL when the nursery is full, instead it allocates a new block and adds it to the nursery. I'd do the GC triggering part in Cmm code instead of C code -- I'm not sure if it's possible to do this in C code. There should be some functions in PrimOps.cmm that do heap allocation, maybe look there. I'd look for uses of ALLOC_PRIM. The file HeapStackCheck.cmm may also be helpful (may at least give an idea of how a GC is triggered). Ömer David Feuer , 20 Eyl 2018 Per, 12:34 tarihinde şunu yazdı: > > If it returns NULL, then I need to back off what I'm doing and trigger a GC. How do I do the latter? > > On Thu, Sep 20, 2018, 5:31 AM Ömer Sinan Ağacan wrote: >> >> allocateMightFail does the heap check for you and returns NULL. For the current >> capability you can use MyCapability() in Cmm and pass the value to the RTS >> function you're implementing. >> >> Ömer >> >> David Feuer , 20 Eyl 2018 Per, 12:26 tarihinde >> şunu yazdı: >> > >> > Aha! Okay. How do I get the current capability to pass to that? I guess I should probably perform a heap check before calling lookupSta bleName for simplicity, at least to start. >> > >> > On Thu, Sep 20, 2018, 5:16 AM Ömer Sinan Ağacan wrote: >> >> >> >> Have you seen Storage.c:allocateMightFail ? >> >> >> >> Ömer >> >> >> >> >> >> David Feuer , 20 Eyl 2018 Per, 11:32 tarihinde >> >> şunu yazdı: >> >> > >> >> > I'm working on re-implementing the stable name system. For the new design, it seems much cleaner to allocate stable names in lookupStableName (in rts/StableName.c) rather than in the C-- code that calls it. But I haven't seen RTS code that does heap allocation. Is it possible? If so, how do I do it? >> >> > _______________________________________________ >> >> > ghc-devs mailing list >> >> > ghc-devs at haskell.org >> >> > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs From david.feuer at gmail.com Thu Sep 20 09:50:38 2018 From: david.feuer at gmail.com (David Feuer) Date: Thu, 20 Sep 2018 05:50:38 -0400 Subject: Heap allocation in the RTS In-Reply-To: References: Message-ID: I'm not sure I understand. Are you saying allocateMightFail ignores the usual nursery size? That's not my intention. It would actually be just fine to simply fail if GC would be required--I can then back off, fail out to CMM, trigger a GC there, and retry. Or I could perform an extra heap check before I start; that's a little silly, but I doubt it'll be expensive enough to really matter here. On Thu, Sep 20, 2018, 5:42 AM Ömer Sinan Ağacan wrote: > allocateMightFail allocates new nursery blocks as long as you don't hit the > heap limit, so it returns NULL less often than you might think. In > particular, > it doesn't return NULL when the nursery is full, instead it allocates a new > block and adds it to the nursery. > > I'd do the GC triggering part in Cmm code instead of C code -- I'm not > sure if > it's possible to do this in C code. There should be some functions in > PrimOps.cmm that do heap allocation, maybe look there. I'd look for uses of > ALLOC_PRIM. The file HeapStackCheck.cmm may also be helpful (may at least > give > an idea of how a GC is triggered). > > Ömer > > David Feuer , 20 Eyl 2018 Per, 12:34 tarihinde > şunu yazdı: > > > > If it returns NULL, then I need to back off what I'm doing and trigger a > GC. How do I do the latter? > > > > On Thu, Sep 20, 2018, 5:31 AM Ömer Sinan Ağacan > wrote: > >> > >> allocateMightFail does the heap check for you and returns NULL. For the > current > >> capability you can use MyCapability() in Cmm and pass the value to the > RTS > >> function you're implementing. > >> > >> Ömer > >> > >> David Feuer , 20 Eyl 2018 Per, 12:26 tarihinde > >> şunu yazdı: > >> > > >> > Aha! Okay. How do I get the current capability to pass to that? I > guess I should probably perform a heap check before calling lookupSta > bleName for simplicity, at least to start. > >> > > >> > On Thu, Sep 20, 2018, 5:16 AM Ömer Sinan Ağacan > wrote: > >> >> > >> >> Have you seen Storage.c:allocateMightFail ? > >> >> > >> >> Ömer > >> >> > >> >> > >> >> David Feuer , 20 Eyl 2018 Per, 11:32 > tarihinde > >> >> şunu yazdı: > >> >> > > >> >> > I'm working on re-implementing the stable name system. For the new > design, it seems much cleaner to allocate stable names in lookupStableName > (in rts/StableName.c) rather than in the C-- code that calls it. But I > haven't seen RTS code that does heap allocation. Is it possible? If so, how > do I do it? > >> >> > _______________________________________________ > >> >> > ghc-devs mailing list > >> >> > ghc-devs at haskell.org > >> >> > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > -------------- next part -------------- An HTML attachment was scrubbed... URL: From omeragacan at gmail.com Thu Sep 20 09:57:54 2018 From: omeragacan at gmail.com (=?UTF-8?Q?=C3=96mer_Sinan_A=C4=9Facan?=) Date: Thu, 20 Sep 2018 12:57:54 +0300 Subject: Heap allocation in the RTS In-Reply-To: References: Message-ID: > Are you saying allocateMightFail ignores the usual nursery size? Right, so normally in Cmm you'd do something like `if (Hp + size > HpLim) { trigger GC }`, but allocateMightFail adds more blocks to the nursery instead. Maybe just look at the code, it's quite simple. I don't know how to check Hp in the RTS and trigger a GC. I'd do that part in Cmm as there are lots of Cmm functions that do this already (in PrimOps.cmm and maybe elsewhere). Ömer David Feuer , 20 Eyl 2018 Per, 12:50 tarihinde şunu yazdı: > > I'm not sure I understand. Are you saying allocateMightFail ignores the usual nursery size? That's not my intention. It would actually be just fine to simply fail if GC would be required--I can then back off, fail out to CMM, trigger a GC there, and retry. Or I could perform an extra heap check before I start; that's a little silly, but I doubt it'll be expensive enough to really matter here. > > On Thu, Sep 20, 2018, 5:42 AM Ömer Sinan Ağacan wrote: >> >> allocateMightFail allocates new nursery blocks as long as you don't hit the >> heap limit, so it returns NULL less often than you might think. In particular, >> it doesn't return NULL when the nursery is full, instead it allocates a new >> block and adds it to the nursery. >> >> I'd do the GC triggering part in Cmm code instead of C code -- I'm not sure if >> it's possible to do this in C code. There should be some functions in >> PrimOps.cmm that do heap allocation, maybe look there. I'd look for uses of >> ALLOC_PRIM. The file HeapStackCheck.cmm may also be helpful (may at least give >> an idea of how a GC is triggered). >> >> Ömer >> >> David Feuer , 20 Eyl 2018 Per, 12:34 tarihinde >> şunu yazdı: >> > >> > If it returns NULL, then I need to back off what I'm doing and trigger a GC. How do I do the latter? >> > >> > On Thu, Sep 20, 2018, 5:31 AM Ömer Sinan Ağacan wrote: >> >> >> >> allocateMightFail does the heap check for you and returns NULL. For the current >> >> capability you can use MyCapability() in Cmm and pass the value to the RTS >> >> function you're implementing. >> >> >> >> Ömer >> >> >> >> David Feuer , 20 Eyl 2018 Per, 12:26 tarihinde >> >> şunu yazdı: >> >> > >> >> > Aha! Okay. How do I get the current capability to pass to that? I guess I should probably perform a heap check before calling lookupSta bleName for simplicity, at least to start. >> >> > >> >> > On Thu, Sep 20, 2018, 5:16 AM Ömer Sinan Ağacan wrote: >> >> >> >> >> >> Have you seen Storage.c:allocateMightFail ? >> >> >> >> >> >> Ömer >> >> >> >> >> >> >> >> >> David Feuer , 20 Eyl 2018 Per, 11:32 tarihinde >> >> >> şunu yazdı: >> >> >> > >> >> >> > I'm working on re-implementing the stable name system. For the new design, it seems much cleaner to allocate stable names in lookupStableName (in rts/StableName.c) rather than in the C-- code that calls it. But I haven't seen RTS code that does heap allocation. Is it possible? If so, how do I do it? >> >> >> > _______________________________________________ >> >> >> > ghc-devs mailing list >> >> >> > ghc-devs at haskell.org >> >> >> > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs From simonpj at microsoft.com Thu Sep 20 10:33:47 2018 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Thu, 20 Sep 2018 10:33:47 +0000 Subject: Windows testsuite failures Message-ID: Hi Tamar The list of testsuite failure on Windows has grown quite long - see below. Most seem to concern plugins or linking. Do you know what is going on here? If they can't be fixed, can we mark them as expect_broken on Windows, so that it's easier (when developing) to know when I've introduced a regression. Currently I have to do a manual diff against a rather long list. Thanks! Simon SUMMARY for test run started at Thu Sep 20 00:13:20 2018 GMTST 1:03:11 spent to go through 6530 total tests, which gave rise to 18728 test cases, of which 12206 were skipped 33 had missing libraries 6278 expected passes 173 expected failures 9 caused framework failures 1 caused framework warnings 0 unexpected passes 31 unexpected failures 7 unexpected stat failures Unexpected failures: ghci/linking/dyn/T10955dyn.run T10955dyn [bad exit code] (normal) ghci/linking/dyn/T10955.run T10955 [bad stderr] (ghci) ghci/linking/dyn/T11072gcc.run T11072gcc [bad exit code] (normal) numeric/should_run/FloatFnInverses.run FloatFnInverses [bad stdout] (normal) plugins/T11244.run T11244 [bad stderr] (normal) plugins/plugin-recomp-change.run plugin-recomp-change [bad exit code] (normal) rts/T7040_ghci.run T7040_ghci [bad stdout] (ghci) rts/linker_unload.run linker_unload [bad exit code] (normal) rts/linker_error1.run linker_error1 [bad exit code] (normal) rts/linker_error2.run linker_error2 [bad exit code] (normal) rts/T12771/T12771.run T12771 [bad exit code] (normal) rts/T13082/T13082_good.run T13082_good [bad exit code] (normal) rts/T14611/T14611.run T14611 [bad exit code] (normal) simplCore/should_compile/T7702.run T7702 [exit code non-0] (normal) rts/T10672/T10672_x64.run T10672_x64 [bad exit code] (normal) libraries/Win32/tests/T4452.run T4452 [bad exit code] (normal) plugins/plugins01.run plugins01 [bad exit code] (normal) plugins/plugins07.run plugins07 [bad exit code] (normal) plugins/plugins09.run plugins09 [bad exit code] (normal) plugins/plugins11.run plugins11 [bad exit code] (normal) plugins/plugins12.run plugins12 [bad exit code] (normal) plugins/plugins13.run plugins13 [bad exit code] (normal) plugins/plugins14.run plugins14 [bad exit code] (normal) plugins/plugins15.run plugins15 [bad exit code] (normal) plugins/T10420.run T10420 [bad exit code] (normal) plugins/T10294.run T10294 [bad exit code] (normal) plugins/T10294a.run T10294a [bad exit code] (normal) plugins/T12567a.run T12567a [bad exit code] (normal) plugins/plugin-recomp-pure.run plugin-recomp-pure [bad exit code] (normal) plugins/plugin-recomp-impure.run plugin-recomp-impure [bad exit code] (normal) plugins/plugin-recomp-flags.run plugin-recomp-flags [bad exit code] (normal) Unexpected stat failures: perf/compiler/T9872d.run T9872d [stat not good enough] (normal) perf/compiler/T12425.run T12425 [stat not good enough] (optasm) perf/compiler/T12234.run T12234 [stat not good enough] (optasm) perf/compiler/T12150.run T12150 [stat not good enough] (optasm) perf/should_run/T15226.run T15226 [stat too good] (normal) perf/should_run/T15226a.run T15226a [stat too good] (normal) perf/compiler/MultiLayerModules.run MultiLayerModules [stat not good enough] (normal) Framework failures: ghci/linking/dyn/T10955.run T10955 [ghci] (pre_cmd failed: 2) plugins/T11244.run T11244 [normal] (pre_cmd failed: 2) plugins/plugin-recomp-change.run plugin-recomp-change [normal] (pre_cmd failed: 2) plugins/plugins07.run plugins07 [normal] (pre_cmd failed: 2) plugins/T10420.run T10420 [normal] (pre_cmd failed: 2) plugins/T10294a.run T10294a [normal] (pre_cmd failed: 2) plugins/plugin-recomp-pure.run plugin-recomp-pure [normal] (pre_cmd failed: 2) plugins/plugin-recomp-impure.run plugin-recomp-impure [normal] (pre_cmd failed: 2) plugins/plugin-recomp-flags.run plugin-recomp-flags [normal] (pre_cmd failed: 2) Framework warnings: . T13701 [numfield-no-expected] (No expected value found for bytes allocated in num_field check) -------------- next part -------------- An HTML attachment was scrubbed... URL: From lonetiger at gmail.com Thu Sep 20 11:01:35 2018 From: lonetiger at gmail.com (Phyx) Date: Thu, 20 Sep 2018 12:01:35 +0100 Subject: Windows testsuite failures In-Reply-To: References: Message-ID: Hi Simon, Thanks for the email. I haven't been building head much as I'm working on top of some older commits. From a quick look it seems like the plugin ones are probably testisms, the plugins aren't found so likely a missing path entry somewhere. The linker ones are are weird, I'll need to take a closer look at those, likely culprit is my recent patch, I had been testing in the 32 bit build and didn't notice these. There are a few worrying segfault that shouldn't be there on some random tests so I'll take a closer look at those too. And the stat changes need to be updated. The framework failures I don't see on harbormaster, so think they are again a threading artifact. Need to figure out a more effective way to debug these to find a permanent fix. The ones that harbormaster does see are encoding related. touch is failing on non-ascii names. I will take a look this weekend. Kind regards, Tamar On Thu, Sep 20, 2018, 11:33 Simon Peyton Jones wrote: > Hi Tamar > > The list of testsuite failure on Windows has grown quite long – see > below. Most seem to concern plugins or linking. > > Do you know what is going on here? If they can’t be fixed, can we mark > them as expect_broken on Windows, so that it’s easier (when developing) to > know when I’ve introduced a regression. Currently I have to do a manual > diff against a rather long list. > > Thanks! > > Simon > > > > *SUMMARY for test run started at Thu Sep 20 00:13:20 2018 GMTST* > > *1:03:11 spent to go through* > > * 6530 total tests, which gave rise to* > > * 18728 test cases, of which* > > * 12206 were skipped* > > > > * 33 had missing libraries* > > * 6278 expected passes* > > * 173 expected failures* > > > > * 9 caused framework failures* > > * 1 caused framework warnings* > > * 0 unexpected passes* > > * 31 unexpected failures* > > * 7 unexpected stat failures* > > > > *Unexpected failures:* > > * ghci/linking/dyn/T10955dyn.run T10955dyn [bad exit code] > (normal)* > > * ghci/linking/dyn/T10955.run T10955 [bad stderr] (ghci)* > > * ghci/linking/dyn/T11072gcc.run T11072gcc [bad exit code] > (normal)* > > * numeric/should_run/FloatFnInverses.run FloatFnInverses [bad stdout] > (normal)* > > * plugins/T11244.run T11244 [bad stderr] (normal)* > > * plugins/plugin-recomp-change.run plugin-recomp-change [bad exit > code] (normal)* > > * rts/T7040_ghci.run T7040_ghci [bad stdout] (ghci)* > > * rts/linker_unload.run linker_unload [bad exit code] > (normal)* > > * rts/linker_error1.run linker_error1 [bad exit code] > (normal)* > > * rts/linker_error2.run linker_error2 [bad exit code] > (normal)* > > * rts/T12771/T12771.run T12771 [bad exit code] > (normal)* > > * rts/T13082/T13082_good.run T13082_good [bad exit code] > (normal)* > > * rts/T14611/T14611.run T14611 [bad exit code] > (normal)* > > * simplCore/should_compile/T7702.run T7702 [exit code non-0] > (normal)* > > * rts/T10672/T10672_x64.run T10672_x64 [bad exit code] > (normal)* > > * libraries/Win32/tests/T4452.run T4452 [bad exit code] (normal)* > > * plugins/plugins01.run plugins01 [bad exit code] > (normal)* > > * plugins/plugins07.run plugins07 [bad exit code] > (normal)* > > * plugins/plugins09.run plugins09 [bad exit code] > (normal)* > > * plugins/plugins11.run plugins11 [bad exit code] > (normal)* > > * plugins/plugins12.run plugins12 [bad exit code] > (normal)* > > * plugins/plugins13.run plugins13 [bad exit code] > (normal)* > > * plugins/plugins14.run plugins14 [bad exit code] > (normal)* > > * plugins/plugins15.run plugins15 [bad exit code] > (normal)* > > * plugins/T10420.run T10420 [bad exit code] > (normal)* > > * plugins/T10294.run T10294 [bad exit code] > (normal)* > > * plugins/T10294a.run T10294a [bad exit code] > (normal)* > > * plugins/T12567a.run T12567a [bad exit code] > (normal)* > > * plugins/plugin-recomp-pure.run plugin-recomp-pure [bad exit > code] (normal)* > > * plugins/plugin-recomp-impure.run plugin-recomp-impure [bad exit > code] (normal)* > > * plugins/plugin-recomp-flags.run plugin-recomp-flags [bad exit > code] (normal)* > > > > *Unexpected stat failures:* > > * perf/compiler/T9872d.run T9872d [stat not good enough] > (normal)* > > * perf/compiler/T12425.run T12425 [stat not good enough] > (optasm)* > > * perf/compiler/T12234.run T12234 [stat not good enough] > (optasm)* > > * perf/compiler/T12150.run T12150 [stat not good enough] > (optasm)* > > * perf/should_run/T15226.run T15226 [stat too good] (normal)* > > * perf/should_run/T15226a.run T15226a [stat too good] (normal)* > > * perf/compiler/MultiLayerModules.run MultiLayerModules [stat not good > enough] (normal)* > > > > *Framework failures:* > > * ghci/linking/dyn/T10955.run T10955 [ghci] (pre_cmd failed: 2)* > > * plugins/T11244.run T11244 [normal] (pre_cmd failed: 2)* > > * plugins/plugin-recomp-change.run plugin-recomp-change [normal] > (pre_cmd failed: 2)* > > * plugins/plugins07.run plugins07 [normal] (pre_cmd failed: > 2)* > > * plugins/T10420.run T10420 [normal] (pre_cmd failed: 2)* > > * plugins/T10294a.run T10294a [normal] (pre_cmd failed: 2)* > > * plugins/plugin-recomp-pure.run plugin-recomp-pure [normal] (pre_cmd > failed: 2)* > > * plugins/plugin-recomp-impure.run plugin-recomp-impure [normal] > (pre_cmd failed: 2)* > > * plugins/plugin-recomp-flags.run plugin-recomp-flags [normal] > (pre_cmd failed: 2)* > > > > *Framework warnings:* > > * . T13701 [numfield-no-expected] (No expected value found for bytes > allocated in num_field check)* > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From carter.schonwald at gmail.com Fri Sep 21 00:20:20 2018 From: carter.schonwald at gmail.com (Carter Schonwald) Date: Thu, 20 Sep 2018 20:20:20 -0400 Subject: constant pooling in GHC In-Reply-To: References: Message-ID: what precisely do you mean by constant pooling? i can guess several meanings, but what do you mean specifically? On Sat, Sep 15, 2018 at 10:33 AM Phyx wrote: > Hi All, > > I'm hoping someone here can save me some time. I'm working on something > that relies on constants in the same translation unit being pooled before > assembly. > > I've noticed GHC does some const pooling at -O1 , but this doesn't seem to > be very consistent, which leads me to believe this is a byproduct of > another optimization rather than an explicit thing. > > I couldn't find anything obvious in the sources, so does GHC intentionally > do constant pooling already? Or do I need a new pass to guarantee it. > > Thanks, > Tamar > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > -------------- next part -------------- An HTML attachment was scrubbed... URL: From lonetiger at gmail.com Fri Sep 21 05:23:25 2018 From: lonetiger at gmail.com (Phyx) Date: Fri, 21 Sep 2018 06:23:25 +0100 Subject: constant pooling in GHC In-Reply-To: References: Message-ID: I simply mean that the same constant is not emitted more than once to memory. I.e. If a constant string is used twice, there is only one value in .rodata for it. On Fri, Sep 21, 2018, 01:20 Carter Schonwald wrote: > what precisely do you mean by constant pooling? i can guess several > meanings, but what do you mean specifically? > > On Sat, Sep 15, 2018 at 10:33 AM Phyx wrote: > >> Hi All, >> >> I'm hoping someone here can save me some time. I'm working on something >> that relies on constants in the same translation unit being pooled before >> assembly. >> >> I've noticed GHC does some const pooling at -O1 , but this doesn't seem >> to be very consistent, which leads me to believe this is a byproduct of >> another optimization rather than an explicit thing. >> >> I couldn't find anything obvious in the sources, so does GHC >> intentionally do constant pooling already? Or do I need a new pass to >> guarantee it. >> >> Thanks, >> Tamar >> > _______________________________________________ >> ghc-devs mailing list >> ghc-devs at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From carter.schonwald at gmail.com Fri Sep 21 13:09:30 2018 From: carter.schonwald at gmail.com (Carter Schonwald) Date: Fri, 21 Sep 2018 09:09:30 -0400 Subject: constant pooling in GHC In-Reply-To: References: Message-ID: oh ok, so CSE / sharing for string and numerical literals? On Fri, Sep 21, 2018 at 1:23 AM Phyx wrote: > I simply mean that the same constant is not emitted more than once to > memory. I.e. If a constant string is used twice, there is only one value in > .rodata for it. > > On Fri, Sep 21, 2018, 01:20 Carter Schonwald > wrote: > >> what precisely do you mean by constant pooling? i can guess several >> meanings, but what do you mean specifically? >> >> On Sat, Sep 15, 2018 at 10:33 AM Phyx wrote: >> >>> Hi All, >>> >>> I'm hoping someone here can save me some time. I'm working on something >>> that relies on constants in the same translation unit being pooled before >>> assembly. >>> >>> I've noticed GHC does some const pooling at -O1 , but this doesn't seem >>> to be very consistent, which leads me to believe this is a byproduct of >>> another optimization rather than an explicit thing. >>> >>> I couldn't find anything obvious in the sources, so does GHC >>> intentionally do constant pooling already? Or do I need a new pass to >>> guarantee it. >>> >>> Thanks, >>> Tamar >>> >> _______________________________________________ >>> ghc-devs mailing list >>> ghc-devs at haskell.org >>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >>> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From carter.schonwald at gmail.com Fri Sep 21 20:40:37 2018 From: carter.schonwald at gmail.com (Carter Schonwald) Date: Fri, 21 Sep 2018 16:40:37 -0400 Subject: Looking for student ticket to GHC In-Reply-To: References: Message-ID: you wanna email ghc devs On Fri, Sep 21, 2018 at 11:11 AM Virashree Patel wrote: > Hi, > I am looking to buy a student ticket to GHC 2018. If you are selling still > please contact me. > Thank you! > > Best, > Vira Patel, > Graduate Research Assistant at *Kansas State University * > LinkedIn: *linkedin.com/in/virashreepatel > * > _______________________________________________ > ghc-tickets mailing list > ghc-tickets at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-tickets > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben at well-typed.com Sat Sep 22 00:57:02 2018 From: ben at well-typed.com (Ben Gamari) Date: Fri, 21 Sep 2018 20:57:02 -0400 Subject: [ANNOUNCE] GHC 8.6.1 released Message-ID: <87wore1h9i.fsf@smart-cactus.org> Hello everyone, The GHC team is pleased to announce the availability of GHC 8.6.1, the fourth major release in the GHC 8 series. The source distribution, binary distributions, and documentation for this release are available at https://downloads.haskell.org/~ghc/8.6.1 The 8.6 release fixes over 400 bugs from the 8.4 series and introduces a number of exciting features. These most notably include: * A new deriving mechanism, `deriving via`, providing a convenient way for users to extend Haskell's typeclass deriving mechanism * Quantified constraints, allowing forall quantification in constraint contexts * An early version of the GHCi `:doc` command * The `ghc-heap-view` package, allowing introspection into the structure of GHC's heap * Valid hole fit hints, helping the user to find terms to fill typed holes in their programs * The BlockArguments extension, allowing the `$` operator to be omitted in some unambiguous contexts * An exciting new plugin mechanism, source plugins, allowing plugins to inspect and modify a wide variety of compiler representations. * Improved recompilation checking when plugins are used * Significantly better handling of macOS linker command size limits, avoiding linker errors while linking large projects * The next phase of the MonadFail proposal, enabling -XMonadFailDesugaring by default A full list of the changes in this release can be found in the release notes: https://downloads.haskell.org/~ghc/8.6.1/docs/html/users_guide/8.6.1-notes.html Perhaps of equal importance, GHC 8.6 is the second major release made under GHC's accelerated six-month release schedule and the first set of binary distributions built primarily using our new continuous integration scheme. While the final 8.6 release is around three weeks later than initially scheduled due to late-breaking bug reports, we expect that the 8.8 release schedule shouldn't be affected. Thanks to everyone who has contributed to developing, documenting, and testing this release! As always, let us know if you encounter trouble. How to get it ~~~~~~~~~~~~~ The easy way is to go to the web page, which should be self-explanatory: https://www.haskell.org/ghc/ We supply binary builds in the native package format for many platforms, and the source distribution is available from the same place. Packages will appear as they are built - if the package for your system isn't available yet, please try again later. Background ~~~~~~~~~~ Haskell is a standard lazy functional programming language. GHC is a state-of-the-art programming suite for Haskell. Included is an optimising compiler generating efficient code for a variety of platforms, together with an interactive system for convenient, quick development. The distribution includes space and time profiling facilities, a large collection of libraries, and support for various language extensions, including concurrency, exceptions, and foreign language interfaces. GHC is distributed under a BSD-style open source license. A wide variety of Haskell related resources (tutorials, libraries, specifications, documentation, compilers, interpreters, references, contact information, links to research groups) are available from the Haskell home page (see below). On-line GHC-related resources ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Relevant URLs on the World-Wide Web: GHC home page https://www.haskell.org/ghc/ GHC developers' home page https://ghc.haskell.org/trac/ghc/ Haskell home page https://www.haskell.org/ Supported Platforms ~~~~~~~~~~~~~~~~~~~ The list of platforms we support, and the people responsible for them, is here: https://ghc.haskell.org/trac/ghc/wiki/Contributors Ports to other platforms are possible with varying degrees of difficulty. The Building Guide describes how to go about porting to a new platform: https://ghc.haskell.org/trac/ghc/wiki/Building Developers ~~~~~~~~~~ We welcome new contributors. Instructions on accessing our source code repository, and getting started with hacking on GHC, are available from the GHC's developer's site run by Trac: https://ghc.haskell.org/trac/ghc/ Mailing lists ~~~~~~~~~~~~~ We run mailing lists for GHC users and bug reports; to subscribe, use the web interfaces at https://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-tickets There are several other haskell and ghc-related mailing lists on www.haskell.org; for the full list, see https://mail.haskell.org/cgi-bin/mailman/listinfo Some GHC developers hang out on #haskell on IRC, too: https://www.haskell.org/haskellwiki/IRC_channel Please report bugs using our bug tracking system. Instructions on reporting bugs can be found here: https://www.haskell.org/ghc/reportabug -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 487 bytes Desc: not available URL: From hvriedel at gmail.com Sat Sep 22 08:30:13 2018 From: hvriedel at gmail.com (Herbert Valerio Riedel) Date: Sat, 22 Sep 2018 10:30:13 +0200 Subject: [ANNOUNCE] GHC 8.6.1 released In-Reply-To: <87wore1h9i.fsf@smart-cactus.org> (Ben Gamari's message of "Fri, 21 Sep 2018 20:57:02 -0400") References: <87wore1h9i.fsf@smart-cactus.org> Message-ID: <877ejehr3e.fsf@gmail.com> Hello everyone, Here's an addendum to the announcment as it ommitted an important detail: GHC 8.6.1 is only guaranteed to work properly with tooling which uses lib:Cabal version 2.4.0.1 or later. As such, GHC 8.6.1 works best with ​`cabal-install` 2.4.0.0 or later; please upgrade to `cabal-install` 2.4.0.0 if you haven't already. Note that cabal-install 2.4 supports all GHC versions back till GHC 7.0.4 and we also strongly recommend to use the latest available stable release of `cabal` even with older GHC releases as bugfixes and improvements aren't always backported to older Cabal releases as well as to be able to benefit from recently added CABAL format features[8] (or be able to access package releases on Hackage[9] which rely on those features) which require recent enough versions of Cabal as well. Note that binaries aren't available on cabal's download page[1] yet. If you're on Ubuntu or Debian, you can get a compiled cabal-install 2.4 `.deb` package via Apt from - https://launchpad.net/~hvr/+archive/ubuntu/ghc or - http://downloads.haskell.org/debian/ respectively. Binary versions for macOS and Windows are also expected to become available via [2] and [3] soon (and also at [1]). In the meantime, if you already have GHC 7.10 or later (together with a compatible `cabal` executable) installed, you can easily install cabal 2.4 yourself from Hackage[9] by invoking cabal install cabal-install-2.4.0.0 and making sure that the resulting `cabal` executable is accessible via your $PATH; you can check with `cabal --version` which should emit something along the lines of $ cabal --version cabal-install version 2.4.0.0 compiled using version 2.4.0.1 of the Cabal library Finally, the Haskell Platform[4] release for GHC 8.6.1 should be available soon as well which provides yet another recommended "standard way to get GHC and related tools"[5] in a uniform way across multiple operating systems. See [4] and [5] for more details about the standard Haskell Platform distribution. [1]: https://www.haskell.org/cabal/download.html [2]: https://haskell.futurice.com/ [3]: https://hub.zhox.com/posts/chocolatey-introduction/ [4]: https://www.haskell.org/platform/ [5]: https://mail.haskell.org/pipermail/ghc-devs/2015-July/009379.html [6]: https://launchpad.net/~hvr/+archive/ubuntu/ghc [7]: http://downloads.haskell.org/debian/ [8]: https://cabal.readthedocs.io/en/latest/file-format-changelog.html [9]: http://hackage.haskell.org/ -- Herbert On 2018-09-21 at 20:57:02 -0400, Ben Gamari wrote: > Hello everyone, > > The GHC team is pleased to announce the availability of GHC 8.6.1, the > fourth major release in the GHC 8 series. The source distribution, binary > distributions, and documentation for this release are available at > > https://downloads.haskell.org/~ghc/8.6.1 > > The 8.6 release fixes over 400 bugs from the 8.4 series and introduces a > number of exciting features. These most notably include: > > * A new deriving mechanism, `deriving via`, providing a convenient way > for users to extend Haskell's typeclass deriving mechanism > > * Quantified constraints, allowing forall quantification in constraint contexts > > * An early version of the GHCi `:doc` command > > * The `ghc-heap-view` package, allowing introspection into the > structure of GHC's heap > > * Valid hole fit hints, helping the user to find terms to fill typed > holes in their programs > > * The BlockArguments extension, allowing the `$` operator to be omitted > in some unambiguous contexts > > * An exciting new plugin mechanism, source plugins, allowing plugins to > inspect and modify a wide variety of compiler representations. > > * Improved recompilation checking when plugins are used > > * Significantly better handling of macOS linker command size limits, > avoiding linker errors while linking large projects > > * The next phase of the MonadFail proposal, enabling > -XMonadFailDesugaring by default > > A full list of the changes in this release can be found in the > release notes: > > https://downloads.haskell.org/~ghc/8.6.1/docs/html/users_guide/8.6.1-notes.html > > Perhaps of equal importance, GHC 8.6 is the second major release made > under GHC's accelerated six-month release schedule and the first set of > binary distributions built primarily using our new continuous > integration scheme. While the final 8.6 release is around three weeks > later than initially scheduled due to late-breaking bug reports, we > expect that the 8.8 release schedule shouldn't be affected. > > Thanks to everyone who has contributed to developing, documenting, and > testing this release! > > As always, let us know if you encounter trouble. > > > How to get it > ~~~~~~~~~~~~~ > > The easy way is to go to the web page, which should be self-explanatory: > > https://www.haskell.org/ghc/ > > We supply binary builds in the native package format for many > platforms, and the source distribution is available from the same > place. > > Packages will appear as they are built - if the package for your > system isn't available yet, please try again later. > > > Background > ~~~~~~~~~~ > > Haskell is a standard lazy functional programming language. > > GHC is a state-of-the-art programming suite for Haskell. Included is > an optimising compiler generating efficient code for a variety of > platforms, together with an interactive system for convenient, quick > development. The distribution includes space and time profiling > facilities, a large collection of libraries, and support for various > language extensions, including concurrency, exceptions, and foreign > language interfaces. GHC is distributed under a BSD-style open source license. > > A wide variety of Haskell related resources (tutorials, libraries, > specifications, documentation, compilers, interpreters, references, > contact information, links to research groups) are available from the > Haskell home page (see below). > > > On-line GHC-related resources > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > Relevant URLs on the World-Wide Web: > > GHC home page https://www.haskell.org/ghc/ > GHC developers' home page https://ghc.haskell.org/trac/ghc/ > Haskell home page https://www.haskell.org/ > > > Supported Platforms > ~~~~~~~~~~~~~~~~~~~ > > The list of platforms we support, and the people responsible for them, > is here: > > https://ghc.haskell.org/trac/ghc/wiki/Contributors > > Ports to other platforms are possible with varying degrees of > difficulty. The Building Guide describes how to go about porting to a > new platform: > > https://ghc.haskell.org/trac/ghc/wiki/Building > > > Developers > ~~~~~~~~~~ > > We welcome new contributors. Instructions on accessing our source > code repository, and getting started with hacking on GHC, are > available from the GHC's developer's site run by Trac: > > https://ghc.haskell.org/trac/ghc/ > > > Mailing lists > ~~~~~~~~~~~~~ > > We run mailing lists for GHC users and bug reports; to subscribe, use > the web interfaces at > > https://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-tickets > > There are several other haskell and ghc-related mailing lists on > www.haskell.org; for the full list, see > > https://mail.haskell.org/cgi-bin/mailman/listinfo > > Some GHC developers hang out on #haskell on IRC, too: > > https://www.haskell.org/haskellwiki/IRC_channel > > Please report bugs using our bug tracking system. Instructions on > reporting bugs can be found here: > > https://www.haskell.org/ghc/reportabug From omeragacan at gmail.com Sat Sep 22 10:37:29 2018 From: omeragacan at gmail.com (=?UTF-8?Q?=C3=96mer_Sinan_A=C4=9Facan?=) Date: Sat, 22 Sep 2018 13:37:29 +0300 Subject: [Haskell] [ANNOUNCE] GHC 8.6.1 released In-Reply-To: <87wore1h9i.fsf@smart-cactus.org> References: <87wore1h9i.fsf@smart-cactus.org> Message-ID: Thanks to everyone involved with the release! It's a bit sad that we don't have DWARF bindists this time (we had those for 8.4.2 and 8.4.3). DWARF builds make debugging GHC much easier, and because runtime panics also include stack traces in DWARF builds tickets reported for those bindists tend to be more helpful. Would it be possible to provide DWARF bindists at a later date? Ömer Ben Gamari , 22 Eyl 2018 Cmt, 03:57 tarihinde şunu yazdı: > > Hello everyone, > > The GHC team is pleased to announce the availability of GHC 8.6.1, the > fourth major release in the GHC 8 series. The source distribution, binary > distributions, and documentation for this release are available at > > https://downloads.haskell.org/~ghc/8.6.1 > > The 8.6 release fixes over 400 bugs from the 8.4 series and introduces a > number of exciting features. These most notably include: > > * A new deriving mechanism, `deriving via`, providing a convenient way > for users to extend Haskell's typeclass deriving mechanism > > * Quantified constraints, allowing forall quantification in constraint contexts > > * An early version of the GHCi `:doc` command > > * The `ghc-heap-view` package, allowing introspection into the > structure of GHC's heap > > * Valid hole fit hints, helping the user to find terms to fill typed > holes in their programs > > * The BlockArguments extension, allowing the `$` operator to be omitted > in some unambiguous contexts > > * An exciting new plugin mechanism, source plugins, allowing plugins to > inspect and modify a wide variety of compiler representations. > > * Improved recompilation checking when plugins are used > > * Significantly better handling of macOS linker command size limits, > avoiding linker errors while linking large projects > > * The next phase of the MonadFail proposal, enabling > -XMonadFailDesugaring by default > > A full list of the changes in this release can be found in the > release notes: > > https://downloads.haskell.org/~ghc/8.6.1/docs/html/users_guide/8.6.1-notes.html > > Perhaps of equal importance, GHC 8.6 is the second major release made > under GHC's accelerated six-month release schedule and the first set of > binary distributions built primarily using our new continuous > integration scheme. While the final 8.6 release is around three weeks > later than initially scheduled due to late-breaking bug reports, we > expect that the 8.8 release schedule shouldn't be affected. > > Thanks to everyone who has contributed to developing, documenting, and > testing this release! > > As always, let us know if you encounter trouble. > > > How to get it > ~~~~~~~~~~~~~ > > The easy way is to go to the web page, which should be self-explanatory: > > https://www.haskell.org/ghc/ > > We supply binary builds in the native package format for many > platforms, and the source distribution is available from the same > place. > > Packages will appear as they are built - if the package for your > system isn't available yet, please try again later. > > > Background > ~~~~~~~~~~ > > Haskell is a standard lazy functional programming language. > > GHC is a state-of-the-art programming suite for Haskell. Included is > an optimising compiler generating efficient code for a variety of > platforms, together with an interactive system for convenient, quick > development. The distribution includes space and time profiling > facilities, a large collection of libraries, and support for various > language extensions, including concurrency, exceptions, and foreign > language interfaces. GHC is distributed under a BSD-style open source license. > > A wide variety of Haskell related resources (tutorials, libraries, > specifications, documentation, compilers, interpreters, references, > contact information, links to research groups) are available from the > Haskell home page (see below). > > > On-line GHC-related resources > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > Relevant URLs on the World-Wide Web: > > GHC home page https://www.haskell.org/ghc/ > GHC developers' home page https://ghc.haskell.org/trac/ghc/ > Haskell home page https://www.haskell.org/ > > > Supported Platforms > ~~~~~~~~~~~~~~~~~~~ > > The list of platforms we support, and the people responsible for them, > is here: > > https://ghc.haskell.org/trac/ghc/wiki/Contributors > > Ports to other platforms are possible with varying degrees of > difficulty. The Building Guide describes how to go about porting to a > new platform: > > https://ghc.haskell.org/trac/ghc/wiki/Building > > > Developers > ~~~~~~~~~~ > > We welcome new contributors. Instructions on accessing our source > code repository, and getting started with hacking on GHC, are > available from the GHC's developer's site run by Trac: > > https://ghc.haskell.org/trac/ghc/ > > > Mailing lists > ~~~~~~~~~~~~~ > > We run mailing lists for GHC users and bug reports; to subscribe, use > the web interfaces at > > https://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-tickets > > There are several other haskell and ghc-related mailing lists on > www.haskell.org; for the full list, see > > https://mail.haskell.org/cgi-bin/mailman/listinfo > > Some GHC developers hang out on #haskell on IRC, too: > > https://www.haskell.org/haskellwiki/IRC_channel > > Please report bugs using our bug tracking system. Instructions on > reporting bugs can be found here: > > https://www.haskell.org/ghc/reportabug > _______________________________________________ > Haskell mailing list > Haskell at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell From ben at smart-cactus.org Sat Sep 22 13:18:21 2018 From: ben at smart-cactus.org (Ben Gamari) Date: Sat, 22 Sep 2018 09:18:21 -0400 Subject: [Haskell] [ANNOUNCE] GHC 8.6.1 released In-Reply-To: References: <87wore1h9i.fsf@smart-cactus.org> Message-ID: <87pnx51xif.fsf@smart-cactus.org> Ömer Sinan Ağacan writes: > Thanks to everyone involved with the release! > > It's a bit sad that we don't have DWARF bindists this time (we had those for > 8.4.2 and 8.4.3). DWARF builds make debugging GHC much easier, and because > runtime panics also include stack traces in DWARF builds tickets reported for > those bindists tend to be more helpful. > Yes, I'm working on it. I just didn't want to hold the release for them since I was under the (happily mistaken) impression that I was the only one using them. Cheers, - Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 487 bytes Desc: not available URL: From qdunkan at gmail.com Sat Sep 22 22:09:15 2018 From: qdunkan at gmail.com (Evan Laforge) Date: Sat, 22 Sep 2018 15:09:15 -0700 Subject: bug in aclocal.m4 Message-ID: Tiny bug, so I'll just throw it out here instead of trying to get arc set up again: aclocal.m4 line 2438, at head (commit 7e77f41430ae1cad84d5b0c90328331d38f3eda0) has # typo'd as $. It causes a harmless but alarming error in configure. Also `ld --version` causes an error on OS X since OS X ld doesn't have that flag, but I think it just causes it to correctly detect it as "not gnu ld". From qdunkan at gmail.com Sat Sep 22 22:44:24 2018 From: qdunkan at gmail.com (Evan Laforge) Date: Sat, 22 Sep 2018 15:44:24 -0700 Subject: [ANNOUNCE] GHC 8.6.1 released In-Reply-To: <87wore1h9i.fsf@smart-cactus.org> References: <87wore1h9i.fsf@smart-cactus.org> Message-ID: Has anyone installed the OS X binary distribution? I get: "utils/ghc-cabal/dist-install/build/tmp/ghc-cabal-bindist" copy libraries/ghc-prim dist-install "strip" '' '/usr/local' '/usr/local/lib/ghc-8.6.1' '/usr/local/share/doc/ghc-8.6.1/html/libraries' 'v p dyn' dyld: Library not loaded: /usr/local/opt/gmp/lib/libgmp.10.dylib Referenced from: /usr/local/src/hs/ghc-8.6.1/libraries/base/dist-install/build/libHSbase-4.12.0.0-ghc8.6.1.dylib Reason: image not found otool -L on libHSBase indeed shows a reference to /usr/local/opt/gmp/lib/libgmp.10.dylib, which of course doesn't exist, not being a standard location. otool on 8.4.2's libHSBase has no reference to libgmp at all. Both of them have @rpath/libHSinteger-gmp-1.0.2.0-ghc$version.dylib, but perhaps that's just ghc's binding to libgmp. I don't actually know how ghc links libgmp nowadays. Perhaps the usual OS X build statically links libgmp and some flags got wrong for this one and it wound up dynamic? On Fri, Sep 21, 2018 at 5:57 PM Ben Gamari wrote: > > Hello everyone, > > The GHC team is pleased to announce the availability of GHC 8.6.1, the > fourth major release in the GHC 8 series. The source distribution, binary > distributions, and documentation for this release are available at > > https://downloads.haskell.org/~ghc/8.6.1 > > The 8.6 release fixes over 400 bugs from the 8.4 series and introduces a > number of exciting features. These most notably include: > > * A new deriving mechanism, `deriving via`, providing a convenient way > for users to extend Haskell's typeclass deriving mechanism > > * Quantified constraints, allowing forall quantification in constraint contexts > > * An early version of the GHCi `:doc` command > > * The `ghc-heap-view` package, allowing introspection into the > structure of GHC's heap > > * Valid hole fit hints, helping the user to find terms to fill typed > holes in their programs > > * The BlockArguments extension, allowing the `$` operator to be omitted > in some unambiguous contexts > > * An exciting new plugin mechanism, source plugins, allowing plugins to > inspect and modify a wide variety of compiler representations. > > * Improved recompilation checking when plugins are used > > * Significantly better handling of macOS linker command size limits, > avoiding linker errors while linking large projects > > * The next phase of the MonadFail proposal, enabling > -XMonadFailDesugaring by default > > A full list of the changes in this release can be found in the > release notes: > > https://downloads.haskell.org/~ghc/8.6.1/docs/html/users_guide/8.6.1-notes.html > > Perhaps of equal importance, GHC 8.6 is the second major release made > under GHC's accelerated six-month release schedule and the first set of > binary distributions built primarily using our new continuous > integration scheme. While the final 8.6 release is around three weeks > later than initially scheduled due to late-breaking bug reports, we > expect that the 8.8 release schedule shouldn't be affected. > > Thanks to everyone who has contributed to developing, documenting, and > testing this release! > > As always, let us know if you encounter trouble. > > > How to get it > ~~~~~~~~~~~~~ > > The easy way is to go to the web page, which should be self-explanatory: > > https://www.haskell.org/ghc/ > > We supply binary builds in the native package format for many > platforms, and the source distribution is available from the same > place. > > Packages will appear as they are built - if the package for your > system isn't available yet, please try again later. > > > Background > ~~~~~~~~~~ > > Haskell is a standard lazy functional programming language. > > GHC is a state-of-the-art programming suite for Haskell. Included is > an optimising compiler generating efficient code for a variety of > platforms, together with an interactive system for convenient, quick > development. The distribution includes space and time profiling > facilities, a large collection of libraries, and support for various > language extensions, including concurrency, exceptions, and foreign > language interfaces. GHC is distributed under a BSD-style open source license. > > A wide variety of Haskell related resources (tutorials, libraries, > specifications, documentation, compilers, interpreters, references, > contact information, links to research groups) are available from the > Haskell home page (see below). > > > On-line GHC-related resources > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > Relevant URLs on the World-Wide Web: > > GHC home page https://www.haskell.org/ghc/ > GHC developers' home page https://ghc.haskell.org/trac/ghc/ > Haskell home page https://www.haskell.org/ > > > Supported Platforms > ~~~~~~~~~~~~~~~~~~~ > > The list of platforms we support, and the people responsible for them, > is here: > > https://ghc.haskell.org/trac/ghc/wiki/Contributors > > Ports to other platforms are possible with varying degrees of > difficulty. The Building Guide describes how to go about porting to a > new platform: > > https://ghc.haskell.org/trac/ghc/wiki/Building > > > Developers > ~~~~~~~~~~ > > We welcome new contributors. Instructions on accessing our source > code repository, and getting started with hacking on GHC, are > available from the GHC's developer's site run by Trac: > > https://ghc.haskell.org/trac/ghc/ > > > Mailing lists > ~~~~~~~~~~~~~ > > We run mailing lists for GHC users and bug reports; to subscribe, use > the web interfaces at > > https://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-tickets > > There are several other haskell and ghc-related mailing lists on > www.haskell.org; for the full list, see > > https://mail.haskell.org/cgi-bin/mailman/listinfo > > Some GHC developers hang out on #haskell on IRC, too: > > https://www.haskell.org/haskellwiki/IRC_channel > > Please report bugs using our bug tracking system. Instructions on > reporting bugs can be found here: > > https://www.haskell.org/ghc/reportabug > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users From slyich at gmail.com Sat Sep 22 22:57:37 2018 From: slyich at gmail.com (Sergei Trofimovich) Date: Sat, 22 Sep 2018 23:57:37 +0100 Subject: bug in aclocal.m4 In-Reply-To: References: Message-ID: <20180922235737.7f82b4ad@sf> On Sat, 22 Sep 2018 15:09:15 -0700 Evan Laforge wrote: > Tiny bug, so I'll just throw it out here instead of trying to get arc > set up again: > > aclocal.m4 line 2438, at head (commit > 7e77f41430ae1cad84d5b0c90328331d38f3eda0) has # typo'd as $. It > causes a harmless but alarming error in configure. Sounds reasonable. Proposed as https://phabricator.haskell.org/D5171 -- Sergei -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 981 bytes Desc: Цифровая подпись OpenPGP URL: From george.colpitts at gmail.com Sun Sep 23 01:33:19 2018 From: george.colpitts at gmail.com (George Colpitts) Date: Sat, 22 Sep 2018 22:33:19 -0300 Subject: [ANNOUNCE] GHC 8.6.1 released In-Reply-To: References: <87wore1h9i.fsf@smart-cactus.org> Message-ID: Yes, it worked for me. On Sat, Sep 22, 2018 at 7:44 PM Evan Laforge wrote: > Has anyone installed the OS X binary distribution? I get: > > "utils/ghc-cabal/dist-install/build/tmp/ghc-cabal-bindist" copy > libraries/ghc-prim dist-install "strip" '' '/usr/local' > '/usr/local/lib/ghc-8.6.1' > '/usr/local/share/doc/ghc-8.6.1/html/libraries' 'v p dyn' > dyld: Library not loaded: /usr/local/opt/gmp/lib/libgmp.10.dylib > Referenced from: > > /usr/local/src/hs/ghc-8.6.1/libraries/base/dist-install/build/libHSbase-4.12.0.0-ghc8.6.1.dylib > Reason: image not found > > otool -L on libHSBase indeed shows a reference to > /usr/local/opt/gmp/lib/libgmp.10.dylib, which of course doesn't exist, > not being a standard location. otool on 8.4.2's libHSBase has no > reference to libgmp at all. Both of them have > @rpath/libHSinteger-gmp-1.0.2.0-ghc$version.dylib, but perhaps that's > just ghc's binding to libgmp. > > I don't actually know how ghc links libgmp nowadays. Perhaps the > usual OS X build statically links libgmp and some flags got wrong for > this one and it wound up dynamic? > On Fri, Sep 21, 2018 at 5:57 PM Ben Gamari wrote: > > > > Hello everyone, > > > > The GHC team is pleased to announce the availability of GHC 8.6.1, the > > fourth major release in the GHC 8 series. The source distribution, binary > > distributions, and documentation for this release are available at > > > > https://downloads.haskell.org/~ghc/8.6.1 > > > > The 8.6 release fixes over 400 bugs from the 8.4 series and introduces a > > number of exciting features. These most notably include: > > > > * A new deriving mechanism, `deriving via`, providing a convenient way > > for users to extend Haskell's typeclass deriving mechanism > > > > * Quantified constraints, allowing forall quantification in constraint > contexts > > > > * An early version of the GHCi `:doc` command > > > > * The `ghc-heap-view` package, allowing introspection into the > > structure of GHC's heap > > > > * Valid hole fit hints, helping the user to find terms to fill typed > > holes in their programs > > > > * The BlockArguments extension, allowing the `$` operator to be omitted > > in some unambiguous contexts > > > > * An exciting new plugin mechanism, source plugins, allowing plugins to > > inspect and modify a wide variety of compiler representations. > > > > * Improved recompilation checking when plugins are used > > > > * Significantly better handling of macOS linker command size limits, > > avoiding linker errors while linking large projects > > > > * The next phase of the MonadFail proposal, enabling > > -XMonadFailDesugaring by default > > > > A full list of the changes in this release can be found in the > > release notes: > > > > > https://downloads.haskell.org/~ghc/8.6.1/docs/html/users_guide/8.6.1-notes.html > > > > Perhaps of equal importance, GHC 8.6 is the second major release made > > under GHC's accelerated six-month release schedule and the first set of > > binary distributions built primarily using our new continuous > > integration scheme. While the final 8.6 release is around three weeks > > later than initially scheduled due to late-breaking bug reports, we > > expect that the 8.8 release schedule shouldn't be affected. > > > > Thanks to everyone who has contributed to developing, documenting, and > > testing this release! > > > > As always, let us know if you encounter trouble. > > > > > > How to get it > > ~~~~~~~~~~~~~ > > > > The easy way is to go to the web page, which should be self-explanatory: > > > > https://www.haskell.org/ghc/ > > > > We supply binary builds in the native package format for many > > platforms, and the source distribution is available from the same > > place. > > > > Packages will appear as they are built - if the package for your > > system isn't available yet, please try again later. > > > > > > Background > > ~~~~~~~~~~ > > > > Haskell is a standard lazy functional programming language. > > > > GHC is a state-of-the-art programming suite for Haskell. Included is > > an optimising compiler generating efficient code for a variety of > > platforms, together with an interactive system for convenient, quick > > development. The distribution includes space and time profiling > > facilities, a large collection of libraries, and support for various > > language extensions, including concurrency, exceptions, and foreign > > language interfaces. GHC is distributed under a BSD-style open source > license. > > > > A wide variety of Haskell related resources (tutorials, libraries, > > specifications, documentation, compilers, interpreters, references, > > contact information, links to research groups) are available from the > > Haskell home page (see below). > > > > > > On-line GHC-related resources > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > > > Relevant URLs on the World-Wide Web: > > > > GHC home page https://www.haskell.org/ghc/ > > GHC developers' home page https://ghc.haskell.org/trac/ghc/ > > Haskell home page https://www.haskell.org/ > > > > > > Supported Platforms > > ~~~~~~~~~~~~~~~~~~~ > > > > The list of platforms we support, and the people responsible for them, > > is here: > > > > https://ghc.haskell.org/trac/ghc/wiki/Contributors > > > > Ports to other platforms are possible with varying degrees of > > difficulty. The Building Guide describes how to go about porting to a > > new platform: > > > > https://ghc.haskell.org/trac/ghc/wiki/Building > > > > > > Developers > > ~~~~~~~~~~ > > > > We welcome new contributors. Instructions on accessing our source > > code repository, and getting started with hacking on GHC, are > > available from the GHC's developer's site run by Trac: > > > > https://ghc.haskell.org/trac/ghc/ > > > > > > Mailing lists > > ~~~~~~~~~~~~~ > > > > We run mailing lists for GHC users and bug reports; to subscribe, use > > the web interfaces at > > > > > https://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users > > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-tickets > > > > There are several other haskell and ghc-related mailing lists on > > www.haskell.org; for the full list, see > > > > https://mail.haskell.org/cgi-bin/mailman/listinfo > > > > Some GHC developers hang out on #haskell on IRC, too: > > > > https://www.haskell.org/haskellwiki/IRC_channel > > > > Please report bugs using our bug tracking system. Instructions on > > reporting bugs can be found here: > > > > https://www.haskell.org/ghc/reportabug > > _______________________________________________ > > Glasgow-haskell-users mailing list > > Glasgow-haskell-users at haskell.org > > http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: From juhpetersen at gmail.com Mon Sep 24 07:09:13 2018 From: juhpetersen at gmail.com (Jens Petersen) Date: Mon, 24 Sep 2018 16:09:13 +0900 Subject: [ANNOUNCE] GHC 8.6.1 released In-Reply-To: <87wore1h9i.fsf@smart-cactus.org> References: <87wore1h9i.fsf@smart-cactus.org> Message-ID: I have built 8.6.1 for Fedora 27, 28, 29, Rawhide, and EPEL7 in: https://copr.fedorainfracloud.org/coprs/petersen/ghc-8.6.1/ The repo also includes latest cabal-install. Thanks for the release! Jens On Sat, 22 Sep 2018 at 09:58, Ben Gamari wrote: > > Hello everyone, > > The GHC team is pleased to announce the availability of GHC 8.6.1, the > fourth major release in the GHC 8 series. The source distribution, binary > distributions, and documentation for this release are available at > > https://downloads.haskell.org/~ghc/8.6.1 > > The 8.6 release fixes over 400 bugs from the 8.4 series and introduces a > number of exciting features. These most notably include: > > * A new deriving mechanism, `deriving via`, providing a convenient way > for users to extend Haskell's typeclass deriving mechanism > > * Quantified constraints, allowing forall quantification in constraint contexts > > * An early version of the GHCi `:doc` command > > * The `ghc-heap-view` package, allowing introspection into the > structure of GHC's heap > > * Valid hole fit hints, helping the user to find terms to fill typed > holes in their programs > > * The BlockArguments extension, allowing the `$` operator to be omitted > in some unambiguous contexts > > * An exciting new plugin mechanism, source plugins, allowing plugins to > inspect and modify a wide variety of compiler representations. > > * Improved recompilation checking when plugins are used > > * Significantly better handling of macOS linker command size limits, > avoiding linker errors while linking large projects > > * The next phase of the MonadFail proposal, enabling > -XMonadFailDesugaring by default > > A full list of the changes in this release can be found in the > release notes: > > https://downloads.haskell.org/~ghc/8.6.1/docs/html/users_guide/8.6.1-notes.html > > Perhaps of equal importance, GHC 8.6 is the second major release made > under GHC's accelerated six-month release schedule and the first set of > binary distributions built primarily using our new continuous > integration scheme. While the final 8.6 release is around three weeks > later than initially scheduled due to late-breaking bug reports, we > expect that the 8.8 release schedule shouldn't be affected. > > Thanks to everyone who has contributed to developing, documenting, and > testing this release! > > As always, let us know if you encounter trouble. > > > How to get it > ~~~~~~~~~~~~~ > > The easy way is to go to the web page, which should be self-explanatory: > > https://www.haskell.org/ghc/ > > We supply binary builds in the native package format for many > platforms, and the source distribution is available from the same > place. > > Packages will appear as they are built - if the package for your > system isn't available yet, please try again later. > > > Background > ~~~~~~~~~~ > > Haskell is a standard lazy functional programming language. > > GHC is a state-of-the-art programming suite for Haskell. Included is > an optimising compiler generating efficient code for a variety of > platforms, together with an interactive system for convenient, quick > development. The distribution includes space and time profiling > facilities, a large collection of libraries, and support for various > language extensions, including concurrency, exceptions, and foreign > language interfaces. GHC is distributed under a BSD-style open source license. > > A wide variety of Haskell related resources (tutorials, libraries, > specifications, documentation, compilers, interpreters, references, > contact information, links to research groups) are available from the > Haskell home page (see below). > > > On-line GHC-related resources > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > Relevant URLs on the World-Wide Web: > > GHC home page https://www.haskell.org/ghc/ > GHC developers' home page https://ghc.haskell.org/trac/ghc/ > Haskell home page https://www.haskell.org/ > > > Supported Platforms > ~~~~~~~~~~~~~~~~~~~ > > The list of platforms we support, and the people responsible for them, > is here: > > https://ghc.haskell.org/trac/ghc/wiki/Contributors > > Ports to other platforms are possible with varying degrees of > difficulty. The Building Guide describes how to go about porting to a > new platform: > > https://ghc.haskell.org/trac/ghc/wiki/Building > > > Developers > ~~~~~~~~~~ > > We welcome new contributors. Instructions on accessing our source > code repository, and getting started with hacking on GHC, are > available from the GHC's developer's site run by Trac: > > https://ghc.haskell.org/trac/ghc/ > > > Mailing lists > ~~~~~~~~~~~~~ > > We run mailing lists for GHC users and bug reports; to subscribe, use > the web interfaces at > > https://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-tickets > > There are several other haskell and ghc-related mailing lists on > www.haskell.org; for the full list, see > > https://mail.haskell.org/cgi-bin/mailman/listinfo > > Some GHC developers hang out on #haskell on IRC, too: > > https://www.haskell.org/haskellwiki/IRC_channel > > Please report bugs using our bug tracking system. Instructions on > reporting bugs can be found here: > > https://www.haskell.org/ghc/reportabug > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs From harendra.kumar at gmail.com Mon Sep 24 10:42:23 2018 From: harendra.kumar at gmail.com (Harendra Kumar) Date: Mon, 24 Sep 2018 16:12:23 +0530 Subject: clonetype Message-ID: Often, we need to create a newtype that is equivalent to a given type for safety reasons. Using type synonym is useless from type safety perspective. With newtype, we have to add a "deriving" clause to it for deriving the required instances, to make it practically useful. Does it make sense, and is it possible to have something like a "clonetype" that creates a new type and derives all the instances of the parent type as well? It will be quite helpful in creating equivalent newtype synonyms quickly. Almost always, I do not use a newtype where I should just because of the inconvenience of deriving the instances. Ideally, we should just be able to say something like: clonetype MyString = String and we are good to go. What is the shortest possible way to achieve this with currently available mechanisms, if any? -harendra -------------- next part -------------- An HTML attachment was scrubbed... URL: From simonpj at microsoft.com Mon Sep 24 12:35:02 2018 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Mon, 24 Sep 2018 12:35:02 +0000 Subject: Windows testsuite failures In-Reply-To: <5ba8807e.1c69fb81.fd5f8.54f4@mx.google.com> References: <5ba8807e.1c69fb81.fd5f8.54f4@mx.google.com> Message-ID: Tamar Thank you, that’s great! For the ones that need more work, can we mark them as expect-broken, so that they don’t pollute the testsuite output? Simon From: lonetiger at gmail.com Sent: 24 September 2018 07:13 To: Simon Peyton Jones Subject: RE: Windows testsuite failures Hi Simon, I created some patches to fix the majority of these https://phabricator.haskell.org/D5174 https://phabricator.haskell.org/D5175 https://phabricator.haskell.org/D5176 The remaining ones I’ve either pinged the patches that caused the issues or created tickets For them because they’re actual bugs that require a bit more time to find the cause and fix. https://ghc.haskell.org/trac/ghc/ticket/15668 https://ghc.haskell.org/trac/ghc/ticket/15669 https://ghc.haskell.org/trac/ghc/ticket/15670 https://ghc.haskell.org/trac/ghc/ticket/15671 these should bring down the amount of failing tests to about 5. Kind Regards, Tamar From: Simon Peyton Jones Sent: Thursday, September 20, 2018 12:05 To: Phyx Subject: RE: Windows testsuite failures Thanks Tamar. I’ll look forward to hearing back S From: Phyx > Sent: 20 September 2018 12:02 To: Simon Peyton Jones > Cc: ghc-devs at haskell.org Subject: Re: Windows testsuite failures Hi Simon, Thanks for the email. I haven't been building head much as I'm working on top of some older commits. From a quick look it seems like the plugin ones are probably testisms, the plugins aren't found so likely a missing path entry somewhere. The linker ones are are weird, I'll need to take a closer look at those, likely culprit is my recent patch, I had been testing in the 32 bit build and didn't notice these. There are a few worrying segfault that shouldn't be there on some random tests so I'll take a closer look at those too. And the stat changes need to be updated. The framework failures I don't see on harbormaster, so think they are again a threading artifact. Need to figure out a more effective way to debug these to find a permanent fix. The ones that harbormaster does see are encoding related. touch is failing on non-ascii names. I will take a look this weekend. Kind regards, Tamar On Thu, Sep 20, 2018, 11:33 Simon Peyton Jones > wrote: Hi Tamar The list of testsuite failure on Windows has grown quite long – see below. Most seem to concern plugins or linking. Do you know what is going on here? If they can’t be fixed, can we mark them as expect_broken on Windows, so that it’s easier (when developing) to know when I’ve introduced a regression. Currently I have to do a manual diff against a rather long list. Thanks! Simon SUMMARY for test run started at Thu Sep 20 00:13:20 2018 GMTST 1:03:11 spent to go through 6530 total tests, which gave rise to 18728 test cases, of which 12206 were skipped 33 had missing libraries 6278 expected passes 173 expected failures 9 caused framework failures 1 caused framework warnings 0 unexpected passes 31 unexpected failures 7 unexpected stat failures Unexpected failures: ghci/linking/dyn/T10955dyn.run T10955dyn [bad exit code] (normal) ghci/linking/dyn/T10955.run T10955 [bad stderr] (ghci) ghci/linking/dyn/T11072gcc.run T11072gcc [bad exit code] (normal) numeric/should_run/FloatFnInverses.run FloatFnInverses [bad stdout] (normal) plugins/T11244.run T11244 [bad stderr] (normal) plugins/plugin-recomp-change.run plugin-recomp-change [bad exit code] (normal) rts/T7040_ghci.run T7040_ghci [bad stdout] (ghci) rts/linker_unload.run linker_unload [bad exit code] (normal) rts/linker_error1.run linker_error1 [bad exit code] (normal) rts/linker_error2.run linker_error2 [bad exit code] (normal) rts/T12771/T12771.run T12771 [bad exit code] (normal) rts/T13082/T13082_good.run T13082_good [bad exit code] (normal) rts/T14611/T14611.run T14611 [bad exit code] (normal) simplCore/should_compile/T7702.run T7702 [exit code non-0] (normal) rts/T10672/T10672_x64.run T10672_x64 [bad exit code] (normal) libraries/Win32/tests/T4452.run T4452 [bad exit code] (normal) plugins/plugins01.run plugins01 [bad exit code] (normal) plugins/plugins07.run plugins07 [bad exit code] (normal) plugins/plugins09.run plugins09 [bad exit code] (normal) plugins/plugins11.run plugins11 [bad exit code] (normal) plugins/plugins12.run plugins12 [bad exit code] (normal) plugins/plugins13.run plugins13 [bad exit code] (normal) plugins/plugins14.run plugins14 [bad exit code] (normal) plugins/plugins15.run plugins15 [bad exit code] (normal) plugins/T10420.run T10420 [bad exit code] (normal) plugins/T10294.run T10294 [bad exit code] (normal) plugins/T10294a.run T10294a [bad exit code] (normal) plugins/T12567a.run T12567a [bad exit code] (normal) plugins/plugin-recomp-pure.run plugin-recomp-pure [bad exit code] (normal) plugins/plugin-recomp-impure.run plugin-recomp-impure [bad exit code] (normal) plugins/plugin-recomp-flags.run plugin-recomp-flags [bad exit code] (normal) Unexpected stat failures: perf/compiler/T9872d.run T9872d [stat not good enough] (normal) perf/compiler/T12425.run T12425 [stat not good enough] (optasm) perf/compiler/T12234.run T12234 [stat not good enough] (optasm) perf/compiler/T12150.run T12150 [stat not good enough] (optasm) perf/should_run/T15226.run T15226 [stat too good] (normal) perf/should_run/T15226a.run T15226a [stat too good] (normal) perf/compiler/MultiLayerModules.run MultiLayerModules [stat not good enough] (normal) Framework failures: ghci/linking/dyn/T10955.run T10955 [ghci] (pre_cmd failed: 2) plugins/T11244.run T11244 [normal] (pre_cmd failed: 2) plugins/plugin-recomp-change.run plugin-recomp-change [normal] (pre_cmd failed: 2) plugins/plugins07.run plugins07 [normal] (pre_cmd failed: 2) plugins/T10420.run T10420 [normal] (pre_cmd failed: 2) plugins/T10294a.run T10294a [normal] (pre_cmd failed: 2) plugins/plugin-recomp-pure.run plugin-recomp-pure [normal] (pre_cmd failed: 2) plugins/plugin-recomp-impure.run plugin-recomp-impure [normal] (pre_cmd failed: 2) plugins/plugin-recomp-flags.run plugin-recomp-flags [normal] (pre_cmd failed: 2) Framework warnings: . T13701 [numfield-no-expected] (No expected value found for bytes allocated in num_field check) -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben at well-typed.com Mon Sep 24 13:36:38 2018 From: ben at well-typed.com (Ben Gamari) Date: Mon, 24 Sep 2018 08:36:38 -0500 Subject: [ANNOUNCE] GHC 8.6.1 released In-Reply-To: References: <87wore1h9i.fsf@smart-cactus.org> Message-ID: <4E0D6D6B-0F2F-4070-A22E-8336A7905667@well-typed.com> On September 24, 2018 2:09:13 AM CDT, Jens Petersen wrote: >I have built 8.6.1 for Fedora 27, 28, 29, Rawhide, and EPEL7 in: > >https://copr.fedorainfracloud.org/coprs/petersen/ghc-8.6.1/ > >The repo also includes latest cabal-install. > Thanks Jens! This is a very helpful service. Cheers, - Ben -- Sent from my Android device with K-9 Mail. Please excuse my brevity. From lonetiger at gmail.com Tue Sep 25 06:11:35 2018 From: lonetiger at gmail.com (Phyx) Date: Tue, 25 Sep 2018 07:11:35 +0100 Subject: Windows testsuite failures In-Reply-To: References: <5ba8807e.1c69fb81.fd5f8.54f4@mx.google.com> Message-ID: Hi Simon, Sure I'll do that. I'll create the patches later tonight. Kind regards, Tamar On Mon, Sep 24, 2018, 13:35 Simon Peyton Jones wrote: > Tamar > > > > Thank you, that’s great! > > > > For the ones that need more work, can we mark them as expect-broken, so > that they don’t pollute the testsuite output? > > > Simon > > > > > > *From:* lonetiger at gmail.com > *Sent:* 24 September 2018 07:13 > > > *To:* Simon Peyton Jones > *Subject:* RE: Windows testsuite failures > > > > > > Hi Simon, > > > > I created some patches to fix the majority of these > > > > https://phabricator.haskell.org/D5174 > > https://phabricator.haskell.org/D5175 > > https://phabricator.haskell.org/D5176 > > > > The remaining ones I’ve either pinged the patches that caused the issues > or created tickets > > For them because they’re actual bugs that require a bit more time to find > the cause and fix. > > > > https://ghc.haskell.org/trac/ghc/ticket/15668 > > https://ghc.haskell.org/trac/ghc/ticket/15669 > > https://ghc.haskell.org/trac/ghc/ticket/15670 > > https://ghc.haskell.org/trac/ghc/ticket/15671 > > > > these should bring down the amount of failing tests to about 5. > > > > Kind Regards, > > Tamar > > > > *From: *Simon Peyton Jones > *Sent: *Thursday, September 20, 2018 12:05 > *To: *Phyx > *Subject: *RE: Windows testsuite failures > > > > Thanks Tamar. I’ll look forward to hearing back > > > > S > > > > *From:* Phyx > *Sent:* 20 September 2018 12:02 > *To:* Simon Peyton Jones > *Cc:* ghc-devs at haskell.org > *Subject:* Re: Windows testsuite failures > > > > Hi Simon, > > > > Thanks for the email. I haven't been building head much as I'm working on > top of some older commits. From a quick look it seems like the plugin ones > are probably testisms, the plugins aren't found so likely a missing path > entry somewhere. > > > > The linker ones are are weird, I'll need to take a closer look at those, > likely culprit is my recent patch, I had been testing in the 32 bit build > and didn't notice these. > > > > There are a few worrying segfault that shouldn't be there on some random > tests so I'll take a closer look at those too. > > > > And the stat changes need to be updated. > > > > The framework failures I don't see on harbormaster, so think they are > again a threading artifact. Need to figure out a more effective way to > debug these to find a permanent fix. The ones that harbormaster does see > are encoding related. touch is failing on non-ascii names. > > > > I will take a look this weekend. > > > > Kind regards, > > Tamar > > > > On Thu, Sep 20, 2018, 11:33 Simon Peyton Jones > wrote: > > Hi Tamar > > The list of testsuite failure on Windows has grown quite long – see > below. Most seem to concern plugins or linking. > > Do you know what is going on here? If they can’t be fixed, can we mark > them as expect_broken on Windows, so that it’s easier (when developing) to > know when I’ve introduced a regression. Currently I have to do a manual > diff against a rather long list. > > Thanks! > > Simon > > > > *SUMMARY for test run started at Thu Sep 20 00:13:20 2018 GMTST* > > *1:03:11 spent to go through* > > * 6530 total tests, which gave rise to* > > * 18728 test cases, of which* > > * 12206 were skipped* > > > > * 33 had missing libraries* > > * 6278 expected passes* > > * 173 expected failures* > > > > * 9 caused framework failures* > > * 1 caused framework warnings* > > * 0 unexpected passes* > > * 31 unexpected failures* > > * 7 unexpected stat failures* > > > > *Unexpected failures:* > > * ghci/linking/dyn/T10955dyn.run T10955dyn [bad exit code] > (normal)* > > * ghci/linking/dyn/T10955.run T10955 [bad stderr] (ghci)* > > * ghci/linking/dyn/T11072gcc.run T11072gcc [bad exit code] > (normal)* > > * numeric/should_run/FloatFnInverses.run FloatFnInverses [bad stdout] > (normal)* > > * plugins/T11244.run T11244 [bad stderr] (normal)* > > * plugins/plugin-recomp-change.run plugin-recomp-change [bad exit > code] (normal)* > > * rts/T7040_ghci.run T7040_ghci [bad stdout] (ghci)* > > * rts/linker_unload.run linker_unload [bad exit code] > (normal)* > > * rts/linker_error1.run linker_error1 [bad exit code] > (normal)* > > * rts/linker_error2.run linker_error2 [bad exit code] > (normal)* > > * rts/T12771/T12771.run T12771 [bad exit code] > (normal)* > > * rts/T13082/T13082_good.run T13082_good [bad exit code] > (normal)* > > * rts/T14611/T14611.run T14611 [bad exit code] > (normal)* > > * simplCore/should_compile/T7702.run T7702 [exit code non-0] > (normal)* > > * rts/T10672/T10672_x64.run T10672_x64 [bad exit code] > (normal)* > > * libraries/Win32/tests/T4452.run T4452 [bad exit code] (normal)* > > * plugins/plugins01.run plugins01 [bad exit code] > (normal)* > > * plugins/plugins07.run plugins07 [bad exit code] > (normal)* > > * plugins/plugins09.run plugins09 [bad exit code] > (normal)* > > * plugins/plugins11.run plugins11 [bad exit code] > (normal)* > > * plugins/plugins12.run plugins12 [bad exit code] > (normal)* > > * plugins/plugins13.run plugins13 [bad exit code] > (normal)* > > * plugins/plugins14.run plugins14 [bad exit code] > (normal)* > > * plugins/plugins15.run plugins15 [bad exit code] > (normal)* > > * plugins/T10420.run T10420 [bad exit code] > (normal)* > > * plugins/T10294.run T10294 [bad exit code] > (normal)* > > * plugins/T10294a.run T10294a [bad exit code] > (normal)* > > * plugins/T12567a.run T12567a [bad exit code] > (normal)* > > * plugins/plugin-recomp-pure.run plugin-recomp-pure [bad exit > code] (normal)* > > * plugins/plugin-recomp-impure.run plugin-recomp-impure [bad exit > code] (normal)* > > * plugins/plugin-recomp-flags.run plugin-recomp-flags [bad exit > code] (normal)* > > > > *Unexpected stat failures:* > > * perf/compiler/T9872d.run T9872d [stat not good enough] > (normal)* > > * perf/compiler/T12425.run T12425 [stat not good enough] > (optasm)* > > * perf/compiler/T12234.run T12234 [stat not good enough] > (optasm)* > > * perf/compiler/T12150.run T12150 [stat not good enough] > (optasm)* > > * perf/should_run/T15226.run T15226 [stat too good] (normal)* > > * perf/should_run/T15226a.run T15226a [stat too good] (normal)* > > * perf/compiler/MultiLayerModules.run MultiLayerModules [stat not good > enough] (normal)* > > > > *Framework failures:* > > * ghci/linking/dyn/T10955.run T10955 [ghci] (pre_cmd failed: 2)* > > * plugins/T11244.run T11244 [normal] (pre_cmd failed: 2)* > > * plugins/plugin-recomp-change.run plugin-recomp-change [normal] > (pre_cmd failed: 2)* > > * plugins/plugins07.run plugins07 [normal] (pre_cmd failed: > 2)* > > * plugins/T10420.run T10420 [normal] (pre_cmd failed: 2)* > > * plugins/T10294a.run T10294a [normal] (pre_cmd failed: 2)* > > * plugins/plugin-recomp-pure.run plugin-recomp-pure [normal] (pre_cmd > failed: 2)* > > * plugins/plugin-recomp-impure.run plugin-recomp-impure [normal] > (pre_cmd failed: 2)* > > * plugins/plugin-recomp-flags.run plugin-recomp-flags [normal] > (pre_cmd failed: 2)* > > > > *Framework warnings:* > > * . T13701 [numfield-no-expected] (No expected value found for bytes > allocated in num_field check)* > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.feuer at gmail.com Wed Sep 26 15:54:40 2018 From: david.feuer at gmail.com (David Feuer) Date: Wed, 26 Sep 2018 11:54:40 -0400 Subject: Stable name allocation In-Reply-To: References: Message-ID: Simon seems a bit busy right now. Can anyone else advise me on the basics of heap allocation in primops? On Tue, Sep 25, 2018 at 1:42 PM, David Feuer wrote: > Let's forget about allocate(). I can definitely handle this part in > C--. But I'm still lost in the macros and such. For example, I'm very > unclear on the differences among the ALLOC, HP_CHK, and MAYBE_GC > classes of macro. I can't find anything in the commentary, and the > source code documentation is very sparse. I'm okay with either of the > following approaches, but either way I need a bit more info. > > 1. First see if we need to allocate a StableName#. If so, check > whether GC would be required to allocate the StableName# (how?). If > so, drop the lock, run GC (how?) and start over. This looks cleanest > to me if it can be done easily. > > 2. First run the GC if we're low on memory (how?). Then if we need to > allocate a StableName#, we'll be sure to have room. > > > On Tue, Sep 25, 2018 at 6:25 AM, Simon Marlow wrote: >> You can do it unconditionally before taking the lock, or you can do it >> conditionally as long as you release the lock if the heap check fails. I >> think in the latter case there might not be a macro that allows this, but >> you could use the `allocate()` method for allocating memory (like >> newByteArray#) and then you could write a heap check like the MAYBE_GC() >> macro. Doing it unconditionally is easier and probably not a big performance >> hit, but note that you'll have to retreat Hp if you don't use the memory. >> >> Cheers >> Simon >> >> On Sat, 22 Sep 2018 at 13:08, David Feuer wrote: >>> >>> How do I check if GC will be required, and how do I trigger it? Should I >>> perform the check unconditionally at the beginning of the operation so I >>> don't have to drop the lock, GC, then retake? I don't know the right ways to >>> deal with this stuff, and the macros are mostly undocumented. >>> >>> On Sep 22, 2018 3:53 AM, "Simon Marlow" wrote: >>> >>> Yes, the current implementation looks like it creates the object after >>> adding the entry to the StableName table and releasing the lock, which is >>> unsafe because another thread could read that same entry before the object >>> has been created. The easiest solution to that is to take and release the >>> lock in C-- in the right places instead of in the C lookupStableName() >>> function (you might need to make a separate version of lookupStableName() >>> that doesn't take the lock). >>> >>> Cheers >>> Simon >>> >>> >>> On Fri, 21 Sep 2018 at 12:53, David Feuer wrote: >>>> >>>> It seems awkward to do it in C--, but maybe you can help me work out how. >>>> The allocation facilities definitely seem much nicer there, and allocating a >>>> small heap object in C feels like an abuse of the facilities we have there. >>>> The essential challenge, as I see it, is that we need the key to point to a >>>> valid stable name object by the time we drop the hash table lock. The >>>> process, as I imagine it: >>>> >>>> 1. Follow indirections, untag, choose the right generation. (All this is >>>> in C) >>>> 2. Take the appropriate hash table lock. (C) >>>> 3. Look up the key in the hash table (C). >>>> >>>> Now there's a branch. If we found the key, then we don't need to allocate >>>> an SNO. We just drop the lock and return. Otherwise >>>> >>>> 4. Allocate an SNO and set its info pointer (most easily done in C--). If >>>> this necessitates GC, we need to drop the lock first and might as well just >>>> go back to the very beginning afterwards. >>>> 5. Populate the SNO with its "hash value" (we can do this anywhere we >>>> like, I imagine). >>>> 6. Insert the key and SNO into the hash table and drop the hash table >>>> lock (C) >>>> 7. If necessary, insert the SNO into the remembered set (C) >>>> >>>> How would you recommend structuring this back-and-forth? >>>> >>>> On Fri, Sep 21, 2018, 3:19 AM Simon Marlow wrote: >>>>> >>>>> I'm a bit sceptical that you need to allocate a heap object in C instead >>>>> of C--, but still, here's an example: >>>>> https://phabricator.haskell.org/diffusion/GHC/browse/master/rts%2FThreads.c$258-261 >>>>> >>>>> It's slightly less efficient to do this in C than C--, because >>>>> `allocate()` is slower than allocating by bumping `Hp`. >>>>> >>>>> On Mon, 17 Sep 2018 at 21:25, David Feuer wrote: >>>>>> >>>>>> How can I allocate a heap object in C code in the rts? I've only seen >>>>>> heap objects allocated in C--, and doing that here would be lousy for >>>>>> performance and worse for clarity. >>>>>> >>>>>> David >>> >>> >> From marlowsd at gmail.com Thu Sep 27 22:59:45 2018 From: marlowsd at gmail.com (Simon Marlow) Date: Thu, 27 Sep 2018 17:59:45 -0500 Subject: Stable name allocation In-Reply-To: References: Message-ID: On Wed, 26 Sep 2018 at 10:54, David Feuer wrote: > Simon seems a bit busy right now. Can anyone else advise me on the > basics of heap allocation in primops? > > On Tue, Sep 25, 2018 at 1:42 PM, David Feuer > wrote: > > Let's forget about allocate(). I can definitely handle this part in > > C--. But I'm still lost in the macros and such. For example, I'm very > > unclear on the differences among the ALLOC, HP_CHK, and MAYBE_GC > > classes of macro. I can't find anything in the commentary, and the > > source code documentation is very sparse. I'm okay with either of the > > following approaches, but either way I need a bit more info. > The best way to understand these macros is to look at their implementations and see how they're used in other parts of the RTS. MAYBE_GC doesn't bump Hp, it is used to ensure that we don't indefinitely call allocate() in primops that use it. The ALLOC family are wrappers around the lower level HP_CHK functions, these bump Hp. Some of the variations are optimisations to generate less verbose code - again, see the other primops for examples. It's always safe to use HP_CHK_GEN_TICKY(), but there might be better alternatives depending on the type of your primitive. Cheers Simon > > 1. First see if we need to allocate a StableName#. If so, check > > whether GC would be required to allocate the StableName# (how?). If > > so, drop the lock, run GC (how?) and start over. This looks cleanest > > to me if it can be done easily. > > > > 2. First run the GC if we're low on memory (how?). Then if we need to > > allocate a StableName#, we'll be sure to have room. > > > > > > On Tue, Sep 25, 2018 at 6:25 AM, Simon Marlow > wrote: > >> You can do it unconditionally before taking the lock, or you can do it > >> conditionally as long as you release the lock if the heap check fails. I > >> think in the latter case there might not be a macro that allows this, > but > >> you could use the `allocate()` method for allocating memory (like > >> newByteArray#) and then you could write a heap check like the MAYBE_GC() > >> macro. Doing it unconditionally is easier and probably not a big > performance > >> hit, but note that you'll have to retreat Hp if you don't use the > memory. > >> > >> Cheers > >> Simon > >> > >> On Sat, 22 Sep 2018 at 13:08, David Feuer > wrote: > >>> > >>> How do I check if GC will be required, and how do I trigger it? Should > I > >>> perform the check unconditionally at the beginning of the operation so > I > >>> don't have to drop the lock, GC, then retake? I don't know the right > ways to > >>> deal with this stuff, and the macros are mostly undocumented. > >>> > >>> On Sep 22, 2018 3:53 AM, "Simon Marlow" wrote: > >>> > >>> Yes, the current implementation looks like it creates the object after > >>> adding the entry to the StableName table and releasing the lock, which > is > >>> unsafe because another thread could read that same entry before the > object > >>> has been created. The easiest solution to that is to take and release > the > >>> lock in C-- in the right places instead of in the C lookupStableName() > >>> function (you might need to make a separate version of > lookupStableName() > >>> that doesn't take the lock). > >>> > >>> Cheers > >>> Simon > >>> > >>> > >>> On Fri, 21 Sep 2018 at 12:53, David Feuer > wrote: > >>>> > >>>> It seems awkward to do it in C--, but maybe you can help me work out > how. > >>>> The allocation facilities definitely seem much nicer there, and > allocating a > >>>> small heap object in C feels like an abuse of the facilities we have > there. > >>>> The essential challenge, as I see it, is that we need the key to > point to a > >>>> valid stable name object by the time we drop the hash table lock. The > >>>> process, as I imagine it: > >>>> > >>>> 1. Follow indirections, untag, choose the right generation. (All this > is > >>>> in C) > >>>> 2. Take the appropriate hash table lock. (C) > >>>> 3. Look up the key in the hash table (C). > >>>> > >>>> Now there's a branch. If we found the key, then we don't need to > allocate > >>>> an SNO. We just drop the lock and return. Otherwise > >>>> > >>>> 4. Allocate an SNO and set its info pointer (most easily done in > C--). If > >>>> this necessitates GC, we need to drop the lock first and might as > well just > >>>> go back to the very beginning afterwards. > >>>> 5. Populate the SNO with its "hash value" (we can do this anywhere we > >>>> like, I imagine). > >>>> 6. Insert the key and SNO into the hash table and drop the hash table > >>>> lock (C) > >>>> 7. If necessary, insert the SNO into the remembered set (C) > >>>> > >>>> How would you recommend structuring this back-and-forth? > >>>> > >>>> On Fri, Sep 21, 2018, 3:19 AM Simon Marlow > wrote: > >>>>> > >>>>> I'm a bit sceptical that you need to allocate a heap object in C > instead > >>>>> of C--, but still, here's an example: > >>>>> > https://phabricator.haskell.org/diffusion/GHC/browse/master/rts%2FThreads.c$258-261 > >>>>> > >>>>> It's slightly less efficient to do this in C than C--, because > >>>>> `allocate()` is slower than allocating by bumping `Hp`. > >>>>> > >>>>> On Mon, 17 Sep 2018 at 21:25, David Feuer > wrote: > >>>>>> > >>>>>> How can I allocate a heap object in C code in the rts? I've only > seen > >>>>>> heap objects allocated in C--, and doing that here would be lousy > for > >>>>>> performance and worse for clarity. > >>>>>> > >>>>>> David > >>> > >>> > >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From omeragacan at gmail.com Sun Sep 30 11:18:29 2018 From: omeragacan at gmail.com (=?UTF-8?Q?=C3=96mer_Sinan_A=C4=9Facan?=) Date: Sun, 30 Sep 2018 14:18:29 +0300 Subject: nofib oldest GHC to support? Message-ID: Do we have a policy on the oldest GHC to support in nofib? I'm currently doing some hacking on nofib to parse some new info printed by a modified GHC, and I think we can do a lot of cleaning (at the very least remove some regexes and parsers) if we decide on which GHCs to support. I checked the README and RunningNoFib wiki page but couldn't see anything relevant. Thanks Ömer