- ghc-devs - Haskell.org

Failing ASSERT in ghci044 and ghci047
by Edward Z. Yang 01 Aug '14

01 Aug '14

CC'd Simon because you were touching these test-cases recently. You'll need to run with -DDEBUG, which is probably why validate didn't catch these. Maybe the ASSERT is out of date? =====> ghci044(ghci) 1719 of 4065 [0, 0, 0] [72/1822] cd ./ghci/scripts && HC='/home/hs01/ezyang/ghc-validate/inplace/bin/ghc-stage2' HC_OPTS='-dcore-lint - dcmm-lint -dno-debug-output -no-user-package-db -rtsopts -fno-ghci-history ' '/home/hs01/ezyang/ghc-va lidate/inplace/bin/ghc-stage2' --interactive -v0 -ignore-dot-ghci -dcore-lint -dcmm-lint -dno-debug-ou tput -no-user-package-db -rtsopts -fno-ghci-history <ghci044.script >ghci044.run.stdout 2>ghci044. run.stderr Actual stderr output differs from expected: --- ./ghci/scripts/ghci044.stderr 2014-07-31 11:00:16.433141666 -0700 +++ ./ghci/scripts/ghci044.run.stderr 2014-08-01 10:38:17.352234466 -0700 @@ -6,3 +6,12 @@ instance C a => C [a] -- Defined at <interactive>:8:10 In the expression: f [4 :: Int] In an equation for ‘it’: it = f [4 :: Int] +*** Exception: ASSERT failed! file compiler/ghci/Linker.lhs, line 907 +*** Exception: ASSERT failed! file compiler/ghci/Linker.lhs, line 907 +*** Exception: ASSERT failed! file compiler/ghci/Linker.lhs, line 907 +*** Exception: ASSERT failed! file compiler/ghci/Linker.lhs, line 907 + +<interactive>:15:1: + No instance for (C Bool) arising from a use of ‘f’ + In the expression: f [True] + In an equation for ‘it’: it = f [True] Actual stdout output differs from expected: =====> ghci047(ghci) 1723 of 4065 [0, 1, 0] cd ./ghci/scripts && HC='/home/hs01/ezyang/ghc-validate/inplace/bin/ghc-stage2' HC_OPTS='-dcore-lint - dcmm-lint -dno-debug-output -no-user-package-db -rtsopts -fno-ghci-history ' '/home/hs01/ezyang/ghc-va lidate/inplace/bin/ghc-stage2' --interactive -v0 -ignore-dot-ghci -dcore-lint -dcmm-lint -dno-debug-ou tput -no-user-package-db -rtsopts -fno-ghci-history <ghci047.script >ghci047.run.stdout 2>ghci047. run.stderr Actual stderr output Actual stderr output differs from expected: --- ./ghci/scripts/ghci047.stderr 2014-05-28 15:38:19.608946057 -0700 +++ ./ghci/scripts/ghci047.run.stderr 2014-08-01 10:38:17.658906746 -0700 @@ -1,16 +1,14 @@ +*** Exception: ASSERT failed! file compiler/ghci/Linker.lhs, line 907 +*** Exception: ASSERT failed! file compiler/ghci/Linker.lhs, line 907 Cheers, Edward --- End forwarded message ---

1 0

Changing the -package dependency resolution algorithm
by Edward Z. Yang 01 Aug '14

01 Aug '14

Right now, GHC has a very complex and hard to explain algorithm for picking packages from the package database when you give it a pile of -package/-package-id/-{hide,ignore,trust,distrust}-package flags. Roughly, it currently does something like this. 1. Concatenate all of the package databases into a giant list, with system packages first and then user packages later, removing duplicate entries with the same installed package ID (preferring later packages). Call this PACKAGES. 2. Take all the -package-id flags and compute their transitive closure (call this set P). 3. Calculate the set of shadowed packages--the set of installed packages for which there exists another package with the same package ID (foo-0.1) which is in P or is later in the package stack. 4. Calculate the set of ignored packages---the set of packages which match all -ignore-package flags 5. Filter out shadowed and ignored packages from the list of packages, calling the result ALL_PACKAGES. 6. Calculate the set of broken packages---the set of packages not contained in the least fixed point of the relation that takes a set of packages, and adds all packages whose dependencies are satisfied, from ALL_PACKAGES. 7. Process the package flags in order, operating on PACKAGES (not ALL_PACKAGES). For -package/-hide-package, take the package with the *latest* version that matches the flag and are not broken (since this includes shadowed packages, the result is unique) and toggle it to be exposed/unexposed, and hide all the other packages. For -trust-package/-distrust-package, toggle the trusted bit for all instances in the database. 8. If we have exposed multiple versions of the same package name, hide all the older versions What a mouthful! I have no idea, given a set of flags, how this works. So here is an alternate proposal for an alternate way of handling these flags *when starting from an empty database* (e.g. -hide-all-packages) Suppose we maintain a set of selected packages, which starts off empty. Process each package flag in turn. For -package and -package-id, get the set of installed packages which match the flag. (If multiple package names apply, process each in turn as if it were a separate flag.) Compute the transitive closure of dependencies for all of them, and filter out all choices which have dependencies which are inconsistent with the current set of selected packages. Consistency without multi-instances is a mapping of a package name to an installed package. If there is still more than one choice, tiebreak by version, which database and time of install. (The latter tiebreak should not be necessary until we allow multiple instances of a package with the same package ID.) For -hide-package, get the set of packages which match and hide them all; for -ignore-package, hide the transitive closure of dependencies of it. For -trust,distrust-package, toggle for all matching packages as before. Here are some differences in behavior between this and the previous scheme: - It's no longer valid to indirectly depend on two different versions of the same package. Most of the time, users didn't want this anyway. Note that the current scheme prevents directly depending on two different versions by shadowing the old ones. - We can easily extend it to handle multi-instances by relaxing the consistency check. - It assumes *-hide-all-packages* at the beginning. This scheme probably works less well without that: now we need some consistent view of the database to start with. What do people think? Cheers, Edward

4 7

Multiple imports on single line
by eng. Vassil Ognyanov Keremidchiev 31 Jul '14

31 Jul '14

Hello, dear GHC developers! Is it possible to add such constructions in next GHCs: import Data.List, Data.Array, Data.Aeson, Network.HTTP.Conduit on a single line. This will simplify source code and clear the space before the actual code. Best regards, Vassil Keremidchiev

2 1

pthread.h missing
by Simon Peyton Jones 31 Jul '14

31 Jul '14

On Windows rts/T8124 is failing thus: T8124_c.c:4:21: fatal error: pthread.h: No such file or directory compilation terminated. *** unexpected failure for T8124(threaded1) Simon

2 1

Haskell Platform 2014.2.0.0 Release Candidate 3
by Mark Lentczner 31 Jul '14

31 Jul '14

Small update to the Haskell Platfrom 2014.2.0.0 release: We have new Release Candidate 3 versions of the source tarball... and a new generic-linux bindist of the platform! - source tarball: haskell-platform-2014.2.0.0-srcdist-RC3.tar.gz <http://www.ozonehouse.com/mark/platform/haskell-platform-2014.2.0.0-srcdist…> - generic linux: haskell-platform-2014.2.0.0-unknown-linux-x86_64-RC3.tar.gz <http://www.ozonehouse.com/mark/platform/haskell-platform-2014.2.0.0-unknown…> *Windows and OS X users: There are no RC3 versions - as the RC2 versions seem to be holding up fine!* *General* - hptool (and hence ./platform.sh script) take a new --prefix parameter that is used for generic (non-OS X, non-Windows) builds: It sets the root under which haskell installations are located. Defaults to /usr/local/haskell. Everything will be placed in a directory named ghc-7.8.3-<arch> under this prefix. - activate-hs script for default Posix-like builds - small fixes to allow bootstrapping the platform with GHC 7.4 - README and LICENSE updated *Source Tarball* - all missing pieces now present - build platfrom from source tarball verified *Generic Linux Binary Dist* - Built from the GHC's generic Linux bindist for Deb 7 style systems - Complete tarball: this is all you need to install Haskell on a compatible system - Built on Ubuntu 12.04LTS - Tested on Ubuntu 14 - my system needed a symlink from libgmp.so to libgmp.so.10 - this seems to be an issue with the GHC bindist built components To install this: cd / sudo tar xvf ~/haskell-platform-2014.2.0.0-unknown-linux-x86_64-RC3.tar.gz sudo /usr/local/haskell/ghc-7.8.3-x8_64/bin/activate-hs This will finish the package registration, and install symlinks from /usr/local/bin for all the standard haskell command line tools. — Mark *shasum -a 256:* ab759ec50618f2604163eca7ad07e50c8292398a2d043fdc1012df161b2eb89a haskell-platform-2014.2.0.0-srcdist-RC3.tar.gz 0da6879ae657481849e7ec4e5d3c4c035e090824167f97434b48af297ec17cf9 haskell-platform-2014.2.0.0-unknown-linux-x86_64-RC3.tar.gz

1 0

Forcing apps to collect GC stats?
by Bryan O'Sullivan 31 Jul '14

31 Jul '14

I spent a bit of time over the weekend trying to figure out how to force the RTS to collect GC statistics, but was unable to do so. I'm currently working on enriching criterion's ability to gather data, among which I'd like to see GC statistics. If I try to obtain GC stats using criterion when I'm not running the benchmark app with +RTS -T, I get an exception. Is there a way to allow criterion to forcibly enable stats collection? My efforts to do so have gotten me nowhere. It would be unfortunate if I had to tell users of criterion that they should always run with +RTS -T or add a -rtsopts clause, as they'll simply forget. And while I'm asking, why does GHC not simply collect GC stats by default? Collecting them seems to have zero cost, from what I can see? Thanks! Bryan.

5 7

RE: A couple of GHC-API questions
by Simon Peyton Jones 31 Jul '14

31 Jul '14

| This is what I mean by “resolving” the types. For single-module programs | this is trivial, we can do something like | | resolve x = do rn <- hscParseIdentifier x | hscTcRnLookupRdrName rn | | For multi-module programs it becomes trickier because we also have to | resolve the types that we’ve imported from other modules. No, that is no harder **provided those types are in scope**. So suppose you have module M where import A( Foo ) f :: Int -> Int {-# LIQUID f :: { x | ..blah..Foo..blah } -> Int #-} Here I am supposing that the Liquid Haskell specification is in a pragma of M, and mentions an imported data type Foo. To resolve the string "Foo" to the Name A.Foo (or Bar.Foo, or whatever), hscTcRnLookupRdrName will work just fine. If you import Foo qualified, then of course you'll have to use a qualified name in the source module M where import qualified A( Foo ) f :: Int -> Int {-# LIQUID f :: { x | ..blah..A.Foo..blah } -> Int #-} If you *don't* import Foo at all, then it's utterly non-obvious where to look for it, so I don't suppose you are doing that. In short, why doesn’t hscTcRnLookupRdrName do the job? Incidentally, it doesn't make sense to ask if a Name is "in scope". Only RdrNames can be "in scope" or "not in scope". Simon | example from earlier, when we type-check module B we have to turn the | String “Foo” into the Name A.Foo. This is problematic because module B | imported module A qualified, so “Foo” is not in scope inside B but | “A.Foo” is. | | I believe GHC might be avoiding this issue via the .hi files, so when you | import a Type from another module, it is already using TyCons instead of | Strings. | | > Later you say "is there a simple way to ask GHC to resolve the name x | in the context of module | > m". You could mean | > * Imagine that the unqualified name "x" appeared in module m. How do I | look it up, in m's | > top-level lexical environment. | > but I don’t think that is what you mean. | | I think this is almost exactly what I mean, except that I want to be able | to look up the unqualified “x” as well as the qualified | “SomeModuleThatMayHaveBeenRenamed.x” inside m’s top-level environment. | This is more or less what the | DynamicLoading.lookupRdrNameInModuleForPlugins function that I’ve copied | and tweaked does, but it requires the presence of the original source | code. I’m hoping there may be some other function out there that does the | same thing without requiring the source code, so we can use it for the | base libraries as well. | | > I'm confused. Could you be more concrete? | > Possibly this may help? | https://ghc.haskell.org/trac/ghc/wiki/Commentary/Compiler/NameType | | Thanks for the reference, I’m familiar with most of the info there | already from browsing GHC’s source, but this is laid out much more | newcomer-friendly manner :) | | Hopefully I’ve made my question a bit clearer. | | Eric

2 4

The build is broken: docs/users_guide/users_guide.xml
by Páli Gábor János 31 Jul '14

31 Jul '14

Hi there, I have dblatex installed on my builders that makes them failing for the last few days, e.g. [1]. The cause of the failure is this: "/usr/local/bin/dblatex" -P 'filename.as.url=0' docs/users_guide/users_guide.xml --ps -o docs/users_guide/users_guide.ps [..] Build users_guide.ps latex failed users_guide.tex:6509: Lonely \item--perhaps a missing list environment. users_guide.tex:6509: leading text: ...-{}\-i\-p\-i\-d} \index{-{}-{}ipid} }] Unexpected error occured The version of dblatex is 0.3.2. [1] http://haskell.inf.elte.hu/builders/freebsd-amd64-head/336/10.html

1 0

Re: [commit: ghc] master: rts: add Emacs 'Local Variables' to every .c file (39b5c1c)
by Simon Marlow 31 Jul '14

31 Jul '14

4 4

RE: Overlapping and incoherent instances
by Simon Peyton Jones 31 Jul '14

31 Jul '14

| My proposal is to have just one pragma, e.g. OVERLAP, that allows | overlap in either direction. But if you have examples whether the | extra sophistication introduced by a separation into OVERLAPPABLE and | OVERLAPPING is needed, I am happy to go along... Great! As you'll see the proposal, "OVERLAPS" is precisely what you want. I don't care whether it is called "OVERLAP" or "OVERLAPS". So it sounds as if you are content. (I assume you don't want to *prevent* careful programmers from saying something more precise.) Simon | | On 31.07.2014 10:13, Simon Peyton Jones wrote: | > Andreas, remember that GHC 7.8 already implements (essentially) the | same algorithm. The difference is that 7.8 offers only the brutal - | XOverlappingInstances to control it. In your example of the decision | you make when writing | > instance Bla a => Bla [a] | > vs | > instance {-# OVERLAPPABLE #-} Bla a => Bla [a] you are, with GHC | > 7.8, making precisely the same decision when you decide whether or | not to add {-# LANGUAGE OverlappingInstances #-} to that module. | Perhaps that wasn't clear in what I wrote; apologies. | > | > So your proposal seems to be this | > | > don't remove -XOverlappingInstances, because that will prevent | > programmers from "flipping on/off pragmas until their program | > goes through". | > | > It's hard to argue AGAINST providing the opportunity for more careful | programmers to express their intentions more precisely, which is what | the OVERLAP/OVERLAPPABLE pragmas do. | > | > Concerning deprecating OverlappingInstances, my gut feel is that it | is positively a good thing to guide programmers towards a more robust | programming style. But my reason for starting this thread was to see | whether or not others' gut feel is similar. | > | > Simon | > | > | -----Original Message----- | > | From: Libraries [mailto:libraries-bounces@haskell.org] On Behalf Of | > | Andreas Abel | > | Sent: 31 July 2014 08:59 | > | To: Simon Peyton Jones; ghc-devs; GHC users; Haskell Libraries | > | (libraries(a)haskell.org) | > | Subject: Re: Overlapping and incoherent instances | > | | > | On 31.07.2014 09:20, Simon Peyton Jones wrote: | > | > Friends, in sending my message below, I should also have sent a | > | > link to | > | > | > | > https://ghc.haskell.org/trac/ghc/ticket/9242#comment:25 | > | | > | Indeed. | > | | > | Quoting from the spec: | > | | > | * Eliminate any candidate IX for which both of the following | hold: | > | * There is another candidate IY that is strictly more specific; | > | that is, IY is a substitution instance of IX but not vice | versa. | > | | > | * Either IX is overlappable or IY is overlapping. | > | | > | Mathematically, this makes a lot of sense. But put on the hat of | > | library writers, and users, and users that don't rtfm. Looking out | > | from under this hat, the one may always wonder whether one should | > | make one's generic instances OVERLAPPABLE or not. | > | | > | If I create a library with type class Bla and | > | | > | instance Bla a => Bla [a] | > | | > | I could be a nice library writer and spare my users from declaring | > | their Bla String instances as OVERLAPPING, so I'd write | > | | > | instance {-# OVERLAPPABLE #-} Bla a => Bla [a] | > | | > | Or maybe that would be malicious? | > | | > | I think the current proposal is too sophisticated. There are no | > | convincing examples given in the discussion so far that demonstrate | > | where this sophistication pays off in practice. | > | | > | Keep in mind that 99% of the Haskell users will never study the | > | instance resolution algorithm or its specification, but just flip | > | on/off pragmas until their code goes through. [At least that was | my | > | approach: whenever GHC asks for one more LANGUAGE pragma, just | throw | > | it in.] | > | | > | Cheers, | > | Andreas | > | | > | | > | > Comment 25 describes the semantics of OVERLAPPING/OVERLAPPABLE | > | > etc, which I signally failed to do in my message below, leading | to | > | > confusion in the follow up messages. My apologies for that. | > | > | > | > Some key points: | > | > | > | > *There is a useful distinction between /overlapping/ and | > | > /overlappable/, but if you don't want to be bothered with it you | > | > can just say OVERLAPS (which means both). | > | > | > | > *Overlap between two candidate instances is allowed if /either/ | > | > has the relevant property. This is a bit sloppy, but reduces the | > | > annotation burden. Actually, with this per-instance stuff I | think | > | > it'd be perfectly defensible to require both to be annotated, but | > | > that's a different discussion. | > | > | > | > I hope that helps clarify. | > | > | > | > I'm really pretty certain that the basic proposal here is good: | it | > | > implements the current semantics in a more fine-grained manner. | > | > My main motivation was to signal the proposed deprecation of the | > | > global per-module flag -XoverlappingInstances. Happily people | > | > generally | > | seem | > | > fine with this. It is, after all, precisely what deprecations | are | > | for | > | > ("the old thing still works for now, but it won't do so for ever, | > | > and you should change as soon as is convenient"). | > | > | > | > Thanks | > | > | > | > Simon | > | > | > | > *From:*Libraries [mailto:libraries-bounces@haskell.org] *On | Behalf | > | > Of *Simon Peyton Jones | > | > *Sent:* 29 July 2014 10:11 | > | > *To:* ghc-devs; GHC users; Haskell Libraries | > | > (libraries(a)haskell.org) | > | > *Subject:* Overlapping and incoherent instances | > | > | > | > Friends | > | > | > | > One of GHC's more widely-used features is overlapping (and | > | > sometimes | > | > incoherent) instances. The user-manual documentation is here | > | > <http://www.haskell.org/ghc/docs/latest/html/users_guide/type- | clas | > | > s- | > | extensions.html#instance-overlap>. | > | > | > | > The use of overlapping/incoherent instances is controlled by | > | > LANGUAGE | > | > pragmas: OverlappingInstances and IncoherentInstances | respectively. | > | > | > | > However the overlap/incoherent-ness is a property of the | > | > **instance | > | > declaration** itself, and has been for a long time. Using | > | > LANGUAGE OverlappingInstances simply sets the "I am an | overlapping instance" | > | > flag for every instance declaration in that module. | > | > | > | > This is a Big Hammer. It give no clue about **which** particular | > | > instances the programmer is expecting to be overlapped, nor which | are | > | > doing the overlapping. It brutally applies to every instance | in | > | the | > | > module. Moreover, when looking at an instance declaration, there | > | > is no nearby clue that it might be overlapped. The clue might be | > | > in the command line that compiles that module! | > | > | > | > Iavor has recently implemented per-instance-declaration pragmas, | > | > so you can say | > | > | > | > instance {-# OVERLAPPABLE #-} Show a => Show [a] where ... | > | > | > | > instance {-# OVERLAPPING #-} Show [Char] where ... | > | > | > | > This is much more precise (it affects only those specific | > | > instances) and it is much clearer (you see it when you see the | > | > instance | > | declaration). | > | > | > | > This new feature will be in GHC 7.10 and I'm sure you will be | > | > happy about that. *But I propose also to deprecate the LANGUAGE | > | > pragmas OverlappingInstances and IncoherentInstances*, as way to | > | > encourage everyone to use the new feature instead of the old big | > | > hammer. The old LANGUAGE pragmas will continue to work, of | > | > course, for at least another complete release cycle. We could | > | > make that two cycles if it | > | was helpful. | > | > | > | > However, if you want deprecation-free libraries, it will entail a | > | wave | > | > of library updates. | > | > | > | > This email is just to warn you, and to let you yell if you think | > | > this | > | is | > | > a bad idea. It would actually not be difficult to retain the | old | > | > LANGUAGE pragmas indefinitely - it just seems wrong not to | > | > actively push authors in the right direction. | > | > | > | > These deprecations of course popped up in the test suite, so I've | > | been | > | > replacing them with per-instance pragmas there too. | Interestingly | > | > in some cases, when looking for which instances needed the | > | > pragmas, I found...none. So OverlappingInstances was entirely | > | > unnecessary. Maybe library authors will find that too! | > | > | > | > Simon | > | > | > | > | > | > | > | > _______________________________________________ | > | > Libraries mailing list | > | > Libraries(a)haskell.org | > | > http://www.haskell.org/mailman/listinfo/libraries | > | > | > | | > | | > | -- | > | Andreas Abel <>< Du bist der geliebte Mensch. | > | | > | Department of Computer Science and Engineering Chalmers and | > | Gothenburg University, Sweden | > | | > | andreas.abel(a)gu.se | > | http://www2.tcs.ifi.lmu.de/~abel/ | > | _______________________________________________ | > | Libraries mailing list | > | Libraries(a)haskell.org | > | http://www.haskell.org/mailman/listinfo/libraries | > _______________________________________________ | > Libraries mailing list | > Libraries(a)haskell.org | > http://www.haskell.org/mailman/listinfo/libraries | > | | | -- | Andreas Abel <>< Du bist der geliebte Mensch. | | Department of Computer Science and Engineering Chalmers and Gothenburg | University, Sweden | | andreas.abel(a)gu.se | http://www2.tcs.ifi.lmu.de/~abel/

1 0