Re: recomp001 failing on OSX for Phab:D2853

Luke Maurer writes: > Getting an odd test failure from Phab: > > @@ -1,2 +0,0 @@ > - > -C.hs:3:11: Module ‘B’ does not export ‘foo’ > Actual stderr output differs from expected: > *** unexpected failure for recomp001(normal) > > https://phabricator.haskell.org/harbormaster/build/18499/?l=0 > > I

[GHC Proposal] Propose overhaul of implicit quantification in Template Haskell quoting

Hello everyone, Ryan Scott just opened Pull Request #36 [1] against the ghc-proposals repository. This is a proposal to change the behavior of Template Haskell quoting with respect to implicitly quantified type variables. The overall effect is that implicitly quantified type variables will be sepa

T13156

Hi Simon, I'm seeing some rather peculiar validation issues with your most recent patch. Namely, => T13156(normal) 1 of 1 [0, 0, 0] cd "./simplCore/should_compile/T13156.run" && $MAKE -s --no-print-directory T13156 Actual stdout output differs from expected: diff -uw "./simplCore/should_co

Re: T13156

Ben Gamari writes: > Hi Simon, > Hi Simon, Please ignore this; my working tree was dirty. Unfortunately this means that my version of akio's top-level strings patch regresses, but I can work this out on my own. Sorry for the noise. Cheers, - Ben signature.asc Description: PG

Re: Problems with `arc` and `phabricator`

Iavor Diatchki writes: > Ah good, that worked. I've pushed before, I wonder what happened to my key? > It's quite possible you never had one. A key has only been mandatory for uploads for a few months now. Cheers, - Ben signature.asc Description: PGP signature __

Re: quick building the user's guide

Takenobu Tani writes: > Dear devs, > > Can We build the user's guide without building the ghc binary? > If so, new contributors can easily check the generated html. > Sadly no. I would like to make this possible, but currently we rely on the stage1 ghc library to extract information about flags.

Re: Overloaded record fields for 8.2?

Adam Gundry writes: > Hi Ben, devs, > > I'd like to propose that we merge my latest ORF patch > (https://phabricator.haskell.org/D2708) for 8.2 (modulo any code review > improvements, of course). The corresponding proposal discussion > (https://github.com/ghc-proposals/ghc-proposals/pull/6) seems

Re: Lazy ST vs concurrency

David Feuer writes: > On Monday, January 30, 2017 9:50:56 PM EST Simon Marlow wrote: > >> Unfortunately the mechanisms we have right now to fix it aren't ideal - >> noDuplicate# is a bigger hammer than we need. > > Do you think you could explain this a bit more? What aspect of nuDuplicate# > is

Freeze update

Hello everyone, As you likely know, the feature freeze date for the 8.2.1 was yesterday. Unfortunately, it looks like that date may have been a bit optimistic as there are there are still several major patches outstanding that we would like to have for 8.2.1. These are namely, * Join points rewo

Re: D2038: [WIP] TysPrim: Generalize kind of (->)

Richard Eisenberg writes: snip > > I think the Right Answer is to get rid of newtype-classes & fix reify, and > I’m worried that anything short of that will fail catastrophically at some > point. Otherwise, it’s patches on top of patches. > > I don’t think there is disagreement here, but there

Re: Join points revised

Luke Maurer writes: > Revised version of the join points patch is up: > > https://phabricator.haskell.org/D2853 > > Hoping to commit ASAP. Thanks all! > I have a few further review comments that I'm about to submit. Cheers, - Ben signature.asc Description: PGP signature __

Re: D2038: [WIP] TysPrim: Generalize kind of (->)

Richard Eisenberg writes: > I had another thought on my drive home: why do we need to sort out > Constraint v Type for 8.2? I have the patch, and it's essentially all > set. But it weakens equality in a way that's troublesome for D2038 and > introduces heterogeneous axioms, which are strange, ill

Re: More history in perf.haskell.org graphs

Reid Barton writes: > Hi Joachim, > > The graphs like https://perf.haskell.org/ghc/#graph/buildtime/make are > very helpful, but I haven't found a way to adjust the range of commits > shown from the default of the last 50 commits. For example, suppose I > wanted to see the history of build time o

RE: D2038: [WIP] TysPrim: Generalize kind of (->)

Simon Peyton Jones via ghc-devs writes: > Check out > https://ghc.haskell.org/trac/ghc/wiki/Status/GHC-8.2.1 > > There are several tickets you own in highest or high prio. Notably #12919 > (an outright bug). And #12670, #13160, #13202 > > BEN: yell for whatever help you need with (->) and

Re: Master broken?

Simon Peyton Jones via ghc-devs writes: > My clean build of origin/master, on 64-bit Linux is showing these failures > > Unexpected failures: > >/tmp/ghctest-5_qx1p/test spaces/./pmcheck/should_compile/T11195.run > T11195 [exit code non-0] (normal) > > > > Unexpected stat failures: > >

Talkative Join points warning

Hi Luke, I've noticed that a new WARN in OccurAnal seems to be quite loud. Validations now produce thousands of lines of the form, WARNING: file compiler/simplCore/OccurAnal.hs, line 2633 OccurAnal failed to rediscover join point(s): [$j_shTG] WARNING: file compiler/simplCore/Occur

RE: Panic from rewritableTyVarsOfType

Simon Peyton Jones writes: > Ben, Richard > > rewritableTyVarsOfType is used when deciding whether to split a [WD] > constraint into [W] and [D]. For example, if we are adding >[WD] C a > and there is an inert >[WD] a ~ Int > then we want to split the [WD] into >[W] C a >[D] C a >

RE: Panic from rewritableTyVarsOfType

Ben Gamari writes: > Simon Peyton Jones writes: > >> Meanwhile to get you rolling, you can replace rewritableTyVars with >> tyCoVarsOfType and it'll all work, just a bit less efficiently. >> > Thanks Simon! Indeed that allows things to proceed and in the process

Phabricator upgrade tomorrow

Hello everyone! Tomorrow I'm going to perform another Phabricator update if no one objects. Let me know if this will cause you undue burden. Cheers, - Ben signature.asc Description: PGP signature ___ ghc-devs mailing list ghc-devs@haskell.org http:/

Re: Handling of unlifted types

Erik de Castro Lopo writes: > Hi all, > > I'm working on pulling the core parts of Joachim Breitner's > ghc-heap-view library into GHC. The WIP Phab review is here: > > https://phabricator.haskell.org/D3055 > > Currently that library has a function: > > getClosureData :: a -> IO Closure >

Re: D2903 Needs Review

Thomas Jakway writes: > If anyone has a free moment I'd appreciate feedback on D2903: > https://phabricator.haskell.org/D2903 > Thanks Thomas! Cheers, - Ben signature.asc Description: PGP signature ___ ghc-devs mailing list ghc-devs@haskell.org ht

8.2.1 Status

Hello everyone, Over the last week I've been busily helping Richard finish up the last bits destined for 8.2.1. At this point things are looking okay, although there is still a bit of a push necessary before we can cut an 8.2 branch, * We have decided to punt the separation of * and Constraint (

Re: 8.2.1 Status

George Colpitts writes: > Hi Ben > > It would be good if the status page ( > https://ghc.haskell.org/trac/ghc/wiki/Status/GHC-8.2.1) could be updated > with what we will actually be getting. In particular, according to > https://ghc.haskell.org/trac/ghc/ticket/10074 Implement the 'Improved LLVM >

Re: Build time over travis time limit again

Joachim Breitner writes: > Hi, > > Am Mittwoch, den 08.02.2017, 12:47 + schrieb Andrey Mokhov: >> Does Hadrian speed up a build from scratch? >> >> Hadrian can build GHC on Windows (AppVeyor) and Linux (Travis) CI >> instances in about 40 mins using the 'quickest' build flavour (no >> optimi

Re: 8.2.1 Status

Ryan Scott writes: > Hi Ben, > Hi Ryan, > Sorry for not asking this sooner, but I'd like to merge some form of > https://phabricator.haskell.org/D2961 in time for 8.2 if possible. Sadly, > doing it "the right way" (according to Simon) is proving to be extremely > challenging. A previous iteratio

RE: Build time over travis time limit again

Andrey Mokhov writes: > Joachim, Ben, > > I gave it a try on my machine. > > First of all, we currently need "--flavour=quick" instead of "quickest" > because the latter builds only vanilla RTS. > > If I do: > > ./build.bat -j --flavour=quick > ./build.bat -j --flavour=quick validate > > Then t

Re: Non-wip/* branches

Joachim Breitner writes: > Hi, > >> facundominguez added a comment. >>  >> @nomeata please, could you remove the branches fd/fix-travis and  >> fd/fix-travis2? Some server hook is preventing me from doing so. > > turns out I cannot do that either (which I knew). From experience, I > know that I c

Trac maintenance

Hello everyone, I'll be doing some maintenance on the Trac installation in a few minutes. It may be a bit flaky while this happens. Sorry for the inconvenience! Cheers, - Ben signature.asc Description: PGP signature ___ ghc-devs mailing list ghc-devs

Re: Trac maintenance

Ben Gamari writes: > Hello everyone, > > I'll be doing some maintenance on the Trac installation in a few > minutes. It may be a bit flaky while this happens. Sorry for the > inconvenience! > Alright, I believe that should do it. We are now running Trac 1.2. Let me kn

Re: Trac maintenance

Konrad Gądek writes: >> upon a quick try, I am missing the live preview of changes as I edit a >> ticket. >> >> Oh, and when I try to edit a ticket I get >> >> AttributeError: 'Environment' object has no attribute 'get_db_cnx' > > I get the same error when I try to create new ticket. > Thanks

Re: Trac maintenance

Matthew Pickering writes: > Were there any particular features that we should know about which > motivated the upgrade? > The primary motivations were to get better spam filtering for user registration and to fix syntax highlighting. > Displaying real names is slightly inconvenient now for the p

Re: Nofib runtimes sensitivity to RTS changes

Joachim Breitner writes: > Hi, > > this is mostly a rant, targeted at the very vague fact that runtime > performance benchmarks are so damn hard. > > This commit just came in: > https://git.haskell.org/ghc.git/commitdiff/56c9bb39246f9ffd8ed41a0656bfe8e60d23be57 > Clearly, only parts of the profil

Convincing GHC not to produce unfoldings during simplification

I'm currently trying to get the interface file bulk imposed by TTypeable down. The branch will currently produce two top-level bindings for each TyCon. For instance, given the type, data Proxy (a :: k) = Proxy the branch will produce (ignoring the promoted datacon for a moment), $tcProxy

Re: Convincing GHC not to produce unfoldings during simplification

Ben Gamari writes: > I have observed that the floated bindings are not included in the > interface file with -O0. Moreover, the core2core output clearly shows > the unfoldings being added after the first simplifier phase. I haven't > yet determined where in the simplifier the

Re: Trac maintenance

Ben Gamari writes: > Matthew Pickering writes: > >> Were there any particular features that we should know about which >> motivated the upgrade? >> > The primary motivations were to get better spam filtering for user > registration and to fix syntax highlighting.

Re: Improving trac notifications

Matthew Pickering writes: > I attach a patch which should improve the notifications. > I have applied this patch to our Trac 1.2 installation. Cheers, - Ben signature.asc Description: PGP signature ___ ghc-devs mailing list ghc-devs@haskell.org http

Re: Trac

Simon Peyton Jones via ghc-devs writes: > Trac tickets now open up with the "Modify ticket" boxes open. That > makes them vulnerable to accidental edits. Could it be closed by > default as it used to be? Hmm, I'm having trouble reproducing this behavior. I wonder whether this is due to some per

Re: Trac

Richard Eisenberg writes: > As another data point, I am *not* seeing this change in behavior. My "Modify > Ticket" tab is closed by default. > Hmm, this is interesting. I just tried this in Chromium and indeed I see the Modify Ticket pane open by default. By contrast, Firefox is closed. What bro

Re: Trac

Ben Gamari writes: > Richard Eisenberg writes: > >> As another data point, I am *not* seeing this change in behavior. My "Modify >> Ticket" tab is closed by default. >> > Hmm, this is interesting. I just tried this in Chromium and indeed I see > th

Re: Trac

Ben Gamari writes: > Ben Gamari writes: > >> Richard Eisenberg writes: >> >>> As another data point, I am *not* seeing this change in behavior. My >>> "Modify Ticket" tab is closed by default. >>> >> Hmm, this is interesting. I just

Re: Trac

Simon Peyton Jones via ghc-devs writes: > Trac tickets now open up with the "Modify ticket" boxes open. That > makes them vulnerable to accidental edits. Could it be closed by > default as it used to be? Let me know if you are still seeing this; I believe it should be resolved if you refresh. C

Trac password reset temporarily disabled

Since the Trac upgrade user password reset and email verification messages have been incorrectly sent to ghc-tick...@haskell.org. This appears to be a bug in the AccountManagerPlugin; I have opened a ticket with upstream (https://trac-hacks.org/ticket/13074) and hope to hear back soon. Until this

Re: Better perf for haddock.base, haddock.Cabal (f4aa998)

Joachim Breitner writes: > Hi, > ... > > I guess https://phabricator.haskell.org/D3089 was merged a bit > prematurely in that respect.¹ > > Greetings, > Joachim > > > ¹ There is a workflow problem with Phab’s DR: > * A creates a new DR. > * B requests changes. DR now in state “revision needed

GHC 8.2.1 status

Hello everyone, It has been a bit over a week since the last update regarding 8.2.1. At the moment we are on the final stretch leading up cutting the branch. Over the last week I have been cleaning up a variety of odds and ends around the tree, bumping core libraries, merging some last patches, sm

Re: Static data and RULES

David Feuer writes: > On Friday, February 17, 2017 12:33:12 AM EST Simon Peyton Jones via ghc-devs > wrote: >> The "L" rule becomes problematic when we try to identify static data the >> simplifier shouldn't have to try to optimize. If it identifies LCon 0 as >> static, the "L" rule will never f

RE: Static data and RULES

Simon Peyton Jones writes: > PS: before we go to some effort to optimise X, can we > I briefly characterized this earlier this week. For a module exporting lots of static data of roughly the same type as TypeRep (e.g. data T = T Addr# Int# Int), the cost scales essentially linearly in the numbe

Re: Trac #13255

Simon Peyton Jones via ghc-devs writes: > Ben > I have pushed a fix for #13255 (blocking the release) to wip/T13255-spj > It contains a series of patches, of which the important one is the last. But > Phabbing them exceeded my skill level. > I'm rebuilding yet again, but I got a couple of stran

RE: Windows build broken again

Simon Peyton Jones via ghc-devs writes: > Windows build still broken. Please please could someone fix? > It's something to do with the testsuite Python script This is #13375. I have a fix in D3289. It's currently validating. Cheers, - Ben signature.asc Description: PGP signature ___

Re: Windows build broken again

Phyx writes: > https://ghc.haskell.org/trac/ghc/ticket/13375 > Are people not receiving my messages pointing out this ticket? I've mentioned it twice now but I get the impression that these messages aren't being seen. Cheers, - Ben signature.asc Description: PGP signature ___

Re: Better perf

Simon Peyton Jones via ghc-devs writes: > I've just committed this patch sequence > > fb9ae288088a3eabc4e1bb4e86fa473a3881d2e2 Make FloatOut/SetLevels idemoptent > on bottoming functions > > 995ab74b3c55fe3a0299bd94b49e948c942e76d6 Comments only > > 1163f4f2fe9aabd722c963497c67c5f8c71ef71b Tiny

Re: Windows build broken again

Simon Peyton Jones via ghc-devs writes: > The Windows build is broken again. Here's the tail of the log > Yes, I opened a ticket (#13375) about this earlier. Running, "C:/msys64/home/ben/ghc/inplace/bin/ghc-pkg.exe" recache is sufficient to work around the issue it seems. Cheers, - Ben

Re: Windows build failing in a new way

Simon Peyton Jones via ghc-devs writes: > My windows build is more broken than usual. I can't even build a GHC. > Please, could someone fix this? I'm getting desperate. This is very odd; Harbormaster is also seeing it but I've been unable to reproduce locally. It seems that the libffi build is

Re: Windows build failing in a new way

Phyx writes: > My CI server is also reproducing it while I also haven't been able to > locally. Weird indeed. > Ahhh, I just noticed that Reid stumbled upon the culprit yesterday. See [1]. Cheers, - Ben [1] https://phabricator.haskell.org/rGHCe901ed1c5d66 signature.asc Description: PGP sign

RE: Windows build failing in a new way

loneti...@gmail.com writes: > Ah great, > > Triples again.. I still wonder why it is suddenly an issue. We haven’t > touched the .m4 file in a while and no one changed libffi either > right? This is just like last time the normalization bit us. Causing > days of broken builds on different targets

RE: Windows build failing in a new way

Ben Gamari writes: > loneti...@gmail.com writes: > >> Ah great, >> >> Triples again.. I still wonder why it is suddenly an issue. We haven’t >> touched the .m4 file in a while and no one changed libffi either >> right? This is just like last time the norm

Re: New commits

Simon Peyton Jones via ghc-devs writes: > Edward, Ben, others > I have just pushed a patch series > > 2209d5e6 Comments only > > 4eeb3273 Drop redundant import > > 2d3cb34a Define TcSimplify.simplifyTopImplic and use it > > af6ed4a6 Fix constraint simplification in rules > > 48d1866e Improve erro

Re: can't validate on Linux

Richard Eisenberg writes: > Hi devs, > > When I try validating my patch, validation fails with > >> ... >> Registering library for ghc-prim-0.5.0.0.. >> ghc-cabal: '/home/rae/ghc/ghc-valid/bindisttest/install >> dir/lib/ghc-8.3.20170312/bin/ghc-pkg' exited with an error: >> ghc-pkg: Couldn't open

Trac password change interface restored

Hello everyone, For the last few weeks Trac's password change functionality has been disabled due to passwords being leaked through the ghc-tickets mailing list. I have updated the Trac configuration to fix this leakage and reenabled this interface. Moreover, we shouldn't see any further email ad

Re: LLVM calling convention for AVX2 and AVX512 registers

Siddhanathan Shanmugam writes: >> It would be even better if we could *also* teach the native back end about > SSE instructions. Is there anyone who might be willing to work on that? > > Yes. Though, it would be better if someone with more experience than me > decides to pick this up instead. > I

Re: can't validate on Linux

Richard Eisenberg writes: > Hi devs, > > When I try validating my patch, validation fails with > >> ... >> Registering library for ghc-prim-0.5.0.0.. >> ghc-cabal: '/home/rae/ghc/ghc-valid/bindisttest/install >> dir/lib/ghc-8.3.20170312/bin/ghc-pkg' exited with an error: >> ghc-pkg: Couldn't open

Removing core-spec.pdf from repository?

Hello everyone, Currently there is a typeset copy of the Core specification in the GHC repository. This means any time someone changes the specification the repository grows by around 300kB. While this isn't the end of the world, it's generally considered bad form to put generated files under vers

Re: LLVM calling convention for AVX2 and AVX512 registers

Edward Kmett writes: > That, rather tangentially, reminds me: If we do start to teach the code > generator about how to produce these sorts of things from simpler parts, > e.g. via enabling something like LLVM's vectorization pass, or some > internal future ghc compiler pass that checks for, say,

Re: LLVM calling convention for AVX2 and AVX512 registers

Edward Kmett writes: > Hrmm. In C/C++ I can tell individual functions to turn on additional ISA > feature sets with compiler-specific __attribute__((target("avx2"))) tricks. > This avoids complains from the compiler when I call builtins that aren't > available at my current compilation feature le

Re: LLVM calling convention for AVX2 and AVX512 registers

Siddhanathan Shanmugam writes: >> I would be happy to advise if you would like to pick this up. > > Thanks Ben! > >> This would mean that Haskell libraries compiled with different flags >> would not be ABI compatible. > > Wait, can we not maintain ABI compatibility if we limit the target > featur

Re: LLVM calling convention for AVX2 and AVX512 registers

Edward Kmett writes: > Currently if you try to use a DoubleX4# and don't have AVX2 turned on, it > deliberately crashes out during code generation, no? I very well be missing something, but I don't believe this is true. This program compiles just fine with merely -fllvm -msse, {-# LANGUAGE

Re: LLVM calling convention for AVX2 and AVX512 registers

Carter Schonwald writes: > solution: lets call these registers what they are, instead of pretending > they're portable. we are not going to find the right abstraction in the > first go. lets not do that. first get it working sanely, then figure out > proper abstractions > I'm not sure I understan

Re: LLVM calling convention for AVX2 and AVX512 registers

It's a bit unclear from this comment whether this statement is a critique of a particular implementation strategy for adding SIMD support to the NCG or a more general reflection on SIMD interfaces. From your later messages I infer the latter in my response; feel free to disregard if I misinterprete

Re: LLVM calling convention for AVX2 and AVX512 registers

Carter Schonwald writes: > No matter *how* ghc ultimately bundles simd for high level > programming, it *will* have to bottom out into these target specific > operations at code gen time, and LLVM is *not* an abstraction for it. > I am very interested to hear what you mean by this; please do elab

Re: PSA: perf.haskell.org/ghc temporarily out of order

Joachim Breitner writes: > Hi, > > a recent change to nofib > (https://phabricator.haskell.org/rNOFIB313812d319e009d698bc1a4d2e8ac26d4dfe3c0a) > broke the perf.haskell.org builder, so we won’t be getting perf > warnings until that is fixed. > I've pushed the michalt's fix. Thanks for the quick tu

Re: Adding a module

Simon Peyton Jones via ghc-devs writes: > If you add a module to GHC, I know you need to extend ghc.cabal.in. But > also ghc.mk? Otherwise I get hits > > > If you add a module to GHC, I know you need to extend ghc.cabal.in. But > also ghc.mk? Otherwise I get hits > /usr/bin/ar: creating rts

Re: Why are there no Show instances for internal types

On March 18, 2017 9:03:48 AM EDT, Tom Sydney Kerckhove wrote: Snip. > >My questions for you: > >- Is there a reason that there are no derived 'Show' instances for most > types? As Richard mentioned, we don't derive Show due to code size and compilation time concerns. Show in particular is r

Re: Why are there no Show instances for internal types

Rahul Muttineni writes: > I think another way to go about this problem is to figure out an > alternative to baking in DynFlags to SDocContext (which I feel is the core > problem here). The only use of those DynFlags is via sdocWithDynFlags and > 94 call sites use them. > Indeed, I would love to s

Re: Stat too good

Simon Peyton Jones via ghc-devs writes: > Ben, > I still get these four stat-too-good "failures" on 64-bit Linux. > > Unexpected stat failures: > >/tmp/ghctest-ca0gfq/test spaces/./perf/compiler/T13035.run T13035 [stat > too good] (normal) > >/tmp/ghctest-ca0gfq/test spaces/./perf/c

Re: Why are there no Show instances for internal types

Tom Sydney Kerckhove writes: > On 19-03-17 02:08:56, Rahul Muttineni wrote: >> Syd, can you tell us what kind of things you were trying to print out? > > Maybe I wasn't very clear. > I'm trying to visualise the internal structure of some of the > typechecker's output. > I specifically do NOT need

Re: Building head on Openbsd

Karel Gardas writes: > On 03/26/17 04:54 PM, Sergei Trofimovich wrote: >> On Sun, 26 Mar 2017 15:08:50 +0200 >> Karel Gardas wrote: >> >>> On 03/26/17 03:04 PM, Sergei Trofimovich wrote: I guess openbsd does not have definition of EM_PPC64 (yet?). >>> >>> IIRC it does not. I even rememberin

Re: [commit: ghc] master: rts linker: Introduce MachOTypes (8ed29b5)

Moritz Angermann writes: > Hi Gabor, > > thanks! And sorry for causing trouble. I’ll look into the MachO > case. > Thanks for handling this Gabor and Moritz! Cheers, - Ben signature.asc Description: PGP signature ___ ghc-devs mailing list ghc-devs

GHC 8.2.1 status

Hello everyone, Here is your periodic release update. After a number of false-starts, the tree is finally approaching a releasable state. Last week I cut the ghc-8.2 branch and things have been stabilizing ever since. At this point we are waiting on only a couple more fixes before the rc1 source r

Re: GHC 8.2.1 status

George Colpitts writes: > Thanks Ben. When you have a chance it would be good to update the status > page wrt what we > will be getting, specifically will Backpack be in 8.2.1 > Hi George, I just reviewed the status page and cleaned a few

D3316 status

Hi Richard, It took me a bit longer than expected to get back to D3316 but I think I am now done. It wasn't quite as trivial as I thought it might be, so I thought I would summarize what was needed, 1. tcSplitTyConApp_maybe and tcRepSplitTyConApp_maybe have been moved from TcType to Type to

Re: Translation of GHC typechecker output to haskell-src-exts's 'Type'

Tom Sydney Kerckhove writes: > Dear GHC Devs, Hi Tom, > Because of the unwieldy nature of the data that the GHC type checker > outputs, I am trying to convert a GHC 'Type' [1] to a haskell-src-ext > 'Type' [2]. > > The translation does not need to be perfect for now, but I would at > least like

Re: Translation of GHC typechecker output to haskell-src-exts's 'Type'

Tom Sydney Kerckhove writes: > On 02-04-17 14:40:05, Tom Sydney Kerckhove wrote: >> Is there a way to access the types before this translation happens? >> It's okay if I have to assume that type-checking succeeds... > > I have found a way to do what I want, even after this translation. > It relie

Re: FW: [Haskell-cafe] [Call for Contributions] Haskell Communities and Activities Report, May 2017 edition (32nd edition)

Simon Peyton Jones via ghc-devs writes: > Ben > > Will you coordinate the GHC status report for HCAR? > Of course. > Everyone: please don’t leave Ben doing all the heavy lifting. He'll > sketch a structure but it's up to the rest of us to fill it in. These > six monthly reports are widely read,

GHC 8.2.1-rc1 source tarball availability

tl;dr: If you would like to produce a binary distribution for GHC 8.2.1-rc1 then let me know, grab the source distribution and start building. The binary distributions will be announced one week from today. Hello GHC packagers, I am happy to announce the release of the 8.2.1

Re: GHC 8.2.1-rc1 source tarball availability

Alan & Kim Zimmerman writes: > There is no tag in the source tree, which commit has been used? > As I mention in the message, I intentionally held off on pushing the tag to avoid the need to force push in case this commit ends up being bad. The tarball was produced from d67f0471cd3584c5a548ff30c9

Re: Windows 10 Creators Update will break GHC (Was FW: GHC on Windows 10 15019+)

Phyx writes: > We have discussed a few options on what to do, but haven't gotten a > conclusion/concensus yet. > Tamar and I have discussed this on IRC in the passed. I tend to agree that we will need to, at the very least, put out a new 8.0.2. I'm not sure about 7.10. Moreover, there is reported

Re: Windows 10 Creators Update will break GHC (Was FW: GHC on Windows 10 15019+)

Ryan Trinkle writes: > I would strongly urge that any new tarballs be released under new names, > and that the old tarballs be kept in place. Changing existing tarball URLs > silently causes breakage for Nix, and, I would imagine, for any other build > systems that are particularly concerned wit

Re: linux build broken

Simon Peyton Jones via ghc-devs writes: > My linux build is broken. See below. Help! All of this is due to the recent CPP cleanup, unfortunately. I think I will revert it for now and we can work out the issues elsewhere. Cheers, - Ben signature.asc Description: PGP signature __

Phabricator upgrade tonight

Unless someone objects I will be performing an upgrade of Phabricator tonight. I'll likely start around 23:00 EST (4:00 UTC). As usual, Phabricator may be down for anywhere from 10 minutes to a few hours, depending upon how things go. Cheers, - Ben signature.asc Description: PGP signature _

Re: Phabricator upgrade tonight

Ben Gamari writes: > Unless someone objects I will be performing an upgrade of Phabricator > tonight. I'll likely start around 23:00 EST (4:00 UTC). As usual, > Phabricator may be down for anywhere from 10 minutes to a few hours, > depending upon how things go. > As there h

Re: Phabricator upgrade tonight

Ben Gamari writes: > Ben Gamari writes: > >> Unless someone objects I will be performing an upgrade of Phabricator >> tonight. I'll likely start around 23:00 EST (4:00 UTC). As usual, >> Phabricator may be down for anywhere from 10 minutes to a few hours, &g

Re: testsuite not in GHC 8.2.1-rc1 source tarball ?

George Colpitts writes: > Thanks Brandon > > After downloading the source tarball and doing a build successfully I > wanted to run the testsuite. > You can indeed run the testsuite. However, note that the testsuite is not included in the "-src" tarball to keep the distribution size down. There i

Re: Where do I start if I would like help improve GHC compilation times?

Alfredo Di Napoli writes: > Hey folks, > Hi Alfredo! First, thanks for writing. More eyes looking at GHC's compiler performance is badly needed. > maybe I’m setting up for something too ambitious for me, but I would like > to take an active stance to the overlasting “GHC compilation times are >

Re: testsuite failures on Mac

Richard Eisenberg writes: > Hi devs, > > On today's HEAD, I built from a cleaned tree and then ran the > testsuite. How clean is clean? distclean? Cheers, - Ben signature.asc Description: PGP signature ___ ghc-devs mailing list ghc-devs@haskell.org

Re: testsuite failures on Mac

Richard Eisenberg writes: >> On Apr 7, 2017, at 3:27 PM, Ben Gamari wrote: >> >> How clean is clean? distclean? > > maintainer-clean. I never settle for anything less. :) > Hmm, that is quite peculiar. Harbormaster is currently behind master by three commits, bu

Re: testsuite not in GHC 8.2.1-rc1 source tarball ?

George Colpitts writes: > Are there any guidelines on how much memory is required to run the tests? > On my Mac I have 12 GB of RAM and a few hundred gigabytes of free disk > space. The first time I did > > >- make THREADS=4 test > > and I got a message > > >- Your system has run out of a

Re: testsuite not in GHC 8.2.1-rc1 source tarball ?

Erik de Castro Lopo writes: > Ben Gamari wrote: > >> Well, unfortunately one of the changes that just barely missesd the >> window for -rc1 was a fix to a rather serious memory leak in the compiler >> (#13426). > > Thats going to fixed for rc2? > Yes, the patch

[ANNOUNCE] GHC 8.2.1 release candidate 1

Hello everyone, The GHC team is very pleased to announce the first candidate of the 8.2.1 release of the Glasgow Haskell Compiler. Source and binary distributions are available at https://downloads.haskell.org/~ghc/8.2.1-rc1/ This is the first of a few release candidates leading up the fina

Re: [ANNOUNCE] GHC 8.2.1 release candidate 1

Phyx writes: > Hi Ben, > > The windows build is unusable. The settings file has $TopDir expanded and > hard-coded to the build path on drydock. > Hmm, this is very odd and sounds like a build system bug since I used the same scripts as usual to generate this bindist. I'll investigate. Cheers, -

Re: [ANNOUNCE] GHC 8.2.1 release candidate 1

"Boespflug, Mathieu" writes: > Hi Ben, > > this is great news! I'm particularly keen on learning more about two points > you mentioned in your email: > > * Compiler performance: do you have any numbers to quantify what 8.0 vs 8.2 > is likely to look like? I'm afraid the best I can provide at the

Re: [ANNOUNCE] GHC 8.2.1 release candidate 1

"Boespflug, Mathieu" writes: > Hi Ben, > > thank you for this summary. The DWARF status page is helpful. Something was > unclear to me though. There are three main potential use cases for DWARF > that I see: > > 1. debugging, possibly with gdb > 2. stack traces on exceptions > 3. stack sampling,

<    2   3   4   5   6   7   8   9   10   11   >