- ghc-devs - Haskell.org

Re: Non-deterministic package IDs are really bad in 7.10
by Mateusz Kowalczyk 20 May '15

20 May '15

On 05/14/2015 05:43 PM, Joachim Breitner wrote: > Hi, > > Am Sonntag, den 10.05.2015, 19:39 +0100 schrieb Mateusz Kowalczyk: >> I'd like to bring some attention to ticket #4012 about non-determinism. >> As many of you may know, the nix package manager distributes binaries >> throughout its binary caches. The binaries are shared as long as the >> hash of some of their inputs matches: this means that we can end up with >> two of the same hashes of inputs but thanks to #4012 means that the >> actual contents can differ. You end up with machines with some packages >> built locally and some elsewhere and due to non-determinism, the GHC >> package IDs don't line up and everything is broken. > > is NixOS sensitive to changes in the build directory. Debian is, and > since 7.8 the build path creeps into the interface files and affects the > hash: https://bugs.debian.org/785282 > > But you probably are not, otherwise you’d have complained when 7.8 was > out, and not now :-) > > Greetings, > Joachim > Not a problem for nix, the paths are are calculated based on the derivation inputs. I don't want to go into details but if same expression goes in, same path comes out. If the path that comes out is different, you simply don't get to use it. More or less nix does ‘calculate the store path from this expression, check if it exists in binary caches and fetch it if it does, build if it does not’. So for us the store paths in the interface files would always be the same for the same inputs hence no problem there. -- Mateusz K.

3 4

Re: [commit: ghc] master: Refactor tuple constraints (ffc2150)
by Christiaan Baaij 20 May '15

20 May '15

Hi, This patch broke the ‘Binary’ instance for ‘IfaceType’ in ‘iface/IfaceType.hs’ Specifically, it changed: ``` put_ bh (IfaceLitTy n) = do { putByte bh 30; put_ bh n } ``` to: ``` put_ bh (IfaceLitTy n) = do { putByte bh 7; put_ bh n } ``` However, the ‘get’ definition was left as: ``` 30 -> do n <- get bh return (IfaceLitTy n) ``` I don’t know what’s preferable: - revert the definition of `put_`, - or update the `get` definition to `7` Regards, Christiaan > On 18 May 2015, at 14:45, git(a)git.haskell.org wrote: > > Repository : ssh://git@git.haskell.org/ghc > > On branch : master > Link : http://ghc.haskell.org/trac/ghc/changeset/ffc21506894c7887d3620423aaf86bc61… > >> --------------------------------------------------------------- > > commit ffc21506894c7887d3620423aaf86bc6113a1071 > Author: Simon Peyton Jones <simonpj(a)microsoft.com> > Date: Mon May 11 23:19:14 2015 +0100 > > Refactor tuple constraints > > Make tuple constraints be handled by a perfectly ordinary > type class, with the component constraints being the > superclasses: > class (c1, c2) => (c2, c2) > > This change was provoked by > > #10359 inability to re-use a given tuple > constraint as a whole > > #9858 confusion between term tuples > and constraint tuples > > but it's generally a very nice simplification. We get rid of > - In Type, the TuplePred constructor of PredTree, > and all the code that dealt with TuplePreds > - In TcEvidence, the constructors EvTupleMk, EvTupleSel > > See Note [How tuples work] in TysWiredIn. > > Of course, nothing is ever entirely simple. This one > proved quite fiddly. > > - I did quite a bit of renaming, which makes this patch > touch a lot of modules. In partiuclar tupleCon -> tupleDataCon. > > - I made constraint tuples known-key rather than wired-in. > This is different to boxed/unboxed tuples, but it proved > awkward to have all the superclass selectors wired-in. > Easier just to use the standard mechanims. > > - While I was fiddling with known-key names, I split the TH Name > definitions out of DsMeta into a new module THNames. That meant > that the known-key names can all be gathered in PrelInfo, without > causing module loops. > > - I found that the parser was parsing an import item like > T( .. ) > as a *data constructor* T, and then using setRdrNameSpace to > fix it. Stupid! So I changed the parser to parse a *type > constructor* T, which means less use of setRdrNameSpace. > > I also improved setRdrNameSpace to behave better on Exact Names. > Largely on priciple; I don't think it matters a lot. > > - When compiling a data type declaration for a wired-in thing like > tuples (,), or lists, we don't really need to look at the > declaration. We have the wired-in thing! And not doing so avoids > having to line up the uniques for data constructor workers etc. > See Note [Declarations for wired-in things] > > - I found that FunDeps.oclose wasn't taking superclasses into > account; easily fixed. > > - Some error message refactoring for invalid constraints in TcValidity > > - Haddock needs to absorb the change too; so there is a submodule update > > >> --------------------------------------------------------------- > > ffc21506894c7887d3620423aaf86bc6113a1071 > compiler/basicTypes/BasicTypes.hs | 21 +- > compiler/basicTypes/DataCon.hs | 1 - > compiler/basicTypes/RdrName.hs | 28 +- > compiler/basicTypes/Unique.hs | 28 +- > compiler/basicTypes/VarSet.hs | 23 +- > compiler/coreSyn/CoreLint.hs | 2 +- > compiler/coreSyn/MkCore.hs | 7 +- > compiler/coreSyn/PprCore.hs | 4 +- > compiler/deSugar/Check.hs | 2 +- > compiler/deSugar/DsArrows.hs | 2 +- > compiler/deSugar/DsBinds.hs | 25 +- > compiler/deSugar/DsCCall.hs | 6 +- > compiler/deSugar/DsExpr.hs | 5 +- > compiler/deSugar/DsMeta.hs | 840 +-------------------- > compiler/deSugar/Match.hs | 4 +- > compiler/ghc.cabal.in | 3 +- > compiler/ghci/RtClosureInspect.hs | 7 +- > compiler/hsSyn/Convert.hs | 4 +- > compiler/hsSyn/HsExpr.hs | 3 +- > compiler/hsSyn/HsPat.hs | 35 +- > compiler/hsSyn/HsTypes.hs | 2 +- > compiler/iface/BinIface.hs | 14 +- > compiler/iface/BuildTyCl.hs | 4 + > compiler/iface/IfaceSyn.hs | 9 +- > compiler/iface/IfaceType.hs | 154 ++-- > compiler/iface/TcIface.hs | 84 ++- > compiler/main/Constants.hs | 3 + > compiler/main/HscMain.hs | 11 +- > compiler/parser/Parser.y | 20 +- > compiler/parser/RdrHsSyn.hs | 164 +++- > compiler/prelude/PrelInfo.hs | 28 +- > compiler/prelude/PrelNames.hs | 17 - > compiler/prelude/PrelRules.hs | 6 +- > compiler/prelude/PrimOp.hs | 2 +- > compiler/prelude/THNames.hs | 836 ++++++++++++++++++++ > compiler/prelude/TysWiredIn.hs | 269 ++++--- > compiler/rename/RnEnv.hs | 1 + > compiler/rename/RnNames.hs | 42 +- > compiler/rename/RnSplice.hs | 6 +- > compiler/simplStg/UnariseStg.hs | 10 +- > compiler/specialise/Specialise.hs | 3 +- > compiler/stranal/WwLib.hs | 6 +- > compiler/typecheck/FunDeps.hs | 32 +- > compiler/typecheck/TcBinds.hs | 52 +- > compiler/typecheck/TcCanonical.hs | 32 - > compiler/typecheck/TcErrors.hs | 2 - > compiler/typecheck/TcEvidence.hs | 15 +- > compiler/typecheck/TcExpr.hs | 10 +- > compiler/typecheck/TcGenDeriv.hs | 15 +- > compiler/typecheck/TcHsSyn.hs | 5 +- > compiler/typecheck/TcHsType.hs | 15 +- > compiler/typecheck/TcInstDcls.hs | 4 +- > compiler/typecheck/TcInteract.hs | 11 +- > compiler/typecheck/TcMType.hs | 1 - > compiler/typecheck/TcPat.hs | 2 +- > compiler/typecheck/TcRnMonad.hs | 4 + > compiler/typecheck/TcSimplify.hs | 1 - > compiler/typecheck/TcSplice.hs | 2 +- > compiler/typecheck/TcTyClsDecls.hs | 20 +- > compiler/typecheck/TcType.hs | 3 - > compiler/typecheck/TcValidity.hs | 186 +++-- > compiler/types/TyCon.hs | 34 +- > compiler/types/Type.hs | 7 +- > compiler/types/TypeRep.hs | 11 +- > compiler/vectorise/Vectorise/Builtins/Base.hs | 2 +- > .../vectorise/Vectorise/Builtins/Initialise.hs | 2 +- > compiler/vectorise/Vectorise/Utils/Closure.hs | 4 +- > libraries/ghc-prim/GHC/Classes.hs | 44 +- > libraries/ghc-prim/GHC/Tuple.hs | 242 +++--- > libraries/ghc-prim/GHC/Types.hs | 2 +- > .../should_fail/NotRelaxedExamples.stderr | 17 +- > .../indexed-types/should_fail/TyFamUndec.stderr | 17 +- > testsuite/tests/module/all.T | 2 +- > testsuite/tests/module/mod89.hs | 2 + > testsuite/tests/module/mod89.stderr | 10 +- > .../tests/typecheck/should_fail/T9858a.stderr | 2 +- > .../tests/typecheck/should_fail/fd-loop.stderr | 12 +- > .../tests/typecheck/should_fail/tcfail108.stderr | 4 +- > .../tests/typecheck/should_fail/tcfail154.stderr | 6 +- > .../tests/typecheck/should_fail/tcfail157.stderr | 12 +- > .../tests/typecheck/should_fail/tcfail213.stderr | 4 +- > .../tests/typecheck/should_fail/tcfail214.stderr | 8 +- > .../tests/typecheck/should_fail/tcfail220.hsig | 1 - > .../tests/typecheck/should_fail/tcfail220.stderr | 8 - > utils/genprimopcode/Main.hs | 49 +- > utils/haddock | 2 +- > 86 files changed, 1985 insertions(+), 1672 deletions(-) > > Diff suppressed because of size. To see it, use: > > git diff-tree --root --patch-with-stat --no-color --find-copies-harder --ignore-space-at-eol --cc ffc21506894c7887d3620423aaf86bc6113a1071 > _______________________________________________ > ghc-commits mailing list > ghc-commits(a)haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-commits

2 1

RE: Some test data
by Tamar Christina 20 May '15

20 May '15

Hi Ben, I haven't noticed a target for ARM in the split script which is why it wasn't in my list. I'll check later but my guess if the ARM version of the compiler does not support obj-split. Cheers, TamarFrom: Ben Gamari Sent: ‎5/‎20/‎2015 14:38 To: Tamar Christina; GHC Subject: Re: Some test data Tamar Christina <lonetiger(a)gmail.com> writes: > Hi All, > > > I’m currently busy rewriting the GHC-split perl script into Haskell and require some for the platforms I don’t have at the moment. > > > I require an example file(s) for: > > - Apple Darwin > > - Sparc > > - PowerPC Linux > > - X86 Linux > > - X86_64 Linux > Is this to say that you have an ARM? If not I would be willing to do some testing once my hardware arrives (which may be a month or so sadly; it's currently drifting across the Atlantic). Cheers, - Ben

1 0

Some test data
by Tamar Christina 20 May '15

20 May '15

Hi All, I’m currently busy rewriting the GHC-split perl script into Haskell and require some for the platforms I don’t have at the moment. I require an example file(s) for: - Apple Darwin - Sparc - PowerPC Linux - X86 Linux - X86_64 Linux The test file I require can be generated using ghc -split-objs -keep-tmp-files -v <hs_file> and I’m looking for the file ending with .split_s (e.g. "R:\Temp\ghc1764_0\ghc1764_2.split_s") Any file of a non-trivial nature would be helpful. Thanks, Tamar

3 3

FFI problems on 64-bit Windows
by Yitzchak Gale 20 May '15

20 May '15

As I am sure many people have noticed, there is currently a serious problem with FFI on 64-bit Windows. It often happens that when you link in FFI against a standard DLL, the resulting application segfaults as soon as any function from the DLL is called. I experienced this problem with Bryan's text-icu library when I linked it against the standard Windows 64-bit DLLs provided by the ICU project. In this case, the workaround I found is to link instead against DLLs built using mingw-w64 and provided as part of MSYS2: https://mail.haskell.org/pipermail/haskell-cafe/2015-May/119737.html On reddit, /u/awson (is that Kyra?) pointed out that this issue is probably caused by a serious bug in GNU binutils that was fixed about two months ago: https://sourceware.org/bugzilla/show_bug.cgi?id=16598 Is it possible to update the MSYS2/mingw-w64 toolchain used by GHC to a recent version that includes this fix? Thanks, Yitz

1 0

GHC Trac slow again
by Simon Peyton Jones 20 May '15

20 May '15

Herbert Did you manage to fix your Trac re-initialiser? Trac is soul-destroyingly slow today Simon

2 1

Interactions between type-checker plugins
by Christiaan Baaij 19 May '15

19 May '15

Hi, My apologies for this rather lengthy email. I have a question about how type-checker plugins should interact. My situation is the following: I have two type-checker plugins, one that can solve equalities involving the standard type-level operations on kind Nat (+,*,-,^), and another type-checker plugin that can prove equalities involving a new type-level operation GCD. In the following, the type-checker plugin involving the stand type-level operations is called ‘A’, and the type checker involving the new GCD operations is called ‘B’. When type-checker plugin A encounters: [W] GCD 6 8 + x ~ x + GCD 9 6 It knows that (+) is commutative, so it can prove the above equality _given_ that "GCD 6 8 ~ GCD 9 6” holds. So what type-checker plugin A does now is emits a new wanted constraints: [W] GCD 6 8 ~ GCD 9 6 And remembers that it emitted this wanted constraint. In type-checker plugin lingo, it returns: TcPluginOk [] ["[W] GCD 6 8 ~ GCD 9 6”] Now whenever type-checker plugin encounters [W] GCD 6 8 + x ~ x + GCD 9 6 again, it checks to see if the discharged constraint [W] GCD 6 8 ~ GCD 9 6 Is already solved, is disproven, or unsolved. If the discharged constraint is solved, it will return: TcPluginOk ["[W] GCD 6 8 + x ~ x + GCD 9 6”] [] If the discharged constraint is dis proven, it returns: TcPluginContradiction ["[W] GCD 6 8 + x ~ x + GCD 9 6”] And otherwise, it doesn’t do anything: TcPluginOk [] [] Now, type-checker plugin B, the one that knows about GCD, comes along. It sees: [W] GCD 6 8 + x ~ x + GCD 9 6 [W] GCD 6 8 ~ GCD 9 6 I doesn’t know anything about (+); but it does know about GCD, and clearly sees that GCD 6 8 is not equal to GCD 9 6. So it tells that GCD 6 8 ~ GCD 9 6 is insoluble. In type-checker plugin lingo it says: TcPluginContradiction ["[W] GCD 6 8 ~ GCD 9 6”] According to https://github.com/ghc/ghc/blob/228ddb95ee137e7cef02dcfe2521233892dd61e0/co… What happens next is that the insoluble constraint [W] GCD 6 8 ~ GCD 9 6 is taken of the work list for all plugins. However! the same thing happens when a plugin is able to prove a constraint. That is, if B would have (erroneously) returned: TcPluginOk ["[W] GCD 6 8 ~ GCD 9 6”] [] Then there is _no_ way for type-checker plugin A to know what happened. Were its discharged constraints taken from the work-list because it was insoluble? or because it was solved? This is a problem because to me it seems that the work list is the only way that two type-checker plugins can communicate. I guess my question is: if not through the work list, how are type-checker plugins supposed to communicate? Am I going about it all wrong in terms how I should be writing type-checker plugins? Or, should the type of ‘TcPluginSolver’ (https://downloads.haskell.org/~ghc/7.10.1/docs/html/libraries/ghc-7.10.1/Tc…) be updated to?: ``` type TcPluginSolver = [Ct] -- ^ Given constraints -> [Ct] -- ^ Derived constraints -> [Ct] -- ^ Wanted constraints -> [Ct] -- ^ Insoluble constraints -> TcPluginM TcPluginResult ``` Best regards, Christiaan

2 1

Re: [Haskell-cafe] RFC: "Native -XCPP" Proposal
by Malcolm Wallace 19 May '15

19 May '15

Exactly. My post was an attempt to elicit response from anyone to whom it matters. There is no point in worrying about hypothetical licensing problems - let's hear about the real ones. Regards, Malcolm On 7 May 2015, at 22:15, Tomas Carnecky wrote: > That doesn't mean those people don't exist. Maybe they do but are too afraid to speak up (due to corporate policy or whatever). > > On Thu, May 7, 2015 at 10:41 PM, Malcolm Wallace <malcolm.wallace(a)me.com> wrote: > I also note that in this discussion, so far not a single person has said that the cpphs licence would actually be a problem for them. > > Regards, > Malcolm > > On 7 May 2015, at 20:54, Herbert Valerio Riedel wrote: > > > On 2015-05-06 at 13:38:16 +0200, Jan Stolarek wrote: > > > > [...] > > > >> Regarding licensing issues: perhaps we should simply ask Malcolm > >> Wallace if he would consider changing the license for the sake of GHC? > >> Or perhaps he could grant a custom-tailored license to the GHC > >> project? After all, the project page [1] says: " If that's a problem > >> for you, contact me to make other arrangements." > > > > Fyi, Neil talked to him[1]: > > > > | I talked to Malcolm. His contention is that it doesn't actually change > > | the license of the ghc package. As such, it's just a single extra > > | license to add to a directory full of licenses, which is no big deal. > > > > > > [1]: http://www.reddit.com/r/haskell/comments/351pur/rfc_native_xcpp_for_ghc_pro… > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe(a)haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >

5 6

Re: [Haskell-cafe] RFC: "Native -XCPP" Proposal
by malcolm.wallace 19 May '15

19 May '15

How does your company deal with the Integer type, whose standard implementation in ghc is via the LGPL'd Gnu multi-precision routines? Regards, Malcolm On 18 May, 2015,at 09:19 PM, Lars Kuhtz <haskell(a)kuhtz.eu> wrote: I work for PivotCloud. We use Haskell/GHC in our production system on the server side and on the client side. My experience is that any license that contains the string "GPL" can cause problems in an corporate context, no matter if it actually is a legal issue or not. Folks who are responsible for making decisions about legal implications of the usage of third party software don't always have experience with open source software. Also they are often not familiar with the technical details of "derived work", different types of linking, or the subtleties of distinguishing between build-, link-, and run-time dependencies in modern software engineering pipelines. So, any mentioning of "LGPL" (or similar) potentially causes overhead in the adaption. Regards, Lars On 5/7/15 11:10 PM, Malcolm Wallace wrote: Exactly. My post was an attempt to elicit response from anyone to whom it matters. There is no point in worrying about hypothetical licensing problems - let's hear about the real ones. Regards, Malcolm On 7 May 2015, at 22:15, Tomas Carnecky wrote: That doesn't mean those people don't exist. Maybe they do but are too afraid to speak up (due to corporate policy or whatever). On Thu, May 7, 2015 at 10:41 PM, Malcolm Wallace <malcolm.wallace(a)me.com> wrote: I also note that in this discussion, so far not a single person has said that the cpphs licence would actually be a problem for them. Regards, Malcolm On 7 May 2015, at 20:54, Herbert Valerio Riedel wrote: On 2015-05-06 at 13:38:16 +0200, Jan Stolarek wrote: [...] Regarding licensing issues: perhaps we should simply ask Malcolm Wallace if he would consider changing the license for the sake of GHC? Or perhaps he could grant a custom-tailored license to the GHC project? After all, the project page [1] says: " If that's a problem for you, contact me to make other arrangements." Fyi, Neil talked to him[1]: | I talked to Malcolm. His contention is that it doesn't actually change | the license of the ghc package. As such, it's just a single extra | license to add to a directory full of licenses, which is no big deal. [1]: http://www.reddit.com/r/haskell/comments/351pur/rfc_native_xcpp_for_ghc_pro… _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe(a)haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe _______________________________________________ ghc-devs mailing list ghc-devs(a)haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs _______________________________________________ ghc-devs mailing list ghc-devs(a)haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

2 1

RE: [Diffusion] [Build Failed] rGHCfc8c5e7a5168: Test Trac #8799, #8555
by Simon Peyton Jones 19 May '15

19 May '15

Devs, The failure seems to be for ghci.debugger/print007. I can't see the build log on Phabricator, so I can't see what went wrong. Works on my machine. I do see print007.stderr <no location info>: Warning: -O conflicts with --interactive; -O ignored. which seems odd. Why not fix the test? Simon | -----Original Message----- | From: noreply(a)phabricator.haskell.org | [mailto:noreply@phabricator.haskell.org] | Sent: 19 May 2015 12:20 | To: Simon Peyton Jones | Subject: [Diffusion] [Build Failed] rGHCfc8c5e7a5168: Test Trac #8799, | #8555 | | Harbormaster failed to build B4076: rGHCfc8c5e7a5168: Test Trac #8799, | #8555! | | USERS | simonpj (Author) | GHC - Testsuite (Auditor) | | COMMIT | https://phabricator.haskell.org/rGHCfc8c5e7a5168 | | EMAIL PREFERENCES | https://phabricator.haskell.org/settings/panel/emailpreferences/ | | To: simonpj, GHC - Testsuite

2 1