- ghc-devs - Haskell.org

Re: Update Cabal submodule to HEAD (1.21)
by Joachim Breitner 24 Jul '14

24 Jul '14

Hi, Am Samstag, den 19.07.2014, 01:14 +0100 schrieb Edward Z.Yang: > The reason for this is that the builders do not have a sufficiently > recent version of process, which Cabal has upgraded to depend on. > Probably 'cabal update && cabal install process' should bring it up to > date and make it working. Unfortunately, the build system bypasses > Cabal for the bootstrap build of Cabal, so the version dependency range > is not checked. didn’t seem to help just like that. https://api.travis-ci.org/jobs/30346178/log.txt?deansi=true Probably because of "-no-user-package-db". Trying with "cabal install --global" now. > BTW, I noticed the builders are still bootstrapping from 7.4. Since > 7.8 was stabilized recently, we're going to be retiring support for > bootstrapping from 7.4 soon. Upgrade! 7.4 is still the version in the latest Debian stable release, as well as the almost latest Ubuntu LTS release (14.4 is still kinda new). But I guess I can install ghc from a PPA on travis. It doesn’t help with the process problem, though, that also affects 7.6. Greetings, Joachim -- Joachim “nomeata” Breitner mail(a)joachim-breitner.de • http://www.joachim-breitner.de/ Jabber: nomeata(a)joachim-breitner.de • GPG-Key: 0xF0FBF51F Debian Developer: nomeata(a)debian.org

2 7

Re: GHCi: Behave nicely on `-e`, like `ghc` and other programs
by Alexander Berntsen 24 Jul '14

24 Jul '14

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 24/07/14 01:29, Andrew Pennebaker wrote: > Like many programming language environments, GHC offers a handy > `-e` option for evaluating an expression, then returning to the > shell. > > $ ghc -e '2 + 2' > > 4 > > One would expect the interpreter, GHCi, to offer a similar flag, > but it surprisingly rejects it. > > ghci -e '2 + 2' > > ghc: on the commandline: cannot use `--interactive' with `-e' > > Usage: For basic information, try the `--help' option. > > > I think this behavior is quite unintuitive--when I pass `-e <exp>` > to ghci, or pass `--interactive -e <exp>` to ghc, I expect the > expression to be evaluated as the leading expression in an > interactive interpreter session. > > > Could we please tweak ghc like this to make it slightly more > intuitive when these flags are used together? Good idea! I'll look into it. But did you mean to post this to the ghc-devs list? I've CC'd them with your entire email intact. Also, in case I forget all about this or fail, you should add a ticket to our Trac system[0]. That way, this won't get lost. Thanks! [0] <https://ghc.haskell.org/trac/ghc/> - -- Alexander alexander(a)plaimi.net https://secure.plaimi.net/~alexander -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iF4EAREIAAYFAlPQxhUACgkQRtClrXBQc7XylgEAqbDrspchvHllACPf9lwrFTbN YenIDCggXbj98NJR5/8BAJUxpkej6T6QV4G+jk9R61nbUOEASEJ+0GBcHLBXpAsw =3/+R -----END PGP SIGNATURE-----

1 0

The haddock / clang problem revisited ... root cause found...
by Mark Lentczner 23 Jul '14

23 Jul '14

tl;dr: - cabal is the culprit - If you have the `Extensions: CPP` directive in your .cabal file, then when invoking haddock, cabal causes every file to be pre-processed twice in sequence. - pre-processing isn't idempotent - when done under clang, it outputs things that ghc. longer: Regarding the ellusive problem whereby haddock for some packages fails on ghc-7.8.3 / haddock-2.14.2 systems with clang (as in OS X 10.9): Bugs were filed for both haddock and cabal: https://github.com/haskell/haddock/issues/284 https://github.com/haskell/cabal/issues/1740 I've been trying to find a work-around before releasing the platform for OS X. In sleuthing this I found the root cause: cabal. Full details here: Root cause of haddock / clang failure <https://gist.github.com/mzero/d4ba11c567977111749a> The correct fix is to change cabal's behavior: Either don't pre-process the fils for Haddock, or don't pass --optghc=-XCPP There is no good work around: We could add -optP-P to all compilations, but that breaks line numbers for everything. We could wrap haddock to remove the --optghc=-XCPP, but that will break hand invocations of haddock. - Mark

2 3

Call for help on testing integer-gmp2 on non-Linux archs
by Herbert Valerio Riedel 23 Jul '14

23 Jul '14

Hello *, As some of you may have already noticed, there's an attempt[1] in the works to reimplement integer-gmp in such a way to avoid overriding GMP's internal memory allocator functions, and thus make it possible to link GHC/integer-gmp compiled programs with other components linked to libgmp which break if GMP's memory allocation goes via GHC's GC. I also hope this will facilitate to ship GHC bindists for Windows with a dynamically linked (& unpatched!) GMP library, to reduce LGPL licencing concerns for resulting GHC compiled programs. So far, I've only been able to test the code on Linux/i386 and Linux/amd64 where it works correctly. Now it'd be interesting to know if integer-gmp2 in its current form works also on non-Linux archs, and if not, what's needed to make it work. Fwiw, I mostly suspect linker-related issues. Therefore, is anyone here interested to help out with making sure GHC+integer-gmp2 builds on Windows, OSX and so on? If so, please get into contact with me! Cheers, hvr [1]: https://ghc.haskell.org/trac/ghc/ticket/9281 https://phabricator.haskell.org/D82

4 6

Looking for list comprehensions use cases
by Jan Stolarek 23 Jul '14

23 Jul '14

Haskellers, recently I've been looking into the possibility of creating some new optimisations for GHC. These would be mostly aimed at list comprehensions. Here's where I need your help: 1. Do you have complex list comprehensions usage examples from real code? By complex I mean nested list comprehensions, reading from more than one list ([ ...| x <- xs, y <- ys ... ]) etc. 2. Do you have list comprehensions code that you had to optimize by hand because GHC was unable to make them fast enough? Janek

1 0

a little phrustrated
by Richard Eisenberg 22 Jul '14

22 Jul '14

Hi all, I'm trying to use Phab for the first time this morning, and hitting a fair number of obstacles. I'm writing up my experiences here in order to figure out which of these are my fault, which can be fixed, and which are just things to live with; and also to help others who may go down the same path. If relevant, my diff is at https://phabricator.haskell.org/D73 1) I had some untracked files in a submodule repo. I couldn't find a way to get `arc diff` to ignore these, as they appeared to git to be a change in a tracked file (that is, a change to a submodule, which is considered tracked). `git stash` offered no help, so I had to delete the untracked files. This didn't cause real pain (the files were there in error), but it seems a weakness of the system if I can't make progress otherwise. 2) I develop and build in the same tree. This means that I often have a few untracked files in the outer, ghc.git repo that someone hasn't yet added to .gitignore. Thus, I need to say `--allow-untracked` to get `arc diff` to work. I will likely always need `--allow-untracked`, so I looked for a way to get this to be configured automatically. I found https://secure.phabricator.com/book/phabricator/article/arcanist/#configura… , but the details there are sparse. Any advice? 3) The linter picks up and complains about tabs in any of my touched files. I can then write an excuse for every `arc diff` I do, or de-tab the files. In one case, I changed roughly one line in the file (MkCore.lhs) and didn't think it right to de-tab the whole file. Even if I did de-tab the whole file, then my eventual `arc land` would squash the whitespace commit in with my substantive commits, which we expressly don't want. I can imagine a fair amount of git fiddling which would push the whitespace commit to master and then rebase my substantive work on top so that the final, landed, squashed patch would avoid the whitespace changes, but this is painful. And advice on this? Just ignore the lint errors and write silly excuses? Or, is there a way Phab/arc can be smart enough to keep whitespace-only commits (perhaps tagged with the words "whitespace only" in the commit message) separate from other commits when squashing in `arc land`? 4) For better or worse, we don't currently require every file to be tab-free, just some of them. Could this be reflected in Phab's lint settings to avoid the problem in (3)? (Of course, a way to de-tab and keep the history nice would be much better!) 5) In writing my revision description, I had to add reviewers. I assumed these should be comma-separated. This worked and I have updated the Wiki. Please advise if I am wrong. 6) When I looked at my posted revision, it said that the revision was "closed"... and that I had done it! slyfox on IRC informed me that this was likely because I had pushed my commits to a wip/... branch. Is using wip branches with Phab not recommended? Or, can Phab be configured not to close revisions if the commit appears only in wip/... branches? 7) How can I "re-open" my revision? 8) Some time after posting, phaskell tells me that my build failed. OK. This is despite the fact that Travis was able to build the same commit (https://travis-ci.org/ghc/ghc/builds/30066130) I go to find out why it failed, and am directed to build log F3870 (https://phabricator.haskell.org/file/info/PHID-FILE-hz2r4sjamkkrbf7nsz6b/) I can't view the file online, but instead have to download and then ungzip it. Is it possible to view this file directly? Or not have it be compressed? 9) When I do view the build log, I get no answers. The end of the file comes abruptly in the middle of some haddock output, and the closest thing that looks like an error is about a missing link in a haddock tag `$kind_subtyping` in Type.lhs. I didn't touch this file, and I imagine the missing link has been there for some time, so I'm dubious that this is the real problem. Are these log files cut off? 10) More of a question than a phrustration: is there a way to link directly to Trac tickets and/or wiki pages from Phab comments? I like the Phab:D73 syntax from Trac to Phab, and thanks, Austin, for adding the field at the top of Trac tickets to Phab revisions. I did fully expect to hit a few bumps on my first use of this new tool, but it got to the point where I thought I should seek some advice before continuing to muddle through -- hence this email. I do hope my tone is not overly negative: I'm *very* appreciative of the work that many of you do to support GHC's infrastructure, and I look forward to being able to get and provide source code feedback through Phab. We just need to work out some kinks, I think! (Any number of these kinks may be solely my fault, of course.) Many thanks, Richard

8 9

RE: tcInferRho
by Simon Peyton Jones 22 Jul '14

22 Jul '14

Richard You are right; there is something squishy here. The original idea was that a unification variable only stands for a *monotype* (with no for-alls). But our basic story for the type inference engine is tcExpr :: HsExpr -> TcType -> TcM HsExpr' which checks that the expression has the given expected type. To do inference we pass in a unification variable as the "expected type". BUT if the expression actually has a type like (forall a. a->a) -> Int, then the unification variable clearly isn't being unified with a monotype. There are a couple of places where we must "zonk" the expected type, after calling tcExpr, to expose the foralls. A major example is TcExpr.tcInferFun. I say this is squishy because *in principle* we could replace every unification with generating an equality constraint, for later solving. (This does often happen, see TcUnify.uType_defer.) BUT if we generate an equality constraint, the zonking won't work, and the foralls won't be exposed early enough. I wish that the story here was more solid. The original idea of tcInferRho was to have some special cases that did not rely on this squishy "unify with polytype" story. It had a number of special cases, perhaps not enough as you observe. But it does look as if the original goal (which I think was to deal with function applications) doesn't even use it -- it uses tcInferFun instead. So I think you may be right: tcInferRho may not be important. There is a perhaps-significant efficiency question though: it avoids allocating an unifying a fresh unification variable each time. Simon | -----Original Message----- | From: Richard Eisenberg [mailto:eir@cis.upenn.edu] | Sent: 18 July 2014 22:00 | To: Simon Peyton Jones | Subject: Re: tcInferRho | | I thought as much, but I can't seem to tickle the bug. For example: | | > {-# LANGUAGE RankNTypes #-} | > | > f :: Int -> Bool -> (forall a. a -> a) -> Int | > f = undefined | > | > x = (3 `f` True) | > | | | GHCi tells me that x's type is `x :: (forall a. a -> a) -> Int`, as we | would hope. If we were somehow losing the higher-rank polymorphism | without tcInferRho, then I would expect something like `(3 `f` True) $ | not)` to succeed (or behave bizarrely), but we get a very sensible type | error | | Couldn't match type 'a' with 'Bool' | 'a' is a rigid type variable bound by | a type expected by the context: a -> a | at /Users/rae/temp/Bug.hs:6:5 | Expected type: a -> a | Actual type: Bool -> Bool | In the second argument of '($)', namely 'not' | In the expression: (3 `f` True) $ not | | So, instead of just adding more cases, I wonder if we can't *remove* | cases, as it seems that the gears turn fine without this function. This | continues to surprise me, but it's what the evidence indicates. Can you | make any sense of this? | | Thanks, | Richard | | | On Jul 18, 2014, at 12:49 PM, Simon Peyton Jones <simonpj(a)microsoft.com> | wrote: | | > You're right, its' an omission. The reason for the special case is | described in the comment on tcInferRho. Adding OpApp would be a Good | Thing. A bit tiresome because we'd need to pass to tcInferApp the | function to use to reconstruct the result HsExpr (currently foldl | mkHsApp, in tcInferApp), so that in the OpApp case it'd reconstruct an | OpApp. | > | > Go ahead and do this if you like | > | > S | > | > | -----Original Message----- | > | From: Richard Eisenberg [mailto:eir@cis.upenn.edu] | > | Sent: 17 July 2014 18:48 | > | To: Simon Peyton Jones | > | Subject: tcInferRho | > | | > | Hi Simon, | > | | > | I'm in the process of rejiggering the functions in TcHsType to be | more | > | like those in TcExpr, in order to handle the richer type/kind | language | > | of my branch. | > | | > | I have a question about tcInferRho (TcExpr.lhs:115). It calls | > | tcInfExpr, which handles three special cases of HsExpr, before | > | deferring to tcExpr. The three cases are HsVar, HsPar, and HsApp. | > | What's odd about this is that there are other cases that seem to | belong | > | in this group, like OpApp. After all, (x + y) and ((+) x y) should | > | behave the same in all circumstances, right? I can't find a way to | > | tickle the omission here, so there may not be a bug, but it certainly | > | is a little strange. Can you shed any light? | > | | > | Thanks! | > | Richard | >

2 4

Re: [QuickCheck] Status of Haskell Platform 2014.2.0.0
by Johan Tibell 22 Jul '14

22 Jul '14

On Mon, Jul 21, 2014 at 1:30 AM, Nick Smallbone <nicsma(a)chalmers.se> wrote: > 1. We make sure that tf-random becomes stable and hope it can be > included in the next version of the platform. > > 2. We add a simple TFGen-inspired generator directly to QuickCheck. > > 3. We fix StdGen by replacing it with a TFGen-inspired implementation. > > Number 3 would be best for everyone, but if it doesn't happen maybe > option 2 is the most pragmatic one. I agree that (2) looks like the most pragmatic one.

1 0

Re: Multi-instance packages status report
by Joachim Breitner 22 Jul '14

22 Jul '14

[Replying to the list, in case it was sent to me in private by accident] Hi Edward, Am Montag, den 21.07.2014, 23:25 +0100 schrieb Edward Z.Yang: > Excerpts from Joachim Breitner's message of 2014-07-21 21:06:49 +0100: > > maybe a stupid question, but how does the package key relate to the hash > > that "ghc-pkg" shows for package? > > Fine question---this is definitely something that is different from the > GSoC project. The short answer is, the current hash shown in ghc-pkg is > the ABI hash associated with the InstalledPackageId, which is computed > after GHC is done compiling your code; whereas the package key is a > hash of the dependency graph, which can be done before compilation. > > The longer answer is we now have three ID-like things, in order of > increasing specificity: > > Package IDs: containers-0.9 > These are the "user visible" things that we expect users to talk > about in Cabal file > Package Keys: md5("containers-0.9" + transitive deps) > These are the identifiers the compiler cares about: they are used > for type equality, and contain a bit more detail than we expect > a user to normally need---however, a user might need to refer to > this to disambiguate in some situations. > Installed Package IDs: ABI hash of compiled code > This uniquely identifies an installed package in the database, up > to ABI. > > So, if two packages have the same IPID, their package keys are > guaranteed to be the same, but not vice versa. (And likewise for package > IDs.) thanks for the explanations, it makes it clear to me. Do the package key contain the flags used to compile dependencies? In the example where it could matter the flag would change that package’s key, so maybe it is redundant.... And just to confirm my understandn: If we had a completely reproducible environment, the same key would (conceptually, not practically) imply the same IPID, right? Greetings, Joachim -- Joachim “nomeata” Breitner mail(a)joachim-breitner.de • http://www.joachim-breitner.de/ Jabber: nomeata(a)joachim-breitner.de • GPG-Key: 0xF0FBF51F Debian Developer: nomeata(a)debian.org

3 4

SV: Windows breakage -- again
by Niklas Larsson 22 Jul '14

22 Jul '14

I posted a working and tested patch last night. Please feel free to commit it, I haven't the rights to do it. Niklas ----- Ursprungligt meddelande ----- Från: "Simon Peyton Jones" <simonpj(a)microsoft.com> Skickat: ‎2014-‎07-‎18 15:55 Till: "Niklas Larsson" <metaniklas(a)gmail.com>; "Johan Tibell" <johan.tibell(a)gmail.com> Kopia: "ghc-devs(a)haskell.org" <ghc-devs(a)haskell.org> Ämne: RE: Windows breakage -- again Thank you all for pursuing this. I gather that you know what is going on, so no further info needed from me. Yell if it is otherwise. Meanwhile, is the fix imminent, or should we revert Johan’s patch? Simon From: Niklas Larsson [mailto:metaniklas@gmail.com] Sent: 16 July 2014 19:58 To: Johan Tibell; Simon Peyton Jones Cc: ghc-devs(a)haskell.org Subject: Re: Windows breakage -- again I get the same failure when I try to build HEAD. Turns out the error occurs on the 32-bit Windows build, and my successful build was a 64-bit build. My 64-bit build still succeeds. Also, gcc is 4.5.2 on 32-bit, not 4.6.3 as on 64-bit. Niklas 2014-07-16 14:48 GMT+02:00 Niklas Larsson <metaniklas(a)gmail.com>: I have built ghc on windows after that was added with no issue. I can take a look this evening and see how HEAD works for me. The standard gcc in the tarballs is 4.6.3, which is getting long in the tooth, there is an issue on trac to upgrade it. -- Niklas Från: Johan Tibell Skickat: ‎2014-‎07-‎16 09:57 Till: Simon Peyton Jones Kopia: ghc-devs(a)haskell.org Ämne: Re: Windows breakage -- again You can rollback the commit (git revert 4ee4ab01c1d97845aecb7707ad2f9a80933e7a49) and push that to the repo if you wish. I will try to re-add the primop again after I figure out what's wrong. On Wed, Jul 16, 2014 at 9:37 AM, Johan Tibell <johan.tibell(a)gmail.com> wrote: I added some primops about a month ago (4ee4ab01c1d97845aecb7707ad2f9a80933e7a49) that call __sync_fetch_and_add, a gcc/llvm builtin. I'm a bit surprised to see this error. The GCC manual [1] says: > " Not all operations are supported by all target processors. If a particular operation cannot be implemented on the target processor, a warning will be generated and a call an external function will be generated. The external function will carry the same name as the builtin, with an additional suffix `_n' where n is the size of the data type." I'm a bit surprised by this error for two reasons: * A call to that symbol should only be generated if the CPU doesn't support the atomic instructions. What CPU model does Windows report that you have? * gcc should define such a symbol. For me the following test program compiles: #include <stdint.h> uint8_t test(uint8_t* ptr, uint8_t val) { return __sync_fetch_and_add_1(ptr, val); } int main(void) { uint8_t n; return test(&n, 1); } Does that compile for you? Which version of GCC do we end up using on Windows? The reported symbol (___sync_fetch_and_add_1) has three leading underscores, that looks weird. Can you compile just libraries/ghc-prim/cbits/atomic.c and see if it's indeed GCC that generates a reference to that symbol? 1. http://gcc.gnu.org/onlinedocs/gcc-4.1.2/gcc/Atomic-Builtins.html On Wed, Jul 16, 2014 at 12:29 AM, Simon Peyton Jones <simonpj(a)microsoft.com> wrote: Aargh! The Windows build has broken – again. I can’t build GHC on my laptop any more. [Hela det ursprungliga meddelandet tas inte med.]

4 8