- Glasgow-haskell-users

Re: How to describe this bug?
by Tyson Whitehead 10 Jul '12

10 Jul '12

On July 10, 2012 10:39:41 Colin Adams wrote: > Sure they would be better modelled that way, but the whole point of using > floating point arithmetic is to sacrifice accuracy for performance, is it > not? True. I just find it interesting that some types have a builtin Nothing value. Some further examples are pointer (where NULL is Nothing) and clamped/saturation arithmetic (where min and max values are Nothing). It would be nice if somehow they could be unified at the top level without the performance penalty associated with a genuine Maybe value. Another possibility might be to consider NaN to encode bottom in Float#. When you constructed Float from Float# with a NaN it would give bottom. Would the existance of unboxed lifted types be a problem? Cheers! -Tyson

1 0

Modified layout for lambda-case
by Tyson Whitehead 09 Jul '12

09 Jul '12

It seems my suggestion isn't getting too much traction. It occurs to me this may be because I jumped right into layout rules and didn't first give some simple motivating examples to get the idea across. SHORT VERSION: Assume '\' is a grouping construct. I proposed always interpreting ... \x -> do (3a) ... as ... \ { x -> do { ... } } (3b) and never as ... \ { x -> do { }; ... } (3c) or ... \ { x -> do { } } ... (3d) This would be apposed to our current situation of all these being possible depending on if the second line starts past (3c), at (3b), or before (3d) 'x'. We loose nothing is at best empty groups do nothing (let and where) and at worst are errors (do and case) as in the above. LONGER VERSION: What I was suggesting was to change the layout rule that gives you empty groupings. Currently nonsensical nested empty where and let clauses like let { x = ... where { }; ... } (1a) do { let { }; ... } (2a) can be expressed using layouts let x = ... where (1b) ... do let (2b) ... because each new grouping has to be indented further than the previous. This trips us up if we change '\' into a grouping construct as the common ... \x -> do (3a) ... will get interpreted incorrectly as ... \ { x -> do { } } ... (3d) It all seems silly though. At best empty grouping does nothing (let and where) and at worst is an error (do and case). Why then not always go with ... \ { x -> do { ... } } (3b) That is, if a line ends in a grouping clauses and the next line is further indented, then what follows is the associated grouped statements. It's also easier to read. Further indented lines following a grouping clause are associated with that clause. No need to identify other potential grouping clauses and check relative indentation levels. Cheers! -Tyson

1 0

More infinite simplifier bugs?
by Ron Alford 07 Jul '12

07 Jul '12

So a while back Simon added a tick counter to the simplifier: http://hackage.haskell.org/trac/ghc/ticket/5448 Are there any known bugs that can cause the simplifier to run out of memory /without/ hitting the tick counter limit? I have code that /used/ to run (at least after hacking around the previous simplifier bug): https://github.com/ronwalf/Planning With GHC 7.4.[12], it exhausts all the RAM on my machine (4GB). Compiling with -O0 fixes the problem. I can start bisecting my code to find the problem if nothing comes to mind. -Ron Alford (who seems to be good at killing the simplifier)

2 2

Creating stubs statically
by Paolo Capriotti 05 Jul '12

05 Jul '12

As explained in detail here: http://www.haskell.org/pipermail/ffi/2012-June/001867.html, it may be useful to have a form of foreign declaration that creates a static stub for a haskell function without exporting a symbol. Here is a ticket for that: http://hackage.haskell.org/trac/ghc/ticket/7048. It is not particularly clear how such a declaration would look like syntactically. In the ticket I proposed the following: foreign import ccall myCallbackPtr :: FunPtr (IO ()) = myCallback but please do suggest better alternatives. It would also be useful to see some use cases of this new form of declaration. Library binding authors: would this be a welcome addition for you? BR, Paolo

2 1

[GHC Users] Dictionary sharing
by Jonas Almström Duregård 02 Jul '12

02 Jul '12

Hi, Is there a way to ensure that functions in a class instance are treated as top level definitions and not re-evaluated? For instance if I have this: >>> class C a where list :: [a] instance List a => List [a] where list = permutations list <<< How can I ensure that list :: [[X]] is evaluated at most once for any type X (throughout my program)? I assume this is potentially harmful, since list can never be garbage collected and there may exist an unbounded number of X's. I currently have a solution that uses Typeable to memoise the result of the function based on its type. Is there an easier way? Regards, Jonas

3 4

Compiling ghcjs
by Nathan Hüsken 02 Jul '12

02 Jul '12

Hi, I hope this is the correct list to ask this question. I am trying to compile the ghcjs compiler. I am on ubuntu 12.04 and have ghc-7.4.1 installed (via apt-get). I am following the instruction I found here: https://github.com/ghcjs/ghcjs The first trouble comes with "git pull ghcjs". I get: remote: Counting objects: 42, done. remote: Compressing objects: 100% (9/9), done. remote: Total 26 (delta 22), reused 21 (delta 17) Unpacking objects: 100% (26/26), done. >From github.com:ghcjs/packages-Cabal * [new branch] encoding -> ghcjs/encoding * [new branch] ghc-7.2 -> ghcjs/ghc-7.2 * [new branch] ghc-7.4 -> ghcjs/ghc-7.4 * [new branch] master -> ghcjs/master You asked to pull from the remote 'ghcjs', but did not specify a branch. Because this is not the default configured remote for your current branch, you must specify a branch on the command line. So I am doing: git pull ghcjs ghc-7.4 Then "git branch ghc-7.4 ghcjs/ghc-7.4" gives me: fatal: A branch named 'ghc-7.4' already exists. And finaly "perl boot" fails with: Error: libraries/extensible-exceptions/LICENSE doesn't exist. Maybe you haven't done './sync-all get'? at boot line 74, <PACKAGES> line 57. What can I do? Thanks! Nathan

2 1

Strange behavior when using stable names inside ghci?
by Facundo Domínguez 29 Jun '12

29 Jun '12

Hi, The program below when loaded in ghci prints always False, and when compiled with ghc it prints True. I'm using ghc-7.4.1 and I cannot quite explain such behavior. Any hints? Thanks in advance, Facundo {-# LANGUAGE GADTs #-} import System.Mem.StableName import Unsafe.Coerce import GHC.Conc data D where D :: a -> b -> D main = do putStr "type enter" s <- getLine let i = fromEnum$ head$ s++"0" d = D i i case d of D a b -> do let a' = a sn0 <- pseq a'$ makeStableName a' sn1 <- pseq b$ makeStableName b print (sn0==unsafeCoerce sn1)

4 4

Re: Fwd: ghc-7.6 branch
by Johan Tibell 28 Jun '12

28 Jun '12

(Moving lots of people to BCC. If you want to follow this discussion it will continue on the glasgow-haskell-users(a)haskell.org list.) On Tue, Jun 26, 2012 at 3:40 PM, Ian Lynagh <ian(a)well-typed.com> wrote: > Please attribute any blame to me, not Paolo; he's only doing what I > asked him to :-) No blame to attribute. I just want to see things changed. :) > When following option 1, I think starting from the HEAD rather than the > last release makes sense in general: Maybe. It doesn't matter as I want (2). > * Some of the recent changes may have been to make the library work with > GHC HEAD, and will therefore be necessary to work with the 7.6 branch This works already today. I periodically get patches to e.g. network and containers to make it work with the current GHC HEAD. That seems to work fine. > * Some libraries will need to have version bumps, which means that other > libraries will need to loosen their dependencies, which means another > release will be needed anyway GHC is no different that any other library here though. Library A is released and thus library B needs to be updated and released. The argument here is that the author of library A needs to make a release of the author of library B's package. > so I think it's a reasonable default. But if it doesn't apply for a > particular library, then no problem, just let us know - that's why we're > e-mailing you :-) So at least don't make releases of containers (I think that's the only library I maintain that's released by GHC nowadays.) Can I please have this preference sticky in case I'm on vacation next time one of these emails go out? Aside: I don't believe this has happened yet but imagine the odd feeling of a library author, whose library was recently added as a GHC dependency, getting an email saying that if he/she doesn't reply GHC will make a release of his/her library! > That sounds like it would also work. I assume there's some way to pull > to a tag. git fetch (and thus pull) retrieves all branches and tags by default (and thus all commits pointed to by them.) Cheers, Johan

5 9

Re: Fwd: ghc-7.6 branch
by Johan Tibell 27 Jun '12

27 Jun '12

On Wed, Jun 27, 2012 at 3:20 AM, Paolo Capriotti <p.capriotti(a)gmail.com> wrote: > On Wed, Jun 27, 2012 at 12:30 AM, Johan Tibell <johan.tibell(a)gmail.com> wrote: >>> * Some libraries will need to have version bumps, which means that other >>> libraries will need to loosen their dependencies, which means another >>> release will be needed anyway >> >> GHC is no different that any other library here though. Library A is >> released and thus library B needs to be updated and released. The >> argument here is that the author of library A needs to make a release >> of the author of library B's package. > > The difference is that here the dependency is mutual, in a way. GHC needs > library B to build, and library B needs to adapt to changes to GHC. Making a local change is not the same as making a release though. I make local changes to other people's code all the time, to unblock myself until the patches have made their way upstream. I'm not against that, I'm against releasing other people's code except they explicitly ask you to. > That's not what I wrote, however. We are just creating branches at this stage. > If we do make changes and need a version bump, we will coordinate again with > the maintainer to ensure everything goes upstream normally. I know that's not what you wrote (hence the "has not happened yet" part.) But consider the scenario for a second. If GHC adds a new package as a dependency now all of a sudden the maintainer of that package is in a situation where he/she explicitly needs to state a preference to have someone else not make release versions of his/her package! > It still makes sense for us to maintain a 'ghc-x.x' branch in each of the > mirrored resositories. It doesn't have to mirror an upstream branch > necessarily, but that's the easiest way to ensure all commits end up upstream. Except this is not what happens always. Commits have not always made it upstream in the past and sometimes packages released by GHC aren't uploaded to Hackage. > The current workflow is: > > - library needs a change > - make the change locally, validate, test > - send the patch upstream This doesn't always happen. > - wait for the patch to be integrated > - pull changes into the corresponding GHC mirror Just amend > - Before release, ask maintainer to make new release the package. and we'll be in the same situation of all other packages on Hackage. > Using tags as you propose should also be possible, but it would require a > release on the part of the library maintainer every time a change is made, and > then we need to update our mirror and point it to the new tag. I don't really object to you having unreleased changes for shorter periods of time. Just you releasing them. > The advantage would be that no revision of GHC ever depends an unreleased > revision of a library, but is this really worth the extra trouble? Those > intermediate releases are not particularly meaningful, and they may even end up > being unusable with every released version of GHC. I don't think this is necessary. The problem is releasing other people's code, not having temporary deviating branches. P.S. All these problems will disappear once we have proper ACLs on Hackage, as at that point no one but the maintainer and people he/she gives permission to can upload his/her package to Hackage. -- Johan

1 0

parallel garbage collection performance
by John Lato 27 Jun '12

27 Jun '12

Hello, I have a program that is intermittently experiencing performance issues that I believe are related to parallel GC, and I was hoping to get some advice on how I might improve it. Essentially, any given execution is either slow or fast (the same executable, without recompiling), most often slow. So far I can't find anything that would trigger either case. This is with ghc-7.4.2 on 64bit linux. Here are the statistics from running with -N4 -A8m -s: slow run: 16,647,460,328 bytes allocated in the heap 313,767,248 bytes copied during GC 17,305,120 bytes maximum residency (22 sample(s)) 601,952 bytes maximum slop 73 MB total memory in use (0 MB lost due to fragmentation) Tot time (elapsed) Avg pause Max pause Gen 0 1268 colls, 1267 par 8.62s 8.00s 0.0063s 0.0389s Gen 1 22 colls, 22 par 0.63s 0.60s 0.0275s 0.0603s Parallel GC work balance: 1.53 (39176141 / 25609887, ideal 4) MUT time (elapsed) GC time (elapsed) Task 0 (worker) : 0.00s ( 0.01s) 0.00s ( 0.00s) Task 1 (worker) : 0.00s ( 13.66s) 0.01s ( 0.04s) Task 2 (bound) : 0.00s ( 13.98s) 0.00s ( 0.00s) Task 3 (worker) : 0.00s ( 18.14s) 0.16s ( 0.44s) Task 4 (worker) : 0.53s ( 17.49s) 1.29s ( 4.25s) Task 5 (worker) : 0.00s ( 17.45s) 1.25s ( 4.42s) Task 6 (worker) : 0.00s ( 14.98s) 1.75s ( 6.90s) Task 7 (worker) : 0.00s ( 21.87s) 0.02s ( 0.06s) Task 8 (worker) : 0.01s ( 37.12s) 0.06s ( 0.17s) Task 9 (worker) : 0.00s ( 21.41s) 4.88s ( 15.99s) Task 10 (worker) : 0.84s ( 43.06s) 1.99s ( 8.25s) Task 11 (bound) : 6.39s ( 51.13s) 0.06s ( 0.18s) Task 12 (worker) : 0.00s ( 0.00s) 8.04s ( 21.42s) Task 13 (worker) : 0.43s ( 28.38s) 8.14s ( 22.94s) Task 14 (worker) : 5.35s ( 29.30s) 5.81s ( 22.02s) SPARKS: 7 (7 converted, 0 overflowed, 0 dud, 0 GC'd, 0 fizzled) INIT time 0.03s ( 0.01s elapsed) MUT time 43.88s ( 42.71s elapsed) GC time 9.26s ( 8.60s elapsed) EXIT time 0.01s ( 0.01s elapsed) Total time 53.65s ( 51.34s elapsed) Alloc rate 374,966,825 bytes per MUT second Productivity 82.7% of total user, 86.4% of total elapsed gc_alloc_block_sync: 1388000 whitehole_spin: 0 gen[0].sync: 0 gen[1].sync: 0 -- -------------------------- Fast run: 42,061,441,560 bytes allocated in the heap 725,062,720 bytes copied during GC 36,963,480 bytes maximum residency (21 sample(s)) 1,382,536 bytes maximum slop 141 MB total memory in use (0 MB lost due to fragmentation) Tot time (elapsed) Avg pause Max pause Gen 0 3206 colls, 3205 par 8.34s 1.87s 0.0006s 0.0089s Gen 1 21 colls, 21 par 0.76s 0.17s 0.0081s 0.0275s Parallel GC work balance: 1.78 (90535973 / 50955059, ideal 4) MUT time (elapsed) GC time (elapsed) Task 0 (worker) : 0.00s ( 0.00s) 0.00s ( 0.00s) Task 1 (worker) : 0.00s ( 0.00s) 0.00s ( 0.00s) Task 2 (worker) : 0.00s ( 11.50s) 0.00s ( 0.00s) Task 3 (worker) : 0.00s ( 12.40s) 0.00s ( 0.00s) Task 4 (worker) : 0.58s ( 12.20s) 0.59s ( 0.61s) Task 5 (bound) : 0.00s ( 12.89s) 0.00s ( 0.00s) Task 6 (worker) : 0.00s ( 13.40s) 0.02s ( 0.02s) Task 7 (worker) : 0.00s ( 14.66s) 0.00s ( 0.00s) Task 8 (worker) : 0.95s ( 14.18s) 0.69s ( 0.76s) Task 9 (worker) : 2.82s ( 13.50s) 1.37s ( 1.44s) Task 10 (worker) : 1.72s ( 17.59s) 1.07s ( 1.16s) Task 11 (worker) : 3.99s ( 24.68s) 0.37s ( 0.38s) Task 12 (worker) : 1.24s ( 24.25s) 0.80s ( 0.82s) Task 13 (bound) : 6.18s ( 25.02s) 0.04s ( 0.04s) Task 14 (worker) : 1.46s ( 23.42s) 1.59s ( 1.65s) Task 15 (worker) : 0.00s ( 0.00s) 0.66s ( 0.66s) Task 16 (worker) : 11.00s ( 23.36s) 1.67s ( 1.70s) SPARKS: 28 (28 converted, 0 overflowed, 0 dud, 0 GC'd, 0 fizzled) INIT time 0.04s ( 0.02s elapsed) MUT time 42.08s ( 23.02s elapsed) GC time 9.10s ( 2.04s elapsed) EXIT time 0.00s ( 0.00s elapsed) Total time 51.69s ( 25.09s elapsed) Alloc rate 987,695,300 bytes per MUT second Productivity 82.3% of total user, 169.6% of total elapsed gc_alloc_block_sync: 164572 whitehole_spin: 0 gen[0].sync: 164 gen[1].sync: 18147 When I record an eventlog and view it with Threadscope, the slow run shows long frequent pauses for GC, whereas on a fast run GC is extremely fast. Running with the parallel collector disabled (-qg) is more-or-less consistently between these two runs. Given this, can anyone suggest any likely causes of this issue, or anything I might want to look for? Also, should I be concerned about the much larger gc_alloc_block_sync level for the slow run? Does that indicate the allocator waiting to alloc a new block, or is it something else? Am I on completely the wrong track? Thanks very much, John L.

7 12