RE: GHC perf

2020-01-22 Thread Simon Peyton Jones via ghc-devs
David Thanks. Concerning this: 1. Checkout an the commit. 2. Use `git status` to double check git sees a clean working tree. 3. Run the performance tests. 4. Check out your branch. 5. Use `git status` to double check git sees a clean working tree (else commit any changes) 6.

RE: Find constraints over type

2020-01-17 Thread Simon Peyton Jones via ghc-devs
Starting from any point in the typechecked syntax tree, you can look outwards to find binding sites for enclosing constraints, and then use whatever method you like to decide if they are relevant. Binding sites are: * ConPatOut; binds dictionaries from GADT matches * AbsBinds: abs_ev_va

RE: Windows testsuite failures

2020-01-17 Thread Simon Peyton Jones via ghc-devs
Both Tamar and Omer are right. * Not doing CI on Windows is bad. It means that bugs get introduced, and not discovered until later. This is Tamer’s point, and it is valid. * Holding up MRs because a failures in Windows CI that is unrelated to the MR is also bad. It a frustrating waste

RE: Find constraints over type

2020-01-16 Thread Simon Peyton Jones via ghc-devs
There is definitely no pure way to get from ‘a’ to its constraints. * It is far from clear what “its constraints” are. Is (C a b) such a constraint? C [a] b? What about superclasses? * Constraints vary depending on where you are. GADT matches can bring into scope extra constraints

GHC perf

2020-01-14 Thread Simon Peyton Jones via ghc-devs
Ben, David I'm still baffled by how to reliably get GHC perf metrics on my local machine. The wiki page https://gitlab.haskell.org/ghc/ghc/wikis/building/running-tests/performance-tests helps, but not enough! * There are two things going on: * CI perf measurements * Local mach

RE: Code generation/SRT question

2020-01-07 Thread Simon Peyton Jones via ghc-devs
| Close, I'm asking whether we should include a pointer to f in f's SRT | (when f is | recursive) when we're using f as the SRT (the [FUN] optimisation). Definitely not. Doing so would not change the set of reachable CAFs, would it? Simon | -Original Message- | From: Ömer Sinan Ağa

RE: Superclasses of type families returning constraints?

2020-01-06 Thread Simon Peyton Jones via ghc-devs
| In this case, in core, we receive an argument of type `F a b ~ ()`, and we | can force that to obtain a coercion of type `F a b ~# ()`. For reasons | similar to the mechanisms behind injective type families, that equality | really does imply `a ~# b`. Ah, I see a bit better now. So you want a w

RE: Code generation/SRT question

2020-01-06 Thread Simon Peyton Jones via ghc-devs
Aha, great. Well at least [Note SRTs] should point back to the wiki page. Omer's question is referring specifically to the [FUN] optimisation described in the Note. Hmm. So is he asking whether f’s SRT should have an entry for itself? No, that’ would be silly! It would not lead to any more C

RE: Code generation/SRT question

2020-01-06 Thread Simon Peyton Jones via ghc-devs
Omer, I think I’m not understanding all the details, but I have a clear “big picture”. Simon can correct me if I’m wrong. ·The info table for any closure (top-level or otherwise) has a (possibly empty) Static Reference Table, SRT. ·The SRT for an info table identifies the st

RE: Superclasses of type families returning constraints?

2020-01-06 Thread Simon Peyton Jones via ghc-devs
I've read this thread, superficially so far. But I'm puzzled about the goal. | type family F a b :: Constraint where | F a a = () | | eq :: F a b => a :~: b | eq = Refl This is rejected, and it's not in the least bit puzzling! You have evidence for (F a b) and you need to pro

RE: Perf metrics

2019-12-20 Thread Simon Peyton Jones via ghc-devs
: Ben Gamari | Sent: 19 December 2019 17:54 | To: Simon Peyton Jones ; ghc-devs@haskell.org | Subject: Re: Perf metrics | | Simon Peyton Jones via ghc-devs writes: | | > When I run `sh validate -legacy`, towards the end I see stuff like | this | > | > Performance Metrics (test

Perf metrics

2019-12-19 Thread Simon Peyton Jones via ghc-devs
When I run `sh validate -legacy`, towards the end I see stuff like this Performance Metrics (test environment: local): Conversions(normal) runtime/bytes allocated 107696.000 DeriveNull(normal)runtime/bytes allocated 112050960.000 Inli

RE: Total failure

2019-12-10 Thread Simon Peyton Jones via ghc-devs
i | Sent: 09 December 2019 17:20 | To: Simon Peyton Jones ; ghc-devs@haskell.org | Subject: Re: Total failure | | Simon Peyton Jones via ghc-devs writes: | | > Bad things are happening. I can't build GHC at all! | > I'm trying 'sh validate -fast' on a clean

RE: Running test with the stage-1 compiler

2019-12-09 Thread Simon Peyton Jones via ghc-devs
ones ; ghc-devs@haskell.org | Subject: Re: Running test with the stage-1 compiler | | Simon Peyton Jones via ghc-devs writes: | | > Apparently 'sh validate' now uses Hadrian. | > This has broken one of my workflows: | > | > * build the stage1 compiler | > * cd tes

RE: More failure

2019-12-09 Thread Simon Peyton Jones via ghc-devs
ct: Re: More failure | | Simon Peyton Jones via ghc-devs writes: | | > More pain. I said | > sh validate --fast --no-clean | > and got this output | > | > Error when running Shake build system: | > | > at action, called at src/Rules.hs:71:19 in main:Rules | > | > at

More failure

2019-12-09 Thread Simon Peyton Jones via ghc-devs
More pain. I said sh validate --fast --no-clean and got this output Error when running Shake build system: at action, called at src/Rules.hs:71:19 in main:Rules at need, called at src/Rules.hs:93:5 in main:Rules * Depends on: _validatebuild/stage1/lib/package.conf.d/base-4.14.0.0.conf a

Total failure

2019-12-09 Thread Simon Peyton Jones via ghc-devs
Bad things are happening. I can't build GHC at all! I'm trying 'sh validate -fast' on a clean build of a master checkout HEAD detached at 3a96a0b6db (this is the master checkout from which !2276 branches off) But alas I get this Exit code: 1 Stderr: compiler/main/DynFlags.hs:323:0: error:

Running test with the stage-1 compiler

2019-12-09 Thread Simon Peyton Jones via ghc-devs
Apparently 'sh validate' now uses Hadrian. This has broken one of my workflows: * build the stage1 compiler * cd testsuite/tests * make stage=1 That is, run the testsuite with the stage-1 compile. (This often produces a small test case for a compiler crash, much easier than debugging

RE: re-engineering overloading and rebindable syntax

2019-12-05 Thread Simon Peyton Jones via ghc-devs
senberg | Sent: 05 December 2019 09:54 | To: Simon Peyton Jones via ghc-devs | Subject: re-engineering overloading and rebindable syntax | | Hi devs, | | I've recently discovered the `overloaded` package, which allows us to do | very clever things around overloading in a sourc

RE: new llvm IR callbr instruction useful for proc-point splitting?

2019-12-04 Thread Simon Peyton Jones via ghc-devs
Thanks Kavon. What news of CpsCall in LLVM? That seems crucial. I didn’t know of an effort to use a different SP register. I seriously doubt that, with GHC’s use of zillions of small, heap-allocated stacks that move around during GHC, we’ll be able to leverage profiling or debugging tools in

RE: Question about negative Integers

2019-11-15 Thread Simon Peyton Jones via ghc-devs
I'm not *at all* close to this, but what you say sounds sensible. What is the user-facing change you propose? Something about the behaviour of (Bits Integer)? If so, fly it past the Core Libraries Committee, but in concrete form: I propose to change X to Y. Simon | -Original Message-

gc.log file

2019-11-15 Thread Simon Peyton Jones via ghc-devs
Devs, I'm getting mysterious messages from git, below. I have no file gc.log in my tree. Also I have run 'git prune' but the message still occurs. Any ideas? Simon simonpj@MSRC-3645512:~/code/HEAD$ git push --force setsockopt IPV6_TCLASS 8: Operation not permitted: Counting objects: 34, done

RE: Proposed changes to merge request workflow

2019-11-08 Thread Simon Peyton Jones via ghc-devs
| If the maintainers are not willing to either review or find reviewers | for a new contributors patch | then it doesn't seem to me that a project wants or values new | contributors. Yes, that would be an unfortunate -- and indeed wrong -- impression to convey. Thanks for highlighting it. Y

Linking problem

2019-10-30 Thread Simon Peyton Jones via ghc-devs
Devs On the branch wip/inline-compulsory, I'm getting a strange link error: simonpj@MSRC-3645512:~/tmp$ ~/code/HEAD-2/inplace/bin/ghc-stage1 Hello.hs [1 of 1] Compiling Main ( Hello.hs, Hello.o ) Linking Hello ... /home/simonpj/code/HEAD-2/rts/dist/build/libHSrts.a(Updates.o):stg_bh

RE: Handling source locations in HsSyn via TTG

2019-10-28 Thread Simon Peyton Jones via ghc-devs
s citizens. Let’s say I | have `MyToolPass`, how would I write an instance of `WrapL` for it? | | - Vlad | | > On 28 Oct 2019, at 12:31, Simon Peyton Jones via ghc-devs wrote: | > | > Friends | > | > As you know | > | > • We are trying to use “Trees That Grow” (TTG) to mov

Handling source locations in HsSyn via TTG

2019-10-28 Thread Simon Peyton Jones via ghc-devs
Friends As you know * We are trying to use "Trees That Grow" (TTG) to move HsSyn towards a situation in which GHC is merely a client of a generic HsSyn data type that can be used by clients other than GHC. * One stic

RE: Debugging specialization

2019-10-25 Thread Simon Peyton Jones via ghc-devs
Hi Alexis | I am trying to understand why GHC is not specializing an imported | INLINABLE instance method, and the information provided by -ddump-spec - | Wall-missed-specialisations has not been enough to help me figure it out. | Is there some easy/well-trodden way that I could build GHC with

RE: How to navigate around the source tree?

2019-10-25 Thread Simon Peyton Jones via ghc-devs
I think there is at least something to be said for module names that are unique, mainly for the human interface. For example, I often say (in Notes or Gitlab comments) "In TcType.foo we see ...". Now I could say "In GHC.Hs.Typecheck.Type we see ..." but it's less convenient. I could take the

RE: Urgent: git problem

2019-10-23 Thread Simon Peyton Jones via ghc-devs
stale branches: ../rae/... can't be a directory if it's already a file! If that still doesn't work (if it tries to record new branches before deleting stale ones), you'd have to muck around in .git/refs/remotes and remove the files manually. On Wed, 23 Oct 2019, 18.29 Simon

RE: Urgent: git problem

2019-10-23 Thread Simon Peyton Jones via ghc-devs
an't entirely recall. | | On Wed, Oct 23, 2019 at 5:22 PM Simon Peyton Jones via ghc-devs | wrote: | > | > Aieee! All my GHC repos are failing with this. As a result I can’t | pull. What should I do? Thanks! | > | > Simon | > | > | > | > git pull | &g

RE: Urgent: git problem

2019-10-23 Thread Simon Peyton Jones via ghc-devs
a completely fresh clone seems ok. but that's a bit brutal From: ghc-devs On Behalf Of Simon Peyton Jones via ghc-devs Sent: 23 October 2019 17:22 To: ghc-devs Subject: Urgent: git problem Aieee! All my GHC repos are failing with this. As a result I can't pull. What s

Urgent: git problem

2019-10-23 Thread Simon Peyton Jones via ghc-devs
Aieee! All my GHC repos are failing with this. As a result I can't pull. What should I do? Thanks! Simon git pull error: cannot lock ref 'refs/remotes/origin/wip/rae/remove-tc-dep': 'refs/remotes/origin/wip/rae' exists; cannot create 'refs/remotes/origin/wip/rae/remove-tc-dep' >From gi

RE: atomicModifyMutVar2

2019-10-17 Thread Simon Peyton Jones via ghc-devs
What do you think about the version that takes a function as an argument, and is optimized for the case where that's a selector? In any case that would change the API etc and I think that’s a bridge too far for a tidy-up. Make a proposal if you like! Simon From: Carter Schonwald Sent: 17 Oct

RE: Help with debugging a batch mode (or type checker) bug

2019-10-15 Thread Simon Peyton Jones via ghc-devs
Great. Before you are done with this patch, let's make sure there is an overview Note to explain the big picture. Simon | -Original Message- | From: Ömer Sinan Ağacan | Sent: 15 October 2019 08:31 | To: Simon Peyton Jones | Cc: ghc-devs | Subject: Re: Help with debugging a batc

RE: atomicModifyMutVar2

2019-10-14 Thread Simon Peyton Jones via ghc-devs
OK. I propose: * To give atomicModieyMutVarOf# its proper type, with a pair, as in the proposal. * To do that I’ll fiddle with genprimopcode, to allow it to parse tuples as well as unboxed tuples; not hard. * This would disallow all this stuff about “any type that has a first fie

RE: Help with debugging a batch mode (or type checker) bug

2019-10-14 Thread Simon Peyton Jones via ghc-devs
In --make mode, after compiling module M, rather than serialising M.hi and the deserialising and typechecking it, we simply use the type environment generated by compiling M and put it into M's entry of the Home Package Table (HPT). But we have to take care to ensure that the IdInfo in that type

RE: atomicModifyMutVar2

2019-10-11 Thread Simon Peyton Jones via ghc-devs
e x in v `seq` (v,v)) or something like that. Is this right? At least this should be documented super-clearly. Simon From: ghc-devs On Behalf Of Simon Peyton Jones via ghc-devs Sent: 11 October 2019 17:56 To: David Feuer Cc: ghc-devs Subject: RE: atomicModifyMutVar2 The result doesn't

RE: atomicModifyMutVar2

2019-10-11 Thread Simon Peyton Jones via ghc-devs
The result doesn't have to be a pair. It can be a tuple of any size at all. Indeed, it can even be an arbitrary record type whose first pointer field has the appropriate type. I think that is 100.0% undocumented, in the code, or in the proposal. Are you sure this is a settled consensus among t

atomicModifyMutVar2

2019-10-11 Thread Simon Peyton Jones via ghc-devs
David I'm deeply puzzled atomicModifyMutVar2#. I have read the proposal, and the comments in primops.txt.pp (reproduced below). Question 1 I think the "real" type of atomicModifyMutVar2 is atomicMo

RE: Proposed changes to merge request workflow

2019-10-09 Thread Simon Peyton Jones via ghc-devs
| > Make it clear that it is the contributor's responsibility to identify | reviewers for their merge requests. | | Asking for reviews is one of the most frustrating parts of | contributing patches, even if you know who to ask! So I think the | maintainer's should be responsible for finding

RE: Should coercion binders (arguments or binders in patterns) be TyVars?

2019-10-06 Thread Simon Peyton Jones via ghc-devs
| Is this intentional? Yes, it's absolutely intentional. Consider this Core defn f :: forall a b. (a ~# b) -> Int f = /\a b. \(g :: a ~# b). error "urk" Now is `seq f True` equal to True, or to (error "urk"). Definitely the former. So we cannot and must not discard coercion lambda. Howe

RE: eqType modulo associated types?

2019-09-16 Thread Simon Peyton Jones via ghc-devs
Can you be more explicit? I think you are referring to Type.eqType in GHC itself? I think you might want to apply FamInstEnv.normaliseType first. Simon From: ghc-devs On Behalf Of Conal Elliott Sent: 16 September 2019 02:38 To: ghc-devs@haskell.org Subject: eqType modulo associated types? It

RE: New implementation for `ImpredicativeTypes`

2019-09-09 Thread Simon Peyton Jones via ghc-devs
Suppose Haskell did have existentials; Yes, I think that's an interesting thing to work on! I'm not sure what the implications would be. At very least we'd need to extend System FC (GHC's intermediate language) with existential types and the corresponding pack and unpack syntactic forms. I d

RE: New implementation for `ImpredicativeTypes`

2019-09-06 Thread Simon Peyton Jones via ghc-devs
I’m confused. Char does not have the type (forall a. Show a =>a), so our example is iill-typed in System F, never mind about type inference. Perhaps there’s a typo? I think you may have ment exists a. Show a => a which doesn’t exist in Haskell. You can write existentials with

RE: New implementation for `ImpredicativeTypes`

2019-09-05 Thread Simon Peyton Jones via ghc-devs
I update the MR Description to make the link more discoverable. S From: ghc-devs On Behalf Of Alejandro Serrano Mena Sent: 05 September 2019 09:30 To: GHC developers Subject: Re: New implementation for `ImpredicativeTypes` To follow up

RE: IntRep etc

2019-09-04 Thread Simon Peyton Jones via ghc-devs
You successfully persuaded me, in #17026, that getting rid of Int and IntRep in a platform-dependent way is very awkward to implement. My proposal, made in #17026 is: * Keep Int# distinct from Int32#, Int64# * Keep IntRep distinct from Int32Rep, Int64Rep. * Have primops to convert between Ints o

RE: Multiple configurations???

2019-09-03 Thread Simon Peyton Jones via ghc-devs
Git repo yet: Just a hunch, | look at the content of the .gitmodules file; maybe a bad Git merge caused | duplication of entries in that `.gitmodules` file | | On Mon, Sep 2, 2019 at 2:20 PM Simon Peyton Jones via ghc-devs wrote: | > | > I’m getting the message below on ‘g

IntRep etc

2019-09-02 Thread Simon Peyton Jones via ghc-devs
Omer, Ben There's a little cluster of tickets that it'd be really good to nail. * !1381/#16893: inline unsafeCoerce# in CorePrep * #17041: coercion safety in STG Lint * !1552: tidy up linting on unsafe coercions * #16964: definition of Int# * #17026: definition of IntRep They a

Multiple configurations???

2019-09-02 Thread Simon Peyton Jones via ghc-devs
I'm getting the message below on 'git fetch'. Should I worry? Simon simonpj@MSRC-3645512:~/code/HEAD$ git fetch setsockopt IPV6_TCLASS 8: Operation not permitted: remote: Enumerating objects: 163, done. remote: Counting objects: 100% (163/163), done. remote: Compressing objects: 100% (78/78)

RE: Getting a hole's relevant local binds?

2019-08-29 Thread Simon Peyton Jones via ghc-devs
Simon, my reasoning here is that holes are the only place GHC will mention relevant bindings. I'd definitely prefer to put all of the relevant local bindings in scope for _every_ HsVar, but that seemed less amenable to being merged :) I didn’t explain myself well enough. No need to merge anyth

RE: Getting a hole's relevant local binds?

2019-08-28 Thread Simon Peyton Jones via ghc-devs
how receptive would y'all be to a patch that puts the `TcLclEnv`, or something similar inside `XUnboundVar GhcTc`. That sounds plausible. But is an unbound-var the only place an editor/IDE tooling might want to get its hands on such a thing? ie would that solve your problem, but not the nex

RE: A few questions about BuiltInSynFamily/CoAxiomRules

2019-08-28 Thread Simon Peyton Jones via ghc-devs
Thanks Iavor for your reply -- all correct I think. Re | This is the basic idea, but axioms are encoded in a slightly different | way---instead of being parameterized by just types, they are | parameterized by equalities (the reason for this is what I seem to have | forgotten, or perhaps it

RE: Typechecker plugins and BuiltInSynFamily

2019-08-23 Thread Simon Peyton Jones via ghc-devs
Alexis What you suggest sounds like an excellent idea. For some plugins, being able to extend the range of “built in” families might be all the plugin needs to do! (For others it might need to do some solving too.) I’ve thought a bit about how to achieve this: * The most direct thing wo

Haskell implementors workshop

2019-08-19 Thread Simon Peyton Jones via ghc-devs
Colleagues At the Haskell Implementors Workshop on Friday there is a 23-min slot for an update on GHC status. It's followed by panel discussion. In our annual status reports I have typically summarised what is going on with a few slides. But as GHC grows, and more people contribute, it gets har

RE: Properly writing typechecker plugins

2019-08-02 Thread Simon Peyton Jones via ghc-devs
. I went looking in the GHC source, only to discover that you, Simon, are apparently deeply suspicious

RE: Properly writing typechecker plugins

2019-08-01 Thread Simon Peyton Jones via ghc-devs
Alexis Thanks for writing this up so carefully. I hope that others will join in. And please then put the distilled thought onto the wiki page(s) so they are not lost. Some quick thoughts from me: * Flattening. I’m pretty sure we pass constraints unflattened because that’s what someon

RE: gitlab subject lines

2019-07-23 Thread Simon Peyton Jones via ghc-devs
m: ghc-devs On Behalf Of Richard | Eisenberg | Sent: 22 July 2019 18:29 | To: Ben Gamari | Cc: Simon Peyton Jones via ghc-devs | Subject: gitlab subject lines | | Hi Ben, | | Since the recent GitLab upgrade, all GitLab emails have "GHC | Glasgow | Haskell Compiler | " pr

RE: What's preventing inlining GHC.Magic.lazy?

2019-07-17 Thread Simon Peyton Jones via ghc-devs
Several points. 1. In GHC.Magic, the comments on lazyId say -- Implementation note: its strictness and unfolding are over-ridden -- by the definition in MkId.hs; in both cases to nothing at all. -- That way, 'lazy' does not get inlined, and the strictness analyser -- sees it as lazy. Then the wor

Gitlab wiki

2019-07-09 Thread Simon Peyton Jones via ghc-devs
I'm looking at a GHC wiki page: https://gitlab.haskell.org/ghc/ghc/wikis/Developing-Hadrian Whenever looking at such a wiki page, the right hand third of my landscape screen is taken up with a mostly-blank menu. Can I hide it, so I can read the document more easily? As it is, I have large are

Test failures with -DDEBUG stage2

2019-07-08 Thread Simon Peyton Jones via ghc-devs
Devs Should I expect failures with a stage2 compiler built with -DDEBUG? I'd much prefer the answer to be "no". But I several failure Unexpected failures: deriving/should_compile/T11148.run T11148 [bad exit code (2)] (normal) indexed-types/should_compile/T11361.runT11361 [e

RE: Issue weight migration

2019-07-08 Thread Simon Peyton Jones via ghc-devs
Thanks Ben. Did we agree to have * 3 explicit labels (high, normal, low) * With absence of a label indicating "has not been assigned a priority" which you can also read as "needs triage". I would strongly prefer not to have "no label" = "low priority" as I described earlier Simon | --

RE: Gitlab workflow

2019-07-05 Thread Simon Peyton Jones via ghc-devs
s because B was merged into master | > | after A, not directly onto HEAD (as the original MR was). | > | | > | There is no option to change this status in the gitlab API. | > | | > | Cheers, | > | | > | Matt | > | | > | On Fri, Jul 5, 2019 at 8:38 AM Simon

RE: Gitlab workflow

2019-07-05 Thread Simon Peyton Jones via ghc-devs
t directly onto HEAD (as the original MR was). | | There is no option to change this status in the gitlab API. | | Cheers, | | Matt | | On Fri, Jul 5, 2019 at 8:38 AM Simon Peyton Jones via ghc-devs wrote: | > | > Ben | > | > Still trying to understand GitLab. Look at

Gitlab workflow

2019-07-05 Thread Simon Peyton Jones via ghc-devs
Ben Still trying to understand GitLab. Look at MR 1352 https://gitlab.haskell.org/ghc/ghc/merge_requests/1352 * It clearly says on the first page "The changes were not merged into master" * But lower down (at the end) it says "Merged in 80af..." What should I believe? Merged or not merg

RE: Weight field in issues too fine grained?

2019-07-02 Thread Simon Peyton Jones via ghc-devs
ect: RE: Weight field in issues too fine grained? | | Simon Peyton Jones via ghc-devs writes: | | > Hang on. | > | > | > * P::High would be category (1) | > | > * P::Low would be category (2) | > | > * No P::* label would imply categoy (3) | > | > Let's have P

RE: Weight field in issues too fine grained?

2019-07-02 Thread Simon Peyton Jones via ghc-devs
Hang on. | > * P::High would be category (1) | > * P::Low would be category (2) | > * No P::* label would imply categoy (3) Let's have P:High, P:Medium, P:Low, with no "P:" label meaning "no one has assigned it a priority yet". It's very important to be able to distinguish "no one has assign

RE: Weight field in issues too fine grained?

2019-07-02 Thread Simon Peyton Jones via ghc-devs
Omer's suggestion makes sense to me | -Original Message- | From: ghc-devs On Behalf Of Ömer Sinan | Agacan | Sent: 02 July 2019 07:05 | To: ghc-devs | Subject: Weight field in issues too fine grained? | | Hi, | | One of the problems I'm having when triaging is that I think th

User manual

2019-07-01 Thread Simon Peyton Jones via ghc-devs
I use this link to see the most up to date GHC user manual https://ghc.gitlab.haskell.org/ghc/doc/users_guide/index.html But I think I'm seeing on from 13 June. It's labelled as GHC 8.9.0.20190613 User's Guide How come it's so out of

RE: Guarded Impredicativity

2019-06-28 Thread Simon Peyton Jones via ghc-devs
Just to amplify: we are very interested to * Get some idea of whether anyone cares about impredicativity. If we added it to GHC, would you use it? Have you ever bumped up Haskell’s inability to instantiate a polymorphic function at a polytype. * Get some idea of whether the partic

RE: Cloning

2019-06-25 Thread Simon Peyton Jones via ghc-devs
HC's .gitsubmodules use relative paths. Why not make them absolute? -- Best wishes, Artem On Tue, 25 Jun 2019 at 11:52, Simon Peyton Jones via ghc-devs mailto:ghc-devs@haskell.org>> wrote: What is the right procedure for cloning from someone else’s repo. For example, I wanted to s

Cloning

2019-06-25 Thread Simon Peyton Jones via ghc-devs
What is the right procedure for cloning from someone else's repo. For example, I wanted to see what was going wrong for Tobias in #16615, so after some detective work I tried git clone --recursive g...@gitlab.haskell.org:tdammers/ghc.git tdammers but I got lots of errors: Cloning into '/home/simo

RE: StgRun and reserved C stack space

2019-06-24 Thread Simon Peyton Jones via ghc-devs
Perhaps Simon Marlow, or others, may be able to help? It would be good to capture the answers somewhere, perhaps in the GHC Commentary? https://gitlab.haskell.org/ghc/ghc/wikis/commentary Simon | -Original Message- | From: ghc-devs On Behalf Of Stefan Schulze | Frielinghaus | Sent: 22

RE: Typed hole improvements

2019-06-07 Thread Simon Peyton Jones via ghc-devs
The constraint solver can certainly simplify this to get b ~ y. Perhaps all that is needed is to call it? David: a small reproducer would be helpful. Mathias, yell if you need help. Simon From: ghc-devs On Behalf Of David Feuer Sent: 07 June 2019 18:37 To: GHC users ; ghc-devs Subject: Ty

RE: reviewing on GitLab

2019-06-06 Thread Simon Peyton Jones via ghc-devs
e the document with any new problems you have now uncovered. Simon | -Original Message- | From: ghc-devs On Behalf Of Richard | Eisenberg | Sent: 06 June 2019 20:34 | To: Simon Peyton Jones via ghc-devs | Subject: reviewing on GitLab | | Hi all, | | I've just reviewed !364, an

RE: Wiki markup

2019-06-04 Thread Simon Peyton Jones via ghc-devs
@haskell.org Subject: Re: Wiki markup Hi Simon, I think you can just indent the code block to achieve this. Ryan On Mon, Jun 3, 2019 at 12:46 PM Simon Peyton Jones via ghc-devs mailto:ghc-devs@haskell.org>> wrote: This is a GitLab wiki markup question. Suppose I want to have a bulleted li

setsockopt IPV2_TCLASS 8

2019-06-03 Thread Simon Peyton Jones via ghc-devs
I'm getting a lot of these messages from ssh when using git setsockopt IPV6_TCLASS 8: Operation not permitted: (Same thing when directly invoking ssh g...@gitlab.haskell.org) Should I worry? Simon ___ ghc-devs mailing lis

Wiki markup

2019-06-03 Thread Simon Peyton Jones via ghc-devs
This is a GitLab wiki markup question. Suppose I want to have a bulleted list, in which a single item has some text, then some laid-out code, then more text. I want the second blob of text to be indented as part of the bullet. Absent the laid-out code, indenting the second para 2 spaces seems to

RE: Pushing to gitlab.haskell.org

2019-06-03 Thread Simon Peyton Jones via ghc-devs
ct: Re: Pushing to gitlab.haskell.org | | You probably need to use the "git@" remote. | | g...@gitlab.haskell.org:ghc/ghc.git | | git remote set-url origin g...@gitlab.haskell.org:ghc/ghc.git | | | On Mon, Jun 3, 2019 at 3:04 PM Simon Peyton Jones via ghc-devs wrote: | >

Pushing to gitlab.haskell.org

2019-06-03 Thread Simon Peyton Jones via ghc-devs
Devs Suddenly I can't push to (a non-master branch on) gitlab.haskell.org. In .git/config I have [remote "origin"] url = https://gitlab.haskell.org/ghc/ghc fetch = +refs/heads/*:refs/remotes/origin/* [branch "master"] remote = origin merge = refs/heads/master An attempt to push leads

RE: should TcCanonical.rewriteEvidence preserve ctev_nosh?

2019-06-02 Thread Simon Peyton Jones via ghc-devs
Nick That looks outright wrong to me. Would you like to make a ticket for it? It should be easy to fix. I’m surprised it has not caused more trouble before now. Well spotted and well diagnosed! Simon From: ghc-devs On Behalf Of Nicolas Frisby Sent: 01 June 2019 04:24 To: ghc-devs@haskell.o

RE: search on GItlab

2019-05-31 Thread Simon Peyton Jones via ghc-devs
. | | Giorgio | | | Giorgio | | | | On Fri, 31 May 2019 at 16:19, Simon Peyton Jones via ghc-devs wrote: | > | > If I search in GitLab for “checkExpectedKind” I don’t fine #16635, which | clearly mentions that. | > | > Why not? | > | > Thanks | > | > Simon | > | >

RE: Cmm syntax page on wiki

2019-05-31 Thread Simon Peyton Jones via ghc-devs
Really good, thank you. Let's make sure it's discoverable. Perhaps from the commentary, in at least two places: The description of code generation: https://gitlab.haskell.org/ghc/ghc/wikis/commentary/compiler/code-gen The runtime system https://gitlab.haskell.org/ghc/ghc/wikis/commentary/rts

search on GItlab

2019-05-31 Thread Simon Peyton Jones via ghc-devs
If I search in GitLab for "checkExpectedKind" I don't fine #16635, which clearly mentions that. Why not? Thanks Simon ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

RE: Container type classes

2019-05-29 Thread Simon Peyton Jones via ghc-devs
| having a common pattern for naming the operations certainly seems | nice. I am ambivalent if we do this with a class, or just name the | operations the same way, and use the module system. This was my reaction too. Consistent naming, yes. Using a type class, when every invocation is at a s

RE: Clean build fails with make

2019-05-29 Thread Simon Peyton Jones via ghc-devs
ge the cleaning | stuff to actually fix the issue, but I am not sure how. | | Sorry for more disruption, | | John | | On Tue, May 28, 2019, at 5:56 PM, Ben Gamari wrote: | > Simon Peyton Jones via ghc-devs writes: | > | > > A 'sh validate` in a clean tree fails as below.

RE: newtype workers

2019-05-28 Thread Simon Peyton Jones via ghc-devs
| I'm working on unlifted newtypes. | | In MkId.mkDataConWorkId, I see | | > mkDataConWorkId wkr_name data_con | > | isNewTyCon tycon | > = mkGlobalId (DataConWrapId data_con) wkr_name wkr_ty nt_work_info | > | otherwise | > = mkGlobalId (DataConWorkId data_con) wkr_name wkr_ty a

Clean build fails with make

2019-05-28 Thread Simon Peyton Jones via ghc-devs
A 'sh validate` in a clean tree fails as below. Is that expected? That is, is validate dead? If so let's change the shell script to say "game over, just use Hadrian". Simon "inplace/bin/ghc-cabal" check libraries/ghc-prim "inplace/bin/ghc-cabal" configure libraries/ghc-prim dist-install --with-

RE: Processing MRs very slow?

2019-05-28 Thread Simon Peyton Jones via ghc-devs
David Ben writes (on #16586) @simonpj, in general GHC HQ sets the milestone during triage (which I did in this case; I only realized that Iavor had submitted an MR after I left the comment requesting that he set the milestone). Could you include this point in your workflow revisions? Simon Fr

RE: Processing MRs very slow?

2019-05-28 Thread Simon Peyton Jones via ghc-devs
This leave one loose end: /home is left almost empty I think /home can give a little overview of what’s on the wiki, including: * A copy of what’s in the side-bar, annotated with what’s in each bit. * A pointer to the title list for the wiki (which we auto-generate I think). I’m sure oth

RE: Bug or feature?

2019-05-21 Thread Simon Peyton Jones via ghc-devs
Ryan Scott Subject: Re: Bug or feature? On May 21, 2019, at 10:23 AM, Simon Peyton Jones via ghc-devs mailto:ghc-devs@haskell.org>> wrote: But (A) looks sound to me. I like (A). (B) makes me nervous, too. > A. An implication is considered to “bind local equalities” iff it has at > le

RE: Bug or feature?

2019-05-21 Thread Simon Peyton Jones via ghc-devs
Let me have a quick stab at Nick’s idea. Consider forall b[2]. (a ~ Int) => alpha[1] ~ Maybe a Then we don’t want to unify alpha := Maybe a, because an equally good way to solve the constraint would be alpha := Maybe Int. And constraints elsewhere might force one or the other

How to contribute a patch

2019-05-16 Thread Simon Peyton Jones via ghc-devs
Ben The "how to contribute a patch" page https://gitlab.haskell.org/ghc/ghc/wikis/working-conventions/fixing-bugs doesn't say anything about the process of actually getting it committed, notably: * Picking approvers * Assigning to Marge * Monitoring progress if it doesn't land withi

RE: clarification re Note [Deeper level on the left]

2019-05-16 Thread Simon Peyton Jones via ghc-devs
I'm wondering about the claim "and that can float out of the implication". The Note does go on to mention #15009 --- and I understand how that Wanted floats *with* #15009 --- but as written, it sounds like the Wanted could float even without #15009. Consider our example forall a[2]. b[1

RE: Question about Gitlab MR workflow.

2019-05-09 Thread Simon Peyton Jones via ghc-devs
Thanks. That page is one click from the "Working conventions" page which is listed in the sidebar. (I wonder if "Working conventions" is the right title?) The numbering of the "Contributing a patch" page is deeply strange. 1,2,1,1,1,2,3,4. | -Original Message- | From: ghc-devs On

RE: Old build system broken

2019-05-09 Thread Simon Peyton Jones via ghc-devs
en't kicked off yet today. Thanks, Tamar Sent from my Mobile On Wed, May 8, 2019, 16:24 Simon Peyton Jones via ghc-devs mailto:ghc-devs@haskell.org>> wrote: I know we are supposed to be using Hadrian now, but is the old build system supposed to be broken? A clean build fails with "i

RE: Website for viewing proposals

2019-05-09 Thread Simon Peyton Jones via ghc-devs
Interesting. How would it differ from what we have (i.e. github's RST viewer)? | -Original Message- | From: ghc-devs On Behalf Of Matthew | Pickering | Sent: 09 May 2019 09:40 | To: GHC developers | Subject: Website for viewing proposals | | Hi, | | It would be useful if the

RE: Question about Gitlab MR workflow.

2019-05-09 Thread Simon Peyton Jones via ghc-devs
It would be good to add this advice to our "how-to-contribute" pages. Simon | -Original Message- | From: ghc-devs On Behalf Of Ömer Sinan | Agacan | Sent: 09 May 2019 07:46 | To: Iavor Diatchki | Cc: ghc-devs | Subject: Re: Question about Gitlab MR workflow. | | Hi, | | >

Old build system broken

2019-05-08 Thread Simon Peyton Jones via ghc-devs
I know we are supposed to be using Hadrian now, but is the old build system supposed to be broken? A clean build fails with "inplace/bin/ghc-cabal" check libraries/ghc-prim "inplace/bin/ghc-cabal" configure libraries/ghc-prim dist-install --with-ghc="/home/simonpj/code/HEAD/inplace/bin/ghc-stag

RE: MR titles

2019-05-08 Thread Simon Peyton Jones via ghc-devs
our contributing guide at work, for the reasons you mentioned. Additionally it helps avoid the need to read the MR's contents (comments/code) before going into it, since reading relevant tickets is almost always something you want to do. Thanks On Wed, May 8, 2019, 4:51 AM Simon Peyton Jone

MR titles

2019-05-08 Thread Simon Peyton Jones via ghc-devs
Friends In this MR, Vlad includes the number of the ticket it fixes in the title of the MR. That is so helpful: * It links the MR back to the issue * And does so in large font (screen shot below) * And the link is clickable, even

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