RE: Require -fexternal-interpreter support for future TH changes?

I’m ok with this. It would certainly be great not to support TWO mechanisms indefinitely. What are the disadvantages to committing to this path? Would anyone even notice? There are a lot of moving parts to the implementation, and I for one am utterly ignorant of how it all works. I would

RE: Require -fexternal-interpreter support for future TH changes?

It’s a great start, thanks Simon From: Simon Marlow [mailto:marlo...@gmail.com] Sent: 22 June 2016 12:32 To: Simon Peyton Jones Cc: ghc-devs@haskell.org Subject: Re: Require -fexternal-interpreter support for future TH changes? How's this?

RE: Inferring instance constraints with DeriveAnyClass

| forward scenarios. If there is a simple and easy-to-specify way to | infer the simple cases properly though, I am certainly not opposed to | it. I think there is a simple easy-to-specify way to infer /all/ cases! Simon | -Original Message- | From: Andres Löh

Simon's email classified as spam

Dear GHC devs/users This is another test to see if email from me, relayed via Haskell.org, ends up in your spam folder. Gershom thinks he’s fixed it (below). Can I trespass on your patience once more? Just let me know if this email ends up in your inbox or spam. Can you cc John and Gershom

RE: [commit: ghc] master: Accept new (lower) allocations for T7257 (15641b0)

Does anyone know what made T7257 better? Simon | -Original Message- | From: ghc-commits [mailto:ghc-commits-boun...@haskell.org] On Behalf Of | g...@git.haskell.org | Sent: 22 June 2016 22:08 | To: ghc-comm...@haskell.org | Subject: [commit: ghc] master: Accept new (lower) allocations

isInvisible

Richard I have just spent an hour plumbing the torrid swamp of binder visibility. There is bad naming confusion. We have · Visible · Specified · Invisible The function isVisible returns True for Visible and False otherwise. But isInvisible returns True for Invisible

RE: isInvisible

No. We can't use visible type application with Visible arguments. If they're Visible, then you don't need the @. Ah yes. How about * Required * Specified * Inferred A Required argument is just that: it must be provided at all call sites. A Specified argument is one whose order we know

RE: isInvisible

It’d be great if you could. I’m about to commit a patch, but it doesn’t affect this much. (It’s just that getting the patch right made me fall into the swamp) S From: Richard Eisenberg [mailto:e...@cis.upenn.edu] Sent: 23 June 2016 14:17 To: Simon Peyton Jones Cc:

RE: Testsuite cleaning

ticket/12112 for details. On Fri, Jun 24, 2016 at 10:26 AM, Ömer Sinan Ağacan <omeraga...@gmail.com<mailto:omeraga...@gmail.com>> wrote: I also realized this after a rebase I did yesterday. Should be a recent thing. 2016-06-24 7:58 GMT+00:00 Simon Peyton Jones via ghc-devs <ghc-

RE: [Diffusion] [Build Failed] rGHCbb84ee44e30e: Improve pretty-printing of Avail

These failures are odd. One is this change in T8761 which I'm sure is not my fault. I saw that simonmar did some hFlush thing -- could that be it? Simon +++ ./T8761.run/T8761.comp.stderr.normalised2016-06-24 15:00:22.975083533 +0100 @@ -1,3 +1,7 @@ +pattern Q1 x1_0 x2_1 x3_2 <- ((x1_0,

RE: Help on first ticket

Richard, did you get on ok? Simon | -Original Message- | From: ghc-devs [mailto:ghc-devs-boun...@haskell.org] On Behalf Of Ben | Gamari | Sent: 04 June 2016 23:20 | To: Richard Fung ; ghc-devs@haskell.org | Subject: Re: Help on first ticket | | Richard

Testsuite cleaning

Thomas During debugging I often compile a single test program ghc -c T1969.hs But the new testsuite setup doesn’t remove .hi and .o files before running a test, so make TEST=T1969 says bytes allocated value is too low: … Deviation T1969(normal) bytes allocated:

RE: Help on first ticket

Great. No rush. Yell if you need help. Simon From: Richard Fung [mailto:minesasec...@gmail.com] Sent: 24 June 2016 19:05 To: Simon Peyton Jones Cc: ghc-devs@haskell.org Subject: Re: Help on first ticket Hi Simon, I am making progress but slowly (I only have time to

RE: msys2 64 bit: help help!

Tamar Thank you! Yes, it's in c:/msys64 Since I wrote more odd things have happened. 1. I just left the machine for 10-15 mins and lo! the shell windows opened up. It just took a lng time. At this point, starting a new shell no longer took a long time. It all seemed to be working. 2.

RE: Request for feedback: deriving strategies syntax

Ryan I've been on holiday, and there's been a lot of traffic on this deriving-strategy thread. Would you like to send an email summarising the state of play. Eg * Current specification is here: ... * Patch is here: ... (complete?) * Unresolved issues? Ready to review? Thanks Simon |

RE: enumFromThenTo for Doubles

Sounds somewhat plausible. By all means give it a try. S -Original Message- From: ghc-devs [mailto:ghc-devs-boun...@haskell.org] On Behalf Of Andrew Farmer Sent: 10 August 2016 04:22 To: ghc-devs@haskell.org Subject: enumFromThenTo for Doubles Noticed this today: ghci> let xs =

RE: Windows build

Indeed – it works great now. Thank you! I have a working Windows build on my Surface Book. Hooray. Many thanks to everyone who helped. Simon From: ghc-devs [mailto:ghc-devs-boun...@haskell.org] On Behalf Of Phyx Sent: 09 July 2016 18:00 To: Simon Peyton Jones via ghc-devs <ghc-d

RE: [commit: ghc] wip/generics-flip: Flip around imports of GHC.Generics (cb12bdf)

I don’t object to this, but I suspect that it's just covering up some other bug. Simon -Original Message- From: ghc-commits [mailto:ghc-commits-boun...@haskell.org] On Behalf Of g...@git.haskell.org Sent: 18 July 2016 14:57 To: ghc-comm...@haskell.org Subject: [commit: ghc]

RE: Request for feedback: deriving strategies syntax

I'm not following all the details here, and I do not feel strongly about syntax; but I do hope that you'll update the wiki page to reflect the discussion. Thanks Simon -Original Message- From: ghc-devs [mailto:ghc-devs-boun...@haskell.org] On Behalf Of Ryan Scott Sent: 18 July 2016

RE: Parser changes for supporting top-level SCC annotations

Terrific! Is there a ticket? A wiki page with a specification? Simon | -Original Message- | From: ghc-devs [mailto:ghc-devs-boun...@haskell.org] On Behalf Of Ömer | Sinan Agacan | Sent: 19 July 2016 10:04 | To: ghc-devs | Subject: Re: Parser changes for

git.haskell.org slow

Is it my imagination or is git.haskell.org really slow at the moment? SImion ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

RE: Rethinking GHC's approach to managing proposals

Just to be clear: * We are actively seeking feedback about the proposal [4] below. It's not a fait-accompli. * You can join the dialogue by (a) replying to this email, (b) via the "Conversations" tab of [4], namely https://github.com/ghc-proposals/ghc-proposals/pull/1 Doubtless via

RE: msys2 64 bit: help help!

cutable that magit uses, to avoid the overhead of traversing the environment for each call? (M-x customize-var RET magit-git-executable RET) On Tue, Jun 28, 2016 at 2:51 PM Simon Peyton Jones via ghc-devs <ghc-devs@haskell.org<mailto:ghc-devs@haskell.org>> wrote: David, Tamar I

msys2 64 bit: help help!

Friends, esp Tamar, I am in happy possession of a new Surface Book, running Windows 10, which is delightful - except that I can't make the msys64 installation work, which is crucial for GHC. Can any of you help? *I install it from here:

Msys2 64: progress

Friends I want to thank everyone who has responded - very helpful! Thanks to your help I am making progress *I re-installed msys64 from scratch, this time following the instructions on the GHC wiki rather than the msys2 page. By doing update-core; then pacman -Su; then pacman -Su

RE: Msys2 64: progress

-devs-boun...@haskell.org] On Behalf Of loneti...@gmail.com Sent: 28 June 2016 22:19 To: Simon Peyton Jones via ghc-devs <ghc-devs@haskell.org>; David Macek <david.mace...@gmail.com>; ta...@zhox.com Cc: ghc-devs@haskell.org Subject: RE: Msys2 64: progress Hi Simon, You’re missing a

RE: Msys2 64: progress

@gmail.com<mailto:loneti...@gmail.com> Sent: 28 June 2016 22:19 To: Simon Peyton Jones via ghc-devs <ghc-devs@haskell.org<mailto:ghc-devs@haskell.org>>; David Macek <david.mace...@gmail.com<mailto:david.mace...@gmail.com>>; ta...@zhox.com<mailto:ta...@zhox.com> C

Windows is still broken

Simon, Windows is still broken. Do you want me to revert both patches, or will you? Simon "inplace/bin/ghc-stage1.exe" -optc-fno-stack-protector -optc-Wall -optc-Werror -optc-Wall -optc-Wextra -optc-Wstrict-prototypes -optc-Wmissing-prototypes -optc-Wmissing-declarations -optc-Winline

RE: [commit: ghc] master: Use deterministic maps for FamInstEnv (9858552)

| | -type FamInstEnv = UniqFM FamilyInstEnv -- Maps a family to its | instances | +type FamInstEnv = UniqDFM FamilyInstEnv -- Maps a family to its | +instances |-- See Note [FamInstEnv] Bartosz, could you add your comment from the commit (or variant thereof) as a comment to

RE: [Diffusion] [Committed] rCABAL2863a628f857: Add two local type signatures

I don't believe I made this commit, or the ones around it. Mysterious; I hope I'm not being impersonated! Simon From: nore...@phabricator.haskell.org [mailto:nore...@phabricator.haskell.org] Sent: 08 July 2016 20:43 To: Simon Peyton Jones Subject: [Diffusion]

Windows build

I've completed a successful build on my Surface Book! Thank you. One last glitch. I'm getting the validate failure bellow. No other test requires gcc in my path. GHC itself carefully navigates to its own private gcc. Do we really want this family of tests (half a dozen variants of T11223)

RE: Msys2 64: progress

com>; loneti...@gmail.com; | ghc-devs@haskell.org | Subject: Re: Msys2 64: progress | | On 30. 6. 2016 14:38, Simon Peyton Jones via ghc-devs wrote: | > BTW, during ./boot, I get a lot of errors like this. Should I | worry? | | > perl: warning: Setting locale failed. | > perl:

RE: Msys2 64: progress

appening? The Python version is 3.4.3. Thanks Simon From: ghc-devs [mailto:ghc-devs-boun...@haskell.org] On Behalf Of Simon Peyton Jones via ghc-devs Sent: 29 June 2016 12:08 To: loneti...@gmail.com Cc: ghc-devs@haskell.org Subject: RE: Msys2 64: progress Aha! That sounds very plausible.

RE: Msys2 64: progress

d installed on your system. perl: warning: Falling back to the standard locale ("C"). Booting libraries/integer-gmp/ perl: warning: Setting locale failed. perl: warning: Please check that your locale settings: From: ghc-devs [mailto:ghc-devs-boun...@haskell.org] On Behalf Of Simon Pe

Trac spam

If someone could kill this spate of Trac spam, it’d be great. Simon ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

RE: Msys2 64: progress

rectory '/c/code/HEAD/utils/checkUniques' /c/code/HEAD$ Any ideas about what might be happening? The Python version is 3.4.3. Thanks Simon From: ghc-devs [mailto:ghc-devs-boun...@haskell.org] On Behalf Of Simon Peyton Jones via ghc-devs Sent: 29 June 2016 12:08 To: loneti...@gmail.com<mai

RE: Linker.c broken

Let’s re-enable it. Or: how can I selectively re-enable it for in my validate.mk? From: ghc-devs [mailto:ghc-devs-boun...@haskell.org] On Behalf Of Phyx Sent: 04 July 2016 13:05 To: Erik de Castro Lopo ; ghc-devs Subject: Re: Linker.c broken There

RE: msys2 64 bit: help help!

David, Tamar Thanks for your help. I'm a bit further forward. | > 1. I just left the machine for 10-15 mins and lo! the shell windows | opened up. It just took a lng time. | | I could be something with Active Directory. Cygwin (upon which is | MSYS2 based) integrates with AD, but

RE: msys2 64 bit: help help!

p help! | | On 27. 6. 2016 23:33, Simon Peyton Jones via ghc-devs wrote: | > 1. I just left the machine for 10-15 mins and lo! the shell windows | opened up. It just took a lng time. | | I could be something with Active Directory. Cygwin (upon which is | MSYS2 based) integrate

RE: Msys2 64: progress

wnload x86_64 completes after 1 second, with no messages of any kind. What next?! Thanks Simon From: ghc-devs [mailto:ghc-devs-boun...@haskell.org] On Behalf Of loneti...@gmail.com<mailto:loneti...@gmail.com> Sent: 28 June 2016 22:19 To: Simon Peyton Jones via ghc-devs <ghc-devs@haskell.

RE: Linker.c broken

That was it. Simon M: would you care to fix? Or should I push a revert? Simon | -Original Message- | From: ghc-devs [mailto:ghc-devs-boun...@haskell.org] On Behalf Of | Edward Z. Yang | Sent: 02 July 2016 01:02 | To: ghc-devs | Subject: Re: Linker.c broken |

Linker.c broken

Aargh! Windows is broken /again/. Some mess-up in Linker.c. I have not yet tried reverting recent patches. Might someone fix please? It’s really helpful to validate on Windows when making RTS changes. Simon rts\Linker.c: In function 'ghci_find': rts\Linker.c:1482:52: error: error:

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

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 Typable Simon From: Richard Eisenberg

RE: Talkative Join points warning

Better still, figure out why it's happening and stop it happening. It shouldn't! S | -Original Message- | From: ghc-devs [mailto:ghc-devs-boun...@haskell.org] On Behalf Of Ben | Gamari | Sent: 02 February 2017 21:36 | To: Luke Maurer | Cc: ghc-devs@haskell.org

RE: Lazy ST vs concurrency

Huh. You are right. That’s horrible. OK, here’s another idea. Provide, applyOnce# :: (a->b) -> a -> b which behaves like applyOnce f x = f x but guarantees that any thunk (applyOnce# f x) will be evaluated with atomic eager black-holing. \(s :: State# s) -> let

RE: Lazy ST vs concurrency

If we could identify exactly the thunks we wanted to be atomic, then yes, that would be better than a whole-module solution. However I'm not sure how to do that - doing it on the basis of a free variable with State# type doesn't work if the State# is buried in a data structure or a function

RE: Join points revised

GHC devs: this join-point patch has been long in gestation, and I've reviewed it several times with Luke. I think it's ready to go, but if you have time to take a look, please do. The Wiki page https://ghc.haskell.org/trac/ghc/wiki/SequentCore Simon | -Original Message- | From:

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

1. Hold off on Constraint v Type until after the branch is cut. Good idea. I think that’d be OK. It’s no worse than the status quo. I’m MUCH more keen to get the TypeRep stuff in, because it has been in the works for nearly two years!! So let’s do 1-3 pronto.Who is acting there. Just

RE: Lazy ST vs concurrency

But what if GHC decided to add another thunk, e.g. Ugh. That is even more horrible. Clearly I’m not very good at thinking about this stuff. It smells wrong; we should find a simple, composable primitive that does the right thing. I’d like to leave some breadcrumbs of this thread, at very

RE: Handling of unlifted types

Suppose f1 :: forall (a :: TYPE LiftedPtrRep). a -> Closure f2 :: forall (a :: TYPE UnliftedPtrRep). a -> Closure f3 :: forall (a :: TYPE FloatRep). a -> Closure f3 takes its argument in a floating point register, whereas f1 and f2 take their arguments in a pointer register; so you can't

Master broken?

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: /tmp/ghctest-5_qx1p/test

RE: [Diffusion] [Build Failed] rGHCb8f58d79ee3e: Another improvement to SetLevels

https://phabricator.haskell.org/harbormaster/build/20383/ There's something very odd here. I got "stat too good" solidly, so I reduced the number. But Harbormaster consistently allocates more 6.6% more than my 64-bit machine. I have no idea why. I reported this some days ago. It only seems

RE: Panic from rewritableTyVarsOfType

| Typeable1.hs:22:5: error: | • Couldn't match kind ‘* -> (* -> *) -> (* -> *) -> * -> *’ | with ‘forall k. (* -> *) -> (k -> *) -> k -> *’ I still don't see why we end up equating a polykind with a kind. | Anyways, hopefully this will be resolved with the

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

Replying by email because I'm on a train. Simon Huh. Put otherwise, your point is this. Suppose we have the following kind for `(->)`: (->) :: forall v1 v2 r1 r2. TYPE v1 r1 -> TYPE v2 r2 -> Type To coerce from (C a -> Int) to (a -> Int) we'd have to cough up a coercion `g`: g

RE: Floating lazy primops

We should have this conversation on a ticket, perhaps #13027. | good at the time). Are there actually any primops with lifted arguments | where we *want* speculation? Perhaps the most important primop to | consider is seq#, which is I don't understand this question. comment:23 of #13027

RE: StablePtr / StableName ?

Add this conversation to #13165? From: ghc-devs [mailto:ghc-devs-boun...@haskell.org] On Behalf Of Simon Marlow Sent: 24 January 2017 09:38 To: Johannes Waldmann Cc: ghc-devs@haskell.org Subject: Re: StablePtr / StableName ? StableNames do use the RTS hash

RE: Constant functions and selectors make for interesting arguments

e | enough to fix this problem, but I suspect there's some way to fix it. | Fixing it in Functor deriving would be a start (I can look into that), | but fixing it in user code would be quite good too. | | On Monday, January 30, 2017 9:01:34 PM EST Simon Peyton Jones via ghc- | devs | wrote: | > Func

RE: Lazy ST vs concurrency

We don’t want to do this on a per-module basis do we, as -fatomic-eager-blackholing would suggest. Rather, on per-thunk basis, no? Which thunks, precisely? I think perhaps precisely thunks one of whose free variables has type (Sttate# s) for some s. These are thunks that consume a state

RE: Constant functions and selectors make for interesting arguments

Functions whose body is no bigger (by the inliner’s metrics) than the call are always inlined vigorously. So (\.-> k) replaces a call by a single variable. GHC will do that a lot. These ideas are best backed by use-cases where something good is not happening. Do you have some? Simon

RE: [commit: ghc] wip/discount-fv: Discount scrutinized free variables (fd9608e)

Alex Interesting. Care to give us any background on what you are working on? I've often thought about discounting for free vars. Do you have some compelling examples? (Also fine if you just want to noodle privately for now.) Simon | -Original Message- | From: ghc-commits

RE: [commit: ghc] wip/discount-fv: Discount scrutinized free variables (fd9608e)

Long story short: learning and experimenting how GHC works and eventually contribute my findings (if any). OK great! Let us know if you need help. Simon From: Alex Biehl [mailto:alex.bi...@gmail.com] Sent: 25 January 2017 10:32 To: Simon Peyton Jones Cc:

RE: [Diffusion] [Build Failed] rGHCb78fa759bfb4: Simplify and improve CSE

: ghc-devs [mailto:ghc-devs-boun...@haskell.org] On Behalf Of Simon Peyton Jones via ghc-devs Sent: 20 January 2017 17:46 To: ghc-devs@haskell.org Subject: RE: [Diffusion] [Build Failed] rGHCb78fa759bfb4: Simplify and improve CSE I'm sorry about all these Phab failures. I'm struggling with a

Time library broken

I'm getting this libraries/time/lib/Data/Time/Clock/Internal/SystemTime.hs:1:14: warning: [-Wtrustworthy-safe] 'Data.Time.Clock.Internal.SystemTime' is marked as Trustworthy but has been inferred as safe! | 1 | {-# LANGUAGE Trustworthy #-} | ^^^ Since I use

RE: Status of early-inline branch

It's ready to go. I'm just doing small deltas. Go for it; It's fine as-is. Anything else is just further progress. You can always put stuff up and I can plonk any further patches on top of whatever you finally commit. Anyway, go for it.. don't wait for me. And tell me if I'm getting in the

RE: Windows build broken

n't branched yet for 8.2 On Wed, 22 Feb 2017, 14:09 Simon Peyton Jones via ghc-devs, <ghc-devs@haskell.org<mailto:ghc-devs@haskell.org>> wrote: Please please please could some one fix this? On windows. It’s frustrating being unable to build. Please please Simon libraries\time\lib\

RE: Windows build broken

now, it's not my ground to meddle in, but I just can't be calmly watching | this entirely preventable suffering.. | | Simon Peyton Jones via ghc-devs writes: | > Please please please could some one fix this? On windows. | > | > It’s frustrating being unable to build. | >

Superclasses

Edward In comment:23 of https://ghc.haskell.org/trac/ghc/ticket/11523 I claim that there is an infinite tower of superclasses, so that GHC can legitimately spin. You have not responded for nearly a year. Do you agree? Simon ___ ghc-devs mailing list

RE: Early inline

each of these submitted as a | separate differential *in order*? Or do you want a more complex mix-and- | match? | Also, are there any commits you think should be squashed? | | On Friday, February 17, 2017 4:41:33 PM EST Simon Peyton Jones via ghc- | devs | wrote: | > Ben, David, Reid | >

Trac #13255

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 strange testsuite errors. Here is one T2592: Heap

RE: Early inline

" phase, on the grounds that that's | what the programmer said.")? | | https://ghc.haskell.org/trac/ghc/ticket/12603#comment:30 | | | | On Fri, Feb 17, 2017 at 5:41 PM, Simon Peyton Jones via ghc-devs wrote: | > Ben, David, Reid | > | > I have been working for months (on

RE: Static data and RULES

The immediate problem today is with "S". The SCon wrapper could very well inline before the rule has a chance to fire. We'd like to be able to phase that inline to give it a chance. Yes that’s a problem today. It is orthogonal to the current thread. (As I happens I have fix in my tree.) The

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

| clearly points to this commit: | | commit fc9d152b058f21ab03986ea722d0c94688b9969f | Author: Simon Peyton Jones | Date: Thu Feb 16 09:41:55 2017 + | | Comments and tiny refactor only Crumbs! You are right! I have NO IDEA why this

RE: Static data and RULES

I don’t understand any of this. However, RULES are allowed to match on data constructors and it would be nice to let that keep happening. Why won’t it keep happening? What is the problem you are trying to solve? Why does the fast-path make it harder? Maybe open a ticket? Simon From:

RE: Datacon RULES test

NB: the actual ticket Trac #12689 is /not/ about rules /for/ data cons. It's about rules that /match/ datacons. It's only the latter I object to. The test T12689 sort of snuck in there under false pretences :-). Also I'm not permanently set against rules for datacons. It's just that I

RE: Trac #13255

I've just rebuilt that branch from scratch. I see Unexpected failures: /tmp/ghctest-q4hnbi/test spaces/./codeGen/should_run/cgrun057.run cgrun057 [bad stderr] (profasm) /tmp/ghctest-q4hnbi/test spaces/./profiling/should_run/T2592.run T2592 [bad stderr] (profasm)

Early inline

Ben, David, Reid I have been working for months (on and off, mostly off, but very ON for the last week or two) on a very simple idea: the simplifier should inline things even in the "gentle" phase. It seems so simple. And it is: the key patch is tiny. But it stressed corners of the optimiser

RE: Windows build broken

The package has been fixed already but the submodule hasn't been updated. For a quick fix just cd into libraries/time and checkout master. I was hesitant to push the new submodule since we hadn't branched yet for 8.2 On Wed, 22 Feb 2017, 14:09 Simon Peyton Jones via ghc-devs, <ghc-devs@haske

Windows build broken

Please please please could some one fix this? On windows. It's frustrating being unable to build. Please please Simon libraries\time\lib\Data\Time\Clock\Internal\SystemTime.hs:57:5: error: Not in scope: data constructorFILETIME Perhaps you meantWin32.FILETIME(imported from

RE: Trac

Firefox! | -Original Message- | From: Ben Gamari [mailto:b...@smart-cactus.org] | Sent: 13 February 2017 18:07 | To: Richard Eisenberg ; George Colpitts | | Cc: Simon Peyton Jones ; ghc-devs@haskell.org | Subject:

FW: [Diffusion] [Build Failed] rGHC6bab649bde65: Improve checking of joins in Core Lint

perf/haddock.base and haddock.Cabal have improved, hence failure here.. am building with HADDOCK_DOCS on. If someone else gets there first, be my guest From: nore...@phabricator.haskell.org [mailto:nore...@phabricator.haskell.org] Sent: 16 February 2017 16:08 To: Simon Peyton Jones

RE: Convincing GHC not to produce unfoldings during simplification

Yes, inl_act :: Activation controls what inlining takes place inl_inline :: InlineSpec says what the user originally wrote Perhaps I should beef up the comments. Simon | -Original Message- | From: ghc-devs [mailto:ghc-devs-boun...@haskell.org] On Behalf Of Ben | Gamari | Sent: 12

RE: Convincing GHC not to produce unfoldings during simplification

Can you tell me how to repro this? I can't. I tried module Foo( foo ) where {-# NOINLINE foo #-} foo = ("fred" , True, ('c', 'e')) And just as expected, I see foo in the interface file, but none of its components. Simon | -Original Message- | From: ghc-devs

Trac

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? Simon ___ ghc-devs mailing list ghc-devs@haskell.org

RE: Static data and RULES

{-# RULES "L" LCon1 0 = LCon2 Oh I missed this entirely. You want to write a rule FOR a data constructor I thought you just meant one that matches on a data constructor. That is you want (L 0) to rewrite, all by itself, to LCon2? That had never occurred to me as a possibility. Bizarre.

RE: Static data and RULES

PS: before we go to some effort to optimise X, can we · do some measurements to ensure that X is a problem · check that the problem with X doesn’t have an easy solution For example: · Make a big file with lots of static data · Compile it · Check

Type family bug?

Richard This works type family F (a :: k) type instance F Maybe = Char But this does not. Surely it should? type family F (a :: k) where -- = r | r -> a where F Maybe = Char The latter is rejected with Foo.hs:6:5: error: * Expecting one more argument to `Maybe' Expected kind

RE: Magical function to support reflection

David says that this paper is relevant http://okmij.org/ftp/Haskell/tr-15-04.pdf Simon From: David Feuer [mailto:david.fe...@gmail.com] Sent: 14 January 2017 00:50 To: Simon Peyton Jones Cc: ghc-devs ; Edward Kmett Subject: RE:

RE: Magical function to support reflection

To make the reflection library work in a fully type-safe manner would take 1-3 additional wired ins that would consist of well-typed core. The stuff David is proposing above would be more general but less safe. The approach I proposed below looks general, safe, and performant. Or not? To make

RE: Join points

All, Yes, do take a look at this. It’s a fairly direct implementation of the paper “Compiling without continuations”. You should definitely read the paper first; it’ll set the scene. I am really hoping

Windows build

Hi Tamar The current state of a clean Windows build has improved - but still has multiple failures. See below Thanks for your work on this. I can send more details if that'd be helpful Simon Unexpected failures: plugins/plugins07.run plugins07 [bad exit code] (normal)

RE: Magical function to support reflection

I've added some comments. I like ReflectableDF a lot. Simon | -Original Message- | From: David Feuer [mailto:da...@well-typed.com] | Sent: 19 January 2017 02:59 | To: ghc-devs@haskell.org; Simon Peyton Jones | Cc: Edward Kmett | Subject: Re:

Arc doesn't work

I can't use arc. At the end of 'arc diff' it says Exception Some linters failed: - CommandException: Command failed with error #1! COMMAND python3 .arc-linters/check-cpp.py 'compiler/basicTypes/Id.hs' STDOUT (empty) STDERR File

RE: [Diffusion] [Build Failed] rGHCb78fa759bfb4: Simplify and improve CSE

I'm sorry about all these Phab failures. I'm struggling with arc, and so committing directly. It all validates fine on my machine. They seem to be all about T1969. It validates fine on my machine. But only just! On my machine I get peak_megabytes = 64; but on Harbormaster it seems to be

RE: Arc doesn't work

about. | | Regards, | Reid Barton | | On Fri, Jan 20, 2017 at 10:50 AM, Simon Peyton Jones via ghc-devs wrote: | > I can’t use arc. At the end of ‘arc diff’ it says | > | > Exception | > | > Some linters failed: | > | > - CommandException: C

RE: [Diffusion] [Build Failed] rGHC5a9a1738023a: Refine exprOkForSpeculation

I'm sorry but I cannot make head or tail of the offending build log here. I validated from scratch at my end. Could it be a Harbormaster error? Simon From: nore...@phabricator.haskell.org [mailto:nore...@phabricator.haskell.org] Sent: 16 January 2017 16:52 To: Simon Peyton Jones

RE: Landing Backpack in HEAD

I'm supportive of doing this, and am working with Edward on it. Yell if you object. Simon | -Original Message- | From: ghc-devs [mailto:ghc-devs-boun...@haskell.org] On Behalf Of | Edward Z. Yang | Sent: 11 August 2016 20:07 | To: ghc-devs | Subject: Landing

RE: RdrName and decorations

I think it belongs in the HsSyn syntax tree. The RdrName for (say) Prelude.map is the same RdrName, whether or not it looks like `Prelude.map`. Simon From: ghc-devs [mailto:ghc-devs-boun...@haskell.org] On Behalf Of Alan & Kim Zimmerman Sent: 05 August 2016 14:40 To: ghc-devs@haskell.org

RE: SSH failing on Windows

| To: ghc-devs@haskell.org | Subject: Re: SSH failing on Windows | | Simon Peyton Jones via ghc-devs wrote: | | > | > But 'git push' says | > | > /c/code/HEAD$ git push | > | > Permission denied (publickey). | > | > fatal: Could not read from remote repository

Windows build broken

Windows build is broken again. Might someone fix? Simon "inplace/bin/ghc-stage1.exe" -optc-fno-stack-protector -optc-Wall -optc-Werror -optc-Wall -optc-Wextra -optc-Wstrict-prototypes -optc-Wmissing-prototypes -optc-Wmissing-declarations -optc-Winline -optc-Waggregate-return

cabal

I’m trying to follow the instructions for https://ghc.haskell.org/trac/ghc/ticket/12562 But I get cabal new-build llvm-general --with-ghc=/home/simonpj/5builds/HEAD-4/inplace/bin/ghc-stage2 cabal: unrecognised command: new-build (try --help) simonpj@cam-05-unx:~/tmp/llvm-general$ Maybe my

  1   2   3   4   5   6   7   8   9   10   >