- ghc-devs - Haskell.org

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

RFC: unsafeShrinkMutableByteArray#
by Herbert Valerio Riedel 22 Jul '14

22 Jul '14

Hello Simon (et al.) While experimenting with refactoring/improving integer-gmp, I'd like to represent a GMP number just by a ByteArrays# (and thus save a redundant limb-count field). However, for that I'd need an efficient way to resize a MutableByteArray# for the result value in case its initial size over- (or under-)allocated. Right now I'd re-allocate via newByteArray# with the final size and copyMutableByteArray#, and now I was wondering if we couldn't simply have an unsafeShrinkMutableByteArray# :: MutableByteArray# s# -> Int# -> State# s -> State# s operation, which would allow for zero-copying. (the 'unsafe' denotes this wouldn't check if the new size is less-or-equal to the current size, and that one has to be careful when subsequently using sizeofMutableByteArray# which is currently a pure function) Is such an operation feasible, or is there something in the RTS/GC that would trip over when a ByteArray has suddenly a smaller byte-count than its originally newByteArray#'ed amount? PS: maybe unsafeShrinkMutableByteArray# could unsafe-freeze the ByteArray# while at it (thus be called something like unsafeShrinkAndFreezeMutableByteArray#), as once I know the final smaller size I would freeze it anyway right after shrinking. Cheers, hvr

2 3

GHC contribution guidelines and infrastructure talk on 6th September at HIW?
by Rob Stewart 22 Jul '14

22 Jul '14

Hi, On Saturday 6th September is the Haskell Implementers Workshop. There has been plenty of discussion over the last 12 months about making contributions to GHC less formidable. Is this story going to be told at HIW? A talk about revised contribution guidelines and helpful tool support might engage those sat on, or peering over, the fence. This might include: * Phabricator code review demonstration. * Continuous integration infrastructure. * Trac demonstration, e.g. how to contribute to design discussions. * Wiki navigation, and important new pages born in recent months. * GHC coding guidelines, e.g. using notes and haddock documentation. * Git policies, e.g. use of submodules. * What GHC needs.. Windows testers? * Old contribution guidelines that no longer apply. Is HIW on 6th September a good place to give a "GHC contributions and infrastructure" talk? -- Rob

5 7

Thread status constants
by Kyle Van Berendonck 21 Jul '14

21 Jul '14

Hi, I found these: https://github.com/ghc/ghc/blob/5f3c5384df59717ca8013c5df8d1f65692867825/in… They go only 0-14, so there's some long chains of branches and stuff in hot paths that could be cleaned up into single &-masked branches by changing these into a set of flags. And then I saw these: https://github.com/ghc/ghc/blob/master/libraries/base/GHC/Conc/Sync.lhs#L483 Where does 16 and 17 come from -- I couldn't find them in the header files anywhere? Kyle

2 2