RE: Can't build on Windows

· I was using “sh validate”. Incidentally, does that still use validate.mk, are-validating.mk etc? Or is all that gone now, in which case if I want to modify the validate settings what do I do? · 32 vs 64 bit? How do I find out? I’m on a 64-bit processor, but for all I know

dll-split

It's just not my day. Now, on Linux, on my branch wip/spj-wildcard-refactor, I get a failure in dll-split! Should dll-split be running at all on Linux The output it produces is below. I'm totally stuck. Help desperately needed. Simon inplace/bin/dll-split

New error on linux

Clean build on HEAD on Linux is now giving a new error. Actual stderr output differs from expected: --- ./driver/T10970a.stderr.normalised2015-10-27 09:44:02.279188078 + +++ ./driver/T10970a.comp.stderr.normalised 2015-10-27 09:44:02.279188078 + @@ -1,6 +1,4 @@

Re: New error on linux

Simon Peyton Jones writes: > Clean build on HEAD on Linux is now giving a new error. > > Actual stderr output differs from expected: > > --- ./driver/T10970a.stderr.normalised2015-10-27 09:44:02.279188078 + > > +++ ./driver/T10970a.comp.stderr.normalised

RE: dll-split

Thanks. Indeed, in parallel, I randomly tried that and indeed it’s going again now. · But why is dll-split running at all on Linux? Ben says: “I believe dll-split is run to ensure that the module list remains consistent, even when developers are building on non-Windows platforms”.

Re: dll-split

I think you need to remove Ctype and Lexer from https://github.com/ghc/ghc/blob/master/compiler/ghc.mk#L498 On 27 Oct 2015 11:06 AM, "Simon Peyton Jones" wrote: > It’s just not my day. > > Now, on Linux, on my branch wip/spj-wildcard-refactor, I get a failure in >

RE: New error on linux

gcc 4.6.3 | -Original Message- | From: Ben Gamari [mailto:b...@smart-cactus.org] | Sent: 27 October 2015 10:31 | To: Simon Peyton Jones; ghc-devs@haskell.org | Subject: Re: New error on linux | | Simon Peyton Jones writes: | | > Clean build on HEAD on

Re: dll-split

Simon Peyton Jones writes: > It's just not my day. > Now, on Linux, on my branch wip/spj-wildcard-refactor, I get a failure > in dll-split! Should dll-split be running at all on Linux > I'm looking into it. Give me a few minutes. I believe dll-split is run to ensure

Re: dll-split

Alan & Kim Zimmerman writes: > I think you need to remove Ctype and Lexer from > https://github.com/ghc/ghc/blob/master/compiler/ghc.mk#L498 > Thanks Alan! That being said looking at the branch it's not entirely clear to me where this change came from. It doesn't appear

RE: New error on linux

Simon Peyton Jones writes: > gcc 4.6.3 > Alright, we'll need to figure out what to do about these differences. Cheers, - Ben signature.asc Description: PGP signature ___ ghc-devs mailing list ghc-devs@haskell.org

Doc warnings

I'm getting these warnings relating to the user manual. They seem non-fatal, but are alarming. Simon reading sources... [ 66%] ghc looking for now-outdated files... none found pickling environment... done checking consistency... /5playpen/simonpj/HEAD-2/docs/users_guide/ghc.rst:: WARNING:

RE: stg_upd_frame_info still broken

I'm pretty sure this error is being produced by ghc's own runtime linker, which has a built-in symbol table (essentially just a C array of structs of { "foo", }). This array is built from a bunch of macros such as SymI_HasProto(stg_upd_frame_info), which used to be present in rts/Linker.c but

RE: stg_upd_frame_info still broken

I'm sure it's the runtime linker. Static linking is fine. The symbol is defined in Updates.cmm, and is there in Updates.o, and in ghc-stage2.exe | -Original Message- | From: Ben Gamari [mailto:b...@well-typed.com] | Sent: 27 October 2015 14:47 | To: Simon Peyton Jones;

Re: stg_upd_frame_info still broken

On Tue, Oct 27, 2015 at 10:46 AM, Ben Gamari wrote: > Simon Peyton Jones writes: > > I cloned an entirely new GHC repository. > > Then 'sh validate'. > > Same result as before: any attempt to run GHCi fails with an unresolved > symbol. > > > > bash$

Re: Segfault in a CoreLinted program (and a GHC-generated Core question)

Didn't you know? Once the core-to-core passes are complete, a binary appears on disk by sheer magic. And magic is never wrong. Richard On Oct 27, 2015, at 10:28 AM, Joachim Breitner wrote: > Am Dienstag, den 27.10.2015, 09:44 -0400 schrieb Richard Eisenberg: >> Phew.

Re: stg_upd_frame_info still broken

I got lucky and found an error in the first place I looked. I have no way to test it, but I expect that https://phabricator.haskell.org/D1382 will fix the build on Windows, or at least make it closer to correct :) Regards, Reid On Tue, Oct 27, 2015 at 11:25 AM, Reid Barton

Re: stg_upd_frame_info still broken

Reid Barton writes: > I got lucky and found an error in the first place I looked. I have no way > to test it, but I expect that https://phabricator.haskell.org/D1382 will > fix the build on Windows, or at least make it closer to correct :) > I can test. Cheers, - Ben

Re: Segfault in a CoreLinted program (and a GHC-generated Core question)

Am Dienstag, den 27.10.2015, 10:41 -0400 schrieb Richard Eisenberg: > Didn't you know? Once the core-to-core passes are complete, a binary > appears on disk by sheer magic. And magic is never wrong. Ah, no, I didn’t. No wonder my feeble attempts to make the code generation for switches more

Re: stg_upd_frame_info still broken

Unfortunately the DYNAMIC_GHC_PROGRAMS=NO build on Linux did produce a working ghci, so I guess that leaves reviewing the likely culprit patch(es) very carefully... Regards, Reid Barton On Tue, Oct 27, 2015 at 10:57 AM, Simon Peyton Jones wrote: > I'm pretty sure this

RE: New error on linux

"Edward Z. Yang" writes: > OK fixed. > Thanks Edward! Cheers, - Ben signature.asc Description: PGP signature ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

RE: New error on linux

That's simple, we can just use ifdef to test for macro appearance. I'll commit a fix. Edward Excerpts from Ben Gamari's message of 2015-10-27 04:04:42 -0700: > Simon Peyton Jones writes: > > > gcc 4.6.3 > > > Alright, we'll need to figure out what to do about these

Re: Type-level error messages

Hello, On Thu, Oct 22, 2015 at 9:47 AM, Simon Peyton Jones wrote: > I’ve forgotten the state of your type-level error messages work. How’s it > going? > > I think we should try to add it to 8.0.1. The current status is that the > idea is implemented on a branch. Then,

RE: stg_upd_frame_info still broken

Well done Reid! That fixed it. Austin will commit it. Thanks for such timely help. You are a star Simon From: Reid Barton [mailto:rwbar...@gmail.com] Sent: 27 October 2015 15:54 To: Simon Peyton Jones Cc: Ben Gamari; ghc-devs@haskell.org Subject: Re: stg_upd_frame_info still broken I got

RE: Type-level error messages

Simon Peyton Jones writes: > I’ve forgotten the state of your type-level error messages work. How’s it > going? > > Iavor Diatchki writes: > > > I think we should try to add it to 8.0.1. The current status is that > > the idea is implemented

Re: Type-level error messages

Iavor Diatchki writes: > Hello, > Hello! Very good timing on the message; we just finished discussing your work not more than an hour ago. You can disregard my message; I didn't notice yours before sending it. > On Thu, Oct 22, 2015 at 9:47 AM, Simon Peyton Jones

RE: New error on linux

OK fixed. Edward Excerpts from Edward Z. Yang's message of 2015-10-27 10:36:36 -0700: > That's simple, we can just use ifdef to test for macro appearance. > I'll commit a fix. > > Edward > > Excerpts from Ben Gamari's message of 2015-10-27 04:04:42 -0700: > > Simon Peyton Jones

Re: Type-level error messages

Hi Ben, I updated the wiki page for GHC 8.0.1 to add an entry for the custom type errors (under "in flight, but likely to make it"). It shouldn't be a problem to make all changes needed by the end of November. Ther phabricator link is this: https://phabricator.haskell.org/D1236 The ticket is

unboundKey and fromIntegerClassOpKey unique overlap?

Hello everyone, I noticed while looking through PrelNames that unboundKey and fromIntegerClassOpKey appear to share a unique in the master branch. Is this safe/expected? Cheers, - Ben signature.asc Description: PGP signature ___ ghc-devs mailing

Re: Warning suppression pragmas

Hi Ben! I concreted some points in local warnings suppression pragmas wiki page with specification. https://ghc.haskell.org/trac/ghc/wiki/Design/LocalWarningPragmas Do you know something about defining custom pragmas in GHC? I suppose, i need to add it to the lexer and parser. In that case, how

Re: Type-level error messages

Hi Iavor, You can update your diff by using "arc diff --update D1236" Matt On Tue, Oct 27, 2015 at 8:48 PM, Iavor Diatchki wrote: > Hi Ben, > > I updated the wiki page for GHC 8.0.1 to add an entry for the custom type > errors (under "in flight, but likely to make

RE: Type-level error messages

It would be great to document some of these common workflows. Simon | -Original Message- | From: ghc-devs [mailto:ghc-devs-boun...@haskell.org] On Behalf Of Matthew | Pickering | Sent: 27 October 2015 21:10 | To: Iavor Diatchki | Cc: ghc-devs@haskell.org | Subject: Re: Type-level error

GADT decls

Ahh. I think I get it. The trouble is that ConDecl doesn’t have the same structure as what the user wrote. Maybe we should just fix that? How about this declaration? Would that make the annotations easier? Ie simple and routine. Simon data ConDecl name | ConDeclGADT { con_names

RE: unboundKey and fromIntegerClassOpKey unique overlap?

This is BAD. Do please fix! Thanks Simon | -Original Message- | From: ghc-devs [mailto:ghc-devs-boun...@haskell.org] On Behalf Of Ben Gamari | Sent: 27 October 2015 20:15 | To: GHC developers | Subject: unboundKey and fromIntegerClassOpKey unique overlap? | | Hello everyone, | | I

Re: Warning suppression pragmas

Эдгар Жаворонков writes: > Hi Ben! > > I concreted some points in local warnings suppression pragmas wiki page > with specification. Hello! Things are definitely improving! I still think you should be more explicit about the possible uses here. In particular, what

Re: Unlifted data types

Hello, I've added a section with my notes on the minimal semantics required to address what Haskell lacks with respect to strict types. Ed Kmett pointed me to some stuff that I think may fix all the problems with the !T sort of solution. It builds on the new constraint being considered for

Re: dns issues with ghc.haskell.org

> lennart spitzner writes: > I have not observed a failure of this kind for any other server. I don't > really know what could be the issue or how to diagnose this further. If it > helps, in this case (have not checked when this occurred previously): > "wrong"

Re: Unlifted data types

The idea of treating !S as a subtype of S and then relying on the potential for new impredicativity machinery to let us just talk about how !S <= S makes me really happy. data Nat = Z | S !Nat Pattern matching on S could give back the tighter type !Nat rather than Nat for the argument, and if we

Temporarily pinning a thread to a capability

Would anything go wrong with a thread id if I pinned it to a capability after the fact? I could in theory do so just by setting tso->flags |= TSO_LOCKED and then disabling this later by restoring the TSO flags. I can't think of anything but I figured folks here might be able to think of

Re: Segfault in a CoreLinted program (and a GHC-generated Core question)

Am Dienstag, den 27.10.2015, 09:44 -0400 schrieb Richard Eisenberg: > Phew. This was an alarming email! If a core-linted program segfaults, > there's either a bug in CoreLint or a bug in the theory behind GHC. > If it's the latter, someone will have an interesting paper to > write... :) ... or in

stg_upd_frame_info still broken

Friends I still cannot build GHC on Windows. On Ben's advice I dumped my current msys setup and re-installed msys64 as described here https://ghc.haskell.org/trac/ghc/wiki/Building/Preparation/Windows I cloned an entirely new GHC repository. Then 'sh validate'. Same result as before: any

Re: Doc warnings

Simon Peyton Jones writes: > I'm getting these warnings relating to the user manual. They seem non-fatal, > but are alarming. > Simon > > > reading sources... [ 66%] ghc > > > > looking for now-outdated files... none found > > pickling environment... done > > checking